Re: [Boost-build] External library support

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 
>> http://www.atlassian.com/software/confluence/ (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 
http://www.vim.org/scripts/script.php?script_id=273 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])