Re: [jamboost] Re: I'm back!

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-10-15 00:16:26

David Abrahams wrote:
> Vladimir Prus <ghost_at_[hidden]> writes:
> 
> 
>>David Abrahams wrote:
>>
>>I'm bad at writing comments, it seems, either in full or in parts :-)
>>I'll try to explain semantic verbosely.
> 
> 
> Sometimes that's the best answer for the comments, too ;-)

I'm only 30% sure I've understand this sentence. Do you mean that 
sometimes, when good comment is needed, verbose explanation of semantic 
is the best comment?

>>If you call 'generate' with full property set, in means to build it
>>with those properties. 
> 
> 
> By "full property set", do you mean one where all non-optional
> features are represented? Or do you mean something else?

I doesn't matter, taking into consideration the agreement below.

>>For example, this happens when there's a list of properties in the
>>command line, and the abstract target is directly requested.
>>
>>If you call 'generate' with a property set containing only
>><toolset>, it means to build it using the given toolset, and using
> 
> Suggest rephrase: "only <toolset>xxx"
> 
>>some default set of property sets. For example, when called with
>>"<toolset>gcc", a target with default build of "debug release" will
>>build itself with two property sets
>>
>> <toolset>gcc <variant>debug ...
>> <toolset>gcc <variant>release ...
>>
>>Why special treatment for toolset? In V1 default build is done using
>>all available toolsets. In other words, a target with default build
>>"debug" can be build with <toolset>gcc and
> 
> "built"----------^^^^^
> 
>><toolset>borland. Currently, main target's generate simply calls
>>'build-request.expand' with the value of it's default build
> 
> "its"--------------------------------------^^^^
> 
>>attribute. And 'build-request.expand' can't return property sets
>>with different values of <toolset>, unless explicit list of
>><toolset> properties is passed to it. I thought this handling of
>>predefined set of toolsets in better done at the high level, not
>>inside main-target.
>>
>>However, do we really need such semantics? 
> 
> 
> IMO, no.
> 
> 
>>In general, we don't build two variants unless explicitly
>>asked. Maybe, we can build with "default" toolset, unless asked
>>otherwise? 
> 
> 
> Yes.
> 
> 
>>IE, on my Linux box, "bjam" will build with gcc, and msvc will be
>>used for someone else?
> 
> 
> Total agreement.
> 
> It should probably use user-config.jam and site-config.jam and then
> fall back to platform-specific behavior. On Windows it should probably
> check the registry for known compilers (yes, there's a Jam extension
> for this out there) and auto-select if there's only one, notify
> otherwise.

Oh, yes! This simplifies everything dramatically. Now, generate should 
be called either with empty property set, or not non-empty. With 
non-empty, the target will be just built using those properties. 
Otherwise, it will be built with a default set of property sets. For 
example, a main target with default build of "debug release" will be 
built with

<toolset>{default-toolset} <variant>debug
<toolset>{default-toolset} <variant>release

Of course, this set of property sets can be obtained from

[ build-request.expand debug release ]

I'm gonna change build-system.jam and targets.jam accordingly right now.

- Volodya