Re: [jamboost] V2: build issues

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-02-06 01:41:37

Dave Abrahams wrote:
> On Wednesday, February 05, 2003 10:36 AM [GMT+1=CET],
> Vladimir Prus <ghost_at_[hidden]> wrote:
> 
> 
>>Dave Abrahams wrote:
>>
>>>If I understand the proposal correctly, I don't like this. In v1,
>>>default-build didn't work this way. It should be possible to build
>>>targets of a single project that require threading-multi and
>>>threading-single using the same build command.
>>
>>I'm keeping half of the truth to myself, as usual :-( I did not mean that
>>default build cannot include both <threading>single and <threading>multi.
>>I just want <threading>multi in build request if it's in default build
>>and the user did no specify threading=single on the command line.
> 
> 
> Volodya and I had a chat session about this, and though we didn't
> reach an agreement, I came to some very definite conclusions of my own
> ;o)
> 
> So, here they are:
> 
> * Default-build specifications on projects, targets, etc. are
> different from build requests. Users should be able to specify
> default build on individual targets and subprojects without them
> being overridden by (parent) projects.
> 
> One obvious use-case is that a project may have default-build
> "release", but its regression tests should be built by default in
> "debug" mode. It should certainly be possible to build the tests
> in release mode, e.g. in order to test against the optimizer. 

Yes, this is quite reasonable use-case now that you put it in words.

> It
> should also be possible for the user to request that everything
> be built in debug mode, by putting it

Looks like unfinished statement...

> 
> * all features should be treated uniformly with respect to
> default-build. That is, features specified in subprojects, even
> free features, should override the features specified in their
> parents. If the user wishes to specify additional values of a free
> feature which may have been specified in a parent, she can write:
> 
> +<feature>value
> 
> likewise, she can write
> 
> -<feature>value
> 
> to remove a feature which may have been specified in a parent's
> default-build.

Well, this leaves out an important question of how default-build are combined.
If parent has "debug" as default build and child has "threading=multi", then
what properties are used for targets in child if nothing's on command line?
Combination of the above to properties? What if there's "release" on command 
line? Will "release threading=multi" be used?

As I said in chat, relation with requirements is not clear still. We probably
could merge requirements and default build, like that:

project foo
: requirements <threading>multi *<stdlib>stlport
;

This would mean that <threading>multi will be always in properties, and
<stdlib>sltport will be in properties unless user said something different on
the command line. Alas, it's not clear how to specify "debug and release" at
the same time (or just "*relese *debug"?)
And "+"/"-" are still unclear to me. If there's <define>FOO in parements 
requirements, it should always be in properties. Well, suppose that
parent has <define>FOO *<define>BAR and child has *<define>GIZ. We
can make final properties "<define>FOO <define>GIZ", so that parent 
requirements specified without "*" are always honoured. I still don't know
why "+/-" are usefull, though.

Last thing, related but not about default-build per se. Top-level project
has default-build of "debug <define>FOO", and has two subprojects with one
targets in each: "app/app" and "lib1/lib1". The "app" project has "release"
default build, and uses "lib1/lib1". You say "bjam". Should "lib1/lib1" be
build with <define>FOO, or not? For one thing, it's under top, which has
<define>FOO in default build. For another, "app/app" uses release variant
of "lib1/lib1", and why <define>FOO should apply?

- Volodya