Chris G. Demetriou wrote:

> Jonathan Stone <jonathan@DSG.Stanford.EDU> writes:
> > 1.  Some subset of the tree has to be coded `portably enough' that
> >     it will compile painlesly on non-NetBSD systems: FreBSD, LInux,
> >     Solaris, what-have-you.
> 
> yup.  it might well be OK to have a small portability library that
> copes with some of the more commonplace non-standard functions
> (e.g. err/warn), just as e.g. the toolchain has libiberty.  however,
> it should be fairly obvious how to bootstrap the whole thing, and
> requiring a zoularis-like environment is just Too Much.
> 
> I actually think there are probably plenty of assumptions that you
> could make to make your life easier, too.  (e.g. ANSI C.)

Ok, back to my example of endian support - if we have something in
nice portable ANSI C, does this alleviate the need for things like the
endian-specific macros in <sys/endian.h> - or should they stay because
they're a nice clean interface to do what we want to do?  On a similar
note, is it worthwhile or pointless to do something like:

	#if (defined(__unix__) || defined(unix)) && !defined(USG)
	# include <sys/param.h>
	#endif
	#if defined(__NetBSD_Version__) && (__NetBSD_Version__ > something)
	# include <sys/endian.h>
	#else
	# define HTOBE64(foo) ....
	  ...
	#endif

in tools that are run on the compiling host?

Looking further, it's sortof worse with fortune - it calls the strfile
in the objdir, so this one is going to require further work to allow
cross-compiling...

Simon.