DragonFly BSD
DragonFly kernel List (threaded) for 2005-01
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: compatibility Re: link: "Recursive Make Considered Harmful"

From: Joerg Sonnenberger <joerg@xxxxxxxxxxxxxxxxx>
Date: Thu, 13 Jan 2005 17:17:15 +0100
Mail-followup-to: kernel@crater.dragonflybsd.org

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
> >makefiles:
> >    - 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,
> portability.h
>     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.


[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]