Boost Interest :
Subject: Re: [Boost-cmake] [PATCH] Use LIB_SUFFIX, allows installing 64bit libs into /usr/lib64.
From: Ingmar Vanhassel (ingmar_at_[hidden])
Date: 2009-10-26 17:53:27
Excerpts from troy d. straszheim's message of Mon Oct 26 22:35:13 +0100 2009:
> Ingmar Vanhassel wrote:
> > Excerpts from troy d. straszheim's message of Mon Oct 26 21:37:58 +0100 2009:
> >> Ingmar Vanhassel wrote:
> >>> ---
> >>> tools/build/CMake/BoostCore.cmake | 2 +-
> >>> 1 files changed, 1 insertions(+), 1 deletions(-)
> >>> Try the following patch.
> >>> Use 'cmake -DLIB_SUFFIX=64 .' if you want libraries to be installed to /usr/lib64.
> >> Thanks for this.
> >> 1.41.0 is patched to support changing that lib install location via
> >> 'BOOST_INSTALL_LIB_SUBDIR_NAME'.
> >> -t
> > Can't this use the standard LIB_SUFFIX?
> > This is what I really hate about CMake, autotools is somewhat
> > standardized, with CMake everyone does their own thing.
> > For packagers, standardization is far more interesting since we have
> > build-scripts & macros that have some sensible defaults...
> > For users it sucks to have to look through all the CMake options to find
> > what you named it, rather than looking whether the de-factor standard
> > for this is available.
> I had no idea LIB_SUFFIX was standard. Can you point me to some
> examples? Of course we'll prefer the most standard thing when it
> exists. For that matter, it would be great if cmake supported
> configure-style '--prefix' and friends.
Anything KDE-4 based supports this. kdelibs installs a set of macros
that just about any KDE4 package uses, and thus automatically supports.
> Do let me know if there are more annoyances like this. Packagers are
> very important (at least to me), and I recognize that boost has a lot of
> catching up to do to be packager-friendly. That's a large part of the
> reason this boost-cmake effort exists.
I just want to say that boost-cmake is a humonguous step forward from
boost-build, and in Exherbo we've started using it as soon as we got it
I'll have a look sometime this week if there's anything we could improve
on in this department.
-- Exherbo KDE, X.org maintainer