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