compatibility Re: link: "Recursive Make Considered Harmful"
joerg at britannica.bec.de
Thu Jan 13 08:18:39 PST 2005
On Wed, Jan 12, 2005 at 03:22:03PM -0500, George Georgalis wrote:
> >Some places where I have been forced to use shell variable assignment in
> > - os/arch/platform detection eg: 'uname' for multi-platform builds.
Either done *outside* the build system or support by it, e.g. Jam.
> > - converting pathnames (when dealing with Windoze systems)
Support by Jam and should be done with support from build system.
> > - wild-carding, eg: just pull in *.c as sources without having to
> >specify them manually.
This is IMO a bug in the scripts and doesn't the shell-expansion.
> > - interfacing to other build systems to extract variables
> > - interfacing to source code control systems
Read my other mail about some comments about this.
> A few months back Matt D had mentioned the idea of compatibility.h, ahem,
> Then instead of adding quirks for various OS's we could require that
> the platform provide the <portability.h> file according to the
> standard <snip> portability.h would have things like:
> #define _SPS_HAS_SENDFILE_A_ 1 /* type A sendfile */
> #define _SPS_HAS_SENDFILE_B_ 1 /* type B sendfile */
> #define _SPS_HAS_VSNPRINTF 1 /* vsnprintf supported */
> Anymore thoughts on the idea?
I'm working on something to achieve this effect for buildworld.
More information about the Kernel