Re: [jamboost] Re: include various source based on platform

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-11-20 08:04:57

On Saturday 20 November 2004 15:48, Reece Dunn wrote:

> >>E.g. bjam cw-8.3 target-os=mac # os=NT
> >
> > Why would you want to have host os as property? After all, you can't
> > build with two host os at the moment. In other words
> >
> > bjam cw-8.3 host-os=NT host-os=LINUX
> >
> > makes no sense, so Boost.Build can just detect host os itself and use
> > this information when needed. And that means "os" can mean "target os".
>
> What I mean is that bjam defines os to be the OS that the user is
> running on (i.e. the host os). This is set internally, so you don't set
> it on the command line (thst is not what I meant).

This need to be tweaked: you current os should be default value of the "os" 
feature, but still allow user to specify a different value. What I'm saying 
that we need only one feature, there's no need for both host-os and 
target-os.

> >>One of the motivations for using <gui> as a feature, or a better name
> >>might be <os-api>, is to allow support for different APIs, e.g.:
> >>
> >> bjam msvc-8.0 os-api=win32
> >> bjam msvc-8.0 os-api=win64
> >> bjam gcc-3.3 target-os=linux os-api=x11
> >> bjam gcc-3.3 target-os=linux os-api=motif
> >
> > Maybe you're right, if you want to target Qt and gtk, then <os> would be
> > too coarse grained.
>
> We can have the following rules:
> [1] set <os> to the operating system being run (already implemented);
> [2] if <target-os> is not defined, define it to be equal to <os> (note:
> you may want to define <target-os> as NT when <os>=CYGWIN).
> [3] validate that <target-os> has an appropriate value (already
> provided via feature).
> [4] if <os-api> is not defined, define it to an appropriate default (e.g.:
> <target-os>NT:<os-api>win32
> <target-os>LINUX:<os-api>x11
> <target-os>MAC:<os-api>cocoa
> )
> [5] validate that the <os-api> value is appropriate for the value of
> <target-os> (e.g. <target-os>LINUX:<os-api>cocoa is invalid).

Interesting, it means some combination of features should be declared invalid 
and it should be checked by Boost.Build. OTOH, this is purely optional 
enhancement.

- Volodya