From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-02-05 05:49:42
Jürgen Hunold wrote:
>>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
>>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
> 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 hope to achieve tolerable speed within a week. After that, the issue we're
discussing can be addressed in real code.
>>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
>>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.
You'd put them along "requirement" and "default-build" section in top
level Jamfile. I'm not fond of this idea, because "default-properties"
together with "default-build" is as confusing as it can get.
>>3. Change default-build semantic (I did propose that already!). It
>>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
>>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
> 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.
I agree with you -- those extra path element should be removed. Have to think
a little about this.
>>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.
I see. I'll post a message when anything improves.
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