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:
http://denisarnaud.fedorapeople.org/boost/1.40.0/10/) 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
(https://fedoraproject.org/wiki/Packaging:Cmake#RPM_Macros), though some
suggest (https://fedoraproject.org/wiki/PackagingDrafts/cmake) 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 (http://lists.boost.org/boost-cmake/2009/10/0670.php).
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:if(LIB_SUFFIX)
BoostConfig.cmake: boost_report_pretty("Lib suffix" LIB_SUFFIX)
Have you got the right code?
% git log -n1
commit e26008ef3a9f94d3854e073865fe4ce3a9481ef4
Author: troy d. straszheim <t...@resophonic.com>
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
(http://denisarnaud.fedorapeople.org/boost/1.40.0/10/boost.spec) 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
-DCMAKE_INSTALL_PREFIX=$RPM_BUILD_ROOT%{_prefix} \
$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: https://fedoraproject.org/wiki/Packaging:Cmake#Specfile_Usage ?)
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.
-t
_______________________________________________
Boost-cmake mailing list
Boost-cmake@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
