[Boost-build] External library support (was: wxWidgets support files)

From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2006-08-12 15:20:25

Alex Besogonov wrote:
> Bojan Resnik wrote:
>>>>   However, if I try to put the version explicitly, like
>>>>            using wxWidgets : E:/wx : 2.6 ;
>>>>   it doesn't work anymore (complains about not being able to find wxbaseud.lib).
>>> Fixed. Please, try the attached patches.
>>   Sorry for the delay, I was on vacation. These patches have fixed the
>> problems I was having. Can wxWidgets support become a standard part of
>> Boost.Build?
> Yes, I hope so.
> 
> 2Vladimir Prus: what do I need to do in order to include wxWidgets.jam 
> to the official Boost distribution?

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

I don't think it's a good idea to have such library support as standard 
to Boost.Build. First, it prevents as rapid updates to such support as 
is required to keep up with the rapid pace libraries change. Second, it 
closes off maintenance to a few people who are currently rather busy, 
and likely will be for an indefinite future. Third, it just makes the BB 
distribution that much larger and likely will detract users. Fourth, it 
prevents users from adding support piecemeal.

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. The quickest, least 
effort first cut would be adding such packages to the Boost Valt 
<http://boost-consulting.com/vault/> in an appropriate directory, and 
adding detailed descriptions in the wiki if needed. Of course 
suggestions, i.e. solutions, on this are appreciated.

This does require some requirements, for consistency, on those packages. 
I'm trying to think of, and to follow, some of those requirements as I 
implement the wxWidgets compile support. The ones I have so far:

* All targets for such packages should be declared in an "/ext" root 
project.

* Each package should have one subproject below the "/ext" root. For 
example wxWidgets would declare targets in "/ext/wxwidgets".

* Features needed by the package should be prefixed with a unique 
identifier to avoid collisions. The ID need not be the same as the 
subproject. For example the wxWidgets support might use the shorter 
"wx-" prefix for all it's features.

* Packages must provide a "using..." interface for setup for consistency 
with current practices.

* There should only be one jam file at the top level named to match the 
subproject name.

* Any additional support files should be in a subdirectory also matching 
the subproject name.

* There will be an additional subdirectory in the BB distribution "ext" 
(or possibly extras) that will be part of the BOOST_BUILD_PATH. User can 
then just drop in packages to this dir and start using them without 
messing with the boost-build.jam or env variables. Of course they would 
be free to do the latter also.

Thoughts?

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