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

[Steven Newbury]

On Sun, 2017-02-26 at 19:04 +0100, Christian Schmidbauer wrote:
> I don't think our patches will be mutually exclusive.
Agreed.

>  If I understand
> you correctly, you are trying to make x32 auto-detectable, hence make
> it work "out of the box". I like the idea and I also tried x32
> auto-detection in the past, but it seemed to me that the
> infrastructure does not support it very well. I also don't think that
> enough people use x32 to justify putting many working hours into it.
> 
I seem to have it working.  I need to expand the tests to cover it
before I send a patch.  I've been hopeful for a long time more people
will try x32 if the key infrastructure and applications are in place. 
Clearly you recognise some of the benefits!

> My approach of this patch on the other hand is much more general in
> nature: I am trying to support any lib, as defined in [1]. This
> allows cmake to be used in environments which have more specific
> requirements. Hence it overwrites the default heuristic, which is
> usually wrong in such environments. The x32 ABI is just one scenario
> where you could apply this overwrite.
> 
> [1] http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s10.html
> 

I wasn't intending to imply otherwise, I'd just like to see x32 treated
as a existent thing by critical infrastructure components.


signature.asc
Description: This is a digitally signed message part
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

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

[Christian Schmidbauer]

I don't think our patches will be mutually exclusive. If I understand
you correctly, you are trying to make x32 auto-detectable, hence make
it work "out of the box". I like the idea and I also tried x32
auto-detection in the past, but it seemed to me that the
infrastructure does not support it very well. I also don't think that
enough people use x32 to justify putting many working hours into it.

My approach of this patch on the other hand is much more general in
nature: I am trying to support any lib, as defined in [1]. This
allows cmake to be used in environments which have more specific
requirements. Hence it overwrites the default heuristic, which is
usually wrong in such environments. The x32 ABI is just one scenario
where you could apply this overwrite.

[1] http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s10.html

On Sun, Feb 26, 2017 at 6:38 PM, Steven Newbury  wrote:
> On Sun, 2017-02-26 at 16:25 +, Steven Newbury wrote:
>> On Sun, 2017-02-26 at 16:42 +0100, Christian Schmidbauer wrote:
>> > 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.0 +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}"
>> >
>>
>> Hallo Chris,
>>
>> I've made some progress with run-time x32 detection in cmake.  I'll
>> see
>> how that goes, if I can't get it working (which I'm testing now) I'll
>> use your approach.
>
> I have to say, the whole idea behind having either 32-bit or 64-bit
> library paths determined by the size of a single type, this way seems a
> little flawed to me.  Linux x32 (Linux ELF x86-64-32) isn't the only
> 32-bit userland on 64-bit kernel.  MIPS does the same and there's also
> ILP32 for aarch64 (ARM64-32).  Not to mention any other ABI variants.
>
> Previous code used CMAKE_INTERNAL_PLATFORM_ABI at least for MIPS, this
> just makes much more sense to me, and it's the approach I've used in my
> updated x32 cmake patch to determine at run-time if we're using x32-
> abi.
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

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

[Steven Newbury]

On Sun, 2017-02-26 at 16:25 +, Steven Newbury wrote:
> On Sun, 2017-02-26 at 16:42 +0100, Christian Schmidbauer wrote:
> > 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.0 +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}"
> > 
> 
> Hallo Chris,
> 
> I've made some progress with run-time x32 detection in cmake.  I'll
> see
> how that goes, if I can't get it working (which I'm testing now) I'll
> use your approach.

I have to say, the whole idea behind having either 32-bit or 64-bit
library paths determined by the size of a single type, this way seems a
little flawed to me.  Linux x32 (Linux ELF x86-64-32) isn't the only
32-bit userland on 64-bit kernel.  MIPS does the same and there's also
ILP32 for aarch64 (ARM64-32).  Not to mention any other ABI variants.

Previous code used CMAKE_INTERNAL_PLATFORM_ABI at least for MIPS, this
just makes much more sense to me, and it's the approach I've used in my
updated x32 cmake patch to determine at run-time if we're using x32-
abi.


signature.asc
Description: This is a digitally signed message part
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

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

[Steven Newbury]

On Sun, 2017-02-26 at 16:42 +0100, Christian Schmidbauer wrote:
> 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.0 +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}"
> 
Hallo Chris,

