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
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.
>> 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:
>> likewise, she can write
>> to remove a feature which may have been specified in a parent's
> 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?
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
: 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.
> Well, suppose that parent has <define>FOO *<define>BAR and child has
In requirements or default-build? And wht is this '*' supposed to
> 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
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
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk