Simon Burge <simonb@netbsd.org> writes:
> No - I'd much rather use one macro do the work since it already exists
> in NetBSD.  There's no need to polute our source tree with guff that we
> don't need.  I'm happy to change fortune and monop so that they run on a
> "run of the mill" system if cross-compiling is a realistic goal of the
> project.  At the moment, the goals on the web pages[1] list "the ability
> to recompile itself", not "the ability for anything to recompile it"...

OK, I'll buy that, and then argue that the project's goals are
incomplete in one of a couple of ways, especially if it's committed to
encouraging "professionals" to use the system as a base for embedded
applications.

First, if the project wishes to support embedded systems developers,
then I think it _has_ to support cross-compilation from other systems.
Whether or not the project wants to admit it, people want to use other
systems than NetBSD on their development servers.  (I've seen that at
least twice now, in companies that were trying to use NetBSD.)  That
means the ability to build from other systems is important.

Second, even if the ability to build from other systems is not so
important, lack of reliance on host tools and libraries is.  A
significant contribution to reliability and maintainability of a
software system is reproducability of the build.  That means, in a
nutshell, being able to build the entire software system from scratch.
You can do that if you have extensive reliance on host tools, but it
makes life much harder.  (it makes setting up the environment in which
you do builds much harder.  e.g. you have to install zoularis, or
upgrade your NetBSD 'host install' to the latest and greatest bits.
and then if you're going to do that, you have to keep all of the
"environment" sources under source control, in addition to all of the
sources that you actually care about.)


In reality, games and the manual pages are probably the least
important facets of the system from an "embedded developer's" point of
view, but the mind-set that's showing up here goes much further.
Another quick example of it that i've run into recently is the whole
"use the pkgsrc cross tools if you want to cross compile" notion.

My point is: there are valid technical and license-related reasons why
system developers might want to provide NetBSD as an operating system
choice for their platform.  However, it's much harder for them to do
so than it should be, and is for other systems, because of issues like
this (if not exactly this, since they typically don't care about
games).



cgd
-- 
Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.