Re: [Boost-build] External library support

From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2006-08-12 23:05:28

Alex Besogonov wrote:
> Rene Rivera wrote:
>> Note... I'm close to having the wxWidgets support that builds wx done. 
>> Work obligations means I have have to get it done by Monday :-) That said...
> 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.

>> OK, since I don't usually put down suggestions without providing 
>> alternatives, here's the alternative. We create a repository of non-core 
>> BB support. This might be similar CPAN, for example.

> 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 ;-)

> 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?

> Good ideas. But we need one more thing from BBv2 to make it work - the 
> ability to use custom package search paths.
> 
> 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?

-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo