Boost logo

Boost-Build :

From: Alex Besogonov (cyberax_at_[hidden])
Date: 2006-08-13 08:36:55

Rene Rivera wrote:
>> How did you implement it? Using my wxWidgets.jam or by adding BBv2 files
>> to the wxWidgets' sources?
> Neither. I read in and parse the build/bakefiles/file.bkl. And use the
> results to declare my own set of library targets that match the targets
> in monolithic.bkl and multilib.bkl. The interface for declaring a set of
> libraries is something like:
> using wxwidgets : 2.6.3 : C:/Development/wxWidgets-2.6.3 :
> --enable-monolithic --with-msw --disable-protocols ;
> That is, it uses the same options available from the configure script in
> wx (or close to it). And it doesn't change the wx tree in any form, so
> there's no need to go through the configure setup and one can build
> different variants from the same tree.
>> Does your solution support library name
>> mangling?
> Right now it mangles using the Boost convention. But that's just so I
> could get something quick going. Although truth be told, I prefer the
> Boost names over the wx names.
Interesting, I think we can merge our implementations to use native WX
name mangling to be compatible with existing WX infrastructure
(wx-config on POSIX systems and bakefile-generated .vcproj files).

>> That's a good idea. I think Wiki and a project on SourceForge is the
>> right way for this. My favorite Wiki brand is
>> (it's free for OpenSource
>> products).
> Well, we already have a Boost wiki ;-)
It's not very easy to use and is not very feature-reach :)

>> I don't like Boost Vault, it's not easy to use and is known to have bugs.
> Yea, I'm not fond of it either but it's already working which is why I
> labeled this a quick solution. Question since you suggested it... Why
> use an SF project?
For version control system, the other possible way is to use something
like ViM script repository (see for example)

>> Currently I have to do something like this:
>> ==========
>> # Add 'tools' directory to module search path.
>> local x = [ modules.peek : BOOST_BUILD_PATH ] ;
>> modules.poke : BOOST_BUILD_PATH : $(TOP)/build/tools $(x) ;
>> ==========
>> We need something better and more user-friendly.
> I'm not sure I understand what you want. Where is the above
> "build/tools" located? How does it relate to the external library support?
I have a project which uses some project-specific jamscripts (test
harness) in $(PROJECT_TOP)/build/tools directory, but BBv2 has no means
to specify additional search directories for jamfiles. The best solution
I've found is direct modification of BOOST_BUILD_PATH.

If we are going to add a separate project which will likely be located
outside of the Boost source tree on users' machines then we need means
to modify search paths without such hacks.

With respect,
             Alex Besogonov (cyberax_at_[hidden])

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