[cmake-developers] [PATCH] Allow LIB_SUFFIX be used as find path

[Christian Schmidbauer]

Hallo,

I provided a v2 of my previous patch to the ML a few hours back (see
[1]), you can give it a try. I was successfully able to build llvm on
Gentoo, by adding the following lines to
/usr/portage/eclass/cmake-utils.eclass

--- aaa/cmake-utils.eclass      2017-02-07 06:44:59.000000000 +0100
+++ bbb/cmake-utils.eclass      2017-02-26 16:37:53.176993623 +0100
@@ -607,6 +607,7 @@
        cat > "${common_config}" <<- _EOF_ || die
                SET (CMAKE_GENTOO_BUILD ON CACHE BOOL "Indicate Gentoo
package build")
                SET (LIB_SUFFIX ${libdir/lib} CACHE STRING "library
path suffix" FORCE)
+               SET (CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX
"${libdir/lib}" CACHE STRING "")
                SET (CMAKE_INSTALL_LIBDIR ${libdir} CACHE PATH "Output
directory for libraries")
        _EOF_
        [[ "${NOCOLOR}" = true || "${NOCOLOR}" = yes ]] && echo 'SET
(CMAKE_COLOR_MAKEFILE OFF CACHE BOOL "pretty colors during make"
FORCE)' >> "${common_config}"


Best regards,
Chris

[1] https://cmake.org/pipermail/cmake-developers/2017-February/029867.html

On Sun, Feb 26, 2017 at 2:52 PM, Steven Newbury <steve at snewbury.org.uk> wrote:
> On Fri, 2016-06-17 at 18:53 +0200, Christian Schmidbauer wrote:
>> On Mon, Jun 13, 2016 at 5:22 PM, Brad King <brad.king at kitware.com>
>> wrote:
>> > Hi Christian,
>> >
>> > Thanks for working on this.
>> >
>> > On 06/12/2016 05:59 AM, Christian Schmidbauer wrote:
>> > > A similar idea has already been suggested in #10287
>> >
>> > Yes.
>> >
>> > > and is required for bug #15594.
>> >
>> > That issue appears unrelated.  Did you typo the number?
>> >
>>
>> Indeed, I meant bug #15994.
>>
>> > >  Help/command/find_library.rst                      |  5 ++++
>> > >  Help/manual/cmake-properties.7.rst
>> >
>> > Please also add the FIND_LIBRARY_USE_CUSTOM_SUFFIX item
>> > documentation,
>> > or whatever it becomes after the discussion below.
>> >
>>
>> Where do you want me to document it?
>>
>> > > +If the :prop_gbl:`FIND_LIBRARY_USE_CUSTOM_SUFFIX` global
>> > > property is set
>> > > +all search paths will be tested as normal, with `LIB_SUFFIX`
>> > > appended, and
>> > > +with all matches of ``lib/`` replaced with
>> > > `lib${LIB_SUFFIX}/`.  This property
>> > > +overrides both `FIND_LIBRARY_USE_LIB32_PATHS` and
>> > > `FIND_LIBRARY_USE_LIB64_PATHS`.
>> >
>> > [snip]
>> > > +set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_CUSTOM_SUFFIX
>> > > TRUE)
>> > > +set(LIB_SUFFIX "XYZ")
>> >
>> > Typically the FIND_LIBRARY_USE_LIB{32,64}_PATHS global properties
>> > can be set by the platform information modules in CMake itself
>> > on platforms that need the behavior.  In what context might the
>> > FIND_LIBRARY_USE_CUSTOM_SUFFIX/LIB_SUFFIX values be set in
>> > practice?
>> >
>> > Thanks,
>> > -Brad
>> >
>>
>> In custom environments, where neither lib, lib32 or lib64 would serve
>> the purpose but some custom library folder. I have a multilib system
>> with an additional "libx32" next to lib/lib32 and lib64. Currently,
>> you have to trick cmake in order to for libraries to be found. You
>> could go ahead and add a similar patch like the lib32 one, but I
>> think
>> it's a better approach to let the user decide in such scenarios where
>> he wants cmake to look.
> Chris,
> I'm not really convinced x32 is a "custom" environment, nor should it
> be treated as such.  It's a supported platform with Gentoo, which I've
> personally been working towards getting everything working with for
> years now.
>
> I've been trying to fix bug #15994 (again) today, currently failing to
> build multilib llvm with patched cmake.  If you have a working patch
> for x32 can we think about getting #15994 fixed first?