I've made some progress with run-time x32 detection in cmake.  I'll see
how that goes, if I can't get it working (which I'm testing now) I'll
use your approach.


signature.asc
Description: This is a digitally signed message part
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [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.0 +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  wrote:
> On Fri, 2016-06-17 at 18:53 +0200, Christian Schmidbauer wrote:
>> On Mon, Jun 13, 2016 at 5:22 PM, Brad King 
>> 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?
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

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

[Steven Newbury]

On Fri, 2016-06-17 at 18:53 +0200, Christian Schmidbauer wrote:
> On Mon, Jun 13, 2016 at 5:22 PM, Brad King 
> 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?


signature.asc
Description: This is a digitally signed message part
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

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

[Christian Schmidbauer]

On Fri, Jun 17, 2016 at 8:10 PM, Brad King  wrote:
> On 06/17/2016 01:33 PM, Christian Schmidbauer wrote:
>>> CMake sets the lib32/lib64 ones in its own
>>> platform modules for the relevant platforms so user code never
>>> needs to do it.  Where in user code would it be done?
>>
>> In my setup, I would create a custom my-config.cmake file
>
> And that is included from CMakeLists.txt files?
>
>> SET (FIND_LIBRARY_USE_CUSTOM_PATHS TRUE CACHE BOOL "force libx32 search 
>> path" FORCE)
>
> I think you meant to use set_property here.  It is not a cache entry.
> However, see below.
>
>> This way I can overwrite cmake's default lib32/lib64 search folders.
>> Why do you ask? Do you have a specific opinion about this?
>
> If the goal is to be able to override it for a local build then
> we shouldn't have to modify the project CMake code.  Setting the
> global property requires editing code.  The existing properties
> FIND_LIBRARY_USE_LIB{32,64}_PATHS make sense because they are
> configured by CMake as properties of the current system.
>
> Instead we could activate this behavior through a variable that
> could then be added to the cache on the command line via -D.
> That would allow local builds to configure any project to search
> this way.  For example:
>
>   cmake ../src -DCMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX=x32
>
> -Brad
>

I did not intend to use it for a local build. My idea of
"FIND_LIBRARY_USE_CUSTOM_PATHS" was the following:

Currently, cmake tries to detect the naming scheme for
lib/lib32/lib64, hence making the life of a distribution with
non-standard library folders very hard. This patch should allow a
distribution to set the naming scheme of the lib folder to
whatever they want (allowed should be anything, see [1]).

I don't have enough insight into cmake in order to say what would be
the "proper" way to achieve this. I went ahead and followed the logic
from Gentoo's portage (see [2] line 531-533) and tried to expand it
such that you can specify any string for .

If you have a better way to achieve this, I am all ears.

Best regards,
Chris

[1] http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s10.html
[2] 
https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/cmake-utils.eclass?revision=1.114=markup
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

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

[Brad King]

On 06/17/2016 01:33 PM, Christian Schmidbauer wrote:
>> CMake sets the lib32/lib64 ones in its own
>> platform modules for the relevant platforms so user code never
>> needs to do it.  Where in user code would it be done?
> 
> In my setup, I would create a custom my-config.cmake file

And that is included from CMakeLists.txt files?

> SET (FIND_LIBRARY_USE_CUSTOM_PATHS TRUE CACHE BOOL "force libx32 search path" 
> FORCE)

I think you meant to use set_property here.  It is not a cache entry.
However, see below.

> This way I can overwrite cmake's default lib32/lib64 search folders.
> Why do you ask? Do you have a specific opinion about this?

If the goal is to be able to override it for a local build then
we shouldn't have to modify the project CMake code.  Setting the
global property requires editing code.  The existing properties
FIND_LIBRARY_USE_LIB{32,64}_PATHS make sense because they are
configured by CMake as properties of the current system.

Instead we could activate this behavior through a variable that
could then be added to the cache on the command line via -D.
That would allow local builds to configure any project to search
this way.  For example:

  cmake ../src -DCMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX=x32

-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

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

[Christian Schmidbauer]

On Fri, Jun 17, 2016 at 7:13 PM, Brad King  wrote:
> On 06/17/2016 12:53 PM, Christian Schmidbauer wrote:
>>> 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?
>
> In the same places that FIND_LIBRARY_USE_LIB32_PATHS documentation was
> added.  Add a `Help/prop_gbl/FIND_LIBRARY_USE_CUSTOM_SUFFIX.rst` and
> associated links to it.
>
Ok, I will add those and re-send the patch.

>>> 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?
>>>
>> In custom environments, where neither lib, lib32 or lib64 would serve
>> the purpose but some custom library folder.
>
> Actually I was asking in what source code context the actual
>
>  set(LIB_SUFFIX ...)
>  set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_CUSTOM_SUFFIX ...)
>
> lines would appear.  CMake sets the lib32/lib64 ones in its own
> platform modules for the relevant platforms so user code never
> needs to do it.  Where in user code would it be done?
>
> Thanks,
> -Brad
>

In my setup, I would create a custom my-config.cmake file like which I
can include in each cmake build with the following content:

SET (LIB_SUFFIX x32 CACHE STRING "library path suffix" FORCE)
SET (FIND_LIBRARY_USE_CUSTOM_PATHS TRUE CACHE BOOL "force libx32
search path" FORCE)
SET (CMAKE_INSTALL_LIBDIR libx32 CACHE PATH "Output directory for libraries")

This way I can overwrite cmake's default lib32/lib64 search folders.
Why do you ask? Do you have a specific opinion about this?

Best regards,
Chris
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

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

[Brad King]

On 06/17/2016 12:53 PM, Christian Schmidbauer wrote:
>> 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?

In the same places that FIND_LIBRARY_USE_LIB32_PATHS documentation was
added.  Add a `Help/prop_gbl/FIND_LIBRARY_USE_CUSTOM_SUFFIX.rst` and
associated links to it.

>> 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?
>>
> In custom environments, where neither lib, lib32 or lib64 would serve
> the purpose but some custom library folder.

Actually I was asking in what source code context the actual

 set(LIB_SUFFIX ...)
 set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_CUSTOM_SUFFIX ...)

lines would appear.  CMake sets the lib32/lib64 ones in its own
platform modules for the relevant platforms so user code never
needs to do it.  Where in user code would it be done?

Thanks,
-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

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

[Christian Schmidbauer]

On Mon, Jun 13, 2016 at 5:22 PM, Brad King  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.

Best regards,
Chris
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

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

[Brad King]

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?

>  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.

> +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

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

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

[Christian Schmidbauer]

Inspired by commit 896ad25 for bug #11260, this commit allows to use the
variable LIB_SUFFIX to be used as find path as well. Allowing the find
path to be more deterministic on custom setups.

A similar idea has already been suggested in #10287 and is required for
bug #15594.
---
 Help/command/find_library.rst  |  5 
 Help/manual/cmake-properties.7.rst |  1 +
 Modules/FindPkgConfig.cmake|  5 +++-
 Source/cmFindLibraryCommand.cxx| 27 ++
 Source/cmFindPackageCommand.cxx| 32 +++---
 Source/cmFindPackageCommand.h  |  1 +
 Tests/CMakeOnly/find_library/CMakeLists.txt| 14 ++
 .../CMakeOnly/find_library/lib/A/libXYZ/libtest3.a |  0
 Tests/CMakeOnly/find_library/lib/XYZ/libtest2.a|  0
 .../CMakeOnly/find_library/libXYZ/A/lib/libtest2.a |  0
 .../find_library/libXYZ/A/libXYZ/libtest1.a|  0
 Tests/CMakeOnly/find_library/libXYZ/A/libtest1.a   |  0
 Tests/CMakeOnly/find_library/libXYZ/libtest1.a |  0
 13 files changed, 62 insertions(+), 23 deletions(-)
 create mode 100644 Tests/CMakeOnly/find_library/lib/A/libXYZ/libtest3.a
 create mode 100644 Tests/CMakeOnly/find_library/lib/XYZ/libtest2.a
 create mode 100644 Tests/CMakeOnly/find_library/libXYZ/A/lib/libtest2.a
 create mode 100644 Tests/CMakeOnly/find_library/libXYZ/A/libXYZ/libtest1.a
 create mode 100644 Tests/CMakeOnly/find_library/libXYZ/A/libtest1.a
 create mode 100644 Tests/CMakeOnly/find_library/libXYZ/libtest1.a

diff --git a/Help/command/find_library.rst b/Help/command/find_library.rst
index 1eb50f7..66eb401 100644
--- a/Help/command/find_library.rst
+++ b/Help/command/find_library.rst
@@ -49,6 +49,11 @@ path to the framework ``/A.framework``.  When a 
full path to a
 framework is used as a library, CMake will use a ``-framework A``, and a
 ``-F`` to link the framework to the target.
 
+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`.
+
 If the :prop_gbl:`FIND_LIBRARY_USE_LIB32_PATHS` global property is set
 all search paths will be tested as normal, with ``32/`` appended, and
 with all matches of ``lib/`` replaced with ``lib32/``.  This property is
diff --git a/Help/manual/cmake-properties.7.rst 
b/Help/manual/cmake-properties.7.rst
index d16f231..128f180 100644
--- a/Help/manual/cmake-properties.7.rst
+++ b/Help/manual/cmake-properties.7.rst
@@ -24,6 +24,7 @@ Properties of Global Scope
/prop_gbl/DISABLED_FEATURES
/prop_gbl/ENABLED_FEATURES
/prop_gbl/ENABLED_LANGUAGES
+   /prop_gbl/FIND_LIBRARY_USE_CUSTOM_SUFFIX
/prop_gbl/FIND_LIBRARY_USE_LIB32_PATHS
/prop_gbl/FIND_LIBRARY_USE_LIB64_PATHS
/prop_gbl/FIND_LIBRARY_USE_OPENBSD_VERSIONING
diff --git a/Modules/FindPkgConfig.cmake b/Modules/FindPkgConfig.cmake
index 33290c4..75fbef8 100644
--- a/Modules/FindPkgConfig.cmake
+++ b/Modules/FindPkgConfig.cmake
@@ -311,7 +311,10 @@ macro(_pkg_check_modules_internal _is_required _is_silent 
_no_cmake_path _no_cma
   if(NOT DEFINED CMAKE_SYSTEM_NAME
   OR (CMAKE_SYSTEM_NAME MATCHES "^(Linux|kFreeBSD|GNU)$"
   AND NOT CMAKE_CROSSCOMPILING))
-if(EXISTS "/etc/debian_version") # is this a debian system ?
+get_property(uselibcustom GLOBAL PROPERTY 
FIND_LIBRARY_USE_CUSTOM_SUFFIX)
+if(uselibcustom)
+  list(APPEND _lib_dirs "lib${LIB_SUFFIX}/pkgconfig")
+elseif(EXISTS "/etc/debian_version") # is this a debian system ?
   if(CMAKE_LIBRARY_ARCHITECTURE)
 list(APPEND _lib_dirs 
"lib/${CMAKE_LIBRARY_ARCHITECTURE}/pkgconfig")
   endif()
diff --git a/Source/cmFindLibraryCommand.cxx b/Source/cmFindLibraryCommand.cxx
index 3094fcf..d86137a 100644
--- a/Source/cmFindLibraryCommand.cxx
+++ b/Source/cmFindLibraryCommand.cxx
@@ -40,20 +40,23 @@ bool 
cmFindLibraryCommand::InitialPass(std::vector const& argsIn,
 return true;
   }
 
+  // add custom lib${LIB_SUFFIX} paths instead of defaults
   if (this->Makefile->GetState()->GetGlobalPropertyAsBool(
-"FIND_LIBRARY_USE_LIB32_PATHS")) {
-// add special 32 bit paths if this is a 32 bit compile.
-if (this->Makefile->PlatformIs32Bit()) {
-  this->AddArchitecturePaths("32");
-}
+"FIND_LIBRARY_USE_CUSTOM_SUFFIX") &&
+  this->Makefile->GetDefinition("LIB_SUFFIX")) {
+this->AddArchitecturePaths(this->Makefile->GetDefinition("LIB_SUFFIX"));
   }
-
-  if (this->Makefile->GetState()->GetGlobalPropertyAsBool(
-"FIND_LIBRARY_USE_LIB64_PATHS")) {
-// add special 64 bit paths if this is a 64 bit compile.
-if (this->Makefile->PlatformIs64Bit()) {
-  this->AddArchitecturePaths("64");
-}
+  // add special 32 bit paths if this is a 32