From 909937233 at qq.com Sun Jan 1 21:16:25 2017 From: 909937233 at qq.com (=?ISO-8859-1?B?dHVyYnVsZW50?=) Date: Mon, 2 Jan 2017 10:16:25 +0800 Subject: [CMake] CMake project with fpp preprocessed Fortran source file failed Message-ID: Hi, I'm trying to use fpp preprocessor in a Fortran project built with CMake. For example, I have two source files. The file x.f90 defines module x: module x #ifdef ENABLE_Z use z #endif implicit none end module x The module z used in module x is defined in z.f90 as followed: module z implicit none integer :: z_a end module z Below is the CMakeLists.txt: cmake_minimum_required(VERSION 3.1) project(foo Fortran) set_source_files_properties(x.f90 PROPERTIES COMPILE_DEFINITIONS "ENABLE_Z" ) add_library(mylib x.f90 z.f90 ) I use "MinGW Makefile" generator and Intel Parallel Studio XE 2015 to build mylib under windows 7 command console: D:\dev\cmake\fortran_depend_fpp\build>cmake -G"MinGW Makefiles" -DCMAKE_Fortran_ COMPILER=ifort ..\src -- The Fortran compiler identification is Intel 15.0.2.20150121 -- Check for working Fortran compiler: C:/Intel/Composer XE 2015/bin/intel64/ifo rt.exe -- Check for working Fortran compiler: C:/Intel/Composer XE 2015/bin/intel64/ifo rt.exe -- works -- Detecting Fortran compiler ABI info -- Detecting Fortran compiler ABI info - done -- Checking whether C:/Intel/Composer XE 2015/bin/intel64/ifort.exe supports For tran 90 -- Checking whether C:/Intel/Composer XE 2015/bin/intel64/ifort.exe supports For tran 90 -- yes -- Configuring done -- Generating done -- Build files have been written to: D:/dev/cmake/fortran_depend_fpp/build When building library mylib, it failed: D:\dev\cmake\fortran_depend_fpp\build>mingw32-make mylib Scanning dependencies of target mylib [ 33%] Building Fortran object CMakeFiles/mylib.dir/x.f90.obj D:\dev\cmake\fortran_depend_fpp\src\x.f90(4): error #7002: Error in opening the compiled module file. Check INCLUDE paths. [Z] use z ------^ compilation aborted for D:\dev\cmake\fortran_depend_fpp\src\x.f90 (code 1) CMakeFiles\mylib.dir\build.make:61: recipe for target 'CMakeFiles/mylib.dir/x.f9 0.obj' failed mingw32-make[3]: *** [CMakeFiles/mylib.dir/x.f90.obj] Error 1 CMakeFiles\Makefile2:104: recipe for target 'CMakeFiles/mylib.dir/all' failed mingw32-make[2]: *** [CMakeFiles/mylib.dir/all] Error 2 CMakeFiles\Makefile2:117: recipe for target 'CMakeFiles/mylib.dir/rule' failed mingw32-make[1]: *** [CMakeFiles/mylib.dir/rule] Error 2 Makefile:130: recipe for target 'mylib' failed mingw32-make: *** [mylib] Error 2 The reason is that x.f90 is compiled before z.f90. It seems that the makefile doesn't contain the rule about module x's dependency on module z. How could I correct it? Thanks in advance for your suggestions. BTW: the "Visual Studio 12 2013" generator works fine. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfazlolahzadeh at yahoo.com Tue Jan 3 08:23:44 2017 From: mfazlolahzadeh at yahoo.com (=?UTF-8?Q?=E2=80=AAMarzieh_Fazlolahzadeh=E2=80=AC_=E2=80=AA?=) Date: Tue, 3 Jan 2017 13:23:44 +0000 (UTC) Subject: [CMake] problem with ((The source directory "C:/opencv" does not appear to contain CMakeLists.txt.)) References: <782962793.9378849.1483449824231.ref@mail.yahoo.com> Message-ID: <782962793.9378849.1483449824231@mail.yahoo.com> helloI HAVE PROBLEM WITH?The source directory "C:/opencv" does not appear to contain CMakeLists.txt. i want to use opencv and when?type direction c:/opencv as where is the source codeand c:/opencv/build as where to build the binaries ?in cmake gui window i face this error:The source directory "C:/opencv" does not appear to contain CMakeLists.txt. in win8-64 ?opencv 3.2 and python 2.7 and visual studio 2015,cmake 3.7.1?marzieh fazlolahzadeh? -------------- next part -------------- An HTML attachment was scrubbed... URL: From boxerab at gmail.com Wed Jan 4 08:43:29 2017 From: boxerab at gmail.com (Aaron Boxer) Date: Wed, 4 Jan 2017 08:43:29 -0500 Subject: [CMake] Tracing ctest crash on windows Message-ID: Hello, I am on windows, with visual studio 2015. Some of my ctest tests are crashing with exception. Is there a way of debugging these tests ? When I run in debug mode, I get an exception dialog, but can't drop into debugging environment. Thanks, Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: From aishwaryaselvaraj1708 at gmail.com Wed Jan 4 12:29:57 2017 From: aishwaryaselvaraj1708 at gmail.com (aishwarya selvaraj) Date: Wed, 4 Jan 2017 22:59:57 +0530 Subject: [CMake] To include external libraries using Cmake Message-ID: Hi , I'm using Cmake to create binary files as it can give a way to build my application that will successfully compile on different platforms . I use : Linux -14.04 Cmake - 2.8.12 My .cpp code is called TSM_CODE_V3.cpp.It depends on two external library files .1) armadillo 2) sndfile . I scripted a CmakeLists.txt as follows : CMAKE_MINIMUM_REQUIRED(VERSION 2.8.9) PROJECT(TSM2) FIND_LIBRARY(ARMADILLO armadillo) MESSAGE(STATUS "Armadillo Library location: " ${ARMADILLO}) IF (NOT ARMADILLO_FOUND) include(ExternalProject) MESSAGE(STATUS "Armadillo not found in the system ,Trying to install armadillo...") ExternalProject_Add(armadillo URL https://github.com/lsolanka/armadillo/archive/master.zip PREFIX ${CMAKE_CURRENT_BINARY_DIR}/armadillo-latest) ENDIF() FIND_LIBRARY(SNDFILE sndfile) MESSAGE(STATUS "Sndfile Library location: " ${SNDFILE}) IF (NOT SNDFILE_FOUND) include(ExternalProject) MESSAGE(STATUS "Armadillo not found in the system ,Trying to install libsndfile...") ExternalProject_Add(sndfile URL https://github.com/erikd/libsndfile/archive/master.zip PREFIX ${CMAKE_CURRENT_BINARY_DIR}/sndfile-latest) ENDIF() ADD_EXECUTABLE(tsm ${PROJECT_SOURCE_DIR}/src/TSM_CODE_V3.cpp) TARGET_LINK_LIBRARIES(tsm ${ARMADILLO} ${SNDFILE}) I made use of ExternalProject_add to download the external libraries from the specified link address ,but when I try to compile the CmakeLists.txt , it throws an error of saying library not found .Basically , the external library is not downloaded from the specified link . I'm not sure where am I going wrong here . Can anyone help me out ? Hoping to hear from you.. -- Regards, Aishwarya Selvaraj -------------- next part -------------- An HTML attachment was scrubbed... URL: From parag at ionicsecurity.com Wed Jan 4 14:52:49 2017 From: parag at ionicsecurity.com (Parag Chandra) Date: Wed, 4 Jan 2017 19:52:49 +0000 Subject: [CMake] [EXTERNAL]: To include external libraries using Cmake In-Reply-To: References: Message-ID: <526EB2C4-5876-4C78-8C4E-4A3EC08BA6EC@ionic.com> Hi there, If I?m not mistaken, when a library cannot be found, the value of the variable ?ARMADILLO? will be set to ?ARMADILLO-NOTFOUND?. So I think you need to adjust your test to: IF (${ARMADILLO} STREQUAL ?ARMADILLO-NOTFOUND?) # do what you want ENDIF () The following links in the doc may be helpful: https://cmake.org/cmake/help/v3.7/command/find_library.html https://cmake.org/cmake/help/v3.7/command/if.html Parag Chandra Technical Lead, Mobile Team Mobile: +1.919.824.1410 Ionic Security Inc. 1170 Peachtree St. NE STE 400, Atlanta, GA 30309 From: CMake on behalf of aishwarya selvaraj Date: Wednesday, January 4, 2017 at 12:29 PM To: cmake Subject: [EXTERNAL]: [CMake] To include external libraries using Cmake Hi , I'm using Cmake to create binary files as it can give a way to build my application that will successfully compile on different platforms . I use : Linux -14.04 Cmake - 2.8.12 My .cpp code is called TSM_CODE_V3.cpp.It depends on two external library files .1) armadillo 2) sndfile . I scripted a CmakeLists.txt as follows : CMAKE_MINIMUM_REQUIRED(VERSION 2.8.9) PROJECT(TSM2) FIND_LIBRARY(ARMADILLO armadillo) MESSAGE(STATUS "Armadillo Library location: " ${ARMADILLO}) IF (NOT ARMADILLO_FOUND) include(ExternalProject) MESSAGE(STATUS "Armadillo not found in the system ,Trying to install armadillo...") ExternalProject_Add(armadillo URL https://github.com/lsolanka/armadillo/archive/master.zip PREFIX ${CMAKE_CURRENT_BINARY_DIR}/armadillo-latest) ENDIF() FIND_LIBRARY(SNDFILE sndfile) MESSAGE(STATUS "Sndfile Library location: " ${SNDFILE}) IF (NOT SNDFILE_FOUND) include(ExternalProject) MESSAGE(STATUS "Armadillo not found in the system ,Trying to install libsndfile...") ExternalProject_Add(sndfile URL https://github.com/erikd/libsndfile/archive/master.zip PREFIX ${CMAKE_CURRENT_BINARY_DIR}/sndfile-latest) ENDIF() ADD_EXECUTABLE(tsm ${PROJECT_SOURCE_DIR}/src/TSM_CODE_V3.cpp) TARGET_LINK_LIBRARIES(tsm ${ARMADILLO} ${SNDFILE}) I made use of ExternalProject_add to download the external libraries from the specified link address ,but when I try to compile the CmakeLists.txt , it throws an error of saying library not found .Basically , the external library is not downloaded from the specified link . I'm not sure where am I going wrong here . Can anyone help me out ? Hoping to hear from you.. -- Regards, Aishwarya Selvaraj -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.woehlke at kitware.com Wed Jan 4 17:23:21 2017 From: matthew.woehlke at kitware.com (Matthew Woehlke) Date: Wed, 4 Jan 2017 17:23:21 -0500 Subject: [CMake] [EXTERNAL]: To include external libraries using Cmake In-Reply-To: <526EB2C4-5876-4C78-8C4E-4A3EC08BA6EC@ionic.com> References: <526EB2C4-5876-4C78-8C4E-4A3EC08BA6EC@ionic.com> Message-ID: <586D75D9.2050208@kitware.com> (Arf, re-send with an account that's allowed to post to the list...) On 2017-01-04 14:52, Parag Chandra wrote: > If I?m not mistaken, when a library cannot be found, the value of > the variable ?ARMADILLO? will be set to ?ARMADILLO-NOTFOUND?. Correct. But... > So I think you need to adjust your test to: > > IF (${ARMADILLO} STREQUAL ?ARMADILLO-NOTFOUND?) > # do what you want > ENDIF () CMake treats several strings as having the Boolean value 'false', including "FALSE" (duh), "0", "OFF", and anything that ends with "-NOTFOUND". So, it's clearer to just write `if(NOT ARMADILLO)`. (That said, note that it is convention to name variables that receive the location of a library like ARMADILLO_LIBRARY. Also, uppercase commands are sooo last decade ;-).) BTW, avoid writing unquoted variable expansions in `if()`, as they are subject to multiple expansion that way. (And it's only recently that quoted values are not subject to expansion!) Instead, just write the variable name without the `${` and `}`; it will be expanded for you. -- Matthew From aishwaryaselvaraj1708 at gmail.com Thu Jan 5 05:10:32 2017 From: aishwaryaselvaraj1708 at gmail.com (aishwarya selvaraj) Date: Thu, 5 Jan 2017 15:40:32 +0530 Subject: [CMake] To include external libraries using Cmake Message-ID: Thanks for feedback : > IF (${ARMADILLO} STREQUAL ?ARMADILLO-NOTFOUND?) > # do what you want > ENDIF () ? I tried this way of writing : IF (${ARMADILLO} STREQUAL "ARMADILLO-NOTFOUND") include(ExternalProject) ExternalProject_Add(armadillo URL https://github.com/lsolanka/armadillo/archive/master.zip PREFIX ${CMAKE_CURRENT_BINARY_DIR}/armadillo-latest) ENDIF() and IF (ARMADILLO STREQUAL ARMADILLO-NOTFOUND) include(ExternalProject) MESSAGE(STATUS "Trying to install armadillo...") ExternalProject_Add(armadillo URL https://github.com/lsolanka/armadillo/archive/master.zip PREFIX ${CMAKE_CURRENT_BINARY_DIR}/armadillo-latest) ENDIF() ?But both of them gave me an error : -- * Armadillo Library location: ARMADILLO-NOTFOUND-- Trying to install armadillo...-- Sndfile Library location: SNDFILE-NOTFOUND-- Trying to install libsndfile...CMake Error: The following variables are used in this project, but they are set to NOTFOUND.Please set them or make sure they are set and tested correctly in the CMake files:ARMADILLO linked by target "tsm" in directory /home/computing9/TSM_cmakeSNDFILE linked by target "tsm" in directory /home/computing9/TSM_cmake-- Configuring incomplete, errors occurred!See also "/home/computing9/TSM_cmake/build/CMakeFiles/CMakeOutput.log".* ExternalProject_add command is not instlling the mentioned libraries from the specifies link . Any suggestions ? Regards Aishwarya Selvaraj -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsvanbethlehem at gmail.com Thu Jan 5 09:32:44 2017 From: jsvanbethlehem at gmail.com (Jakob van Bethlehem) Date: Thu, 5 Jan 2017 15:32:44 +0100 Subject: [CMake] Tracing ctest crash on windows In-Reply-To: References: Message-ID: Hej, CTest is not some magical tool that internally runs your test or something like that - instead CTest just fires up your test executable and does clever things with the output. In the same way you can just set your test project as startup-project, and debug it like any other executable. Sincerely, Jakob On Wed, Jan 4, 2017 at 2:43 PM, Aaron Boxer wrote: > Hello, > I am on windows, with visual studio 2015. > Some of my ctest tests are crashing with exception. > Is there a way of debugging these tests ? > > When I run in debug mode, I get an exception dialog, > but can't drop into debugging environment. > > Thanks, > Aaron > > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Dvir.Yitzchaki at ceva-dsp.com Thu Jan 5 04:28:55 2017 From: Dvir.Yitzchaki at ceva-dsp.com (Dvir Yitzchaki) Date: Thu, 5 Jan 2017 09:28:55 +0000 Subject: [CMake] cpack multiple packages In-Reply-To: References: <47b07b498c81452798ec3f9661e75a06@ceva-dsp.com> Message-ID: <0ad1b773ec8a493b8458608e46574426@ceva-dsp.com> Hi Domen. That works perfectly. This is my code if anyone?s interested: function(install_common) foreach(component ${ALL_COMPONENTS}) install(${ARGV} COMPONENT ${component}) endforeach() endfunction() where ALL_COMPONENTS is a global variable holding all components. Thanks, Dvir From: Domen Vrankar [mailto:domen.vrankar at gmail.com] Sent: Thursday, December 22, 2016 20:43 To: Dvir Yitzchaki Cc: Eric Noulard ; cmake at cmake.org Subject: Re: [CMake] cpack multiple packages 2016-12-21 12:29 GMT+01:00 Dvir Yitzchaki >: Thanks, but as I understand a component can only belong to one group. How can I get the same component/target on multiple packages? Usually you wouldn't want to package same file on same location with same filename since during unpackaging they would override each other so this is not supported out of the box. Usually in such cases I would split packages even further so that one package would be base package of others (but automatic dependency tracking between them would require something more sophisticated than zip - RPM, Deb or some other CPack supported packager perhaps). However if you really need to do something like that you could write a function that you would call instead of install(...) command which would just forward to it and the first parameter would have a list of components to which the file should belong. For e.g. some pseudo code: function(my_install my_list other_params_that_get_forwarded...) foreach(component_name_ IN LISTS my_list) install(other_params_that_get_forwarded... COMPONENT ${component_name_}) endforeach() endfunction() my_install("first;second;and_anotherone" "TARGETS target_name" "DESTINATION some_dir") Hope this helps. Regards, Domen -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcdailey.lists at gmail.com Thu Jan 5 11:30:18 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Thu, 5 Jan 2017 10:30:18 -0600 Subject: [CMake] How do static libraries get linked in Ninja? Message-ID: I have two targets in CMake: a static library and a shared library. The shared library specifies the static library as a target link library. When I generate for Ninja, and I run: $ ninja -v During the link command for the shared library, I do not see the static library specified to g++. I do see *.so files, but not *.a files. Why are static libraries not showing up on the command line for the link step? There must be some black magic happening that I'm not seeing... From bill.hoffman at kitware.com Thu Jan 5 11:51:35 2017 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Thu, 5 Jan 2017 11:51:35 -0500 Subject: [CMake] Tracing ctest crash on windows In-Reply-To: References: Message-ID: On 1/5/2017 9:32 AM, Jakob van Bethlehem wrote: > > CTest is not some magical tool that internally runs your test or > something like that - instead CTest just fires up your test executable > and does clever things with the output. In the same way you can just set > your test project as startup-project, and debug it like any other > executable. > > Sincerely, > Jakob > > On Wed, Jan 4, 2017 at 2:43 PM, Aaron Boxer > wrote: > > Hello, > I am on windows, with visual studio 2015. > Some of my ctest tests are crashing with exception. > Is there a way of debugging these tests ? > > When I run in debug mode, I get an exception dialog, > but can't drop into debugging environment. If you run ctest -VV it will show the full command line. Best way is to just run the same command in the debugger. -Bill From matthew.woehlke at kitware.com Thu Jan 5 14:21:40 2017 From: matthew.woehlke at kitware.com (Matthew Woehlke) Date: Thu, 5 Jan 2017 14:21:40 -0500 Subject: [CMake] To include external libraries using Cmake In-Reply-To: References: Message-ID: <586E9CC4.4040402@kitware.com> On 2017-01-05 05:10, aishwarya selvaraj wrote: > Thanks for feedback : > >> IF (${ARMADILLO} STREQUAL ?ARMADILLO-NOTFOUND?) >> # do what you want >> ENDIF () > ? > I tried this way of writing : > > IF (${ARMADILLO} STREQUAL "ARMADILLO-NOTFOUND") > include(ExternalProject) > ExternalProject_Add(armadillo > URL https://github.com/lsolanka/armadillo/archive/master.zip > PREFIX ${CMAKE_CURRENT_BINARY_DIR}/armadillo-latest) > ENDIF() > > and > > IF (ARMADILLO STREQUAL ARMADILLO-NOTFOUND) > include(ExternalProject) > MESSAGE(STATUS "Trying to install armadillo...") > ExternalProject_Add(armadillo > URL https://github.com/lsolanka/armadillo/archive/master.zip > PREFIX ${CMAKE_CURRENT_BINARY_DIR}/armadillo-latest) > ENDIF() `if(NOT ARMADILLO)` is probably better... > ?But both of them gave me an error : > CMake Error: The following variables are used in this project, but > they are set to NOTFOUND. Please set them or make sure they are set > and tested correctly in the CMake files: > ARMADILLO > linked by target "tsm" in directory /home/computing9/TSM_cmake > SNDFILE > linked by target "tsm" in directory /home/computing9/TSM_cmake Ah... I was mostly replying to Parag; I hadn't actually looked that closely at your original problem. What you're trying to do is similar to a "superbuild" with optional components. The usual way to do this is to treat *your own project* as one of several external projects, so that the "superbuild" consists solely of external projects. Something like: set(mydeps) if(NOT armadillo) externalproject_add(armadillo ...) list(APPEND mydeps armadillo endif() # similar for other externals externalproject_add(myproject ... DEPENDS ${mydeps}) This way, by the time your project configures, the library exists. (You'll probably end up looking for the library twice; once in the superbuild to decide whether to build it, and again in your project proper where you'll a) assume it exists and hard error otherwise, and b) want to specify as an additional search path where the superbuild will produce it.) Without this, trying to set up the rules so that you can both link the library that will be created, and also get the dependencies correct so that the build knows how to produce it when needed, is probably going to be tricky. (Read: I'm not convinced it's impossible, but I've never seen someone actually doing this and wouldn't recommend it.) An alternative that may work is to set up the externals as subprojects and have CMake fetch them at configure time if they are needed, and then incorporate their builds directly in your own build (i.e. using add_subdirectory rather than externalproject_add); then you can link to the library target names when you build them yourself, and everything will work. p.s. I don't recommend always obtaining the current master of externals. It's usually safer to pick a SHA and bump it as needed, so that you are insulated against breaking changes upstream. I'm also not sure why you are fetching snapshots instead of just using the git repositories directly. -- Matthew From boxerab at gmail.com Thu Jan 5 15:17:09 2017 From: boxerab at gmail.com (Aaron Boxer) Date: Thu, 5 Jan 2017 15:17:09 -0500 Subject: [CMake] Tracing ctest crash on windows In-Reply-To: References: Message-ID: Thanks, Bill and Jakob. I did what you suggested and found the problem Aaron On Thu, Jan 5, 2017 at 11:51 AM, Bill Hoffman wrote: > On 1/5/2017 9:32 AM, Jakob van Bethlehem wrote: > >> >> CTest is not some magical tool that internally runs your test or >> something like that - instead CTest just fires up your test executable >> and does clever things with the output. In the same way you can just set >> your test project as startup-project, and debug it like any other >> executable. >> >> Sincerely, >> Jakob >> >> On Wed, Jan 4, 2017 at 2:43 PM, Aaron Boxer > > wrote: >> >> Hello, >> I am on windows, with visual studio 2015. >> Some of my ctest tests are crashing with exception. >> Is there a way of debugging these tests ? >> >> When I run in debug mode, I get an exception dialog, >> but can't drop into debugging environment. >> > If you run ctest -VV it will show the full command line. Best way is to > just run the same command in the debugger. > > -Bill > > > -- > > 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/opensou > rce/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Thu Jan 5 16:39:34 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 5 Jan 2017 16:39:34 -0500 Subject: [CMake] How do static libraries get linked in Ninja? In-Reply-To: References: Message-ID: Do you mean you don't see where the static library is created or where the static library is listed on the link line for the dynamic library? On Thu, Jan 5, 2017 at 11:30 AM, Robert Dailey wrote: > I have two targets in CMake: a static library and a shared library. > The shared library specifies the static library as a target link > library. > > When I generate for Ninja, and I run: > > $ ninja -v > > During the link command for the shared library, I do not see the > static library specified to g++. I do see *.so files, but not *.a > files. Why are static libraries not showing up on the command line for > the link step? There must be some black magic happening that I'm not > seeing... > -- > > 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 From bradbell at seanet.com Fri Jan 6 07:37:40 2017 From: bradbell at seanet.com (Brad Bell) Date: Fri, 6 Jan 2017 05:37:40 -0700 Subject: [CMake] PROJECT( LANGUAGES ) and m4 Message-ID: If one looks at the documentation https://cmake.org/cmake/help/v3.0/command/project.html one sees project( [LANGUAGES] [...]) and the following text: 'By default C and CXX are enabled if no language options are given.' It there a list of available languages ? I have a project that has m4 input files. A single m4 input file can be used to generate output in Perl, Octave, Python, or C++ language. Can CMake handle this type of dependency, or would I have to use custom targets in this case ? From daryl at daryllee.com Fri Jan 6 10:41:27 2017 From: daryl at daryllee.com (daryl at daryllee.com) Date: Fri, 06 Jan 2017 10:41:27 -0500 Subject: [CMake] CMake 3.7.1 gui fails to launch Message-ID: <20170106104127.Horde.ToRqoeADXuB1Sm-IHgshqtY@www.daryllee.com> I'm running Ubuntu 14.04 and I'm trying to get the current version of CMake to run. (The apt-get version is 2.8). I installed Qt4 (version 4.8.6) with $ sudo apt-get install libqt4-core libqt4-dev libqt4-gui qt4-dev-tools I installed cmake $ ./bootstrap & make & sudo make install all seemed to run without issue. Running "cmake-gui --version" reported version 3.7.1, but running "cmake-gui" failed: ========= daryl at eve-ldb:~/cmake/cmake-3.7.1$ cmake-gui --version cmake version 3.7.1 CMake suite maintained and supported by Kitware (kitware.com/cmake). daryl at eve-ldb:~/cmake/cmake-3.7.1$ cmake-gui cmake-gui: symbol lookup error: cmake-gui: undefined symbol: _ZN9QListData11detach_growEPii ========== That looks like a Qt linkage error. Any suggestions on resolving this? From DLRdave at aol.com Fri Jan 6 10:51:54 2017 From: DLRdave at aol.com (David Cole) Date: Fri, 6 Jan 2017 10:51:54 -0500 Subject: [CMake] CMake 3.7.1 gui fails to launch In-Reply-To: <20170106104127.Horde.ToRqoeADXuB1Sm-IHgshqtY@www.daryllee.com> References: <20170106104127.Horde.ToRqoeADXuB1Sm-IHgshqtY@www.daryllee.com> Message-ID: Can you use Qt5? CMake 3.7 is typically built using Qt5: perhaps a Qt5 **requirement** has crept in since it's the commonly used one now. HTH, David C. On Fri, Jan 6, 2017 at 10:41 AM, wrote: > I'm running Ubuntu 14.04 and I'm trying to get the current version of CMake > to run. (The apt-get version is 2.8). > > I installed Qt4 (version 4.8.6) with > > $ sudo apt-get install libqt4-core libqt4-dev libqt4-gui qt4-dev-tools > > I installed cmake > > $ ./bootstrap & make & sudo make install > > all seemed to run without issue. Running "cmake-gui --version" reported > version 3.7.1, but running "cmake-gui" failed: > > ========= > daryl at eve-ldb:~/cmake/cmake-3.7.1$ cmake-gui --version > cmake version 3.7.1 > > CMake suite maintained and supported by Kitware (kitware.com/cmake). > daryl at eve-ldb:~/cmake/cmake-3.7.1$ cmake-gui > cmake-gui: symbol lookup error: cmake-gui: undefined symbol: > _ZN9QListData11detach_growEPii > ========== > > That looks like a Qt linkage error. Any suggestions on resolving this? > -- > > 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 From konstantin at podsvirov.pro Fri Jan 6 11:10:51 2017 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Fri, 06 Jan 2017 19:10:51 +0300 Subject: [CMake] CMake 3.7.1 gui fails to launch In-Reply-To: References: <20170106104127.Horde.ToRqoeADXuB1Sm-IHgshqtY@www.daryllee.com> Message-ID: <1255891483719051@web11g.yandex.ru> An HTML attachment was scrubbed... URL: From apaku at gmx.de Fri Jan 6 12:32:18 2017 From: apaku at gmx.de (Andreas Pakulat) Date: Fri, 6 Jan 2017 18:32:18 +0100 Subject: [CMake] CMake 3.7.1 gui fails to launch In-Reply-To: <20170106104127.Horde.ToRqoeADXuB1Sm-IHgshqtY@www.daryllee.com> References: <20170106104127.Horde.ToRqoeADXuB1Sm-IHgshqtY@www.daryllee.com> Message-ID: Hi, On Fri, Jan 6, 2017 at 4:41 PM, wrote: > CMake suite maintained and supported by Kitware (kitware.com/cmake). > daryl at eve-ldb:~/cmake/cmake-3.7.1$ cmake-gui > cmake-gui: symbol lookup error: cmake-gui: undefined symbol: > _ZN9QListData11detach_growEPii > ========== > > That looks like a Qt linkage error. Any suggestions on resolving this? Right, in particular it means that cmake-gui uses that symbol but none of the libraries loaded into the executable have it. I'd start with checking what ldd says is being loaded for your cmake-gui executable. Maybe there's another Qt installation in LD_LIBRARY_PATH that is being used for running cmake-gui even though its been built against the Qt in /usr/. The other common cause could be the inverse of that, its trying to run against your system Qt but the build process has picked up a Qt from elsewhere compiled with different flags that change the symbols name. Andreas From daryl at daryllee.com Fri Jan 6 12:41:20 2017 From: daryl at daryllee.com (daryl at daryllee.com) Date: Fri, 06 Jan 2017 12:41:20 -0500 Subject: [CMake] CMake 3.7.1 gui fails to launch In-Reply-To: References: <20170106104127.Horde.ToRqoeADXuB1Sm-IHgshqtY@www.daryllee.com> Message-ID: <20170106124120.Horde.U3Sc0LaJ3q5phZjBC0a9wUR@www.daryllee.com> As it turns out, no, I can't use Qt5. In fact, I'd love to hear from anyone who actually has. I find this in Modules/FindQt.make: =========================== if (Qt_FIND_VERSION) if (Qt_FIND_VERSION MATCHES "^([34])(\\.[0-9]+.*)?$") set(DESIRED_QT_VERSION ${CMAKE_MATCH_1}) else () message(FATAL_ERROR "FindQt was called with invalid version '${Qt_FIND_VERSION}'. Only Qt major versions 3 or 4 are supported. If you do not need to support both Qt3 and Qt4 in your source consider calling find_package(Qt3) or find_package(Qt4) instead of find_package(Qt) instead.") endif () endif () =========================== So I re-installed Qt4, rebuilt CMake (./bootstrap --qt-gui, make, sudo make install) and still got the same runtime failure. Quoting David Cole : > Can you use Qt5? CMake 3.7 is typically built using Qt5: perhaps a Qt5 > **requirement** has crept in since it's the commonly used one now. > > > HTH, > David C. > > > > On Fri, Jan 6, 2017 at 10:41 AM, wrote: >> I'm running Ubuntu 14.04 and I'm trying to get the current version of CMake >> to run. (The apt-get version is 2.8). >> >> I installed Qt4 (version 4.8.6) with >> >> $ sudo apt-get install libqt4-core libqt4-dev libqt4-gui qt4-dev-tools >> >> I installed cmake >> >> $ ./bootstrap & make & sudo make install >> >> all seemed to run without issue. Running "cmake-gui --version" reported >> version 3.7.1, but running "cmake-gui" failed: >> >> ========= >> daryl at eve-ldb:~/cmake/cmake-3.7.1$ cmake-gui --version >> cmake version 3.7.1 >> >> CMake suite maintained and supported by Kitware (kitware.com/cmake). >> daryl at eve-ldb:~/cmake/cmake-3.7.1$ cmake-gui >> cmake-gui: symbol lookup error: cmake-gui: undefined symbol: >> _ZN9QListData11detach_growEPii >> ========== >> >> That looks like a Qt linkage error. Any suggestions on resolving this? >> -- >> >> 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 From irwin at beluga.phys.uvic.ca Fri Jan 6 13:51:42 2017 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Fri, 6 Jan 2017 10:51:42 -0800 (PST) Subject: [CMake] CMake 3.7.1 gui fails to launch In-Reply-To: <20170106124120.Horde.U3Sc0LaJ3q5phZjBC0a9wUR@www.daryllee.com> References: <20170106104127.Horde.ToRqoeADXuB1Sm-IHgshqtY@www.daryllee.com> <20170106124120.Horde.U3Sc0LaJ3q5phZjBC0a9wUR@www.daryllee.com> Message-ID: On 2017-01-06 12:41-0500 daryl at daryllee.com wrote: > As it turns out, no, I can't use Qt5. In fact, I'd love to hear from anyone > who actually has. My "ldd -r" results for cmake-gui show my recent bootstrap builds (of cmake-3.7.0) have been built with Qt5 without linking issues. I didn't do anything special for Qt5 other than to install its development packages (for Debian Jessie in my case). So I think if you did the same, it would just work. That said, ~6 months or so ago, I didn't have Qt5 installed on my system so my cmake-gui builds back then were done (without issues) using Qt4. Also, I have used the combination of cmake and Qt5 in other contexts. The issue that is likely confusing you (since it confused me at first encounter as well) is Qt5 cmake support is provided directly by Qt5 (see which is provided by Qt5 developers and not cmake developers). So, for example, the PLplot build system uses either Qt4 (based on CMake support provided by CMake) or Qt5 (based on CMake support provided by Qt5) and my recent (6 months ago and now) experience with CMake builds is they also work fine for either Qt4 or Qt5. So like others here have commented, I suspect you have some Qt4 installation issue (e.g., a mixture of private and system versions) that is causing your present difficulties. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From rcdailey.lists at gmail.com Fri Jan 6 14:12:18 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Fri, 6 Jan 2017 13:12:18 -0600 Subject: [CMake] How do static libraries get linked in Ninja? In-Reply-To: References: Message-ID: The latter. On Thu, Jan 5, 2017 at 3:39 PM, Robert Maynard wrote: > Do you mean you don't see where the static library is created or where > the static library is listed on the link line for the dynamic library? > > On Thu, Jan 5, 2017 at 11:30 AM, Robert Dailey wrote: >> I have two targets in CMake: a static library and a shared library. >> The shared library specifies the static library as a target link >> library. >> >> When I generate for Ninja, and I run: >> >> $ ninja -v >> >> During the link command for the shared library, I do not see the >> static library specified to g++. I do see *.so files, but not *.a >> files. Why are static libraries not showing up on the command line for >> the link step? There must be some black magic happening that I'm not >> seeing... >> -- >> >> 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 From apaku at gmx.de Fri Jan 6 14:10:11 2017 From: apaku at gmx.de (Andreas Pakulat) Date: Fri, 6 Jan 2017 20:10:11 +0100 Subject: [CMake] CMake 3.7.1 gui fails to launch In-Reply-To: <20170106124120.Horde.U3Sc0LaJ3q5phZjBC0a9wUR@www.daryllee.com> References: <20170106104127.Horde.ToRqoeADXuB1Sm-IHgshqtY@www.daryllee.com> <20170106124120.Horde.U3Sc0LaJ3q5phZjBC0a9wUR@www.daryllee.com> Message-ID: Hi, On Fri, Jan 6, 2017 at 6:41 PM, wrote: > As it turns out, no, I can't use Qt5. In fact, I'd love to hear from anyone > who actually has. I find this in Modules/FindQt.make: That module is specifically only for applications wanting to support Qt3 and Qt4 at the same time. > =========================== > if (Qt_FIND_VERSION) > if (Qt_FIND_VERSION MATCHES "^([34])(\\.[0-9]+.*)?$") > set(DESIRED_QT_VERSION ${CMAKE_MATCH_1}) > else () > message(FATAL_ERROR "FindQt was called with invalid version > '${Qt_FIND_VERSION}'. Only Qt major versions 3 or 4 are supported. If you do > not need to support both Qt3 and Qt4 in your source consider calling > find_package(Qt3) or find_package(Qt4) instead of find_package(Qt) > instead.") > endif () > endif () > =========================== > > So I re-installed Qt4, rebuilt CMake (./bootstrap --qt-gui, make, sudo make > install) and still got the same runtime failure. Well, Qt5 isn't found through a find-module but rather through the module-mode (or whatever it was called). Qt5 ships with cmake-specific files that allow cmake to find it as long as its installed in a common prefix (like /usr) or the installation directory is specified via CMAKE_PREFIX_PATH. I suspect if you look at the CMakeLists.txt file you'll see some logic to lookup Qt5 with something like find_package(Qt5 MODULES QtCore QtGui QtWidgets) and a fallback for finding with FindQt4 like find_package(Qt4 MODULES QtCore QtGui QtWidgets). I don't think you'll find usage of the FindQt module in the cmake sources as the code likely won't build with Qt3. Andreas From Mike.Nicholson at viavisolutions.com Fri Jan 6 15:41:11 2017 From: Mike.Nicholson at viavisolutions.com (Mike Nicholson) Date: Fri, 6 Jan 2017 20:41:11 +0000 Subject: [CMake] Ctest logs error but returns zero exit code. Message-ID: Hello, I recently ran into a situation where one of our scripts was attempting to run CTest in the wrong directory. CTest did output a helpful error message: ********************************* No test configuration file found! ********************************* Usage ctest [options] But it still returned an exit code of zero. This behavior seems to be counterintuitive. CTest checks for the error condition (no arguments are specified at command line and the default CMake or Dart TestFile doesn?t exist) and logs the error but does not update the exit code accordingly. I?d be happy to contribute a patch but before investing the time to do so I?d like to understand if this is expected behavior and if so the reasoning behind it. Thanks, Mike Nicholson -------------- next part -------------- An HTML attachment was scrubbed... URL: From daryl at daryllee.com Fri Jan 6 17:37:00 2017 From: daryl at daryllee.com (daryl at daryllee.com) Date: Fri, 06 Jan 2017 17:37:00 -0500 Subject: [CMake] CMake 3.7.1 gui fails to launch In-Reply-To: References: <20170106104127.Horde.ToRqoeADXuB1Sm-IHgshqtY@www.daryllee.com> <20170106124120.Horde.U3Sc0LaJ3q5phZjBC0a9wUR@www.daryllee.com> Message-ID: <20170106173700.Horde.n2B_DSl4jn8JfquoUtKwxWT@www.daryllee.com> And the answer is... I recently installed an IDE from a not-to-be-named company that I do a lot of business with. The installation of that software places their installation directory in LD_LIBRARY_PATH and guess what? their installation contains a copy of libQtGui.so and libQtCore.so. The "ldd" tip led me to that discovery. For now I have put /usr/lib/x86_64-linux-gnu in front of their path in LD_LIBRARY_PATH and cmake-gui V3.7.1 is working. I may have to come up with a more permanent fix, but for now their stuff seems to work and CMake seems to work, so I'm claiming victory. All I can think of now is how often when I was a kid my dad complained about how stubborn I was. Who knew that would be an asset when I grew up? Thanks again for the help. Quoting "Alan W. Irwin" : > On 2017-01-06 12:41-0500 daryl at daryllee.com wrote: > >> As it turns out, no, I can't use Qt5. In fact, I'd love to hear >> from anyone who actually has. > > My "ldd -r" results for cmake-gui show my recent bootstrap builds (of > cmake-3.7.0) have been built with Qt5 without linking issues. I > didn't do anything special for Qt5 other than to install its > development packages (for Debian Jessie in my case). So I think if > you did the same, it would just work. That said, ~6 months or so ago, > I didn't have Qt5 installed on my system so my cmake-gui builds back > then were done (without issues) using Qt4. > > Also, I have used the combination of cmake and Qt5 in other contexts. The > issue that is likely confusing you (since it confused me at first > encounter as well) is Qt5 cmake support is provided directly by Qt5 > (see which is provided by > Qt5 developers and not cmake developers). > > So, for example, the PLplot build system uses either Qt4 (based on > CMake support provided by CMake) or Qt5 (based on CMake support provided > by Qt5) and my recent (6 months ago and now) experience with CMake > builds is they also work fine for either Qt4 or Qt5. > > So like others here have commented, I suspect you have some Qt4 > installation issue (e.g., a mixture of private and system versions) > that is causing your present difficulties. > > Alan > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state > implementation for stellar interiors (freeeos.sf.net); the Time > Ephemerides project (timeephem.sf.net); PLplot scientific plotting > software package (plplot.sf.net); the libLASi project > (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); > and the Linux Brochure Project (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ From post at hendrik-sattler.de Sat Jan 7 03:11:34 2017 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Sat, 07 Jan 2017 09:11:34 +0100 Subject: [CMake] CMake 3.7.1 gui fails to launch In-Reply-To: <20170106173700.Horde.n2B_DSl4jn8JfquoUtKwxWT@www.daryllee.com> References: <20170106104127.Horde.ToRqoeADXuB1Sm-IHgshqtY@www.daryllee.com> <20170106124120.Horde.U3Sc0LaJ3q5phZjBC0a9wUR@www.daryllee.com> <20170106173700.Horde.n2B_DSl4jn8JfquoUtKwxWT@www.daryllee.com> Message-ID: Am 6. Januar 2017 23:37:00 MEZ schrieb daryl at daryllee.com: >And the answer is... > >I recently installed an IDE from a not-to-be-named company that I do a > >lot of business with. The installation of that software places their >installation directory in LD_LIBRARY_PATH and guess what? their >installation contains a copy of libQtGui.so and libQtCore.so. The >"ldd" tip led me to that discovery. For now I have put >/usr/lib/x86_64-linux-gnu in front of their path in LD_LIBRARY_PATH >and cmake-gui V3.7.1 is working. I may have to come up with a more >permanent fix, but for now their stuff seems to work and CMake seems >to work, so I'm claiming victory. Maybe as a customer you should tell them about this bad experience. They should either set RPATH in their programs or should set LD_LIBRARY_PATH only in a start wrapper script. In a program that lets the user start other programs, RPATH should be preferred or LD_LIBRARY_PATH should be cleaned up for child processes. HS -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. From saadrustam at gmail.com Sat Jan 7 22:01:35 2017 From: saadrustam at gmail.com (Saad Khattak) Date: Sun, 08 Jan 2017 03:01:35 +0000 Subject: [CMake] target_link_libraries is using relative path of library Message-ID: Hello, This is a very strange behavior I am encountering. I am using CMake 3.7.1 with Visual Studio 2015. I have the following as part of a CMakeLists file: find_library(glfw_LIB_D glfw3_d ${glfw_LIBRARIES}) find_library(glfw_LIB glfw3 ${glfw_LIBRARIES}) When I do "message(STATUS ${glfw_LIB_D})" I get the full absolute path. However, when I add an executable that depends on the library: add_executable(vk_test src/vulkan_test.cpp ) target_link_libraries(vk_test ${glfw_LIB_D}) CMake puts the relative path when I look at my project's project properties: ..\install\glfw\lib\glfw_d.lib I also tried the following: target_link_libraries(vk_test "${CMAKE_SOURCE_DIR}/install/glfw/lib/glfw_d.lib") And it's still a relative path. Because of this issue, my project will not compile as Visual Studio is looking for the library in the incorrect folder. I even set the following, thinking that somehow relative paths got set: set(${CMAKE_USE_RELATIVE_PATHS} FALSE FORCE) I still got the same relative path. What is going on? -------------- next part -------------- An HTML attachment was scrubbed... URL: From saadrustam at gmail.com Sun Jan 8 01:22:09 2017 From: saadrustam at gmail.com (Saad Khattak) Date: Sun, 08 Jan 2017 06:22:09 +0000 Subject: [CMake] Find Vulkan on 32 bit builds Message-ID: Hello, When I run "find_package(VULKAN)" in a CMakeLists for a Visual Studio 2015 32-bit project, the ${Vulkan_LIBRARY} and ${Vulkan_LIBRARIES} variables both point to the "Bin" folder for the Vulkan installation instead of the "Bin32" folder. I looked at the FindVulkan.cmake module and even put MESSAGE(STATUS ...) on the "elseif(CMAKE_SIZEOF_VOID_P EQUAL 4)" to see if I made a mistake setting up. The message does indeed print confirming that my pointer size is 4 and thus the current toolchain selected is 32 bit. What's perplexing is that when I do a MESSAGE(STATUS ${Vulkan_LIBRARY}) the path is: D:/VulkanSDK/1.0.37.0/Bin/vulkan-1.lib instead of D:/VulkanSDK/1.0.37.0/Bin32/vulkan-1.lib It makes no sense. Line 47 of FindVulkan.cmake has Bin32. Why is CMake ignoring 32? -------------- next part -------------- An HTML attachment was scrubbed... URL: From bradbell at seanet.com Sun Jan 8 08:29:41 2017 From: bradbell at seanet.com (Brad Bell) Date: Sun, 8 Jan 2017 06:29:41 -0700 Subject: [CMake] PROJECT( LANGUAGES ) and m4 In-Reply-To: References: Message-ID: <3a098ba9-dddd-c07c-d38e-4c4e977814ec@seanet.com> Using a custom_command (not custom_target) and a looping over the output file names, I was able to get cmake to properly track the m4 output files and create them when necessary; see https://cmake.org/pipermail/cmake/2009-June/029909.html This seems to me like a good solution. On 01/06/2017 05:37 AM, Brad Bell wrote: > If one looks at the documentation > https://cmake.org/cmake/help/v3.0/command/project.html > one sees > project( [LANGUAGES] [...]) > and the following text: 'By default C and CXX are enabled if no > language options are given.' > > It there a list of available languages ? > > I have a project that has m4 input files. A single m4 input file can > be used to generate output in Perl, Octave, Python, or C++ language. > Can CMake handle this type of dependency, or would I have to use > custom targets in this case ? > > From Andreas-Naumann at gmx.net Sun Jan 8 08:35:26 2017 From: Andreas-Naumann at gmx.net (Andreas Naumann) Date: Sun, 8 Jan 2017 14:35:26 +0100 Subject: [CMake] target_link_libraries is using relative path of library In-Reply-To: References: Message-ID: <621f2fb8-0ee0-5daa-90f3-5ef3e6e9e3a3@gmx.net> Hello, on Linux cmake treats system directorys specially, i.e. those libraries are linked without any path. Furthermore there are environment variables, whose content is added to the set of system directories. I do not work on Windows, but your problem looks like a smiliar problem. Does some of the environment variables (except path) contain your directory? Hope that helps, Andreas Am 08.01.2017 um 04:01 schrieb Saad Khattak: > Hello, > > This is a very strange behavior I am encountering. I am using CMake > 3.7.1 with Visual Studio 2015. I have the following as part of a > CMakeLists file: > > find_library(glfw_LIB_D glfw3_d ${glfw_LIBRARIES}) > find_library(glfw_LIB glfw3 ${glfw_LIBRARIES}) > > When I do "message(STATUS ${glfw_LIB_D})" I get the full absolute > path. However, when I add an executable that depends on the library: > > add_executable(vk_test src/vulkan_test.cpp ) > target_link_libraries(vk_test ${glfw_LIB_D}) > > CMake puts the relative path when I look at my project's project > properties: > > ..\install\glfw\lib\glfw_d.lib > > I also tried the following: > > target_link_libraries(vk_test > "${CMAKE_SOURCE_DIR}/install/glfw/lib/glfw_d.lib") > > And it's still a relative path. Because of this issue, my project will > not compile as Visual Studio is looking for the library in the > incorrect folder. > > I even set the following, thinking that somehow relative paths got set: > > set(${CMAKE_USE_RELATIVE_PATHS} FALSE FORCE) > > I still got the same relative path. What is going on? > > From Andreas-Naumann at gmx.net Sun Jan 8 08:36:21 2017 From: Andreas-Naumann at gmx.net (Andreas Naumann) Date: Sun, 8 Jan 2017 14:36:21 +0100 Subject: [CMake] Find Vulkan on 32 bit builds In-Reply-To: References: Message-ID: Hello, Am 08.01.2017 um 07:22 schrieb Saad Khattak: > Hello, > > When I run "find_package(VULKAN)" in a CMakeLists for a Visual Studio > 2015 32-bit project, the ${Vulkan_LIBRARY} and ${Vulkan_LIBRARIES} > variables both point to the "Bin" folder for the Vulkan installation > instead of the "Bin32" folder. > > I looked at the FindVulkan.cmake module and even put MESSAGE(STATUS > ...) on the "elseif(CMAKE_SIZEOF_VOID_P EQUAL 4)" to see if I made a > mistake setting up. The message does indeed print confirming that my > pointer size is 4 and thus the current toolchain selected is 32 bit. > > What's perplexing is that when I do a MESSAGE(STATUS > ${Vulkan_LIBRARY}) the path is: > > > D:/VulkanSDK/1.0.37.0/Bin/vulkan-1.lib > > > instead of > > > D:/VulkanSDK/1.0.37.0/Bin32/vulkan-1.lib > > > > It makes no sense. Line 47 of FindVulkan.cmake has Bin32. Why is CMake > ignoring 32? > You should think the other way around: Why should cmake look in a special directory, when it finds a library with an appropriate name before this one? This decision should be in the corresponding FindVulkan.cmake, i.e. the corresponding find_library call should be constrained to ${VULKAN_DIR}/Bin32 in the 32bit case. > > Regards, Andreas From saadrustam at gmail.com Sun Jan 8 16:49:52 2017 From: saadrustam at gmail.com (Saad Khattak) Date: Sun, 08 Jan 2017 21:49:52 +0000 Subject: [CMake] ExternalProject_Add Message-ID: Hello, I have an external project glfw that I added to my project like this: ========== include(ExternalProject) ExternalProject_Add(glfw GIT_REPOSITORY "https://github.com/glfw/glfw.git" GIT_TAG "master" SOURCE_DIR "${CMAKE_SOURCE_DIR}/dep/glfw" CMAKE_ARGS -DGLFW_BUILD_DOCS=OFF -DGLFW_BUILD_TESTS=OFF -DGLFW_BUILD_EXAMPLES=OFF -DCMAKE_INSTALL_PREFIX=${CMAKE_SOURCE_DIR}/install/glfw/ -DCMAKE_DEBUG_POSTFIX=_d TEST_COMMAND "" ) set(GLFW_INCLUDE_DIR "${CMAKE_SOURCE_DIR}/install/glfw/include/") set(GLFW_LIBRARY_DIR "${CMAKE_SOURCE_DIR}/install/glfw/lib/") ========== Then I include it in my project like so: ========== find_library(GLFW_LIB_D glfw3_d ${GLFW_LIBRARY_DIR}) find_library(GLFW_LIB glfw3 ${GLFW_LIBRARY_DIR}) include_directories(${GLFW_INCLUDE_DIR}) add_executable(vk_test src/vulkan_test.cpp ) target_link_libraries(vk_test debug ${GLFW_LIB_D} optimized ${GLFW_LIB}) add_dependencies(vk_test glfw) ========== As you can see, I depend on the libraries compiled by the external project glfw. Unfortunately, when I first configure the project, CMake complains that it cannot find the libraries specified by ${GLFW_LIB_D} and ${GLFW_LIB} variables. Of course, this is because CMake did not begin cloning, configuring and building the glfw project. That only happens AFTER my project has been configured and starts building. This becomes a chicken and the egg problem. Currently, my solution is to add dummy .lib files so that I can at least configure and generate my project. My question is, am I approaching this problem in the wrong way? If yes, what is the correct way to add a dependency to an external project and have it clone/configure/build BEFORE the "find_library" call? -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicholas11braden at gmail.com Sun Jan 8 20:47:32 2017 From: nicholas11braden at gmail.com (Nicholas Braden) Date: Sun, 8 Jan 2017 19:47:32 -0600 Subject: [CMake] ExternalProject_Add In-Reply-To: References: Message-ID: The way to solve this is to use a superbuild project layout - you use ExternalProject_Add to build your dependencies AND your own project, using the DEPENDS option to control build order. Thus by the time it gets around to configuring your project, the dependencies have already been built and installed fully. On Sun, Jan 8, 2017 at 3:49 PM, Saad Khattak wrote: > Hello, > > I have an external project glfw that I added to my project like this: > > ========== > include(ExternalProject) > ExternalProject_Add(glfw > GIT_REPOSITORY "https://github.com/glfw/glfw.git" > GIT_TAG "master" > > SOURCE_DIR "${CMAKE_SOURCE_DIR}/dep/glfw" > CMAKE_ARGS -DGLFW_BUILD_DOCS=OFF -DGLFW_BUILD_TESTS=OFF > -DGLFW_BUILD_EXAMPLES=OFF -DCMAKE_INSTALL_PREFIX=${ > CMAKE_SOURCE_DIR}/install/glfw/ -DCMAKE_DEBUG_POSTFIX=_d > > TEST_COMMAND "" > ) > set(GLFW_INCLUDE_DIR "${CMAKE_SOURCE_DIR}/install/glfw/include/") > set(GLFW_LIBRARY_DIR "${CMAKE_SOURCE_DIR}/install/glfw/lib/") > ========== > > Then I include it in my project like so: > > ========== > find_library(GLFW_LIB_D glfw3_d ${GLFW_LIBRARY_DIR}) > find_library(GLFW_LIB glfw3 ${GLFW_LIBRARY_DIR}) > > include_directories(${GLFW_INCLUDE_DIR}) > > add_executable(vk_test > src/vulkan_test.cpp > ) > target_link_libraries(vk_test debug ${GLFW_LIB_D} optimized ${GLFW_LIB}) > add_dependencies(vk_test glfw) > ========== > > As you can see, I depend on the libraries compiled by the external project > glfw. Unfortunately, when I first configure the project, CMake complains > that it cannot find the libraries specified by ${GLFW_LIB_D} and > ${GLFW_LIB} variables. > > Of course, this is because CMake did not begin cloning, configuring and > building the glfw project. That only happens AFTER my project has been > configured and starts building. This becomes a chicken and the egg problem. > > Currently, my solution is to add dummy .lib files so that I can at least > configure and generate my project. My question is, am I approaching this > problem in the wrong way? If yes, what is the correct way to add a > dependency to an external project and have it clone/configure/build BEFORE > the "find_library" call? > > > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From post at hendrik-sattler.de Mon Jan 9 00:07:04 2017 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Mon, 09 Jan 2017 06:07:04 +0100 Subject: [CMake] ExternalProject_Add In-Reply-To: References: Message-ID: One possibility is the often mentioned superbuild, another is not using find_library() but setting the variables with the library file paths manually (that's static info anyway). Am 8. Januar 2017 22:49:52 MEZ schrieb Saad Khattak : >Hello, > >I have an external project glfw that I added to my project like this: > >========== >include(ExternalProject) >ExternalProject_Add(glfw > GIT_REPOSITORY "https://github.com/glfw/glfw.git" > GIT_TAG "master" > > SOURCE_DIR "${CMAKE_SOURCE_DIR}/dep/glfw" > CMAKE_ARGS -DGLFW_BUILD_DOCS=OFF -DGLFW_BUILD_TESTS=OFF >-DGLFW_BUILD_EXAMPLES=OFF >-DCMAKE_INSTALL_PREFIX=${CMAKE_SOURCE_DIR}/install/glfw/ >-DCMAKE_DEBUG_POSTFIX=_d > > TEST_COMMAND "" > ) >set(GLFW_INCLUDE_DIR "${CMAKE_SOURCE_DIR}/install/glfw/include/") >set(GLFW_LIBRARY_DIR "${CMAKE_SOURCE_DIR}/install/glfw/lib/") >========== > >Then I include it in my project like so: > >========== >find_library(GLFW_LIB_D glfw3_d ${GLFW_LIBRARY_DIR}) >find_library(GLFW_LIB glfw3 ${GLFW_LIBRARY_DIR}) > >include_directories(${GLFW_INCLUDE_DIR}) > >add_executable(vk_test > src/vulkan_test.cpp > ) >target_link_libraries(vk_test debug ${GLFW_LIB_D} optimized >${GLFW_LIB}) >add_dependencies(vk_test glfw) >========== > >As you can see, I depend on the libraries compiled by the external >project >glfw. Unfortunately, when I first configure the project, CMake >complains >that it cannot find the libraries specified by ${GLFW_LIB_D} and >${GLFW_LIB} variables. > >Of course, this is because CMake did not begin cloning, configuring and >building the glfw project. That only happens AFTER my project has been >configured and starts building. This becomes a chicken and the egg >problem. > >Currently, my solution is to add dummy .lib files so that I can at >least >configure and generate my project. My question is, am I approaching >this >problem in the wrong way? If yes, what is the correct way to add a >dependency to an external project and have it clone/configure/build >BEFORE >the "find_library" call? -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. From michael.stuermer at schaeffler.com Mon Jan 9 03:50:07 2017 From: michael.stuermer at schaeffler.com (Stuermer, Michael SP/HZA-ZSEP) Date: Mon, 9 Jan 2017 08:50:07 +0000 Subject: [CMake] Tracing ctest crash on windows In-Reply-To: References: Message-ID: <54a0eb2d02834c289814d95f25eedf24@DE013666.schaeffler.com> Hallo Aaron, if you?d like to have the full luxury of visual studio with test explorer and running/debugging tests directly as you can do it with other .NET based tests etc. you can try these extensions: - child process debugging power tools (https://marketplace.visualstudio.com/items?itemName=GreggMiskelly.MicrosoftChildProcessDebuggingPowerTool) - ctesttestadapter (https://github.com/micst/CTestTestAdapter/tree/master/dist) For debugging tests you need both extensions: the first for hooking on the process that is launched by ctest.exe, the second for actual ctest integration in visual studio. Compared to running your binary test-targets directly you will gain the advantage that you do not have to modify and debugging command line, you have all tests listed in a explorer windows with easy access and you get all verbose messages from ctest in the test explorer as well. The VSIX extension is a fork from https://github.com/toeb/CTestTestAdapter with some changes and bugfixes. It's not tested very well but I use it every day and it works for me. Do not use the "ctesttestadapter" you can find directly in visual studio, it does not work with latest cmake. CAUTION: If you use the cmaketools extension (http://cmaketools.codeplex.com) in Visual Studio, the link to the test location in the test explorer does not work (double clicking on a test will show some "could open file location" error). This does not break the test adapter, opening the CTestTestfile.cmake is just not possible from within Visual Studio. Michael From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Aaron Boxer Sent: Thursday, January 05, 2017 9:17 PM To: Bill Hoffman Cc: cmake Subject: Re: [CMake] Tracing ctest crash on windows Thanks, Bill and Jakob. I did what you suggested and found the problem Aaron On Thu, Jan 5, 2017 at 11:51 AM, Bill Hoffman > wrote: On 1/5/2017 9:32 AM, Jakob van Bethlehem wrote: CTest is not some magical tool that internally runs your test or something like that - instead CTest just fires up your test executable and does clever things with the output. In the same way you can just set your test project as startup-project, and debug it like any other executable. Sincerely, Jakob On Wed, Jan 4, 2017 at 2:43 PM, Aaron Boxer >> wrote: Hello, I am on windows, with visual studio 2015. Some of my ctest tests are crashing with exception. Is there a way of debugging these tests ? When I run in debug mode, I get an exception dialog, but can't drop into debugging environment. If you run ctest -VV it will show the full command line. Best way is to just run the same command in the debugger. -Bill -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Harry at codexdigital.com Mon Jan 9 06:54:37 2017 From: Harry at codexdigital.com (Harry Mallon) Date: Mon, 9 Jan 2017 11:54:37 +0000 Subject: [CMake] Up to date iOS instructions Message-ID: Hello, Are there any up to date instructions for doing iOS builds? There are load of tutorials going back many years on Google. I am using something based on this https://github.com/cristeab/ios-cmake as a toolchain file currently but I am seeing the ${EFFECTIVE_PLATFORM_NAME} generator expression problem mentioned here last year (https://cmake.org/pipermail/cmake/2016-March/063113.html). I have heard something about CMAKE_OSX_SYSROOT = iphoneos and maybe CMAKE_IOS_INSTALL_COMBINED? Yours, Harry Harry Mallon CODEX | Software Engineer 60 Poland Street | London | England | W1F 7NT E harry at codexdigital.com | T +44 203 7000 989 Website | Facebook | Twitter [http://codex.online/?action=asset&id=5B21DF7C-EC27-4199-852F-D596F5F28DA9] -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Mon Jan 9 09:36:49 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Mon, 9 Jan 2017 09:36:49 -0500 Subject: [CMake] How do static libraries get linked in Ninja? In-Reply-To: References: Message-ID: When I make an example project I see the following link line /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -Wl,-search_paths_first -Wl,-headerpad_max_install_names CMakeFiles/example.dir/test.cpp.o -o example liblib1.a liblib2.a && : Can you provide a short self contained example so I can try reproduce the problem? On Fri, Jan 6, 2017 at 2:12 PM, Robert Dailey wrote: > The latter. > > On Thu, Jan 5, 2017 at 3:39 PM, Robert Maynard > wrote: >> Do you mean you don't see where the static library is created or where >> the static library is listed on the link line for the dynamic library? >> >> On Thu, Jan 5, 2017 at 11:30 AM, Robert Dailey wrote: >>> I have two targets in CMake: a static library and a shared library. >>> The shared library specifies the static library as a target link >>> library. >>> >>> When I generate for Ninja, and I run: >>> >>> $ ninja -v >>> >>> During the link command for the shared library, I do not see the >>> static library specified to g++. I do see *.so files, but not *.a >>> files. Why are static libraries not showing up on the command line for >>> the link step? There must be some black magic happening that I'm not >>> seeing... >>> -- >>> >>> 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 From antoine.villeret at gmail.com Mon Jan 9 11:16:15 2017 From: antoine.villeret at gmail.com (Antoine Villeret) Date: Mon, 9 Jan 2017 17:16:15 +0100 Subject: [CMake] SET(ENV{PKG_CONFIG_SYSROOT_DIR} $FOO) doesn't work on the first run Message-ID: Hello everyone, in my toolchain file I have : SET(ENV{PKG_CONFIG_SYSROOT_DIR} "${RPI_ROOT_PATH}") then I run : cmake -DCMAKE_TOOLCHAIN_FILE=${PWD}/../of/dev/arm-linux-gnueabihf.cmake -DRPI_ROOT_PATH='/tmp/rpi/root' -DOF_PLATFORM=armv7 -G Ninja ../of Environnement variable PKG_CONFIG_SYSROOT_DIR should then be filled with ' /tmp/rpi/root' But that doesn't work. If I run `cmake` once again (with all of the arguments above), the environnement variable is correctly set. I mean : message(STATUS "PKG_CONFIG_SYSROOT_DIR: " $ENV{PKG_CONFIG_SYSROOT_DIR}) shows : PKG_CONFIG_SYSROOT_DIR: /tmp/rpi/root which is correct, but since `pkg-config` has been run without that defined on the first run, the include and library paths are not updated and build failed. Why SET method doesn't set the variable right on the first run ? If I use : SET(ENV{PKG_CONFIG_SYSROOT_DIR} "/tmp/rpi/root") everything works fine. Moreover a very minimal CMakeLists.txt and toolchain.cmake works fine (see : https://gist.github.com/avilleret/58ca1c9ba79cd203e16729ffe760ddc2). The original files are here : https://github.com/ofnode/of/blob/feature/rpiCrossCompiling/CMakeLists.txt and https://github.com/ofnode/of/blob/feature/rpiCrossCompiling/dev/arm-linux-gnueabihf.cmake And I'm using CMake 3.5.2. Where is my mistake ? Regards Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: From parag at ionicsecurity.com Mon Jan 9 12:00:47 2017 From: parag at ionicsecurity.com (Parag Chandra) Date: Mon, 9 Jan 2017 17:00:47 +0000 Subject: [CMake] [EXTERNAL]: Up to date iOS instructions In-Reply-To: References: Message-ID: Hi Harry, I?m not sure about any official instructions, but here?s how I?m doing it: # Adapted from https://code.google.com/p/ios-cmake/ # Standard settings set (CMAKE_SYSTEM_NAME Darwin) set (CMAKE_SYSTEM_VERSION 1) set (UNIX True) set (APPLE True) set (IOS True) # Required as of cmake 2.8.10 set (CMAKE_OSX_DEPLOYMENT_TARGET "" CACHE STRING "Force unset of the deployment target for iOS" FORCE) # Figure out where Xcode is installed execute_process (COMMAND "xcode-select" "--print-path" OUTPUT_VARIABLE CMAKE_XCODE_ROOT OUTPUT_STRIP_TRAILING_WHITESPACE) set (CMAKE_XCODE_ROOT ${CMAKE_XCODE_ROOT} CACHE PATH "Location of Xcode. Normally auto-detected via 'xcode-select', but can be overridden") # Skip the platform compiler checks for cross compiling set (CMAKE_CXX_COMPILER_WORKS TRUE) set (CMAKE_C_COMPILER_WORKS TRUE) # Setup iOS platform unless specified manually with DEVICE_OR_SIMULATOR if (NOT DEFINED DEVICE_OR_SIMULATOR) set (DEVICE_OR_SIMULATOR "OS") endif () set (DEVICE_OR_SIMULATOR ${DEVICE_OR_SIMULATOR} CACHE STRING "Set to 'Simulator' (for simulators), or 'OS' (for devices)") # Check the platform selection and setup for developer root if (NOT((${DEVICE_OR_SIMULATOR} STREQUAL "OS") OR (${DEVICE_OR_SIMULATOR} STREQUAL "Simulator"))) message (FATAL_ERROR "Unsupported DEVICE_OR_SIMULATOR value selected. Please choose 'OS' or 'Simulator'") endif () set (CMAKE_IOS_DEVELOPER_ROOT "${CMAKE_XCODE_ROOT}/Platforms/iPhone${DEVICE_OR_SIMULATOR}.platform/Developer") # Find and use the most recent iOS sdk unless specified manually with CMAKE_IOS_SDK_ROOT if (NOT DEFINED CMAKE_IOS_SDK_ROOT) file (GLOB _CMAKE_IOS_SDKS "${CMAKE_IOS_DEVELOPER_ROOT}/SDKs/*") if (_CMAKE_IOS_SDKS) list (SORT _CMAKE_IOS_SDKS) list (REVERSE _CMAKE_IOS_SDKS) list (GET _CMAKE_IOS_SDKS 0 CMAKE_IOS_SDK_ROOT) else () message (FATAL_ERROR "No iOS SDK's found in default search path ${CMAKE_IOS_DEVELOPER_ROOT}. Manually set CMAKE_IOS_SDK_ROOT or install the iOS SDK.") endif () message (STATUS "Toolchain using default iOS SDK: ${CMAKE_IOS_SDK_ROOT}") endif () set (CMAKE_IOS_SDK_ROOT ${CMAKE_IOS_SDK_ROOT} CACHE PATH "Location of the selected iOS SDK") set (CMAKE_XCODE_EFFECTIVE_PLATFORMS "-iphoneos;-iphonesimulator") # Set the sysroot default to the most recent SDK # If we're generating Xcode projects, the keyword "iphoneos" is all that's needed; otherwise # we need to specify the complete path if (${CMAKE_GENERATOR} STREQUAL "Xcode") set (CMAKE_OSX_SYSROOT "iphoneos") else () # set (CMAKE_OSX_SYSROOT ${CMAKE_IOS_SDK_ROOT} CACHE PATH "Sysroot used for iOS support") # Actually, just fail - we haven't yet done the work to support any generator except Xcode for iOS message (FATAL_ERROR "Only the Xcode generator is supported at this time. Be sure to specify '-GXcode' on the cmd line.") endif () # Set the find root to the iOS developer roots and to user defined paths set (CMAKE_FIND_ROOT_PATH "${CMAKE_XCODE_ROOT}/Toolchains/XcodeDefault.xctoolchain/usr/bin" ${CMAKE_IOS_DEVELOPER_ROOT} ${CMAKE_IOS_SDK_ROOT} ${CMAKE_PREFIX_PATH} CACHE string "iOS find search path root") # default to searching for frameworks first set (CMAKE_FIND_FRAMEWORK FIRST) # set up the default search directories for frameworks set (CMAKE_SYSTEM_FRAMEWORK_PATH ${CMAKE_IOS_SDK_ROOT}/System/Library/Frameworks ${CMAKE_IOS_SDK_ROOT}/System/Library/PrivateFrameworks ${CMAKE_IOS_SDK_ROOT}/Developer/Library/Frameworks ) Parag Chandra Technical Lead, Mobile Team Mobile: +1.919.824.1410 Ionic Security Inc. 1170 Peachtree St. NE STE 400, Atlanta, GA 30309 From: CMake on behalf of Harry Mallon Date: Monday, January 9, 2017 at 6:54 AM To: "cmake at cmake.org" Subject: [EXTERNAL]: [CMake] Up to date iOS instructions Hello, Are there any up to date instructions for doing iOS builds? There are load of tutorials going back many years on Google. I am using something based on this https://github.com/cristeab/ios-cmake as a toolchain file currently but I am seeing the ${EFFECTIVE_PLATFORM_NAME} generator expression problem mentioned here last year (https://cmake.org/pipermail/cmake/2016-March/063113.html). I have heard something about CMAKE_OSX_SYSROOT = iphoneos and maybe CMAKE_IOS_INSTALL_COMBINED? Yours, Harry Harry Mallon CODEX | Software Engineer 60 Poland Street | London | England | W1F 7NT E harry at codexdigital.com | T +44 203 7000 989 Website | Facebook | Twitter [http://codex.online/?action=asset&id=5B21DF7C-EC27-4199-852F-D596F5F28DA9] -------------- next part -------------- An HTML attachment was scrubbed... URL: From sstallion at gmail.com Mon Jan 9 12:59:40 2017 From: sstallion at gmail.com (Steven Stallion) Date: Mon, 9 Jan 2017 12:59:40 -0500 Subject: [CMake] Mixing CPack and ExternalProject Message-ID: All, I currently have a set of packages defined as ExternalProjects and packaged up with CPack. I've noticed recently that the preinstall step has begun failing for a given package and after a little digging, I've realized that I've likely been using CPack incorrectly for years. So, rather than poke around at a bespoke set of list files and trying to puzzle out how I can disable preinstall, I figured I'd ask a different question: What is the best method of generating a CPack package built from an ExternalProject (using autotools) such that the resulting package is only built once? TIA, Steve From dschepler at scalable-networks.com Mon Jan 9 13:08:58 2017 From: dschepler at scalable-networks.com (Daniel Schepler) Date: Mon, 9 Jan 2017 18:08:58 +0000 Subject: [CMake] CMake 3.7.1 gui fails to launch In-Reply-To: References: <20170106104127.Horde.ToRqoeADXuB1Sm-IHgshqtY@www.daryllee.com> <20170106124120.Horde.U3Sc0LaJ3q5phZjBC0a9wUR@www.daryllee.com> <20170106173700.Horde.n2B_DSl4jn8JfquoUtKwxWT@www.daryllee.com>, Message-ID: Another alternative, which is the one we use here, is to configure the custom Qt build with a "-qtlibinfix" flag - which produces libraries with completely different SONAMEs so there's no conflict. (We use this in conjunction with an RPATH.) One thing that could break is that some distributions set QT_PLUGIN_PATH for KDE logins which causes errors on trying to load incompatible plugins, so they might need to unset QT_PLUGIN_PATH in their wrapper script. -- Daniel ________________________________________ From: CMake [cmake-bounces at cmake.org] on behalf of Hendrik Sattler [post at hendrik-sattler.de] Sent: Saturday, January 07, 2017 12:11 AM To: cmake at cmake.org; daryl at daryllee.com; Alan W. Irwin Subject: Re: [CMake] CMake 3.7.1 gui fails to launch Am 6. Januar 2017 23:37:00 MEZ schrieb daryl at daryllee.com: >And the answer is... > >I recently installed an IDE from a not-to-be-named company that I do a > >lot of business with. The installation of that software places their >installation directory in LD_LIBRARY_PATH and guess what? their >installation contains a copy of libQtGui.so and libQtCore.so. The >"ldd" tip led me to that discovery. For now I have put >/usr/lib/x86_64-linux-gnu in front of their path in LD_LIBRARY_PATH >and cmake-gui V3.7.1 is working. I may have to come up with a more >permanent fix, but for now their stuff seems to work and CMake seems >to work, so I'm claiming victory. Maybe as a customer you should tell them about this bad experience. They should either set RPATH in their programs or should set LD_LIBRARY_PATH only in a start wrapper script. In a program that lets the user start other programs, RPATH should be preferred or LD_LIBRARY_PATH should be cleaned up for child processes. HS -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. -- 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 From rjh at sixdemonbag.org Tue Jan 10 03:02:44 2017 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 10 Jan 2017 03:02:44 -0500 Subject: [CMake] Bundling for OS X Message-ID: <632bff13-f519-bd9e-ed41-79d755ed07a6@sixdemonbag.org> (Full source is available at https://github.com/rjhansen/sherpa ) I have a Qt 5.7 application which I'm trying to migrate from qmake to cmake 3.7. So far it almost works on OS X, except when it comes to making a proper app bundle. The relevant contents of my CMakeLists.txt are as follows: ===== install(DIRECTORY "${QT_PLUGINS_DIR}/imageformats" DESTINATION ${plugin_dest_dir}/plugins COMPONENT Runtime) install(CODE " file(WRITE \"\${CMAKE_INSTALL_PREFIX}/${qtconf_dest_dir}/qt.conf\" \"\") " COMPONENT Runtime) set(DIRS ${QT_LIBRARY_DIRS}) install(CODE " file(GLOB_RECURSE QTPLUGINS \"\${CMAKE_INSTALL_PREFIX}/${plugin_dest_dir}/plugins/*${CMAKE_SHARED_LIBRARY_SUFFIX}\") include(BundleUtilities) fixup_bundle(\"${APPS}\" \"\${QTPLUGINS}\" \"${DIRS}\") " COMPONENT Runtime) # To Create a package, one can run "cpack -G DragNDrop CPackConfig.cmake" on Mac OS X # where CPackConfig.cmake is created by including CPack # And then there's ways to customize this as well set(CPACK_BINARY_DRAGNDROP ON) include(CPack) ===== Some of this was taken from CMake's example Qt4/OS X application, but Qt5 changed enough that the Qt4 example doesn't quite work. Although it creates an app bundle, the linkage points all over the map: ===== quorra:Sherpa rjh$ otool -L Sherpa.app/Contents/MacOS/Sherpa Sherpa.app/Contents/MacOS/Sherpa: @rpath/QtWidgets.framework/Versions/5/QtWidgets (compatibility version 5.7.0, current version 5.7.0) /usr/local/lib/libgpgme.11.dylib (compatibility version 29.0.0, current version 29.0.0) /usr/local/lib/libassuan.0.dylib (compatibility version 8.0.0, current version 8.3.0) /usr/local/opt/libgpg-error/lib/libgpg-error.0.dylib (compatibility version 22.0.0, current version 22.0.0) /usr/local/opt/minizip/lib/libminizip.1.dylib (compatibility version 2.0.0, current version 2.0.0) @rpath/QtGui.framework/Versions/5/QtGui (compatibility version 5.7.0, current version 5.7.0) @rpath/QtCore.framework/Versions/5/QtCore (compatibility version 5.7.0, current version 5.7.0) /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 307.4.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.0.0) ===== Qt comes with a tool, macdeployqt, which seems to mangle the app bundle beyond reason: ===== quorra:Sherpa rjh$ ~/Qt5.7.0/5.7/clang_64/bin/macdeployqt Sherpa.app quorra:Sherpa rjh$ open Sherpa.app LSOpenURLsWithRole() failed with error -10810 for the file /Users/rjh/Projects/Sherpa/Sherpa.app. ===== Although macdeployqt *appears* to copy and relink things correctly, invoking the binary directly yields the problem: "dyld: initializer function 0x1082cfbd5 not in mapped image for /usr/local/lib/libgpg-error.0.dylib" -- whatever that means. tl;dr -- How can I copy my libraries (GPGME_LIBRARY, ASSUAN_LIBRARY, GPGERR_LIBRARY, MINIZIP_LIBRARY, as well as QtWidgets, QtCore, and QtGui) into the bundle and run install_name_tool to correctly relink the application to the in-bundle libs? From cmake at anteru.net Tue Jan 10 10:38:14 2017 From: cmake at anteru.net (=?UTF-8?Q?Matth=c3=a4us_G._Chajdas?=) Date: Tue, 10 Jan 2017 16:38:14 +0100 Subject: [CMake] Find Vulkan on 32 bit builds In-Reply-To: References: Message-ID: Hi, the problem here is that the Vulkan SDK helpfully adds D:/VulkanSDK/1.0.37.0/Bin into PATH, while the Vulkan module dutifully searches Bin on x64 and Bin32 on x86. However, because /Bin is in the PATH, and because the libraries for both architectures are named the same, it will pick up the one from /Bin first (as the search order for find_library is system paths first, and PATHS/HINTS variable second). There's a couple of ways to fix this; for instance, on Windows I could use NO_DEFAULT_PATH on the find_library call and that would resolve the issue. The main reason why I haven't done this yet is because I think that's a packaging bug in the Vulkan SDK side which I was going to report there (I want to ask them to move the libraries into a lib/ subfolder, and ideally use different names for different architectures.) For now the easiest workaround is to remove the path to the Vulkan SDK from PATH; and I'll try to report this with the LunarG SDK and see how far I get there. If this doesn't work out, I'll guess I'll have to special-case the find_library call to ignore default paths on Windows & 32-bit only. If this is a blocker for you, please file an issue and I'll fix it on the CMake end before even starting the discussion with LunarG. Cheers, Matth?us Am 08.01.2017 um 14:36 schrieb Andreas Naumann: > Hello, > Am 08.01.2017 um 07:22 schrieb Saad Khattak: >> Hello, >> >> When I run "find_package(VULKAN)" in a CMakeLists for a Visual Studio >> 2015 32-bit project, the ${Vulkan_LIBRARY} and ${Vulkan_LIBRARIES} >> variables both point to the "Bin" folder for the Vulkan installation >> instead of the "Bin32" folder. >> >> I looked at the FindVulkan.cmake module and even put MESSAGE(STATUS >> ...) on the "elseif(CMAKE_SIZEOF_VOID_P EQUAL 4)" to see if I made a >> mistake setting up. The message does indeed print confirming that my >> pointer size is 4 and thus the current toolchain selected is 32 bit. >> >> What's perplexing is that when I do a MESSAGE(STATUS >> ${Vulkan_LIBRARY}) the path is: >> >> >> D:/VulkanSDK/1.0.37.0/Bin/vulkan-1.lib >> >> >> instead of >> >> >> D:/VulkanSDK/1.0.37.0/Bin32/vulkan-1.lib >> >> >> >> It makes no sense. Line 47 of FindVulkan.cmake has Bin32. Why is CMake >> ignoring 32? >> > You should think the other way around: Why should cmake look in a > special directory, when it finds a library with an appropriate name > before this one? > This decision should be in the corresponding FindVulkan.cmake, i.e. the > corresponding find_library call should be constrained to > ${VULKAN_DIR}/Bin32 in the 32bit case. >> >> > > Regards, > Andreas From saadrustam at gmail.com Tue Jan 10 11:11:07 2017 From: saadrustam at gmail.com (Saad Khattak) Date: Tue, 10 Jan 2017 16:11:07 +0000 Subject: [CMake] Find Vulkan on 32 bit builds In-Reply-To: References: Message-ID: That makes sense! Removing the variable from PATH does indeed fix the issue. It is not a blocking issue for me. I agree that this is a Vulkan packaging issue. However, since you are looking for $ENV{VULKAN_SDK} in the find module and assuming it exists, then it 'should' override the other path? I do see what you are saying in that this now becomes a special case just because Vulkan SDK didn't package the libs properly. Thanks Matth?us and Andreas for your help! On Tue, Jan 10, 2017 at 10:38 AM Matth?us G. Chajdas wrote: Hi, the problem here is that the Vulkan SDK helpfully adds D:/VulkanSDK/1.0.37.0/Bin into PATH, while the Vulkan module dutifully searches Bin on x64 and Bin32 on x86. However, because /Bin is in the PATH, and because the libraries for both architectures are named the same, it will pick up the one from /Bin first (as the search order for find_library is system paths first, and PATHS/HINTS variable second). There's a couple of ways to fix this; for instance, on Windows I could use NO_DEFAULT_PATH on the find_library call and that would resolve the issue. The main reason why I haven't done this yet is because I think that's a packaging bug in the Vulkan SDK side which I was going to report there (I want to ask them to move the libraries into a lib/ subfolder, and ideally use different names for different architectures.) For now the easiest workaround is to remove the path to the Vulkan SDK from PATH; and I'll try to report this with the LunarG SDK and see how far I get there. If this doesn't work out, I'll guess I'll have to special-case the find_library call to ignore default paths on Windows & 32-bit only. If this is a blocker for you, please file an issue and I'll fix it on the CMake end before even starting the discussion with LunarG. Cheers, Matth?us Am 08.01.2017 um 14:36 schrieb Andreas Naumann: > Hello, > Am 08.01.2017 um 07:22 schrieb Saad Khattak: >> Hello, >> >> When I run "find_package(VULKAN)" in a CMakeLists for a Visual Studio >> 2015 32-bit project, the ${Vulkan_LIBRARY} and ${Vulkan_LIBRARIES} >> variables both point to the "Bin" folder for the Vulkan installation >> instead of the "Bin32" folder. >> >> I looked at the FindVulkan.cmake module and even put MESSAGE(STATUS >> ...) on the "elseif(CMAKE_SIZEOF_VOID_P EQUAL 4)" to see if I made a >> mistake setting up. The message does indeed print confirming that my >> pointer size is 4 and thus the current toolchain selected is 32 bit. >> >> What's perplexing is that when I do a MESSAGE(STATUS >> ${Vulkan_LIBRARY}) the path is: >> >> >> D:/VulkanSDK/1.0.37.0/Bin/vulkan-1.lib >> >> >> instead of >> >> >> D:/VulkanSDK/1.0.37.0/Bin32/vulkan-1.lib >> >> >> >> It makes no sense. Line 47 of FindVulkan.cmake has Bin32. Why is CMake >> ignoring 32? >> > You should think the other way around: Why should cmake look in a > special directory, when it finds a library with an appropriate name > before this one? > This decision should be in the corresponding FindVulkan.cmake, i.e. the > corresponding find_library call should be constrained to > ${VULKAN_DIR}/Bin32 in the 32bit case. >> >> > > Regards, > Andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: From eike at sf-mail.de Tue Jan 10 11:17:12 2017 From: eike at sf-mail.de (Rolf Eike Beer) Date: Tue, 10 Jan 2017 17:17:12 +0100 Subject: [CMake] Find Vulkan on 32 bit builds In-Reply-To: References: Message-ID: > There's a couple of ways to fix this; for instance, on Windows I could > use NO_DEFAULT_PATH on the find_library call and that would resolve the > issue. The main reason why I haven't done this yet is because I think > that's a packaging bug in the Vulkan SDK side which I was going to > report there (I want to ask them to move the libraries into a lib/ > subfolder, and ideally use different names for different > architectures.) Ideally they would just provide CMake config files then? Eike -- From dev at irieger.net Tue Jan 10 13:30:11 2017 From: dev at irieger.net (dev at irieger.net) Date: Tue, 10 Jan 2017 19:30:11 +0100 Subject: [CMake] Problems building a MODULE library (OpenFX plugin) with correct cuda object linking Message-ID: Hello, after hours and hours of searching and trying to get it to work I hope someone here can help me as I'm now out of ideas. I'm trying to build an OpenFX plugin for DaVinci Resolve (a movie color grading software, https://www.blackmagicdesign.com/products) via CMake. Resolve is delivered with a developer sample plugin using a standard Makefile (Mac) and project files for Apple XCode/VisualStudio. But for a better structure I wanted to build a CMake build framework for this plugin. Notes for better understanding: The CUDA implementation is a proprietary Add On to the OpenSource OpenFX interfaces as far as I understand it. Stock OpenFX would pass memory references only to host memory address space while the Resolve extension passed CUDA/OpenCL addresses to reduce memory transfer overhead for better real time processing. OpenFX plugins are build as bundles of objects(?) (MODULE library build in CMake). The basic structure is a plugin that offers processing with CPU, OpenCL or CUDA depending on the processing mode the host application is using. This plugin is bundled into a single module library which is loaded by Resolve. For the plugin a few helper classes are used to handle the Plugin metadata (user interface, host communication) while CUDA/OpenCL control code is also seperated into two separate files (OpenCLKernel.cpp and CudaKernel.cu). Both contain the GPU Kernel itselt and a host function which is included in the main Plugin just via extern declaration. Sample: > extern void RunCudaKernel(int p_Width, int p_Height, float* p_Gain, > const float* p_Input, float* p_Output); The Makefile then just compiles all cpp files with the standard $(CXX) compiler and the CudaKernel.cu with $(NVCC) which is defined before. Then a simple > $(CXX) -bundle $^ -o $@ -L${CUDAPATH}/lib -lcuda -lcudart > -F/Library/Frameworks -framework CUDA -framework OpenCL does the linking and works fine. I tried to replicate this structure of linking in CMake and it works as long as I keep CUDA deactivated (One of the reasons of building a flexible CMake infrastructure is making a few parts configurable via CMake/Compiler options). Most stuff is working now, but I have a problem integrating the CUDA part. For OpenCL I just build an object library from the OpenCLKernel.cpp and add it as a target object: > add_library(GainLibOpenCL OBJECT OpenCLKernel.cpp) ... > add_library(${PLUGIN_NAME} MODULE src/${PLUGIN_NAME}.cpp > $) I tried to replicate this for the CUDA code but cuda_add_library doesn't seem to support generating object files and a combination of cuda_compile + add_library also doesn't allow to generate object files so how do I replicate the Makefile result. Here are two examples how I tried different methods. Did a few more tests based on many results of questions on the net but non solved my problem. Variant 1: > cuda_add_library(GainLibCUDA CudaKernel.cu) > set(LIBS ${LIBS} GainLibCUDA PARENT_SCOPE) Will compile but result in a crash of Resolve, with STATIC as an option for cuda_add_library it builds and Resolve stays open, but processing isn't working. And it links to the CUDA static libraries which isn't intended as the host cuda lib should be used. > cuda_compile(cuda_exec_obj CudaKernel.cu) > add_library(GainLibCUDA OBJECT CudaKernel.h ${cuda_exec_obj}) > set(TARGET_OBJECTS ${TARGET_OBJECTS} $ > PARENT_SCOPE) Results in the error: > CMake Error at src/CUDA/CMakeLists.txt:21 (add_library): > OBJECT library "GainLibCUDA" contains: > > cuda_compile_1_generated_CudaKernel.cu.o > > but may contain only sources that compile, header files, and other > files > that would not affect linking of a normal library. Also just adding "cuda_compile(cuda_exec_obj CudaKernel.cu)" and then ${cuda_exec_obj} as a file to the "add_library(${PLUGIN_NAME} MODULE ..." line results in and error: "Cannot find source file". So this mail got pretty long but I hope this helps someone to help me and then also help others if they reach a similar problem. Kind regards, Ingmar From ghisvail at gmail.com Tue Jan 10 13:52:30 2017 From: ghisvail at gmail.com (Ghislain Vaillant) Date: Tue, 10 Jan 2017 18:52:30 +0000 Subject: [CMake] Platform-independent config package Message-ID: Dear all, I am currently hit by an issue with the CMake detection of a header-only library [1]. The library is built on a 64-bit machine and packaged for all other architectures supported by Debian. However, CMake detection fails on 32-bit platforms with the following error: ``` Any attempt to call `find_package(glm REQUIRED)` produces the following error: ``` Could not find a configuration file for package "glm" that is compatible with requested version "". The following configuration files were considered but not accepted: /usr/lib/cmake/glm/glmConfig.cmake, version: 0.9.8 (64bit) ``` How can this be effectively solved? Can the bit-ness detection be dropped somehow? It should not be needed for a header-only target. Cheers, Ghis [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850277 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggarra13 at gmail.com Tue Jan 10 14:08:49 2017 From: ggarra13 at gmail.com (=?UTF-8?Q?Gonzalo_Garramu=c3=b1o?=) Date: Tue, 10 Jan 2017 16:08:49 -0300 Subject: [CMake] Chocolatey? (Windows) Message-ID: <276e2716-c7b2-3b4b-b59b-9c897b625bee@gmail.com> I was wondering if anyone was familiar with Chocolatey and whether there are plans to add support for it in cmake/cpack. For those that don't know, Chocolatey is a small Windows' utility similar to Debian's apt-get. It allows simple management of packages (binaries mainly). From Andreas-Naumann at gmx.net Tue Jan 10 15:10:17 2017 From: Andreas-Naumann at gmx.net (Andreas Naumann) Date: Tue, 10 Jan 2017 21:10:17 +0100 Subject: [CMake] Platform-independent config package In-Reply-To: References: Message-ID: Dear Ghis, the easiest long-term fix would be an own glmConfig.cmake file. The command write_basic_package_version_file uses a template with those pointer checks. The glm-developers could simply copy the template to their source directory, remove the unneeded lines and run the configure_file command themself on the changed template. The short solution for debian would be a patch file,which just uncomments the last 5 lines. Regards, Andreas Am 10.01.2017 um 19:52 schrieb Ghislain Vaillant: > Dear all, > > I am currently hit by an issue with the CMake detection of a > header-only library [1]. The library is built on a 64-bit machine and > packaged for all other architectures supported by Debian. > > However, CMake detection fails on 32-bit platforms with the following > error: > > ``` > Any attempt to call `find_package(glm REQUIRED)` produces the following > error: > > ``` > Could not find a configuration file for package "glm" that is > compatible with requested version "". > > The following configuration files were considered but not accepted: > > /usr/lib/cmake/glm/glmConfig.cmake, version: 0.9.8 (64bit) > ``` > > How can this be effectively solved? Can the bit-ness detection be > dropped somehow? It should not be needed for a header-only target. > > Cheers, > Ghis > > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850277 > > From ggarra13 at gmail.com Tue Jan 10 15:34:57 2017 From: ggarra13 at gmail.com (=?UTF-8?Q?Gonzalo_Garramu=c3=b1o?=) Date: Tue, 10 Jan 2017 17:34:57 -0300 Subject: [CMake] Custom command on cpack target Message-ID: <99832f4e-241a-68a8-f99b-05bfc52ada60@gmail.com> I would like to run a custom command on the zip file generated by cpack. The idea is that I want to calculate its sha256 checksum. Unfortunately it seems the zip file cannot be a target in a CMakeLists.txt file or I'm doing something wrong. Can someone give me a hand? -- Gonzalo Garramu?o From sergiu.dotenco at gmail.com Tue Jan 10 17:53:03 2017 From: sergiu.dotenco at gmail.com (Sergiu Deitsch) Date: Tue, 10 Jan 2017 23:53:03 +0100 Subject: [CMake] Platform-independent config package In-Reply-To: References: Message-ID: You can temporarily unset CMAKE_SIZEOF_VOID_P before calling write_basic_package_version_file. See for instance https://bitbucket.org/eigen/eigen/src/ff6170e75ab07d74d8f7dd21af777a94799d168d/CMakeLists.txt?at=3.3&fileviewer=file-view-default#CMakeLists.txt-541:545 . On Tue, Jan 10, 2017 at 7:52 PM, Ghislain Vaillant wrote: > Dear all, > > I am currently hit by an issue with the CMake detection of a header-only > library [1]. The library is built on a 64-bit machine and packaged for all > other architectures supported by Debian. > > However, CMake detection fails on 32-bit platforms with the following > error: > > ``` > Any attempt to call `find_package(glm REQUIRED)` produces the following > error: > > ``` > Could not find a configuration file for package "glm" that is > compatible with requested version "". > > The following configuration files were considered but not accepted: > > /usr/lib/cmake/glm/glmConfig.cmake, version: 0.9.8 (64bit) > ``` > > How can this be effectively solved? Can the bit-ness detection be dropped > somehow? It should not be needed for a header-only target. > > Cheers, > Ghis > > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850277 > > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From greenc at fnal.gov Tue Jan 10 18:30:15 2017 From: greenc at fnal.gov (Chris Green) Date: Tue, 10 Jan 2017 17:30:15 -0600 Subject: [CMake] Add CXX dependency generation to custom command for Ninja? Message-ID: <8e5a434e-1d17-138c-e16a-3ec232c86859@fnal.gov> Hi, We have a custom command for a third-party utility (genreflex, from the ROOT system) which has a directive: IMPLICIT_DEPENDS CXX ${CMAKE_CURRENT_SOURCE_DIR}/classes.h How would I, either as an extra COMMAND or as a separate custom command, manually invoke the configured CXX compiler with all the correctly-configured include directories and other pre-processor and compiler flags with the expected option (-MMD for GCC, I think) on the above-mentioned classes.h file so that the resulting file can be used in a DEPFILE directive for the Ninja generator? I would like to model as closely as possible exactly what CMake would specify to invoke the compiler to (e.g.) compile an object with only the necessary changes, but I'm not sure whence to obtain this information. I'm assuming it's some combination of automatic variables and properties via generator expressions, but I'm at a loss, I'm afraid. I also don't know whether I would need to specify the .d file as an OUTPUT or a BYPRODUCTS if I do this as a COMMAND, or in DEPENDS in addition to DEPFILE if a separate custom command, and which choice would be better (assuming both of them work). The resulting CMake code would need to conditionally support both Makefile and Ninja generators. Any advice gratefully accepted. Current custom command definition: add_custom_command( OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/${dictname}_dict.cpp ${SOURCE_OUTPUT} ${GD_ROOTMAP_OUTPUT} ${PCM_OUTPUT} COMMAND ${ROOT_GENREFLEX} ${CMAKE_CURRENT_SOURCE_DIR}/classes.h -s ${CMAKE_CURRENT_SOURCE_DIR}/classes_def.xml -I${CMAKE_SOURCE_DIR} ${GENREFLEX_INCLUDES} ${GENREFLEX_FLAGS} -o ${dictname}_dict.cpp ${CLEANUP_COMMAND} IMPLICIT_DEPENDS CXX ${CMAKE_CURRENT_SOURCE_DIR}/classes.h DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/classes_def.xml COMMENT "Generating dictionary files for target ${dictname}" ) Many thanks, Chris. -- Chris Green , FNAL CS/SCD/ADSS/SSI/TAC; 'phone (630) 840-2167; Skype: chris.h.green; IM: greenc at jabber.fnal.gov, chissgreen (AIM), chris.h.green (Google Talk). From gjasny at googlemail.com Wed Jan 11 08:33:26 2017 From: gjasny at googlemail.com (Gregor Jasny) Date: Wed, 11 Jan 2017 14:33:26 +0100 Subject: [CMake] MSVC15 variable available for Visual Studio 2017 Message-ID: <2ce55b7b-77b2-91e2-a4d0-3d978d74129d@googlemail.com> Hello, I wonder if there is a reason why no MSVC15 variable is available for Visual Studio 2017? I'm using those MSVCxx variables and CMAKE_GENERATOR_TOOLSET to detect the active toolset: > # Visual Studio 2008 > if((MSVC90 AND "${CMAKE_GENERATOR_TOOLSET}" STREQUAL "") OR (CMAKE_GENERATOR_TOOLSET MATCHES "v90")) > set(COL_BUILD_TOOLCHAIN) > elseif((MSVC11 AND "${CMAKE_GENERATOR_TOOLSET}" STREQUAL "") OR (CMAKE_GENERATOR_TOOLSET MATCHES "^v110.*")) > set(COL_BUILD_TOOLCHAIN _v110) > elseif((MSVC12 AND "${CMAKE_GENERATOR_TOOLSET}" STREQUAL "") OR (CMAKE_GENERATOR_TOOLSET MATCHES "^v120.*")) > set(COL_BUILD_TOOLCHAIN _v120) > elseif((MSVC14 AND "${CMAKE_GENERATOR_TOOLSET}" STREQUAL "") OR (CMAKE_GENERATOR_TOOLSET MATCHES "^v140.*")) > set(COL_BUILD_TOOLCHAIN _v140) > else() > message(FATAL_ERROR "Unknown Visual Studio version (${MSVC_VERSION}) or generator toolset (${CMAKE_GENERATOR_TOOLSET})") > endif() If I now select the Visual Studio 2017 compiler but omit the toolset on the command line, the CMAKE_GENERATOR_TOOLSET is empty and MSVC15 is not set. I wonder how I could detect the v141(_xp) toolset? Thanks, Gregor From brad.king at kitware.com Wed Jan 11 10:20:35 2017 From: brad.king at kitware.com (Brad King) Date: Wed, 11 Jan 2017 10:20:35 -0500 Subject: [CMake] MSVC15 variable available for Visual Studio 2017 In-Reply-To: <2ce55b7b-77b2-91e2-a4d0-3d978d74129d@googlemail.com> References: <2ce55b7b-77b2-91e2-a4d0-3d978d74129d@googlemail.com> Message-ID: <8bb866dc-4292-2423-4dc8-ac6714c1873d@kitware.com> On 01/11/2017 08:33 AM, Gregor Jasny via CMake wrote: > I wonder if there is a reason why no MSVC15 variable is available for > Visual Studio 2017? The values correspond to the toolset versions: * https://cmake.org/cmake/help/v3.7/variable/MSVC14.html and VS 2017 uses toolset version v141 which is still "14". At the time the VS 2017 generator was first written we were using a VS 15 preview and its toolset was still called v140. Please submit a MR to update the above-linked docs to mention that MSVC14 is for v140 or v141. > I wonder how I could detect the v141(_xp) toolset? Use CMAKE_C_COMPILER_VERSION instead. The `MSVC##` variables are legacy, though not deprecated because they can still be handy due to the "or another compiler that simulates it" part of the documentation. -Brad From acrespodelavina at gmail.com Wed Jan 11 10:32:19 2017 From: acrespodelavina at gmail.com (Arturo Crespo) Date: Wed, 11 Jan 2017 15:32:19 +0000 Subject: [CMake] Response files not working with TI compilers Message-ID: Dear All, I'm currently using CMake-3.7.1 to build a big project with different TI compilers (cl6x, armcl, cl-arp32) and since several months ago I started to use linker response files because the linker command line was too long for Windows and the build was failing. When I tried to do this for the first time I got a linker error with an invalid flag being used, as the TI linker doesn't support response files (-@) The way CMake invokes the TI linker is as mentioned in the TI documentation by invoking the compiler with an option to run the linker, i.e. cl6x --run_linker [options] filename1, ..., filenameN, in TI-CXX.cmake: set(CMAKE_CXX_LINK_EXECUTABLE " --run_linker --output_file= --map_file=.map ") The solution that I found was to change the order of the arguments passed to the linker, because the TI compiler supports response files (-@) and it passes that information to the linker, so by moving before --run_linker the problem was solved: set(CMAKE_CXX_LINK_EXECUTABLE " --run_linker --output_file= --map_file=.map ") The same change is needed in TI-C.cmake This issue is present since at least since CMake-3.3.2 Regards, Arturo -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Wed Jan 11 15:42:42 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 11 Jan 2017 15:42:42 -0500 Subject: [CMake] Problems building a MODULE library (OpenFX plugin) with correct cuda object linking In-Reply-To: References: Message-ID: I believe you will want to use the low level command CUDA_WRAP_SRCS with the MODULE option. Since CUDA_WRAP_SRCS is a low level command, If you need separable compilation you will need to manually invoke those steps too ( read CUDA_SEPARABLE_COMPILATION documentation on what methods you will need to use ). On Tue, Jan 10, 2017 at 1:30 PM, wrote: > Hello, > > after hours and hours of searching and trying to get it to work I hope > someone here can help me as I'm now out of ideas. I'm trying to build an > OpenFX plugin for DaVinci Resolve (a movie color grading software, > https://www.blackmagicdesign.com/products) via CMake. Resolve is delivered > with a developer sample plugin using a standard Makefile (Mac) and project > files for Apple XCode/VisualStudio. But for a better structure I wanted to > build a CMake build framework for this plugin. > > Notes for better understanding: The CUDA implementation is a proprietary Add > On to the OpenSource OpenFX interfaces as far as I understand it. Stock > OpenFX would pass memory references only to host memory address space while > the Resolve extension passed CUDA/OpenCL addresses to reduce memory transfer > overhead for better real time processing. OpenFX plugins are build as > bundles of objects(?) (MODULE library build in CMake). > > The basic structure is a plugin that offers processing with CPU, OpenCL or > CUDA depending on the processing mode the host application is using. This > plugin is bundled into a single module library which is loaded by Resolve. > For the plugin a few helper classes are used to handle the Plugin metadata > (user interface, host communication) while CUDA/OpenCL control code is also > seperated into two separate files (OpenCLKernel.cpp and CudaKernel.cu). Both > contain the GPU Kernel itselt and a host function which is included in the > main Plugin just via extern declaration. Sample: >> >> extern void RunCudaKernel(int p_Width, int p_Height, float* p_Gain, const >> float* p_Input, float* p_Output); > > > The Makefile then just compiles all cpp files with the standard $(CXX) > compiler and the CudaKernel.cu with $(NVCC) which is defined before. Then a > simple >> >> $(CXX) -bundle $^ -o $@ -L${CUDAPATH}/lib -lcuda -lcudart >> -F/Library/Frameworks -framework CUDA -framework OpenCL > > does the linking and works fine. > > > I tried to replicate this structure of linking in CMake and it works as long > as I keep CUDA deactivated (One of the reasons of building a flexible CMake > infrastructure is making a few parts configurable via CMake/Compiler > options). Most stuff is working now, but I have a problem integrating the > CUDA part. > > For OpenCL I just build an object library from the OpenCLKernel.cpp and add > it as a target object: >> >> add_library(GainLibOpenCL OBJECT OpenCLKernel.cpp) > > ... >> >> add_library(${PLUGIN_NAME} MODULE src/${PLUGIN_NAME}.cpp >> $) > > > I tried to replicate this for the CUDA code but cuda_add_library doesn't > seem to support generating object files and a combination of cuda_compile + > add_library also doesn't allow to generate object files so how do I > replicate the Makefile result. > > Here are two examples how I tried different methods. Did a few more tests > based on many results of questions on the net but non solved my problem. > > Variant 1: >> >> cuda_add_library(GainLibCUDA CudaKernel.cu) >> set(LIBS ${LIBS} GainLibCUDA PARENT_SCOPE) > > Will compile but result in a crash of Resolve, with STATIC as an option for > cuda_add_library it builds and Resolve stays open, but processing isn't > working. And it links to the CUDA static libraries which isn't intended as > the host cuda lib should be used. > >> cuda_compile(cuda_exec_obj CudaKernel.cu) >> add_library(GainLibCUDA OBJECT CudaKernel.h ${cuda_exec_obj}) >> set(TARGET_OBJECTS ${TARGET_OBJECTS} $ >> PARENT_SCOPE) > > > Results in the error: >> >> CMake Error at src/CUDA/CMakeLists.txt:21 (add_library): >> OBJECT library "GainLibCUDA" contains: >> >> cuda_compile_1_generated_CudaKernel.cu.o >> >> but may contain only sources that compile, header files, and other files >> that would not affect linking of a normal library. > > > Also just adding "cuda_compile(cuda_exec_obj CudaKernel.cu)" and then > ${cuda_exec_obj} as a file to the "add_library(${PLUGIN_NAME} MODULE ..." > line results in and error: "Cannot find source file". > > So this mail got pretty long but I hope this helps someone to help me and > then also help others if they reach a similar problem. > > > Kind regards, > Ingmar > -- > > 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 From paul at mad-scientist.net Thu Jan 12 00:49:36 2017 From: paul at mad-scientist.net (Paul Smith) Date: Thu, 12 Jan 2017 00:49:36 -0500 Subject: [CMake] Linker flags on all except a couple of programs Message-ID: <1484200176.10997.45.camel@mad-scientist.net> I have a CMake-based build that creates about 170 binaries (most of them are individual unit test programs). I have set the CMAKE_EXE_LINKER_FLAGS to a set of flags I wanted on all the binaries. Now it turns out that I need to remove, or not set, one specific flag on a small number (like 5) of these binaries, but I still want it set on all the others. Unfortunately for this flag there's no "turn it off" extra flag I can add to the end of the list of flags: I have to actually remove the flag itself. What's the cleanest/simplest way to accomplish this? I don't really want to modify my cmake files to add an explicit set_target_property() to all 165 binaries that I _do_ want to have this flag set on, just so I can avoid calling it on the 5 binaries I don't. I want to add something particular to the 5 "oddball" binaries, instead, to override these values. But I can't seem to come up with a way to remove a flag from a global list like this, just for one (or a few) targets. Any hints? From bitminer at gmail.com Thu Jan 12 02:13:18 2017 From: bitminer at gmail.com (Brian J. Davis) Date: Thu, 12 Jan 2017 01:13:18 -0600 Subject: [CMake] ExternalProject_Add and include_external_msproject dynamic duo... but what if their powers combined? Message-ID: Every time I create a superbuild using ExternalProject_Add sooner or later a project will not support cmake, but will have buried within its bowels a visual studio solution project .sln and sometimes gobs of .vcxproj files (read CPython). Now ofcourse include_external_msproject can do this. If only these two wonder twins (https://en.wikipedia.org/wiki/Wonder_Twins) could work together in the same ExternalProject_Add command. Maybe by adding after HG_TAG say VCX_PROJS or some such. Only thing better would be getting original project maintainer to support CMake. So feature request: Can we get ExternalProject_Add to support visual studio project files? From parag at ionicsecurity.com Thu Jan 12 10:41:21 2017 From: parag at ionicsecurity.com (Parag Chandra) Date: Thu, 12 Jan 2017 15:41:21 +0000 Subject: [CMake] [EXTERNAL]: Linker flags on all except a couple of programs In-Reply-To: <1484200176.10997.45.camel@mad-scientist.net> References: <1484200176.10997.45.camel@mad-scientist.net> Message-ID: <61025F7B-04F5-4899-94CB-873F875D747D@ionic.com> Have you tried the various string commands? https://cmake.org/cmake/help/v3.7/command/string.html I?ve done something similar to replace default linker flags with ones of my own choosing. I bet you could use something like string(REGEX REPLACE ?) to essentially remove the unwanted linker flags in each of the 5 projects that needs it. You might even be able to do this once, in a separate .cmake file, as either a function or macro, and then simply include() that .cmake file in each of the 5 projects for better maintenance. Parag Chandra Technical Lead, Mobile Team Mobile: +1.919.824.1410 Ionic Security Inc. 1170 Peachtree St. NE STE 400, Atlanta, GA 30309 On 1/12/17, 12:49 AM, "CMake on behalf of Paul Smith" wrote: I have a CMake-based build that creates about 170 binaries (most of them are individual unit test programs). I have set the CMAKE_EXE_LINKER_FLAGS to a set of flags I wanted on all the binaries. Now it turns out that I need to remove, or not set, one specific flag on a small number (like 5) of these binaries, but I still want it set on all the others. Unfortunately for this flag there's no "turn it off" extra flag I can add to the end of the list of flags: I have to actually remove the flag itself. What's the cleanest/simplest way to accomplish this? I don't really want to modify my cmake files to add an explicit set_target_property() to all 165 binaries that I _do_ want to have this flag set on, just so I can avoid calling it on the 5 binaries I don't. I want to add something particular to the 5 "oddball" binaries, instead, to override these values. But I can't seem to come up with a way to remove a flag from a global list like this, just for one (or a few) targets. Any hints? -- 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 From matthew.woehlke at kitware.com Thu Jan 12 12:27:18 2017 From: matthew.woehlke at kitware.com (Matthew Woehlke) Date: Thu, 12 Jan 2017 12:27:18 -0500 Subject: [CMake] Linker flags on all except a couple of programs In-Reply-To: <1484200176.10997.45.camel@mad-scientist.net> References: <1484200176.10997.45.camel@mad-scientist.net> Message-ID: <5877BC76.3010203@kitware.com> On 2017-01-12 00:49, Paul Smith wrote: > I have a CMake-based build that creates about 170 binaries (most of them > are individual unit test programs). > > I have set the CMAKE_EXE_LINKER_FLAGS to a set of flags I wanted on all > the binaries. > > Now it turns out that I need to remove, or not set, one specific flag on > a small number (like 5) of these binaries, but I still want it set on > all the others. Unfortunately for this flag there's no "turn it off" > extra flag I can add to the end of the list of flags: I have to actually > remove the flag itself. > > What's the cleanest/simplest way to accomplish this? I don't really > want to modify my cmake files to add an explicit set_target_property() > to all 165 binaries that I _do_ want to have this flag set on, just so I > can avoid calling it on the 5 binaries I don't. I want to add something > particular to the 5 "oddball" binaries, instead, to override these > values. > > But I can't seem to come up with a way to remove a flag from a global > list like this, just for one (or a few) targets. I *thought* (but have not checked) that after the target exists, you can get its link flags as a target property, which you could then adjust as needed. Failing that, I think you can remove the flag from the appropriate global variable, create the target (add_executabe or whatever), then restore the previous value. If you wrap this in a function, it will scope the value so you don't even have to worry about restoring it after. Of course, you could also just wrap all your add_executable calls in a function that handles the set_target_property dance for you... Hope this helps! -- Matthew From dev at irieger.net Thu Jan 12 17:04:48 2017 From: dev at irieger.net (Ingmar Rieger) Date: Thu, 12 Jan 2017 23:04:48 +0100 Subject: [CMake] Problems building a MODULE library (OpenFX plugin) with correct cuda object linking In-Reply-To: References: Message-ID: <84c16971f34da13ddd4dda367306ec57@irieger.net> Hey, thank you for your answer. I already tried with CUDA_WRAP_SRCS but didn't really get how to use it and the https://cmake.org/cmake/help/v3.7/module/FindCUDA.html lacks of any samples really showing what is going on. How can I use CUDA_WRAP_SRCS to create the OBJECT and then add it to a library? add_library also only supports source files (Cannot find source file error when trying to add an object). Is there an example anywhere that demonstrates how to manually add a CUDA object there? On 2017-01-11 21:42, Robert Maynard wrote: > I believe you will want to use the low level command CUDA_WRAP_SRCS > with the MODULE option. Since CUDA_WRAP_SRCS is a low level command, > If you need separable compilation you will need to manually invoke > those steps too ( read CUDA_SEPARABLE_COMPILATION documentation on > what methods you will need to use ). -- Regards, Ingmar From robert.maynard at kitware.com Thu Jan 12 17:15:43 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 12 Jan 2017 17:15:43 -0500 Subject: [CMake] Problems building a MODULE library (OpenFX plugin) with correct cuda object linking In-Reply-To: <84c16971f34da13ddd4dda367306ec57@irieger.net> References: <84c16971f34da13ddd4dda367306ec57@irieger.net> Message-ID: Hi, Here is a example that uses CUDA_WRAP_SRCS and separable compilation. I quickly ported the code from a project, so it most likely has some minor issues. https://git.io/vMga3 On Thu, Jan 12, 2017 at 5:04 PM, Ingmar Rieger wrote: > Hey, > > thank you for your answer. I already tried with CUDA_WRAP_SRCS but didn't > really get how to use it and the > https://cmake.org/cmake/help/v3.7/module/FindCUDA.html lacks of any samples > really showing what is going on. How can I use CUDA_WRAP_SRCS to create the > OBJECT and then add it to a library? add_library also only supports source > files (Cannot find source file error when trying to add an object). > > Is there an example anywhere that demonstrates how to manually add a CUDA > object there? > > > On 2017-01-11 21:42, Robert Maynard wrote: >> >> I believe you will want to use the low level command CUDA_WRAP_SRCS >> with the MODULE option. Since CUDA_WRAP_SRCS is a low level command, >> If you need separable compilation you will need to manually invoke >> those steps too ( read CUDA_SEPARABLE_COMPILATION documentation on >> what methods you will need to use ). > > > > -- > Regards, > Ingmar From robert.maynard at kitware.com Fri Jan 13 14:21:47 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 13 Jan 2017 14:21:47 -0500 Subject: [CMake] [ANNOUNCE] CMake 3.7.2 available for download Message-ID: We are pleased to announce that CMake 3.7.2 is now available for download. Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! ------------------------------------------------------------------------- Changes in 3.7.2 since 3.7.1: Aleix Pol (1): cmake-server: Do not try watching subdirectories with empty names Brad King (4): VS: Add v141 flag table entry for `-Zc:inline-` VS: Add v140 flag table entries for `-Zc:inline[-]` VS: Fix standalone Windows7.1SDK toolset selection CMake 3.7.2 Roger Leigh (1): FindBoost: Add support for 1.63 Rolf Eike Beer (1): FindPostgreSQL: automatically find installations from yum.postgresql.org Tobias Hunger (3): server-mode: Do not ignore the first cacheArgument on configure server-mode: Call ResetErrorOccured before configure server-mode: Do not crash when running into INTERFACE_LIBRARY Vic Luo (1): FindBoost: Add support for VS 2017 From robert.maynard at kitware.com Fri Jan 13 14:21:47 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 13 Jan 2017 14:21:47 -0500 Subject: [CMake] [ANNOUNCE] CMake 3.7.2 available for download Message-ID: We are pleased to announce that CMake 3.7.2 is now available for download. Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! ------------------------------------------------------------------------- Changes in 3.7.2 since 3.7.1: Aleix Pol (1): cmake-server: Do not try watching subdirectories with empty names Brad King (4): VS: Add v141 flag table entry for `-Zc:inline-` VS: Add v140 flag table entries for `-Zc:inline[-]` VS: Fix standalone Windows7.1SDK toolset selection CMake 3.7.2 Roger Leigh (1): FindBoost: Add support for 1.63 Rolf Eike Beer (1): FindPostgreSQL: automatically find installations from yum.postgresql.org Tobias Hunger (3): server-mode: Do not ignore the first cacheArgument on configure server-mode: Call ResetErrorOccured before configure server-mode: Do not crash when running into INTERFACE_LIBRARY Vic Luo (1): FindBoost: Add support for VS 2017 From James.Sutherland at utah.edu Fri Jan 13 18:52:34 2017 From: James.Sutherland at utah.edu (James Sutherland) Date: Fri, 13 Jan 2017 16:52:34 -0700 Subject: [CMake] ExternalProject_Add In-Reply-To: References: Message-ID: I found this solution helpful: https://crascit.com/2015/07/25/cmake-gtest It is unfortunate that CMake doesn't have a proper way to accomplish this. --James On Sun, Jan 8, 2017 at 10:07 PM, Hendrik Sattler wrote: > One possibility is the often mentioned superbuild, another is not using > find_library() but setting the variables with the library file paths > manually (that's static info anyway). > > > Am 8. Januar 2017 22:49:52 MEZ schrieb Saad Khattak >: > >Hello, > > > >I have an external project glfw that I added to my project like this: > > > >========== > >include(ExternalProject) > >ExternalProject_Add(glfw > > GIT_REPOSITORY "https://github.com/glfw/glfw.git" > > GIT_TAG "master" > > > > SOURCE_DIR "${CMAKE_SOURCE_DIR}/dep/glfw" > > CMAKE_ARGS -DGLFW_BUILD_DOCS=OFF -DGLFW_BUILD_TESTS=OFF > >-DGLFW_BUILD_EXAMPLES=OFF > >-DCMAKE_INSTALL_PREFIX=${CMAKE_SOURCE_DIR}/install/glfw/ > >-DCMAKE_DEBUG_POSTFIX=_d > > > > TEST_COMMAND "" > > ) > >set(GLFW_INCLUDE_DIR "${CMAKE_SOURCE_DIR}/install/glfw/include/") > >set(GLFW_LIBRARY_DIR "${CMAKE_SOURCE_DIR}/install/glfw/lib/") > >========== > > > >Then I include it in my project like so: > > > >========== > >find_library(GLFW_LIB_D glfw3_d ${GLFW_LIBRARY_DIR}) > >find_library(GLFW_LIB glfw3 ${GLFW_LIBRARY_DIR}) > > > >include_directories(${GLFW_INCLUDE_DIR}) > > > >add_executable(vk_test > > src/vulkan_test.cpp > > ) > >target_link_libraries(vk_test debug ${GLFW_LIB_D} optimized > >${GLFW_LIB}) > >add_dependencies(vk_test glfw) > >========== > > > >As you can see, I depend on the libraries compiled by the external > >project > >glfw. Unfortunately, when I first configure the project, CMake > >complains > >that it cannot find the libraries specified by ${GLFW_LIB_D} and > >${GLFW_LIB} variables. > > > >Of course, this is because CMake did not begin cloning, configuring and > >building the glfw project. That only happens AFTER my project has been > >configured and starts building. This becomes a chicken and the egg > >problem. > > > >Currently, my solution is to add dummy .lib files so that I can at > >least > >configure and generate my project. My question is, am I approaching > >this > >problem in the wrong way? If yes, what is the correct way to add a > >dependency to an external project and have it clone/configure/build > >BEFORE > >the "find_library" call? > > -- > Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail > gesendet. > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From James.Sutherland at utah.edu Fri Jan 13 18:53:17 2017 From: James.Sutherland at utah.edu (James Sutherland) Date: Fri, 13 Jan 2017 16:53:17 -0700 Subject: [CMake] To include external libraries using Cmake In-Reply-To: <586E9CC4.4040402@kitware.com> References: <586E9CC4.4040402@kitware.com> Message-ID: I found this solution helpful: https://crascit.com/2015/07/25/cmake-gtest It is unfortunate that CMake doesn't have a proper way to accomplish this. --James On Thu, Jan 5, 2017 at 12:21 PM, Matthew Woehlke < matthew.woehlke at kitware.com> wrote: > On 2017-01-05 05:10, aishwarya selvaraj wrote: > > Thanks for feedback : > > > >> IF (${ARMADILLO} STREQUAL ?ARMADILLO-NOTFOUND?) > >> # do what you want > >> ENDIF () > > ? > > I tried this way of writing : > > > > IF (${ARMADILLO} STREQUAL "ARMADILLO-NOTFOUND") > > include(ExternalProject) > > ExternalProject_Add(armadillo > > URL https://github.com/lsolanka/armadillo/archive/master.zip > > PREFIX ${CMAKE_CURRENT_BINARY_DIR}/armadillo-latest) > > ENDIF() > > > > and > > > > IF (ARMADILLO STREQUAL ARMADILLO-NOTFOUND) > > include(ExternalProject) > > MESSAGE(STATUS "Trying to install armadillo...") > > ExternalProject_Add(armadillo > > URL https://github.com/lsolanka/armadillo/archive/master.zip > > PREFIX ${CMAKE_CURRENT_BINARY_DIR}/armadillo-latest) > > ENDIF() > > `if(NOT ARMADILLO)` is probably better... > > > ?But both of them gave me an error : > > CMake Error: The following variables are used in this project, but > > they are set to NOTFOUND. Please set them or make sure they are set > > and tested correctly in the CMake files: > > ARMADILLO > > linked by target "tsm" in directory /home/computing9/TSM_cmake > > SNDFILE > > linked by target "tsm" in directory /home/computing9/TSM_cmake > > Ah... I was mostly replying to Parag; I hadn't actually looked that > closely at your original problem. > > What you're trying to do is similar to a "superbuild" with optional > components. The usual way to do this is to treat *your own project* as > one of several external projects, so that the "superbuild" consists > solely of external projects. Something like: > > set(mydeps) > if(NOT armadillo) > externalproject_add(armadillo ...) > list(APPEND mydeps armadillo > endif() > # similar for other externals > externalproject_add(myproject ... DEPENDS ${mydeps}) > > This way, by the time your project configures, the library exists. > (You'll probably end up looking for the library twice; once in the > superbuild to decide whether to build it, and again in your project > proper where you'll a) assume it exists and hard error otherwise, and b) > want to specify as an additional search path where the superbuild will > produce it.) > > Without this, trying to set up the rules so that you can both link the > library that will be created, and also get the dependencies correct so > that the build knows how to produce it when needed, is probably going to > be tricky. (Read: I'm not convinced it's impossible, but I've never seen > someone actually doing this and wouldn't recommend it.) > > An alternative that may work is to set up the externals as subprojects > and have CMake fetch them at configure time if they are needed, and then > incorporate their builds directly in your own build (i.e. using > add_subdirectory rather than externalproject_add); then you can link to > the library target names when you build them yourself, and everything > will work. > > p.s. I don't recommend always obtaining the current master of externals. > It's usually safer to pick a SHA and bump it as needed, so that you are > insulated against breaking changes upstream. I'm also not sure why you > are fetching snapshots instead of just using the git repositories directly. > > -- > Matthew > -- > > 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/opensou > rce/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmake at anteru.net Sat Jan 14 05:11:17 2017 From: cmake at anteru.net (=?UTF-8?Q?Matth=c3=a4us_G._Chajdas?=) Date: Sat, 14 Jan 2017 11:11:17 +0100 Subject: [CMake] Find Vulkan on 32 bit builds In-Reply-To: References: Message-ID: <22aed983-cda4-0397-437b-c54a4b86b584@anteru.net> Hi, I've filed a bug report with LunarG. The issue is here: https://vulkan.lunarg.com/issue/view/587509589ab0fa2af19621ca In the meantime, I'll prepare an update which can handle /lib, /lib32 and adds the NO_DEFAULT_PATH in case of 32-bit Windows. Thanks for the report! Cheers, Matth?us Am 10.01.2017 um 17:11 schrieb Saad Khattak: > That makes sense! Removing the variable from PATH does indeed fix the issue. > > It is not a blocking issue for me. > > I agree that this is a Vulkan packaging issue. However, since you are > looking for $ENV{VULKAN_SDK} in the find module and assuming it exists, > then it 'should' override the other path? I do see what you are saying > in that this now becomes a special case just because Vulkan SDK didn't > package the libs properly. > > Thanks Matth?us and Andreas for your help! > > On Tue, Jan 10, 2017 at 10:38 AM Matth?us G. Chajdas > wrote: > > Hi, > > the problem here is that the Vulkan SDK helpfully adds > D:/VulkanSDK/1.0.37.0/Bin into PATH, while the > Vulkan module dutifully > searches Bin on x64 and Bin32 on x86. However, because /Bin is in the > PATH, and because the libraries for both architectures are named the > same, it will pick up the one from /Bin first (as the search order for > find_library is system paths first, and PATHS/HINTS variable second). > > There's a couple of ways to fix this; for instance, on Windows I could > use NO_DEFAULT_PATH on the find_library call and that would resolve the > issue. The main reason why I haven't done this yet is because I think > that's a packaging bug in the Vulkan SDK side which I was going to > report there (I want to ask them to move the libraries into a lib/ > subfolder, and ideally use different names for different architectures.) > > For now the easiest workaround is to remove the path to the Vulkan SDK > from PATH; and I'll try to report this with the LunarG SDK and see how > far I get there. If this doesn't work out, I'll guess I'll have to > special-case the find_library call to ignore default paths on Windows & > 32-bit only. > > If this is a blocker for you, please file an issue and I'll fix it on > the CMake end before even starting the discussion with LunarG. > > Cheers, > Matth?us > > Am 08.01.2017 um 14:36 schrieb Andreas Naumann: > > Hello, > > Am 08.01.2017 um 07:22 schrieb Saad Khattak: > >> Hello, > >> > >> When I run "find_package(VULKAN)" in a CMakeLists for a Visual Studio > >> 2015 32-bit project, the ${Vulkan_LIBRARY} and ${Vulkan_LIBRARIES} > >> variables both point to the "Bin" folder for the Vulkan installation > >> instead of the "Bin32" folder. > >> > >> I looked at the FindVulkan.cmake module and even put MESSAGE(STATUS > >> ...) on the "elseif(CMAKE_SIZEOF_VOID_P EQUAL 4)" to see if I made a > >> mistake setting up. The message does indeed print confirming that my > >> pointer size is 4 and thus the current toolchain selected is 32 bit. > >> > >> What's perplexing is that when I do a MESSAGE(STATUS > >> ${Vulkan_LIBRARY}) the path is: > >> > >> > >> D:/VulkanSDK/1.0.37.0/Bin/vulkan-1.lib > > >> > >> > >> instead of > >> > >> > >> D:/VulkanSDK/1.0.37.0/Bin32/vulkan-1.lib > > >> > >> > >> > >> It makes no sense. Line 47 of FindVulkan.cmake has Bin32. Why is > CMake > >> ignoring 32? > >> > > You should think the other way around: Why should cmake look in a > > special directory, when it finds a library with an appropriate name > > before this one? > > This decision should be in the corresponding FindVulkan.cmake, > i.e. the > > corresponding find_library call should be constrained to > > ${VULKAN_DIR}/Bin32 in the 32bit case. > >> > >> > > > > Regards, > > Andreas > From paul at mad-scientist.net Sat Jan 14 18:35:03 2017 From: paul at mad-scientist.net (Paul Smith) Date: Sat, 14 Jan 2017 18:35:03 -0500 Subject: [CMake] cmake 3.7.2: add_custom_command can't DEPEND on OBJECT library? Message-ID: <1484436903.10997.61.camel@mad-scientist.net> If I create an OBJECT library: add_library(libIface OBJECT iface.cpp) Then I create a custom command that depends on this: add_custom_command(OUTPUT out.map ? ???COMMAND touch out.map ? ??DEPENDS libIface ? ???VERBATIM) It doesn't work: the dependency is missing so when I edit the iface.cpp file the custom command is not run. I'm using the Makefile generator, on Linux, and if I look at the generated makefile it's obvious that there's nothing there representing the OBJECT library: out.map: ????????@$(CMAKE_COMMAND) -E ... "Generating out.map" ????????touch out.map The documentation for add_custom_command() clearly says that DEPENDS can specify "any target (created by the ... add_library() command)". Is there something missing from the docs that should say it doesn't work with OBJECT libraries, or is this a bug in cmake? Repro: -------------------------------------------------------------------- $ cat CMakeLists.txt cmake_minimum_required(VERSION 3.5) project(MapTest) add_library(libIface OBJECT iface.cpp) add_custom_command(OUTPUT out.map ????COMMAND touch out.map ????DEPENDS libIface ????VERBATIM) add_custom_target(libIfaceMap DEPENDS out.map) add_library(iface SHARED $ out.map) $ touch iface.cpp $ cmake . $ make Scanning dependencies of target libIface [ 33%] Building CXX object CMakeFiles/libIface.dir/iface.cpp.o [ 33%] Built target libIface [ 66%] Generating out.map Scanning dependencies of target iface [100%] Linking CXX shared library libiface.so [100%] Built target iface $ touch iface.cpp $ make Scanning dependencies of target libIface [ 33%] Building CXX object CMakeFiles/libIface.dir/iface.cpp.o [ 33%] Built target libIface [ 66%] Linking CXX shared library libiface.so [100%] Built target iface -------------------------------------------------------------------- Note that in the last step the "out.map" file was not recreated even though iface.cpp was modified. From ggarra13 at gmail.com Sat Jan 14 18:44:33 2017 From: ggarra13 at gmail.com (=?UTF-8?Q?Gonzalo_Garramu=c3=b1o?=) Date: Sat, 14 Jan 2017 20:44:33 -0300 Subject: [CMake] Custom command on cpack target In-Reply-To: <99832f4e-241a-68a8-f99b-05bfc52ada60@gmail.com> References: <99832f4e-241a-68a8-f99b-05bfc52ada60@gmail.com> Message-ID: <9bfdb8ac-c17f-a7ef-cb3e-62180df41213@gmail.com> El 10/01/17 a las 17:34, Gonzalo Garramu?o escribi?: > > I would like to run a custom command on the zip file generated by > cpack. The idea is that I want to calculate its sha256 checksum. > Unfortunately it seems the zip file cannot be a target in a > CMakeLists.txt file or I'm doing something wrong. > > Can someone give me a hand? > To answer my own question and for others that might want to do the same: # Cmake only adds the default package target if a package config file # named CPackConfig.cmake exists in the outermost binary build directory. # By forcing the CPack module to generate the package file under a # different name, we prevent the "target" path from being generated. SET( CPACK_OUTPUT_CONFIG_FILE "${CMAKE_BINARY_DIR}/BundleConfig.cmake" ) include(CPack) ADD_CUSTOM_TARGET( bundle COMMAND "${CMAKE_CPACK_COMMAND}" "-C" "$" "--config" "${CMAKE_BINARY_DIR}/BundleConfig.cmake" COMMENT "Running CPack. Please wait..." DEPENDS ${PROJECT_NAME}) IF (WIN32) ADD_CUSTOM_COMMAND( TARGET bundle POST_BUILD COMMAND ${CMAKE_COMMAND} -D CMAKE_SYSTEM_NAME=${CMAKE_SYSTEM_NAME} -D VERSION=${VERSION} "-P" "${CMAKE_CURRENT_SOURCE_DIR}/../../chocolatey/mrViewer/CMakeLists.txt" WORKING_DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}" ) ENDIF( WIN32 ) This works in that instead of calling make/ninja package you call make/ninja bundle. -- Gonzalo Garramu?o From paul at mad-scientist.net Sat Jan 14 18:46:23 2017 From: paul at mad-scientist.net (Paul Smith) Date: Sat, 14 Jan 2017 18:46:23 -0500 Subject: [CMake] How to use a generated linker map with a shared library? Message-ID: <1484437583.10997.63.camel@mad-scientist.net> I'm really stuck: maybe someone can provide a hint. I'm trying to create a shared library from a bunch of object files, and use a linker script to mark almost all the symbols as local. ?The tricky thing is I'm auto-generating the linker script via a shell script that examines the object files for my library (using readelf) to find global symbols. I basically need a process like this: 1. Start with source files and a linker map generator shell script 2. Compile all the code into object files 3. If any file was recompiled (or the generator script) is modified, re- run the generator script to recreate the linker script 4. If any file was recompiled or the linker script was recreated, rebuild the shared library, using the linker script. In "make-ese" it would be trivial: something like: libmy.so: $(OBJECTS) link.script ; ... link.script: $(OBJECTS) genlinkscript ; ... I simply can't figure out how to create something like this in CMake. I have a custom command to create the linker script: add_custom_command(OUTPUT out.script ????COMMAND genlinkscript ${CMAKE_CURRENT_BINARY_DIR} ????DEPENDS <> ? ???VERBATIM) And I have an add_library command to create the shared library: add_library(mylib SHARED foo.cpp foo.h out.script) ??set_property(TARGET mylib APPEND_STRING PROPERTY ????????LINK_FLAGS " -Wl,--version-script=out.script") But what can my custom_command depend on, so that it's run AFTER all the object files are created, but BEFORE the shared library is created? I tried to do this using an OBJECT library, but see my previous post that adding OBJECT libraries as dependencies of custom commands doesn't work. What can I do? I'm happy with a solution that works only on Linux (I can use if()/endif() to turn it off on my other platforms, which don't use these linker scripts anyway). From craig.scott at crascit.com Sat Jan 14 20:08:17 2017 From: craig.scott at crascit.com (Craig Scott) Date: Sun, 15 Jan 2017 12:08:17 +1100 Subject: [CMake] How to use a generated linker map with a shared library? In-Reply-To: <1484437583.10997.63.camel@mad-scientist.net> References: <1484437583.10997.63.camel@mad-scientist.net> Message-ID: While not directly answering your question, it seems you may be trying to deal with symbol visibility. Are you aware of CMake's symbol visibility features? A good place to start would be the GenerateExportHeader module, the documentation for which does a reasonable job of showing how to use the visibility features CMake provides. Dealing with your question more directly, you may want to look at the TARGET form of add_custom_command() and in particular, the PRE_LINK keyword. See the Build Events section near the bottom of the page for the add_custom_command() docs . On Sun, Jan 15, 2017 at 10:46 AM, Paul Smith wrote: > I'm really stuck: maybe someone can provide a hint. > > I'm trying to create a shared library from a bunch of object files, and > use a linker script to mark almost all the symbols as local. The tricky > thing is I'm auto-generating the linker script via a shell script that > examines the object files for my library (using readelf) to find global > symbols. > > I basically need a process like this: > > 1. Start with source files and a linker map generator shell script > 2. Compile all the code into object files > 3. If any file was recompiled (or the generator script) is modified, re- > run the generator script to recreate the linker script > 4. If any file was recompiled or the linker script was recreated, > rebuild the shared library, using the linker script. > > In "make-ese" it would be trivial: something like: > > libmy.so: $(OBJECTS) link.script ; ... > > link.script: $(OBJECTS) genlinkscript ; ... > > I simply can't figure out how to create something like this in CMake. > > I have a custom command to create the linker script: > > add_custom_command(OUTPUT out.script > COMMAND genlinkscript ${CMAKE_CURRENT_BINARY_DIR} > DEPENDS <> > VERBATIM) > > And I have an add_library command to create the shared library: > > add_library(mylib SHARED foo.cpp foo.h out.script) > > set_property(TARGET mylib APPEND_STRING PROPERTY > LINK_FLAGS " -Wl,--version-script=out.script") > > But what can my custom_command depend on, so that it's run AFTER all the > object files are created, but BEFORE the shared library is created? > > I tried to do this using an OBJECT library, but see my previous post > that adding OBJECT libraries as dependencies of custom commands doesn't > work. > > What can I do? I'm happy with a solution that works only on Linux (I > can use if()/endif() to turn it off on my other platforms, which don't > use these linker scripts anyway). > -- > > 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 -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at mad-scientist.net Sat Jan 14 21:16:21 2017 From: paul at mad-scientist.net (Paul Smith) Date: Sat, 14 Jan 2017 21:16:21 -0500 Subject: [CMake] How to use a generated linker map with a shared library? In-Reply-To: References: <1484437583.10997.63.camel@mad-scientist.net> Message-ID: <1484446581.10997.65.camel@mad-scientist.net> On Sun, 2017-01-15 at 12:08 +1100, Craig Scott wrote: > While not directly answering your question, it seems you may be trying > to deal with symbol visibility. Are you aware of CMake's symbol > visibility features? A good place to start would be the > GenerateExportHeader module, the documentation for which does a > reasonable job of showing how to use the visibility features CMake > provides. Yes, thanks for that info. My situation is that I need to force ALL symbols to be private, even those from external static shared libraries that I'm linking in (whose symbols have global visibility by default). So I need a linker script that contains (this is for GCC's ld): { global: ...; local: *; }; I need the "local: *;" to hide the external symbols, but to keep it from hiding all my global symbols I need to list them all explicitly in the global: section. > Dealing with your question more directly, you may want to look at the > TARGET form of add_custom_command() and in particular, the PRE_LINK > keyword. See the Build Events section near the bottom of the page for > the add_custom_command() docs. Oh beauty! That seems to be just what I need. Thanks! From julien.jomier at kitware.com Mon Jan 16 03:33:02 2017 From: julien.jomier at kitware.com (Julien Jomier) Date: Mon, 16 Jan 2017 09:33:02 +0100 Subject: [CMake] ANN: CMake Course - March 13 in Lyon, France Message-ID: Kitware will be holding a CMake training course on March 13, 2017 at Kitware's office in Lyon, France. This one-day course will cover CMake, CTest, CPack and CDash. Visit our website for more information and registration details (early registration and student discounts available): http://training.kitware.fr/browse/129 Note that the course will be taught in English. If you have any questions, please contact me directly or training at kitware.fr. We are looking forward to seeing you in Lyon, Julien From nat-cmake at mulle-kybernetik.com Mon Jan 16 05:02:21 2017 From: nat-cmake at mulle-kybernetik.com (Nat!) Date: Mon, 16 Jan 2017 11:02:21 +0100 Subject: [CMake] Problem with a simple framework target on OS X Message-ID: <587C9A2D.8000905@mulle-kybernetik.com> Hi I am trying to create an OS X framework with resources and headers using cmake. This is my `CMakeLists.txt` file: project( Foo) cmake_minimum_required (VERSION 3.7) add_library( Foo SHARED foo.c ) set_target_properties( Foo PROPERTIES FRAMEWORK TRUE RESOURCE "foo.md" PUBLIC_HEADER "foo.h" ) When I run `( mkdir build ; cd build ; cmake .. ; make)` a `Foo.framework` is generated, but the header and the resource do not appear in it. What am I missing ? (cmake version 3.7.1) --- How to reproduce. Save above CMakeLists.txt. Now execute: #!/bin/sh echo "int version = 1;" > foo.c touch foo.h touch foo.md ( mkdir build ; cd build ; cmake .. ; make) ls -R build/Foo.framework/ Ciao Nat! P.S. Asked this on stackoverflow too (https://stackoverflow.com/posts/41597860) a few days ago. From nilsgladitz at gmail.com Mon Jan 16 05:23:03 2017 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Mon, 16 Jan 2017 11:23:03 +0100 Subject: [CMake] Problem with a simple framework target on OS X In-Reply-To: <587C9A2D.8000905@mulle-kybernetik.com> References: <587C9A2D.8000905@mulle-kybernetik.com> Message-ID: <4486aa2c-fb74-d1be-35e3-6ae0720df693@gmail.com> On 01/16/2017 11:02 AM, Nat! wrote: > Hi > > I am trying to create an OS X framework with resources and headers using > cmake. This is my `CMakeLists.txt` file: > > project( Foo) > > cmake_minimum_required (VERSION 3.7) > > add_library( Foo SHARED > foo.c > ) > > set_target_properties( Foo PROPERTIES > FRAMEWORK TRUE > RESOURCE "foo.md" > PUBLIC_HEADER "foo.h" > ) > > > When I run `( mkdir build ; cd build ; cmake .. ; make)` a > `Foo.framework` is generated, but the header and the resource do not > appear in it. What am I missing ? (cmake version 3.7.1) Try add_library( Foo SHARED foo.c foo.h foo.md). From what I remember the target properties in this case only apply to sources that are associated with the target. Unrelated but cmake_minimum_required() should come before project(). Nils From Harry at codexdigital.com Mon Jan 16 09:37:50 2017 From: Harry at codexdigital.com (Harry Mallon) Date: Mon, 16 Jan 2017 14:37:50 +0000 Subject: [CMake] Using XCODE_PRODUCT_TYPE to make kexts Message-ID: <6AC2ED65-1C7E-4C09-BAE3-AE980480821F@codex.london> Hello, I am almost there making kexts with XCode generator and CMake. However they appear as "com.apple.product-type.bundle" rather than "com.apple.product-type.kernel-extension.iokit" in the Xcode project file. This means they do not get the Xcode/kext magic compile line without lots of manual setting (which I can't get right at the moment). Looking at the code https://gitlab.kitware.com/cmake/cmake/blob/master/Source/cmGlobalXCodeGenerator.cxx it seems setting XCODE_PRODUCT_TYPE on the target should work. But it doesn't work for me. Any ideas? Harry Harry Mallon CODEX | Software Engineer 60 Poland Street | London | England | W1F 7NT E harry at codexdigital.com | T +44 203 7000 989 Website | Facebook | Twitter [http://codex.online/?action=asset&id=5B21DF7C-EC27-4199-852F-D596F5F28DA9] -------------- next part -------------- An HTML attachment was scrubbed... URL: From Harry at codexdigital.com Mon Jan 16 09:43:09 2017 From: Harry at codexdigital.com (Harry Mallon) Date: Mon, 16 Jan 2017 14:43:09 +0000 Subject: [CMake] Using XCODE_PRODUCT_TYPE to make kexts In-Reply-To: <6AC2ED65-1C7E-4C09-BAE3-AE980480821F@codex.london> References: <6AC2ED65-1C7E-4C09-BAE3-AE980480821F@codex.london> Message-ID: Hi again, Sorry look like it is not in the release build yet. Harry Harry Mallon CODEX | Software Engineer 60 Poland Street | London | England | W1F 7NT E harry at codexdigital.com | T +44 203 7000 989 Website | Facebook | Twitter [http://codex.online/?action=asset&id=5B21DF7C-EC27-4199-852F-D596F5F28DA9] On 16 Jan 2017, at 14:37, Harry Mallon > wrote: Hello, I am almost there making kexts with XCode generator and CMake. However they appear as "com.apple.product-type.bundle" rather than "com.apple.product-type.kernel-extension.iokit" in the Xcode project file. This means they do not get the Xcode/kext magic compile line without lots of manual setting (which I can't get right at the moment). Looking at the code https://gitlab.kitware.com/cmake/cmake/blob/master/Source/cmGlobalXCodeGenerator.cxx it seems setting XCODE_PRODUCT_TYPE on the target should work. But it doesn't work for me. Any ideas? Harry -------------- next part -------------- An HTML attachment was scrubbed... URL: From gjasny at googlemail.com Mon Jan 16 11:23:55 2017 From: gjasny at googlemail.com (Gregor Jasny) Date: Mon, 16 Jan 2017 17:23:55 +0100 Subject: [CMake] Using XCODE_PRODUCT_TYPE to make kexts In-Reply-To: References: <6AC2ED65-1C7E-4C09-BAE3-AE980480821F@codex.london> Message-ID: <34ffe97f-9132-a9df-ed28-ab7bc7a7750e@googlemail.com> Hello, On 16/01/2017 15:43, Harry Mallon wrote: > Sorry look like it is not in the release build yet. correct, please use a recent nightly: https://cmake.org/files/dev/?C=M;O=D Maybe you could report back if the attribute works for you. Thanks, Gregor From clinton at elemtech.com Mon Jan 16 11:07:39 2017 From: clinton at elemtech.com (clinton at elemtech.com) Date: Mon, 16 Jan 2017 09:07:39 -0700 Subject: [CMake] How to use a generated linker map with a shared library? Message-ID: <42feaf73-149b-46be-a228-7210355eb980@email.android.com> An HTML attachment was scrubbed... URL: From yves.frederix+cmake at gmail.com Tue Jan 17 06:02:17 2017 From: yves.frederix+cmake at gmail.com (Yves Frederix) Date: Tue, 17 Jan 2017 12:02:17 +0100 Subject: [CMake] Add dependencies to the automoc/autorcc target? Message-ID: Hi all, I have a situation in which I would need to define a dependency for the automoc target. Is it possible to do this somehow? Basically, I have a setup in which a resource that is to be embedded is generated by another target. However, due to parallelism in the build and the lack of a dependency of the _automoc target on this target, I often get an error like : RCC: Error in '.../build/resources.qrc': Cannot find file '../build/myfile.txt' I tried adding a dependency using add_dependencies, but this doesn't seem to work. Minimal example code is below (you will need to create an empty main.cpp though). I am using CMake 3.7.1 with a VS generator. My build command looks like 'cmake --build . -- -m'. cmake_minimum_required(VERSION 3.7) project(test CXX) find_package(Qt5Quick REQUIRED) set(CMAKE_AUTORCC ON) # Define target that generates some files. add_custom_target(generate_files) add_custom_command(TARGET generate_files COMMAND sleep 1) # Wait a bit... add_custom_command(TARGET generate_files COMMAND ${CMAKE_COMMAND} -E touch ${CMAKE_BINARY_DIR}/myfile.txt) # Write the .qrc file for embedding these generated files. file(WRITE ${CMAKE_BINARY_DIR}/resources.qrc "\n\n${CMAKE_BINARY_DIR}/myfile.txt\n\n") add_library(foo SHARED main.cpp ${CMAKE_BINARY_DIR}/resources.qrc) add_dependencies(foo generate_files) target_link_libraries(foo PRIVATE Qt5::Quick) Thanks! Regards, Yves From jsvanbethlehem at gmail.com Tue Jan 17 06:47:59 2017 From: jsvanbethlehem at gmail.com (Jakob van Bethlehem) Date: Tue, 17 Jan 2017 12:47:59 +0100 Subject: [CMake] Add dependencies to the automoc/autorcc target? In-Reply-To: References: Message-ID: Hej Yves, The problem is that the 'add_custom_command' does *NOT* create a new target, which seems to be what you assume, see https://cmake.org/cmake/help/v3.0/command/add_custom_command.html The signature you're using is supposed to be used to *add* a custom command to an *existing* target. In other words, it should read: add_custom_command(TARGET foo PRE_BUILD COMMAND ${CMAKE_COMMAND} -E touch ${CMAKE_BINARY_DIR}/myfile.txt) (and hopefully it is immediately obvious that the 'sleep' command should go - CMake will never execute that command) Sincerely, Jakob On Tue, Jan 17, 2017 at 12:02 PM, Yves Frederix < yves.frederix+cmake at gmail.com> wrote: > Hi all, > > I have a situation in which I would need to define a dependency for > the automoc target. Is it possible to do this somehow? > > Basically, I have a setup in which a resource that is to be embedded > is generated by another target. However, due to parallelism in the > build and the lack of a dependency of the _automoc target on this > target, I often get an error like : > > RCC: Error in '.../build/resources.qrc': Cannot find file > '../build/myfile.txt' > > I tried adding a dependency using add_dependencies, but this doesn't > seem to work. > > Minimal example code is below (you will need to create an empty > main.cpp though). I am using CMake 3.7.1 with a VS generator. My build > command looks like 'cmake --build . -- -m'. > > > cmake_minimum_required(VERSION 3.7) > > project(test CXX) > > find_package(Qt5Quick REQUIRED) > > set(CMAKE_AUTORCC ON) > > # Define target that generates some files. > add_custom_target(generate_files) > add_custom_command(TARGET generate_files COMMAND sleep 1) # Wait a bit... > add_custom_command(TARGET generate_files COMMAND ${CMAKE_COMMAND} -E touch > ${CMAKE_BINARY_DIR}/myfile.txt) > > # Write the .qrc file for embedding these generated files. > file(WRITE ${CMAKE_BINARY_DIR}/resources.qrc > " version=\"1.0\">\n\n${CMAKE_BINARY_DIR}/ > myfile.txt\n\n") > > add_library(foo SHARED main.cpp ${CMAKE_BINARY_DIR}/resources.qrc) > add_dependencies(foo generate_files) > target_link_libraries(foo PRIVATE Qt5::Quick) > > > Thanks! > > Regards, > Yves > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yves.frederix+cmake at gmail.com Tue Jan 17 06:56:01 2017 From: yves.frederix+cmake at gmail.com (Yves Frederix) Date: Tue, 17 Jan 2017 12:56:01 +0100 Subject: [CMake] Add dependencies to the automoc/autorcc target? In-Reply-To: References: Message-ID: Hi Jacob, Thanks for your answer. I am aware that add_custom_command() does not create a target, hence the call to add_custom_target(generate_files), followed by add_custom_command(TARGET generate_files...). The presence of the sleep command is for illustration purposes only. It delays the generation of 'myfile.txt' so that I can illustrate the problem (in a parallel build the autorcc will be started before the file is generated and the error will be shown). Regards, Yves On Tue, Jan 17, 2017 at 12:47 PM, Jakob van Bethlehem wrote: > Hej Yves, > > The problem is that the 'add_custom_command' does *NOT* create a new target, > which seems to be what you assume, see > https://cmake.org/cmake/help/v3.0/command/add_custom_command.html > > The signature you're using is supposed to be used to *add* a custom command > to an *existing* target. In other words, it should read: > > add_custom_command(TARGET foo PRE_BUILD COMMAND ${CMAKE_COMMAND} -E touch > ${CMAKE_BINARY_DIR}/myfile.txt) > > (and hopefully it is immediately obvious that the 'sleep' command should go > - CMake will never execute that command) > > Sincerely, > Jakob > > On Tue, Jan 17, 2017 at 12:02 PM, Yves Frederix > wrote: >> >> Hi all, >> >> I have a situation in which I would need to define a dependency for >> the automoc target. Is it possible to do this somehow? >> >> Basically, I have a setup in which a resource that is to be embedded >> is generated by another target. However, due to parallelism in the >> build and the lack of a dependency of the _automoc target on this >> target, I often get an error like : >> >> RCC: Error in '.../build/resources.qrc': Cannot find file >> '../build/myfile.txt' >> >> I tried adding a dependency using add_dependencies, but this doesn't >> seem to work. >> >> Minimal example code is below (you will need to create an empty >> main.cpp though). I am using CMake 3.7.1 with a VS generator. My build >> command looks like 'cmake --build . -- -m'. >> >> >> cmake_minimum_required(VERSION 3.7) >> >> project(test CXX) >> >> find_package(Qt5Quick REQUIRED) >> >> set(CMAKE_AUTORCC ON) >> >> # Define target that generates some files. >> add_custom_target(generate_files) >> add_custom_command(TARGET generate_files COMMAND sleep 1) # Wait a bit... >> add_custom_command(TARGET generate_files COMMAND ${CMAKE_COMMAND} -E touch >> ${CMAKE_BINARY_DIR}/myfile.txt) >> >> # Write the .qrc file for embedding these generated files. >> file(WRITE ${CMAKE_BINARY_DIR}/resources.qrc >> "> >> version=\"1.0\">\n\n${CMAKE_BINARY_DIR}/myfile.txt\n\n") >> >> add_library(foo SHARED main.cpp ${CMAKE_BINARY_DIR}/resources.qrc) >> add_dependencies(foo generate_files) >> target_link_libraries(foo PRIVATE Qt5::Quick) >> >> >> Thanks! >> >> Regards, >> Yves >> -- >> >> 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 > > From nilsgladitz at gmail.com Tue Jan 17 07:46:26 2017 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 17 Jan 2017 13:46:26 +0100 Subject: [CMake] Add dependencies to the automoc/autorcc target? In-Reply-To: References: Message-ID: On 01/17/2017 12:02 PM, Yves Frederix wrote: > Hi all, > > I have a situation in which I would need to define a dependency for > the automoc target. Is it possible to do this somehow? https://cmake.org/cmake/help/v3.7/prop_tgt/AUTOGEN_TARGET_DEPENDS.html The Documentation seems to imply this is AUTOMOC specific but I think (like the name implies) that it probably applies to all the AUTOGEN variants. Nils From yves.frederix+cmake at gmail.com Tue Jan 17 08:11:09 2017 From: yves.frederix+cmake at gmail.com (Yves Frederix) Date: Tue, 17 Jan 2017 14:11:09 +0100 Subject: [CMake] Add dependencies to the automoc/autorcc target? In-Reply-To: References: Message-ID: Works like a charm. Thanks a lot! Yves On Tue, Jan 17, 2017 at 1:46 PM, Nils Gladitz wrote: > On 01/17/2017 12:02 PM, Yves Frederix wrote: > >> Hi all, >> >> I have a situation in which I would need to define a dependency for >> the automoc target. Is it possible to do this somehow? > > > https://cmake.org/cmake/help/v3.7/prop_tgt/AUTOGEN_TARGET_DEPENDS.html > > The Documentation seems to imply this is AUTOMOC specific but I think (like > the name implies) that it probably applies to all the AUTOGEN variants. > > Nils From Harry at codexdigital.com Tue Jan 17 09:53:49 2017 From: Harry at codexdigital.com (Harry Mallon) Date: Tue, 17 Jan 2017 14:53:49 +0000 Subject: [CMake] Using XCODE_PRODUCT_TYPE to make kexts In-Reply-To: <34ffe97f-9132-a9df-ed28-ab7bc7a7750e@googlemail.com> References: <6AC2ED65-1C7E-4C09-BAE3-AE980480821F@codex.london> <34ffe97f-9132-a9df-ed28-ab7bc7a7750e@googlemail.com> Message-ID: <9C538E8C-232E-4EF7-B1ED-C5D90A411600@codex.london> Hi Gregor, With a CMake file similar to the following I seem to be able to make proper kexts with the latest nightly 3.7.20170113-g26509. At least they seem to be working, I have been bitten before. "kextutil -nt X.kext" is useful for testing them. This could close the issue https://gitlab.kitware.com/cmake/cmake/issues/13487. Harry ================================================ find_path(KERNEL_INCLUDE_DIR IOKit/pci/IOPCIDevice.h) add_library(driver MODULE Kext.cpp Kext.h ) target_include_directories(driver PRIVATE ${KERNEL_INCLUDE_DIR} ) set(driver_name "Driver") set(driver_id "com.driver.driver") set(driver_version "1.0.0") set_target_properties(driver PROPERTIES BUNDLE YES BUNDLE_EXTENSION kext INSTALL_RPATH "" # rpath must not be set! MACOSX_BUNDLE_BUNDLE_NAME ${driver_name} MACOSX_BUNDLE_BUNDLE_VERSION ${driver_version} MACOSX_BUNDLE_GUI_IDENTIFIER ${driver_id} MACOSX_BUNDLE_INFO_PLIST CmakeTemplate.plist.in OUTPUT_NAME ${driver_name} XCODE_ATTRIBUTE_MODULE_NAME ${driver_id} XCODE_ATTRIBUTE_MODULE_VERSION ${driver_version} XCODE_PRODUCT_TYPE "com.apple.product-type.kernel-extension.iokit" ) install(TARGETS driver DESTINATION Library/Extensions COMPONENT driver ) # Now we do a signing routine which we rolled ourselves ================================================ Harry Mallon CODEX | Software Engineer 60 Poland Street | London | England | W1F 7NT E harry at codexdigital.com | T +44 203 7000 989 Website | Facebook | Twitter [http://codex.online/?action=asset&id=5B21DF7C-EC27-4199-852F-D596F5F28DA9] -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at mad-scientist.net Tue Jan 17 13:20:23 2017 From: paul at mad-scientist.net (Paul Smith) Date: Tue, 17 Jan 2017 13:20:23 -0500 Subject: [CMake] How to use a generated linker map with a shared library? In-Reply-To: <42feaf73-149b-46be-a228-7210355eb980@email.android.com> References: <42feaf73-149b-46be-a228-7210355eb980@email.android.com> Message-ID: <1484677223.8157.7.camel@mad-scientist.net> On Mon, 2017-01-16 at 09:07 -0700, clinton at elemtech.com wrote: > > Yes, thanks for that info.? My situation is that I need to force ALL? > > symbols to be private, even those from external static shared libraries? > > that I'm linking in (whose symbols have global visibility by default). > > Have you tried the "--exclude-libs ALL" linker option? ?Using that > should hide symbols from static libraries. Yes, I looked at this. ?I can't quite figure out what algorithm it uses though. ?It gives me _almost_ the same results as my linker script with "local: *;", but not quite: With the linker script if I use: ? nm libfoo.so | grep ' [A-TV-Z] ' I see only and exactly the symbols I marked as global in my code, and nothing else as global. If I use --exclude-libs=ALL then I see the symbols I marked as global and _almost_ all the other symbols are local, but there some exceptions; for example: 0000000001f925a0 A __bss_start 0000000001f925a0 A _edata 0000000001fc0f4f A _end 000000000098c648 T _fini 000000000015b1b8 T _init In addition, some C++ templated symbols (very complex) are public as "W" (global weak symbols). ?I don't know why. I wonder whether _fini and _init need to be exported in order to properly handle global ctor/dtor when the library is loaded/unloaded? ?Hm. ?I may need to do some experimentation here. I don't see any point in the static data symbols being public. From paul at mad-scientist.net Tue Jan 17 14:46:40 2017 From: paul at mad-scientist.net (Paul Smith) Date: Tue, 17 Jan 2017 14:46:40 -0500 Subject: [CMake] How to use a generated linker map with a shared library? In-Reply-To: <1484677223.8157.7.camel@mad-scientist.net> References: <42feaf73-149b-46be-a228-7210355eb980@email.android.com> <1484677223.8157.7.camel@mad-scientist.net> Message-ID: <1484682400.8157.9.camel@mad-scientist.net> On Tue, 2017-01-17 at 13:20 -0500, Paul Smith wrote: > I wonder whether _fini and _init need to be exported in order to > properly handle global ctor/dtor when the library is loaded/unloaded? > ?Hm. ?I may need to do some experimentation here. FWIW I tried some experimentation with both dynamic linking and dlopen()/dlclose() methods of loading the shared library, and all my global ctors and dtors appeared to be invoked as expected in both situations regardless of whether the _fini and _init symbols were public... So I dunno. From veikko_e at hotmail.com Wed Jan 18 01:22:22 2017 From: veikko_e at hotmail.com (Veikko Eeva) Date: Wed, 18 Jan 2017 06:22:22 +0000 Subject: [CMake] On adding external projects and libraries, using Boost as a primary learning vehicle Message-ID: Hi! I'm relatively new to CMake and I'm trying to use https://github.com/veikkoeeva/cmaketest as a learning vehicle. My goal is to make a small, but sufficiently self-contained "Hello, World" project with a few other added projects. It looks to me this e-mail list might be a format suitable for a few starter questions and maybe a few follow-up ones if anyone has the time and inclination for little hand-holdng. Currently I have Boost added so it is downloaded on the fly, compiled and then the headers and link directories added. I would like to add and compile Boost like that at using https://github.com/veikkoeeva/cmaketest/blob/master/CMakeLists.txt#L77 *ExternalProject_Add*, but I've since learned from http://stackoverflow.com/questions/39178338/compile-a-compiler-as-an-external-project-and-use-it/39186321#39186321 and perusing Craig Scott's blog at https://crascit.com/ that what I'm doing currently may not be achievable in the way I'm trying to do currently. I have a few clear problems and then some others that I don't fully understand or that I'm not even aware of. For instance, I would to compile and add Boost headers and libraries dynamically, but I wouldn't like to have the Boost libraries to show in the IDE projects. Other less obvious is the libraries are added to the linker paths twice, which comes from my incomplete understanding of CMake build steps, I assume. The script has other mistakes too, I think, in how I add manually some Boost paths that perhaps could use less trouble (but the Boost build is a separate thing, so it might be required anyhow). Or in find_package(Boost). Could anyone give advice, hints, fragments etc. on how to deal with the issues? I think I try to complete this endeavor by adding an already compiled library dependency (such as OpenSSL, Sodium or LevelDb, that are common occurrences) and a source include at some point, so in that sense too understanding this Boost case looks like prevalent. And then after that adding tests, for instance. I made a question related to this at http://stackoverflow.com/questions/41674055/running-externalproject-add-in-configure-time-or-preventing-it-from-running-ever too, but as noted, it looks like to make an e-mail list perhaps would be a more appropriate vehicle. So, to recap: How could I add Boost as downloading dynamically, perhaps using ExternalProject_Add and compile it, but then not having it in the IDE projects but having the headers and compiled libraries included appropriately. I would appreciate even a slick code example "doing it right" so as not to just learn one way of hacking things together. Cordially, Veikko From rcdailey.lists at gmail.com Wed Jan 18 10:52:58 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Wed, 18 Jan 2017 09:52:58 -0600 Subject: [CMake] Multi-line strings with indentation ignored Message-ID: At the moment, with CMake 3.0 and on, I can use this syntax for multi-line strings: option( ZIOSK_ENABLE_ZPAY_DIAGNOSTICS "\ Enable additional diagnostic logs for zPay related code. \ Should not be enabled for production due to the sensitivity \ and volume of logs that will be printed." ) The problem with this approach is that it's ugly; I can't indent the code because the indentations are made to be a literal part of the string itself. I prefer the C++ approach to multi-line strings because it allows strings to be hard-wrapped AND indent them for style, all without affecting the actual string data: option( ZIOSK_ENABLE_ZPAY_DIAGNOSTICS "Enable additional diagnostic logs for zPay related code. " "Should not be enabled for production due to the sensitivity " "and volume of logs that will be printed" ) This is much nicer, but CMake fails this code because it sees each string as a separate parameter. Is there a mechanism I can use to style my strings this way? If not, are there any plans to add better multi-line string support? From ardillasdelmonte at gmail.com Wed Jan 18 12:39:01 2017 From: ardillasdelmonte at gmail.com (ardi) Date: Wed, 18 Jan 2017 18:39:01 +0100 Subject: [CMake] Managing a local installation of cmake-built open source packages Message-ID: Hi, I want to install (on UNIX-like systems) a collection of open source packages which use cmake as the build tool, but I need the installation to be performed in a local directory (inside my home directory), and I wish convenient updating to new versions of the packages. I didn't arrive to a convincing solution, so any advice will be welcome. Here are my thoughts: The trivial solution is of course to directly install to a non-root prefix when invoking cmake, but, however, this isn't well suited for updating a previous installation of the packages (building and installing a new version will only overwrite files that have the same name, but it will keep old files that no longer exist in the new version, cluttering the local installation directory with no longer needed and mismatched files). A possibility would be to keep a copy of install_manifest.txt whenever I install a package, and remembering to always run 'xargs rm < install_manifest.txt' before installing a different version of a previously installed package. But keeping the install_manifest.txt of each installed package (and using it before updating a package) looks like a too-manual task, candidate to some kind of automation. Another (perhaps wiser) possibility would be to use cpack for creating either a RPM or DEB, and then use the corresponding package manager to install the package. But this has problems too: most package managers assume a / root installation directory. Also, I use several OSs: OSX, Linux, and some BSDs, and I'm not sure that either the RPM nor the DEB pkg managers will work flawlessly across all the OSs I use. What would you recommend here? Thanks a lot! From konstantin at podsvirov.pro Wed Jan 18 13:19:34 2017 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Wed, 18 Jan 2017 21:19:34 +0300 Subject: [CMake] Managing a local installation of cmake-built open source packages In-Reply-To: References: Message-ID: <313671484763574@web7j.yandex.ru> An HTML attachment was scrubbed... URL: From ardillasdelmonte at gmail.com Wed Jan 18 13:32:05 2017 From: ardillasdelmonte at gmail.com (ardi) Date: Wed, 18 Jan 2017 19:32:05 +0100 Subject: [CMake] Managing a local installation of cmake-built open source packages In-Reply-To: <313671484763574@web7j.yandex.ru> References: <313671484763574@web7j.yandex.ru> Message-ID: On Wed, Jan 18, 2017 at 7:19 PM, Konstantin Podsvirov wrote: > Hello Ardi! > [...] > > Sounds like, you need cross-platform (several desktops) package manager > compatible with cmake. > > If all desktops with GUI, what about using CPack IFW generator? > > https://cmake.org/cmake/help/latest/module/CPackIFW.html Thanks for the idea, Konstantin. Yes, all the OSs I use have a GUI, although I don't use Qt. If the best solution is IFW, I'd use Qt only for this. BTW, I'm new to IFW, and if I'm reading it correctly, cpack generates an installer, which I guess is an executable... but... can the installer also be used for uninstalling? Will an installer of a new version of a package uninstall an older version if it exists? From konstantin at podsvirov.pro Wed Jan 18 13:47:18 2017 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Wed, 18 Jan 2017 21:47:18 +0300 Subject: [CMake] Managing a local installation of cmake-built open source packages In-Reply-To: References: <313671484763574@web7j.yandex.ru> Message-ID: <403751484765238@web19o.yandex.ru> An HTML attachment was scrubbed... URL: From jsvanbethlehem at gmail.com Wed Jan 18 15:02:45 2017 From: jsvanbethlehem at gmail.com (Jakob van Bethlehem) Date: Wed, 18 Jan 2017 21:02:45 +0100 Subject: [CMake] cmake 3.7.2: add_custom_command can't DEPEND on OBJECT library? In-Reply-To: <1484436903.10997.61.camel@mad-scientist.net> References: <1484436903.10997.61.camel@mad-scientist.net> Message-ID: Hej, CMake experts may correct me if I'm wrong, but this is actually indeed not supported (yet). Even though an object-library looks like any ordinary library, in fact it is just a kind of 'shortcut' for a bunch of object files - it is *not* a proper cmake TARGET. Some additional explanation can be found here: https://cmake.org/cmake/help/latest/manual/cmake-buildsystem.7.html#object-libraries So, then the question obviously becomes how to achieve the desired result. If the creation of out.map only depends on that one source file, I'd expect you get the wanted result if instead of writing 'DEPENDS liblface', you write 'DEPENDS iface.cpp' - I'm not totally sure though. Sincerely, Jakob On Sun, Jan 15, 2017 at 12:35 AM, Paul Smith wrote: > If I create an OBJECT library: > > add_library(libIface OBJECT iface.cpp) > > Then I create a custom command that depends on this: > > add_custom_command(OUTPUT out.map > COMMAND touch out.map > DEPENDS libIface > VERBATIM) > > It doesn't work: the dependency is missing so when I edit the iface.cpp > file the custom command is not run. I'm using the Makefile generator, > on Linux, and if I look at the generated makefile it's obvious that > there's nothing there representing the OBJECT library: > > out.map: > @$(CMAKE_COMMAND) -E ... "Generating out.map" > touch out.map > > The documentation for add_custom_command() clearly says that DEPENDS can > specify "any target (created by the ... add_library() command)". > > Is there something missing from the docs that should say it doesn't work > with OBJECT libraries, or is this a bug in cmake? > > > Repro: > > -------------------------------------------------------------------- > $ cat CMakeLists.txt > cmake_minimum_required(VERSION 3.5) > project(MapTest) > > add_library(libIface OBJECT iface.cpp) > > add_custom_command(OUTPUT out.map > COMMAND touch out.map > DEPENDS libIface > VERBATIM) > > add_custom_target(libIfaceMap DEPENDS out.map) > > add_library(iface SHARED $ out.map) > > $ touch iface.cpp > > $ cmake . > > $ make > Scanning dependencies of target libIface > [ 33%] Building CXX object CMakeFiles/libIface.dir/iface.cpp.o > [ 33%] Built target libIface > [ 66%] Generating out.map > Scanning dependencies of target iface > [100%] Linking CXX shared library libiface.so > [100%] Built target iface > > $ touch iface.cpp > > $ make > Scanning dependencies of target libIface > [ 33%] Building CXX object CMakeFiles/libIface.dir/iface.cpp.o > [ 33%] Built target libIface > [ 66%] Linking CXX shared library libiface.so > [100%] Built target iface > -------------------------------------------------------------------- > > Note that in the last step the "out.map" file was not recreated even > though iface.cpp was modified. > -- > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dumont.guillaume at gmail.com Wed Jan 18 15:11:00 2017 From: dumont.guillaume at gmail.com (Guillaume Dumont) Date: Wed, 18 Jan 2017 15:11:00 -0500 Subject: [CMake] Managing a local installation of cmake-built open source packages In-Reply-To: <403751484765238@web19o.yandex.ru> References: <313671484763574@web7j.yandex.ru> <403751484765238@web19o.yandex.ru> Message-ID: You can have a look at: Hunter: https://github.com/ruslo/hunter Conan: https://conan.io/ HTH Guillaume On Wed, Jan 18, 2017 at 1:47 PM, Konstantin Podsvirov < konstantin at podsvirov.pro> wrote: > 18.01.2017, 21:32, "ardi" : > > On Wed, Jan 18, 2017 at 7:19 PM, Konstantin Podsvirov > wrote: > > Hello Ardi! > > > [...] > > > Sounds like, you need cross-platform (several desktops) package manager > compatible with cmake. > > If all desktops with GUI, what about using CPack IFW generator? > > https://cmake.org/cmake/help/latest/module/CPackIFW.html > > > Thanks for the idea, Konstantin. Yes, all the OSs I use have a GUI, > although I don't use Qt. If the best solution is IFW, I'd use Qt only > for this. BTW, I'm new to IFW, and if I'm reading it correctly, cpack > generates an installer, which I guess is an executable... but... can > the installer also be used for uninstalling? Will an installer of a > new version of a package uninstall an older version if it exists? > > CPack IFW generator help you to create installer (yes, it's executable > based on Qt, > but static linked) thats you need run on target platform (you don't have > preinstalled Qt). > > CPack IFW generator can also help you to create packages repository to use > from installers > (local or from network). > > Installer will remove old package before update him to new version. > > -- > 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 > -- Guillaume Dumont ========================= dumont.guillaume at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ardillasdelmonte at gmail.com Wed Jan 18 16:37:41 2017 From: ardillasdelmonte at gmail.com (ardi) Date: Wed, 18 Jan 2017 22:37:41 +0100 Subject: [CMake] Managing a local installation of cmake-built open source packages In-Reply-To: References: <313671484763574@web7j.yandex.ru> <403751484765238@web19o.yandex.ru> Message-ID: Thanks a lot, Guillaume, I didn't know about these tools, it's the first time I hear of hunter and conan. Thinking twice, I think that what I need is something similar to BSD ports, or MacPorts, but with the difference that I don't want to patch anything, just install and build the source as is, and in a multi build environment. It seems that both hunter and conan seem to be similar to BSD ports in nature, so I'll look at them. If anybody has further suggestions, please don't hesitate to tell. Thanks! On Wed, Jan 18, 2017 at 9:11 PM, Guillaume Dumont < dumont.guillaume at gmail.com > wrote: > You can have a look at: > > Hunter: https://github.com/ruslo/hunter > Conan: https://conan.io/ > > HTH > > Guillaume > > > On Wed, Jan 18, 2017 at 1:47 PM, Konstantin Podsvirov > > wrote: >> >> 18.01.2017, 21:32, "ardi" >: >> >> On Wed, Jan 18, 2017 at 7:19 PM, Konstantin Podsvirov >> > wrote: >> >> Hello Ardi! >> >> >> [...] >> >> >> >> Sounds like, you need cross-platform (several desktops) package manager >> compatible with cmake. >> >> If all desktops with GUI, what about using CPack IFW generator? >> >> https://cmake.org/cmake/help/latest/module/CPackIFW.html >> >> >> Thanks for the idea, Konstantin. Yes, all the OSs I use have a GUI, >> although I don't use Qt. If the best solution is IFW, I'd use Qt only >> for this. BTW, I'm new to IFW, and if I'm reading it correctly, cpack >> generates an installer, which I guess is an executable... but... can >> the installer also be used for uninstalling? Will an installer of a >> new version of a package uninstall an older version if it exists? >> >> CPack IFW generator help you to create installer (yes, it's executable >> based on Qt, >> but static linked) thats you need run on target platform (you don't have >> preinstalled Qt). >> >> CPack IFW generator can also help you to create packages repository to use >> from installers >> (local or from network). >> >> Installer will remove old package before update him to new version. >> >> -- >> 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 > > > > > -- > Guillaume Dumont > ========================= > dumont.guillaume at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From domen.vrankar at gmail.com Wed Jan 18 18:21:06 2017 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Thu, 19 Jan 2017 00:21:06 +0100 Subject: [CMake] Managing a local installation of cmake-built open source packages In-Reply-To: References: <313671484763574@web7j.yandex.ru> <403751484765238@web19o.yandex.ru> Message-ID: 2017-01-18 22:37 GMT+01:00 ardi : > If anybody has further suggestions, please don't hesitate to tell. > Alternative 1: I usually go with the platform supported packages even if that means having more than one package format... I prefer less custom dependencies to one-package-to-rule-them-all logic specially since most of the time programs already have to be recompiled on each platform. For me less custom dependencies is worth far more than having only one package type to maintain. Since you're saying that you can already install the files through CMake you've already won half the battle - the installation part is basis for all CPack packages (you set 2-3 variables and you have minimal RPM or DEB package(s) - even component packages if install commands have components). I don't know about the rest of the packagers but CPackRPM and Deb are quite similar in that regard so there is not too much of a learning curve. If you don't maintain the packages and they don't use CPack it's easy to append the rules at the end of the root CMakeLists.txt (I did that for C++ version of apache qpid a while back and produced minimal component RPM packages for AIX OS in under 5 minutes). Regarding installation on a different location as I said I'm not too familiar with the rest of the packagers but you can create a custom package database for both RPM and Deb packages and then install them on a different location (relocatable RPM or a bit hackish way with Deb packages - see LONG_FILENAMES/VerifiResult.cmake CMake test for an example with deb packages). Alternative 2: You were talking about install_manifest.txt file. CPack Archive packagier (particularly STGZ - self extracting tar gz - version) could easily be extended to produce such file and check for it on next install (asking you if you'd really like to delete the content or something similar). Contributing something like that to CPack would even remove the burden of maintaining a patched cpack version yourself. Drawbacks are that you loose files database that comes with rpm/deb (nobody will warn you if a file has been changed, was present in two packages etc.) and also the currently-not-supported-by-cpack part (but since it's fairly easy to implement we could probably get it into next CMake release). Regards, Domen -------------- next part -------------- An HTML attachment was scrubbed... URL: From elizabeth.fischer at columbia.edu Wed Jan 18 18:25:28 2017 From: elizabeth.fischer at columbia.edu (Elizabeth A. Fischer) Date: Wed, 18 Jan 2017 18:25:28 -0500 Subject: [CMake] Managing a local installation of cmake-built open source packages In-Reply-To: References: Message-ID: Ardi, What you describe is pretty much what Spack does. I would take a look at it, see if it meets your needs. Chances are, at least some of the packages you need are already included in Spack: https://github.com/llnl/spack -- Elizabeth On Wed, Jan 18, 2017 at 12:39 PM, ardi wrote: > Hi, > > I want to install (on UNIX-like systems) a collection of open source > packages which use cmake as the build tool, but I need the > installation to be performed in a local directory (inside my home > directory), and I wish convenient updating to new versions of the > packages. > > I didn't arrive to a convincing solution, so any advice will be welcome. > > Here are my thoughts: > > The trivial solution is of course to directly install to a non-root > prefix when invoking cmake, but, however, this isn't well suited for > updating a previous installation of the packages (building and > installing a new version will only overwrite files that have the same > name, but it will keep old files that no longer exist in the new > version, cluttering the local installation directory with no longer > needed and mismatched files). > > A possibility would be to keep a copy of install_manifest.txt whenever > I install a package, and remembering to always run 'xargs rm < > install_manifest.txt' before installing a different version of a > previously installed package. > > But keeping the install_manifest.txt of each installed package (and > using it before updating a package) looks like a too-manual task, > candidate to some kind of automation. > > Another (perhaps wiser) possibility would be to use cpack for creating > either a RPM or DEB, and then use the corresponding package manager to > install the package. But this has problems too: most package managers > assume a / root installation directory. Also, I use several OSs: OSX, > Linux, and some BSDs, and I'm not sure that either the RPM nor the DEB > pkg managers will work flawlessly across all the OSs I use. > > What would you recommend here? > > Thanks a lot! > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kris.f.thielemans at gmail.com Thu Jan 19 02:49:14 2017 From: kris.f.thielemans at gmail.com (Kris Thielemans) Date: Thu, 19 Jan 2017 07:49:14 -0000 Subject: [CMake] installing source (or object) files In-Reply-To: <000d01d2605c$009506b0$01bf1410$@gmail.com> References: <000d01d2605c$009506b0$01bf1410$@gmail.com> Message-ID: <048a01d27228$88b46df0$9a1d49d0$@gmail.com> Hi I haven't had any replies to my message below, hopefully because it was sent at the wrong time of year. So I'm reposting, but with some clarifications. I wrote the message about include_flags only. I've currently solved this by adding a variable Set(STIR_INCLUDE_DIRS blabla) in my STIRConfig.cmake.in (which is at https://github.com/UCL/UCL-STIR/blob/master/src/cmake/STIRConfig.cmake.in) and tell the user of the library that they have to do include_directories(${STIR_INCLUDE_DIRS}) This works but only for include directories, not for other compiler flags. I've currently solved that by putting all (most?) of these in a STIRConfig.h.in. I don't particularly like the include_directories solution however. I believe CMake's eport facility is trying to get away from this. Indeed, for the library, its include path (and other compilation flags) get automatically exported, so the user doesn't have to do anything else than target_link_libraries to inherit all necessary flags. Also, my current solution relies on exporting the .cxx. It seems safer to export the object file as that is guaranteed to have been compiled with the correct flags, but I don't know how to do that. I hope my message below makes more sense now. Thanks Kris From: Kris Thielemans Sent: 27 December 2016 16:12 To: cmake at cmake.org Subject: installing source (or object) files Hi all I have a non-standard set-up where I have a library that needs to be linked together with some extra source files that contain "registries"). So in my CMakeLists.txt I use Add_executable(wonderful_program wonderful_program.cxx registry.cxx) target_link_libraries(wonderful_program mylib) registry.cxx needs to be compiled with some of my include files. For that, I added include_directories("${PROJECT_SOURCE_DIR}/src/include") I guess I could just as well have added SET_PROPERTY(SOURCE registry.cxx PROPERTY COMPILE_FLAG "-I${STIR_INCLUDE_DIR}") This works fine, but now I want to export my library (relocatable). I have created a config file etc, added mylib as an install target, installed the include files etc. All of that works great for the library. However, I have no idea how to install registry.cxx. I could just INSTALL(FILES registry.cxx .) However, that doesn't copy the properties of the source files anywhere. In particular, it means that a "client" doesn't know what compilation flags to use. Any ideas? Best wishes for 2017! Kris PS: The reason that I need registry.cxx is that it contains some variables that have a funky constructor that initialises some registries somewhere. PS: Full source code is at https://github.com/UCL/STIR -------------- next part -------------- An HTML attachment was scrubbed... URL: From Martin.Wagner at neuberger.net Thu Jan 19 03:30:41 2017 From: Martin.Wagner at neuberger.net (Wagner Martin) Date: Thu, 19 Jan 2017 08:30:41 +0000 Subject: [CMake] install() rename with version string Message-ID: <56E920142ED81D4FBE3260E4B9D1DB3E97C2AB64@ROTSRV13.Neuberger.local> Hello, I?ve searched for some time, but didn?t find anything useful. Most finds deal with including version system stuff passed to header files for compilation. I want to achieve something like that: Include(version.cmake) install(FILES firmware.hex RENAME firmware_${version_string}.hex) where version.cmake is created like explained in this mail https://cmake.org/pipermail/cmake/2010-July/038015.html alongside headers needed for compilation. However, CMake needs to include version.cmake at first CMake run time, which is not possible because it?s a generated file. Is there any other way to do the rename? Thanks for your help! Regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.noulard at gmail.com Thu Jan 19 07:00:18 2017 From: eric.noulard at gmail.com (Eric Noulard) Date: Thu, 19 Jan 2017 13:00:18 +0100 Subject: [CMake] install() rename with version string In-Reply-To: <56E920142ED81D4FBE3260E4B9D1DB3E97C2AB64@ROTSRV13.Neuberger.local> References: <56E920142ED81D4FBE3260E4B9D1DB3E97C2AB64@ROTSRV13.Neuberger.local> Message-ID: You can try: include(version.cmake OPTIONAL) which will make include tolerate the absence of version.cmake, but then your install statement will only be OK after version.cmake has been created. 2017-01-19 9:30 GMT+01:00 Wagner Martin : > Hello, > > > > I?ve searched for some time, but didn?t find anything useful. Most finds > deal with including version system stuff passed to header files for > compilation. > > > > I want to achieve something like that: > > Include(version.cmake) > > install(FILES firmware.hex RENAME firmware_${version_string}.hex) > > > > where version.cmake is created like explained in this mail > https://cmake.org/pipermail/cmake/2010-July/038015.html alongside headers > needed for compilation. > > > > However, CMake needs to include version.cmake at first CMake run time, > which is not possible because it?s a generated file. > > > > Is there any other way to do the rename? > > > > Thanks for your help! > > > > Regards, > > Martin > > -- > > 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 > -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From Martin.Wagner at neuberger.net Thu Jan 19 08:07:46 2017 From: Martin.Wagner at neuberger.net (Wagner Martin) Date: Thu, 19 Jan 2017 13:07:46 +0000 Subject: [CMake] install() rename with version string In-Reply-To: References: <56E920142ED81D4FBE3260E4B9D1DB3E97C2AB64@ROTSRV13.Neuberger.local> Message-ID: <56E920142ED81D4FBE3260E4B9D1DB3E97C2AC8E@ROTSRV13.Neuberger.local> That doesn't work as CMake seems to only evaluate the include() statement once at first run. With the OPTIONAL statement, my project builds, but the ${version_string} variable is not populated. Von: Eric Noulard [mailto:eric.noulard at gmail.com] Gesendet: Donnerstag, 19. Januar 2017 13:00 An: Wagner Martin Cc: cmake at cmake.org Betreff: Re: [CMake] install() rename with version string You can try: include(version.cmake?OPTIONAL) which will make include tolerate the absence of version.cmake, but then your install statement will only be OK after version.cmake has been created. 2017-01-19 9:30 GMT+01:00 Wagner Martin : Hello, ? I?ve searched for some time, but didn?t find anything useful. Most finds deal with including version system stuff passed to header files for compilation. ? I want to achieve something like that: Include(version.cmake) install(FILES firmware.hex ?RENAME? firmware_${version_string}.hex) ? where version.cmake is created like explained in this mail https://cmake.org/pipermail/cmake/2010-July/038015.html alongside headers needed for compilation. ? However, CMake needs to include version.cmake at first CMake run time, which is not possible because it?s a generated file. ? Is there any other way to do the rename? ? Thanks for your help! ? Regards, Martin -- 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 -- Eric From ardillasdelmonte at gmail.com Thu Jan 19 08:57:19 2017 From: ardillasdelmonte at gmail.com (ardi) Date: Thu, 19 Jan 2017 14:57:19 +0100 Subject: [CMake] Managing a local installation of cmake-built open source packages In-Reply-To: References: Message-ID: Thanks a lot, Elisabeth, Domen, Guillaume, and Konstantin, I believe spack is the closest to what I need. However, all these solutions (hunter, conan, spack...) have perhaps their strongest focus in packaging, dependencies, automatic downloads, etc... while I prefer to do all such tasks myself. I prefer to not have packages, just download the source in the original developer provided form, untar it, and to even build it on my own, following the developer instructions. In other words, I want to be as little intrusive as possible, keeping the original distribution file as is. Once it's built, then it's the install phase what is critical, because a previous version of the package might need to be uninstalled, or there might even be files with equal names across different packages, as Domen pointed out. As I said, I think spack is the closest. However, I feel it tries to automate too much the build. Yes, it gives you a lot of customization options, but I'm not sure the complexity is worth the effort. However, I think I can follow the spack design without using spack: Install every project on a different prefix. Then just keep on the environment CMAKE_INSTALL_PREFIX set to a colon separated list of all prefixes of all installed projects, and that's it. Uninstalling is trivial: delete the installation directory. Keeping several versions of the same package is trivial too: just set the currently used version in CMAKE_INSTALL_PREFIX Updating is trivial as well: Install new version to a new prefix, and either keep or delete the installation directory of the previous version, and update CMAKE_INSTALL_PREFIX accordingly. Of course spack does all this automatically for you, but it does a lot more, and, as I said, I'm not sure the added complexity and automation is worth the effort. I think that by using this approach, I could reconsider moving to spack in the future (I'd likely have to install all packages from scratch if I move to spack later, but my directory hierarchy will end up being the same, so all the work I do now -writing code and projects- would be reusable without modification). Thanks a lot for all your ideas!! On Thu, Jan 19, 2017 at 12:25 AM, Elizabeth A. Fischer wrote: > Ardi, > > What you describe is pretty much what Spack does. I would take a look at > it, see if it meets your needs. Chances are, at least some of the packages > you need are already included in Spack: > > https://github.com/llnl/spack > > -- Elizabeth > > On Wed, Jan 18, 2017 at 12:39 PM, ardi wrote: >> >> Hi, >> >> I want to install (on UNIX-like systems) a collection of open source >> packages which use cmake as the build tool, but I need the >> installation to be performed in a local directory (inside my home >> directory), and I wish convenient updating to new versions of the >> packages. >> >> I didn't arrive to a convincing solution, so any advice will be welcome. >> >> Here are my thoughts: >> >> The trivial solution is of course to directly install to a non-root >> prefix when invoking cmake, but, however, this isn't well suited for >> updating a previous installation of the packages (building and >> installing a new version will only overwrite files that have the same >> name, but it will keep old files that no longer exist in the new >> version, cluttering the local installation directory with no longer >> needed and mismatched files). >> >> A possibility would be to keep a copy of install_manifest.txt whenever >> I install a package, and remembering to always run 'xargs rm < >> install_manifest.txt' before installing a different version of a >> previously installed package. >> >> But keeping the install_manifest.txt of each installed package (and >> using it before updating a package) looks like a too-manual task, >> candidate to some kind of automation. >> >> Another (perhaps wiser) possibility would be to use cpack for creating >> either a RPM or DEB, and then use the corresponding package manager to >> install the package. But this has problems too: most package managers >> assume a / root installation directory. Also, I use several OSs: OSX, >> Linux, and some BSDs, and I'm not sure that either the RPM nor the DEB >> pkg managers will work flawlessly across all the OSs I use. >> >> What would you recommend here? >> >> Thanks a lot! >> -- >> >> 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 > > From ggarra13 at gmail.com Thu Jan 19 09:26:47 2017 From: ggarra13 at gmail.com (=?UTF-8?Q?Gonzalo_Garramu=c3=b1o?=) Date: Thu, 19 Jan 2017 11:26:47 -0300 Subject: [CMake] install() rename with version string In-Reply-To: <56E920142ED81D4FBE3260E4B9D1DB3E97C2AB64@ROTSRV13.Neuberger.local> References: <56E920142ED81D4FBE3260E4B9D1DB3E97C2AB64@ROTSRV13.Neuberger.local> Message-ID: El 19/01/17 a las 05:30, Wagner Martin escribi?: > > However, CMake needs to include version.cmake at first CMake run time, > which is not possible because it?s a generated file. > > Is there any other way to do the rename? > > You will need to do the install as another target/command. For example: add_custom_command( TARGET version POST_BUILD COMMAND ${CMAKE_COMMAND} -D VERSION=${version_string} -P install_commands.cmake USES_TERMINAL ) -- Gonzalo Garramu?o -------------- next part -------------- An HTML attachment was scrubbed... URL: From theon.vliegenthart at philips.com Thu Jan 19 10:26:40 2017 From: theon.vliegenthart at philips.com (Vliegenthart, Theon) Date: Thu, 19 Jan 2017 15:26:40 +0000 Subject: [CMake] Cmake 3.7.2 use external compiler Message-ID: <1d5b09db30bb4c26ae936f82c54c70f9@VI1PR9001MB0175.MGDPHG.emi.philips.com> Hi, We use for our complex project the Cmake 2.4 for vXworks compiler from windriver. For the new project we want to update the cmake to 3.7.2, but vxworks is not yet supported any more. Therefore we have written an alternative toolchain file which is started with the following commando: cmake.exe" -DCMAKE_TOOLCHAIN_FILE=S:\..\....vxworks.cmake. In the file we define the compilers: SET(CMAKE_C_COMPILER ${COM_path}/dcc.exe) SET(CMAKE_CXX_COMPILER ${COM_path}/dplus.exe) (Crosscompiler process) Cmake test the ID of the compiler and do a separated test. Both tests lead to cmake errors in CMakeTestCCompiler. We want to disable this test but variable as "CMAKE_C_COMPILER_WORKS" is not supported. How can we solve this issue or the define an additional compiler? Founded error: "Start cmake (1)" ...... -- RTWDEVENV_DIR1 = c:/eqcp_reuse/EqCP/EqCP-dev/allPlatforms/matlab_include/RTW _DevEnv -- RTWDEVENV_DIR2 = c:/eqcp_reuse/EqCP/EqCP-dev/allPlatforms/matlab_include/RTW _DevEnv/R2016a -- EQCP_INCLUDE_DIR= c:/eqcp_reuse/EqCP/EqCP-dev/VxWorks6-smp-pcPentium/Debug/in clude -- EQCP_LIB_DIR = c:/eqcp_reuse/EqCP/EqCP-dev/VxWorks6-smp-pcPentium/Debug/li b TC: Path for CXX compiler C:/WindRiver/diab/5.8.0.0/WIN32/bin/dplus.exe TC: Build directory is:S:/S_Project/Stage/buildenv CMake Error at C:/Program Files/CMake 3.7.2/share/cmake-3.7/Modules/CMakeDetermi neCompilerId.cmake:506 (string): string begin index: 1 is out of range 0 - 0 Call Stack (most recent call first): C:/Program Files/CMake 3.7.2/share/cmake-3.7/Modules/CMakeDetermineCompilerId. cmake:36 (CMAKE_DETERMINE_COMPILER_ID_CHECK) C:/Program Files/CMake 3.7.2/share/cmake-3.7/Modules/CMakeDetermineCCompiler.c make:112 (CMAKE_DETERMINE_COMPILER_ID) CMakeLists.txt:143 (PROJECT) CMake Error at C:/Program Files/CMake 3.7.2/share/cmake-3.7/Modules/CMakeDetermi neCompilerId.cmake:514 (math): math cannot parse the expression: " * 16 + ": syntax error, unexpected exp_TIMES, expecting exp_OPENPARENT or exp_NUMBER (2) Call Stack (most recent call first): C:/Program Files/CMake 3.7.2/share/cmake-3.7/Modules/CMakeDetermineCompilerId. cmake:36 (CMAKE_DETERMINE_COMPILER_ID_CHECK) C:/Program Files/CMake 3.7.2/share/cmake-3.7/Modules/CMakeDetermineCCompiler.c make:112 (CMAKE_DETERMINE_COMPILER_ID) CMakeLists.txt:143 (PROJECT) CMake Error at C:/Program Files/CMake 3.7.2/share/cmake-3.7/Modules/CMakeDetermi neCompilerId.cmake:506 (string): string begin index: 1 is out of range 0 - 0 Call Stack (most recent call first): C:/Program Files/CMake 3.7.2/share/cmake-3.7/Modules/CMakeDetermineCompilerId. cmake:36 (CMAKE_DETERMINE_COMPILER_ID_CHECK) C:/Program Files/CMake 3.7.2/share/cmake-3.7/Modules/CMakeDetermineCCompiler.c make:112 (CMAKE_DETERMINE_COMPILER_ID) CMakeLists.txt:143 (PROJECT) CMake Error at C:/Program Files/CMake 3.7.2/share/cmake-3.7/Modules/CMakeDetermi neCompilerId.cmake:514 (math): math cannot parse the expression: " * 16 + ": syntax error, unexpected exp_TIMES, expecting exp_OPENPARENT or exp_NUMBER (2) Call Stack (most recent call first): C:/Program Files/CMake 3.7.2/share/cmake-3.7/Modules/CMakeDetermineCompilerId. cmake:36 (CMAKE_DETERMINE_COMPILER_ID_CHECK) C:/Program Files/CMake 3.7.2/share/cmake-3.7/Modules/CMakeDetermineCCompiler.c make:112 (CMAKE_DETERMINE_COMPILER_ID) CMakeLists.txt:143 (PROJECT) CMake Error at C:/Program Files/CMake 3.7.2/share/cmake-3.7/Modules/CMakeDetermi neCompilerId.cmake:506 (string): string begin index: 1 is out of range 0 - 0 Call Stack (most recent call first): C:/Program Files/CMake 3.7.2/share/cmake-3.7/Modules/CMakeDetermineCompilerId. cmake:36 (CMAKE_DETERMINE_COMPILER_ID_CHECK) C:/Program Files/CMake 3.7.2/share/cmake-3.7/Modules/CMakeDetermineCCompiler.c make:112 (CMAKE_DETERMINE_COMPILER_ID) CMakeLists.txt:143 (PROJECT) CMake Error at C:/Program Files/CMake 3.7.2/share/cmake-3.7/Modules/CMakeDetermi neCompilerId.cmake:514 (math): math cannot parse the expression: " * 16 + ": syntax error, unexpected exp_TIMES, expecting exp_OPENPARENT or exp_NUMBER (2) Call Stack (most recent call first): C:/Program Files/CMake 3.7.2/share/cmake-3.7/Modules/CMakeDetermineCompilerId. cmake:36 (CMAKE_DETERMINE_COMPILER_ID_CHECK) C:/Program Files/CMake 3.7.2/share/cmake-3.7/Modules/CMakeDetermineCCompiler.c make:112 (CMAKE_DETERMINE_COMPILER_ID) CMakeLists.txt:143 (PROJECT) -- The C compiler identification is unknown -- The CXX compiler identification is unknown -- Check for working C compiler: C:/WindRiver/diab/5.8.0.0/WIN32/bin/dcc.exe -- Check for working C compiler: C:/WindRiver/diab/5.8.0.0/WIN32/bin/dcc.exe -- works -- Detecting C compiler ABI info TC: Path for CXX compiler C:/WindRiver/diab/5.8.0.0/WIN32/bin/dplus.exe TC: Build directory is: -- Detecting C compiler ABI info - failed -- Check for working CXX compiler: C:/WindRiver/diab/5.8.0.0/WIN32/bin/dplus.exe -- Check for working CXX compiler: C:/WindRiver/diab/5.8.0.0/WIN32/bin/dplus.exe -- broken CMake Error at C:/Program Files/CMake 3.7.2/share/cmake-3.7/Modules/CMakeTestCXX Compiler.cmake:44 (message): The C++ compiler "C:/WindRiver/diab/5.8.0.0/WIN32/bin/dplus.exe" is not able to compile a simple test program. It fails with the following output: Change Dir: C:/BuildProjects/S_Project/proj_build/build/VxWorks6-smp-pcPentiu m/Debug/CMakeFiles/CMakeTmp Run Build Command:"C:/eqcp_reuse/external/sh_from_cygwin/make.exe" "cmTC_3e0e3/fast" /bin/make -f CMakeFiles/cmTC_3e0e3.dir/build.make CMakeFiles/cmTC_3e0e3.dir/build make[1]: Entering directory `/cygdrive/c/BuildProjects/S_Project/proj_build/build/VxWorks6-smp-pcPentium/D ebug/CMakeFiles/CMakeTmp' Building CXX object CMakeFiles/cmTC_3e0e3.dir/testCXXCompiler.cxx.obj C:/WindRiver/diab/5.8.0.0/WIN32/bin/dplus.exe -o CMakeFiles/cmTC_3e0e3.dir/testCXXCompiler.cxx.obj -c C:/BuildProjects/S_Project/proj_build/build/VxWorks6-smp-pcPentium/Debug/CMake Files/CMakeTmp/testCXXCompiler.cxx Target Unknown. Use the -t option or set a default target with dctrl -t make[1]: *** [CMakeFiles/cmTC_3e0e3.dir/testCXXCompiler.cxx.obj] Error 1 make[1]: Leaving directory `/cygdrive/c/BuildProjects/S_Project/proj_build/build/VxWorks6-smp-pcPentium/D ebug/CMakeFiles/CMakeTmp' make: *** [cmTC_3e0e3/fast] Error 2 CMake will not be able to correctly generate this project. Call Stack (most recent call first): CMakeLists.txt:143 (PROJECT) -- Configuring incomplete, errors occurred! See also "C:/BuildProjects/S_Project/proj_build/build/VxWorks6-smp-pcPentium/Deb ug/CMakeFiles/CMakeOutput.log". See also "C:/BuildProjects/S_Project/proj_build/build/VxWorks6-smp-pcPentium/Deb ug/CMakeFiles/CMakeError.log". Leaving generate-VxWorks6-smp-pcPentium-Debug.cmd Press any key to continue . . . Theon ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ardillasdelmonte at gmail.com Thu Jan 19 10:29:05 2017 From: ardillasdelmonte at gmail.com (ardi) Date: Thu, 19 Jan 2017 16:29:05 +0100 Subject: [CMake] Managing a local installation of cmake-built open source packages In-Reply-To: References: Message-ID: Typo in my last message: All occurrences of CMAKE_INSTALL_PREFIX were meant to be CMAKE_PREFIX_PATH instead. On Thu, Jan 19, 2017 at 2:57 PM, ardi wrote: > Thanks a lot, Elisabeth, Domen, Guillaume, and Konstantin, > > I believe spack is the closest to what I need. However, all these > solutions (hunter, conan, spack...) have perhaps their strongest focus > in packaging, dependencies, automatic downloads, etc... while I prefer > to do all such tasks myself. I prefer to not have packages, just > download the source in the original developer provided form, untar it, > and to even build it on my own, following the developer instructions. > In other words, I want to be as little intrusive as possible, keeping > the original distribution file as is. Once it's built, then it's the > install phase what is critical, because a previous version of the > package might need to be uninstalled, or there might even be files > with equal names across different packages, as Domen pointed out. > > As I said, I think spack is the closest. However, I feel it tries to > automate too much the build. Yes, it gives you a lot of customization > options, but I'm not sure the complexity is worth the effort. > > However, I think I can follow the spack design without using spack: > Install every project on a different prefix. Then just keep on the > environment CMAKE_INSTALL_PREFIX set to a colon separated list of all > prefixes of all installed projects, and that's it. > > Uninstalling is trivial: delete the installation directory. > Keeping several versions of the same package is trivial too: just set > the currently used version in CMAKE_INSTALL_PREFIX > Updating is trivial as well: Install new version to a new prefix, and > either keep or delete the installation directory of the previous > version, and update CMAKE_INSTALL_PREFIX accordingly. > > Of course spack does all this automatically for you, but it does a lot > more, and, as I said, I'm not sure the added complexity and automation > is worth the effort. > > I think that by using this approach, I could reconsider moving to > spack in the future (I'd likely have to install all packages from > scratch if I move to spack later, but my directory hierarchy will end > up being the same, so all the work I do now -writing code and > projects- would be reusable without modification). > > Thanks a lot for all your ideas!! > > > On Thu, Jan 19, 2017 at 12:25 AM, Elizabeth A. Fischer > wrote: >> Ardi, >> >> What you describe is pretty much what Spack does. I would take a look at >> it, see if it meets your needs. Chances are, at least some of the packages >> you need are already included in Spack: >> >> https://github.com/llnl/spack >> >> -- Elizabeth >> >> On Wed, Jan 18, 2017 at 12:39 PM, ardi wrote: >>> >>> Hi, >>> >>> I want to install (on UNIX-like systems) a collection of open source >>> packages which use cmake as the build tool, but I need the >>> installation to be performed in a local directory (inside my home >>> directory), and I wish convenient updating to new versions of the >>> packages. >>> >>> I didn't arrive to a convincing solution, so any advice will be welcome. >>> >>> Here are my thoughts: >>> >>> The trivial solution is of course to directly install to a non-root >>> prefix when invoking cmake, but, however, this isn't well suited for >>> updating a previous installation of the packages (building and >>> installing a new version will only overwrite files that have the same >>> name, but it will keep old files that no longer exist in the new >>> version, cluttering the local installation directory with no longer >>> needed and mismatched files). >>> >>> A possibility would be to keep a copy of install_manifest.txt whenever >>> I install a package, and remembering to always run 'xargs rm < >>> install_manifest.txt' before installing a different version of a >>> previously installed package. >>> >>> But keeping the install_manifest.txt of each installed package (and >>> using it before updating a package) looks like a too-manual task, >>> candidate to some kind of automation. >>> >>> Another (perhaps wiser) possibility would be to use cpack for creating >>> either a RPM or DEB, and then use the corresponding package manager to >>> install the package. But this has problems too: most package managers >>> assume a / root installation directory. Also, I use several OSs: OSX, >>> Linux, and some BSDs, and I'm not sure that either the RPM nor the DEB >>> pkg managers will work flawlessly across all the OSs I use. >>> >>> What would you recommend here? >>> >>> Thanks a lot! >>> -- >>> >>> 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 >> >> From post at hendrik-sattler.de Thu Jan 19 11:02:32 2017 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Thu, 19 Jan 2017 17:02:32 +0100 Subject: [CMake] install() rename with version string In-Reply-To: References: <56E920142ED81D4FBE3260E4B9D1DB3E97C2AB64@ROTSRV13.Neuberger.local> Message-ID: <60DEEBA7-6F29-4A3F-8F92-D08DEE3E2F1B@hendrik-sattler.de> Am 19. Januar 2017 15:26:47 MEZ schrieb "Gonzalo Garramu?o" : > > >El 19/01/17 a las 05:30, Wagner Martin escribi?: >> >> However, CMake needs to include version.cmake at first CMake run >time, >> which is not possible because it?s a generated file. >> >> Is there any other way to do the rename? >> >> >You will need to do the install as another target/command. For >example: > >add_custom_command( TARGET version > POST_BUILD > COMMAND ${CMAKE_COMMAND} -D >VERSION=${version_string} > -P install_commands.cmake > USES_TERMINAL ) Or even simpler, do all of that in the install_commands.cmake by using install(CODE) AND escaping the $. Just looking at the generated install_commands.cmake will make this much clearer. HS -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. From mellery451 at gmail.com Thu Jan 19 11:07:03 2017 From: mellery451 at gmail.com (Michael Ellery) Date: Thu, 19 Jan 2017 08:07:03 -0800 Subject: [CMake] installing source (or object) files In-Reply-To: <048a01d27228$88b46df0$9a1d49d0$@gmail.com> References: <000d01d2605c$009506b0$01bf1410$@gmail.com> <048a01d27228$88b46df0$9a1d49d0$@gmail.com> Message-ID: <51CD56C5-4D58-4093-9DA7-322152CCDDD3@gmail.com> I think my initial reaction to installing a source (cxx) file is that you should install a static library instead (.a) - which is basically what you are suggesting. Just define a new static library target that includes the cxx file and install it?should work fine. If there are headers needed to use that static lib, you install those as well. There is a third type of library target called OBJECT, but those are usually just for use in the context of a build and not meant to be installed (if i recall correctly?). HTH, Mike Ellery > On Jan 18, 2017, at 11:49 PM, Kris Thielemans wrote: > > Hi > > I haven?t had any replies to my message below, hopefully because it was sent at the wrong time of year? So I?m reposting, but with some clarifications. > > I wrote the message about include_flags only. I?ve currently solved this by adding a variable > > Set(STIR_INCLUDE_DIRS blabla) > > in my STIRConfig.cmake.in (which is at https://github.com/UCL/UCL-STIR/blob/master/src/cmake/STIRConfig.cmake.in) > > and tell the user of the library that they have to do > > include_directories(${STIR_INCLUDE_DIRS}) > > This works but only for include directories, not for other compiler flags. I?ve currently solved that by putting all (most?) of these in a STIRConfig.h.in. > > I don?t particularly like the include_directories solution however. I believe CMake?s eport facility is trying to get away from this. Indeed, for the library, its include path (and other compilation flags) get automatically exported, so the user doesn?t have to do anything else than target_link_libraries to inherit all necessary flags. > > Also, my current solution relies on exporting the .cxx. It seems safer to export the object file as that is guaranteed to have been compiled with the correct flags, but I don?t know how to do that. > > I hope my message below makes more sense now. > > Thanks > > Kris > From: Kris Thielemans > Sent: 27 December 2016 16:12 > To: cmake at cmake.org > Subject: installing source (or object) files > > Hi all > > I have a non-standard set-up where I have a library that needs to be linked together with some extra source files that contain ?registries?). So in my CMakeLists.txt I use > > Add_executable(wonderful_program wonderful_program.cxx registry.cxx) > target_link_libraries(wonderful_program mylib) > > registry.cxx needs to be compiled with some of my include files. > > For that, I added > > include_directories(?${PROJECT_SOURCE_DIR}/src/include?) > > I guess I could just as well have added > > SET_PROPERTY(SOURCE registry.cxx PROPERTY COMPILE_FLAG "-I${STIR_INCLUDE_DIR}") > > > This works fine, but now I want to export my library (relocatable). I have created a config file etc, added mylib as an install target, installed the include files etc. All of that works great for the library. However, I have no idea how to install registry.cxx. I could just > > INSTALL(FILES registry.cxx ?) > > However, that doesn?t copy the properties of the source files anywhere. In particular, it means that a ?client? doesn?t know what compilation flags to use. > > Any ideas? > > Best wishes for 2017! > > Kris > > PS: The reason that I need registry.cxx is that it contains some variables that have a funky constructor that initialises some registries somewhere. > PS: Full source code is at https://github.com/UCL/STIR > -- > > 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 From elizabeth.fischer at columbia.edu Thu Jan 19 11:09:10 2017 From: elizabeth.fischer at columbia.edu (Elizabeth A. Fischer) Date: Thu, 19 Jan 2017 11:09:10 -0500 Subject: [CMake] Managing a local installation of cmake-built open source packages In-Reply-To: References: Message-ID: Aldi, > I believe spack is the closest to what I need. However, all these > solutions (hunter, conan, spack...) have perhaps their strongest focus > in packaging, dependencies, automatic downloads, etc... while I prefer > to do all such tasks myself. I prefer to not have packages, just download the source in the original developer provided form, untar it, > and to even build it on my own, following the developer instructions. > That is exactly what Spack does. A Spack "package" is really just a recipe that automates those tasks. I think of the Spack recipe as a Python encoding of the English-language build instructions. In fact, when I want to know how a package is built, I prefer to look at the Spack recipe. It's more concise than English, and frequently more complete. > As I said, I think spack is the closest. However, I feel it tries to > automate too much the build. Yes, it gives you a lot of customization > options, but I'm not sure the complexity is worth the effort. > Spack should work out-of-the-box without customizing things. Many of the features --- shell integration, environment modules, etc --- are not strictly necessary. You might be interested in the `spack setup` command, which currently works with CMake-based projects. It is especially good for projects you're developing, or otherwise already have the source code in your directory. I use this feature to configure all the projects I'm working on. To use Spack setup, you do the following: 1. Download and untar the software yourself, in your favorite location. (This is especially useful for development versions that don't yet have a tarball). 2. Run `spack setup`. This creates a script whose purpose it is to call CMake with appropriate options for dependencies and install location. 3. Run the Spack-generated script in place of CMake 4. Build and install yourself. http://spack.readthedocs.io/en/latest/workflows.html?highlight=spack%20setup Here's an example... $ tar xvfz myproject.tar.gz $ cd myproject $ spack setup myproject at develop $ mkdir build $ cd build $ ../spconfig.py .. # Calls through to CMake $ make $ make install > I think that by using this approach, I could reconsider moving to > spack in the future (I'd likely have to install all packages from > scratch if I move to spack later, but my directory hierarchy will end > up being the same, so all the work I do now -writing code and > projects- would be reusable without modification). > With an auto-builder, I've found that re-installing everything is no big deal. I can re-install 100 packages in a few hours of wall time, and no more than a few minutes of my time. -- Elizabeth -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidklind at gmail.com Thu Jan 19 13:00:48 2017 From: davidklind at gmail.com (David Lind) Date: Thu, 19 Jan 2017 11:00:48 -0700 Subject: [CMake] CCACHE_DIR Environment Variable Message-ID: <9365318C-BFD1-45B7-96AE-3A1542CD188B@gmail.com> I am porting existing makefiles to cmake. One of the key features of these makefiles is setting the CCACHE_DIR environment variable based upon the tool chain selected. I have TC_.cmake files created. Ideally, I would add a line to these files to set the CCACHE_DIR. But, CMake doesn?t have the ability to set environment variables during the build step. So, I?m stuck. Has anyone encountered this kind of situation? ?Dave From craig.scott at crascit.com Thu Jan 19 14:57:36 2017 From: craig.scott at crascit.com (Craig Scott) Date: Fri, 20 Jan 2017 06:57:36 +1100 Subject: [CMake] CCACHE_DIR Environment Variable In-Reply-To: <9365318C-BFD1-45B7-96AE-3A1542CD188B@gmail.com> References: <9365318C-BFD1-45B7-96AE-3A1542CD188B@gmail.com> Message-ID: Rather than relying on environment variables, you can use CMake's find_program() command to find ccache on your path and then tell CMake to use that as a launcher. You can find an article with a detailed explanation of how to set this up here: https://crascit.com/2016/04/09/using-ccache-with-cmake/ An advantage of this approach is that the build will work with or without ccache installed. We've been using this in production for some time now and it works very smoothly. The technique can probably also be extended to support Windows too with clcache , but I haven't tried that yet. On Fri, Jan 20, 2017 at 5:00 AM, David Lind wrote: > I am porting existing makefiles to cmake. One of the key features of these > makefiles is setting the CCACHE_DIR environment variable based upon the > tool chain selected. > > I have TC_.cmake files created. Ideally, I would add a line to > these files to set the CCACHE_DIR. But, CMake doesn?t have the ability to > set environment variables during the build step. So, I?m stuck. > > Has anyone encountered this kind of situation? > > ?Dave > -- > > 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 -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidklind at gmail.com Thu Jan 19 15:44:43 2017 From: davidklind at gmail.com (David Lind) Date: Thu, 19 Jan 2017 13:44:43 -0700 Subject: [CMake] CCACHE_DIR Environment Variable In-Reply-To: References: <9365318C-BFD1-45B7-96AE-3A1542CD188B@gmail.com> Message-ID: <263BD9FE-940B-4864-8066-44BE11479FE1@gmail.com> Scott, I have find_program implemented to find ccache, as shown below. find_program(CCACHE ccache) if(CCACHE) set_property(GLOBAL PROPERTY RULE_LAUNCH_COMPILE ${CCACHE}) set_property(GLOBAL PROPERTY RULE_LAUNCH_LINK ${CCACHE}) endif() That?s not the issue. The issue is telling ccache where to place it?s cache files. If I compiles for toolchain X, Y and X, I need to set CCACHE_DIR accordingly. Otherwise the cache will be useless. ?Dave > On Jan 19, 2017, at 12:57 PM, Craig Scott wrote: > > Rather than relying on environment variables, you can use CMake's find_program() command to find ccache on your path and then tell CMake to use that as a launcher. You can find an article with a detailed explanation of how to set this up here: > > https://crascit.com/2016/04/09/using-ccache-with-cmake/ > > An advantage of this approach is that the build will work with or without ccache installed. We've been using this in production for some time now and it works very smoothly. The technique can probably also be extended to support Windows too with clcache , but I haven't tried that yet. > > > On Fri, Jan 20, 2017 at 5:00 AM, David Lind > wrote: > I am porting existing makefiles to cmake. One of the key features of these makefiles is setting the CCACHE_DIR environment variable based upon the tool chain selected. > > I have TC_.cmake files created. Ideally, I would add a line to these files to set the CCACHE_DIR. But, CMake doesn?t have the ability to set environment variables during the build step. So, I?m stuck. > > Has anyone encountered this kind of situation? > > ?Dave > -- > > 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 > > > -- > Craig Scott > Melbourne, Australia > https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dflogeras2 at gmail.com Thu Jan 19 16:00:56 2017 From: dflogeras2 at gmail.com (Dave Flogeras) Date: Thu, 19 Jan 2017 17:00:56 -0400 Subject: [CMake] CCACHE_DIR Environment Variable In-Reply-To: <263BD9FE-940B-4864-8066-44BE11479FE1@gmail.com> References: <9365318C-BFD1-45B7-96AE-3A1542CD188B@gmail.com> <263BD9FE-940B-4864-8066-44BE11479FE1@gmail.com> Message-ID: On Thu, Jan 19, 2017 at 4:44 PM, David Lind wrote: > That?s not the issue. The issue is telling ccache where to place it?s > cache files. If I compiles for toolchain X, Y and X, I need to set > CCACHE_DIR accordingly. Otherwise the cache will be useless. > > https://ccache.samba.org/manual.html#_common_hashed_information It seems that ccache includes stuff specific to the exact compiler when calculating its hashes, which means as long as your CCACHE_DIR is big enough, it will keep all the object code straight (and separated by compiler) -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Thu Jan 19 16:11:06 2017 From: craig.scott at crascit.com (Craig Scott) Date: Fri, 20 Jan 2017 08:11:06 +1100 Subject: [CMake] CCACHE_DIR Environment Variable In-Reply-To: <263BD9FE-940B-4864-8066-44BE11479FE1@gmail.com> References: <9365318C-BFD1-45B7-96AE-3A1542CD188B@gmail.com> <263BD9FE-940B-4864-8066-44BE11479FE1@gmail.com> Message-ID: Ah, sorry, I misunderstood what CCACHE_DIR was for. Nevertheless, the method in that linked article could be easily modified to do what you want. Simply add the setting of the environment variable to the launch scripts. Since those launch scripts are copied across to the build dir at configure time and they support variable substitutions, you can even have the value of CCACHE_DIR be settable from CMake if you want. For example, your launch-c.in file could look like this: #!/bin/sh export CCACHE_CPP2=true export CCACHE_DIR=${CCACHE_DIR} exec "${RULE_LAUNCH_COMPILE}" "${CMAKE_C_COMPILER}" "$@" When you run CMake, it substitutes the value of each of the above variables as they are set when the configure_file() command is called. Therefore, the configure step bakes in the value of CCACHE_DIR and it won't need to be set in your environment when you do the build step. Note that the substitutions are substituting CMake variables, not environment variables, so if you wanted to pass through a CCACHE_DIR environment variable instead, you would do something like this: #!/bin/sh export CCACHE_CPP2=true export CCACHE_DIR=$*ENV*{CCACHE_DIR} exec "${RULE_LAUNCH_COMPILE}" "${CMAKE_C_COMPILER}" "$@" Probably better to do that in your CMakeLists.txt instead though and leave the launch-c.in script as in the first case above. This would mean your CMakeLists.txt would have a line like this somewhere: set(CCACHE_DIR $ENV{CCACHE_DIR}). Note, however, that relying on environment variables for configure or build steps is not so robust. If, for example, you change a CMakeLists.txt file or something else in your project requires CMake to be re-run, then CMake can re-run as part of a build. This then means the environment variables have to be the same between your CMake runs and your build runs. That's normally not a problem for most people, but thought I'd mention it just in case. Personally, I try to avoid relying on environment variables and instead have such values passed in as CMake cache variables like so: cmake -G Ninja -DCCACHE_DIR=${CCACHE_DIR} ../src This saves the value in the cache and then it is preserved regardless of what environment I have when I do subsequent build steps. On Fri, Jan 20, 2017 at 7:44 AM, David Lind wrote: > Scott, > > I have find_program implemented to find ccache, as shown below. > > find_program(CCACHE ccache) > if(CCACHE) > set_property(GLOBAL PROPERTY RULE_LAUNCH_COMPILE ${CCACHE}) > set_property(GLOBAL PROPERTY RULE_LAUNCH_LINK ${CCACHE}) > endif() > > That?s not the issue. The issue is telling ccache where to place it?s > cache files. If I compiles for toolchain X, Y and X, I need to set > CCACHE_DIR accordingly. Otherwise the cache will be useless. > > ?Dave > > On Jan 19, 2017, at 12:57 PM, Craig Scott wrote: > > Rather than relying on environment variables, you can use CMake's > find_program() command to find ccache on your path and then tell CMake to > use that as a launcher. You can find an article with a detailed explanation > of how to set this up here: > > https://crascit.com/2016/04/09/using-ccache-with-cmake/ > > An advantage of this approach is that the build will work with or without > ccache installed. We've been using this in production for some time now and > it works very smoothly. The technique can probably also be extended to > support Windows too with clcache , > but I haven't tried that yet. > > > On Fri, Jan 20, 2017 at 5:00 AM, David Lind wrote: > >> I am porting existing makefiles to cmake. One of the key features of >> these makefiles is setting the CCACHE_DIR environment variable based upon >> the tool chain selected. >> >> I have TC_.cmake files created. Ideally, I would add a line to >> these files to set the CCACHE_DIR. But, CMake doesn?t have the ability to >> set environment variables during the build step. So, I?m stuck. >> >> Has anyone encountered this kind of situation? >> >> ?Dave >> -- >> >> 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 > > > > > -- > Craig Scott > Melbourne, Australia > https://crascit.com > > > -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From kris.f.thielemans at gmail.com Thu Jan 19 16:23:49 2017 From: kris.f.thielemans at gmail.com (Kris Thielemans) Date: Thu, 19 Jan 2017 21:23:49 -0000 Subject: [CMake] installing source (or object) files In-Reply-To: <51CD56C5-4D58-4093-9DA7-322152CCDDD3@gmail.com> References: <000d01d2605c$009506b0$01bf1410$@gmail.com> <048a01d27228$88b46df0$9a1d49d0$@gmail.com> <51CD56C5-4D58-4093-9DA7-322152CCDDD3@gmail.com> Message-ID: <058f01d2729a$53bed0f0$fb3c72d0$@gmail.com> Thanks Mike The motivation for linking explicitly with the object file was in the PS at the bottom, although only very brief of course. The registry.cxx file has static variables with constructors with side effects (they add entries to a std:::map that registers "factories"). Therefore, registry.cxx refers to stuff in mylib, but neither wonderful_program.cxx nor mylib refers to stuff in registry.cxx. If I stick registry.cxx into a library (I could have used mylib for instance), the linker happily removes it from the wonderful_program executable (as it thinks its an irrelevant object file). Result: the std::map never gets initialised. The only way (that I know) to fix this is to link explicitly with registry.o. Then the linker keeps it, hence the variables get initialised, hence the std::map does. This is I believe a relatively standard trick, although I'm not 100% happy with it. If anyone has a replacement for that, I'd be happy to know (but it's probably not for the CMake list). Hope this clarifies why I need to export registry.cxx (or its object file). Kris -----Original Message----- From: Michael Ellery Sent: 19 January 2017 16:07 To: Kris Thielemans Cc: cmake at cmake.org Subject: Re: [CMake] installing source (or object) files I think my initial reaction to installing a source (cxx) file is that you should install a static library instead (.a) - which is basically what you are suggesting. Just define a new static library target that includes the cxx file and install it?should work fine. If there are headers needed to use that static lib, you install those as well. There is a third type of library target called OBJECT, but those are usually just for use in the context of a build and not meant to be installed (if i recall correctly?). HTH, Mike Ellery > On Jan 18, 2017, at 11:49 PM, Kris Thielemans wrote: > > Hi > > I haven?t had any replies to my message below, hopefully because it was sent at the wrong time of year? So I?m reposting, but with some clarifications. > > I wrote the message about include_flags only. I?ve currently solved > this by adding a variable > > Set(STIR_INCLUDE_DIRS blabla) > > in my STIRConfig.cmake.in (which is at > https://github.com/UCL/UCL-STIR/blob/master/src/cmake/STIRConfig.cmake > .in) > > and tell the user of the library that they have to do > > include_directories(${STIR_INCLUDE_DIRS}) > > This works but only for include directories, not for other compiler flags. I?ve currently solved that by putting all (most?) of these in a STIRConfig.h.in. > > I don?t particularly like the include_directories solution however. I believe CMake?s eport facility is trying to get away from this. Indeed, for the library, its include path (and other compilation flags) get automatically exported, so the user doesn?t have to do anything else than target_link_libraries to inherit all necessary flags. > > Also, my current solution relies on exporting the .cxx. It seems safer to export the object file as that is guaranteed to have been compiled with the correct flags, but I don?t know how to do that. > > I hope my message below makes more sense now. > > Thanks > > Kris > From: Kris Thielemans > Sent: 27 December 2016 16:12 > To: cmake at cmake.org > Subject: installing source (or object) files > > Hi all > > I have a non-standard set-up where I have a library that needs to be > linked together with some extra source files that contain > ?registries?). So in my CMakeLists.txt I use > > Add_executable(wonderful_program wonderful_program.cxx registry.cxx) > target_link_libraries(wonderful_program mylib) > > registry.cxx needs to be compiled with some of my include files. > > For that, I added > > include_directories(?${PROJECT_SOURCE_DIR}/src/include?) > > I guess I could just as well have added > > SET_PROPERTY(SOURCE registry.cxx PROPERTY COMPILE_FLAG > "-I${STIR_INCLUDE_DIR}") > > > This works fine, but now I want to export my library (relocatable). I > have created a config file etc, added mylib as an install target, > installed the include files etc. All of that works great for the > library. However, I have no idea how to install registry.cxx. I could > just > > INSTALL(FILES registry.cxx ?) > > However, that doesn?t copy the properties of the source files anywhere. In particular, it means that a ?client? doesn?t know what compilation flags to use. > > Any ideas? > > Best wishes for 2017! > > Kris > > PS: The reason that I need registry.cxx is that it contains some variables that have a funky constructor that initialises some registries somewhere. > PS: Full source code is at https://github.com/UCL/STIR > -- > > 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 From craig.scott at crascit.com Thu Jan 19 16:40:00 2017 From: craig.scott at crascit.com (Craig Scott) Date: Fri, 20 Jan 2017 08:40:00 +1100 Subject: [CMake] installing source (or object) files In-Reply-To: <058f01d2729a$53bed0f0$fb3c72d0$@gmail.com> References: <000d01d2605c$009506b0$01bf1410$@gmail.com> <048a01d27228$88b46df0$9a1d49d0$@gmail.com> <51CD56C5-4D58-4093-9DA7-322152CCDDD3@gmail.com> <058f01d2729a$53bed0f0$fb3c72d0$@gmail.com> Message-ID: If you are using symbol visibility/exports, then marking the symbol as exported may prevent the linker from removing it if the code is going into a shared library (including static libraries that are built up into a shared library). It's not a trivial topic though, so you would need to do some reading up to get up to speed. Some starting points which may help: https://cmake.org/cmake/help/latest/policy/CMP0063.html https://cmake.org/cmake/help/latest/module/GenerateExportHeader.html https://gcc.gnu.org/wiki/Visibility On Fri, Jan 20, 2017 at 8:23 AM, Kris Thielemans < kris.f.thielemans at gmail.com> wrote: > Thanks Mike > > The motivation for linking explicitly with the object file was in the PS > at the bottom, although only very brief of course. > > The registry.cxx file has static variables with constructors with side > effects (they add entries to a std:::map that registers "factories"). > Therefore, registry.cxx refers to stuff in mylib, but neither > wonderful_program.cxx nor mylib refers to stuff in registry.cxx. If I stick > registry.cxx into a library (I could have used mylib for instance), the > linker happily removes it from the wonderful_program executable (as it > thinks its an irrelevant object file). Result: the std::map never gets > initialised. The only way (that I know) to fix this is to link explicitly > with registry.o. Then the linker keeps it, hence the variables get > initialised, hence the std::map does. > > This is I believe a relatively standard trick, although I'm not 100% happy > with it. If anyone has a replacement for that, I'd be happy to know (but > it's probably not for the CMake list). > > Hope this clarifies why I need to export registry.cxx (or its object file). > > Kris > > -----Original Message----- > From: Michael Ellery > Sent: 19 January 2017 16:07 > To: Kris Thielemans > Cc: cmake at cmake.org > Subject: Re: [CMake] installing source (or object) files > > I think my initial reaction to installing a source (cxx) file is that you > should install a static library instead (.a) - which is basically what you > are suggesting. Just define a new static library target that includes the > cxx file and install it?should work fine. If there are headers needed to > use that static lib, you install those as well. There is a third type of > library target called OBJECT, but those are usually just for use in the > context of a build and not meant to be installed (if i recall correctly?). > > HTH, > Mike Ellery > > > On Jan 18, 2017, at 11:49 PM, Kris Thielemans wrote: > > > > Hi > > > > I haven?t had any replies to my message below, hopefully because it was > sent at the wrong time of year? So I?m reposting, but with some > clarifications. > > > > I wrote the message about include_flags only. I?ve currently solved > > this by adding a variable > > > > Set(STIR_INCLUDE_DIRS blabla) > > > > in my STIRConfig.cmake.in (which is at > > https://github.com/UCL/UCL-STIR/blob/master/src/cmake/STIRConfig.cmake > > .in) > > > > and tell the user of the library that they have to do > > > > include_directories(${STIR_INCLUDE_DIRS}) > > > > This works but only for include directories, not for other compiler > flags. I?ve currently solved that by putting all (most?) of these in a > STIRConfig.h.in. > > > > I don?t particularly like the include_directories solution however. I > believe CMake?s eport facility is trying to get away from this. Indeed, for > the library, its include path (and other compilation flags) get > automatically exported, so the user doesn?t have to do anything else than > target_link_libraries to inherit all necessary flags. > > > > Also, my current solution relies on exporting the .cxx. It seems safer > to export the object file as that is guaranteed to have been compiled with > the correct flags, but I don?t know how to do that. > > > > I hope my message below makes more sense now. > > > > Thanks > > > > Kris > > From: Kris Thielemans > > Sent: 27 December 2016 16:12 > > To: cmake at cmake.org > > Subject: installing source (or object) files > > > > Hi all > > > > I have a non-standard set-up where I have a library that needs to be > > linked together with some extra source files that contain > > ?registries?). So in my CMakeLists.txt I use > > > > Add_executable(wonderful_program wonderful_program.cxx registry.cxx) > > target_link_libraries(wonderful_program mylib) > > > > registry.cxx needs to be compiled with some of my include files. > > > > For that, I added > > > > include_directories(?${PROJECT_SOURCE_DIR}/src/include?) > > > > I guess I could just as well have added > > > > SET_PROPERTY(SOURCE registry.cxx PROPERTY COMPILE_FLAG > > "-I${STIR_INCLUDE_DIR}") > > > > > > This works fine, but now I want to export my library (relocatable). I > > have created a config file etc, added mylib as an install target, > > installed the include files etc. All of that works great for the > > library. However, I have no idea how to install registry.cxx. I could > > just > > > > INSTALL(FILES registry.cxx ?) > > > > However, that doesn?t copy the properties of the source files anywhere. > In particular, it means that a ?client? doesn?t know what compilation flags > to use. > > > > Any ideas? > > > > Best wishes for 2017! > > > > Kris > > > > PS: The reason that I need registry.cxx is that it contains some > variables that have a funky constructor that initialises some registries > somewhere. > > PS: Full source code is at https://github.com/UCL/STIR > > -- > > > > 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 > > > -- > > 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 -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From boxerab at gmail.com Thu Jan 19 18:59:37 2017 From: boxerab at gmail.com (Aaron Boxer) Date: Thu, 19 Jan 2017 18:59:37 -0500 Subject: [CMake] Strange test failure Message-ID: I have a test in my ctest suite that fails both with and without a ! at the beginning of the test. So, FOO -BAR -BAZ fails and !FOO -BAR -BAZ fails. Any ideas, or how can I get more info on the failure ? Thanks. Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Fri Jan 20 02:40:57 2017 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 20 Jan 2017 08:40:57 +0100 Subject: [CMake] Strange test failure In-Reply-To: References: Message-ID: On 01/20/2017 12:59 AM, Aaron Boxer wrote: > I have a test in my ctest suite that fails both with > and without a ! at the beginning of the test. > > So, > > FOO -BAR -BAZ > > fails > > and > > !FOO -BAR -BAZ > > fails. I am not aware of "!" having any special meaning in the context of CTest. Can you elaborate? > > Any ideas, or how can I get more info on the failure ? ctest -V or ctest --output-on-failure might help. What type of failure does CTest indicate? Nils From Martin.Wagner at neuberger.net Fri Jan 20 03:36:54 2017 From: Martin.Wagner at neuberger.net (Wagner Martin) Date: Fri, 20 Jan 2017 08:36:54 +0000 Subject: [CMake] install() rename with version string In-Reply-To: <60DEEBA7-6F29-4A3F-8F92-D08DEE3E2F1B@hendrik-sattler.de> References: <56E920142ED81D4FBE3260E4B9D1DB3E97C2AB64@ROTSRV13.Neuberger.local> <60DEEBA7-6F29-4A3F-8F92-D08DEE3E2F1B@hendrik-sattler.de> Message-ID: <56E920142ED81D4FBE3260E4B9D1DB3E97C2AD40@ROTSRV13.Neuberger.local> Thanks for your answers. > >You will need to do the install as another target/command. For > >example: > > > >add_custom_command( TARGET version > > POST_BUILD > > COMMAND ${CMAKE_COMMAND} -D > >VERSION=${version_string} > > -P install_commands.cmake > > USES_TERMINAL ) > > Or even simpler, do all of that in the install_commands.cmake by using > install(CODE) AND escaping the $. > Just looking at the generated install_commands.cmake will make this much > clearer. > I think I don't properly understand what you mean. Can you please give me an example? I've tried install(CODE " Include(version.cmake) install(FILES firmware.hex RENAME firmware_\${version_string}.hex DESTINATION firmware) ") This is correctly expanded in generated "cmake_install.cmake" script, runs without errors, but does not install the file. From post at hendrik-sattler.de Fri Jan 20 06:03:57 2017 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Fri, 20 Jan 2017 12:03:57 +0100 Subject: [CMake] install() rename with version string In-Reply-To: <56E920142ED81D4FBE3260E4B9D1DB3E97C2AD40@ROTSRV13.Neuberger.local> References: <56E920142ED81D4FBE3260E4B9D1DB3E97C2AB64@ROTSRV13.Neuberger.local> <60DEEBA7-6F29-4A3F-8F92-D08DEE3E2F1B@hendrik-sattler.de> <56E920142ED81D4FBE3260E4B9D1DB3E97C2AD40@ROTSRV13.Neuberger.local> Message-ID: Am 20. Januar 2017 09:36:54 MEZ schrieb Wagner Martin : > Thanks for your answers. > > > >You will need to do the install as another target/command. For >> >example: >> > >> >add_custom_command( TARGET version >> > POST_BUILD >> > COMMAND ${CMAKE_COMMAND} -D >> >VERSION=${version_string} >> > -P install_commands.cmake >> > USES_TERMINAL ) >> >> Or even simpler, do all of that in the install_commands.cmake by >using >> install(CODE) AND escaping the $. >> Just looking at the generated install_commands.cmake will make this >much >> clearer. >> > >I think I don't properly understand what you mean. Can you please give >me an example? > >I've tried > >install(CODE " > Include(version.cmake) >install(FILES firmware.hex RENAME firmware_\${version_string}.hex >DESTINATION firmware) >") > >This is correctly expanded in generated "cmake_install.cmake" script, >runs without errors, but does not install the file. Well, the second install command has the wrong scope: install(CODE "include(version.cmake)") install(FILES firmware.hex RENAME firmware_\${version_string}.hex DESTINATION firmware) -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. From swetha.bsharma at gmail.com Fri Jan 20 06:45:15 2017 From: swetha.bsharma at gmail.com (Swetha Sharma) Date: Fri, 20 Jan 2017 17:15:15 +0530 Subject: [CMake] fatal error LNK1112: module machine type 'x64' conflicts with target machine type 'X86' Message-ID: Hi All, I have a project which i have generated with cmake and running in visual studio 2010.I changed the configuration to x64,in visual studio my active solution and the Target Machine in(Properties->Linker->Advanced) is set as x64.I still get the linker LNK1112 error.Is this something which i set in cmakelist.txt if so what is the command? -swetha -------------- next part -------------- An HTML attachment was scrubbed... URL: From Martin.Wagner at neuberger.net Fri Jan 20 07:16:58 2017 From: Martin.Wagner at neuberger.net (Wagner Martin) Date: Fri, 20 Jan 2017 12:16:58 +0000 Subject: [CMake] install() rename with version string -solved- Message-ID: <56E920142ED81D4FBE3260E4B9D1DB3E97C2AD86@ROTSRV13.Neuberger.local> Thank you very much! This did the trick > > Well, the second install command has the wrong scope: > install(CODE "include(version.cmake)") > install(FILES firmware.hex > RENAME firmware_\${version_string}.hex > DESTINATION firmware) > I've tried that before, but without the firmware_---->\<-----${version_string}.hex escape. Looking at the generated cmake_install.cmake makes obvious why it needs to be escaped. if(NOT CMAKE_INSTALL_COMPONENT OR "${CMAKE_INSTALL_COMPONENT}" STREQUAL "Unspecified") include(${CMAKE_BINARY_DIR}/version.cmake) endif() if(NOT CMAKE_INSTALL_COMPONENT OR "${CMAKE_INSTALL_COMPONENT}" STREQUAL "Unspecified") file(INSTALL DESTINATION "firmware.hex" TYPE FILE RENAME "firmware_${version_string}.hex" FILES "path.../firmware.hex ") endif() From brad.king at kitware.com Fri Jan 20 09:12:10 2017 From: brad.king at kitware.com (Brad King) Date: Fri, 20 Jan 2017 09:12:10 -0500 Subject: [CMake] [cmake-developers] Multi-line strings with indentation ignored In-Reply-To: References: Message-ID: On 01/18/2017 10:52 AM, Robert Dailey wrote: > At the moment, with CMake 3.0 and on, I can use this syntax for > multi-line strings: > > option( ZIOSK_ENABLE_ZPAY_DIAGNOSTICS "\ > Enable additional diagnostic logs for zPay related code. \ > Should not be enabled for production due to the sensitivity \ > and volume of logs that will be printed." ) One can also use bracket arguments: https://cmake.org/cmake/help/v3.7/manual/cmake-language.7.html#bracket-argument but they (intentionally) don't process any variable references. Also they don't ignore indentation. > "Enable additional diagnostic logs for zPay related code. " > "Should not be enabled for production due to the sensitivity " > "and volume of logs that will be printed" ) > > it sees each string as a separate parameter. Correct. > Is there a mechanism I can use to style my strings this way? One can do it with an intermediate variable: ``` string(CONCAT mystringvar "Enable additional diagnostic logs for zPay related code. " "Should not be enabled for production due to the sensitivity " "and volume of logs that will be printed" ) option(ZIOSK_ENABLE_ZPAY_DIAGNOSTICS "${mystringvar}") ``` > are there any plans to add better multi-line string support? Not currently. -Brad From david.jobet at free.fr Fri Jan 20 10:36:30 2017 From: david.jobet at free.fr (david.jobet at free.fr) Date: Fri, 20 Jan 2017 15:36:30 +0000 Subject: [CMake] Interfacing cmake with 3rdparties package manager, and exclude them from ninja clean Message-ID: <2cb7fee7-ef26-42c3-b3aa-8c43159cfb74@email.android.com> An HTML attachment was scrubbed... URL: From tamas.kenez at gmail.com Fri Jan 20 17:13:14 2017 From: tamas.kenez at gmail.com (=?UTF-8?B?VGFtw6FzIEtlbsOpeg==?=) Date: Fri, 20 Jan 2017 23:13:14 +0100 Subject: [CMake] Interfacing cmake with 3rdparties package manager, and exclude them from ninja clean In-Reply-To: <2cb7fee7-ef26-42c3-b3aa-8c43159cfb74@email.android.com> References: <2cb7fee7-ef26-42c3-b3aa-8c43159cfb74@email.android.com> Message-ID: Maybe executing your script in configure time (execute_process)? On Fri, Jan 20, 2017 at 4:36 PM, wrote: > Hello, > > I'm working on a project where some of our libs depend on custom build of > some external libraries. > Those external libraries are managed through a repository manager similar > to rpm (redhat package manager) which allows us to retrieve pre-compiled > versions with related header files. (similar to devel packages) > > The catch is we want libraries to be downloaded automatically to a shared > (multiple users) local dir __AND__ we don't want them to be cleaned. > (because another user could be using it). > > I've tried add_custom_command but files disappear with make clean. > I've tried to set NO_CUSTOM_CLEAN, that works with make but not with ninja. > > I've tried to chain add_custom_target to download the file and > add_dependencies, again, this works with make but not with ninja (ninja > does not know how to create protocol buffer compiler "protoc" for example > since it's not the output of any command he knows) > > I've tried externalproject_add with BUILD_BYPRODUCTS but it looks like > ninja still clean the downloaded files. > > Any idea on how to make ninja not clean those downloaded files (we use > generators like protoc, libraries and header files) > > With regards > > David > > PS : in my add_custom_command/add_custom_target, I invoke "cmake -P" on a > custom cmake script with 2 args. The first arg is a file to test for > existence, the second one is the parameter to our custom "rpm" to download > the package. > > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From saadrustam at gmail.com Sat Jan 21 13:17:10 2017 From: saadrustam at gmail.com (Saad Khattak) Date: Sat, 21 Jan 2017 18:17:10 +0000 Subject: [CMake] ExternalProject_Add In-Reply-To: References: Message-ID: >> One possibility is the often mentioned superbuild That is a tempting and I started to go down that route - however, I ran into a problem where my project (which is now also built using ExternalProject_Add) does not have access to the CMake variables. Is the only solution to pass them through the CMAKE_ARGS variable in ExternalProject_Add? On Mon, Jan 9, 2017 at 12:07 AM Hendrik Sattler wrote: One possibility is the often mentioned superbuild, another is not using find_library() but setting the variables with the library file paths manually (that's static info anyway). Am 8. Januar 2017 22:49:52 MEZ schrieb Saad Khattak : >Hello, > >I have an external project glfw that I added to my project like this: > >========== >include(ExternalProject) >ExternalProject_Add(glfw > GIT_REPOSITORY "https://github.com/glfw/glfw.git" > GIT_TAG "master" > > SOURCE_DIR "${CMAKE_SOURCE_DIR}/dep/glfw" > CMAKE_ARGS -DGLFW_BUILD_DOCS=OFF -DGLFW_BUILD_TESTS=OFF >-DGLFW_BUILD_EXAMPLES=OFF >-DCMAKE_INSTALL_PREFIX=${CMAKE_SOURCE_DIR}/install/glfw/ >-DCMAKE_DEBUG_POSTFIX=_d > > TEST_COMMAND "" > ) >set(GLFW_INCLUDE_DIR "${CMAKE_SOURCE_DIR}/install/glfw/include/") >set(GLFW_LIBRARY_DIR "${CMAKE_SOURCE_DIR}/install/glfw/lib/") >========== > >Then I include it in my project like so: > >========== >find_library(GLFW_LIB_D glfw3_d ${GLFW_LIBRARY_DIR}) >find_library(GLFW_LIB glfw3 ${GLFW_LIBRARY_DIR}) > >include_directories(${GLFW_INCLUDE_DIR}) > >add_executable(vk_test > src/vulkan_test.cpp > ) >target_link_libraries(vk_test debug ${GLFW_LIB_D} optimized >${GLFW_LIB}) >add_dependencies(vk_test glfw) >========== > >As you can see, I depend on the libraries compiled by the external >project >glfw. Unfortunately, when I first configure the project, CMake >complains >that it cannot find the libraries specified by ${GLFW_LIB_D} and >${GLFW_LIB} variables. > >Of course, this is because CMake did not begin cloning, configuring and >building the glfw project. That only happens AFTER my project has been >configured and starts building. This becomes a chicken and the egg >problem. > >Currently, my solution is to add dummy .lib files so that I can at >least >configure and generate my project. My question is, am I approaching >this >problem in the wrong way? If yes, what is the correct way to add a >dependency to an external project and have it clone/configure/build >BEFORE >the "find_library" call? -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. -------------- next part -------------- An HTML attachment was scrubbed... URL: From boxerab at gmail.com Sat Jan 21 14:39:59 2017 From: boxerab at gmail.com (Aaron Boxer) Date: Sat, 21 Jan 2017 14:39:59 -0500 Subject: [CMake] Strange test failure In-Reply-To: References: Message-ID: Thanks, Nils, I figured it out. On Jan 20, 2017 2:41 AM, "Nils Gladitz" wrote: > On 01/20/2017 12:59 AM, Aaron Boxer wrote: > > I have a test in my ctest suite that fails both with >> and without a ! at the beginning of the test. >> >> So, >> >> FOO -BAR -BAZ >> >> fails >> >> and >> >> !FOO -BAR -BAZ >> >> fails. >> > > I am not aware of "!" having any special meaning in the context of CTest. > Can you elaborate? > > >> Any ideas, or how can I get more info on the failure ? >> > > ctest -V or ctest --output-on-failure might help. > > What type of failure does CTest indicate? > > Nils > -------------- next part -------------- An HTML attachment was scrubbed... URL: From biot023 at gmail.com Sat Jan 21 19:01:49 2017 From: biot023 at gmail.com (doug livesey) Date: Sun, 22 Jan 2017 00:01:49 +0000 Subject: [CMake] Generate a file with a custom command as part of build Message-ID: Hi, I want to call the following command as part of a build: $ ./node_modules/.bin/webpack This should generate a file public/bundle.js I'm really struggling with this. I guess there's something fundamental that I'm not understanding. `add_custom_command` doesn't seem to be doing anything. I would anticipate that it would put the command I want to call in the makefile, but it hasn't. If anyone could advise me on what I'm not getting here, that would be brilliant. Cheers, Doug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mellery451 at gmail.com Sat Jan 21 19:16:00 2017 From: mellery451 at gmail.com (Michael Ellery) Date: Sat, 21 Jan 2017 16:16:00 -0800 Subject: [CMake] Generate a file with a custom command as part of build In-Reply-To: References: Message-ID: <00CEBF9E-0091-4A87-9AB1-DB61AA02F6A6@gmail.com> add_custom_command is the probably the right thing?but it needs to be triggered by a dependency relationship. You will specify public/bundle.js as the OUTPUT parameter of the add_custom_command and then some other target or install command needs to have that file listed in its sources, and then CMAKE will understand that it needs to run the custom command to generate that OUTPUT file before it runs the dependent target. I think add_custom_command can also be explicitly linked to a specific target (there are two forms of the command) - and in that case I think it always runs (?) when that target rebuilds?I?m not completely sure about that, so you might need to test. Alternatively, if you want to run the generation at the time of makefile generation (when CMAKE is run?), then have a look at execute_process. The downside of that is that it will generally always run when CMAKE is run, but never during the make process so it doesn?t really handle updates to the source (input) files very well. I?m not sure which technique applies best to your situation here. HTH, Mike > On Jan 21, 2017, at 4:01 PM, doug livesey wrote: > > Hi, I want to call the following command as part of a build: > > $ ./node_modules/.bin/webpack > > This should generate a file public/bundle.js > > I'm really struggling with this. I guess there's something fundamental that I'm not understanding. `add_custom_command` doesn't seem to be doing anything. > I would anticipate that it would put the command I want to call in the makefile, but it hasn't. > If anyone could advise me on what I'm not getting here, that would be brilliant. > Cheers, > Doug. > -- > > 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 From david.jobet at free.fr Sun Jan 22 15:20:34 2017 From: david.jobet at free.fr (david.jobet at free.fr) Date: Sun, 22 Jan 2017 20:20:34 +0000 Subject: [CMake] Interfacing cmake with 3rdparties package manager, and exclude them from ninja clean In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: From nicholas11braden at gmail.com Sun Jan 22 22:33:44 2017 From: nicholas11braden at gmail.com (Nicholas Braden) Date: Sun, 22 Jan 2017 21:33:44 -0600 Subject: [CMake] ExternalProject_Add In-Reply-To: References: Message-ID: Yes, that is what I do in my superbuilds. Generally I make is such that my project could be built without the superbuild, and the superbuild is just a convenience. On Sat, Jan 21, 2017 at 12:17 PM, Saad Khattak wrote: > >> One possibility is the often mentioned superbuild > > That is a tempting and I started to go down that route - however, I ran > into a problem where my project (which is now also built using > ExternalProject_Add) does not have access to the CMake variables. Is the > only solution to pass them through the CMAKE_ARGS variable in > ExternalProject_Add? > > On Mon, Jan 9, 2017 at 12:07 AM Hendrik Sattler > wrote: > > One possibility is the often mentioned superbuild, another is not using > find_library() but setting the variables with the library file paths > manually (that's static info anyway). > > > Am 8. Januar 2017 22:49:52 MEZ schrieb Saad Khattak >: > >Hello, > > > >I have an external project glfw that I added to my project like this: > > > >========== > >include(ExternalProject) > >ExternalProject_Add(glfw > > GIT_REPOSITORY "https://github.com/glfw/glfw.git" > > GIT_TAG "master" > > > > SOURCE_DIR "${CMAKE_SOURCE_DIR}/dep/glfw" > > CMAKE_ARGS -DGLFW_BUILD_DOCS=OFF -DGLFW_BUILD_TESTS=OFF > >-DGLFW_BUILD_EXAMPLES=OFF > >-DCMAKE_INSTALL_PREFIX=${CMAKE_SOURCE_DIR}/install/glfw/ > >-DCMAKE_DEBUG_POSTFIX=_d > > > > TEST_COMMAND "" > > ) > >set(GLFW_INCLUDE_DIR "${CMAKE_SOURCE_DIR}/install/glfw/include/") > >set(GLFW_LIBRARY_DIR "${CMAKE_SOURCE_DIR}/install/glfw/lib/") > >========== > > > >Then I include it in my project like so: > > > >========== > >find_library(GLFW_LIB_D glfw3_d ${GLFW_LIBRARY_DIR}) > >find_library(GLFW_LIB glfw3 ${GLFW_LIBRARY_DIR}) > > > >include_directories(${GLFW_INCLUDE_DIR}) > > > >add_executable(vk_test > > src/vulkan_test.cpp > > ) > >target_link_libraries(vk_test debug ${GLFW_LIB_D} optimized > >${GLFW_LIB}) > >add_dependencies(vk_test glfw) > >========== > > > >As you can see, I depend on the libraries compiled by the external > >project > >glfw. Unfortunately, when I first configure the project, CMake > >complains > >that it cannot find the libraries specified by ${GLFW_LIB_D} and > >${GLFW_LIB} variables. > > > >Of course, this is because CMake did not begin cloning, configuring and > >building the glfw project. That only happens AFTER my project has been > >configured and starts building. This becomes a chicken and the egg > >problem. > > > >Currently, my solution is to add dummy .lib files so that I can at > >least > >configure and generate my project. My question is, am I approaching > >this > >problem in the wrong way? If yes, what is the correct way to add a > >dependency to an external project and have it clone/configure/build > >BEFORE > >the "find_library" call? > > -- > Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail > gesendet. > > > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From saadrustam at gmail.com Sun Jan 22 23:11:35 2017 From: saadrustam at gmail.com (Saad Khattak) Date: Mon, 23 Jan 2017 04:11:35 +0000 Subject: [CMake] ExternalProject_Add In-Reply-To: References: Message-ID: That is a good point. I found that a side effect of the superbuild is that my project can be built independently and I can distribute it without the superbuild parent project. Thanks Nicholas! On Sun, Jan 22, 2017 at 10:33 PM Nicholas Braden wrote: > Yes, that is what I do in my superbuilds. Generally I make is such that my > project could be built without the superbuild, and the superbuild is just a > convenience. > > On Sat, Jan 21, 2017 at 12:17 PM, Saad Khattak > wrote: > > >> One possibility is the often mentioned superbuild > > That is a tempting and I started to go down that route - however, I ran > into a problem where my project (which is now also built using > ExternalProject_Add) does not have access to the CMake variables. Is the > only solution to pass them through the CMAKE_ARGS variable in > ExternalProject_Add? > > On Mon, Jan 9, 2017 at 12:07 AM Hendrik Sattler > wrote: > > One possibility is the often mentioned superbuild, another is not using > find_library() but setting the variables with the library file paths > manually (that's static info anyway). > > > Am 8. Januar 2017 22:49:52 MEZ schrieb Saad Khattak >: > >Hello, > > > >I have an external project glfw that I added to my project like this: > > > >========== > >include(ExternalProject) > >ExternalProject_Add(glfw > > GIT_REPOSITORY "https://github.com/glfw/glfw.git" > > GIT_TAG "master" > > > > SOURCE_DIR "${CMAKE_SOURCE_DIR}/dep/glfw" > > CMAKE_ARGS -DGLFW_BUILD_DOCS=OFF -DGLFW_BUILD_TESTS=OFF > >-DGLFW_BUILD_EXAMPLES=OFF > >-DCMAKE_INSTALL_PREFIX=${CMAKE_SOURCE_DIR}/install/glfw/ > >-DCMAKE_DEBUG_POSTFIX=_d > > > > TEST_COMMAND "" > > ) > >set(GLFW_INCLUDE_DIR "${CMAKE_SOURCE_DIR}/install/glfw/include/") > >set(GLFW_LIBRARY_DIR "${CMAKE_SOURCE_DIR}/install/glfw/lib/") > >========== > > > >Then I include it in my project like so: > > > >========== > >find_library(GLFW_LIB_D glfw3_d ${GLFW_LIBRARY_DIR}) > >find_library(GLFW_LIB glfw3 ${GLFW_LIBRARY_DIR}) > > > >include_directories(${GLFW_INCLUDE_DIR}) > > > >add_executable(vk_test > > src/vulkan_test.cpp > > ) > >target_link_libraries(vk_test debug ${GLFW_LIB_D} optimized > >${GLFW_LIB}) > >add_dependencies(vk_test glfw) > >========== > > > >As you can see, I depend on the libraries compiled by the external > >project > >glfw. Unfortunately, when I first configure the project, CMake > >complains > >that it cannot find the libraries specified by ${GLFW_LIB_D} and > >${GLFW_LIB} variables. > > > >Of course, this is because CMake did not begin cloning, configuring and > >building the glfw project. That only happens AFTER my project has been > >configured and starts building. This becomes a chicken and the egg > >problem. > > > >Currently, my solution is to add dummy .lib files so that I can at > >least > >configure and generate my project. My question is, am I approaching > >this > >problem in the wrong way? If yes, what is the correct way to add a > >dependency to an external project and have it clone/configure/build > >BEFORE > >the "find_library" call? > > -- > Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail > gesendet. > > > -- > > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim.kettler at udo.edu Mon Jan 23 04:02:48 2017 From: tim.kettler at udo.edu (Tim Kettler) Date: Mon, 23 Jan 2017 09:02:48 +0000 Subject: [CMake] Visual Studio and dependy on imported library Message-ID: Hi, imagine a project that declares an imported library (#implib#) in a subdirectory. The imported library depends on some other target (#lib#). A second imported library (#implibtop#) with the same dependency is declared in the top-level CMakeLists.txt. Additionally there are three executables that each depend on one of the library targets. An example project is available at Github [1]. With CMake 3.7.2 and Visual Studio 2015 I'm seeing the following project dependencies in the solution: - execlib (target_links #lib#) depends on the #lib# target - execimplib (target_links #implib#) does not depend on the #lib# target - execimplibtop (target_links #implibtop#) depends on the #lib# target Is this the expected behaviour? Why is #execimplib# not picking up the dependency? I discoverd this while creating a wrapper imported library for an external project. -Tim [1] https://github.com/tik/cmake-implib From nikita.kakuev at gmail.com Mon Jan 23 05:35:22 2017 From: nikita.kakuev at gmail.com (Nikita) Date: Mon, 23 Jan 2017 13:35:22 +0300 Subject: [CMake] CMake 3.8 release date In-Reply-To: References: Message-ID: Hi, I couldn't find any release schedule for the project, so I've decided to ask about it here. What is the expected release date of CMake 3.8? I'm interested in it because I'm waiting for this fix: https://gitlab.kitware.com/cmake/cmake/issues/16435 Regards, Nikita -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.stuermer at schaeffler.com Mon Jan 23 07:14:49 2017 From: michael.stuermer at schaeffler.com (Stuermer, Michael SP/HZA-ZSEP) Date: Mon, 23 Jan 2017 12:14:49 +0000 Subject: [CMake] CMake 3.8 release date In-Reply-To: References: Message-ID: <1cb28a564ab248dc89aca219390f3ab8@DE013666.schaeffler.com> Hello Nikita, Brad mentioned a feature freeze for version 3.8 at the end of january. Looking at the source history for version 3.7, it can take some time until the final release is done: 3.10.2016: (candidate 1) 19.10.2016: (candidate 2) 4.11.2016: (candidate 3) 11.11.2016: (final release) You can see it can take more than a month until a final release is ready. I don?t believe there is a certain fixed date when this is due. best regards, Michael From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Nikita Sent: Monday, January 23, 2017 11:35 AM To: CMake ML Subject: [CMake] CMake 3.8 release date Hi, I couldn't find any release schedule for the project, so I've decided to ask about it here. What is the expected release date of CMake 3.8? I'm interested in it because I'm waiting for this fix: https://gitlab.kitware.com/cmake/cmake/issues/16435 Regards, Nikita -------------- next part -------------- An HTML attachment was scrubbed... URL: From biot023 at gmail.com Tue Jan 24 14:34:26 2017 From: biot023 at gmail.com (doug livesey) Date: Tue, 24 Jan 2017 19:34:26 +0000 Subject: [CMake] Generate a file with a custom command as part of build In-Reply-To: <00CEBF9E-0091-4A87-9AB1-DB61AA02F6A6@gmail.com> References: <00CEBF9E-0091-4A87-9AB1-DB61AA02F6A6@gmail.com> Message-ID: Hi -- sorry about the really late reply, I've been away. Up to Hadrian's Wall, and then for a Dark Skies observatory evening. It was ace. :) I've added the following to my CMakeLists.txt file: > set(WEBPACK ${CMAKE_SOURCE_DIR}/node_modules/.bin/webpack) > configure_file(webpack.config.js webpack.config.js) > add_custom_target(public/bundle.js) > add_custom_command(OUTPUT public/bundle.js COMMAND ${WEBPACK}) However, when I try to run `cmake ..` (I'm using a build subdirectory), I get the following error: > CMake Error at CMakeLists.txt:30 (add_custom_target): > add_custom_target called with invalid target name "public/bundle.js". > Target names may not contain a slash. Use ADD_CUSTOM_COMMAND to generate > files. I'm guessing that this means that I should be running some of those commands in a CMakeLists.txt file in a subdirectory (maybe public/) and calling `add_subdirectory(public)` from my top-level file? I've tried this a couple of ways, but so far haven't got it working. Am I on the right sort of approach, or have I wandered far from the beaten track? Thanks again for your help, Doug. On 22 January 2017 at 00:16, Michael Ellery wrote: > add_custom_command is the probably the right thing?but it needs to be > triggered by a dependency relationship. You will specify public/bundle.js > as the OUTPUT parameter of the add_custom_command and then some other > target or install command needs to have that file listed in its sources, > and then CMAKE will understand that it needs to run the custom command to > generate that OUTPUT file before it runs the dependent target. I think > add_custom_command can also be explicitly linked to a specific target > (there are two forms of the command) - and in that case I think it always > runs (?) when that target rebuilds?I?m not completely sure about that, so > you might need to test. > > Alternatively, if you want to run the generation at the time of makefile > generation (when CMAKE is run?), then have a look at execute_process. The > downside of that is that it will generally always run when CMAKE is run, > but never during the make process so it doesn?t really handle updates to > the source (input) files very well. I?m not sure which technique applies > best to your situation here. > > HTH, > Mike > > > On Jan 21, 2017, at 4:01 PM, doug livesey wrote: > > > > Hi, I want to call the following command as part of a build: > > > > $ ./node_modules/.bin/webpack > > > > This should generate a file public/bundle.js > > > > I'm really struggling with this. I guess there's something fundamental > that I'm not understanding. `add_custom_command` doesn't seem to be doing > anything. > > I would anticipate that it would put the command I want to call in the > makefile, but it hasn't. > > If anyone could advise me on what I'm not getting here, that would be > brilliant. > > Cheers, > > Doug. > > -- > > > > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mellery451 at gmail.com Tue Jan 24 15:52:15 2017 From: mellery451 at gmail.com (Michael Ellery) Date: Tue, 24 Jan 2017 12:52:15 -0800 Subject: [CMake] Generate a file with a custom command as part of build In-Reply-To: References: <00CEBF9E-0091-4A87-9AB1-DB61AA02F6A6@gmail.com> Message-ID: The syntax of your add_custom_target is not quite right?I would try something more like: add_custom_target( Webpack ALL $WEBPACK DEPENDS webpack.config.js BYPRODUCTS public/bundle.js ) ?that?s untested, of course. I you do that, then I think you don?t need the add_custom_command at all?.but you will still want to make some of your other targets depend on this target if they need bundle.js before they run. > On Jan 24, 2017, at 11:34 AM, doug livesey wrote: > > Hi -- sorry about the really late reply, I've been away. Up to Hadrian's Wall, and then for a Dark Skies observatory evening. > It was ace. :) > I've added the following to my CMakeLists.txt file: > > > set(WEBPACK ${CMAKE_SOURCE_DIR}/node_modules/.bin/webpack) > > configure_file(webpack.config.js webpack.config.js) > > add_custom_target(public/bundle.js) > > add_custom_command(OUTPUT public/bundle.js COMMAND ${WEBPACK}) > > However, when I try to run `cmake ..` (I'm using a build subdirectory), I get the following error: > > > CMake Error at CMakeLists.txt:30 (add_custom_target): > > add_custom_target called with invalid target name "public/bundle.js". > > Target names may not contain a slash. Use ADD_CUSTOM_COMMAND to generate > > files. > > I'm guessing that this means that I should be running some of those commands in a CMakeLists.txt file in a subdirectory (maybe public/) and calling `add_subdirectory(public)` from my top-level file? > I've tried this a couple of ways, but so far haven't got it working. > Am I on the right sort of approach, or have I wandered far from the beaten track? > Thanks again for your help, > Doug. > > On 22 January 2017 at 00:16, Michael Ellery wrote: > add_custom_command is the probably the right thing?but it needs to be triggered by a dependency relationship. You will specify public/bundle.js as the OUTPUT parameter of the add_custom_command and then some other target or install command needs to have that file listed in its sources, and then CMAKE will understand that it needs to run the custom command to generate that OUTPUT file before it runs the dependent target. I think add_custom_command can also be explicitly linked to a specific target (there are two forms of the command) - and in that case I think it always runs (?) when that target rebuilds?I?m not completely sure about that, so you might need to test. > > Alternatively, if you want to run the generation at the time of makefile generation (when CMAKE is run?), then have a look at execute_process. The downside of that is that it will generally always run when CMAKE is run, but never during the make process so it doesn?t really handle updates to the source (input) files very well. I?m not sure which technique applies best to your situation here. > > HTH, > Mike > > > On Jan 21, 2017, at 4:01 PM, doug livesey wrote: > > > > Hi, I want to call the following command as part of a build: > > > > $ ./node_modules/.bin/webpack > > > > This should generate a file public/bundle.js > > > > I'm really struggling with this. I guess there's something fundamental that I'm not understanding. `add_custom_command` doesn't seem to be doing anything. > > I would anticipate that it would put the command I want to call in the makefile, but it hasn't. > > If anyone could advise me on what I'm not getting here, that would be brilliant. > > Cheers, > > Doug. > > -- > > > > 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 > > From biot023 at gmail.com Wed Jan 25 02:19:40 2017 From: biot023 at gmail.com (doug livesey) Date: Wed, 25 Jan 2017 07:19:40 +0000 Subject: [CMake] Generate a file with a custom command as part of build In-Reply-To: References: <00CEBF9E-0091-4A87-9AB1-DB61AA02F6A6@gmail.com> Message-ID: Perfect, thankyou so much! That nailed it! On 24 January 2017 at 20:52, Michael Ellery wrote: > The syntax of your add_custom_target is not quite right?I would try > something more like: > > add_custom_target( Webpack ALL > $WEBPACK > DEPENDS webpack.config.js > BYPRODUCTS public/bundle.js > ) > > ?that?s untested, of course. I you do that, then I think you don?t need > the add_custom_command at all?.but you will still want to make some of your > other targets depend on this target if they need bundle.js before they run. > > > On Jan 24, 2017, at 11:34 AM, doug livesey wrote: > > > > Hi -- sorry about the really late reply, I've been away. Up to Hadrian's > Wall, and then for a Dark Skies observatory evening. > > It was ace. :) > > I've added the following to my CMakeLists.txt file: > > > > > set(WEBPACK ${CMAKE_SOURCE_DIR}/node_modules/.bin/webpack) > > > configure_file(webpack.config.js webpack.config.js) > > > add_custom_target(public/bundle.js) > > > add_custom_command(OUTPUT public/bundle.js COMMAND ${WEBPACK}) > > > > However, when I try to run `cmake ..` (I'm using a build subdirectory), > I get the following error: > > > > > CMake Error at CMakeLists.txt:30 (add_custom_target): > > > add_custom_target called with invalid target name "public/bundle.js". > > > Target names may not contain a slash. Use ADD_CUSTOM_COMMAND to > generate > > > files. > > > > I'm guessing that this means that I should be running some of those > commands in a CMakeLists.txt file in a subdirectory (maybe public/) and > calling `add_subdirectory(public)` from my top-level file? > > I've tried this a couple of ways, but so far haven't got it working. > > Am I on the right sort of approach, or have I wandered far from the > beaten track? > > Thanks again for your help, > > Doug. > > > > On 22 January 2017 at 00:16, Michael Ellery > wrote: > > add_custom_command is the probably the right thing?but it needs to be > triggered by a dependency relationship. You will specify public/bundle.js > as the OUTPUT parameter of the add_custom_command and then some other > target or install command needs to have that file listed in its sources, > and then CMAKE will understand that it needs to run the custom command to > generate that OUTPUT file before it runs the dependent target. I think > add_custom_command can also be explicitly linked to a specific target > (there are two forms of the command) - and in that case I think it always > runs (?) when that target rebuilds?I?m not completely sure about that, so > you might need to test. > > > > Alternatively, if you want to run the generation at the time of makefile > generation (when CMAKE is run?), then have a look at execute_process. The > downside of that is that it will generally always run when CMAKE is run, > but never during the make process so it doesn?t really handle updates to > the source (input) files very well. I?m not sure which technique applies > best to your situation here. > > > > HTH, > > Mike > > > > > On Jan 21, 2017, at 4:01 PM, doug livesey wrote: > > > > > > Hi, I want to call the following command as part of a build: > > > > > > $ ./node_modules/.bin/webpack > > > > > > This should generate a file public/bundle.js > > > > > > I'm really struggling with this. I guess there's something fundamental > that I'm not understanding. `add_custom_command` doesn't seem to be doing > anything. > > > I would anticipate that it would put the command I want to call in the > makefile, but it hasn't. > > > If anyone could advise me on what I'm not getting here, that would be > brilliant. > > > Cheers, > > > Doug. > > > -- > > > > > > 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 > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From biot023 at gmail.com Wed Jan 25 02:22:56 2017 From: biot023 at gmail.com (doug livesey) Date: Wed, 25 Jan 2017 07:22:56 +0000 Subject: [CMake] Generate a file with a custom command as part of build In-Reply-To: References: <00CEBF9E-0091-4A87-9AB1-DB61AA02F6A6@gmail.com> Message-ID: Is there any way that I can make the files webpack compiles into dependencies for the Webpack task? So that any changes to those are picked up for recompilation? No worries if not, I just thought it would be nice. On 25 January 2017 at 07:19, doug livesey wrote: > Perfect, thankyou so much! > That nailed it! > > On 24 January 2017 at 20:52, Michael Ellery wrote: > >> The syntax of your add_custom_target is not quite right?I would try >> something more like: >> >> add_custom_target( Webpack ALL >> $WEBPACK >> DEPENDS webpack.config.js >> BYPRODUCTS public/bundle.js >> ) >> >> ?that?s untested, of course. I you do that, then I think you don?t need >> the add_custom_command at all?.but you will still want to make some of your >> other targets depend on this target if they need bundle.js before they run. >> >> > On Jan 24, 2017, at 11:34 AM, doug livesey wrote: >> > >> > Hi -- sorry about the really late reply, I've been away. Up to >> Hadrian's Wall, and then for a Dark Skies observatory evening. >> > It was ace. :) >> > I've added the following to my CMakeLists.txt file: >> > >> > > set(WEBPACK ${CMAKE_SOURCE_DIR}/node_modules/.bin/webpack) >> > > configure_file(webpack.config.js webpack.config.js) >> > > add_custom_target(public/bundle.js) >> > > add_custom_command(OUTPUT public/bundle.js COMMAND ${WEBPACK}) >> > >> > However, when I try to run `cmake ..` (I'm using a build subdirectory), >> I get the following error: >> > >> > > CMake Error at CMakeLists.txt:30 (add_custom_target): >> > > add_custom_target called with invalid target name >> "public/bundle.js". >> > > Target names may not contain a slash. Use ADD_CUSTOM_COMMAND to >> generate >> > > files. >> > >> > I'm guessing that this means that I should be running some of those >> commands in a CMakeLists.txt file in a subdirectory (maybe public/) and >> calling `add_subdirectory(public)` from my top-level file? >> > I've tried this a couple of ways, but so far haven't got it working. >> > Am I on the right sort of approach, or have I wandered far from the >> beaten track? >> > Thanks again for your help, >> > Doug. >> > >> > On 22 January 2017 at 00:16, Michael Ellery >> wrote: >> > add_custom_command is the probably the right thing?but it needs to be >> triggered by a dependency relationship. You will specify public/bundle.js >> as the OUTPUT parameter of the add_custom_command and then some other >> target or install command needs to have that file listed in its sources, >> and then CMAKE will understand that it needs to run the custom command to >> generate that OUTPUT file before it runs the dependent target. I think >> add_custom_command can also be explicitly linked to a specific target >> (there are two forms of the command) - and in that case I think it always >> runs (?) when that target rebuilds?I?m not completely sure about that, so >> you might need to test. >> > >> > Alternatively, if you want to run the generation at the time of >> makefile generation (when CMAKE is run?), then have a look at >> execute_process. The downside of that is that it will generally always run >> when CMAKE is run, but never during the make process so it doesn?t really >> handle updates to the source (input) files very well. I?m not sure which >> technique applies best to your situation here. >> > >> > HTH, >> > Mike >> > >> > > On Jan 21, 2017, at 4:01 PM, doug livesey wrote: >> > > >> > > Hi, I want to call the following command as part of a build: >> > > >> > > $ ./node_modules/.bin/webpack >> > > >> > > This should generate a file public/bundle.js >> > > >> > > I'm really struggling with this. I guess there's something >> fundamental that I'm not understanding. `add_custom_command` doesn't seem >> to be doing anything. >> > > I would anticipate that it would put the command I want to call in >> the makefile, but it hasn't. >> > > If anyone could advise me on what I'm not getting here, that would be >> brilliant. >> > > Cheers, >> > > Doug. >> > > -- >> > > >> > > 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 >> > >> > >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mellery451 at gmail.com Wed Jan 25 11:02:37 2017 From: mellery451 at gmail.com (Michael Ellery) Date: Wed, 25 Jan 2017 08:02:37 -0800 Subject: [CMake] Generate a file with a custom command as part of build In-Reply-To: References: <00CEBF9E-0091-4A87-9AB1-DB61AA02F6A6@gmail.com> Message-ID: <83AD3D4A-A74F-46F9-AD94-F98AED744379@gmail.com> > On Jan 24, 2017, at 11:22 PM, doug livesey wrote: > > Is there any way that I can make the files webpack compiles into dependencies for the Webpack task? So that any changes to those are picked up for recompilation? > No worries if not, I just thought it would be nice. > just add any files on which the command depends after the DEPENDS argument. I only added the one source file in that example, but you can add as many as are appropriate. -Mike From craig.scott at crascit.com Wed Jan 25 20:25:36 2017 From: craig.scott at crascit.com (Craig Scott) Date: Thu, 26 Jan 2017 12:25:36 +1100 Subject: [CMake] COMMAND dependencies with add_custom_command() Message-ID: The documentation for add_custom_command() contains this little nugget when discussing the COMMAND keyword: If COMMAND specifies an executable target name ...... Additionally a > target-level dependency will be added so that the executable target will be > built before any target using this custom command. However this does NOT > add a file-level dependency that would cause the custom command to re-run > whenever the executable is recompiled. I'm struggling to come up with a scenario where that last part about file level dependencies becomes relevant. Can anyone come up with a simple use case which highlights that particular aspect of dependencies and commands? -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.jobet at free.fr Thu Jan 26 04:13:50 2017 From: david.jobet at free.fr (David Jobet) Date: Thu, 26 Jan 2017 10:13:50 +0100 (CET) Subject: [CMake] =?utf-8?q?Re=C2=A0=3A_Re=3A__Interfacing_cmake_with_3rdpa?= =?utf-8?q?rties_package_manager=2C_and_exclude_them_from_ninja_clean?= In-Reply-To: Message-ID: <956801697.77957130.1485422030589.JavaMail.root@zimbra63-e11> Hello, I actually gave it a try : it works fine so long versions are hardcoded somewhere in the CMakeLists.txt and it make things really simpler. But it does not work when version is extracted from git repository. I came to realize I can extract this version number at build time (using add_custom_target and cmake -P), and I can even include a generated cmake file that contains the version number, but I don't know how to tell cmake to trigger a rebuild_cache anyway. So I don't know how to make that behaviour "dynamic". Any idea ? With regards David ----- Tam?s Ken?z a ?crit?: > Maybe executing your script in configure time (execute_process)? > > On Fri, Jan 20, 2017 at 4:36 PM, wrote: > > > Hello, > > > > I'm working on a project where some of our libs depend on custom build of > > some external libraries. > > Those external libraries are managed through a repository manager similar > > to rpm (redhat package manager) which allows us to retrieve pre-compiled > > versions with related header files. (similar to devel packages) > > > > The catch is we want libraries to be downloaded automatically to a shared > > (multiple users) local dir __AND__ we don't want them to be cleaned. > > (because another user could be using it). > > > > I've tried add_custom_command but files disappear with make clean. > > I've tried to set NO_CUSTOM_CLEAN, that works with make but not with ninja. > > > > I've tried to chain add_custom_target to download the file and > > add_dependencies, again, this works with make but not with ninja (ninja > > does not know how to create protocol buffer compiler "protoc" for example > > since it's not the output of any command he knows) > > > > I've tried externalproject_add with BUILD_BYPRODUCTS but it looks like > > ninja still clean the downloaded files. > > > > Any idea on how to make ninja not clean those downloaded files (we use > > generators like protoc, libraries and header files) > > > > With regards > > > > David > > > > PS : in my add_custom_command/add_custom_target, I invoke "cmake -P" on a > > custom cmake script with 2 args. The first arg is a file to test for > > existence, the second one is the parameter to our custom "rpm" to download > > the package. > > > > -- > > > > 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 > > From david.jobet at free.fr Thu Jan 26 04:23:08 2017 From: david.jobet at free.fr (David Jobet) Date: Thu, 26 Jan 2017 10:23:08 +0100 (CET) Subject: [CMake] externalproject_add and generating sources Message-ID: <751181391.78013628.1485422588735.JavaMail.root@zimbra63-e11> Hello, suppose I want to use protobuf and integrate it in my project with externalproject_add. (actually, I just have precompiled binaries and libs + header files, I don't have the full sources) Once the project has been 'built' (actually, installed by a custom rpm-like tool to a shared path), I can use the protoc compiler to generate protobuf c++ files (.pb.h and .pb.cpp files) from a .proto description file. I can add_dependencies so that the external project is built before projects depending on libprotobuf.a. However, I don't know how to do the same thing with .pb.h and .pb.cpp files which use a .proto file and the protoc compiler. make is fine with it, but ninja complains with an error like this : ninja: error: '/path_to_external_projects/protobuf/2.6.0.4/bin/protoc', needed by 'some_project/SomeFile.pb.h', missing and no known rule to make it how can I tell ninja that protoc is going to be provided by externalproject ? If I use byproducts, ninja is happy, but "ninja clean" deletes /path_to_external_projects/protobuf/2.6.0.4/bin/protoc. I don't want that to happen since /path_to_external_projects/protobuf/2.6.0.4/bin/protoc is shared with other users. With regards David From biot023 at gmail.com Thu Jan 26 04:42:44 2017 From: biot023 at gmail.com (doug livesey) Date: Thu, 26 Jan 2017 09:42:44 +0000 Subject: [CMake] Generate a file with a custom command as part of build In-Reply-To: <83AD3D4A-A74F-46F9-AD94-F98AED744379@gmail.com> References: <00CEBF9E-0091-4A87-9AB1-DB61AA02F6A6@gmail.com> <83AD3D4A-A74F-46F9-AD94-F98AED744379@gmail.com> Message-ID: I'll have a play with that later. Thanks again for all your help. Doug. On 25 January 2017 at 16:02, Michael Ellery wrote: > > > On Jan 24, 2017, at 11:22 PM, doug livesey wrote: > > > > Is there any way that I can make the files webpack compiles into > dependencies for the Webpack task? So that any changes to those are picked > up for recompilation? > > No worries if not, I just thought it would be nice. > > > > just add any files on which the command depends after the DEPENDS > argument. I only added the one source file in that example, but you can add > as many as are appropriate. > > -Mike > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicholas11braden at gmail.com Thu Jan 26 08:02:43 2017 From: nicholas11braden at gmail.com (Nicholas Braden) Date: Thu, 26 Jan 2017 07:02:43 -0600 Subject: [CMake] externalproject_add and generating sources In-Reply-To: <751181391.78013628.1485422588735.JavaMail.root@zimbra63-e11> References: <751181391.78013628.1485422588735.JavaMail.root@zimbra63-e11> Message-ID: You'll also want to build your own project with ExternalProject, and use the DEPENDS option to control build order. This ensures that all dependencies are fully installed before your own project is even configured. The project with all the ExternalProject calls is typically called a superbuild, and effectively becomes an optional convenience to building your own project. On Thu, Jan 26, 2017 at 3:23 AM, David Jobet wrote: > Hello, > > suppose I want to use protobuf and integrate it in my project with > externalproject_add. (actually, I just have precompiled binaries and libs + > header files, I don't have the full sources) > Once the project has been 'built' (actually, installed by a custom > rpm-like tool to a shared path), I can use the protoc compiler to generate > protobuf c++ files (.pb.h and .pb.cpp files) from a .proto description file. > I can add_dependencies so that the external project is built before > projects depending on libprotobuf.a. > > However, I don't know how to do the same thing with .pb.h and .pb.cpp > files which use a .proto file and the protoc compiler. > > make is fine with it, but ninja complains with an error like this : > ninja: error: '/path_to_external_projects/protobuf/2.6.0.4/bin/protoc', > needed by 'some_project/SomeFile.pb.h', missing and no known rule to make it > > how can I tell ninja that protoc is going to be provided by > externalproject ? > If I use byproducts, ninja is happy, but "ninja clean" deletes > /path_to_external_projects/protobuf/2.6.0.4/bin/protoc. > I don't want that to happen since /path_to_external_projects/protobuf/ > 2.6.0.4/bin/protoc is shared with other users. > > With regards > > David > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mellery451 at gmail.com Thu Jan 26 11:05:47 2017 From: mellery451 at gmail.com (Michael Ellery) Date: Thu, 26 Jan 2017 08:05:47 -0800 Subject: [CMake] externalproject_add and generating sources In-Reply-To: <751181391.78013628.1485422588735.JavaMail.root@zimbra63-e11> References: <751181391.78013628.1485422588735.JavaMail.root@zimbra63-e11> Message-ID: > On Jan 26, 2017, at 1:23 AM, David Jobet wrote: > > Hello, > > suppose I want to use protobuf and integrate it in my project with externalproject_add. (actually, I just have precompiled binaries and libs + header files, I don't have the full sources) > Once the project has been 'built' (actually, installed by a custom rpm-like tool to a shared path), I can use the protoc compiler to generate protobuf c++ files (.pb.h and .pb.cpp files) from a .proto description file. > I can add_dependencies so that the external project is built before projects depending on libprotobuf.a. > > However, I don't know how to do the same thing with .pb.h and .pb.cpp files which use a .proto file and the protoc compiler. > > make is fine with it, but ninja complains with an error like this : > ninja: error: '/path_to_external_projects/protobuf/2.6.0.4/bin/protoc', needed by 'some_project/SomeFile.pb.h', missing and no known rule to make it > > how can I tell ninja that protoc is going to be provided by externalproject ? > If I use byproducts, ninja is happy, but "ninja clean" deletes /path_to_external_projects/protobuf/2.6.0.4/bin/protoc. > I don't want that to happen since /path_to_external_projects/protobuf/2.6.0.4/bin/protoc is shared with other users. > I?ve never used protobufs as an external project (I?ve always just done a one-time setup/install)?but is there a reason you can?t just use the standard finder to locate it? https://github.com/Kitware/CMake/blob/master/Modules/FindProtobuf.cmake -Mike From ggarra13 at gmail.com Thu Jan 26 16:23:05 2017 From: ggarra13 at gmail.com (=?UTF-8?Q?Gonzalo_Garramu=c3=b1o?=) Date: Thu, 26 Jan 2017 18:23:05 -0300 Subject: [CMake] Forcing linking compatability to old libc / libstdc++ (Linux) Message-ID: <802aeca1-99bf-fc7e-5298-25b9c303e277@gmail.com> I currently own an Ubuntu Xenial 14.04.1 LTS box in which I do all my work. I distribute a binary image viewer. However, recently one of my users tried to run the viewer on a CentOS 7 distro and found out that that distro libc and libstdc++ are older and incompatible. I would like to compile my program targeting the older libc and libstdc++. Those files come with symbol version and visibility. Is there an easy way to do that other than copying the old libraries? Any help or hint is appreciated. -- Gonzalo Garramu?o From mellery451 at gmail.com Thu Jan 26 16:35:28 2017 From: mellery451 at gmail.com (Michael Ellery) Date: Thu, 26 Jan 2017 13:35:28 -0800 Subject: [CMake] Forcing linking compatability to old libc / libstdc++ (Linux) In-Reply-To: <802aeca1-99bf-fc7e-5298-25b9c303e277@gmail.com> References: <802aeca1-99bf-fc7e-5298-25b9c303e277@gmail.com> Message-ID: <62375905-72C8-4525-B601-32C24363FFAE@gmail.com> > On Jan 26, 2017, at 1:23 PM, Gonzalo Garramu?o wrote: > > I currently own an Ubuntu Xenial 14.04.1 LTS box in which I do all my work. I distribute a binary image viewer. However, recently one of my users tried to run the viewer on a CentOS 7 distro and found out that that distro libc and libstdc++ are older and incompatible. > > I would like to compile my program targeting the older libc and libstdc++. Those files come with symbol version and visibility. Is there an easy way to do that other than copying the old libraries? > > Any help or hint is appreciated. > In what way is the stdlib incompatible? Does it have bugs, or is this more a matter of cpp standard support? If you want to enforce/require a certain standard of cpp, for instance, have a look at: https://cmake.org/cmake/help/v3.1/variable/CMAKE_CXX_STANDARD_REQUIRED.html If you want to enforce certain language features, you can consider specifying compile-features: https://cmake.org/cmake/help/v3.1/manual/cmake-compile-features.7.html https://cmake.org/cmake/help/v3.1/prop_gbl/CMAKE_CXX_KNOWN_FEATURES.html#prop_gbl:CMAKE_CXX_KNOWN_FEATURES Now, that might still not solve the immediate problem of an old toolchain on Centos7, but at least CMake will make clear to the user what?s missing. For Centos/Redhat specifically, I?ve had good luck with devtoolset for installing/using an updated toolchain: https://www.softwarecollections.org/en/scls/rhscl/devtoolset-3 HTH, Mike Ellery From ggarra13 at gmail.com Thu Jan 26 16:45:21 2017 From: ggarra13 at gmail.com (=?UTF-8?Q?Gonzalo_Garramu=c3=b1o?=) Date: Thu, 26 Jan 2017 18:45:21 -0300 Subject: [CMake] Forcing linking compatability to old libc / libstdc++ (Linux) In-Reply-To: <62375905-72C8-4525-B601-32C24363FFAE@gmail.com> References: <802aeca1-99bf-fc7e-5298-25b9c303e277@gmail.com> <62375905-72C8-4525-B601-32C24363FFAE@gmail.com> Message-ID: <41f710be-2dc8-6699-5900-fbbe1d328b10@gmail.com> El 26/01/2017 a las 18:35, Michael Ellery escribi?: > In what way is the stdlib incompatible? Does it have bugs, or is this more a matter of cpp standard support? I should have been more clear. Sorry. The incompatabilities happen at linker time, with complaints such as: exrstdattr: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by exrstdattr ) exrstdattr: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by /usr/local/mrViewer/lib/libIlmImf-2_2.so.22 ) If I copy the latest libstdc++.so.6 I have on Ubuntu, I get: exrstdattr: /lib64/libc.so.6: version `GLIBC_2.18' not found (required by /usr/local/mrViewer/lib/libstdc++.so.6 ) -- Gonzalo Garramu?o From mellery451 at gmail.com Thu Jan 26 17:34:54 2017 From: mellery451 at gmail.com (Michael Ellery) Date: Thu, 26 Jan 2017 14:34:54 -0800 Subject: [CMake] Forcing linking compatability to old libc / libstdc++ (Linux) In-Reply-To: <41f710be-2dc8-6699-5900-fbbe1d328b10@gmail.com> References: <802aeca1-99bf-fc7e-5298-25b9c303e277@gmail.com> <62375905-72C8-4525-B601-32C24363FFAE@gmail.com> <41f710be-2dc8-6699-5900-fbbe1d328b10@gmail.com> Message-ID: > On Jan 26, 2017, at 1:45 PM, Gonzalo Garramu?o wrote: > > > > El 26/01/2017 a las 18:35, Michael Ellery escribi?: >> In what way is the stdlib incompatible? Does it have bugs, or is this more a matter of cpp standard support? > I should have been more clear. Sorry. The incompatabilities happen at linker time, with complaints such as: > > exrstdattr: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by exrstdattr ) > exrstdattr: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by /usr/local/mrViewer/lib/libIlmImf-2_2.so.22 ) > > If I copy the latest libstdc++.so.6 I have on Ubuntu, I get: > > exrstdattr: /lib64/libc.so.6: version `GLIBC_2.18' not found (required by /usr/local/mrViewer/lib/libstdc++.so.6 ) > > -- > Gonzalo Garramu?o > oh, yeah - I wasn?t paying close attention to the fact that you are distributing *binaries* ? to a different distro no less. This is why projects often either tell users to build from source or they create packages (rpms, dpkgs, etc.) on the specific distros and versions. That said, if you want to distribute binaries to a different distro, I guess you can try static linking OR what you suggested, shipping the stdlib ? see: http://stackoverflow.com/questions/13636513/linking-libstdc-statically-any-gotchas#14082540 I personally would not want to ship a stdlib myself, but using CMake?s RPATH support, you can probably make it work. -Mike From florent.castelli at gmail.com Thu Jan 26 20:34:43 2017 From: florent.castelli at gmail.com (Florent Castelli) Date: Fri, 27 Jan 2017 02:34:43 +0100 Subject: [CMake] Forcing linking compatability to old libc / libstdc++ (Linux) In-Reply-To: References: <802aeca1-99bf-fc7e-5298-25b9c303e277@gmail.com> <62375905-72C8-4525-B601-32C24363FFAE@gmail.com> <41f710be-2dc8-6699-5900-fbbe1d328b10@gmail.com> Message-ID: I've had to deal with this in the past. For glibc, it's more tricky since when you compile on a newer distribution, it will automatically use the newer version of some symbols. Some functions have had breaking changes and to keep compatibility, they kept all the different version in the binary. But you can force the compiler to use a specific version of head but putting that information in a header that contains the definition for all those functions. There is a script describe in this blog post ( https://blogs.gnome.org/tvb/2013/12/14/application-bundles-revisited/ ) you could use to generate a compatibility header for any target version of glibc. Then, you can use a force include (-include) in your favorite build system (CMake) to have those used everywhere automatically. If your application doesn't use any external libraries linked statically and built against your current glibc, it should work. Otherwise, you will probably have to rebuild them. For libstdc++, you could potentially statically link it, it's usually fine. But after what I said about glibc, it means you may have to rebuild it using the compatibility header described before. That may be tricky too... /Florent On 26/01/2017 23:34, Michael Ellery wrote: >> On Jan 26, 2017, at 1:45 PM, Gonzalo Garramu?o wrote: >> >> >> >> El 26/01/2017 a las 18:35, Michael Ellery escribi?: >>> In what way is the stdlib incompatible? Does it have bugs, or is this more a matter of cpp standard support? >> I should have been more clear. Sorry. The incompatabilities happen at linker time, with complaints such as: >> >> exrstdattr: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by exrstdattr ) >> exrstdattr: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by /usr/local/mrViewer/lib/libIlmImf-2_2.so.22 ) >> >> If I copy the latest libstdc++.so.6 I have on Ubuntu, I get: >> >> exrstdattr: /lib64/libc.so.6: version `GLIBC_2.18' not found (required by /usr/local/mrViewer/lib/libstdc++.so.6 ) >> >> -- >> Gonzalo Garramu?o >> > oh, yeah - I wasn?t paying close attention to the fact that you are distributing *binaries* ? to a different distro no less. This is why projects often either tell users to build from source or they create packages (rpms, dpkgs, etc.) on the specific distros and versions. > > That said, if you want to distribute binaries to a different distro, I guess you can try static linking OR what you suggested, shipping the stdlib ? see: > > http://stackoverflow.com/questions/13636513/linking-libstdc-statically-any-gotchas#14082540 > > I personally would not want to ship a stdlib myself, but using CMake?s RPATH support, you can probably make it work. > > -Mike > From bo.schwarzstein at gmail.com Thu Jan 26 20:59:39 2017 From: bo.schwarzstein at gmail.com (Bo Zhou) Date: Fri, 27 Jan 2017 09:59:39 +0800 Subject: [CMake] Forcing linking compatability to old libc / libstdc++ (Linux) In-Reply-To: References: <802aeca1-99bf-fc7e-5298-25b9c303e277@gmail.com> <62375905-72C8-4525-B601-32C24363FFAE@gmail.com> <41f710be-2dc8-6699-5900-fbbe1d328b10@gmail.com> Message-ID: My personal experience is, always create the distribution on old Linux with older compiler to keep the maximal compatibility. Since usually the GCC will pick libstdc++ from system, so if user runs the distribution on even older Linux, 100% sure the error raises. On CentOS/Redhat we do have the devtool-set, but still, the older Linux + GCC are the safest solution. Or you can use the static link of libstdc++, but the size of binary will be larger, and sometimes the problem still exists, and causes more problems. On Fri, Jan 27, 2017 at 9:34 AM, Florent Castelli < florent.castelli at gmail.com> wrote: > I've had to deal with this in the past. > > For glibc, it's more tricky since when you compile on a newer > distribution, it will automatically use the newer version of some symbols. > Some functions have had breaking changes and to keep compatibility, they > kept all the different version in the binary. > But you can force the compiler to use a specific version of head but > putting that information in a header that contains the definition for all > those functions. > There is a script describe in this blog post ( > https://blogs.gnome.org/tvb/2013/12/14/application-bundles-revisited/ ) > you could use to generate a compatibility header for any target version of > glibc. > Then, you can use a force include (-include) in your favorite build system > (CMake) to have those used everywhere automatically. > If your application doesn't use any external libraries linked statically > and built against your current glibc, it should work. Otherwise, you will > probably have to rebuild them. > > For libstdc++, you could potentially statically link it, it's usually fine. > But after what I said about glibc, it means you may have to rebuild it > using the compatibility header described before. That may be tricky too... > > /Florent > > > On 26/01/2017 23:34, Michael Ellery wrote: > >> On Jan 26, 2017, at 1:45 PM, Gonzalo Garramu?o >>> wrote: >>> >>> >>> >>> El 26/01/2017 a las 18:35, Michael Ellery escribi?: >>> >>>> In what way is the stdlib incompatible? Does it have bugs, or is this >>>> more a matter of cpp standard support? >>>> >>> I should have been more clear. Sorry. The incompatabilities happen at >>> linker time, with complaints such as: >>> >>> exrstdattr: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found >>> (required by exrstdattr ) >>> exrstdattr: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found >>> (required by /usr/local/mrViewer/lib/libIlmImf-2_2.so.22 ) >>> >>> If I copy the latest libstdc++.so.6 I have on Ubuntu, I get: >>> >>> exrstdattr: /lib64/libc.so.6: version `GLIBC_2.18' not found (required >>> by /usr/local/mrViewer/lib/libstdc++.so.6 ) >>> >>> -- >>> Gonzalo Garramu?o >>> >>> oh, yeah - I wasn?t paying close attention to the fact that you are >> distributing *binaries* ? to a different distro no less. This is why >> projects often either tell users to build from source or they create >> packages (rpms, dpkgs, etc.) on the specific distros and versions. >> >> That said, if you want to distribute binaries to a different distro, I >> guess you can try static linking OR what you suggested, shipping the stdlib >> ? see: >> >> http://stackoverflow.com/questions/13636513/linking-libstdc- >> statically-any-gotchas#14082540 >> >> I personally would not want to ship a stdlib myself, but using CMake?s >> RPATH support, you can probably make it work. >> >> -Mike >> >> > -- > > 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/opensou > rce/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michele.portolan at grenoble-inp.fr Fri Jan 27 12:04:17 2017 From: michele.portolan at grenoble-inp.fr (Michele Portolan) Date: Fri, 27 Jan 2017 18:04:17 +0100 Subject: [CMake] Comaptibility with older gcc In-Reply-To: <4a51970b-6e01-53bd-fcb5-1a475514e809@grenoble-inp.fr> References: <0354b477-32b9-d6bc-31f7-6693b462a608@grenoble-inp.fr> <4a51970b-6e01-53bd-fcb5-1a475514e809@grenoble-inp.fr> Message-ID: I have a project that build correctly using gcc 4.9.3, generating a dynamic library that I can later link to obtain my executables. So, nothing special. My problem is that on one of my target systems, I only have a gcc 4.1.2 and I am forced to use it for at least linking the last executable. My project uses extensively C++14,so I cannot build it with the older gcc. Is there a way to have Cmake generate a library that is compatible with gcc 4.1.2? Regards, Michele From annulen at yandex.ru Fri Jan 27 12:14:48 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Fri, 27 Jan 2017 20:14:48 +0300 Subject: [CMake] Comaptibility with older gcc In-Reply-To: References: <0354b477-32b9-d6bc-31f7-6693b462a608@grenoble-inp.fr> <4a51970b-6e01-53bd-fcb5-1a475514e809@grenoble-inp.fr> Message-ID: <5906021485537288@web25h.yandex.ru> 27.01.2017, 20:04, "Michele Portolan" : > I have a project that build correctly using gcc 4.9.3, generating a > dynamic library that I can later link to obtain my executables. So, > nothing special. > > My problem is that on one of my target systems, I only have a gcc 4.1.2 > and I am forced to use it for at least linking the last executable. My > project uses extensively C++14,so I cannot build it with the older gcc. > > Is there a way to have Cmake generate a library that is compatible with > gcc 4.1.2? Your issue has nothing to do with cmake, but with used compilers / runtimes. Your library will be possibly compatible with gcc 4.1 if it is not linked to libstdc++. To achieve this you have to elemeinate all std:: usages or only carefully chosen subset which does npot require linking. You also should not use any std:: types in public API of your library. > > Regards, > > Michele > -- > > 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 -- Regards, Konstantin From elizabeth.fischer at columbia.edu Fri Jan 27 12:23:39 2017 From: elizabeth.fischer at columbia.edu (Elizabeth A. Fischer) Date: Fri, 27 Jan 2017 12:23:39 -0500 Subject: [CMake] Comaptibility with older gcc In-Reply-To: References: <0354b477-32b9-d6bc-31f7-6693b462a608@grenoble-inp.fr> <4a51970b-6e01-53bd-fcb5-1a475514e809@grenoble-inp.fr> Message-ID: Get spack, then use it to build GCC 4.9.3 takes a couple hours of wall time, five minutes of your time. Github.com/llnl/spack On Jan 27, 2017 12:04 PM, "Michele Portolan" < michele.portolan at grenoble-inp.fr> wrote: > I have a project that build correctly using gcc 4.9.3, generating a > dynamic library that I can later link to obtain my executables. So, nothing > special. > > My problem is that on one of my target systems, I only have a gcc 4.1.2 > and I am forced to use it for at least linking the last executable. My > project uses extensively C++14,so I cannot build it with the older gcc. > > Is there a way to have Cmake generate a library that is compatible with > gcc 4.1.2? > > Regards, > > > Michele > -- > > 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/opensou > rce/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From post at hendrik-sattler.de Fri Jan 27 12:58:37 2017 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Fri, 27 Jan 2017 18:58:37 +0100 Subject: [CMake] Comaptibility with older gcc In-Reply-To: References: <0354b477-32b9-d6bc-31f7-6693b462a608@grenoble-inp.fr> <4a51970b-6e01-53bd-fcb5-1a475514e809@grenoble-inp.fr> Message-ID: <48F83BD5-5DD2-48FA-8526-4F3DC131FDEA@hendrik-sattler.de> Your answer is totally unrelated to the question. Am 27. Januar 2017 18:23:39 MEZ schrieb "Elizabeth A. Fischer" : >Get spack, then use it to build GCC 4.9.3 takes a couple hours of wall >time, five minutes of your time. > >Github.com/llnl/spack >On Jan 27, 2017 12:04 PM, "Michele Portolan" < >michele.portolan at grenoble-inp.fr> wrote: > >> I have a project that build correctly using gcc 4.9.3, generating a >> dynamic library that I can later link to obtain my executables. So, >nothing >> special. >> >> My problem is that on one of my target systems, I only have a gcc >4.1.2 >> and I am forced to use it for at least linking the last executable. >My >> project uses extensively C++14,so I cannot build it with the older >gcc. >> >> Is there a way to have Cmake generate a library that is compatible >with >> gcc 4.1.2? >> >> Regards, >> >> >> Michele >> -- >> >> 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/opensou >> rce/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake >> -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. From elizabeth.fischer at columbia.edu Fri Jan 27 13:05:09 2017 From: elizabeth.fischer at columbia.edu (Elizabeth A. Fischer) Date: Fri, 27 Jan 2017 13:05:09 -0500 Subject: [CMake] Comaptibility with older gcc In-Reply-To: <48F83BD5-5DD2-48FA-8526-4F3DC131FDEA@hendrik-sattler.de> References: <0354b477-32b9-d6bc-31f7-6693b462a608@grenoble-inp.fr> <4a51970b-6e01-53bd-fcb5-1a475514e809@grenoble-inp.fr> <48F83BD5-5DD2-48FA-8526-4F3DC131FDEA@hendrik-sattler.de> Message-ID: C++ code is not compatible between different compilers. You cannot link C++ code built with GCC 4.9.3 with GCC 4.2.1. Maybe if you hack around and find the GNU C++ libraries from your GCC 4.9.3 installation... just maybe, with enough hacking, it will work. But in general, this is a rabbit hole that will offer you very little in the end. The standard way to build on systems that don't have the compilers you need is... to get the compilers you need. My point was that getting these compilers is actually not very hard. In the end, that will almost certainly be the easiest solution to your problem. On Fri, Jan 27, 2017 at 12:58 PM, Hendrik Sattler wrote: > Your answer is totally unrelated to the question. > > Am 27. Januar 2017 18:23:39 MEZ schrieb "Elizabeth A. Fischer" < > elizabeth.fischer at columbia.edu>: > >Get spack, then use it to build GCC 4.9.3 takes a couple hours of wall > >time, five minutes of your time. > > > >Github.com/llnl/spack > >On Jan 27, 2017 12:04 PM, "Michele Portolan" < > >michele.portolan at grenoble-inp.fr> wrote: > > > >> I have a project that build correctly using gcc 4.9.3, generating a > >> dynamic library that I can later link to obtain my executables. So, > >nothing > >> special. > >> > >> My problem is that on one of my target systems, I only have a gcc > >4.1.2 > >> and I am forced to use it for at least linking the last executable. > >My > >> project uses extensively C++14,so I cannot build it with the older > >gcc. > >> > >> Is there a way to have Cmake generate a library that is compatible > >with > >> gcc 4.1.2? > >> > >> Regards, > >> > >> > >> Michele > >> -- > >> > >> 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/opensou > >> rce/opensource.html > >> > >> Follow this link to subscribe/unsubscribe: > >> http://public.kitware.com/mailman/listinfo/cmake > >> > > -- > Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail > gesendet. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From post at hendrik-sattler.de Fri Jan 27 13:05:19 2017 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Fri, 27 Jan 2017 19:05:19 +0100 Subject: [CMake] Comaptibility with older gcc In-Reply-To: References: <0354b477-32b9-d6bc-31f7-6693b462a608@grenoble-inp.fr> <4a51970b-6e01-53bd-fcb5-1a475514e809@grenoble-inp.fr> Message-ID: It depends very much on your target system. The C++-ABI between 4.9 and 4.1 may be compatible but that is not guaranteed. C++14 is also a bit unspecific: language features or library features? Does your library expose any C++11/14 features in its interface? It may just not be possible after all... Am 27. Januar 2017 18:04:17 MEZ schrieb Michele Portolan : >I have a project that build correctly using gcc 4.9.3, generating a >dynamic library that I can later link to obtain my executables. So, >nothing special. > >My problem is that on one of my target systems, I only have a gcc 4.1.2 > >and I am forced to use it for at least linking the last executable. My > >project uses extensively C++14,so I cannot build it with the older gcc. > >Is there a way to have Cmake generate a library that is compatible with > >gcc 4.1.2? > >Regards, > > >Michele -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. From post at hendrik-sattler.de Fri Jan 27 13:08:15 2017 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Fri, 27 Jan 2017 19:08:15 +0100 Subject: [CMake] Comaptibility with older gcc In-Reply-To: References: <0354b477-32b9-d6bc-31f7-6693b462a608@grenoble-inp.fr> <4a51970b-6e01-53bd-fcb5-1a475514e809@grenoble-inp.fr> <48F83BD5-5DD2-48FA-8526-4F3DC131FDEA@hendrik-sattler.de> Message-ID: <896E8CF1-33F3-4BFE-A1CE-3BC1632B301D@hendrik-sattler.de> If the target platform has an adapted gcc that does not match upstream gcc, or may not be possible to just compile a newer version. Or it is a discontinued arch. Am 27. Januar 2017 19:05:09 MEZ schrieb "Elizabeth A. Fischer" : >C++ code is not compatible between different compilers. You cannot >link >C++ code built with GCC 4.9.3 with GCC 4.2.1. Maybe if you hack around >and >find the GNU C++ libraries from your GCC 4.9.3 installation... just >maybe, >with enough hacking, it will work. But in general, this is a rabbit >hole >that will offer you very little in the end. > >The standard way to build on systems that don't have the compilers you >need >is... to get the compilers you need. My point was that getting these >compilers is actually not very hard. In the end, that will almost >certainly be the easiest solution to your problem. > > >On Fri, Jan 27, 2017 at 12:58 PM, Hendrik Sattler > >wrote: > >> Your answer is totally unrelated to the question. >> >> Am 27. Januar 2017 18:23:39 MEZ schrieb "Elizabeth A. Fischer" < >> elizabeth.fischer at columbia.edu>: >> >Get spack, then use it to build GCC 4.9.3 takes a couple hours of >wall >> >time, five minutes of your time. >> > >> >Github.com/llnl/spack >> >On Jan 27, 2017 12:04 PM, "Michele Portolan" < >> >michele.portolan at grenoble-inp.fr> wrote: >> > >> >> I have a project that build correctly using gcc 4.9.3, generating >a >> >> dynamic library that I can later link to obtain my executables. >So, >> >nothing >> >> special. >> >> >> >> My problem is that on one of my target systems, I only have a gcc >> >4.1.2 >> >> and I am forced to use it for at least linking the last >executable. >> >My >> >> project uses extensively C++14,so I cannot build it with the older >> >gcc. >> >> >> >> Is there a way to have Cmake generate a library that is compatible >> >with >> >> gcc 4.1.2? >> >> >> >> Regards, >> >> >> >> >> >> Michele >> >> -- >> >> >> >> 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/opensou >> >> rce/opensource.html >> >> >> >> Follow this link to subscribe/unsubscribe: >> >> http://public.kitware.com/mailman/listinfo/cmake >> >> >> >> -- >> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail >> gesendet. >> -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. From rjh at sixdemonbag.org Fri Jan 27 13:09:32 2017 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 27 Jan 2017 18:09:32 +0000 Subject: [CMake] Comaptibility with older gcc In-Reply-To: References: <0354b477-32b9-d6bc-31f7-6693b462a608@grenoble-inp.fr> <4a51970b-6e01-53bd-fcb5-1a475514e809@grenoble-inp.fr> <48F83BD5-5DD2-48FA-8526-4F3DC131FDEA@hendrik-sattler.de> Message-ID: <7df0e471-81cf-63b1-4be5-e8a246f0f5ee@sixdemonbag.org> > C++ code is not compatible between different compilers. This is only kinda-sorta true. Clang and G++ interoperate quite nicely on Linux, for instance, since they both implement the Itanium-style ABI. I believe Intel's C++ compiler on Windows implements the same ABI as MSVC++. There are no guarantees of compatibility between different compilers, but it's a little much to say there is no compatibility. From annulen at yandex.ru Fri Jan 27 13:01:50 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Fri, 27 Jan 2017 21:01:50 +0300 Subject: [CMake] Comaptibility with older gcc In-Reply-To: References: <0354b477-32b9-d6bc-31f7-6693b462a608@grenoble-inp.fr> <4a51970b-6e01-53bd-fcb5-1a475514e809@grenoble-inp.fr> Message-ID: <5159541485540110@web18g.yandex.ru> 27.01.2017, 20:04, "Michele Portolan" : > I have a project that build correctly using gcc 4.9.3, generating a > dynamic library that I can later link to obtain my executables. So, > nothing special. > > My problem is that on one of my target systems, I only have a gcc 4.1.2 > and I am forced to use it for at least linking the last executable. Do you have to use libstdc++ from gcc 4.1.2? If no, using gcc for linking does not differ much from using ld directly, and does not create any issues, provided that you compile your other code with gcc 4.9 and you don't link any other libraries depending on gcc 4.1 libraries >My project uses extensively C++14,so I cannot build it with the older gcc. > > Is there a way to have Cmake generate a library that is compatible with > gcc 4.1.2? > > Regards, > > Michele > -- > > 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 -- Regards, Konstantin From annulen at yandex.ru Fri Jan 27 13:08:08 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Fri, 27 Jan 2017 21:08:08 +0300 Subject: [CMake] Comaptibility with older gcc In-Reply-To: References: <0354b477-32b9-d6bc-31f7-6693b462a608@grenoble-inp.fr> <4a51970b-6e01-53bd-fcb5-1a475514e809@grenoble-inp.fr> <48F83BD5-5DD2-48FA-8526-4F3DC131FDEA@hendrik-sattler.de> Message-ID: <5167351485540488@web18g.yandex.ru> 27.01.2017, 21:05, "Elizabeth A. Fischer" : > C++ code is not compatible between different compilers.? This is not true for compilers implementing Itanium C++ ABI, including GCC. The only possible source of incompatibility comes from different standard library versions. >You cannot link C++ code built with GCC 4.9.3 with GCC 4.2.1.? Maybe if you hack around and find the GNU C++ libraries from your GCC 4.9.3 installation... just maybe, with enough hacking, it will work.? But in general, this is a rabbit hole that will offer you very little in the end. > > The standard way to build on systems that don't have the compilers you need is... to get the compilers you need.? My point was that getting these compilers is actually not very hard.? In the end, that will almost certainly be the easiest solution to your problem. > > On Fri, Jan 27, 2017 at 12:58 PM, Hendrik Sattler wrote: >> Your answer is totally unrelated to the question. >> >> Am 27. Januar 2017 18:23:39 MEZ schrieb "Elizabeth A. Fischer" : >>>Get spack, then use it to build GCC 4.9.3? takes a couple hours of wall >>>time, five minutes of your time. >>> >>>Github.com/llnl/spack >>>On Jan 27, 2017 12:04 PM, "Michele Portolan" < >>>michele.portolan at grenoble-inp.fr> wrote: >>> >>>> I have a project that build correctly using gcc 4.9.3, generating a >>>> dynamic library that I can later link to obtain my executables. So, >>>nothing >>>> special. >>>> >>>> My problem is that on one of my target systems, I only have a gcc >>>4.1.2 >>>> and I am forced to use it for at least? linking the last executable. >>>My >>>> project uses extensively C++14,so I cannot build it with the older >>>gcc. >>>> >>>> Is there a way to have Cmake generate a library that is compatible >>>with >>>> gcc 4.1.2? >>>> >>>> Regards, >>>> >>>> >>>> Michele >>>> -- >>>> >>>> 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/opensou >>>> rce/opensource.html >>>> >>>> Follow this link to subscribe/unsubscribe: >>>> http://public.kitware.com/mailman/listinfo/cmake >>>> >> >> -- >> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. > ,-- > > 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 --? Regards, Konstantin From zlynx at acm.org Fri Jan 27 13:05:19 2017 From: zlynx at acm.org (Zan Lynx) Date: Fri, 27 Jan 2017 11:05:19 -0700 Subject: [CMake] Comaptibility with older gcc In-Reply-To: References: <0354b477-32b9-d6bc-31f7-6693b462a608@grenoble-inp.fr> <4a51970b-6e01-53bd-fcb5-1a475514e809@grenoble-inp.fr> Message-ID: <0f510471-abab-f4c3-b3ca-f15e59278d99@acm.org> On 1/27/2017 10:04 AM, Michele Portolan wrote: > I have a project that build correctly using gcc 4.9.3, generating a > dynamic library that I can later link to obtain my executables. So, > nothing special. > > My problem is that on one of my target systems, I only have a gcc 4.1.2 > and I am forced to use it for at least linking the last executable. My > project uses extensively C++14,so I cannot build it with the older gcc. > > Is there a way to have Cmake generate a library that is compatible with > gcc 4.1.2? I think your choices are to rewrite without C++14 or to include all of the static C++ support libraries into your library. You will need to make all your symbols hidden and then explicitly mark what you want exported. You should be doing that anyway of course. And when linking in the static libraries you will want to be sure that ld in the link step is using -exclude-libs ALL option. Because if any C++14 symbols escape from your .so it will screw up the C++03 link. Also, you won't be able to pass any complex objects or exceptions between libraries because the internal implementation of std::list and std::string has changed from 2003 to 2014. From dflogeras2 at gmail.com Fri Jan 27 14:45:39 2017 From: dflogeras2 at gmail.com (Dave Flogeras) Date: Fri, 27 Jan 2017 15:45:39 -0400 Subject: [CMake] CMake 3.7.2 and parallel builds Message-ID: I've recently upgraded to CMake 3.7.2 (and gnu make-4.2.1). Now, when I execute 'make -j5 NightlyBuild', I get the following new (to me) warning: "gmake[4]: warning: jobserver unavailable: using -j1. Add '+' to parent make rule." If I downgrade make back to the previous version, 4.1-r1 (the -r1 is Gentoo), the warning goes away again. If I use CMake-3.6.3 (my previous version) with make-4.2.1, the warning is still there. Is this a known issue? Is it something I am doing wrong in my scripts? Thanks, Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From michele.portolan at grenoble-inp.fr Sat Jan 28 03:17:15 2017 From: michele.portolan at grenoble-inp.fr (Michele Portolan) Date: Sat, 28 Jan 2017 09:17:15 +0100 Subject: [CMake] Comaptibility with older gcc In-Reply-To: <896E8CF1-33F3-4BFE-A1CE-3BC1632B301D@hendrik-sattler.de> References: <0354b477-32b9-d6bc-31f7-6693b462a608@grenoble-inp.fr> <4a51970b-6e01-53bd-fcb5-1a475514e809@grenoble-inp.fr> <48F83BD5-5DD2-48FA-8526-4F3DC131FDEA@hendrik-sattler.de> <896E8CF1-33F3-4BFE-A1CE-3BC1632B301D@hendrik-sattler.de> Message-ID: <91815ad4-6451-e332-86c2-9639af0dcda9@grenoble-inp.fr> Thanks for all the feedback. I cannot go into the details, but the deployment target is a production machine for which I have no installation privileges, and where "stability is king", so asking for updates is out of the question. I am offered an Eclispe environment and have to work on it, hence my idea of importing the cmake-built library (static or dynamic, whichever works better) into the Eclipse projet and include it. I was also doubting about libstdc++ versions, is there maybe a way of asking Cmake to statistically include it in the built library? Regards, Michele Le 27/01/2017 ? 19:08, Hendrik Sattler a ?crit : > If the target platform has an adapted gcc that does not match upstream gcc, or may not be possible to just compile a newer version. Or it is a discontinued arch. > > > Am 27. Januar 2017 19:05:09 MEZ schrieb "Elizabeth A. Fischer" : >> C++ code is not compatible between different compilers. You cannot >> link >> C++ code built with GCC 4.9.3 with GCC 4.2.1. Maybe if you hack around >> and >> find the GNU C++ libraries from your GCC 4.9.3 installation... just >> maybe, >> with enough hacking, it will work. But in general, this is a rabbit >> hole >> that will offer you very little in the end. >> >> The standard way to build on systems that don't have the compilers you >> need >> is... to get the compilers you need. My point was that getting these >> compilers is actually not very hard. In the end, that will almost >> certainly be the easiest solution to your problem. >> >> >> On Fri, Jan 27, 2017 at 12:58 PM, Hendrik Sattler >> >> wrote: >> >>> Your answer is totally unrelated to the question. >>> >>> Am 27. Januar 2017 18:23:39 MEZ schrieb "Elizabeth A. Fischer" < >>> elizabeth.fischer at columbia.edu>: >>>> Get spack, then use it to build GCC 4.9.3 takes a couple hours of >> wall >>>> time, five minutes of your time. >>>> >>>> Github.com/llnl/spack >>>> On Jan 27, 2017 12:04 PM, "Michele Portolan" < >>>> michele.portolan at grenoble-inp.fr> wrote: >>>> >>>>> I have a project that build correctly using gcc 4.9.3, generating >> a >>>>> dynamic library that I can later link to obtain my executables. >> So, >>>> nothing >>>>> special. >>>>> >>>>> My problem is that on one of my target systems, I only have a gcc >>>> 4.1.2 >>>>> and I am forced to use it for at least linking the last >> executable. >>>> My >>>>> project uses extensively C++14,so I cannot build it with the older >>>> gcc. >>>>> Is there a way to have Cmake generate a library that is compatible >>>> with >>>>> gcc 4.1.2? >>>>> >>>>> Regards, >>>>> >>>>> >>>>> Michele >>>>> -- >>>>> >>>>> 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/opensou >>>>> rce/opensource.html >>>>> >>>>> Follow this link to subscribe/unsubscribe: >>>>> http://public.kitware.com/mailman/listinfo/cmake >>>>> >>> -- >>> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail >>> gesendet. >>> From dan at su-root.co.uk Sat Jan 28 04:45:47 2017 From: dan at su-root.co.uk (Dan Liew) Date: Sat, 28 Jan 2017 09:45:47 +0000 Subject: [CMake] Comaptibility with older gcc In-Reply-To: <91815ad4-6451-e332-86c2-9639af0dcda9@grenoble-inp.fr> References: <0354b477-32b9-d6bc-31f7-6693b462a608@grenoble-inp.fr> <4a51970b-6e01-53bd-fcb5-1a475514e809@grenoble-inp.fr> <48F83BD5-5DD2-48FA-8526-4F3DC131FDEA@hendrik-sattler.de> <896E8CF1-33F3-4BFE-A1CE-3BC1632B301D@hendrik-sattler.de> <91815ad4-6451-e332-86c2-9639af0dcda9@grenoble-inp.fr> Message-ID: > I was also doubting about libstdc++ versions, is there maybe a way of asking > Cmake to statistically include it in the built library? I assume you mean statically. If so then you could try invoking cmake like this on the command line. ``` mkdir new_build_dir cd new_build_dir CXXFLAGS="-static-libstdc++ " CFLAGS="-static-libstdc++" cmake /path/to/source/tree make -j$(nproc) ``` Note that `new_build_dir` must be empty every time you invoke the `cmake` command because it will only try to detect your compiler once. Subsequent invocations of cmake in an existing build directory does not change the compiler and setting CXXFLAGS and CFLAGS to different values has no effect. However I don't think this is the best approach. I think you would be much better of recreating the production environment on your development machine. This makes it much easier to reproduce issues you may hit in production. There are many ways about doing this but my suggestion would be to use Docker or a virtual machine for that purpose. You mention you want to use Eclipse so what you could do is develop your application on your local machine (i.e. outside of Docker or the virtual machine) but have your source files mounted into your Docker container (these are called volume mounts) or the virtual machine. That way you can use Eclipse for your development locally but when you want to, you can do a build inside the container/vm using the same source files to test the build still works and also produce binaries that will "just work" on your production system. HTH, Dan. From craig.scott at crascit.com Sat Jan 28 05:46:40 2017 From: craig.scott at crascit.com (Craig Scott) Date: Sat, 28 Jan 2017 21:46:40 +1100 Subject: [CMake] Comaptibility with older gcc In-Reply-To: References: <0354b477-32b9-d6bc-31f7-6693b462a608@grenoble-inp.fr> <4a51970b-6e01-53bd-fcb5-1a475514e809@grenoble-inp.fr> <48F83BD5-5DD2-48FA-8526-4F3DC131FDEA@hendrik-sattler.de> <896E8CF1-33F3-4BFE-A1CE-3BC1632B301D@hendrik-sattler.de> <91815ad4-6451-e332-86c2-9639af0dcda9@grenoble-inp.fr> Message-ID: It's probably outside of the set of possible solutions to your particular problem, but I'll mention this one in case it interests others following the topic. For potentially the broadest compatibility, one could consider using the LSB (Linux Standards Base) to build binaries that are guaranteed to run across a lot of different distributions and versions. Unfortunately, the LSB tends to trail quite a long way behind the latest capabilities and it seems to have lost momentum in recent years, but I've used it in the past to build one binary package which can then be deployed to many systems (this included a full GUI Qt application). If you want to use C++11 or later though, from what I understand I think you're out of luck (but do your own research, I could be wrong on that). One place to start with the LSB is the LSB Navigator. It contains links to the official parts of the standard so you can get a formal reference to what it covers. http://www.linuxbase.org/navigator/commons/welcome.php Something potentially more useful for your particular case is the application checker included in the LSB tools. It can analyse a whole package or just an application and provide a report listing any symbols that will be missing on a variety of different linux distributions. https://wiki.linuxfoundation.org/lsb/check-your-app I've found that app checker to be particularly useful in the past, but it has been some years since I've used it, so I can't comment on how good it is these days. Don't worry so much about the certification aspects of the LSB, it's useful just to build/test portable applications and packages and you don't have to go the certification route just to use the LSB tools. Many linux distributions don't seek to certify themselves but offer pretty good compliance anyway (or at least they used to). On Sat, Jan 28, 2017 at 8:45 PM, Dan Liew wrote: > > I was also doubting about libstdc++ versions, is there maybe a way of > asking > > Cmake to statistically include it in the built library? > > I assume you mean statically. If so then you could try invoking cmake > like this on the command line. > > ``` > mkdir new_build_dir > cd new_build_dir > CXXFLAGS="-static-libstdc++ " CFLAGS="-static-libstdc++" cmake > /path/to/source/tree > make -j$(nproc) > ``` > > Note that `new_build_dir` must be empty every time you invoke the > `cmake` command > because it will only try to detect your compiler once. Subsequent > invocations of cmake > in an existing build directory does not change the compiler and > setting CXXFLAGS and > CFLAGS to different values has no effect. > > However I don't think this is the best approach. I think you would be > much better of recreating > the production environment on your development machine. This makes it > much easier to reproduce > issues you may hit in production. > > There are many ways about doing this but my suggestion would be to use > Docker or a virtual machine for that purpose. > > You mention you want to use Eclipse so what you could do is develop > your application on your local machine (i.e. outside of Docker or the > virtual machine) > but have your source files mounted into your Docker container (these > are called volume mounts) or the virtual machine. > > That way you can use Eclipse for your development locally but when you > want to, you can do a build inside the container/vm using the same > source files > to test the build still works and also produce binaries that will > "just work" on your production system. > > HTH, > Dan. > -- > > 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 > -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at mad-scientist.net Sat Jan 28 09:43:19 2017 From: paul at mad-scientist.net (Paul Smith) Date: Sat, 28 Jan 2017 09:43:19 -0500 Subject: [CMake] CMake 3.7.2 and parallel builds In-Reply-To: References: Message-ID: <1485614599.3653.102.camel@mad-scientist.net> On Fri, 2017-01-27 at 15:45 -0400, Dave Flogeras wrote: > I've recently upgraded to CMake 3.7.2 (and gnu make-4.2.1). Now, when > I execute 'make -j5 NightlyBuild', I get the following new (to me) > warning: > > "gmake[4]: warning: jobserver unavailable: using -j1.? Add '+' to parent make rule." > > If I downgrade make back to the previous version, 4.1-r1 (the -r1 is > Gentoo), the warning goes away again. > > If I use CMake-3.6.3 (my previous version) with make-4.2.1, the > warning is still there. > > Is this a known issue?? Is it something I am doing wrong in my > scripts? My suspicion is that somehow the recursion is invoking an older version of make. In GNU make 4.2 the jobserver interface was stabilized and published, so that other build tools could take advantage of it (if desired); for example if your linker is multithreaded it could participate in the jobserver feature, obtaining jobserver tokens for its threads so it didn't overwhelm the system during linking. As part of this the command-line interface between a parent make and its sub-makes was changed. This means that if a parent make tries to invoke a sub-make and they have different versions there may be an incompatibility. Normally this is very difficult to do because GNU make sets the MAKE variable to the version of make which is currently running (as best it can determine it) and everyone should be invoking submakes using the $(MAKE) variable. But, perhaps something in your setup is confounding this normal behavior. You can try adding "VERBOSE=1" to your make invocation and look at the way sub-makes are invoked and see if there's anything odd-looking about it. If that's not it, I'm not sure what the problem is but perhaps the VERBOSE=1 will help diagnose it anyway. From dflogeras2 at gmail.com Sun Jan 29 07:29:07 2017 From: dflogeras2 at gmail.com (Dave Flogeras) Date: Sun, 29 Jan 2017 08:29:07 -0400 Subject: [CMake] CMake 3.7.2 and parallel builds In-Reply-To: <1485614599.3653.102.camel@mad-scientist.net> References: <1485614599.3653.102.camel@mad-scientist.net> Message-ID: Hey Paul On Sat, Jan 28, 2017 at 10:43 AM, Paul Smith wrote: > My suspicion is that somehow the recursion is invoking an older version > of make. In GNU make 4.2 the jobserver interface was stabilized and > published, so that other build tools could take advantage of it (if > desired); for example if your linker is multithreaded it could > participate in the jobserver feature, obtaining jobserver tokens for its > threads so it didn't overwhelm the system during linking. > > I scoured this system, and others that run make 4.2.1, and that is the only version of make in my PATH. You can try adding "VERBOSE=1" to your make invocation and look at the > way sub-makes are invoked and see if there's anything odd-looking about > it. > > If that's not it, I'm not sure what the problem is but perhaps the > VERBOSE=1 will help diagnose it anyway. > I tried with "make -j5 VERBOSE=1 NightlyBuild" but didn't see anything indicative on the console, or in the cmake output files that shed any light for me. What's weirder (and I forgot to mention) is that if I just build the project normally outside of my regression testing script (ie. "make -j5"), I don't get the jobserver warning. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Sun Jan 29 08:53:12 2017 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Sun, 29 Jan 2017 14:53:12 +0100 Subject: [CMake] CMake 3.7.2 and parallel builds In-Reply-To: References: <1485614599.3653.102.camel@mad-scientist.net> Message-ID: On 29.01.2017 13:29, Dave Flogeras wrote: > > I tried with "make -j5 VERBOSE=1 NightlyBuild" but didn't see anything > indicative on the console, or in the cmake output files that shed any > light for me. > > What's weirder (and I forgot to mention) is that if I just build the > project normally outside of my regression testing script (ie. "make > -j5"), I don't get the jobserver warning. FWIW I don't think -j does anything when you build the NightlyBuild target given that that make invocation is not the one directly performing the actual build. The only command being run by the NightlyBuild target would be "ctest -D NightlyBuild" (nothing to parallelize when there is only one command). CTest would spawn another make process for the build. Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan at su-root.co.uk Sun Jan 29 12:11:47 2017 From: dan at su-root.co.uk (Dan Liew) Date: Sun, 29 Jan 2017 17:11:47 +0000 Subject: [CMake] CMake 3.7.2 and parallel builds In-Reply-To: References: <1485614599.3653.102.camel@mad-scientist.net> Message-ID: > What's weirder (and I forgot to mention) is that if I just build the project > normally outside of my regression testing script (ie. "make -j5"), I don't > get the jobserver warning. The reason for this error message from make is given at [1]. I've seen something like this before when my build used "Unix Makefiles" as the generator and the build invoked an external build system as a `add_custom_command()` that also used makefiles to do its build. The problem was that make (in the outer most build system, i.e. the CMake generated) one was setting the `MAKEFLAGS` environment variable to do communicate various bits of information to handle recursive makefiles (see [2]). This works fine until the CMake generated makefiles invoked the external build system with `MAKEFLAGS` being set. My solution was to strip `MAKEFLAGS` out of the environment when invoking the `make` command externally. This isn't exactly your problem but it may help you figure out what is wrong. My guess is that the sub-make isn't being invoked correctly. [1] https://www.gnu.org/software/make/manual/html_node/Error-Messages.html [2] https://www.gnu.org/software/make/manual/html_node/Options_002fRecursion.html From david.jobet at free.fr Sun Jan 29 15:20:28 2017 From: david.jobet at free.fr (David Jobet) Date: Sun, 29 Jan 2017 20:20:28 +0000 Subject: [CMake] externalproject_add and generating sources In-Reply-To: References: <751181391.78013628.1485422588735.JavaMail.root@zimbra63-e11> Message-ID: <0B428F02-C74F-4460-BE4F-9264B4447479@free.fr> Hello, Yes, main reason is I had to hack FindProtobuf.cmake to make our existing project compile. Also since I need to make it "installable", I had to add some stuff to have the binaries and header installed automatically when referenced. The latter reason led me to experiment with ExternalProject. David Le 26 janvier 2017 16:05:47 GMT+00:00, Michael Ellery a ?crit : > >> On Jan 26, 2017, at 1:23 AM, David Jobet wrote: >> >> Hello, >> >> suppose I want to use protobuf and integrate it in my project with >externalproject_add. (actually, I just have precompiled binaries and >libs + header files, I don't have the full sources) >> Once the project has been 'built' (actually, installed by a custom >rpm-like tool to a shared path), I can use the protoc compiler to >generate protobuf c++ files (.pb.h and .pb.cpp files) from a .proto >description file. >> I can add_dependencies so that the external project is built before >projects depending on libprotobuf.a. >> >> However, I don't know how to do the same thing with .pb.h and .pb.cpp >files which use a .proto file and the protoc compiler. >> >> make is fine with it, but ninja complains with an error like this : >> ninja: error: >'/path_to_external_projects/protobuf/2.6.0.4/bin/protoc', needed by >'some_project/SomeFile.pb.h', missing and no known rule to make it >> >> how can I tell ninja that protoc is going to be provided by >externalproject ? >> If I use byproducts, ninja is happy, but "ninja clean" deletes >/path_to_external_projects/protobuf/2.6.0.4/bin/protoc. >> I don't want that to happen since >/path_to_external_projects/protobuf/2.6.0.4/bin/protoc is shared with >other users. >> > >I?ve never used protobufs as an external project (I?ve always just done >a one-time setup/install)?but is there a reason you can?t just use the >standard finder to locate it? >https://github.com/Kitware/CMake/blob/master/Modules/FindProtobuf.cmake > >-Mike -- Envoy? de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma bri?vet?. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.jobet at free.fr Sun Jan 29 15:24:28 2017 From: david.jobet at free.fr (David Jobet) Date: Sun, 29 Jan 2017 20:24:28 +0000 Subject: [CMake] externalproject_add and generating sources In-Reply-To: References: <751181391.78013628.1485422588735.JavaMail.root@zimbra63-e11> Message-ID: <00689C26-03BA-4E12-AAA6-E3065F845724@free.fr> Oh ok, I see how it works, it makes sense, but I'm somehow disappointed : in order to use it, I'm going to have to change my own project while I originally thought it was going to be a kind of FindXXX on steroid... I'll give it a try though, tx for pointing it out. David Le 26 janvier 2017 13:02:43 GMT+00:00, Nicholas Braden a ?crit : >You'll also want to build your own project with ExternalProject, and >use >the DEPENDS option to control build order. This ensures that all >dependencies are fully installed before your own project is even >configured. The project with all the ExternalProject calls is typically >called a superbuild, and effectively becomes an optional convenience to >building your own project. > >On Thu, Jan 26, 2017 at 3:23 AM, David Jobet >wrote: > >> Hello, >> >> suppose I want to use protobuf and integrate it in my project with >> externalproject_add. (actually, I just have precompiled binaries and >libs + >> header files, I don't have the full sources) >> Once the project has been 'built' (actually, installed by a custom >> rpm-like tool to a shared path), I can use the protoc compiler to >generate >> protobuf c++ files (.pb.h and .pb.cpp files) from a .proto >description file. >> I can add_dependencies so that the external project is built before >> projects depending on libprotobuf.a. >> >> However, I don't know how to do the same thing with .pb.h and .pb.cpp >> files which use a .proto file and the protoc compiler. >> >> make is fine with it, but ninja complains with an error like this : >> ninja: error: >'/path_to_external_projects/protobuf/2.6.0.4/bin/protoc', >> needed by 'some_project/SomeFile.pb.h', missing and no known rule to >make it >> >> how can I tell ninja that protoc is going to be provided by >> externalproject ? >> If I use byproducts, ninja is happy, but "ninja clean" deletes >> /path_to_external_projects/protobuf/2.6.0.4/bin/protoc. >> I don't want that to happen since >/path_to_external_projects/protobuf/ >> 2.6.0.4/bin/protoc is shared with other users. >> >> With regards >> >> David >> -- >> >> 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 >> -- Envoy? de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma bri?vet?. -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.neundorf-work at gmx.net Sun Jan 29 16:36:16 2017 From: a.neundorf-work at gmx.net (Alexander Neundorf) Date: Sun, 29 Jan 2017 22:36:16 +0100 Subject: [CMake] Forcing linking compatability to old libc / libstdc++ (Linux) In-Reply-To: <802aeca1-99bf-fc7e-5298-25b9c303e277@gmail.com> References: <802aeca1-99bf-fc7e-5298-25b9c303e277@gmail.com> Message-ID: <1823948.9KigSHuUzn@linux-l7nd> On 2017 M01 26, Thu 18:23:05 CET Gonzalo Garramu?o wrote: > I currently own an Ubuntu Xenial 14.04.1 LTS box in which I do all my > work. I distribute a binary image viewer. However, recently one of > my users tried to run the viewer on a CentOS 7 distro and found out that > that distro libc and libstdc++ are older and incompatible. > > I would like to compile my program targeting the older libc and > libstdc++. Those files come with symbol version and visibility. Is > there an easy way to do that other than copying the old libraries? you may consider using docker to provide a build environment for an "old" distribution (CentOS 7 is actually quite bleeding edge... ;-) ) There are some CentOS5 images on dockerhub. Alex From jsvanbethlehem at gmail.com Mon Jan 30 05:04:41 2017 From: jsvanbethlehem at gmail.com (Jakob van Bethlehem) Date: Mon, 30 Jan 2017 11:04:41 +0100 Subject: [CMake] Not being able to create a 'link' interface for an OBJECT library Message-ID: Dear all, Recently I read the excellent tip of creating a 'link interface' for an OBJECT library in order to overcome the inability to directly link an OBJECT library, see: https://cmake.org/cmake/help/v3.5/manual/cmake-buildsystem.7.html#object-libraries This sounded like a perfect idea, so I tried it out on Windows 7 with the VS 2013 64bit generator. The first step was to build a shared library out of an object library, which worked like a charm: ==== ## Setup OBJECT library and a 'object link interface' add_library(MyLib.Object OBJECT ... sources .. ) target_include_directories(MyLib.Object PUBLIC .... includes ) add_library(MyLib.Object.LinkInterface INTERFACE) target_sources(MyLib.Object.LinkInterface INTERFACE $) target_include_directories(MyLib.Object.LinkInterface INTERFACE $ ) target_link_libraries(MyLib.Object.LinkInterface INTERFACE .... some dependent libraries ) ## set up shared library: add_library(MyLib SHARED .. some additional sources ) target_link_libraries(MyLib PUBLIC MyLib.Object.LinkInterface ) ==== The second step was to try to create an executable that links with the shared library. That is were I ran into some problems I can't quite fathom: ==== add_executable(MyExe ... sources ... ) target_link_libraries(MyExe MyLib ) ==== This results in the following error from CMake: CMake Error at MyExe/CMakeLists.txt:16 (add_executable): Cannot find source file: /InstrumentControl.Object.dir/$(Configuration)/InstrumentControl.obj Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp .hxx .in .txx It seems that for some reason CMake is trying to reuse the same target sources on the executable, which doesn't make any sense really, as I'm trying to link against a normal shared library. The solution is to remove the 'target_sources' and put the $ directly as a source when creating the shared library. That is quite unfortunate however. The entire purpose of the 'object link interface' was to remove the need to put these generator expressions where there are needed, as explained on the documentation page I referred to above. So, the questions I have: - should the described procedure work? - if yes, did I something wrong, or did I stumble across a CMake bug? - if no, it makes sense to put in a very clear warning on the referred webpage, that the 'trick' will *not* work if one ever tries to link against the final library...... ajjjj Sincerely, Jakob -------------- next part -------------- An HTML attachment was scrubbed... URL: From eldlistmailingz at tropicsoft.com Mon Jan 30 06:44:48 2017 From: eldlistmailingz at tropicsoft.com (Edward Diener) Date: Mon, 30 Jan 2017 03:44:48 -0800 Subject: [CMake] Adding cache entries to cmake gui Message-ID: Using the cmake gui program of the latest cmake 3.7.2 I add a cache entry of CMAKE_CXX_FLAGS to some compile flag value, but as soon as I hit the generate button the cache entry disappears and is no longer retained. Is CMAKE_CXX_FLAGS no longer a valid cmake variable ? If it is not a valid cmake variable, what cmake variable can I use to add a cpp compiler flag to my cmake build ? From nilsgladitz at gmail.com Mon Jan 30 07:44:36 2017 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Mon, 30 Jan 2017 13:44:36 +0100 Subject: [CMake] Adding cache entries to cmake gui In-Reply-To: References: Message-ID: <0ef748aa-c0f7-1e3a-fb1c-5688d742b23e@gmail.com> On 01/30/2017 12:44 PM, Edward Diener wrote: > Using the cmake gui program of the latest cmake 3.7.2 I add a cache > entry of CMAKE_CXX_FLAGS to some compile flag value, but as soon as I > hit the generate button the cache entry disappears and is no longer > retained. Is CMAKE_CXX_FLAGS no longer a valid cmake variable ? If it > is not a valid cmake variable, what cmake variable can I use to add a > cpp compiler flag to my cmake build ? > CMAKE_CXX_FLAGS is an advanced cache variable that should implicitly exist in a C++ project (it does not have to be added). Advanced cache variables are hidden by default. Did you check the "Advanced" option in cmake-gui? Nils From dflogeras2 at gmail.com Mon Jan 30 08:26:33 2017 From: dflogeras2 at gmail.com (Dave Flogeras) Date: Mon, 30 Jan 2017 09:26:33 -0400 Subject: [CMake] CMake 3.7.2 and parallel builds In-Reply-To: References: <1485614599.3653.102.camel@mad-scientist.net> Message-ID: On Sun, Jan 29, 2017 at 9:53 AM, Nils Gladitz wrote: > FWIW I don't think -j does anything when you build the NightlyBuild target > given that that make invocation is not the one directly performing the > actual build. > The only command being run by the NightlyBuild target would be "ctest -D > NightlyBuild" (nothing to parallelize when there is only one command). > CTest would spawn another make process for the build. > > Nils > Good point, I checked with the older version of make (4.1) and even though it doesn't issue the warning, it is not building my project in parallel. I guess that brings up the obvious question: how does one use this target and take advantage of multiple processors? Basically, I'm calling it within a python loop that permutes various projects and configurations (release/debug/shared/static...) then puts the results on a self-hosted CDash server with make NightlySubmit. I thought it used to parallelize the builds, but the script is a few years old and I wouldn't bet my life on it. Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Mon Jan 30 08:38:54 2017 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Mon, 30 Jan 2017 14:38:54 +0100 Subject: [CMake] CMake 3.7.2 and parallel builds In-Reply-To: References: <1485614599.3653.102.camel@mad-scientist.net> Message-ID: <48bd961f-3638-4226-2b4d-980e20634cae@gmail.com> On 01/30/2017 02:26 PM, Dave Flogeras wrote: > On Sun, Jan 29, 2017 at 9:53 AM, Nils Gladitz > wrote: > > FWIW I don't think -j does anything when you build the > NightlyBuild target given that that make invocation is not the one > directly performing the actual build. > The only command being run by the NightlyBuild target would be > "ctest -D NightlyBuild" (nothing to parallelize when there is only > one command). > CTest would spawn another make process for the build. > > Nils > > > Good point, I checked with the older version of make (4.1) and even > though it doesn't issue the warning, it is not building my project in > parallel. > > I guess that brings up the obvious question: how does one use this > target and take advantage of multiple processors? Basically, I'm > calling it within a python loop that permutes various projects and > configurations (release/debug/shared/static...) then puts the results > on a self-hosted CDash server with make NightlySubmit. I don't know how to do this with the generic dashboard targets ... assuming no one else does either you could give CTest script mode a try (ctest -S). In script mode the ctest_build() command has a FLAGS option which takes build tool specific options like -j. Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: From eldlistmailingz at tropicsoft.com Mon Jan 30 10:45:10 2017 From: eldlistmailingz at tropicsoft.com (Edward Diener) Date: Mon, 30 Jan 2017 07:45:10 -0800 Subject: [CMake] Adding cache entries to cmake gui In-Reply-To: <0ef748aa-c0f7-1e3a-fb1c-5688d742b23e@gmail.com> References: <0ef748aa-c0f7-1e3a-fb1c-5688d742b23e@gmail.com> Message-ID: On 1/30/2017 4:44 AM, Nils Gladitz wrote: > On 01/30/2017 12:44 PM, Edward Diener wrote: > >> Using the cmake gui program of the latest cmake 3.7.2 I add a cache >> entry of CMAKE_CXX_FLAGS to some compile flag value, but as soon as I >> hit the generate button the cache entry disappears and is no longer >> retained. Is CMAKE_CXX_FLAGS no longer a valid cmake variable ? If it >> is not a valid cmake variable, what cmake variable can I use to add a >> cpp compiler flag to my cmake build ? >> > > CMAKE_CXX_FLAGS is an advanced cache variable that should implicitly > exist in a C++ project (it does not have to be added). > Advanced cache variables are hidden by default. > Did you check the "Advanced" option in cmake-gui? That was it. Thanks ! From alex at ahans.de Tue Jan 31 05:17:07 2017 From: alex at ahans.de (Alexander Hans) Date: Tue, 31 Jan 2017 11:17:07 +0100 Subject: [CMake] Visual Studio: force use of folders Message-ID: <46fe0e0a1448ce7eb6dc897491576839.squirrel@mail.ahans.de> Hi all, we have the following setup: Visual Studio 2013 Professional is installed, but for compatibility reasons we need to use the Visual Studio 2010 (vc100) compilers. To that end we have Visual Studio 2010 Express installed (to complicate things, we also need the Windows SDK 7.1 to get access to compilers that can produce 64-bit code). What we want is to use Visual Studio 2013 as IDE with the vc100 compilers. It is possible to create a Visual Studio 2010 solution with CMake and open and compile that with Visual Studio 2013. However, as CMake detects an Express Edition of the target platform, it disables generation of folders in the solution. However, folder support is one of the main reasons to use Visual Studio 2013 Professional instead of the 2010 Express Edition. Is there a way to force folder generation in that case? Looking at the source code of the corresponding generator, I don't see a way. By removing the check for IsExpressEdition() in cmGlobalVisualStudio8Generator::UseFolderProperty() and simply always returning cmGlobalGenerator::UseFolderProperty(), folders are generated also if an Express edition is detected. Obviously, that's not a nice solution, since now when actually using an Express Edition, many warnings need to be clicked away ... If this cannot be solved with some already existing option, I would like to implement the option to force folder generation. What would be the preferred way to do this? What comes to mind is implementing a new generator that inherits everything from the existing one and only overrides UseFolderProperty() method, or implementing an option for the existing one. How would one implement such an option? As additional space-separated parameter like the platform (e.g., Visual Studio 2010 Win64 force_folders)? Thanks! Alex From dflogeras2 at gmail.com Tue Jan 31 12:03:49 2017 From: dflogeras2 at gmail.com (Dave Flogeras) Date: Tue, 31 Jan 2017 13:03:49 -0400 Subject: [CMake] CMake 3.7.2 and parallel builds In-Reply-To: <48bd961f-3638-4226-2b4d-980e20634cae@gmail.com> References: <1485614599.3653.102.camel@mad-scientist.net> <48bd961f-3638-4226-2b4d-980e20634cae@gmail.com> Message-ID: On Mon, Jan 30, 2017 at 9:38 AM, Nils Gladitz wrote: > > I don't know how to do this with the generic dashboard targets ... > assuming no one else does either you could give CTest script mode a try > (ctest -S). > In script mode the ctest_build() command has a FLAGS option which takes > build tool specific options like -j. > > Nils > My lazy way out was to just switch to using the ninja generator for my test farm. It doesn't solve the real problem (if any), but it gets the results I wanted. Thanks for all the help anyway guys. Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From acrespodelavina at gmail.com Tue Jan 31 12:15:50 2017 From: acrespodelavina at gmail.com (Arturo Crespo) Date: Tue, 31 Jan 2017 17:15:50 +0000 Subject: [CMake] Green Hills MULTI generator CMAKE_ARCHIVE_OUTPUT_DIRECTORY has no effect Message-ID: Hello All, I'm trying to use the Green Hills MULTI generator with CMake 3,6,2 and I'm having some problems with static libraries. I'm creating several static libraries projects and I want the library to be created in a specific folder different from the build folder, so I tried to use CMAKE_ARCHIVE_OUTPUT_DIRECTORY as I was doing previously with NMake Makefiles JOM generator, but this variable has no effect and the created Multi project has the output path to the build folder. I tried to use other CMake variables and if I use CMAKE_RUNTIME_OUTPUT_DIRECTORY then I get the result that I want but it's not what the documentation explains. Did someone try something similar? Regards, Arturo -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidklind at gmail.com Tue Jan 31 16:57:56 2017 From: davidklind at gmail.com (David Lind) Date: Tue, 31 Jan 2017 14:57:56 -0700 Subject: [CMake] CCACHE_DIR Environment Variable In-Reply-To: References: <9365318C-BFD1-45B7-96AE-3A1542CD188B@gmail.com> <263BD9FE-940B-4864-8066-44BE11479FE1@gmail.com> Message-ID: The example shown on https://crascit.com/2016/04/09/using-ccache-with-cmake/ is for Xcode. Hence setting the CMAKE_XCODE_ATTRIBUTE? variables. On Linux, what are these variables? Are they CMAKE_ATTRIBUTE? without XCODE? > On Jan 19, 2017, at 2:11 PM, Craig Scott wrote: > > Ah, sorry, I misunderstood what CCACHE_DIR was for. Nevertheless, the method in that linked article could be easily modified to do what you want. Simply add the setting of the environment variable to the launch scripts. Since those launch scripts are copied across to the build dir at configure time and they support variable substitutions, you can even have the value of CCACHE_DIR be settable from CMake if you want. For example, your launch-c.in file could look like this: > > #!/bin/sh > export CCACHE_CPP2=true > export CCACHE_DIR=${CCACHE_DIR} > exec "${RULE_LAUNCH_COMPILE}" "${CMAKE_C_COMPILER}" "$@" > When you run CMake, it substitutes the value of each of the above variables as they are set when the configure_file() command is called. Therefore, the configure step bakes in the value of CCACHE_DIR and it won't need to be set in your environment when you do the build step. Note that the substitutions are substituting CMake variables, not environment variables, so if you wanted to pass through a CCACHE_DIR environment variable instead, you would do something like this: > > #!/bin/sh > export CCACHE_CPP2=true > export CCACHE_DIR=$ENV{CCACHE_DIR} > exec "${RULE_LAUNCH_COMPILE}" "${CMAKE_C_COMPILER}" "$@" > Probably better to do that in your CMakeLists.txt instead though and leave the launch-c.in script as in the first case above. This would mean your CMakeLists.txt would have a line like this somewhere: > > set(CCACHE_DIR $ENV{CCACHE_DIR}). > > Note, however, that relying on environment variables for configure or build steps is not so robust. If, for example, you change a CMakeLists.txt file or something else in your project requires CMake to be re-run, then CMake can re-run as part of a build. This then means the environment variables have to be the same between your CMake runs and your build runs. That's normally not a problem for most people, but thought I'd mention it just in case. Personally, I try to avoid relying on environment variables and instead have such values passed in as CMake cache variables like so: > > cmake -G Ninja -DCCACHE_DIR=${CCACHE_DIR} ../src > > This saves the value in the cache and then it is preserved regardless of what environment I have when I do subsequent build steps. > > > > > On Fri, Jan 20, 2017 at 7:44 AM, David Lind > wrote: > Scott, > > I have find_program implemented to find ccache, as shown below. > > find_program(CCACHE ccache) > if(CCACHE) > set_property(GLOBAL PROPERTY RULE_LAUNCH_COMPILE ${CCACHE}) > set_property(GLOBAL PROPERTY RULE_LAUNCH_LINK ${CCACHE}) > endif() > > That?s not the issue. The issue is telling ccache where to place it?s cache files. If I compiles for toolchain X, Y and X, I need to set CCACHE_DIR accordingly. Otherwise the cache will be useless. > > ?Dave > >> On Jan 19, 2017, at 12:57 PM, Craig Scott > wrote: >> >> Rather than relying on environment variables, you can use CMake's find_program() command to find ccache on your path and then tell CMake to use that as a launcher. You can find an article with a detailed explanation of how to set this up here: >> >> https://crascit.com/2016/04/09/using-ccache-with-cmake/ >> >> An advantage of this approach is that the build will work with or without ccache installed. We've been using this in production for some time now and it works very smoothly. The technique can probably also be extended to support Windows too with clcache , but I haven't tried that yet. >> >> >> On Fri, Jan 20, 2017 at 5:00 AM, David Lind > wrote: >> I am porting existing makefiles to cmake. One of the key features of these makefiles is setting the CCACHE_DIR environment variable based upon the tool chain selected. >> >> I have TC_.cmake files created. Ideally, I would add a line to these files to set the CCACHE_DIR. But, CMake doesn?t have the ability to set environment variables during the build step. So, I?m stuck. >> >> Has anyone encountered this kind of situation? >> >> ?Dave >> -- >> >> 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 >> >> >> -- >> Craig Scott >> Melbourne, Australia >> https://crascit.com > > > > > -- > Craig Scott > Melbourne, Australia > https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Tue Jan 31 17:34:58 2017 From: craig.scott at crascit.com (Craig Scott) Date: Wed, 1 Feb 2017 09:34:58 +1100 Subject: [CMake] CCACHE_DIR Environment Variable In-Reply-To: References: <9365318C-BFD1-45B7-96AE-3A1542CD188B@gmail.com> <263BD9FE-940B-4864-8066-44BE11479FE1@gmail.com> Message-ID: On Wed, Feb 1, 2017 at 8:57 AM, David Lind wrote: > The example shown on https://crascit.com/2016/ > 04/09/using-ccache-with-cmake/ is for Xcode. Hence setting the > CMAKE_XCODE_ATTRIBUTE? variables. On Linux, what are these variables? Are > they CMAKE_ATTRIBUTE? without XCODE? > That example is not just for Xcode, it works for Linux too. The CMAKE_XCODE_ATTRIBUTE_... stuff is specific to Xcode, it provides a way to set arbitrary project variables in the Xcode project file that CMake generates. Other generators don't need/support such a mechanism. In that article, the Xcode attributes are used to override the way the compiler and linker are invoked. On Linux, CMake already supports the RULE_LAUNCH_COMPILE and _COMPILER_LAUNCHER properties for use with Ninja or Makefiles to achieve this for you. It's not clear why you are looking for a Linux equivalent of the Xcode attributes. If you need to set CCACHE_DIR as an environment variable, then my previous email shows how to embed that in the launcher script, which will work for both Xcode and Linux (since the same launcher script is ultimately being invoked for both cases). All that said, I've never needed to set CCACHE_DIR and I mix OSX and iOS builds on the same machine. As has already been mentioned by someone else, ccache is smart enough to recognise the two builds as different because the command lines will be different, hence you don't get an iOS object file for a OSX build, for example. > > On Jan 19, 2017, at 2:11 PM, Craig Scott wrote: > > Ah, sorry, I misunderstood what CCACHE_DIR was for. Nevertheless, the > method in that linked article could be easily modified to do what you want. > Simply add the setting of the environment variable to the launch scripts. > Since those launch scripts are copied across to the build dir at configure > time and they support variable substitutions, you can even have the value > of CCACHE_DIR be settable from CMake if you want. For example, your > launch-c.in file could look like this: > > #!/bin/sh > export CCACHE_CPP2=true > export CCACHE_DIR=${CCACHE_DIR} > exec "${RULE_LAUNCH_COMPILE}" "${CMAKE_C_COMPILER}" "$@" > When you run CMake, it substitutes the value of each of the above > variables as they are set when the configure_file() command is called. > Therefore, the configure step bakes in the value of CCACHE_DIR and it won't > need to be set in your environment when you do the build step. Note that > the substitutions are substituting CMake variables, not environment > variables, so if you wanted to pass through a CCACHE_DIR environment > variable instead, you would do something like this: > > #!/bin/sh > export CCACHE_CPP2=true > export CCACHE_DIR=$*ENV*{CCACHE_DIR} > exec "${RULE_LAUNCH_COMPILE}" "${CMAKE_C_COMPILER}" "$@" > Probably better to do that in your CMakeLists.txt instead though and leave > the launch-c.in script as in the first case above. This would mean your > CMakeLists.txt would have a line like this somewhere: > > set(CCACHE_DIR $ENV{CCACHE_DIR}). > > Note, however, that relying on environment variables for configure or > build steps is not so robust. If, for example, you change a CMakeLists.txt > file or something else in your project requires CMake to be re-run, then > CMake can re-run as part of a build. This then means the environment > variables have to be the same between your CMake runs and your build runs. > That's normally not a problem for most people, but thought I'd mention it > just in case. Personally, I try to avoid relying on environment variables > and instead have such values passed in as CMake cache variables like so: > > cmake -G Ninja -DCCACHE_DIR=${CCACHE_DIR} ../src > > This saves the value in the cache and then it is preserved regardless of > what environment I have when I do subsequent build steps. > > > > > On Fri, Jan 20, 2017 at 7:44 AM, David Lind wrote: > >> Scott, >> >> I have find_program implemented to find ccache, as shown below. >> >> find_program(CCACHE ccache) >> if(CCACHE) >> set_property(GLOBAL PROPERTY RULE_LAUNCH_COMPILE ${CCACHE}) >> set_property(GLOBAL PROPERTY RULE_LAUNCH_LINK ${CCACHE}) >> endif() >> >> That?s not the issue. The issue is telling ccache where to place it?s >> cache files. If I compiles for toolchain X, Y and X, I need to set >> CCACHE_DIR accordingly. Otherwise the cache will be useless. >> >> ?Dave >> >> On Jan 19, 2017, at 12:57 PM, Craig Scott >> wrote: >> >> Rather than relying on environment variables, you can use CMake's >> find_program() command to find ccache on your path and then tell CMake to >> use that as a launcher. You can find an article with a detailed explanation >> of how to set this up here: >> >> https://crascit.com/2016/04/09/using-ccache-with-cmake/ >> >> An advantage of this approach is that the build will work with or without >> ccache installed. We've been using this in production for some time now and >> it works very smoothly. The technique can probably also be extended to >> support Windows too with clcache , >> but I haven't tried that yet. >> >> >> On Fri, Jan 20, 2017 at 5:00 AM, David Lind wrote: >> >>> I am porting existing makefiles to cmake. One of the key features of >>> these makefiles is setting the CCACHE_DIR environment variable based upon >>> the tool chain selected. >>> >>> I have TC_.cmake files created. Ideally, I would add a line >>> to these files to set the CCACHE_DIR. But, CMake doesn?t have the ability >>> to set environment variables during the build step. So, I?m stuck. >>> >>> Has anyone encountered this kind of situation? >>> >>> ?Dave >>> -- >>> >>> 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 >> >> >> >> >> -- >> Craig Scott >> Melbourne, Australia >> https://crascit.com >> >> >> > > > -- > Craig Scott > Melbourne, Australia > https://crascit.com > > > -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From joerg.krause at embedded.rocks Tue Jan 31 18:32:41 2017 From: joerg.krause at embedded.rocks (=?ISO-8859-1?Q?J=F6rg?= Krause) Date: Wed, 01 Feb 2017 00:32:41 +0100 Subject: [CMake] Cross-compilation issue with CHECK_SYMBOL_EXISTS Message-ID: <1485905561.4310.2.camel@embedded.rocks> Hi, I have an issue using CMake for cross-compiling bctoolbox on a Debian 64-bit host system as a 32-bit target. The issue is in how the linker works when using CHECK_SYMBOL_EXISTS. bctoolbox uses its own module FindMbedTLS.cmake to check for the symbol `mbedtls_ssl_init`: """ find_path(MBEDTLS_INCLUDE_DIRS NAMES mbedtls/ssl.h PATH_SUFFIXES include) find_library(MBEDTLS_LIBRARY NAMES mbedtls) find_library(MBEDX509_LIBRARY NAMES mbedx509) find_library(MBEDCRYPTO_LIBRARY NAMES mbedcrypto) if(MBEDTLS_LIBRARY AND MBEDX509_LIBRARY AND MBEDCRYPTO_LIBRARY) cmake_push_check_state(RESET) set(CMAKE_REQUIRED_INCLUDES ${MBEDTLS_INCLUDE_DIRS}) set(CMAKE_REQUIRED_LIBRARIES ${MBEDTLS_LIBRARY} ${MBEDX509_LIBRARY} ${MBEDCRYPTO_LIBRARY}) check_symbol_exists(mbedtls_ssl_init "mbedtls/ssl.h" MBEDTLS_V2) cmake_pop_check_state() endif() """ The check fails because the linker tries to link with the host zlib: """ /home/test/autobuild/run/instance-2/output/host/usr/bin/i586-linux- gcc??--sysroot=/home/test/autobuild/run/instance- 2/output/host/usr/i586-buildroot-linux-musl/sysroot -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os???- DNDEBUG????CMakeFiles/cmTC_4cdd8.dir/CheckSymbolExists.c.o??-o cmTC_4cdd8 -Wl,-rpath,/usr/lib32 -rdynamic /home/test/autobuild/run/instance-2/output/host/usr/i586-buildroot- linux-musl/sysroot/usr/lib32/libmbedtls.so /home/test/autobuild/run/instance-2/output/host/usr/i586-buildroot- linux-musl/sysroot/usr/lib32/libmbedx509.so /home/test/autobuild/run/instance-2/output/host/usr/i586-buildroot- linux-musl/sysroot/usr/lib32/libmbedcrypto.so? /home/test/autobuild/run/instance-2/output/host/opt/ext- toolchain/bin/../lib/gcc/i586-buildroot-linux- musl/5.4.0/../../../../i586-buildroot-linux-musl/bin/ld: warning: libc.so.6, needed by /usr/lib32/libz.so.1, not found (try using -rpath or -rpath-link) /usr/lib32/libz.so.1: undefined reference to `strcpy at GLIBC_2.0' /usr/lib32/libz.so.1: undefined reference to `free at GLIBC_2.0' """ As you can see, the linker uses `-Wl,-rpath,/usr/lib32` which should not be used when cross-compiling. I had no success in using any CMAKE symbol to get rid of this linker flag. The toolchain file: """ # # Automatically generated file; DO NOT EDIT. # CMake toolchain file for Buildroot # # In order to allow the toolchain to be relocated, we calculate the # HOST_DIR based on this file's location: $(HOST_DIR)/usr/share/buildroot # and store it in RELOCATED_HOST_DIR. # All the other variables that need to refer to HOST_DIR will use the # RELOCATED_HOST_DIR variable. string(REPLACE "/usr/share/buildroot" "" RELOCATED_HOST_DIR ${CMAKE_CURRENT_LIST_DIR}) set(CMAKE_SYSTEM_NAME Linux) set(CMAKE_SYSTEM_PROCESSOR i586) set(CMAKE_C_FLAGS_DEBUG "" CACHE STRING "Debug CFLAGS") set(CMAKE_CXX_FLAGS_DEBUG "" CACHE STRING "Debug CXXFLAGS") set(CMAKE_C_FLAGS_RELEASE " -DNDEBUG" CACHE STRING "Release CFLAGS") set(CMAKE_CXX_FLAGS_RELEASE " -DNDEBUG" CACHE STRING "Release CXXFLAGS") # Build type from the Buildroot configuration set(CMAKE_BUILD_TYPE Release CACHE STRING "Buildroot build configuration") # Buildroot defaults flags. set(CMAKE_C_FLAGS "-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os" CACHE STRING "Buildroot CFLAGS") set(CMAKE_CXX_FLAGS "-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os" CACHE STRING "Buildroot CXXFLAGS") set(CMAKE_EXE_LINKER_FLAGS "" CACHE STRING "Buildroot LDFLAGS for executables") set(CMAKE_INSTALL_SO_NO_EXE 0) set(CMAKE_PROGRAM_PATH "${RELOCATED_HOST_DIR}/usr/bin") set(CMAKE_SYSROOT "${RELOCATED_HOST_DIR}/usr/i586-buildroot-linux- musl/sysroot") set(CMAKE_FIND_ROOT_PATH "${RELOCATED_HOST_DIR}/usr/i586-buildroot- linux-musl/sysroot") set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY) set(ENV{PKG_CONFIG_SYSROOT_DIR} "${RELOCATED_HOST_DIR}/usr/i586- buildroot-linux-musl/sysroot") # This toolchain file can be used both inside and outside Buildroot. set(CMAKE_C_COMPILER "${RELOCATED_HOST_DIR}/usr/bin/i586-linux-gcc") set(CMAKE_CXX_COMPILER "${RELOCATED_HOST_DIR}/usr/bin/i586-linux-g++") """ Any idea how to fix the linking issue? Best regards, J?rg Krause From harrison37 at llnl.gov Tue Jan 31 18:33:13 2017 From: harrison37 at llnl.gov (Harrison, Cyrus D.) Date: Tue, 31 Jan 2017 23:33:13 +0000 Subject: [CMake] Issue with Python Libs in CMake 3.4 and Beyond on Linux Message-ID: <82E5C8B1-2A08-45F3-9190-6B6AFFA46443@llnl.gov> Hi Everyone, Consistent with the docs here: https://cmake.org/cmake/help/v3.7/module/FindPythonLibs.html We want to seed which python libs we want to look for by calling find_package(PythonInterp), which sets the PYTHON_LIBRARY path, before calling find_package(PythonLibs) Starting with CMake 3.4, this started failing for us on a few linux platforms. Here is the problem: get_filename_component inside of FindPythonLibs.cmake fails b/c PYTHON_LIBRARY contains two entires: The python lib (libpython2.7.so) and a symlink to it (libpython2.7.so.1.0) get_filename_component expects a single entry. This error propagates and halts the configure. Things works for us with CMake 3.3, started seeing this issue with 3.4. Below is a patch that avoids the issue, but not sure if it?s the ideal solution. If PYTHON_LIBRARY is really supposed to be a single path, there could be other CMake logic undermined by the fact PythonInterp produces a list in some cases. ==== diff -c cmake-3.7.2/Modules/FindPythonLibs.cmake cmake-3.7.2-patch/Modules/FindPythonLibs.cmake *** cmake-3.7.2/Modules/FindPythonLibs.cmake 2017-01-13 06:05:41.000000000 -0800 --- cmake-3.7.2-patch/Modules/FindPythonLibs.cmake 2017-01-31 14:28:21.000000000 -0800 *************** *** 168,174 **** # Use the library's install prefix as a hint set(_Python_INCLUDE_PATH_HINT) ! get_filename_component(_Python_PREFIX ${PYTHON_LIBRARY} PATH) get_filename_component(_Python_PREFIX ${_Python_PREFIX} PATH) if(_Python_PREFIX) set(_Python_INCLUDE_PATH_HINT ${_Python_PREFIX}/include) --- 168,181 ---- # Use the library's install prefix as a hint set(_Python_INCLUDE_PATH_HINT) ! # get_filename_component(_Python_PREFIX ${PYTHON_LIBRARY} PATH) ! # the above fails when find_package(PythonInterp) returns a list with ! # both the python lib and a symlink to it. ! # ! # prevent this case by only using the first item in ${PYTHON_LIBRARY} ! # as input to get_filename_component ! list(GET ${PYTHON_LIBRARY} 0 FIRST_FOUND_PYTHON_LIBRARY) ! get_filename_component(_Python_PREFIX ${FIRST_FOUND_PYTHON_LIBRARY} PATH) get_filename_component(_Python_PREFIX ${_Python_PREFIX} PATH) if(_Python_PREFIX) set(_Python_INCLUDE_PATH_HINT ${_Python_PREFIX}/include) ==== -Cyrus From florent.castelli at gmail.com Tue Jan 31 18:49:37 2017 From: florent.castelli at gmail.com (Florent Castelli) Date: Wed, 1 Feb 2017 00:49:37 +0100 Subject: [CMake] CCACHE_DIR Environment Variable In-Reply-To: References: <9365318C-BFD1-45B7-96AE-3A1542CD188B@gmail.com> <263BD9FE-940B-4864-8066-44BE11479FE1@gmail.com> Message-ID: <819107cb-7d5f-30fd-7015-f85982ec22fa@gmail.com> On 31/01/2017 23:34, Craig Scott wrote: > > If you need to set CCACHE_DIR as an environment variable, then my > previous email shows how to embed that in the launcher script, which > will work for both Xcode and Linux (since the same launcher script is > ultimately being invoked for both cases). All that said, I've never > needed to set CCACHE_DIR and I mix OSX and iOS builds on the same > machine. As has already been mentioned by someone else, ccache is > smart enough to recognise the two builds as different because the > command lines will be different, hence you don't get an iOS object > file for a OSX build, for example. > To that, I will add that ccache is certainly smart enough to save both iOS, macOS or Android builds in the same cache, but you need to be careful and maybe set higher limits for the cache size folder as the default one might not be suitable for your usage. See the documentation on how to set it higher. /Florent -------------- next part -------------- An HTML attachment was scrubbed... URL: