Re: [jamboost] Re: Common Lib Subdir

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

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.

copy
c:\data\boost\develop\boost/boost/compatibility/cpp_c_headers\ctime
C:\Boost\include\boost-131\boost\compatibility\cpp_c_headers\ctime

...failed FileClone
C:\Boost\include\boost-131\boost\compatibility\cpp_c_headers\ctime...

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
boost_regex-vc71-gd-131.dll?

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:

boost_regex_vc71_mt_dbg_131.dll

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

libboost_regex_vc71_mt_dbg_srt_pydbg_stldbg_131.dll

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,

John.