Re: [cmake-developers] [PATCH] Allow LIB_SUFFIX be used as find path
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&view=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] COMPILE_FEATURES, Mac and non-Apple clang versions
On Wed, Jan 04, 2017 at 12:12:46 +1100, Craig Scott wrote: > We have many projects which do exactly the scenario you mention above where > a project can be built standalone or added to another project via > add_subdirectory(). We have not found it necessary to test if a project is > top level or not before calling cmake_minimum_required(). The behaviour is > well-defined and performs as per the documentation in regard to policies > and minimum CMake versions as far as we've observed. Can you point me/us at > documentation or code which shows why this should be considered undefined > behaviour? I'm particularly interested in this case since we use it > frequently in production. I agree; I've seen projects do multiple cmake_minimum_required() calls and work as one would expect. However, the problem is, it seems to me, with CMP0025 specifically because it changes the logic around the identity detection of the compiler. The compiler is only identified once, so once it is detected as being X, it will always be X, even if CMP0025 changes in the future (via explicit setting, a change to the version in the cmake_minimum_required() call, etc.) without resetting the build tree. --Ben -- 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] Allow CodeBlocks for NMake Makefiles JOM
Hello again! 24.12.2016, 15:09, "Konstantin Podsvirov" :Hello all! Any promotion please :-) CMake: https://gitlab.kitware.com/cmake/cmake/merge_requests/360 QtCreator: https://codereview.qt-project.org/#/c/180814 QtCreator CR now merged to 4.2 branch: https://codereview.qt-project.org/#/c/180814 And we can configure CodeBlocks extra generator for NMake Makefiles JOM generator via QtCreator. I need help to push my CMake changes to next branch, then master, then release. You can try my binary preview by online installer: http://download.podsvirov.pro/installers/dad-0.3.1-windows-vc14x64-unstable.exe (You need manualy configure 'Kit' with provided CMake) --Regards,Konstantin Podsvirov -- 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
