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