Re: [boost] Boost RPM spec file: Take 2

From: Neal Becker (ndbecker2_at_[hidden])
Date: 2006-08-09 17:28:36

Patrick Hartling wrote:

> Several weeks ago, I posted an RPM spec file for Boost that I was hoping
> to see used as the "upstream" spec file for Boost installations on
> RPM-based Linux distributions. If nothing else, having it serve as a model
> to Linux distributors would be great, too. I have attached an updated
> version of that spec file that I feel is an improvement to the earlier
> version.
> 
> The philosophy behind this new spec file is to be as true as possible to
> what I understand to be a "normal" Boost installation. I realize that
> users are afforded many ways to customize their Boost installation through
> different build-time options. Without doing any build customization,
> however, a Boost installation has single- and multi-threaded variants of
> libraries, both static and dynamic, that are named based on the toolset
> used for building and the Boost version number. Furthermore, the headers
> are installed in a versioned subdirectory. All of this allows parallel
> installations of different Boost build variants, and I see that as an
> extremely powerful capability. The attached RPM spec file leverages that
> in a way that I see as being very valuable.
> 
> Relative to the Boost RPM distributed for use on Red Hat distributions of
> Linux (I do not have experience with pre-packaged versions of Boost from
> other Linux distribution vendors, so I cannot comment on how they do
> things), this RPM spec file has the following benefits:
> 
>    * Allows parallel installations of multiple Boost releases (both the
>      run-time RPM and the developer RPM)
>    * Installs single- and multi-threaded builds of libraries
> 
> The spec file that Red Hat uses for building Boost RPMs removes the
> toolset name and the version information from the base name of the
> library, and it only installs the single-threaded build of each library.
> For reasons that are not yet clear to me, an additional symlink is created
> for each Boost shared library named libboost_<libname>.so.2 that points to
> libboost_<libname>.so.1.33.1. This prevents multiple parallel run-time
> installations. Multiple developer installations are prevented by the
> removal of the version information from the base library name and by the
> fact that the headers are placed in /usr/include/boost instead of in
> /usr/include/boost-1_33_1/boost.
> 
> Since there are likely to be many users who are expecting Boost to be
> installed using the Red Hat RPM, I have added some compatibility bits in
> the form of two extra RPMs called boost-symlinks and boost-devel-symlinks.
> The first installs symlinks for the Boost libraries named using Red Hat's
> stripped down convention (with the version number after the .so part of
> the name). The second RPM installs unversioned symbolic links to the fully
> qualified library names and to the Boost header directory. The idea here
> is that users could have multiple Boost developer installations in
> parallel, and if they so desired, they could install this extra RPM with
> unversioned names to point to whichever Boost installation should be the
> "default" version. Since the symlinks are unversioned, parallel
> installations of multiple versions of these RPMs is not possible.
> Nevertheless, the two together provide a means to make a Boost RPM
> installation that is compatible with what Red Hat has been distributing
> for quite a while now.
> 
> Comments?
> 
>  -Patrick
> 
> 
I have taken some similar approach.  I put includes in a parallel dir, but I
also put libs in a parallel dir.  This prevents any conflicts.  If you do
this, you don't need a seperate symlink package, right?

Since Redhat will produce %{_libdir}/libboost_regex.so.1.33.1
and so might you, don't you have to use a different libdir?  Another issue,
right now, Redhat is using libboost_regex.so.2.  If you run ldconfig, won't
it change your symlink to point to the highest version number, which might
not be what you want?

I don't know why there is arch_args.  When building on x86_64 you don't need
to use -m64 - that's the default.  Is this so you can build the i386 rpm on
an x86_64 host?  Not that it hurts anything.