Re: [jamboost] V2: build issues

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-02-05 03:13:28

Jürgen Hunold wrote:
> Am Montag 03 Februar 2003 16:29 schrieb Vladimir Prus:
> 
> 
>>1. Send the Jamfiles to me, or
> 
> 
> I've attached a simple sample project.

Thanks for another reproducible test case!

> Please unpack and run bjam --v2
> This will build an application in path
> bin/gcc/release/stdlib-stlport/threading-multi/main-target-test_a
> 
> which is what I want for my projects. 

Fine.

> Then try to run bjam --v2 debug or bjam --v2 link=static.
> In my opinion, this should build
> bin/gcc/debug/stdlib-stlport/threading-multi/main-target-test_a
> or 
> bin/gcc/release/link-static/stdlib-stlport/threading-multi/main-target-test_a
> or wherever the "link-static" should be put.
> 
> I fear I missed something while constructing the toplevel-Jamfile.

To start with, the warning message is pretty cryptic. I've improved that, and 
now it reads:

warning: skipping build of project /src at . due to unsatisfied requirements.
warning: explanation: link-incompatible properties <threading>single and
<threading>multi
warning: build-request: <variant>debug <optimization>off <debug-symbols>on
<os>LINUX <toolset>gcc <stdlib>native <link>shared <link-runtime>shared
<threading>single <rtti>on <hardcode-dll-paths>false
warning: requirements: <include>/home/hunold/packages/boost <threading>multi
<uses>qt <hardcode-dll-paths>true <stdlib>stlport

The explanation is simple. Build request says nothing about <threading>, so
the default value of <threading> --- single, is used. Project requirements
contain <threading>multi. The system considers those two properties link
incompatible, and plain refuse to build the project.

You can work it around by saying "threading=multi" on the command line,
but this should not be required. What is really needed is ability to
change the default value of feature for a specific project. So that
<threading>multi is added to build request unless other explicitly specified.

I see a couple of ways:
1. Just provide a rule which changes default value. That's simple, but what
if default is changed by two project-root.jam files to different values?
2. Add 'default-properties' project attribute. It your case, it will include
<threading>multi
3. Change default-build semantic (I did propose that already!). It will be:

before bulding, we look at build request from command line, and default-build
attribute of the *current* project. If a value of feature is given on the 
command line, we take that. If it's given in "default-build", we take that.
Lastly, if it's not given, we take the default.

How the above options look?

- Volodya

P.S. Jurgen, you could chage the order of values for threading feature (in 
builtin.jam) to workaround the problem, but I guess you'd better have 
reasonable speed, right?