Subject: Re: fortune makefiles incorrect ?
To: None <email@example.com>
From: Simon Burge <firstname.lastname@example.org>
Date: 09/07/1999 16:34:45
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>
#if defined(__NetBSD_Version__) && (__NetBSD_Version__ > something)
# include <sys/endian.h>
# define HTOBE64(foo) ....
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