Re: [CMake] find_library doesn't find .dll on windows

Hi Romain, Just to give you more insight on this and add details on top of Juan's answer, CMake will only able to find libraries with the .lib extension because it is what you are supposed to link against. And CMake explicitly defines that in the following file:

[CMake] conditions and included subprojects

Dear CMake users, Maybe my question is trivial for most, but still I do not find an answer on my own! If you have a project and some sub-project (or module or whatever the jargon is) that are both managed with CMake, they should be in separate directories (directory trees), and each of them have

Re: [CMake] conditions and included subprojects

Dear Cornelis,   your description looks to me like having a three valued option: ON, OFF, UNDEFINED. But an option in cmake language has only two values: ON or OFF.  To solve your problem with the connection between your sub-project and the main project, you should forget about the main

Re: [CMake] conditions and included subprojects

Thanks for your proposals! Actually my problem is basically that I want to keep up with some minimum good practice, but I am seeing myself throwing it over board constantly if I do not find a logical solution after one or two hours of struggling... Your second option is close to what I am

Re: [CMake] conditions and included subprojects

Hello Cornelis, I'm not sure if I get your use-case completely, but somtimes I also have the need for three-state variables. What I usually do: set(MY_OPTION "AUTO" CACHE STRING "Documentation for my option") set_property(CACHE MY_OPTION STRINGS "ON:OFF:AUTO") if("${MY_OPTION}" STREQUAL AUTO)

Re: [CMake] conditions and included subprojects

I think, I missunderstood some parts. In particular, why should the user have to change the CMakeLists.txt? He/she can set the value at the commandline or in the cmake-gui and your CMakelist sees the value of your option and can react to that.  Gesendet: Montag, 11. Juni 2018 um 10:55 Uhr Von: 

Re: [CMake] Install libraries defined in INTERFACE targets

Here is an updated version of your example with working exporting of Module3 and importing inside Module4 ( I ignored the XML lib importing ) CMake_with_exporting.tar.xz Description: application/xz -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at:

[Cmake-commits] CMake branch, master, updated. v3.11.3-941-gf49870e

t a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index 0b2b131..8662efc 100644 --- a/Source/CMakeVersion.cmake +++ b/Source/CMakeVersion.cmake @@ -1,5 +1,5 @@ # CMake version number components. set(CMake_VERSION_MAJOR 3) set(CMake_VERSION_MINOR 12) -set(CMake_VERSION_PATCH 20180611) +set(CMake_VER

Re: [cmake-developers] cmake on AIX

On 06/08/2018 11:56 AM, REIX, Tony wrote: > We'd like to know if cmake has already been ported on AIX. Yes, it has long worked on AIX. We have nightly testing on AIX 7.2 with both GCC 7.2 and XL 13.1. A couple of tests are disabled for those builds but it works in general. Since CMake 3.10 we

Re: [cmake-developers] cmake on AIX

Hi Brad, Good news ! Thanks for the information. We are building cmake now only with GCC (6.3.0 for now) on AIX 6.1 . Which GCC compiler version are you using on AIX ? We have been able to build the RPMs files of cmake 3.11.1 once by means of our RPM cmakespec file. Now, when we try to

Re: [cmake-developers] cmake on AIX

On 06/11/2018 11:16 AM, REIX, Tony wrote: > We are building cmake now only with GCC (6.3.0 for now) on AIX 6.1 . > Which GCC compiler version are you using on AIX ? GCC 7.2. We previously tested with 6.1 and that worked too. > It appears that the cmake executable has been built so that it looks