Re: [jamboost] V2: build issues

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

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

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.

- Volodya