Re: [jamboost] V2: build issues

From: David Abrahams (dave_at_[hidden])
Date: 2003-02-11 09:02:08

Vladimir Prus <ghost_at_[hidden]> writes:

> Dave Abrahams wrote:
>> 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)

Half-baked ones, it seems :(

>> 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...

...in the build request.

>> * 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?

variant=debug, threading=multi

> Combination of the above to properties? What if there's "release" on command 
> line? Will "release threading=multi" be used?

I think so. To get a release single-threaded build you'd have to
explicitly say "release threading=single" to override that property.

> 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. 

No, <stdlib>stlport shouldn't appear in the requirements unless it's
an actual requirement, and when it's really a requirement you
shouldn't be able to override it without editing the Jamfile.

> Alas, it's not clear how to specify "debug and release" at
> the same time (or just "*relese *debug"?)

In the build request, you can use this test from build-requests.jam as
a guide:

assert.result
<toolset>gcc/<toolset-version>3.0.1/<stdlib>stlport/<variant>debug/<inlining>off
<toolset>gcc/<toolset-version>3.0.1/<stdlib>stlport/<variant>release/<inlining>off

: build-request.expand-no-defaults gcc-3.0.1/stlport debug release <inlining>off
: $(test-space) ; 

IOW, it's simply "debug release".

I think the same rules can be used for specifying default-build.

> And "+"/"-" are still unclear to me. If there's <define>FOO in parements 
> requirements, it should always be in properties. 

Yes.

> Well, suppose that parent has <define>FOO *<define>BAR and child has
> *<define>GIZ. 

In requirements or default-build? And wht is this '*' supposed to
mean?

> We can make final properties "<define>FOO <define>GIZ", so that
> parent requirements specified without "*" are always honoured. 

You lost me. Too many unanswered questions above.

> I still don't know why "+/-" are usefull, though.

They're not really needed and we could leave them out for simplicity.
They are just a way of saving typing. For example, you might set a
project-wide default-build that contains <define>DISABLE_EXCEPTIONS,
and in a subproject you might also want to add
<define>READ_ONLY_FOOBAR to the default.

> 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?

The logic works as follows:

You requested the default build of everything from the top level. 

1. If lib/lib1 is not set to build only as a dependency (IOW, it
builds as a main target by default), then, because it has no
default build settings of its own and assuming its requirements
don't conflict, you will get a version with the top-level default
properties (debug <define>FOO).

2. The "app" project has a default build of "release". That overrides
the <variant>debug property of the top level project, but not the
<define>FOO property. So app will be built with <variant>release
<define>FOO.

3. Whether or not this causes a "release" version of lib/lib1 to be
built really depends on whether the <variant> feature has the
"propagated" attribute. In our current codebase it is not, so I
guess all the expanded subproperties of "release" that are
"propagated" will be propagated to lib/lib1, and a debug version of
lib/lib1 with all those properties will be built if it's any
different from the target we built in 1.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com