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