Boost logo

Boost Interest :

Subject: Re: [Boost-cmake] [PATCH] Use LIB_SUFFIX, allows installing 64bit libs into /usr/lib64.
From: Sean Chittenden (sean_at_[hidden])
Date: 2009-10-26 17:38:45


Take:
http://www.gnu.org/software/hello/manual/autoconf/Makefile-Substitutions.html#Makefile-Substitutions

Your:
http://www.gnu.org/software/hello/manual/autoconf/Installation-Directory-Variables.html#Installation-Directory-Variables

Pick:
http://www.gnu.org/software/hello/manual/autoconf/Preset-Output-Variables.html

There are many. :) -sc

On Oct 26, 2009, at 2:35 PM, troy d. straszheim wrote:

> 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.
>
> Agreed.
>
>> 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.
>
> 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.
>
> -t
>
> _______________________________________________
> Boost-cmake mailing list
> Boost-cmake_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
>

--
Sean Chittenden
sean_at_[hidden]

Boost-cmake list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk