Boost logo

Boost-Build :

From: John Maddock (boost.regex_at_[hidden])
Date: 2003-08-23 05:45:16

OK, here's my take on what Rene has so far:

First off, well done - you've got a lot further with this than I managed to

1) Header copying doesn't work on windows - the path names contain forward
slashes and that messes up the copy, for example:

FileClone C:\Boost\include\boost-131\boost\compatibility\cpp_c_headers\ctime
The syntax of the command is incorrect.


...failed FileClone

and so on. BTW why copy individual files like this, rather than the whole
directory in one go (I think you would need to use "xcopy /S /Y boost
wherever" for this on windows to make it work though).

2) I'm very much against having an automated install - for a lot of users
(especially on windows) - it would be sufficient to have the built libraries
copied to a central location in the boost tree.

3) I would prefer it if the install/build mechanism was a little more
decentralised - if the user just wants to build the regex lib then they
should be able to cd into libs/regex/build and invoke bjam from there just
as they can now.

Before I got stuck with the way the stage rule works, I was messing about
with something like this:

rule installable-lib ( target : sources + : requirements * : default-build
* )
lib $(target) : $(sources) : $(requirements) : $(default-build) ;
return [ stage $(TOP)/install/lib : <lib>$(target) :
boost-install-stage-tag : debug release ] ;

which doesn't actually work properly, but I think you can see where I'm
going with this, now library authors just change lib to installable-lib and
dll to installable-dll, and everything should "just work". However this
doesn't handle the separate install step - the good news is that testing.jam
has something very similar: the "run" rule builds the .exe if you just
invoke bjam, and then if you do a "bjam test" it does the second step and
runs the tests as well. This is basically how we want install to work - the
installable-lib rule (or whatever it's called) needs to add the installation
stage to the target called "install". Unfortunately, I've never been able
to figure out how testing.jam actually does that - part of the problem is
that I just don't "get" the jam language at all, sorry, I've even read the
manual as well :-)

4) where should the local copy go? Most open source libraries use
project-root/lib, but we already have a "libs" directory which is a little
too similar IMO, so how about boost-root/binaries/lib and
boost-root/binaries/bin, or is that too convoluted?

5) Mangled names - I think these needs careful consideration - the problem I
have with your scheme (and the incompatible one that boost.regex currently
uses for that matter) is that they are too cryptic, I mean what on earth is

So I was thinking - don't use a suffix at all for the most common option -
and use a unique and hopefully understandable suffix for any other cases:

threading - _mt if it's on otherwise nothing (actually I thinking threading
is the more common case these days but I couldn't think of a good suffix for
single threaded).
runtime - _srt for static runtime otherwise nothing
_dbg - for debug, otherwise nothing
.. and so on, which would give us:


which looks almost comprehensible, well slightly better anyway... on the
other hand I worry that this might cause the names to get too long:


is just about possible (multithreaded, debug, static runtime, python debug
lib, STLPort debug lib).

Whatever the scheme is settled on I think we probably need a mini-review or
something, and can we settle on one scheme and stick with it - changing the
regex makefiles and auto-link headers involves a small amount of pain
everytime there is a change :-(

Whew, I think that's a about it, probably something I've forgotten but
there we go...

BTW, I'm having problems with my new ISP at present, so if you don't here
from me for a bit you know why...

Thanks for persevering with this,



Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at