Re: [jamboost] V2: build issues

From: Jürgen Hunold (hunold+lists.Boost_at_[hidden])
Date: 2003-02-05 04:16:26

Hi ! 

On Wednesday 05 February 2003 09:13, Vladimir Prus wrote:
> Jürgen Hunold wrote:
> > Am Montag 03 Februar 2003 16:29 schrieb Vladimir Prus:

> Thanks for another reproducible test case!

You're welcome.

> > Please unpack and run bjam --v2

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

Thanks. That's much more (end-)user friendly.

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

Ah, I understand. I did some probing yesterday evening and found that 
invoking 
bjam --v2 debug threading=multi stdlib=stlport
built what I want. 
I can live with this for the time being, because I only use V2 for 
evaluation now. And right now bjam is simply not ready for a production 
environment. But it is very easy to us. 

> 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

Where do I have to put them ?
I would like to default to multi-threading and STLport.

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

The third options looks very good.
The problem I see here is that the build paths become _very_ long, 
because they always contain

"stdlib-stlport/threading-multi/"

even if I simply _never_ will use the native stlport (at least for gcc, 
msvc and intel on win32 and cannot build a single threaded version of 
my applications...
So I would like composite appproach including 1. and 3. option.

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

Well, yes ;--)) I would like to help in improving bjam, but now the 
turnaround time is about 75 Minutes even if I build only one app.
And it eats one of my cpu and lots of memory (I know the memory is 
needed, no worries about that) for this time and blocks my machine.
And as stated above, I now know how build the desired build-variants.

Yours,

Jürgen
-- 
* Dipl.-Math. Jürgen Hunold ! Institut für Verkehrswesen, Eisenbahnbau
* voice: ++49 511 762-2529 ! und -betrieb, Universität Hannover  
* fax : ++49 511 762-3001 ! Appelstrasse 9a, D-30167 Hannover
* hunold_at_[hidden] ! www.ive.uni-hannover.de