Boost logo

Boost-Build :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-07-21 02:04:13 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.


> 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


Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at