Re: [boost] Re: RFP: boost libraries

From: Steve M. Robbins (steven.robbins_at_[hidden])
Date: 2002-05-02 17:36:53

On Thu, May 02, 2002 at 09:11:05AM -0500, David Abrahams wrote:

> * Nobody has decided what an appropriate unix-style installation for
> boost would look like (where the headers live, how the libs should be
> named and versioned, what symlinks to make, etc.). We need guidance on
> this.

Well, I'm willing to give you my two cents worth.  ;-)

As you mentioned, boost is simply a collection of libraries.  There is
nothing new here: simply install them as you would for any other C++
library under unix.

* install locations

Specifically, the install mechanism should have three configurable
locations:

    includedir   -- install the header files here
    libdir       -- install the libraries here
    htmldir      -- install HTML documentation here

The first two are very standard; the last is less so.  One could argue
for "docdir" instead; I think there is some advantage to being more
specific -- e.g. boost may introduce other forms of documentation later.

In addition, it is very convenient if those three variables are given
default values based on another variable, traditionally named "prefix"
as follows:

    includedir = $prefix/include
    libdir = $prefix/lib
    htmldir = $prefix/share/doc

and the default for prefix should be "/usr/local".  This scheme
supports the common installation scenarios:

    1. specify nothing -- stuff ends up in /usr/local/include and
    /usr/local/lib which are commonly on the compiler search path

    2. install using, e.g. prefix=/opt/boost-1.27 to put everything
    together into its own hierarchy

    3. go wild and customize all three directories individually!

At install time, $includedir/boost would become a copy of 
boost-1.27.0/boost, the libboost* files would end up in $libdir,
and the HTML hierarchy rooted at boost-1.27.0/index.htm would
be copied to $htmldir/boost.  

[Incidentally, I recently discovered a wonderful tool to copy HTML
directories, available from www.httrack.com.  Not only does it make
a mirror copy of the files, but it tidies up the HTML -- changing
backslashes to forward slashes, for example.]

* library names

The library names in use -- libboost_thread, libboost_regex,
libboost_python, and libbgl-viz are reasonable enough.

* library versioning

My understanding is that boost is still moving too fast to maintain an
ABI across versions.  If that is true, my suggestion is to simply
version them using boost's version number (e.g. 1.27).

* symlinks etc

Here things get muddy.  The only way I know how to build shared libs
in a reasonably portable way is to use libtool.  I suspect someone
with enough motivation could teach jam how to use libtool.  

I don't have the requisite motivation, so I just fiddled with jam so
that it builds shared libs with the correct SONAME for linux.  This
hack isn't complete, as the filename is not correct, but I just rename
it afterwards.

With the following patch, I invoke

    jam .... -sSOVERSION=1.27

and end up with libboost_regex.so, which I then rename to
libboost_regex.so.1.27.  In the libdir, one ought to have 
the following files

        libboost_regex.a 
        libboost_regex.so.1.27
        libboost_regex.so (a symlink to libboost_regex.so.1.27)

At least, this is the linux style.  Other systems have other
requirements.

I realise this is incomplete and I apologize for that.
I hope it is of some utility.

-Steve

Index: tools/build/gcc-tools.jam
===================================================================
RCS file: /home/steve/lib/cvs/debian/boost/tools/build/gcc-tools.jam,v
retrieving revision 1.1.1.2
retrieving revision 1.2
diff -u -b -B -r1.1.1.2 -r1.2
--- tools/build/gcc-tools.jam	7 Feb 2002 15:34:18 -0000	1.1.1.2
+++ tools/build/gcc-tools.jam	3 Mar 2002 22:10:06 -0000	1.2
@@ -97,7 +97,7 @@
 # for gcc, we repeat all libraries so that dependencies are always resolved
 actions gcc-Link-action bind NEEDLIBS
 {
-    $(GCC_BIN_DIRECTORY)g++ $(IMPLIB_COMMAND)$(<[2]) $(LINKFLAGS) -o "$(<[1])" -L$(LIBPATH:T) -L$(STDLIBPATH:T) "$(>)" "$(NEEDLIBS)" "$(NEEDLIBS)" -l$(FINDLIBS) -Wl,-rpath-link,.
+    $(GCC_BIN_DIRECTORY)g++ $(IMPLIB_COMMAND)$(<[2]) $(LINKFLAGS) -o "$(<[1])" -L$(LIBPATH:T) -L$(STDLIBPATH:T) "$(>)" "$(NEEDLIBS)" "$(NEEDLIBS)" -l$(FINDLIBS) -Wl,-rpath-link,. -Wl,-soname,$(<[1]:D=).$(SOVERSION)
 }
 
 actions gcc-dllwrap bind NEEDLIBS

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants