From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-06-09 09:10:41
> VP> I think the idea is that "using msvc" and the like occurs in
> VP> user-config.jam and site-config.jam -- and that those files don't
> VP> declare toolsets which are not installed.
> I know that, but as for me it is bad solution, or maybe i have missed
> somithing :). We use boost.Build as main build system. Some of projects
> require only subset of libraries and compilers that should be in
> user-config.jam. So when someone will do cvs up and try to build project,
> it will not builds, coz of lack of libraries and compilers specified in
> user-config.jam for all projects. How can I do such things? I should be
> able to use one build system to build dozen projects, that may have
> unrelated sets of required compilers and libs. Can I localy configure a
> project to use limited subset of libs and compilers? And others projects
> should be able to use this one without any restrictions. Can I do it ?
I'm afraid I still don't understand the problem completely. If all development
boxes have *local* copies of user-config.jam, then only compilers and
libraries available on that box will be declared there. Projects which rely
on some other libraries won't built, but all the other will built just OK.
Or the situation is that you include 'user-config.jam' (and boost.build) in
your projects tree? So, if 'user-config.jam' lists all compilers, then
somebody, after doing checkout runs "bjam" and gets errors about msvc not
> VP> However, there's a more general problem. People might write
> VP> lib a : a_gcc.cpp : <toolset>gcc ;
> VP> lib a : a_msvc.cpp : <toolset>msvc ;
> ^^^^^^^^^^^^^^^^^^^ That what i have
Oh, so this example is real ;-)
> VP> and such a thing requires to initialize both "gcc" and "msvc"
> VP> toolsets --- on all platforms, because otherwise, <toolset>msvc
> VP> won't be recognized as valid property.
> VP> No solution is devised yet. One might be to disable the error
> VP> message. Other is to allow to disable checks explicitly, when
> VP> configuring msvc. Yet another is to allow the user to say
> VP> "<toolset>msvc is valid property", without initialazing msvc.
> VP> I prefer the last approach -- since it's the simplest and will work
> VP> regardless of user-config content.
> I don't know how to say "<toolset>msvc is valid property" :( but I will
> find :)
In fact, I don't know, either. The 'feature.feature' rule won't allow to
declare the same feature twice and we need a something to support my idea ;-)
> Why does bjam so slow doing header and dependency scaning? I am waiting
> about 20 seconds while bjam do it on my projects. (Celeron 733).
If you run bjam with "-d+10" option and send me the output, I'll be able to
say for sure. (Note that "-d+10" must be specified immediately after "bjam").
For now I can only say that Boost.Build is almost unoptimized, and the
situation will improve. In particular, Dave and Ali are doing some redesigns
which can simplify, and consequently speed up some things. I also hope
to improve header scanning pretty soon.
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