From: Vladimir Prus (ghost_at_[hidden])
Date: 2007-07-20 03:21:29
Roland Schwarz wrote:
> Hi Michael,
> Michael Caisse wrote:
>> alias latest
>> : <include>../$(LATEST_RELEASE)
> I am pretty sure this will work for msvc compilers because they support
> automatic linking. I.e. including the headers will embed a hint for the
> linker which will tell it the decorated name of the library.
> I am afraid this is not so on linux.
Yeah, that won't work on Linux. As for linking to pre-installed
boost libraries, using right names, I've sketched the attached.
It's dirty, because it's copy-paste for Boost's top-level Jamfile.v2,
but kinda works.
I think it would be good to have it implemented in a nice way,
but I don't think the right way is adding boost.jam to *Boost.Build*.
The problem is that Boost.Build used by the user is not necessary
the Boost.Build used when building Boost itself. So, it's possible
that the installed Boost has different naming scheme.
I think the ideal approach is to make the install process
create to $prefix/share/boost/Jamroot
Then, any Boost.Build project wishing to link to boost can
use-project /boost : $prefix/share/boost/Jamroot ;
and then have:
exe a : a.cpp /boost//boost_whatever ;
I think it's not very hard to do, actually. We need to extract this
tag rule into boost.jam, located in top-level Boost dir, so that
both Jamfile.v2 and this new installed Jamroot can use it.
Then, we can pre-create Jamroot that will be installed. Then,
we have to modify the install process to install boost.jam and
Jamroot to $prefix/share. I'd imagine this Jamroot need not
be generated -- it can be just hand-written, using the attached
one as reference, and importing boost.jam instead of copy-pasting
the 'tag' rule. Of course, if only I have the time to implement
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