Re: Common Lib Subdir

From: David Abrahams (gclbb-jamboost_at_[hidden])
Date: 2003-08-24 20:17:26

"John Maddock" <boost.regex_at_[hidden]> writes:

> 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

Why?

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

I won't repeat Rene's counterarguments; instead I'll just say "what
he said" ;-)

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

What about invoking with --install=regex from the top? My sense is
that users don't neccessarily want/need to know about the structure of
the libs subdirectory.

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

This is simple. "test" is a NOTFILE target which depends on all the
test results. "test" doesn't build by default because the special
"all" target is not dependent on it.

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

Well if we don't have some mangling we may as well put the results at
the ends of their current build paths :o(

> 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

Boost.Build uses a similar rule for generating subvariant directories.

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

Yep. I think the answer for mangling is: just give up on readability
and pick a single letter for each property.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com