Boost logo

Boost Interest :

Subject: Re: [Boost-cmake] 1.40.0.cmake5 (?) builds cleanly
From: troy d. straszheim (troy_at_[hidden])
Date: 2009-11-03 09:00:59

Denis Arnaud wrote:
> I forgot to mention that I still have to apply two patches (provided in
> attachment, but also available on my Fedora page:
> to alter the
> configuration of CMake.
> a) One is to uncomment the SOVERSION line (which, from my understanding,
> is reported to fail on some platforms such as Mac), so that sonames can
> be generated in the right way.
> b) The other patch is to avoid building binaries (e.g., bcp, inspect).
> As I have included all the possible combinations (BUILD_TESTS=NONE,
> BUILD_BCP=OFF, etc), it should work for many versions of Boost-CMak

the individual BUILD_* options for tools are long gone.
BUILD_TOOLS=NONE should do it:

% cmake ..
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU


-- Skipping config of tools since BUILD_TOOLS is "NONE"
-- Configuring done
-- Generating done
> Now, may I suggest a few enhancements, from a Fedora packaging perspective?
Yes, this is all good stuff.  Keep it coming.
> 1. To enable the installation of the Boost libraries into the /usr/lib64 
> directory on 64bit Linux platforms, I currently use the 
> "-DBOOST_INSTALL_LIB_SUBDIR_NAME=lib64" directive.
> On Fedora, the RPM cmake-macro uses the "-DLIB_SUFFIX=64" directive 
> (, though some 
> suggest ( to 
> replace it by the "-DLIB_INSTALL_DIR:PATH=%{_libdir}" directive (where 
> %{_libdir} is equal to either /usr/lib or /usr/lib64, depending on the 
> platform).
> So, I'd suggest that Boost-CMake supports one of those, as apparently 
> KDE4 does (
Ingmar Vanhassel pointed this out, it is on the 1.40 branch:
% git branch -l
* 1.40.0
% grep BOOST_INSTALL_LIB **/*.cmake
% grep LIB_SUFFIX **/*.cmake
BoostConfig.cmake:set(LIB_SUFFIX "" CACHE STRING "Name of suffix on 
'lib' directory to which libs will be installed (e.g. add '64' here on 
certain 64 bit unices)")
BoostConfig.cmake:  boost_report_pretty("Lib suffix" LIB_SUFFIX)
Have you got the right code?
% git log -n1
commit e26008ef3a9f94d3854e073865fe4ce3a9481ef4
Author: troy d. straszheim <troy_at_[hidden]>
Date:   Sat Oct 31 21:37:53 2009 -0400
     Don't build tools by default.  All they do is break.
> 2. To instruct CMake about the installation directory, I currently use 
> ( the 
> "-DCMAKE_INSTALL_PREFIX=$RPM_BUILD_ROOT%{_prefix}" directive (where 
> %{_prefix} is equal to /usr). However, it has rpmlint (the RPM packaging 
> checker utility) to complain/warn about it:
> $ rpmlint -i SPECS/boost.spec
> SPECS/boost.spec:257: W: rpm-buildroot-usage %build %cmake 
> $RPM_BUILD_ROOT should not be touched during %build or %prep stage, as 
> it may
> break short circuit builds."
Ah, I think it may be creating subdirectories of build/ during the 
configure stage.  Would this set off that alarm?
> Also, the "standard Fedora way" (used by 
> KDE4: ?) 
> is to instruct make (not cmake), like for VERBOSE=1, where to install 
> everything, with "make install DESTDIR=$RPM_BUILD_ROOT".
 > So, if possible, I'd suggest that the installation directory may be
 > instructed at the installation stage, understood by make (and not only
 > by cmake).
Ah yes, DESTDIR.  Have you tried it?  IIRC you get DESTDIR 'for free' 
with cmake, but we might be doing something to confuse it.

Boost-cmake list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at