Re: [jamboost] Re: [BBv2] Some questions

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-07-21 02:04:13

pal.tw wrote:

> First, I must apologize for my carelessness. In Message 4187,
> I answer Mr. David Abrahams's question that the SDK doesn't
> ship with its own setup script. But later I found it --
> "SetEnv.bat" just in the install directory of SDK.
> Therefore I can invoke "SetEnv.bat" after "vcvars32.bat"

Oh... that means it's possible to just add another parameter to "msvc.init", 
which tells SDK location. If you'd be willing to test this stuff, I can add 
the necessary logic (I have msvc here, but don't really use it, so have no 
idea how can I check if SDK works).

> > Is it possible to specify SDK include/lib path via command line
>
> switches to
>
> > the compiler. I guess they take precedence over environment?
>
> Yes, but another problem. It seems no way to set default values in
> "site-config.jam" or "user-config.jam". I must add them in every
> project.

True. I recall "global requirements" were already asked for, but it might take 
a long time for it to be implemented.

> And it seems not be a convenient way...

I agree that specifying only SDK path is easier.

> > Why is it necessary to adjuast PATH?
>
> Because Microsoft provides some useful tools, such as
> MC.exe (message compiler), RC.exe (resource compiler),
> SignCode.exe ...etc. They can also be used in the build process
> and should be later than the ones shipped with the msvc.

Ok. 

> I have read "Boost Build Development Plan". Now the development
> of [BBv2] should be in Milestone 6. It means that you start to
> optimize [BBv2], don't you?

According to plan, yes. The problem is that I've being pretty busy those two 
weeks, so did not have the time to start optimizing. M6 will be bugfix 
release. And I hope to start optimizations for M7.

> I have some idea. Maybe it is impracticable.
> Is it possible to transfer some implementation of [BBv2] Design,
> like "class" and "instance" concepts, to "Bjam" tool and
> make them being built-in rules. I suppose that will not only
> speed up the build process, but also keep [BBv2] more clean.

I've being thinking about such things recently, and I believe we were not 
sufficiently aggressive in extending Boost.Build core. I think there's no 
real compatibiliy issues, and some part are not meant for user to 
extend/modify. Moving them to C would certainly improve performance.

In fact, I did some profiling on my project already, and it indicates that 
about 30 rules accounts for most of Boost.Build run time. I would not mind 
rewritting all those 30 rules in C.

- Volodya