From pfultz2 at yahoo.com Sat Jul 1 09:47:55 2017 From: pfultz2 at yahoo.com (P F) Date: Sat, 1 Jul 2017 08:47:55 -0500 Subject: [CMake] find_package(), FindXXX.cmake and IMPORTED add_library() In-Reply-To: References: Message-ID: > On Jun 30, 2017, at 6:40 AM, Louis-Paul CORDIER wrote: > > Hi, > > I'm particularly familiar with find_package() command, add_library(... IMPORTED) and find_library(). However, I found there are many differences on find_package() usage depending of the library being imported. > > For instance, using find_package() on Qt5 will retrieve a bunch of *Config.cmake files in the Qt installation tree, and add each components as a library using add_library(Qt5::COMPONENT SHARED IMPORTED). > One nice feature with that is the possibility to retrieve the LOCATION property on each component to get the DLL file. > > That said when using find_package(sharedLibFOO) that will make use of hand-written FindsharedLibFOO.cmake, some variables like FindsharedLib_FOUND, FindsharedLib_LIBRARIES, FindsharedLib_VERSION (etc.) are set by the script, but there is almost never add_library() command used inside this CMake find script. > > 1. Should it be mandatory to use add_library() in FindXXX.cmake scripts, so the user just needs to target_link_libraries() and all compile definitions, includes dir, and lib dir are automatically imported? This probably should be the case, but I think a lack of contributions is the problem with the current Find modules not being update on each module. > 2. If not, is it a good practice to use add_library() when writing our FindXXX.cmake package? When writing your own FindXXX.cmake, you should first report a bug to library XXX for not supporting cmake downstream. Also, the purpose of `find_package` is to find prebuilt binaries, its not to add new libraries to be built. > 3. When making an application, is it a good practice to create an imported target for each library, instead of appending manually to the current project using target_link_libraries(), target_compile_definitions(), target_include_directories() and so on? Yes, it is good practice to make your dependencies imported targets as it allows for the dependencies to be relocatable. Here is some more information about cmake packages: https://cmake.org/cmake/help/v3.7/manual/cmake-packages.7.html From elfring at users.sourceforge.net Sat Jul 1 13:33:41 2017 From: elfring at users.sourceforge.net (SF Markus Elfring) Date: Sat, 1 Jul 2017 19:33:41 +0200 Subject: [CMake] Enhanced version management for the command "project" In-Reply-To: <55E5640C.7060401@users.sourceforge.net> References: <55E5640C.7060401@users.sourceforge.net> Message-ID: Hello, CMake provides an interface for the specification of version information by the command "project". https://cmake.org/cmake/help/v3.9/command/project.html Can it be extended a bit more? 1. How do you think about to preserve a software release tag there? 2. Software packages can often evolve and deviate from the specified version numbers after the moment they were copied to an useful location. Would you like to distinguish the extensions to a base version by any additional data (like a commit hash or revision identifier) from a content management system? Regards, Markus From elfring at users.sourceforge.net Sat Jul 1 14:20:24 2017 From: elfring at users.sourceforge.net (SF Markus Elfring) Date: Sat, 1 Jul 2017 20:20:24 +0200 Subject: [CMake] Consistent software dependencies (together with add_subdirectory()?) for shared components Message-ID: <52e19299-cec0-fb9f-0f30-972e83dd4e74@users.sourceforge.net> Hello, CMake provides an interface for the addition of subdirectories. https://cmake.org/cmake/help/v3.9/command/add_subdirectory.html I find it interesting to clarify details which are not described there so far. * How much does this item influence the capability to construct a consistent dependency graph for the generated build system also around shared software components in several folders? * Can it mean a barrier for advanced data exchange with build configuration information between shared components? Regards, Markus From d3ck0r at gmail.com Sat Jul 1 22:31:47 2017 From: d3ck0r at gmail.com (J Decker) Date: Sat, 1 Jul 2017 19:31:47 -0700 Subject: [CMake] CmakeLists chain cannot find source added with add_custom_command In-Reply-To: References: Message-ID: Known issue? Or just doesn't require a response? On Wed, Jun 28, 2017 at 6:05 AM, J Decker wrote: > I have this chain of makefiles. It adds a custom rule to build a source > file, and then a subdirectory cannot reference that file. > > The first is added custom rule for M:/tmp/cmake-chain/sub/src/sack.c > and then later cannot find M:/tmp/cmake-chain/sub/src/sack.c > though it's really referencing it as M:/tmp/cmake-chain/sub/ > sub2/../src/sack.c > > tested with 3.6.0-rc4 and 3.9.0-rc5 > > if the add_custom_rule and add_executable are in the same makefile even if > there's a added path to make it not exactly the same source as the > 'referencing source' message logs; it works. > > > --- CMakeLists.txt --- > cmake_minimum_required(VERSION 2.8) > > message( "Adding custom rule for ${CMAKE_CURRENT_SOURCE_DIR}/src/sack.c" ) > add_custom_command( OUTPUT ${CMAKE_CURRENT_SOURCE_DIR}/src/sack.c > COMMAND cmake -E echo do something to make src/sack.c > ) > add_subdirectory( sub2 ) > ------------------------------------- > > --- sub2/CmakeLists.txt --- > message( "referencing source ${CMAKE_CURRENT_SOURCE_DIR}/../src/sack.c" ) > add_executable( something ${CMAKE_CURRENT_SOURCE_DIR}/../src/sack.c ) > > ------------------------------------- > > --- Truncated output log ------ > Adding custom rule for M:/tmp/cmake-chain/sub/src/sack.c > referencing source M:/tmp/cmake-chain/sub/sub2/../src/sack.c > -- Configuring done > CMake Error at sub2/CMakeLists.txt:3 (add_executable): > Cannot find source file: > > M:/tmp/cmake-chain/sub/src/sack.c > > Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp > .hxx .in .txx > -------------------------------------- > > > ------ Flat CmakeLists.txt which works --------------- > cmake_minimum_required(VERSION 2.8) > > message( "Adding custom rule for ${CMAKE_CURRENT_SOURCE_DIR}/src/sack.c" ) > add_custom_command( OUTPUT ${CMAKE_CURRENT_SOURCE_DIR}/src/sack.c > COMMAND cmake -e echo make file. > ) > > message( "referencing source ${CMAKE_CURRENT_SOURCE_DIR}/src/sack.c" ) > add_executable( something ${CMAKE_CURRENT_SOURCE_DIR}/sub2/../src/sack.c ) > -------------------------------------- > > ----- flat cmakelists output.... ----------- > Adding custom rule for M:/tmp/cmake-chain-flat/src/sack.c > referencing source M:/tmp/cmake-chain-flat/sub2/../src/sack.c > -- Configuring done > -------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.noulard at gmail.com Sun Jul 2 03:11:06 2017 From: eric.noulard at gmail.com (Eric Noulard) Date: Sun, 2 Jul 2017 09:11:06 +0200 Subject: [CMake] CmakeLists chain cannot find source added with add_custom_command In-Reply-To: References: Message-ID: Is the referred file created? Does your actual command creating the file doing it in the source tree and not in the build tree? Are you building in-source or out of source? Could you give us us a toy example which shows the issue? Le 2 juil. 2017 04:32, "J Decker" a ?crit : Known issue? Or just doesn't require a response? On Wed, Jun 28, 2017 at 6:05 AM, J Decker wrote: > I have this chain of makefiles. It adds a custom rule to build a source > file, and then a subdirectory cannot reference that file. > > The first is added custom rule for M:/tmp/cmake-chain/sub/src/sack.c > and then later cannot find M:/tmp/cmake-chain/sub/src/sack.c > though it's really referencing it as M:/tmp/cmake-chain/sub/sub2 > /../src/sack.c > > tested with 3.6.0-rc4 and 3.9.0-rc5 > > if the add_custom_rule and add_executable are in the same makefile even if > there's a added path to make it not exactly the same source as the > 'referencing source' message logs; it works. > > > --- CMakeLists.txt --- > cmake_minimum_required(VERSION 2.8) > > message( "Adding custom rule for ${CMAKE_CURRENT_SOURCE_DIR}/src/sack.c" ) > add_custom_command( OUTPUT ${CMAKE_CURRENT_SOURCE_DIR}/src/sack.c > COMMAND cmake -E echo do something to make src/sack.c > ) > add_subdirectory( sub2 ) > ------------------------------------- > > --- sub2/CmakeLists.txt --- > message( "referencing source ${CMAKE_CURRENT_SOURCE_DIR}/../src/sack.c" ) > add_executable( something ${CMAKE_CURRENT_SOURCE_DIR}/../src/sack.c ) > > ------------------------------------- > > --- Truncated output log ------ > Adding custom rule for M:/tmp/cmake-chain/sub/src/sack.c > referencing source M:/tmp/cmake-chain/sub/sub2/../src/sack.c > -- Configuring done > CMake Error at sub2/CMakeLists.txt:3 (add_executable): > Cannot find source file: > > M:/tmp/cmake-chain/sub/src/sack.c > > Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp > .hxx .in .txx > -------------------------------------- > > > ------ Flat CmakeLists.txt which works --------------- > cmake_minimum_required(VERSION 2.8) > > message( "Adding custom rule for ${CMAKE_CURRENT_SOURCE_DIR}/src/sack.c" ) > add_custom_command( OUTPUT ${CMAKE_CURRENT_SOURCE_DIR}/src/sack.c > COMMAND cmake -e echo make file. > ) > > message( "referencing source ${CMAKE_CURRENT_SOURCE_DIR}/src/sack.c" ) > add_executable( something ${CMAKE_CURRENT_SOURCE_DIR}/sub2/../src/sack.c ) > -------------------------------------- > > ----- flat cmakelists output.... ----------- > Adding custom rule for M:/tmp/cmake-chain-flat/src/sack.c > referencing source M:/tmp/cmake-chain-flat/sub2/../src/sack.c > -- Configuring done > -------------------------------------- > > -- 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 eric.noulard at gmail.com Sun Jul 2 03:12:33 2017 From: eric.noulard at gmail.com (Eric Noulard) Date: Sun, 2 Jul 2017 09:12:33 +0200 Subject: [CMake] CmakeLists chain cannot find source added with add_custom_command In-Reply-To: References: Message-ID: Needless to say that your example should work but somehow CMake does not see that the referred file is GENERATED. Le 2 juil. 2017 09:11, "Eric Noulard" a ?crit : > Is the referred file created? > Does your actual command creating the file doing it in the source tree and > not in the build tree? > Are you building in-source or out of source? > > Could you give us us a toy example which shows the issue? > > Le 2 juil. 2017 04:32, "J Decker" a ?crit : > > Known issue? Or just doesn't require a response? > > On Wed, Jun 28, 2017 at 6:05 AM, J Decker wrote: > >> I have this chain of makefiles. It adds a custom rule to build a source >> file, and then a subdirectory cannot reference that file. >> >> The first is added custom rule for M:/tmp/cmake-chain/sub/src/sack.c >> and then later cannot find M:/tmp/cmake-chain/sub/src/sack.c >> though it's really referencing it as M:/tmp/cmake-chain/sub/sub2 >> /../src/sack.c >> >> tested with 3.6.0-rc4 and 3.9.0-rc5 >> >> if the add_custom_rule and add_executable are in the same makefile even >> if there's a added path to make it not exactly the same source as the >> 'referencing source' message logs; it works. >> >> >> --- CMakeLists.txt --- >> cmake_minimum_required(VERSION 2.8) >> >> message( "Adding custom rule for ${CMAKE_CURRENT_SOURCE_DIR}/src/sack.c" >> ) >> add_custom_command( OUTPUT ${CMAKE_CURRENT_SOURCE_DIR}/src/sack.c >> COMMAND cmake -E echo do something to make src/sack.c >> ) >> add_subdirectory( sub2 ) >> ------------------------------------- >> >> --- sub2/CmakeLists.txt --- >> message( "referencing source ${CMAKE_CURRENT_SOURCE_DIR}/../src/sack.c" ) >> add_executable( something ${CMAKE_CURRENT_SOURCE_DIR}/../src/sack.c ) >> >> ------------------------------------- >> >> --- Truncated output log ------ >> Adding custom rule for M:/tmp/cmake-chain/sub/src/sack.c >> referencing source M:/tmp/cmake-chain/sub/sub2/../src/sack.c >> -- Configuring done >> CMake Error at sub2/CMakeLists.txt:3 (add_executable): >> Cannot find source file: >> >> M:/tmp/cmake-chain/sub/src/sack.c >> >> Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp >> .hxx .in .txx >> -------------------------------------- >> >> >> ------ Flat CmakeLists.txt which works --------------- >> cmake_minimum_required(VERSION 2.8) >> >> message( "Adding custom rule for ${CMAKE_CURRENT_SOURCE_DIR}/src/sack.c" >> ) >> add_custom_command( OUTPUT ${CMAKE_CURRENT_SOURCE_DIR}/src/sack.c >> COMMAND cmake -e echo make file. >> ) >> >> message( "referencing source ${CMAKE_CURRENT_SOURCE_DIR}/src/sack.c" ) >> add_executable( something ${CMAKE_CURRENT_SOURCE_DIR}/sub2/../src/sack.c >> ) >> -------------------------------------- >> >> ----- flat cmakelists output.... ----------- >> Adding custom rule for M:/tmp/cmake-chain-flat/src/sack.c >> referencing source M:/tmp/cmake-chain-flat/sub2/../src/sack.c >> -- Configuring done >> -------------------------------------- >> >> > > -- > > 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 d3ck0r at gmail.com Sun Jul 2 04:20:57 2017 From: d3ck0r at gmail.com (J Decker) Date: Sun, 2 Jul 2017 01:20:57 -0700 Subject: [CMake] CmakeLists chain cannot find source added with add_custom_command In-Reply-To: References: Message-ID: It is not generated; because it is generated during a the build phase not the generate phase. So only the logical idea of the file exists. On Sun, Jul 2, 2017 at 12:12 AM, Eric Noulard wrote: > Needless to say that your example should work but somehow CMake does not > see that the referred file is GENERATED. > > Le 2 juil. 2017 09:11, "Eric Noulard" a ?crit : > >> Is the referred file created? >> Does your actual command creating the file doing it in the source tree >> and not in the build tree? >> Are you building in-source or out of source? >> >> Could you give us us a toy example which shows the issue? >> >> Le 2 juil. 2017 04:32, "J Decker" a ?crit : >> >> Known issue? Or just doesn't require a response? >> >> On Wed, Jun 28, 2017 at 6:05 AM, J Decker wrote: >> >>> I have this chain of makefiles. It adds a custom rule to build a source >>> file, and then a subdirectory cannot reference that file. >>> >>> The first is added custom rule for M:/tmp/cmake-chain/sub/src/sack.c >>> and then later cannot find M:/tmp/cmake-chain/sub/src/sack.c >>> though it's really referencing it as M:/tmp/cmake-chain/sub/sub2 >>> /../src/sack.c >>> >>> tested with 3.6.0-rc4 and 3.9.0-rc5 >>> >>> if the add_custom_rule and add_executable are in the same makefile even >>> if there's a added path to make it not exactly the same source as the >>> 'referencing source' message logs; it works. >>> >>> >>> --- CMakeLists.txt --- >>> cmake_minimum_required(VERSION 2.8) >>> >>> message( "Adding custom rule for ${CMAKE_CURRENT_SOURCE_DIR}/src/sack.c" >>> ) >>> add_custom_command( OUTPUT ${CMAKE_CURRENT_SOURCE_DIR}/src/sack.c >>> COMMAND cmake -E echo do something to make src/sack.c >>> ) >>> add_subdirectory( sub2 ) >>> ------------------------------------- >>> >>> --- sub2/CmakeLists.txt --- >>> message( "referencing source ${CMAKE_CURRENT_SOURCE_DIR}/../src/sack.c" >>> ) >>> add_executable( something ${CMAKE_CURRENT_SOURCE_DIR}/../src/sack.c ) >>> >>> ------------------------------------- >>> >>> --- Truncated output log ------ >>> Adding custom rule for M:/tmp/cmake-chain/sub/src/sack.c >>> referencing source M:/tmp/cmake-chain/sub/sub2/../src/sack.c >>> -- Configuring done >>> CMake Error at sub2/CMakeLists.txt:3 (add_executable): >>> Cannot find source file: >>> >>> M:/tmp/cmake-chain/sub/src/sack.c >>> >>> Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm >>> .hpp >>> .hxx .in .txx >>> -------------------------------------- >>> >>> >>> ------ Flat CmakeLists.txt which works --------------- >>> cmake_minimum_required(VERSION 2.8) >>> >>> message( "Adding custom rule for ${CMAKE_CURRENT_SOURCE_DIR}/src/sack.c" >>> ) >>> add_custom_command( OUTPUT ${CMAKE_CURRENT_SOURCE_DIR}/src/sack.c >>> COMMAND cmake -e echo make file. >>> ) >>> >>> message( "referencing source ${CMAKE_CURRENT_SOURCE_DIR}/src/sack.c" ) >>> add_executable( something ${CMAKE_CURRENT_SOURCE_DIR}/sub2/../src/sack.c >>> ) >>> -------------------------------------- >>> >>> ----- flat cmakelists output.... ----------- >>> Adding custom rule for M:/tmp/cmake-chain-flat/src/sack.c >>> referencing source M:/tmp/cmake-chain-flat/sub2/../src/sack.c >>> -- Configuring done >>> -------------------------------------- >>> >>> >> >> -- >> >> 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 eric.noulard at gmail.com Sun Jul 2 06:57:57 2017 From: eric.noulard at gmail.com (Eric Noulard) Date: Sun, 2 Jul 2017 12:57:57 +0200 Subject: [CMake] CmakeLists chain cannot find source added with add_custom_command In-Reply-To: References: Message-ID: Ok, I reproduced your issue and I can then confirm it. I tried several thing including: - generating the file is the buildtree - refering to the same file with another target in the same dir - using absolute path in the sub2/add_executable nothing works. it looks like a generated file cannot be referred outside the directory where the custom command generates it ??? Here comes an archive with an example similar to the one descrived by J. Decker. If you build it without option it wokrs (because I used an intermediate object lib) If you (try to) build it with cmake -DBROKEN=1 then it'll fails with "Cannot find source file..." This is definitely weird and I never encountered this after +10 years of CMake usage!! So I guess I have always used generated file locally to build exe or lib and then refer to the lib. If this is the intended behaviour then it should be documented more explicitely. Now re-reading the doc of add_custom_command: "This defines a command to generate specified ``OUTPUT`` file(s). A target created in the same directory (``CMakeLists.txt`` file) that specifies any output of the custom command as a source file is given a rule to generate the file using the command at build time." So the "same directory" should be underlined!! Or may be another sentence saying that in fact you CANNOT refer to outputed files outside the directory... In fact it is possible to have cross-directory reference to generated file but this is more like a workaround. You'll have to: define your custom_command and an associated custom target in dir1 define your exe/lib in dir2 and explicitely: - flag the referred cross-dir generated source as GENERATED - make your exe/lib depend on the cross-dir custom target in order to trigger the file generation. The second zip implement that workaround. This is nasty, I wouldn't do that. Shall we open a bug for this misleading behavior or shall we open a bug for doc update? 2017-07-02 10:20 GMT+02:00 J Decker : > It is not generated; because it is generated during a the build phase not > the generate phase. So only the logical idea of the file exists. > > On Sun, Jul 2, 2017 at 12:12 AM, Eric Noulard > wrote: > >> Needless to say that your example should work but somehow CMake does not >> see that the referred file is GENERATED. >> >> Le 2 juil. 2017 09:11, "Eric Noulard" a ?crit : >> >>> Is the referred file created? >>> Does your actual command creating the file doing it in the source tree >>> and not in the build tree? >>> Are you building in-source or out of source? >>> >>> Could you give us us a toy example which shows the issue? >>> >>> Le 2 juil. 2017 04:32, "J Decker" a ?crit : >>> >>> Known issue? Or just doesn't require a response? >>> >>> On Wed, Jun 28, 2017 at 6:05 AM, J Decker wrote: >>> >>>> I have this chain of makefiles. It adds a custom rule to build a >>>> source file, and then a subdirectory cannot reference that file. >>>> >>>> The first is added custom rule for M:/tmp/cmake-chain/sub/src/sack.c >>>> and then later cannot find M:/tmp/cmake-chain/sub/src/sack.c >>>> though it's really referencing it as M:/tmp/cmake-chain/sub/sub2 >>>> /../src/sack.c >>>> >>>> tested with 3.6.0-rc4 and 3.9.0-rc5 >>>> >>>> if the add_custom_rule and add_executable are in the same makefile even >>>> if there's a added path to make it not exactly the same source as the >>>> 'referencing source' message logs; it works. >>>> >>>> >>>> --- CMakeLists.txt --- >>>> cmake_minimum_required(VERSION 2.8) >>>> >>>> message( "Adding custom rule for ${CMAKE_CURRENT_SOURCE_DIR}/src/sack.c" >>>> ) >>>> add_custom_command( OUTPUT ${CMAKE_CURRENT_SOURCE_DIR}/src/sack.c >>>> COMMAND cmake -E echo do something to make src/sack.c >>>> ) >>>> add_subdirectory( sub2 ) >>>> ------------------------------------- >>>> >>>> --- sub2/CmakeLists.txt --- >>>> message( "referencing source ${CMAKE_CURRENT_SOURCE_DIR}/../src/sack.c" >>>> ) >>>> add_executable( something ${CMAKE_CURRENT_SOURCE_DIR}/../src/sack.c ) >>>> >>>> ------------------------------------- >>>> >>>> --- Truncated output log ------ >>>> Adding custom rule for M:/tmp/cmake-chain/sub/src/sack.c >>>> referencing source M:/tmp/cmake-chain/sub/sub2/../src/sack.c >>>> -- Configuring done >>>> CMake Error at sub2/CMakeLists.txt:3 (add_executable): >>>> Cannot find source file: >>>> >>>> M:/tmp/cmake-chain/sub/src/sack.c >>>> >>>> Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm >>>> .hpp >>>> .hxx .in .txx >>>> -------------------------------------- >>>> >>>> >>>> ------ Flat CmakeLists.txt which works --------------- >>>> cmake_minimum_required(VERSION 2.8) >>>> >>>> message( "Adding custom rule for ${CMAKE_CURRENT_SOURCE_DIR}/src/sack.c" >>>> ) >>>> add_custom_command( OUTPUT ${CMAKE_CURRENT_SOURCE_DIR}/src/sack.c >>>> COMMAND cmake -e echo make file. >>>> ) >>>> >>>> message( "referencing source ${CMAKE_CURRENT_SOURCE_DIR}/src/sack.c" ) >>>> add_executable( something ${CMAKE_CURRENT_SOURCE_DIR}/sub2/../src/sack.c >>>> ) >>>> -------------------------------------- >>>> >>>> ----- flat cmakelists output.... ----------- >>>> Adding custom rule for M:/tmp/cmake-chain-flat/src/sack.c >>>> referencing source M:/tmp/cmake-chain-flat/sub2/../src/sack.c >>>> -- Configuring done >>>> -------------------------------------- >>>> >>>> >>> >>> -- >>> >>> 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 > -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: GenFileReferredInSubdir.zip Type: application/zip Size: 1564 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: GenFileReferredInSubdir-v2.zip Type: application/zip Size: 1651 bytes Desc: not available URL: From lp.cordier at dynamixyz.com Mon Jul 3 04:33:33 2017 From: lp.cordier at dynamixyz.com (Louis-Paul CORDIER) Date: Mon, 3 Jul 2017 10:33:33 +0200 Subject: [CMake] find_package(), FindXXX.cmake and IMPORTED add_library() In-Reply-To: References: Message-ID: <73111d5e-a421-c05b-4642-1cac7acd00fe@dynamixyz.com> (My answers to your previous email are below this new question.) I have another question thus: some libraries, especially on Windows, provide both static and shared library. Is there any way for selecting which kind of library we want to get? For instance: LibJPEGTurbo has (turbojpeg.lib + turbojpeg.dll) and (turbojpeg-static.lib). So in the find_package, we can do 1. shared version add_library(LibJPEGTurbo SHARED IMPORTED) set_target_properties(LibJPEGTurbo PROPERTIES IMPORTED_IMPLIB "turbojpeg.lib") set_target_properties(LibJPEGTurbo PROPERTIES IMPORTED_LOCATION "turbojpeg.dll") 2. static version add_library(LibJPEGTurbo STATIC IMPORTED) set_target_properties(LibJPEGTurbo PROPERTIES IMPORTED_LOCATION "turbojpeg-static.lib") Maybe setting a variable before calling find_package, like set(FIND_SHAREDLIBS TRUE)? Le 01/07/2017 ? 15:47, P F a ?crit : >> On Jun 30, 2017, at 6:40 AM, Louis-Paul CORDIER wrote: >> >> Hi, >> >> I'm particularly familiar with find_package() command, add_library(... IMPORTED) and find_library(). However, I found there are many differences on find_package() usage depending of the library being imported. >> >> For instance, using find_package() on Qt5 will retrieve a bunch of *Config.cmake files in the Qt installation tree, and add each components as a library using add_library(Qt5::COMPONENT SHARED IMPORTED). >> One nice feature with that is the possibility to retrieve the LOCATION property on each component to get the DLL file. >> >> That said when using find_package(sharedLibFOO) that will make use of hand-written FindsharedLibFOO.cmake, some variables like FindsharedLib_FOUND, FindsharedLib_LIBRARIES, FindsharedLib_VERSION (etc.) are set by the script, but there is almost never add_library() command used inside this CMake find script. >> >> 1. Should it be mandatory to use add_library() in FindXXX.cmake scripts, so the user just needs to target_link_libraries() and all compile definitions, includes dir, and lib dir are automatically imported? > This probably should be the case, but I think a lack of contributions is the problem with the current Find modules not being update on each module. Thanks, this should be added to the documentation of FindPackage then so people can start getting good habits, shouldn't be? I guess of your answer that every find_package() should populate LOCATION_ properties. > >> 2. If not, is it a good practice to use add_library() when writing our FindXXX.cmake package? > When writing your own FindXXX.cmake, you should first report a bug to library XXX for not supporting cmake downstream. Also, the purpose of `find_package` is to find prebuilt binaries, its not to add new libraries to be built. Unfortunately, many people using CMake build system don't know how to write a proper CMakeLists.txt as there are plenty ways to workaround the exporting process of CMake. Also many project are not using CMake at all. When I mean the add_library command, I am talking about the IMPORTED function of it, meaning that the library is already built and shouldn't create a new target in the Makefile/IDE. >> 3. When making an application, is it a good practice to create an imported target for each library, instead of appending manually to the current project using target_link_libraries(), target_compile_definitions(), target_include_directories() and so on? > Yes, it is good practice to make your dependencies imported targets as it allows for the dependencies to be relocatable. > > Here is some more information about cmake packages: > > https://cmake.org/cmake/help/v3.7/manual/cmake-packages.7.html > > > From mike.jackson at bluequartz.net Mon Jul 3 22:07:35 2017 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Mon, 03 Jul 2017 22:07:35 -0400 Subject: [CMake] CMake Server Mode and USE_FOLDERS Message-ID: <595AF867.3090306@bluequartz.net> I was just exploring in a command line the CMake Server mode in 3.8 (I have not tried 3.9 yet) just to see what gets output and I was wondering if CMake-Server mode supports "set_property(GLOBAL PROPERTY USE_FOLDERS ON)" for any generator? I was specifically using the "ninja" generator for my experiments. I suspect not since Ninja itself does not have the concept of this but I though I would inquire. If IDE's that are now relying on CMake-server had this information it would allow the IDE to present the project in such a way that the developers intended or laid out. I know we put a lot of time into our CMake files so that the Visual Studio and Xcode projects are reasonably organized when you open them instead of just listing 250 targets. Thanks for any insights. Mike Jackson From lp.cordier at dynamixyz.com Tue Jul 4 04:19:55 2017 From: lp.cordier at dynamixyz.com (Louis-Paul CORDIER) Date: Tue, 4 Jul 2017 10:19:55 +0200 Subject: [CMake] DLL handling under CMake In-Reply-To: <590add90.925c1c0a.632e2.33a2@mx.google.com> References: <2114FB31-FF89-4461-8713-75FAA7179E4E@hendrik-sattler.de> <590add90.925c1c0a.632e2.33a2@mx.google.com> Message-ID: <612ed9d4-61ce-b3a2-2a39-887deeceb3b2@dynamixyz.com> Hi, Thank you very much for this code snippet. However I don't like the fixup_bundle function, as it takes the first dll that it found to be linked against. I also did a try with a dependency scanning function. It is quiet long to write, but I guess it is the cleanest way to handle DLL under Windows. Note: I still have an issue with this function. Indeed, if user uses Generator expressions for library dependencies, it will not work. e.g: add_library(Foo_lib IMPORTED GLOBAL) # ... set location properties target_link_libraries(${PROJECT_NAME} optimized $<$:Foo_lib>) Any idea for a workaround? What do you think about this CMake code? Also, I would see a real benefit to add a LINK_DEPENDENT_LIBRARIES property (inspired of IMPORTED_LINK_DEPENDENT_LIBRARIES) to each target that could be automatically filled by each target_link_libraries() calls. # This function scan all dependencies of a project recursively, and retrieve all shared # library associated with it. # Prerequisite: your upstream CMakeLists.txt must make use of add_library(foo SHARED IMPORTED GLOBAL), # and fill the following properties on the imported target: # set_target_properties(foo PROPERTIES IMPORTED_IMPLIB "path_to_foo.lib") # set_target_properties(foo PROPERTIES IMPORTED_LOCATION "path_to_foo.dll") # set_target_properties(foo PROPERTIES IMPORTED_LINK_DEPENDENT_LIBRARIES "path_to_dll_on_which_foo_depends.dll") # GLOBAL keyword is important as it allows downstream CMakeLists.txt to scan dependencies. # Input parameters: # dep_to_scan: your downstream project # config_to_scan: configuration to use for the scanning. # output_variable: variable in which the function stores the result. # Usage: # RECURSIVE_SCAN(my_app Release DLLS) # install(FILES ${DLLS} # DESTINATION release # CONFIGURATIONS Release) set(COUNT 0) function(RECURSIVE_SCAN dep_to_scan config_to_scan output_variable) MATH(EXPR COUNT "${COUNT}+1") string(RANDOM LENGTH ${COUNT} ALPHABET "-" SPACES) message("${SPACES} Scanning ${dep_to_scan}") if(NOT TARGET ${dep_to_scan}) MATH(EXPR COUNT "${COUNT}-1") #message("${dep_to_scan} Is not target") return() endif() get_target_property(_is_imported ${dep_to_scan} IMPORTED) if(_is_imported) # We need to check if the imported library rely on other shared libraries. get_target_property(_dependent_dll ${_lib} IMPORTED_LINK_DEPENDENT_LIBRARIES_${config_to_scan}) if(NOT _dependent_dll) get_target_property(_dependent_dll ${_lib} IMPORTED_LINK_DEPENDENT_LIBRARIES) endif() if(_dependent_dll) list(APPEND ${output_variable} ${_dependent_dll}) endif() #Otherwise, check if it is a shared library. (LOCATION variable can be # either .lib or DLL regarding of the type of library.) get_target_property(_TYPE ${dep_to_scan} TYPE) if(NOT _TYPE STREQUAL STATIC_LIBRARY) get_target_property(_dll_found ${dep_to_scan} LOCATION_${config_to_scan}) if(_dll_found) list(APPEND ${output_variable} ${_dll_found}) endif() endif() message("${SPACES}- DLL found: (${${output_variable}})") endif(_is_imported) get_target_property(_libraries ${dep_to_scan} INTERFACE_LINK_LIBRARIES) if(_libraries) foreach(_lib ${_libraries}) RECURSIVE_SCAN(${_lib} ${config_to_scan} ${output_variable}) endforeach() endif() # If we reach our first recursion, we need to clean the list of # DLL in order to remove duplicates. MATH(EXPR COUNT "${COUNT}-1") if(${COUNT} EQUAL 0) list(REMOVE_DUPLICATES ${output_variable}) endif() set(${output_variable} ${${output_variable}} PARENT_SCOPE) endfunction(RECURSIVE_SCAN) Best regards, Louis-Paul CORDIER Le 04/05/2017 ? 09:51, lectem at gmail.com a ?crit : > > I managed to get it working by using an intermediate script. > > One might want to generate the script instead of using the ? RUN_IT ? > variable trick. > > This was only tested on Windows, but seems to work fine. > > Put the following code in a xxxxxx.cmake file, include it from your > CMakeLists.txt and enjoy. > > # This is a helper script to run BundleUtilities fixup_bundle as postbuild > > # for a target. The primary use case is to copy .DLLs to the build > directory for > > # the Windows platform. It allows generator expressions to be used to > determine > > # the binary location > > # > > # Usage : run_fixup(TARGET LIBS DIRS) > > # - TARGET : A cmake target > > # - See fixup_bundle for LIBS and DIRS arguments > > if(RUN_IT) > > # Script ran by the add_custom_command > > include(BundleUtilities) > > fixup_bundle("${TO_FIXUP_FILE}" "${TO_FIXUP_LIBS}" "${TO_FIXUP_DIRS}") > > # End of script ran by the add_custom_command > > else() > > set(THIS_FILE ${CMAKE_CURRENT_LIST_FILE}) > > message(${THIS_FILE}) > > function(run_fixup _target _libs _dirs) > > message(${THIS_FILE}) > > add_custom_command( > > TARGET ${_target} POST_BUILD > > COMMAND ${CMAKE_COMMAND} > -DRUN_IT:BOOL=ON -DTO_FIXUP_FILE=$ > -DTO_FIXUP_LIBS=${_libs} -DTO_FIXUP_DIRS=${_dirs} -P ${THIS_FILE} > > COMMENT "Fixing up dependencies for > ${_target}" > > VERBATIM > > ) > > endfunction() > > endif() > > *De : *Cl?ment Gregoire > *Envoy? le :*jeudi 4 mai 2017 08:37 > *? : *Hendrik Sattler ; Louis-Paul > CORDIER ; Cmake Mailing List > > *Objet :*Re: [CMake] DLL handling under CMake > > I'd also be interested in this. I saw an old mail in the ML about > this, but it seems fixup_bundle is old and cant use generator > expressions, making it hard to use (I don't want to hardcode the > executable path). > > Do you have a sample for this ? > > CMake would really benefit from having those features made more > accessible instead of everyone having to write its own script > > Le sam. 29 avr. 2017 22:10, Hendrik Sattler > a ?crit : > > > > Am 27. April 2017 10:43:50 MESZ schrieb Louis-Paul CORDIER > >: > >This steps are tedious and I'm wondering if there is a mechanism that > >exists or that have to be imagined to make the DLL nightmare end. > > I use BundleUtilities to achieve the copying of DLL files to the > installation directory. The main problem for this is to enumerate the > needed directories. > > I use the same for copying DLL files to the output directory to ease > debugging. > > The advantage is the inspection of the exe for really needed DLL > files. This AUTOMATICALLY handles the case debug vs. release. > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From csiga.biga at aol.com Tue Jul 4 06:43:24 2017 From: csiga.biga at aol.com (=?utf-8?Q?Nagy-Egri_M=C3=A1t=C3=A9_Ferenc?=) Date: Tue, 4 Jul 2017 12:43:24 +0200 Subject: [CMake] CMake Server Mode and USE_FOLDERS In-Reply-To: <595AF867.3090306@bluequartz.net> References: <595AF867.3090306@bluequartz.net> Message-ID: I can only speak about VS, which currently neither with the VS nor the Ninja generator use the FOLDERS property to lay out the targets inside the Solution Explorer. Instead, it maintains the folder structure of the CMake project. This was an intentional design decision from their part (at least for the time being), due to CMake folks primarily being used to the command line, thus they think in therms of the folder structure, not the logical layout of the CMake scripts. There is a tendency though of hooking all CMake notions into the IDE, such as CTests show up Test Explorer. Reach out to the VS CMake team and let them know that there is such need, perhaps controlled through a switch. Felad?: Michael Jackson Elk?ldve: 2017. j?lius 4., kedd 4:08 C?mzett: Cmake Mailing List T?rgy: [CMake] CMake Server Mode and USE_FOLDERS I was just exploring in a command line the CMake Server mode in 3.8 (I have not tried 3.9 yet) just to see what gets output and I was wondering if CMake-Server mode supports "set_property(GLOBAL PROPERTY USE_FOLDERS ON)" for any generator? I was specifically using the "ninja" generator for my experiments. I suspect not since Ninja itself does not have the concept of this but I though I would inquire. If IDE's that are now relying on CMake-server had this information it would allow the IDE to present the project in such a way that the developers intended or laid out. I know we put a lot of time into our CMake files so that the Visual Studio and Xcode projects are reasonably organized when you open them instead of just listing 250 targets. Thanks for any insights. Mike Jackson -- 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 florent.castelli at gmail.com Tue Jul 4 08:51:12 2017 From: florent.castelli at gmail.com (Florent Castelli) Date: Tue, 4 Jul 2017 14:51:12 +0200 Subject: [CMake] CMake Server Mode and USE_FOLDERS In-Reply-To: <20170704104328.36134F9EF2@public.kitware.com> References: <595AF867.3090306@bluequartz.net> <20170704104328.36134F9EF2@public.kitware.com> Message-ID: <83eef9a8-3ab0-8b0d-45c1-038cf907345e@gmail.com> From what I've read from the VS CMake team at Microsoft in various blog posts and online discussions, they plan to have actual targets someday in VS instead of the "Open folder" structure they currently have with their integration. So right now, that information wouldn't be of any use for them since they don't even have a flat list of projects. It just takes time! Seeing from the progress they've made, I'm sure it will eventually come to the product. /Florent On 04/07/2017 12:43, Nagy-Egri M?t? Ferenc via CMake wrote: > > I can only speak about VS, which currently neither with the VS nor the > Ninja generator use the FOLDERS property to lay out the targets inside > the Solution Explorer. Instead, it maintains the folder structure of > the CMake project. This was an intentional design decision from their > part (at least for the time being), due to CMake folks primarily being > used to the command line, thus they think in therms of the folder > structure, not the logical layout of the CMake scripts. > > There is a tendency though of hooking all CMake notions into the IDE, > such as CTests show up Test Explorer. Reach out to the VS CMake team > and let them know that there is such need, perhaps controlled through > a switch. > > *Felad?: *Michael Jackson > *Elk?ldve: *2017. j?lius 4., kedd 4:08 > *C?mzett: *Cmake Mailing List > *T?rgy: *[CMake] CMake Server Mode and USE_FOLDERS > > I was just exploring in a command line the CMake Server mode in 3.8 (I > > have not tried 3.9 yet) just to see what gets output and I was wondering > > if CMake-Server mode supports "set_property(GLOBAL PROPERTY USE_FOLDERS > > ON)" for any generator? I was specifically using the "ninja" generator > > for my experiments. I suspect not since Ninja itself does not have the > > concept of this but I though I would inquire. > > If IDE's that are now relying on CMake-server had this information it > > would allow the IDE to present the project in such a way that the > > developers intended or laid out. I know we put a lot of time into our > > CMake files so that the Visual Studio and Xcode projects are reasonably > > organized when you open them instead of just listing 250 targets. > > Thanks for any insights. > > Mike Jackson > > -- > > 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 mike.jackson at bluequartz.net Tue Jul 4 09:21:34 2017 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Tue, 04 Jul 2017 09:21:34 -0400 Subject: [CMake] CMake Server Mode and USE_FOLDERS In-Reply-To: <20170704104328.1A5C1FA001@public.kitware.com> References: <595AF867.3090306@bluequartz.net> <20170704104328.1A5C1FA001@public.kitware.com> Message-ID: <595B965E.40501@bluequartz.net> Actually, my comments were spurred on from a discussion on the QtCreator list. I am *very* happy with the layout inside of VS2015 that we have been able to generate based on the USE_FOLDERS property. QtCreator tends to use the Ninja generator to generate the actual build system. QtCreator just calls "cmake --build . ...." when it needs to build your project. And since they use the "Ninja" generator (which I think is user settable) and Ninja does not support the USE_FOLDERS notion, that USE_FOLDERS would need to be implemented in the Ninja generator so that CMAKE-Server mode would pass that information? I don't know how separated the Cmake-server code model is from the actual generator. -- Mike Jackson Nagy-Egri M?t? Ferenc via CMake wrote: > I can only speak about VS, which currently neither with the VS nor > the Ninja generator use the FOLDERS property to lay out the targets > inside the Solution Explorer. Instead, it maintains the folder > structure of the CMake project. This was an intentional design > decision from their part (at least for the time being), due to CMake > folks primarily being used to the command line, thus they think in > therms of the folder structure, not the logical layout of the CMake > scripts. > > There is a tendency though of hooking all CMake notions into the IDE, > such as CTests show up Test Explorer. Reach out to the VS CMake team > and let them know that there is such need, perhaps controlled through > a switch. > > *Felad?: *Michael Jackson > *Elk?ldve: *2017. j?lius 4., kedd 4:08 *C?mzett: *Cmake Mailing List > *T?rgy: *[CMake] CMake Server Mode and > USE_FOLDERS > > I was just exploring in a command line the CMake Server mode in 3.8 > (I > > have not tried 3.9 yet) just to see what gets output and I was > wondering > > if CMake-Server mode supports "set_property(GLOBAL PROPERTY > USE_FOLDERS > > ON)" for any generator? I was specifically using the "ninja" > generator > > for my experiments. I suspect not since Ninja itself does not have > the > > concept of this but I though I would inquire. > > If IDE's that are now relying on CMake-server had this information > it > > would allow the IDE to present the project in such a way that the > > developers intended or laid out. I know we put a lot of time into > our > > CMake files so that the Visual Studio and Xcode projects are > reasonably > > organized when you open them instead of just listing 250 targets. > > Thanks for any insights. > > Mike Jackson > > -- > > 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 ndevenish at gmail.com Wed Jul 5 06:10:52 2017 From: ndevenish at gmail.com (Nicholas Devenish) Date: Wed, 5 Jul 2017 11:10:52 +0100 Subject: [CMake] CmakeLists chain cannot find source added with add_custom_command In-Reply-To: References: Message-ID: Hi, It looks like this is the issue covered in https://cmake.org/Wiki/CMake_FAQ#How_can_I_add_a_dependency_to_a_source_file_which_is_generated_in_a_subdirectory.3F and bug https://gitlab.kitware.com/cmake/cmake/issues/14633 ? I suppose if you are writing your own systems from scratch it's easy not to run into this, but a lot easier when converting existing complicated build systems. I kind of agree that it's easy to miss this constraint reading the documentation, but there doesn't seem to be a better suggested solution yet. Nick On Sun, Jul 2, 2017 at 11:57 AM, Eric Noulard wrote: > Ok, > > I reproduced your issue and I can then confirm it. > I tried several thing including: > - generating the file is the buildtree > - refering to the same file with another target in the same dir > - using absolute path in the sub2/add_executable > > nothing works. > it looks like a generated file cannot be referred outside the directory > where the custom command generates it ??? > > Here comes an archive with an example similar to the one descrived by J. > Decker. > If you build it without option it wokrs (because I used an intermediate > object lib) > If you (try to) build it with > > cmake -DBROKEN=1 > > then it'll fails with "Cannot find source file..." > > This is definitely weird and I never encountered this after +10 years of > CMake usage!! > So I guess I have always used generated file locally to build exe or lib and > then refer to the lib. > If this is the intended behaviour then it should be documented more > explicitely. > > Now re-reading the doc of add_custom_command: > > "This defines a command to generate specified ``OUTPUT`` file(s). > A target created in the same directory (``CMakeLists.txt`` file) > that specifies any output of the custom command as a source file > is given a rule to generate the file using the command at build time." > > So the "same directory" should be underlined!! Or may be another sentence > saying that in fact you CANNOT refer to outputed files outside the > directory... > > In fact it is possible to have cross-directory reference to generated file > but this is > more like a workaround. You'll have to: > > define your custom_command and an associated custom target in dir1 > define your exe/lib in dir2 and explicitely: > - flag the referred cross-dir generated source as GENERATED > - make your exe/lib depend on the cross-dir custom target in order to > trigger the file generation. > > > The second zip implement that workaround. This is nasty, I wouldn't do that. > Shall we open a bug for this misleading behavior or shall we open a bug for > doc update? > > > > 2017-07-02 10:20 GMT+02:00 J Decker : >> >> It is not generated; because it is generated during a the build phase not >> the generate phase. So only the logical idea of the file exists. >> >> On Sun, Jul 2, 2017 at 12:12 AM, Eric Noulard >> wrote: >>> >>> Needless to say that your example should work but somehow CMake does not >>> see that the referred file is GENERATED. >>> >>> Le 2 juil. 2017 09:11, "Eric Noulard" a ?crit : >>>> >>>> Is the referred file created? >>>> Does your actual command creating the file doing it in the source tree >>>> and not in the build tree? >>>> Are you building in-source or out of source? >>>> >>>> Could you give us us a toy example which shows the issue? >>>> >>>> Le 2 juil. 2017 04:32, "J Decker" a ?crit : >>>> >>>> Known issue? Or just doesn't require a response? >>>> >>>> On Wed, Jun 28, 2017 at 6:05 AM, J Decker wrote: >>>>> >>>>> I have this chain of makefiles. It adds a custom rule to build a >>>>> source file, and then a subdirectory cannot reference that file. >>>>> >>>>> The first is added custom rule for M:/tmp/cmake-chain/sub/src/sack.c >>>>> and then later cannot find M:/tmp/cmake-chain/sub/src/sack.c >>>>> though it's really referencing it as >>>>> M:/tmp/cmake-chain/sub/sub2/../src/sack.c >>>>> >>>>> tested with 3.6.0-rc4 and 3.9.0-rc5 >>>>> >>>>> if the add_custom_rule and add_executable are in the same makefile even >>>>> if there's a added path to make it not exactly the same source as the >>>>> 'referencing source' message logs; it works. >>>>> >>>>> >>>>> --- CMakeLists.txt --- >>>>> cmake_minimum_required(VERSION 2.8) >>>>> >>>>> message( "Adding custom rule for >>>>> ${CMAKE_CURRENT_SOURCE_DIR}/src/sack.c" ) >>>>> add_custom_command( OUTPUT ${CMAKE_CURRENT_SOURCE_DIR}/src/sack.c >>>>> COMMAND cmake -E echo do something to make src/sack.c >>>>> ) >>>>> add_subdirectory( sub2 ) >>>>> ------------------------------------- >>>>> >>>>> --- sub2/CmakeLists.txt --- >>>>> message( "referencing source ${CMAKE_CURRENT_SOURCE_DIR}/../src/sack.c" >>>>> ) >>>>> add_executable( something ${CMAKE_CURRENT_SOURCE_DIR}/../src/sack.c ) >>>>> >>>>> ------------------------------------- >>>>> >>>>> --- Truncated output log ------ >>>>> Adding custom rule for M:/tmp/cmake-chain/sub/src/sack.c >>>>> referencing source M:/tmp/cmake-chain/sub/sub2/../src/sack.c >>>>> -- Configuring done >>>>> CMake Error at sub2/CMakeLists.txt:3 (add_executable): >>>>> Cannot find source file: >>>>> >>>>> M:/tmp/cmake-chain/sub/src/sack.c >>>>> >>>>> Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm >>>>> .hpp >>>>> .hxx .in .txx >>>>> -------------------------------------- >>>>> >>>>> >>>>> ------ Flat CmakeLists.txt which works --------------- >>>>> cmake_minimum_required(VERSION 2.8) >>>>> >>>>> message( "Adding custom rule for >>>>> ${CMAKE_CURRENT_SOURCE_DIR}/src/sack.c" ) >>>>> add_custom_command( OUTPUT ${CMAKE_CURRENT_SOURCE_DIR}/src/sack.c >>>>> COMMAND cmake -e echo make file. >>>>> ) >>>>> >>>>> message( "referencing source ${CMAKE_CURRENT_SOURCE_DIR}/src/sack.c" ) >>>>> add_executable( something >>>>> ${CMAKE_CURRENT_SOURCE_DIR}/sub2/../src/sack.c ) >>>>> -------------------------------------- >>>>> >>>>> ----- flat cmakelists output.... ----------- >>>>> Adding custom rule for M:/tmp/cmake-chain-flat/src/sack.c >>>>> referencing source M:/tmp/cmake-chain-flat/sub2/../src/sack.c >>>>> -- Configuring done >>>>> -------------------------------------- >>>>> >>>> >>>> >>>> -- >>>> >>>> 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 > > > > > -- > Eric > > -- > > 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 eric.noulard at gmail.com Wed Jul 5 06:34:59 2017 From: eric.noulard at gmail.com (Eric Noulard) Date: Wed, 5 Jul 2017 12:34:59 +0200 Subject: [CMake] CmakeLists chain cannot find source added with add_custom_command In-Reply-To: References: Message-ID: OK right. I missed the proper FAQ entry, thanks Nicholas for pointing it out. Eric 2017-07-05 12:10 GMT+02:00 Nicholas Devenish : > Hi, > > It looks like this is the issue covered in > https://cmake.org/Wiki/CMake_FAQ#How_can_I_add_a_ > dependency_to_a_source_file_which_is_generated_in_a_subdirectory.3F > and bug https://gitlab.kitware.com/cmake/cmake/issues/14633 ? I > suppose if you are writing your own systems from scratch it's easy not > to run into this, but a lot easier when converting existing > complicated build systems. > > I kind of agree that it's easy to miss this constraint reading the > documentation, but there doesn't seem to be a better suggested > solution yet. > > Nick > > > On Sun, Jul 2, 2017 at 11:57 AM, Eric Noulard > wrote: > > Ok, > > > > I reproduced your issue and I can then confirm it. > > I tried several thing including: > > - generating the file is the buildtree > > - refering to the same file with another target in the same dir > > - using absolute path in the sub2/add_executable > > > > nothing works. > > it looks like a generated file cannot be referred outside the directory > > where the custom command generates it ??? > > > > Here comes an archive with an example similar to the one descrived by J. > > Decker. > > If you build it without option it wokrs (because I used an intermediate > > object lib) > > If you (try to) build it with > > > > cmake -DBROKEN=1 > > > > then it'll fails with "Cannot find source file..." > > > > This is definitely weird and I never encountered this after +10 years of > > CMake usage!! > > So I guess I have always used generated file locally to build exe or lib > and > > then refer to the lib. > > If this is the intended behaviour then it should be documented more > > explicitely. > > > > Now re-reading the doc of add_custom_command: > > > > "This defines a command to generate specified ``OUTPUT`` file(s). > > A target created in the same directory (``CMakeLists.txt`` file) > > that specifies any output of the custom command as a source file > > is given a rule to generate the file using the command at build time." > > > > So the "same directory" should be underlined!! Or may be another sentence > > saying that in fact you CANNOT refer to outputed files outside the > > directory... > > > > In fact it is possible to have cross-directory reference to generated > file > > but this is > > more like a workaround. You'll have to: > > > > define your custom_command and an associated custom target in dir1 > > define your exe/lib in dir2 and explicitely: > > - flag the referred cross-dir generated source as GENERATED > > - make your exe/lib depend on the cross-dir custom target in order to > > trigger the file generation. > > > > > > The second zip implement that workaround. This is nasty, I wouldn't do > that. > > Shall we open a bug for this misleading behavior or shall we open a bug > for > > doc update? > > > > > > > > 2017-07-02 10:20 GMT+02:00 J Decker : > >> > >> It is not generated; because it is generated during a the build phase > not > >> the generate phase. So only the logical idea of the file exists. > >> > >> On Sun, Jul 2, 2017 at 12:12 AM, Eric Noulard > >> wrote: > >>> > >>> Needless to say that your example should work but somehow CMake does > not > >>> see that the referred file is GENERATED. > >>> > >>> Le 2 juil. 2017 09:11, "Eric Noulard" a > ?crit : > >>>> > >>>> Is the referred file created? > >>>> Does your actual command creating the file doing it in the source tree > >>>> and not in the build tree? > >>>> Are you building in-source or out of source? > >>>> > >>>> Could you give us us a toy example which shows the issue? > >>>> > >>>> Le 2 juil. 2017 04:32, "J Decker" a ?crit : > >>>> > >>>> Known issue? Or just doesn't require a response? > >>>> > >>>> On Wed, Jun 28, 2017 at 6:05 AM, J Decker wrote: > >>>>> > >>>>> I have this chain of makefiles. It adds a custom rule to build a > >>>>> source file, and then a subdirectory cannot reference that file. > >>>>> > >>>>> The first is added custom rule for M:/tmp/cmake-chain/sub/src/sack.c > >>>>> and then later cannot find M:/tmp/cmake-chain/sub/src/sack.c > >>>>> though it's really referencing it as > >>>>> M:/tmp/cmake-chain/sub/sub2/../src/sack.c > >>>>> > >>>>> tested with 3.6.0-rc4 and 3.9.0-rc5 > >>>>> > >>>>> if the add_custom_rule and add_executable are in the same makefile > even > >>>>> if there's a added path to make it not exactly the same source as the > >>>>> 'referencing source' message logs; it works. > >>>>> > >>>>> > >>>>> --- CMakeLists.txt --- > >>>>> cmake_minimum_required(VERSION 2.8) > >>>>> > >>>>> message( "Adding custom rule for > >>>>> ${CMAKE_CURRENT_SOURCE_DIR}/src/sack.c" ) > >>>>> add_custom_command( OUTPUT ${CMAKE_CURRENT_SOURCE_DIR}/src/sack.c > >>>>> COMMAND cmake -E echo do something to make src/sack.c > >>>>> ) > >>>>> add_subdirectory( sub2 ) > >>>>> ------------------------------------- > >>>>> > >>>>> --- sub2/CmakeLists.txt --- > >>>>> message( "referencing source ${CMAKE_CURRENT_SOURCE_DIR}/.. > /src/sack.c" > >>>>> ) > >>>>> add_executable( something ${CMAKE_CURRENT_SOURCE_DIR}/../src/sack.c > ) > >>>>> > >>>>> ------------------------------------- > >>>>> > >>>>> --- Truncated output log ------ > >>>>> Adding custom rule for M:/tmp/cmake-chain/sub/src/sack.c > >>>>> referencing source M:/tmp/cmake-chain/sub/sub2/../src/sack.c > >>>>> -- Configuring done > >>>>> CMake Error at sub2/CMakeLists.txt:3 (add_executable): > >>>>> Cannot find source file: > >>>>> > >>>>> M:/tmp/cmake-chain/sub/src/sack.c > >>>>> > >>>>> Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm > >>>>> .hpp > >>>>> .hxx .in .txx > >>>>> -------------------------------------- > >>>>> > >>>>> > >>>>> ------ Flat CmakeLists.txt which works --------------- > >>>>> cmake_minimum_required(VERSION 2.8) > >>>>> > >>>>> message( "Adding custom rule for > >>>>> ${CMAKE_CURRENT_SOURCE_DIR}/src/sack.c" ) > >>>>> add_custom_command( OUTPUT ${CMAKE_CURRENT_SOURCE_DIR}/src/sack.c > >>>>> COMMAND cmake -e echo make file. > >>>>> ) > >>>>> > >>>>> message( "referencing source ${CMAKE_CURRENT_SOURCE_DIR}/src/sack.c" > ) > >>>>> add_executable( something > >>>>> ${CMAKE_CURRENT_SOURCE_DIR}/sub2/../src/sack.c ) > >>>>> -------------------------------------- > >>>>> > >>>>> ----- flat cmakelists output.... ----------- > >>>>> Adding custom rule for M:/tmp/cmake-chain-flat/src/sack.c > >>>>> referencing source M:/tmp/cmake-chain-flat/sub2/../src/sack.c > >>>>> -- Configuring done > >>>>> -------------------------------------- > >>>>> > >>>> > >>>> > >>>> -- > >>>> > >>>> 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 > > > > > > > > > > -- > > Eric > > > > -- > > > > 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 d3ck0r at gmail.com Wed Jul 5 07:05:34 2017 From: d3ck0r at gmail.com (J Decker) Date: Wed, 5 Jul 2017 04:05:34 -0700 Subject: [CMake] CmakeLists chain cannot find source added with add_custom_command In-Reply-To: References: Message-ID: Was more of a style thing... I had (from another project) a cmakelists includable script that builds an amalgamation of sources (makes the compilation much faster overall because it doesn't have to read megs of headers for windows.h et al. for 50 sources but then only 1.) so I was updating to use this script, I already had a folder 'portable' which did more of a source based build instead of pulling various DLLs.... so it was like .../loader (the main project, that links to dlls) included common amalgamation maker here .../loader/portable (the static builds of the same sources) that really only contains a single CMakeLists.txt, so rather than use the sources, updated to use the amalgamation instead, and it blew up. I ended up just moving the portable/CMakeLists.txt to CMakeLists.portable.txt and including that instead. Just caught me off guard that it would keep custom targets private to a directory instead of making it globally available. Which would complicate implementing this more in lots of other 'portable' (single exe, no DLL builds) But I guess I could create a target that's that amalgamation compiled to a static library that could then be referenced by other projects. On Wed, Jul 5, 2017 at 3:34 AM, Eric Noulard wrote: > OK right. > I missed the proper FAQ entry, thanks Nicholas for pointing it out. > > Eric > > 2017-07-05 12:10 GMT+02:00 Nicholas Devenish : > >> Hi, >> >> It looks like this is the issue covered in >> https://cmake.org/Wiki/CMake_FAQ#How_can_I_add_a_dependency_ >> to_a_source_file_which_is_generated_in_a_subdirectory.3F >> and bug https://gitlab.kitware.com/cmake/cmake/issues/14633 ? I >> suppose if you are writing your own systems from scratch it's easy not >> to run into this, but a lot easier when converting existing >> complicated build systems. >> >> I kind of agree that it's easy to miss this constraint reading the >> documentation, but there doesn't seem to be a better suggested >> solution yet. >> >> Nick >> >> >> On Sun, Jul 2, 2017 at 11:57 AM, Eric Noulard >> wrote: >> > Ok, >> > >> > I reproduced your issue and I can then confirm it. >> > I tried several thing including: >> > - generating the file is the buildtree >> > - refering to the same file with another target in the same dir >> > - using absolute path in the sub2/add_executable >> > >> > nothing works. >> > it looks like a generated file cannot be referred outside the directory >> > where the custom command generates it ??? >> > >> > Here comes an archive with an example similar to the one descrived by J. >> > Decker. >> > If you build it without option it wokrs (because I used an intermediate >> > object lib) >> > If you (try to) build it with >> > >> > cmake -DBROKEN=1 >> > >> > then it'll fails with "Cannot find source file..." >> > >> > This is definitely weird and I never encountered this after +10 years of >> > CMake usage!! >> > So I guess I have always used generated file locally to build exe or >> lib and >> > then refer to the lib. >> > If this is the intended behaviour then it should be documented more >> > explicitely. >> > >> > Now re-reading the doc of add_custom_command: >> > >> > "This defines a command to generate specified ``OUTPUT`` file(s). >> > A target created in the same directory (``CMakeLists.txt`` file) >> > that specifies any output of the custom command as a source file >> > is given a rule to generate the file using the command at build time." >> > >> > So the "same directory" should be underlined!! Or may be another >> sentence >> > saying that in fact you CANNOT refer to outputed files outside the >> > directory... >> > >> > In fact it is possible to have cross-directory reference to generated >> file >> > but this is >> > more like a workaround. You'll have to: >> > >> > define your custom_command and an associated custom target in dir1 >> > define your exe/lib in dir2 and explicitely: >> > - flag the referred cross-dir generated source as GENERATED >> > - make your exe/lib depend on the cross-dir custom target in order to >> > trigger the file generation. >> > >> > >> > The second zip implement that workaround. This is nasty, I wouldn't do >> that. >> > Shall we open a bug for this misleading behavior or shall we open a bug >> for >> > doc update? >> > >> > >> > >> > 2017-07-02 10:20 GMT+02:00 J Decker : >> >> >> >> It is not generated; because it is generated during a the build phase >> not >> >> the generate phase. So only the logical idea of the file exists. >> >> >> >> On Sun, Jul 2, 2017 at 12:12 AM, Eric Noulard >> >> wrote: >> >>> >> >>> Needless to say that your example should work but somehow CMake does >> not >> >>> see that the referred file is GENERATED. >> >>> >> >>> Le 2 juil. 2017 09:11, "Eric Noulard" a >> ?crit : >> >>>> >> >>>> Is the referred file created? >> >>>> Does your actual command creating the file doing it in the source >> tree >> >>>> and not in the build tree? >> >>>> Are you building in-source or out of source? >> >>>> >> >>>> Could you give us us a toy example which shows the issue? >> >>>> >> >>>> Le 2 juil. 2017 04:32, "J Decker" a ?crit : >> >>>> >> >>>> Known issue? Or just doesn't require a response? >> >>>> >> >>>> On Wed, Jun 28, 2017 at 6:05 AM, J Decker wrote: >> >>>>> >> >>>>> I have this chain of makefiles. It adds a custom rule to build a >> >>>>> source file, and then a subdirectory cannot reference that file. >> >>>>> >> >>>>> The first is added custom rule for M:/tmp/cmake-chain/sub/src/sac >> k.c >> >>>>> and then later cannot find M:/tmp/cmake-chain/sub/src/sack.c >> >>>>> though it's really referencing it as >> >>>>> M:/tmp/cmake-chain/sub/sub2/../src/sack.c >> >>>>> >> >>>>> tested with 3.6.0-rc4 and 3.9.0-rc5 >> >>>>> >> >>>>> if the add_custom_rule and add_executable are in the same makefile >> even >> >>>>> if there's a added path to make it not exactly the same source as >> the >> >>>>> 'referencing source' message logs; it works. >> >>>>> >> >>>>> >> >>>>> --- CMakeLists.txt --- >> >>>>> cmake_minimum_required(VERSION 2.8) >> >>>>> >> >>>>> message( "Adding custom rule for >> >>>>> ${CMAKE_CURRENT_SOURCE_DIR}/src/sack.c" ) >> >>>>> add_custom_command( OUTPUT ${CMAKE_CURRENT_SOURCE_DIR}/src/sack.c >> >>>>> COMMAND cmake -E echo do something to make src/sack.c >> >>>>> ) >> >>>>> add_subdirectory( sub2 ) >> >>>>> ------------------------------------- >> >>>>> >> >>>>> --- sub2/CmakeLists.txt --- >> >>>>> message( "referencing source ${CMAKE_CURRENT_SOURCE_DIR}/.. >> /src/sack.c" >> >>>>> ) >> >>>>> add_executable( something ${CMAKE_CURRENT_SOURCE_DIR}/../src/sack.c >> ) >> >>>>> >> >>>>> ------------------------------------- >> >>>>> >> >>>>> --- Truncated output log ------ >> >>>>> Adding custom rule for M:/tmp/cmake-chain/sub/src/sack.c >> >>>>> referencing source M:/tmp/cmake-chain/sub/sub2/../src/sack.c >> >>>>> -- Configuring done >> >>>>> CMake Error at sub2/CMakeLists.txt:3 (add_executable): >> >>>>> Cannot find source file: >> >>>>> >> >>>>> M:/tmp/cmake-chain/sub/src/sack.c >> >>>>> >> >>>>> Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ >> .hm >> >>>>> .hpp >> >>>>> .hxx .in .txx >> >>>>> -------------------------------------- >> >>>>> >> >>>>> >> >>>>> ------ Flat CmakeLists.txt which works --------------- >> >>>>> cmake_minimum_required(VERSION 2.8) >> >>>>> >> >>>>> message( "Adding custom rule for >> >>>>> ${CMAKE_CURRENT_SOURCE_DIR}/src/sack.c" ) >> >>>>> add_custom_command( OUTPUT ${CMAKE_CURRENT_SOURCE_DIR}/src/sack.c >> >>>>> COMMAND cmake -e echo make file. >> >>>>> ) >> >>>>> >> >>>>> message( "referencing source ${CMAKE_CURRENT_SOURCE_DIR}/src/sack.c" >> ) >> >>>>> add_executable( something >> >>>>> ${CMAKE_CURRENT_SOURCE_DIR}/sub2/../src/sack.c ) >> >>>>> -------------------------------------- >> >>>>> >> >>>>> ----- flat cmakelists output.... ----------- >> >>>>> Adding custom rule for M:/tmp/cmake-chain-flat/src/sack.c >> >>>>> referencing source M:/tmp/cmake-chain-flat/sub2/../src/sack.c >> >>>>> -- Configuring done >> >>>>> -------------------------------------- >> >>>>> >> >>>> >> >>>> >> >>>> -- >> >>>> >> >>>> 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 >> > >> > >> > >> > >> > -- >> > Eric >> > >> > -- >> > >> > 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 > > -- > > 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 d3ck0r at gmail.com Wed Jul 5 07:08:34 2017 From: d3ck0r at gmail.com (J Decker) Date: Wed, 5 Jul 2017 04:08:34 -0700 Subject: [CMake] CmakeLists chain cannot find source added with add_custom_command In-Reply-To: References: Message-ID: On Wed, Jul 5, 2017 at 4:05 AM, J Decker wrote: > Was more of a style thing... I had (from another project) a cmakelists > includable script that builds an amalgamation of sources (makes the > compilation much faster overall because it doesn't have to read megs of > headers for windows.h et al. for 50 sources but then only 1.) so I was > updating to use this script, I already had a folder 'portable' which did > more of a source based build instead of pulling various DLLs.... so it was > like > .../loader (the main project, that links to dlls) included common > amalgamation maker here > .../loader/portable (the static builds of the same sources) that really > only contains a single CMakeLists.txt, so rather than use the sources, > updated to use the amalgamation instead, and it blew up. > > I ended up just moving the portable/CMakeLists.txt to > CMakeLists.portable.txt and including that instead. > > Just caught me off guard that it would keep custom targets private to a > directory instead of making it globally available. Which would complicate > implementing this more in lots of other 'portable' (single exe, no DLL > builds) But I guess I could create a target that's that amalgamation > compiled to a static library that could then be referenced by other > projects. > hmm that won't work, the source has the target name compiled into it, so it would really have to be recompiled anyway.... and various other definition options might be applied... > > > On Wed, Jul 5, 2017 at 3:34 AM, Eric Noulard > wrote: > >> OK right. >> I missed the proper FAQ entry, thanks Nicholas for pointing it out. >> >> Eric >> >> 2017-07-05 12:10 GMT+02:00 Nicholas Devenish : >> >>> Hi, >>> >>> It looks like this is the issue covered in >>> https://cmake.org/Wiki/CMake_FAQ#How_can_I_add_a_dependency_ >>> to_a_source_file_which_is_generated_in_a_subdirectory.3F >>> and bug https://gitlab.kitware.com/cmake/cmake/issues/14633 ? I >>> suppose if you are writing your own systems from scratch it's easy not >>> to run into this, but a lot easier when converting existing >>> complicated build systems. >>> >>> I kind of agree that it's easy to miss this constraint reading the >>> documentation, but there doesn't seem to be a better suggested >>> solution yet. >>> >>> Nick >>> >>> >>> On Sun, Jul 2, 2017 at 11:57 AM, Eric Noulard >>> wrote: >>> > Ok, >>> > >>> > I reproduced your issue and I can then confirm it. >>> > I tried several thing including: >>> > - generating the file is the buildtree >>> > - refering to the same file with another target in the same dir >>> > - using absolute path in the sub2/add_executable >>> > >>> > nothing works. >>> > it looks like a generated file cannot be referred outside the directory >>> > where the custom command generates it ??? >>> > >>> > Here comes an archive with an example similar to the one descrived by >>> J. >>> > Decker. >>> > If you build it without option it wokrs (because I used an intermediate >>> > object lib) >>> > If you (try to) build it with >>> > >>> > cmake -DBROKEN=1 >>> > >>> > then it'll fails with "Cannot find source file..." >>> > >>> > This is definitely weird and I never encountered this after +10 years >>> of >>> > CMake usage!! >>> > So I guess I have always used generated file locally to build exe or >>> lib and >>> > then refer to the lib. >>> > If this is the intended behaviour then it should be documented more >>> > explicitely. >>> > >>> > Now re-reading the doc of add_custom_command: >>> > >>> > "This defines a command to generate specified ``OUTPUT`` file(s). >>> > A target created in the same directory (``CMakeLists.txt`` file) >>> > that specifies any output of the custom command as a source file >>> > is given a rule to generate the file using the command at build time." >>> > >>> > So the "same directory" should be underlined!! Or may be another >>> sentence >>> > saying that in fact you CANNOT refer to outputed files outside the >>> > directory... >>> > >>> > In fact it is possible to have cross-directory reference to generated >>> file >>> > but this is >>> > more like a workaround. You'll have to: >>> > >>> > define your custom_command and an associated custom target in dir1 >>> > define your exe/lib in dir2 and explicitely: >>> > - flag the referred cross-dir generated source as GENERATED >>> > - make your exe/lib depend on the cross-dir custom target in order >>> to >>> > trigger the file generation. >>> > >>> > >>> > The second zip implement that workaround. This is nasty, I wouldn't do >>> that. >>> > Shall we open a bug for this misleading behavior or shall we open a >>> bug for >>> > doc update? >>> > >>> > >>> > >>> > 2017-07-02 10:20 GMT+02:00 J Decker : >>> >> >>> >> It is not generated; because it is generated during a the build phase >>> not >>> >> the generate phase. So only the logical idea of the file exists. >>> >> >>> >> On Sun, Jul 2, 2017 at 12:12 AM, Eric Noulard >> > >>> >> wrote: >>> >>> >>> >>> Needless to say that your example should work but somehow CMake does >>> not >>> >>> see that the referred file is GENERATED. >>> >>> >>> >>> Le 2 juil. 2017 09:11, "Eric Noulard" a >>> ?crit : >>> >>>> >>> >>>> Is the referred file created? >>> >>>> Does your actual command creating the file doing it in the source >>> tree >>> >>>> and not in the build tree? >>> >>>> Are you building in-source or out of source? >>> >>>> >>> >>>> Could you give us us a toy example which shows the issue? >>> >>>> >>> >>>> Le 2 juil. 2017 04:32, "J Decker" a ?crit : >>> >>>> >>> >>>> Known issue? Or just doesn't require a response? >>> >>>> >>> >>>> On Wed, Jun 28, 2017 at 6:05 AM, J Decker wrote: >>> >>>>> >>> >>>>> I have this chain of makefiles. It adds a custom rule to build a >>> >>>>> source file, and then a subdirectory cannot reference that file. >>> >>>>> >>> >>>>> The first is added custom rule for M:/tmp/cmake-chain/sub/src/sac >>> k.c >>> >>>>> and then later cannot find M:/tmp/cmake-chain/sub/src/sack.c >>> >>>>> though it's really referencing it as >>> >>>>> M:/tmp/cmake-chain/sub/sub2/../src/sack.c >>> >>>>> >>> >>>>> tested with 3.6.0-rc4 and 3.9.0-rc5 >>> >>>>> >>> >>>>> if the add_custom_rule and add_executable are in the same makefile >>> even >>> >>>>> if there's a added path to make it not exactly the same source as >>> the >>> >>>>> 'referencing source' message logs; it works. >>> >>>>> >>> >>>>> >>> >>>>> --- CMakeLists.txt --- >>> >>>>> cmake_minimum_required(VERSION 2.8) >>> >>>>> >>> >>>>> message( "Adding custom rule for >>> >>>>> ${CMAKE_CURRENT_SOURCE_DIR}/src/sack.c" ) >>> >>>>> add_custom_command( OUTPUT ${CMAKE_CURRENT_SOURCE_DIR}/sr >>> c/sack.c >>> >>>>> COMMAND cmake -E echo do something to make src/sack.c >>> >>>>> ) >>> >>>>> add_subdirectory( sub2 ) >>> >>>>> ------------------------------------- >>> >>>>> >>> >>>>> --- sub2/CmakeLists.txt --- >>> >>>>> message( "referencing source ${CMAKE_CURRENT_SOURCE_DIR}/.. >>> /src/sack.c" >>> >>>>> ) >>> >>>>> add_executable( something ${CMAKE_CURRENT_SOURCE_DIR}/../src/sack.c >>> ) >>> >>>>> >>> >>>>> ------------------------------------- >>> >>>>> >>> >>>>> --- Truncated output log ------ >>> >>>>> Adding custom rule for M:/tmp/cmake-chain/sub/src/sack.c >>> >>>>> referencing source M:/tmp/cmake-chain/sub/sub2/../src/sack.c >>> >>>>> -- Configuring done >>> >>>>> CMake Error at sub2/CMakeLists.txt:3 (add_executable): >>> >>>>> Cannot find source file: >>> >>>>> >>> >>>>> M:/tmp/cmake-chain/sub/src/sack.c >>> >>>>> >>> >>>>> Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ >>> .hm >>> >>>>> .hpp >>> >>>>> .hxx .in .txx >>> >>>>> -------------------------------------- >>> >>>>> >>> >>>>> >>> >>>>> ------ Flat CmakeLists.txt which works --------------- >>> >>>>> cmake_minimum_required(VERSION 2.8) >>> >>>>> >>> >>>>> message( "Adding custom rule for >>> >>>>> ${CMAKE_CURRENT_SOURCE_DIR}/src/sack.c" ) >>> >>>>> add_custom_command( OUTPUT ${CMAKE_CURRENT_SOURCE_DIR}/sr >>> c/sack.c >>> >>>>> COMMAND cmake -e echo make file. >>> >>>>> ) >>> >>>>> >>> >>>>> message( "referencing source ${CMAKE_CURRENT_SOURCE_DIR}/src/sack.c" >>> ) >>> >>>>> add_executable( something >>> >>>>> ${CMAKE_CURRENT_SOURCE_DIR}/sub2/../src/sack.c ) >>> >>>>> -------------------------------------- >>> >>>>> >>> >>>>> ----- flat cmakelists output.... ----------- >>> >>>>> Adding custom rule for M:/tmp/cmake-chain-flat/src/sack.c >>> >>>>> referencing source M:/tmp/cmake-chain-flat/sub2/../src/sack.c >>> >>>>> -- Configuring done >>> >>>>> -------------------------------------- >>> >>>>> >>> >>>> >>> >>>> >>> >>>> -- >>> >>>> >>> >>>> 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 >>> > >>> > >>> > >>> > >>> > -- >>> > Eric >>> > >>> > -- >>> > >>> > 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 >> >> -- >> >> 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 seanwayland at gmail.com Wed Jul 5 16:50:14 2017 From: seanwayland at gmail.com (Sean Wayland) Date: Wed, 5 Jul 2017 16:50:14 -0400 Subject: [CMake] cmake create executable Undefined symbols for architecture x86_64: Message-ID: I am attempting to write a cmakelists.txt file for an application. The application has a couple of dependencies. I have been able to build targets for the dependencies but when I try and add an executable for the main application I encounter this error. Undefined symbols for architecture x86_64: "_main", referenced from: implicit entry/start for main executable ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) Googling the error and looking on stack exchange suggests that I don't have a main function in the implicit entry/start . Where does it look for this function ? Does that file need to be first in the list of sources ? This function is included here : ${CATSMAT_DIR}/Application/CATSMAT_main.cpp My cmake file is below. Any advice would be appreciated I have been stuck here for a while! Best Sean ####################################### # CMAKE CATSTMAT ####################################### cmake_minimum_required(VERSION 3.6.3) set(CMAKE_CXX_STANDARD 14) if(CMAKE_CONFIGURATION_TYPES) set(CMAKE_CONFIGURATION_TYPES Debug Release) endif() if(UNIX) add_definitions(-Wall -DGCC) endif(UNIX) ##### RPATH SETTING ##### set(CMAKE_MACOSX_RPATH 1) #if(APPLE) # set (CMAKE_OSX_ARCHITECTURES "x86_64 i386") # if (${CMAKE_SYSTEM_VERSION} VERSION_LESS 9.0.0) # set (CMAKE_OSX_SYSROOT /Developer/SDKs/MacOSX10.4u.sdk) # elseif (${CMAKE_SYSTEM_VERSION} VERSION_LESS 10.8.0) # set (CMAKE_OSX_SYSROOT /Developer/SDKs/MacOSX10.5.sdk) # elseif (${XCODE_VERSION} VERSION_LESS 4.0.0) # set (CMAKE_OSX_SYSROOT /Developer/SDKs/MacOSX10.6.sdk) # else () # set (CMAKE_OSX_SYSROOT "macosx10.7") # endif () # set (CMAKE_C++_FLAGS -mmacosx-version-min=10.4) #endif(APPLE) # #if(WIN32) # add_definitions(-DWINVER=0x0400 -DWIN32) # if(${CMAKE_GENERATOR} STREQUAL "Visual Studio 6") # add_definitions(-DVC6) # elseif(${CMAKE_GENERATOR} STREQUAL "Visual Studio 8 2005") # add_definitions(-DVC2005) # endif(${CMAKE_GENERATOR} STREQUAL "Visual Studio 6") #endif(WIN32) ############### BOOST LIBRARIES ########### if (APPLE) set(BOOST_ROOT "/usr/local/boost") set(BOOST_FILESYSTEM_LIB /usr/local/boost/lib/libboost_filesystem.dylib) set(BOOST_SYSTEM_LIB /usr/local/boost/lib/libboost_system.dylib) else (NOT APPLE) set(BOOST_ROOT "C:/local/boost_1_58_0") set(BOOST_FILESYSTEM_LIB C:/local/boost_1_58_0/lib64-msvc-12.0) set(BOOST_SYSTEM_LIB C:/local/boost_1_58_0/lib64-msvc-12.0) endif (APPLE) FIND_PACKAGE( Boost 1.58.0 REQUIRED ) INCLUDE_DIRECTORIES( ${Boost_INCLUDE_DIR} ) ####################################### # set directories, src and headers. set (CATSMAT_DIR /Users/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat ) set (libIMUSANT_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../../libIMUSANT) set (LOKI_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../../Loki) set (SUFFIX_TREE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../../SuffixTree) set (GOOGLE_TEST_INC_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../../googletest-master/googletest/include) set (IMUSANT_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../../libIMUSANT) set (LIBMUSICXML_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../../libMusicXMLv3) #### SET SOURCES EXPLICITLY ##### set(SRC ${CATSMAT_DIR}/Analysis/src/IMUSANT_contour_suffixtree_builder.cpp ${CATSMAT_DIR}/Analysis/src/IMUSANT_generalised_interval_suffixtree_builder.cpp ${CATSMAT_DIR}/Analysis/src/IMUSANT_interval_suffixtree_builder.cpp ${CATSMAT_DIR}/Analysis/src/IMUSANT_pitch_suffixtree_builder.cpp ${CATSMAT_DIR}/Analysis/src/IMUSANT_repeated_interval_substring.cpp ${CATSMAT_DIR}/Analysis/src/IMUSANT_t_repeated_substring.cpp ${CATSMAT_DIR}/Analysis/src/IMUSANT_VectorMapAnalysisTypes.cpp ${CATSMAT_DIR}/Application/CATSMAT_main.cpp ${CATSMAT_DIR}/Application/CATSMAT_menu.cpp ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_chord.cpp ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_collectionvisitor.cpp ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_cp_matrix.cpp ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_dyad_sequences.cpp ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_dyadtuple_sequences.cpp ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_sonority_sequences.cpp ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_TrigramSequences.cpp ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_TrigramSuffixTreeBuilder.cpp ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_canonic_techniques_tools.cpp ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_partdata.cpp ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_processing.cpp ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_score_profile.tpp ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_score_splitter.cpp ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_score_profile_special.cpp ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_scoredata.cpp ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_scoredatacollector.cpp ${CATSMAT_DIR}/Segmentation/IMUSANT_segment.cpp ${CATSMAT_DIR}/Segmentation/IMUSANT_set_of_segment.cpp ${CATSMAT_DIR}/Segmentation/FixedPeriodDetection/src/IMUSANT_fixed_period_segmenter.cpp ${CATSMAT_DIR}/Segmentation/FixedPeriodDetection/src/IMUSANT_partlist_ordered_by_part_entry.cpp ${CATSMAT_DIR}/Segmentation/FixedPeriodDetection/src/IMUSANT_segmented_part_fixed_period.cpp ${CATSMAT_DIR}/Segmentation/FixedPeriodDetection/src/SegmentedScoreFixedPeriod.cpp ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src/IMUSANT_interval_profile_LBDM.cpp ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src/IMUSANT_LBDM_segmenter.cpp ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src/IMUSANT_segmented_note_vectors.cpp ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src/IMUSANT_segmented_part_LBDM.cpp ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src/IMUSANT_segmented_profile_vectors.cpp ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src/IMUSANT_weighted_strength_vectors.cpp ) # old version of adding source code #set (SRCFOLDERS # ${CATSMAT_DIR}/Analysis/src # ${CATSMAT_DIR}/CounterpointAnalysis/src # ${CATSMAT_DIR}/GeneralAnalysis/src # ${CATSMAT_DIR}/Segmentation/FixedPeriodDetection/src # ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src # ${CATSMAT_DIR}/Application # ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src # ${CATSMAT_DIR}/Segmentation # ${CATSMAT_DIR}/Utilities #) set (INCFOLDERS ${libIMUSANT_DIR} ${CATSMAT_DIR}/Analysis/inc ${CATSMAT_DIR}/Application ${CATSMAT_DIR}/CounterpointAnalysis/inc ${CATSMAT_DIR}/GeneralAnalysis/inc ${CATSMAT_DIR}/Segmentation ${CATSMAT_DIR}/Segmentation/FixedPeriodDetection/inc ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/inc ${CATSMAT_DIR}/Utilities ${libIMUSANT_DIR}/DomainObjects/inc ${libIMUSANT_DIR}/Utilities/inc ${libIMUSANT_DIR}/FileProcessing/inc ${libIMUSANT_DIR}/Converters/MusicXML_v3 ${libIMUSANT_DIR}/Converters/MusicXML_v3/inc ${libIMUSANT_DIR}/Converters/MusicXML_v3/shared/inc ${IMUSANT_DIR}/DomainObjects/inc ${IMUSANT_DIR}/Converters/MusicXML_v3 ${IMUSANT_DIR}/Converters/MusicXML_v3/inc ${IMUSANT_DIR}/Converters/Shared/inc ${IMUSANT_DIR}/FileProcessing/inc ${IMUSANT_DIR}/FileProcessing/Analysis/Segmentation/FixedPeriodDetection/ ${IMUSANT_DIR}/Utilities/inc ${SUFFIXTREE_DIR} ${LIBMUSICXML_DIR}/libmusicxml-3.00-src/src ${LIBMUSICXML_DIR}/libmusicxml-3.00-src/src/lib ${LIBMUSICXML_DIR}/libmusicxml-3.00-src/src/visitors ${LIBMUSICXML_DIR}/libmusicxml-3.00-src/src/parser ${LOKI_DIR} ${SUFFIX_TREE_DIR} ${GOOGLE_TEST_INC_DIR} ) #foreach(folder ${SRCFOLDERS}) # set(SRC ${SRC} "${folder}/*.cpp") # add source files #endforeach(folder) #file (GLOB CORESRC RELATIVE ${CMAKE_CURRENT_SOURCE_DIR} ${SRC}) ## is this necessary I think target link directories might do the job ? foreach(folder ${INCFOLDERS}) set(HEADERS ${HEADERS} "${folder}/*.h") # add header files set(INCL ${INCL} "${folder}") # add include folders endforeach(folder) file (GLOB COREH RELATIVE ${CMAKE_CURRENT_SOURCE_DIR} ${HEADERS}) ####################################### # set includes ( is this needed ? ) include_directories( ${INCFOLDERS}) set_source_files_properties (${COREH} PROPERTIES HEADER_FILE_ONLY TRUE) ####################################### # set library target #if(APPLE OR MSVC) set(target catsmat) # I don't know why these if statements are included they seem to do nothing ' #else(APPLE OR MSVC) # set(target catsmat) #endif(APPLE OR MSVC) ##if(MSVC) ## enable_language(RC) ## set(LIBCONTENT ${CORESRC} ${COREH} ${CATSMAT_DIR}/win32/libIMUSANT/libIMUSANT.rc) ##else(MSVC) ## set(LIBCONTENT ${CORESRC} ${COREH}) ##endif(MSVC) add_executable(${target} ${SRC} ) #### add include directories include_directories ( ${INCFOLDERS} ) ############### Targeted Libraries ########### TARGET_LINK_LIBRARIES(${target} gtest) TARGET_LINK_LIBRARIES(${target} ${BOOST_FILESYSTEM_LIB}) TARGET_LINK_LIBRARIES(${target} ${BOOST_SYSTEM_LIB}) TARGET_LINK_LIBRARIES(${target} libmusicxml2) TARGET_LINK_LIBRARIES(${target} libIMUSANT) set_target_properties (${target} PROPERTIES FRAMEWORK TRUE VERSION ${VERSION} C_STANDARD 99 FRAMEWORK_VERSION ${VERSION} PUBLIC_HEADER "${COREH}" DEFINE_SYMBOL LIBMUSICXML_EXPORTS MACOSX_FRAMEWORK_SHORT_VERSION_STRING ${STRVERS} MACOSX_FRAMEWORK_BUNDLE_VERSION ${SSTRVERS} ) ####################################### # install setup if(NOT APPLE) install ( TARGETS ${target} ${TOOLS} RUNTIME DESTINATION bin LIBRARY DESTINATION lib ARCHIVE DESTINATION lib FRAMEWORK DESTINATION "/Library/Frameworks" CONFIGURATIONS Release PUBLIC_HEADER DESTINATION include/libmusicxml ) endif(NOT APPLE) -- www.seanwayland.com Sean Wayland From micha.hergarden at gmail.com Thu Jul 6 02:48:49 2017 From: micha.hergarden at gmail.com (Micha Hergarden) Date: Thu, 6 Jul 2017 08:48:49 +0200 Subject: [CMake] cmake create executable Undefined symbols for architecture x86_64: In-Reply-To: References: Message-ID: <14d703d8-bfa9-2bbc-4ca5-e251ece61b92@gmail.com> On 05-07-17 22:50, Sean Wayland wrote: > I am attempting to write a cmakelists.txt file for an application. > The application has a couple of dependencies. > I have been able to build targets for the dependencies but when I try > and add an executable for the main application I encounter this error. > > Undefined symbols for architecture x86_64: > > "_main", referenced from: > > implicit entry/start for main executable > > ld: symbol(s) not found for architecture x86_64 > > clang: error: linker command failed with exit code 1 (use -v to see invocation) > > > Googling the error and looking on stack exchange suggests that I don't > have a main function in the implicit entry/start . > > Where does it look for this function ? > Does that file need to be first in the list of sources ? > > > > This function is included here : > ${CATSMAT_DIR}/Application/CATSMAT_main.cpp > > My cmake file is below. > > Any advice would be appreciated I have been stuck here for a while! > > Best Sean > > > ####################################### > # CMAKE CATSTMAT > ####################################### > cmake_minimum_required(VERSION 3.6.3) > set(CMAKE_CXX_STANDARD 14) > if(CMAKE_CONFIGURATION_TYPES) > set(CMAKE_CONFIGURATION_TYPES Debug Release) > endif() > > if(UNIX) > add_definitions(-Wall -DGCC) > endif(UNIX) > > ##### RPATH SETTING ##### > set(CMAKE_MACOSX_RPATH 1) > > #if(APPLE) > # set (CMAKE_OSX_ARCHITECTURES "x86_64 i386") > # if (${CMAKE_SYSTEM_VERSION} VERSION_LESS 9.0.0) > # set (CMAKE_OSX_SYSROOT /Developer/SDKs/MacOSX10.4u.sdk) > # elseif (${CMAKE_SYSTEM_VERSION} VERSION_LESS 10.8.0) > # set (CMAKE_OSX_SYSROOT /Developer/SDKs/MacOSX10.5.sdk) > # elseif (${XCODE_VERSION} VERSION_LESS 4.0.0) > # set (CMAKE_OSX_SYSROOT /Developer/SDKs/MacOSX10.6.sdk) > # else () > # set (CMAKE_OSX_SYSROOT "macosx10.7") > # endif () > # set (CMAKE_C++_FLAGS -mmacosx-version-min=10.4) > #endif(APPLE) > # > #if(WIN32) > # add_definitions(-DWINVER=0x0400 -DWIN32) > # if(${CMAKE_GENERATOR} STREQUAL "Visual Studio 6") > # add_definitions(-DVC6) > # elseif(${CMAKE_GENERATOR} STREQUAL "Visual Studio 8 2005") > # add_definitions(-DVC2005) > # endif(${CMAKE_GENERATOR} STREQUAL "Visual Studio 6") > #endif(WIN32) > > ############### BOOST LIBRARIES ########### > if (APPLE) > set(BOOST_ROOT "/usr/local/boost") > set(BOOST_FILESYSTEM_LIB /usr/local/boost/lib/libboost_filesystem.dylib) > set(BOOST_SYSTEM_LIB /usr/local/boost/lib/libboost_system.dylib) > > else (NOT APPLE) > set(BOOST_ROOT "C:/local/boost_1_58_0") > set(BOOST_FILESYSTEM_LIB C:/local/boost_1_58_0/lib64-msvc-12.0) > set(BOOST_SYSTEM_LIB C:/local/boost_1_58_0/lib64-msvc-12.0) > endif (APPLE) > > FIND_PACKAGE( Boost 1.58.0 REQUIRED ) > INCLUDE_DIRECTORIES( ${Boost_INCLUDE_DIR} ) > > > ####################################### > # set directories, src and headers. > > set (CATSMAT_DIR /Users/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat ) > set (libIMUSANT_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../../libIMUSANT) > set (LOKI_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../../Loki) > set (SUFFIX_TREE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../../SuffixTree) > set (GOOGLE_TEST_INC_DIR > ${CMAKE_CURRENT_SOURCE_DIR}/../../googletest-master/googletest/include) > set (IMUSANT_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../../libIMUSANT) > > > set (LIBMUSICXML_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../../libMusicXMLv3) > > > #### SET SOURCES EXPLICITLY ##### > > set(SRC > > ${CATSMAT_DIR}/Analysis/src/IMUSANT_contour_suffixtree_builder.cpp > ${CATSMAT_DIR}/Analysis/src/IMUSANT_generalised_interval_suffixtree_builder.cpp > ${CATSMAT_DIR}/Analysis/src/IMUSANT_interval_suffixtree_builder.cpp > ${CATSMAT_DIR}/Analysis/src/IMUSANT_pitch_suffixtree_builder.cpp > ${CATSMAT_DIR}/Analysis/src/IMUSANT_repeated_interval_substring.cpp > ${CATSMAT_DIR}/Analysis/src/IMUSANT_t_repeated_substring.cpp > ${CATSMAT_DIR}/Analysis/src/IMUSANT_VectorMapAnalysisTypes.cpp > > ${CATSMAT_DIR}/Application/CATSMAT_main.cpp > ${CATSMAT_DIR}/Application/CATSMAT_menu.cpp > > ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_chord.cpp > ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_collectionvisitor.cpp > ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_cp_matrix.cpp > ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_dyad_sequences.cpp > ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_dyadtuple_sequences.cpp > ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_sonority_sequences.cpp > ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_TrigramSequences.cpp > ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_TrigramSuffixTreeBuilder.cpp > > ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_canonic_techniques_tools.cpp > ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_partdata.cpp > ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_processing.cpp > ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_score_profile.tpp > ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_score_splitter.cpp > ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_score_profile_special.cpp > ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_scoredata.cpp > ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_scoredatacollector.cpp > > ${CATSMAT_DIR}/Segmentation/IMUSANT_segment.cpp > ${CATSMAT_DIR}/Segmentation/IMUSANT_set_of_segment.cpp > > ${CATSMAT_DIR}/Segmentation/FixedPeriodDetection/src/IMUSANT_fixed_period_segmenter.cpp > ${CATSMAT_DIR}/Segmentation/FixedPeriodDetection/src/IMUSANT_partlist_ordered_by_part_entry.cpp > ${CATSMAT_DIR}/Segmentation/FixedPeriodDetection/src/IMUSANT_segmented_part_fixed_period.cpp > ${CATSMAT_DIR}/Segmentation/FixedPeriodDetection/src/SegmentedScoreFixedPeriod.cpp > > ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src/IMUSANT_interval_profile_LBDM.cpp > ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src/IMUSANT_LBDM_segmenter.cpp > ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src/IMUSANT_segmented_note_vectors.cpp > ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src/IMUSANT_segmented_part_LBDM.cpp > ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src/IMUSANT_segmented_profile_vectors.cpp > ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src/IMUSANT_weighted_strength_vectors.cpp > > > > > ) > > > > > # old version of adding source code > > #set (SRCFOLDERS > > > # ${CATSMAT_DIR}/Analysis/src > # ${CATSMAT_DIR}/CounterpointAnalysis/src > # ${CATSMAT_DIR}/GeneralAnalysis/src > # ${CATSMAT_DIR}/Segmentation/FixedPeriodDetection/src > # ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src > # ${CATSMAT_DIR}/Application > # ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src > # ${CATSMAT_DIR}/Segmentation > # ${CATSMAT_DIR}/Utilities > #) > > > set (INCFOLDERS > ${libIMUSANT_DIR} > ${CATSMAT_DIR}/Analysis/inc > ${CATSMAT_DIR}/Application > ${CATSMAT_DIR}/CounterpointAnalysis/inc > ${CATSMAT_DIR}/GeneralAnalysis/inc > ${CATSMAT_DIR}/Segmentation > ${CATSMAT_DIR}/Segmentation/FixedPeriodDetection/inc > ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/inc > ${CATSMAT_DIR}/Utilities > ${libIMUSANT_DIR}/DomainObjects/inc > ${libIMUSANT_DIR}/Utilities/inc > ${libIMUSANT_DIR}/FileProcessing/inc > ${libIMUSANT_DIR}/Converters/MusicXML_v3 > ${libIMUSANT_DIR}/Converters/MusicXML_v3/inc > ${libIMUSANT_DIR}/Converters/MusicXML_v3/shared/inc > ${IMUSANT_DIR}/DomainObjects/inc > ${IMUSANT_DIR}/Converters/MusicXML_v3 > ${IMUSANT_DIR}/Converters/MusicXML_v3/inc > ${IMUSANT_DIR}/Converters/Shared/inc > ${IMUSANT_DIR}/FileProcessing/inc > ${IMUSANT_DIR}/FileProcessing/Analysis/Segmentation/FixedPeriodDetection/ > ${IMUSANT_DIR}/Utilities/inc > ${SUFFIXTREE_DIR} > ${LIBMUSICXML_DIR}/libmusicxml-3.00-src/src > ${LIBMUSICXML_DIR}/libmusicxml-3.00-src/src/lib > ${LIBMUSICXML_DIR}/libmusicxml-3.00-src/src/visitors > ${LIBMUSICXML_DIR}/libmusicxml-3.00-src/src/parser > ${LOKI_DIR} > ${SUFFIX_TREE_DIR} > ${GOOGLE_TEST_INC_DIR} > ) > > > #foreach(folder ${SRCFOLDERS}) > # set(SRC ${SRC} "${folder}/*.cpp") # add source files > #endforeach(folder) > #file (GLOB CORESRC RELATIVE ${CMAKE_CURRENT_SOURCE_DIR} ${SRC}) > > > > ## is this necessary I think target link directories might do the job ? > > foreach(folder ${INCFOLDERS}) > set(HEADERS ${HEADERS} "${folder}/*.h") # add header files > set(INCL ${INCL} "${folder}") # add include folders > endforeach(folder) > file (GLOB COREH RELATIVE ${CMAKE_CURRENT_SOURCE_DIR} ${HEADERS}) > > > ####################################### > # set includes ( is this needed ? ) > include_directories( ${INCFOLDERS}) > set_source_files_properties (${COREH} PROPERTIES HEADER_FILE_ONLY TRUE) > > > ####################################### > # set library target > > #if(APPLE OR MSVC) > > set(target catsmat) > > # I don't know why these if statements are included they seem to do nothing ' > #else(APPLE OR MSVC) > # set(target catsmat) > #endif(APPLE OR MSVC) > > ##if(MSVC) > ## enable_language(RC) > ## set(LIBCONTENT ${CORESRC} ${COREH} > ${CATSMAT_DIR}/win32/libIMUSANT/libIMUSANT.rc) > ##else(MSVC) > ## set(LIBCONTENT ${CORESRC} ${COREH}) > ##endif(MSVC) > > add_executable(${target} ${SRC} ) > > #### add include directories > include_directories ( ${INCFOLDERS} ) > > ############### Targeted Libraries ########### > > TARGET_LINK_LIBRARIES(${target} gtest) > TARGET_LINK_LIBRARIES(${target} ${BOOST_FILESYSTEM_LIB}) > TARGET_LINK_LIBRARIES(${target} ${BOOST_SYSTEM_LIB}) > TARGET_LINK_LIBRARIES(${target} libmusicxml2) > TARGET_LINK_LIBRARIES(${target} libIMUSANT) > > > set_target_properties (${target} PROPERTIES > FRAMEWORK TRUE > VERSION ${VERSION} > C_STANDARD 99 > FRAMEWORK_VERSION ${VERSION} > PUBLIC_HEADER "${COREH}" > DEFINE_SYMBOL LIBMUSICXML_EXPORTS > MACOSX_FRAMEWORK_SHORT_VERSION_STRING ${STRVERS} > MACOSX_FRAMEWORK_BUNDLE_VERSION ${SSTRVERS} > ) > > > > ####################################### > # install setup > if(NOT APPLE) > install ( TARGETS ${target} ${TOOLS} > RUNTIME DESTINATION bin > LIBRARY DESTINATION lib > ARCHIVE DESTINATION lib > FRAMEWORK DESTINATION "/Library/Frameworks" CONFIGURATIONS Release > PUBLIC_HEADER DESTINATION include/libmusicxml > ) > endif(NOT APPLE) > > > > > > Hello Sean, Could you try adding a 'project(CATSTMAT)' call right at the top of your CMakeLists.txt? As well as setting a name for the project, this call also enables languages by default. HTH, Micha -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 525 bytes Desc: OpenPGP digital signature URL: From petr.kmoch at gmail.com Thu Jul 6 08:45:14 2017 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Thu, 6 Jul 2017 14:45:14 +0200 Subject: [CMake] Errors when writing manifest Message-ID: Hi all. I'm on Windows and I'm building my CMake project using MSVC. When I select Visual Studio as the CMake generator, everything works perfectly. However, when I use either the NMake or Ninja generator (in a properly configured command prompt), most of my DLL linking steps fail with the following error: C:/Program Files (x86)/Windows Kits/8.1/bin/x64/mt.exe : general error c101008d: Failed to write the updated manifest to the resource of file "path\to\the.dll". The operation failed. Re-running the exact same command (`nmake` or `ninja`) without doing anything else occasionally solves the problem (it seemed to me it was solved more often with NMake than with Ninja, but I can't be sure), but now I've reached a point where all remaining DLLs consistently fail to link due to the manifest issue. I'd be happy to try to debug/locate the issue myself, but since the error message I get is so wonderfully unhelpful, I don't know *how* to look into it, or even where to start. Would anyone have any ideas how to look what the issue could be? My googling came up with two possibilities: a race with an antivirus for checking the binary file, or write protection on the output directory. I've verified that the directory in not write-protected, and it's in a location which is excluded from AV checks. And anyway, if either of these were the cause, I'd expect the exact same errors when using the Visual Studio IDE to build, but such errors *never* happen there. Any ideas? Petr -------------- next part -------------- An HTML attachment was scrubbed... URL: From seanwayland at gmail.com Thu Jul 6 09:59:16 2017 From: seanwayland at gmail.com (Sean Wayland) Date: Thu, 6 Jul 2017 09:59:16 -0400 Subject: [CMake] cmake create executable Undefined symbols for architecture x86_64: In-Reply-To: <14d703d8-bfa9-2bbc-4ca5-e251ece61b92@gmail.com> References: <14d703d8-bfa9-2bbc-4ca5-e251ece61b92@gmail.com> Message-ID: Hi Micha, Thanks very much I tried that .. I added it to the application directory cmakelists.txt file . Same issue .. It's already in the top level cmake file which looks like this .. project(CATSMAT) cmake_minimum_required(VERSION 3.6.3) if (APPLE) set(CMAKE_C++_FLAGS -mmacosx-version-min=10.4) endif (APPLE) include_directories("catsmat/libIMUSANT") add_subdirectory (catsmat/googletest-master/googletest) add_subdirectory (catsmat/libMusicXMLv3/libmusicxml-3.00-src/cmake) add_subdirectory (catsmat/libIMUSANT/cmake) add_subdirectory (catsmat/libIMUSANT_Tests/cmake) add_subdirectory (catsmat/catsmat/cmake) set(CMAKE_CXX_STANDARD 14) On Thu, Jul 6, 2017 at 2:48 AM, Micha Hergarden wrote: > On 05-07-17 22:50, Sean Wayland wrote: >> I am attempting to write a cmakelists.txt file for an application. >> The application has a couple of dependencies. >> I have been able to build targets for the dependencies but when I try >> and add an executable for the main application I encounter this error. >> >> Undefined symbols for architecture x86_64: >> >> "_main", referenced from: >> >> implicit entry/start for main executable >> >> ld: symbol(s) not found for architecture x86_64 >> >> clang: error: linker command failed with exit code 1 (use -v to see invocation) >> >> >> Googling the error and looking on stack exchange suggests that I don't >> have a main function in the implicit entry/start . >> >> Where does it look for this function ? >> Does that file need to be first in the list of sources ? >> >> >> >> This function is included here : >> ${CATSMAT_DIR}/Application/CATSMAT_main.cpp >> >> My cmake file is below. >> >> Any advice would be appreciated I have been stuck here for a while! >> >> Best Sean >> >> >> ####################################### >> # CMAKE CATSTMAT >> ####################################### >> cmake_minimum_required(VERSION 3.6.3) >> set(CMAKE_CXX_STANDARD 14) >> if(CMAKE_CONFIGURATION_TYPES) >> set(CMAKE_CONFIGURATION_TYPES Debug Release) >> endif() >> >> if(UNIX) >> add_definitions(-Wall -DGCC) >> endif(UNIX) >> >> ##### RPATH SETTING ##### >> set(CMAKE_MACOSX_RPATH 1) >> >> #if(APPLE) >> # set (CMAKE_OSX_ARCHITECTURES "x86_64 i386") >> # if (${CMAKE_SYSTEM_VERSION} VERSION_LESS 9.0.0) >> # set (CMAKE_OSX_SYSROOT /Developer/SDKs/MacOSX10.4u.sdk) >> # elseif (${CMAKE_SYSTEM_VERSION} VERSION_LESS 10.8.0) >> # set (CMAKE_OSX_SYSROOT /Developer/SDKs/MacOSX10.5.sdk) >> # elseif (${XCODE_VERSION} VERSION_LESS 4.0.0) >> # set (CMAKE_OSX_SYSROOT /Developer/SDKs/MacOSX10.6.sdk) >> # else () >> # set (CMAKE_OSX_SYSROOT "macosx10.7") >> # endif () >> # set (CMAKE_C++_FLAGS -mmacosx-version-min=10.4) >> #endif(APPLE) >> # >> #if(WIN32) >> # add_definitions(-DWINVER=0x0400 -DWIN32) >> # if(${CMAKE_GENERATOR} STREQUAL "Visual Studio 6") >> # add_definitions(-DVC6) >> # elseif(${CMAKE_GENERATOR} STREQUAL "Visual Studio 8 2005") >> # add_definitions(-DVC2005) >> # endif(${CMAKE_GENERATOR} STREQUAL "Visual Studio 6") >> #endif(WIN32) >> >> ############### BOOST LIBRARIES ########### >> if (APPLE) >> set(BOOST_ROOT "/usr/local/boost") >> set(BOOST_FILESYSTEM_LIB /usr/local/boost/lib/libboost_filesystem.dylib) >> set(BOOST_SYSTEM_LIB /usr/local/boost/lib/libboost_system.dylib) >> >> else (NOT APPLE) >> set(BOOST_ROOT "C:/local/boost_1_58_0") >> set(BOOST_FILESYSTEM_LIB C:/local/boost_1_58_0/lib64-msvc-12.0) >> set(BOOST_SYSTEM_LIB C:/local/boost_1_58_0/lib64-msvc-12.0) >> endif (APPLE) >> >> FIND_PACKAGE( Boost 1.58.0 REQUIRED ) >> INCLUDE_DIRECTORIES( ${Boost_INCLUDE_DIR} ) >> >> >> ####################################### >> # set directories, src and headers. >> >> set (CATSMAT_DIR /Users/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat ) >> set (libIMUSANT_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../../libIMUSANT) >> set (LOKI_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../../Loki) >> set (SUFFIX_TREE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../../SuffixTree) >> set (GOOGLE_TEST_INC_DIR >> ${CMAKE_CURRENT_SOURCE_DIR}/../../googletest-master/googletest/include) >> set (IMUSANT_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../../libIMUSANT) >> >> >> set (LIBMUSICXML_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../../libMusicXMLv3) >> >> >> #### SET SOURCES EXPLICITLY ##### >> >> set(SRC >> >> ${CATSMAT_DIR}/Analysis/src/IMUSANT_contour_suffixtree_builder.cpp >> ${CATSMAT_DIR}/Analysis/src/IMUSANT_generalised_interval_suffixtree_builder.cpp >> ${CATSMAT_DIR}/Analysis/src/IMUSANT_interval_suffixtree_builder.cpp >> ${CATSMAT_DIR}/Analysis/src/IMUSANT_pitch_suffixtree_builder.cpp >> ${CATSMAT_DIR}/Analysis/src/IMUSANT_repeated_interval_substring.cpp >> ${CATSMAT_DIR}/Analysis/src/IMUSANT_t_repeated_substring.cpp >> ${CATSMAT_DIR}/Analysis/src/IMUSANT_VectorMapAnalysisTypes.cpp >> >> ${CATSMAT_DIR}/Application/CATSMAT_main.cpp >> ${CATSMAT_DIR}/Application/CATSMAT_menu.cpp >> >> ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_chord.cpp >> ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_collectionvisitor.cpp >> ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_cp_matrix.cpp >> ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_dyad_sequences.cpp >> ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_dyadtuple_sequences.cpp >> ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_sonority_sequences.cpp >> ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_TrigramSequences.cpp >> ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_TrigramSuffixTreeBuilder.cpp >> >> ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_canonic_techniques_tools.cpp >> ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_partdata.cpp >> ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_processing.cpp >> ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_score_profile.tpp >> ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_score_splitter.cpp >> ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_score_profile_special.cpp >> ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_scoredata.cpp >> ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_scoredatacollector.cpp >> >> ${CATSMAT_DIR}/Segmentation/IMUSANT_segment.cpp >> ${CATSMAT_DIR}/Segmentation/IMUSANT_set_of_segment.cpp >> >> ${CATSMAT_DIR}/Segmentation/FixedPeriodDetection/src/IMUSANT_fixed_period_segmenter.cpp >> ${CATSMAT_DIR}/Segmentation/FixedPeriodDetection/src/IMUSANT_partlist_ordered_by_part_entry.cpp >> ${CATSMAT_DIR}/Segmentation/FixedPeriodDetection/src/IMUSANT_segmented_part_fixed_period.cpp >> ${CATSMAT_DIR}/Segmentation/FixedPeriodDetection/src/SegmentedScoreFixedPeriod.cpp >> >> ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src/IMUSANT_interval_profile_LBDM.cpp >> ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src/IMUSANT_LBDM_segmenter.cpp >> ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src/IMUSANT_segmented_note_vectors.cpp >> ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src/IMUSANT_segmented_part_LBDM.cpp >> ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src/IMUSANT_segmented_profile_vectors.cpp >> ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src/IMUSANT_weighted_strength_vectors.cpp >> >> >> >> >> ) >> >> >> >> >> # old version of adding source code >> >> #set (SRCFOLDERS >> >> >> # ${CATSMAT_DIR}/Analysis/src >> # ${CATSMAT_DIR}/CounterpointAnalysis/src >> # ${CATSMAT_DIR}/GeneralAnalysis/src >> # ${CATSMAT_DIR}/Segmentation/FixedPeriodDetection/src >> # ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src >> # ${CATSMAT_DIR}/Application >> # ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src >> # ${CATSMAT_DIR}/Segmentation >> # ${CATSMAT_DIR}/Utilities >> #) >> >> >> set (INCFOLDERS >> ${libIMUSANT_DIR} >> ${CATSMAT_DIR}/Analysis/inc >> ${CATSMAT_DIR}/Application >> ${CATSMAT_DIR}/CounterpointAnalysis/inc >> ${CATSMAT_DIR}/GeneralAnalysis/inc >> ${CATSMAT_DIR}/Segmentation >> ${CATSMAT_DIR}/Segmentation/FixedPeriodDetection/inc >> ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/inc >> ${CATSMAT_DIR}/Utilities >> ${libIMUSANT_DIR}/DomainObjects/inc >> ${libIMUSANT_DIR}/Utilities/inc >> ${libIMUSANT_DIR}/FileProcessing/inc >> ${libIMUSANT_DIR}/Converters/MusicXML_v3 >> ${libIMUSANT_DIR}/Converters/MusicXML_v3/inc >> ${libIMUSANT_DIR}/Converters/MusicXML_v3/shared/inc >> ${IMUSANT_DIR}/DomainObjects/inc >> ${IMUSANT_DIR}/Converters/MusicXML_v3 >> ${IMUSANT_DIR}/Converters/MusicXML_v3/inc >> ${IMUSANT_DIR}/Converters/Shared/inc >> ${IMUSANT_DIR}/FileProcessing/inc >> ${IMUSANT_DIR}/FileProcessing/Analysis/Segmentation/FixedPeriodDetection/ >> ${IMUSANT_DIR}/Utilities/inc >> ${SUFFIXTREE_DIR} >> ${LIBMUSICXML_DIR}/libmusicxml-3.00-src/src >> ${LIBMUSICXML_DIR}/libmusicxml-3.00-src/src/lib >> ${LIBMUSICXML_DIR}/libmusicxml-3.00-src/src/visitors >> ${LIBMUSICXML_DIR}/libmusicxml-3.00-src/src/parser >> ${LOKI_DIR} >> ${SUFFIX_TREE_DIR} >> ${GOOGLE_TEST_INC_DIR} >> ) >> >> >> #foreach(folder ${SRCFOLDERS}) >> # set(SRC ${SRC} "${folder}/*.cpp") # add source files >> #endforeach(folder) >> #file (GLOB CORESRC RELATIVE ${CMAKE_CURRENT_SOURCE_DIR} ${SRC}) >> >> >> >> ## is this necessary I think target link directories might do the job ? >> >> foreach(folder ${INCFOLDERS}) >> set(HEADERS ${HEADERS} "${folder}/*.h") # add header files >> set(INCL ${INCL} "${folder}") # add include folders >> endforeach(folder) >> file (GLOB COREH RELATIVE ${CMAKE_CURRENT_SOURCE_DIR} ${HEADERS}) >> >> >> ####################################### >> # set includes ( is this needed ? ) >> include_directories( ${INCFOLDERS}) >> set_source_files_properties (${COREH} PROPERTIES HEADER_FILE_ONLY TRUE) >> >> >> ####################################### >> # set library target >> >> #if(APPLE OR MSVC) >> >> set(target catsmat) >> >> # I don't know why these if statements are included they seem to do nothing ' >> #else(APPLE OR MSVC) >> # set(target catsmat) >> #endif(APPLE OR MSVC) >> >> ##if(MSVC) >> ## enable_language(RC) >> ## set(LIBCONTENT ${CORESRC} ${COREH} >> ${CATSMAT_DIR}/win32/libIMUSANT/libIMUSANT.rc) >> ##else(MSVC) >> ## set(LIBCONTENT ${CORESRC} ${COREH}) >> ##endif(MSVC) >> >> add_executable(${target} ${SRC} ) >> >> #### add include directories >> include_directories ( ${INCFOLDERS} ) >> >> ############### Targeted Libraries ########### >> >> TARGET_LINK_LIBRARIES(${target} gtest) >> TARGET_LINK_LIBRARIES(${target} ${BOOST_FILESYSTEM_LIB}) >> TARGET_LINK_LIBRARIES(${target} ${BOOST_SYSTEM_LIB}) >> TARGET_LINK_LIBRARIES(${target} libmusicxml2) >> TARGET_LINK_LIBRARIES(${target} libIMUSANT) >> >> >> set_target_properties (${target} PROPERTIES >> FRAMEWORK TRUE >> VERSION ${VERSION} >> C_STANDARD 99 >> FRAMEWORK_VERSION ${VERSION} >> PUBLIC_HEADER "${COREH}" >> DEFINE_SYMBOL LIBMUSICXML_EXPORTS >> MACOSX_FRAMEWORK_SHORT_VERSION_STRING ${STRVERS} >> MACOSX_FRAMEWORK_BUNDLE_VERSION ${SSTRVERS} >> ) >> >> >> >> ####################################### >> # install setup >> if(NOT APPLE) >> install ( TARGETS ${target} ${TOOLS} >> RUNTIME DESTINATION bin >> LIBRARY DESTINATION lib >> ARCHIVE DESTINATION lib >> FRAMEWORK DESTINATION "/Library/Frameworks" CONFIGURATIONS Release >> PUBLIC_HEADER DESTINATION include/libmusicxml >> ) >> endif(NOT APPLE) >> >> >> >> >> >> > Hello Sean, > > Could you try adding a 'project(CATSTMAT)' call right at the top of your > CMakeLists.txt? As well as setting a name for the project, this call > also enables languages by default. > > HTH, > Micha > > > > -- > > 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 -- www.seanwayland.com Sean Wayland licensed real estate salesperson phone: 3475231455 From robert.maynard at kitware.com Thu Jul 6 10:11:32 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 6 Jul 2017 10:11:32 -0400 Subject: [CMake] Enhanced version management for the command "project" In-Reply-To: References: <55E5640C.7060401@users.sourceforge.net> Message-ID: Hi, These kind of conversations are better suited to the CMake Developers Mailing List. ( https://cmake.org/mailing-lists/ ) On Sat, Jul 1, 2017 at 1:33 PM, SF Markus Elfring wrote: > Hello, > > CMake provides an interface for the specification of version information > by the command "project". > https://cmake.org/cmake/help/v3.9/command/project.html > > Can it be extended a bit more? > > 1. How do you think about to preserve a software release tag there? > > 2. Software packages can often evolve and deviate from the specified version > numbers after the moment they were copied to an useful location. > Would you like to distinguish the extensions to a base version > by any additional data (like a commit hash or revision identifier) > from a content management system? > > Regards, > Markus > -- > > 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 micha.hergarden at gmail.com Thu Jul 6 15:12:54 2017 From: micha.hergarden at gmail.com (Micha Hergarden) Date: Thu, 6 Jul 2017 21:12:54 +0200 Subject: [CMake] cmake create executable Undefined symbols for architecture x86_64: In-Reply-To: References: <14d703d8-bfa9-2bbc-4ca5-e251ece61b92@gmail.com> Message-ID: <466bb2e6-1603-c860-e99b-4642b847f425@gmail.com> On 06-07-17 15:59, Sean Wayland wrote: > Hi Micha, > Thanks very much I tried that .. I added it to the application > directory cmakelists.txt file . Same issue .. It's already in the top > level cmake file which looks like this .. > > project(CATSMAT) > cmake_minimum_required(VERSION 3.6.3) > > > if (APPLE) > > set(CMAKE_C++_FLAGS -mmacosx-version-min=10.4) > endif (APPLE) > > > include_directories("catsmat/libIMUSANT") > > add_subdirectory (catsmat/googletest-master/googletest) > add_subdirectory (catsmat/libMusicXMLv3/libmusicxml-3.00-src/cmake) > add_subdirectory (catsmat/libIMUSANT/cmake) > add_subdirectory (catsmat/libIMUSANT_Tests/cmake) > add_subdirectory (catsmat/catsmat/cmake) > > set(CMAKE_CXX_STANDARD 14) > > On Thu, Jul 6, 2017 at 2:48 AM, Micha Hergarden > wrote: >> On 05-07-17 22:50, Sean Wayland wrote: >>> I am attempting to write a cmakelists.txt file for an application. >>> The application has a couple of dependencies. >>> I have been able to build targets for the dependencies but when I try >>> and add an executable for the main application I encounter this error. >>> >>> Undefined symbols for architecture x86_64: >>> >>> "_main", referenced from: >>> >>> implicit entry/start for main executable >>> >>> ld: symbol(s) not found for architecture x86_64 >>> >>> clang: error: linker command failed with exit code 1 (use -v to see invocation) >>> >>> >>> Googling the error and looking on stack exchange suggests that I don't >>> have a main function in the implicit entry/start . >>> >>> Where does it look for this function ? >>> Does that file need to be first in the list of sources ? >>> >>> >>> >>> This function is included here : >>> ${CATSMAT_DIR}/Application/CATSMAT_main.cpp >>> >>> My cmake file is below. >>> >>> Any advice would be appreciated I have been stuck here for a while! >>> >>> Best Sean >>> >>> >>> ####################################### >>> # CMAKE CATSTMAT >>> ####################################### >>> cmake_minimum_required(VERSION 3.6.3) >>> set(CMAKE_CXX_STANDARD 14) >>> if(CMAKE_CONFIGURATION_TYPES) >>> set(CMAKE_CONFIGURATION_TYPES Debug Release) >>> endif() >>> >>> if(UNIX) >>> add_definitions(-Wall -DGCC) >>> endif(UNIX) >>> >>> ##### RPATH SETTING ##### >>> set(CMAKE_MACOSX_RPATH 1) >>> >>> #if(APPLE) >>> # set (CMAKE_OSX_ARCHITECTURES "x86_64 i386") >>> # if (${CMAKE_SYSTEM_VERSION} VERSION_LESS 9.0.0) >>> # set (CMAKE_OSX_SYSROOT /Developer/SDKs/MacOSX10.4u.sdk) >>> # elseif (${CMAKE_SYSTEM_VERSION} VERSION_LESS 10.8.0) >>> # set (CMAKE_OSX_SYSROOT /Developer/SDKs/MacOSX10.5.sdk) >>> # elseif (${XCODE_VERSION} VERSION_LESS 4.0.0) >>> # set (CMAKE_OSX_SYSROOT /Developer/SDKs/MacOSX10.6.sdk) >>> # else () >>> # set (CMAKE_OSX_SYSROOT "macosx10.7") >>> # endif () >>> # set (CMAKE_C++_FLAGS -mmacosx-version-min=10.4) >>> #endif(APPLE) >>> # >>> #if(WIN32) >>> # add_definitions(-DWINVER=0x0400 -DWIN32) >>> # if(${CMAKE_GENERATOR} STREQUAL "Visual Studio 6") >>> # add_definitions(-DVC6) >>> # elseif(${CMAKE_GENERATOR} STREQUAL "Visual Studio 8 2005") >>> # add_definitions(-DVC2005) >>> # endif(${CMAKE_GENERATOR} STREQUAL "Visual Studio 6") >>> #endif(WIN32) >>> >>> ############### BOOST LIBRARIES ########### >>> if (APPLE) >>> set(BOOST_ROOT "/usr/local/boost") >>> set(BOOST_FILESYSTEM_LIB /usr/local/boost/lib/libboost_filesystem.dylib) >>> set(BOOST_SYSTEM_LIB /usr/local/boost/lib/libboost_system.dylib) >>> >>> else (NOT APPLE) >>> set(BOOST_ROOT "C:/local/boost_1_58_0") >>> set(BOOST_FILESYSTEM_LIB C:/local/boost_1_58_0/lib64-msvc-12.0) >>> set(BOOST_SYSTEM_LIB C:/local/boost_1_58_0/lib64-msvc-12.0) >>> endif (APPLE) >>> >>> FIND_PACKAGE( Boost 1.58.0 REQUIRED ) >>> INCLUDE_DIRECTORIES( ${Boost_INCLUDE_DIR} ) >>> >>> >>> ####################################### >>> # set directories, src and headers. >>> >>> set (CATSMAT_DIR /Users/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat ) >>> set (libIMUSANT_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../../libIMUSANT) >>> set (LOKI_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../../Loki) >>> set (SUFFIX_TREE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../../SuffixTree) >>> set (GOOGLE_TEST_INC_DIR >>> ${CMAKE_CURRENT_SOURCE_DIR}/../../googletest-master/googletest/include) >>> set (IMUSANT_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../../libIMUSANT) >>> >>> >>> set (LIBMUSICXML_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../../libMusicXMLv3) >>> >>> >>> #### SET SOURCES EXPLICITLY ##### >>> >>> set(SRC >>> >>> ${CATSMAT_DIR}/Analysis/src/IMUSANT_contour_suffixtree_builder.cpp >>> ${CATSMAT_DIR}/Analysis/src/IMUSANT_generalised_interval_suffixtree_builder.cpp >>> ${CATSMAT_DIR}/Analysis/src/IMUSANT_interval_suffixtree_builder.cpp >>> ${CATSMAT_DIR}/Analysis/src/IMUSANT_pitch_suffixtree_builder.cpp >>> ${CATSMAT_DIR}/Analysis/src/IMUSANT_repeated_interval_substring.cpp >>> ${CATSMAT_DIR}/Analysis/src/IMUSANT_t_repeated_substring.cpp >>> ${CATSMAT_DIR}/Analysis/src/IMUSANT_VectorMapAnalysisTypes.cpp >>> >>> ${CATSMAT_DIR}/Application/CATSMAT_main.cpp >>> ${CATSMAT_DIR}/Application/CATSMAT_menu.cpp >>> >>> ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_chord.cpp >>> ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_collectionvisitor.cpp >>> ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_cp_matrix.cpp >>> ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_dyad_sequences.cpp >>> ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_dyadtuple_sequences.cpp >>> ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_sonority_sequences.cpp >>> ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_TrigramSequences.cpp >>> ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_TrigramSuffixTreeBuilder.cpp >>> >>> ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_canonic_techniques_tools.cpp >>> ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_partdata.cpp >>> ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_processing.cpp >>> ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_score_profile.tpp >>> ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_score_splitter.cpp >>> ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_score_profile_special.cpp >>> ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_scoredata.cpp >>> ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_scoredatacollector.cpp >>> >>> ${CATSMAT_DIR}/Segmentation/IMUSANT_segment.cpp >>> ${CATSMAT_DIR}/Segmentation/IMUSANT_set_of_segment.cpp >>> >>> ${CATSMAT_DIR}/Segmentation/FixedPeriodDetection/src/IMUSANT_fixed_period_segmenter.cpp >>> ${CATSMAT_DIR}/Segmentation/FixedPeriodDetection/src/IMUSANT_partlist_ordered_by_part_entry.cpp >>> ${CATSMAT_DIR}/Segmentation/FixedPeriodDetection/src/IMUSANT_segmented_part_fixed_period.cpp >>> ${CATSMAT_DIR}/Segmentation/FixedPeriodDetection/src/SegmentedScoreFixedPeriod.cpp >>> >>> ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src/IMUSANT_interval_profile_LBDM.cpp >>> ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src/IMUSANT_LBDM_segmenter.cpp >>> ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src/IMUSANT_segmented_note_vectors.cpp >>> ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src/IMUSANT_segmented_part_LBDM.cpp >>> ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src/IMUSANT_segmented_profile_vectors.cpp >>> ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src/IMUSANT_weighted_strength_vectors.cpp >>> >>> >>> >>> >>> ) >>> >>> >>> >>> >>> # old version of adding source code >>> >>> #set (SRCFOLDERS >>> >>> >>> # ${CATSMAT_DIR}/Analysis/src >>> # ${CATSMAT_DIR}/CounterpointAnalysis/src >>> # ${CATSMAT_DIR}/GeneralAnalysis/src >>> # ${CATSMAT_DIR}/Segmentation/FixedPeriodDetection/src >>> # ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src >>> # ${CATSMAT_DIR}/Application >>> # ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src >>> # ${CATSMAT_DIR}/Segmentation >>> # ${CATSMAT_DIR}/Utilities >>> #) >>> >>> >>> set (INCFOLDERS >>> ${libIMUSANT_DIR} >>> ${CATSMAT_DIR}/Analysis/inc >>> ${CATSMAT_DIR}/Application >>> ${CATSMAT_DIR}/CounterpointAnalysis/inc >>> ${CATSMAT_DIR}/GeneralAnalysis/inc >>> ${CATSMAT_DIR}/Segmentation >>> ${CATSMAT_DIR}/Segmentation/FixedPeriodDetection/inc >>> ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/inc >>> ${CATSMAT_DIR}/Utilities >>> ${libIMUSANT_DIR}/DomainObjects/inc >>> ${libIMUSANT_DIR}/Utilities/inc >>> ${libIMUSANT_DIR}/FileProcessing/inc >>> ${libIMUSANT_DIR}/Converters/MusicXML_v3 >>> ${libIMUSANT_DIR}/Converters/MusicXML_v3/inc >>> ${libIMUSANT_DIR}/Converters/MusicXML_v3/shared/inc >>> ${IMUSANT_DIR}/DomainObjects/inc >>> ${IMUSANT_DIR}/Converters/MusicXML_v3 >>> ${IMUSANT_DIR}/Converters/MusicXML_v3/inc >>> ${IMUSANT_DIR}/Converters/Shared/inc >>> ${IMUSANT_DIR}/FileProcessing/inc >>> ${IMUSANT_DIR}/FileProcessing/Analysis/Segmentation/FixedPeriodDetection/ >>> ${IMUSANT_DIR}/Utilities/inc >>> ${SUFFIXTREE_DIR} >>> ${LIBMUSICXML_DIR}/libmusicxml-3.00-src/src >>> ${LIBMUSICXML_DIR}/libmusicxml-3.00-src/src/lib >>> ${LIBMUSICXML_DIR}/libmusicxml-3.00-src/src/visitors >>> ${LIBMUSICXML_DIR}/libmusicxml-3.00-src/src/parser >>> ${LOKI_DIR} >>> ${SUFFIX_TREE_DIR} >>> ${GOOGLE_TEST_INC_DIR} >>> ) >>> >>> >>> #foreach(folder ${SRCFOLDERS}) >>> # set(SRC ${SRC} "${folder}/*.cpp") # add source files >>> #endforeach(folder) >>> #file (GLOB CORESRC RELATIVE ${CMAKE_CURRENT_SOURCE_DIR} ${SRC}) >>> >>> >>> >>> ## is this necessary I think target link directories might do the job ? >>> >>> foreach(folder ${INCFOLDERS}) >>> set(HEADERS ${HEADERS} "${folder}/*.h") # add header files >>> set(INCL ${INCL} "${folder}") # add include folders >>> endforeach(folder) >>> file (GLOB COREH RELATIVE ${CMAKE_CURRENT_SOURCE_DIR} ${HEADERS}) >>> >>> >>> ####################################### >>> # set includes ( is this needed ? ) >>> include_directories( ${INCFOLDERS}) >>> set_source_files_properties (${COREH} PROPERTIES HEADER_FILE_ONLY TRUE) >>> >>> >>> ####################################### >>> # set library target >>> >>> #if(APPLE OR MSVC) >>> >>> set(target catsmat) >>> >>> # I don't know why these if statements are included they seem to do nothing ' >>> #else(APPLE OR MSVC) >>> # set(target catsmat) >>> #endif(APPLE OR MSVC) >>> >>> ##if(MSVC) >>> ## enable_language(RC) >>> ## set(LIBCONTENT ${CORESRC} ${COREH} >>> ${CATSMAT_DIR}/win32/libIMUSANT/libIMUSANT.rc) >>> ##else(MSVC) >>> ## set(LIBCONTENT ${CORESRC} ${COREH}) >>> ##endif(MSVC) >>> >>> add_executable(${target} ${SRC} ) >>> >>> #### add include directories >>> include_directories ( ${INCFOLDERS} ) >>> >>> ############### Targeted Libraries ########### >>> >>> TARGET_LINK_LIBRARIES(${target} gtest) >>> TARGET_LINK_LIBRARIES(${target} ${BOOST_FILESYSTEM_LIB}) >>> TARGET_LINK_LIBRARIES(${target} ${BOOST_SYSTEM_LIB}) >>> TARGET_LINK_LIBRARIES(${target} libmusicxml2) >>> TARGET_LINK_LIBRARIES(${target} libIMUSANT) >>> >>> >>> set_target_properties (${target} PROPERTIES >>> FRAMEWORK TRUE >>> VERSION ${VERSION} >>> C_STANDARD 99 >>> FRAMEWORK_VERSION ${VERSION} >>> PUBLIC_HEADER "${COREH}" >>> DEFINE_SYMBOL LIBMUSICXML_EXPORTS >>> MACOSX_FRAMEWORK_SHORT_VERSION_STRING ${STRVERS} >>> MACOSX_FRAMEWORK_BUNDLE_VERSION ${SSTRVERS} >>> ) >>> >>> >>> >>> ####################################### >>> # install setup >>> if(NOT APPLE) >>> install ( TARGETS ${target} ${TOOLS} >>> RUNTIME DESTINATION bin >>> LIBRARY DESTINATION lib >>> ARCHIVE DESTINATION lib >>> FRAMEWORK DESTINATION "/Library/Frameworks" CONFIGURATIONS Release >>> PUBLIC_HEADER DESTINATION include/libmusicxml >>> ) >>> endif(NOT APPLE) >>> >>> >>> >>> >>> >>> >> Hello Sean, >> >> Could you try adding a 'project(CATSTMAT)' call right at the top of your >> CMakeLists.txt? As well as setting a name for the project, this call >> also enables languages by default. >> >> HTH, >> Micha >> >> >> >> -- >> >> 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 > > Hi Sean, I'm also a bit confused as you seem to set 'C_STANDARD 99' as a property for the target, as well as 'set(CMAKE_CXX_STANDARD 14)'. I don't know if these two settings interfere with each other. Could you remove one of the two as an experiment? Regards, Micha -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 525 bytes Desc: OpenPGP digital signature URL: From mike.jackson at bluequartz.net Thu Jul 6 16:00:04 2017 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Thu, 06 Jul 2017 16:00:04 -0400 Subject: [CMake] Parallel moc for Qt files Message-ID: <595E96C4.90209@bluequartz.net> I have a large list of files that need to have Qt's 'moc' run on them (107 headers). I use all the normal CMake facilities for Qt based projects. I noticed that the generation of the moc files are done serially. Is there a flag or anything that I can use to run the generation in Parallel? I ask because each file takes about 3 seconds to run through moc. The code is heavily C++ templated which I think causes 'moc' to run more slowly. We have other places in the code where 'moc' must run and it does each file in the "blink of an eye". Just curious. -- Michael A. Jackson BlueQuartz Software, LLC [e]: mike.jackson at bluequartz.net From cristian.adam at gmail.com Thu Jul 6 18:11:50 2017 From: cristian.adam at gmail.com (Cristian Adam) Date: Fri, 7 Jul 2017 00:11:50 +0200 Subject: [CMake] Parallel moc for Qt files In-Reply-To: <595E96C4.90209@bluequartz.net> References: <595E96C4.90209@bluequartz.net> Message-ID: On Thu, Jul 6, 2017 at 10:00 PM, Michael Jackson < mike.jackson at bluequartz.net> wrote: > I have a large list of files that need to have Qt's 'moc' run on them (107 > headers). I use all the normal CMake facilities for Qt based projects. I > noticed that the generation of the moc files are done serially. Is there a > flag or anything that I can use to run the generation in Parallel? I ask > because each file takes about 3 seconds to run through moc. The code is > heavily C++ templated which I think causes 'moc' to run more slowly. We > have other places in the code where 'moc' must run and it does each file in > the "blink of an eye". > > Just curious. > > Have you tried removing moc altogether using Verdigris ? I'm curious how this would speed up your compilation time. Cheers, Cristian. -------------- next part -------------- An HTML attachment was scrubbed... URL: From seanwayland at gmail.com Thu Jul 6 23:14:25 2017 From: seanwayland at gmail.com (Sean Wayland) Date: Thu, 6 Jul 2017 23:14:25 -0400 Subject: [CMake] cmake create executable Undefined symbols for architecture x86_64: In-Reply-To: <466bb2e6-1603-c860-e99b-4642b847f425@gmail.com> References: <14d703d8-bfa9-2bbc-4ca5-e251ece61b92@gmail.com> <466bb2e6-1603-c860-e99b-4642b847f425@gmail.com> Message-ID: Hi Micha, Thanks very much for the email. That seemed to make a small difference! With both those lines commented out these errors are generated ( below my email ) . I still have included project(CATSMAT) at the top line of the cmake file in the catsmat directory I tried commenting out each of those language type definitions separately but it didn't seem to help. The code compiles under xcode. Those language types ( C++14) are specified in Xcode so I was trying to find a way to copy what is in xcode. Is there a maximum number of "errors" before the clion compiler will spit the dummy ? Another executable will compile with lots and lots of warnings but no "errors" I don't know much about C++ unfortunately. These errors look like simple errors which I could see might be generated if the syntax of the language had changed slightly from one version to the next .. Thanks for you help! Sean /Users/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat/cmake/../../libIMUSANT/DomainObjects/inc/IMUSANT_interval.h:78:14: error: ISO C++ forbids forward references to 'enum' types enum direction : int { descending=-1, repeat=0, ascending = 1, vertical_bottomtotop }; /Users/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat/cmake/../../libIMUSANT/DomainObjects/inc/IMUSANT_interval.h:78:30: error: expected '(' for function-style cast or type construction enum direction : int { descending=-1, repeat=0, ascending = 1, vertical_bottomtotop }; ~~~ ^ /Users/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat/cmake/../../libIMUSANT/DomainObjects/inc/IMUSANT_interval.h:78:24: error: field has incomplete type 'enum direction' enum direction : int { descending=-1, repeat=0, ascending = 1, vertical_bottomtotop }; /Users/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat/cmake/../../libIMUSANT/DomainObjects/inc/IMUSANT_interval.h:78:14: error: ISO C++ forbids forward references to 'enum' types enum direction : int { descending=-1, repeat=0, ascending = 1, vertical_bottomtotop }; ^ /Users/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat/cmake/../../libIMUSANT/DomainObjects/inc/IMUSANT_interval.h:78:30: error: expected '(' for function-style cast or type construction enum direction : int { descending=-1, repeat=0, ascending = 1, vertical_bottomtotop }; ~~~ ^ /Users/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat/cmake/../../libIMUSANT/DomainObjects/inc/IMUSANT_interval.h:78:24: error: field has incomplete type 'enum direction' enum direction : int { descending=-1, repeat=0, ascending = 1, vertical_bottomtotop }; ^ /Users/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat/cmake/../../libIMUSANT/DomainObjects/inc/IMUSANT_interval.h:78:14: note: forward declaration of 'IMUSANT::direction' enum direction : int { descending=-1, repeat=0, ascending = 1, vertical_bottomtotop }; ^ /Users/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat/cmake/../../libIMUSANT/DomainObjects/inc/IMUSANT_interval.h:80:14: error: ISO C++ forbids forward references to 'enum' types enum basic : int { unison = 0, second=1, third, fourth, fifth, sixth, seventh }; ^ /Users/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat/cmake/../../libIMUSANT/DomainObjects/inc/IMUSANT_interval.h:80:26: error: expected '(' for function-style cast or type construction enum basic : int { unison = 0, second=1, third, fourth, fifth, sixth, seventh }; ~~~ ^ /Users/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat/cmake/../../libIMUSANT/DomainObjects/inc/IMUSANT_interval.h:80:20: error: field has incomplete type 'enum basic' enum basic : int { unison = 0, second=1, third, fourth, fifth, sixth, seventh }; sers/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat/cmake/../../libIMUSANT/DomainObjects/inc/IMUSANT_interval.h:80:14: error: ISO C++ forbids forward references to 'enum' types enum basic : int { unison = 0, second=1, third, fourth, fifth, sixth, seventh }; ^ /Users/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat/cmake/../../libIMUSANT/DomainObjects/inc/IMUSANT_interval.h:80:26: error: expected '(' for function-style cast or type construction enum basic : int { unison = 0, second=1, third, fourth, fifth, sixth, seventh }; ~~~ ^ /Users/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat/cmake/../../libIMUSANT/DomainObjects/inc/IMUSANT_interval.h:80:20: error: field has incomplete type 'enum basic' enum basic : int { unison = 0, second=1, third, fourth, fifth, sixth, seventh }; /Users/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat/cmake/../../libIMUSANT/FileProcessing/inc/IMUSANT_processing.h:61:35: error: expected ';' at end of declaration list const char * what () const noexcept ^ ^ 22 warnings and 12 errors generated. make[3]: *** [catsmat/catsmat/cmake/CMakeFiles/catsmat.dir/__/Application/CATSMAT_main.cpp.o] Error 1 make[2]: *** [catsmat/catsmat/cmake/CMakeFiles/catsmat.dir/all] Error 2 make[1]: *** [catsmat/catsmat/cmake/CMakeFiles/catsmat.dir/rule] Error 2 On Thu, Jul 6, 2017 at 3:12 PM, Micha Hergarden wrote: > On 06-07-17 15:59, Sean Wayland wrote: >> Hi Micha, >> Thanks very much I tried that .. I added it to the application >> directory cmakelists.txt file . Same issue .. It's already in the top >> level cmake file which looks like this .. >> >> project(CATSMAT) >> cmake_minimum_required(VERSION 3.6.3) >> >> >> if (APPLE) >> >> set(CMAKE_C++_FLAGS -mmacosx-version-min=10.4) >> endif (APPLE) >> >> >> include_directories("catsmat/libIMUSANT") >> >> add_subdirectory (catsmat/googletest-master/googletest) >> add_subdirectory (catsmat/libMusicXMLv3/libmusicxml-3.00-src/cmake) >> add_subdirectory (catsmat/libIMUSANT/cmake) >> add_subdirectory (catsmat/libIMUSANT_Tests/cmake) >> add_subdirectory (catsmat/catsmat/cmake) >> >> set(CMAKE_CXX_STANDARD 14) >> >> On Thu, Jul 6, 2017 at 2:48 AM, Micha Hergarden >> wrote: >>> On 05-07-17 22:50, Sean Wayland wrote: >>>> I am attempting to write a cmakelists.txt file for an application. >>>> The application has a couple of dependencies. >>>> I have been able to build targets for the dependencies but when I try >>>> and add an executable for the main application I encounter this error. >>>> >>>> Undefined symbols for architecture x86_64: >>>> >>>> "_main", referenced from: >>>> >>>> implicit entry/start for main executable >>>> >>>> ld: symbol(s) not found for architecture x86_64 >>>> >>>> clang: error: linker command failed with exit code 1 (use -v to see invocation) >>>> >>>> >>>> Googling the error and looking on stack exchange suggests that I don't >>>> have a main function in the implicit entry/start . >>>> >>>> Where does it look for this function ? >>>> Does that file need to be first in the list of sources ? >>>> >>>> >>>> >>>> This function is included here : >>>> ${CATSMAT_DIR}/Application/CATSMAT_main.cpp >>>> >>>> My cmake file is below. >>>> >>>> Any advice would be appreciated I have been stuck here for a while! >>>> >>>> Best Sean >>>> >>>> >>>> ####################################### >>>> # CMAKE CATSTMAT >>>> ####################################### >>>> cmake_minimum_required(VERSION 3.6.3) >>>> set(CMAKE_CXX_STANDARD 14) >>>> if(CMAKE_CONFIGURATION_TYPES) >>>> set(CMAKE_CONFIGURATION_TYPES Debug Release) >>>> endif() >>>> >>>> if(UNIX) >>>> add_definitions(-Wall -DGCC) >>>> endif(UNIX) >>>> >>>> ##### RPATH SETTING ##### >>>> set(CMAKE_MACOSX_RPATH 1) >>>> >>>> #if(APPLE) >>>> # set (CMAKE_OSX_ARCHITECTURES "x86_64 i386") >>>> # if (${CMAKE_SYSTEM_VERSION} VERSION_LESS 9.0.0) >>>> # set (CMAKE_OSX_SYSROOT /Developer/SDKs/MacOSX10.4u.sdk) >>>> # elseif (${CMAKE_SYSTEM_VERSION} VERSION_LESS 10.8.0) >>>> # set (CMAKE_OSX_SYSROOT /Developer/SDKs/MacOSX10.5.sdk) >>>> # elseif (${XCODE_VERSION} VERSION_LESS 4.0.0) >>>> # set (CMAKE_OSX_SYSROOT /Developer/SDKs/MacOSX10.6.sdk) >>>> # else () >>>> # set (CMAKE_OSX_SYSROOT "macosx10.7") >>>> # endif () >>>> # set (CMAKE_C++_FLAGS -mmacosx-version-min=10.4) >>>> #endif(APPLE) >>>> # >>>> #if(WIN32) >>>> # add_definitions(-DWINVER=0x0400 -DWIN32) >>>> # if(${CMAKE_GENERATOR} STREQUAL "Visual Studio 6") >>>> # add_definitions(-DVC6) >>>> # elseif(${CMAKE_GENERATOR} STREQUAL "Visual Studio 8 2005") >>>> # add_definitions(-DVC2005) >>>> # endif(${CMAKE_GENERATOR} STREQUAL "Visual Studio 6") >>>> #endif(WIN32) >>>> >>>> ############### BOOST LIBRARIES ########### >>>> if (APPLE) >>>> set(BOOST_ROOT "/usr/local/boost") >>>> set(BOOST_FILESYSTEM_LIB /usr/local/boost/lib/libboost_filesystem.dylib) >>>> set(BOOST_SYSTEM_LIB /usr/local/boost/lib/libboost_system.dylib) >>>> >>>> else (NOT APPLE) >>>> set(BOOST_ROOT "C:/local/boost_1_58_0") >>>> set(BOOST_FILESYSTEM_LIB C:/local/boost_1_58_0/lib64-msvc-12.0) >>>> set(BOOST_SYSTEM_LIB C:/local/boost_1_58_0/lib64-msvc-12.0) >>>> endif (APPLE) >>>> >>>> FIND_PACKAGE( Boost 1.58.0 REQUIRED ) >>>> INCLUDE_DIRECTORIES( ${Boost_INCLUDE_DIR} ) >>>> >>>> >>>> ####################################### >>>> # set directories, src and headers. >>>> >>>> set (CATSMAT_DIR /Users/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat ) >>>> set (libIMUSANT_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../../libIMUSANT) >>>> set (LOKI_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../../Loki) >>>> set (SUFFIX_TREE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../../SuffixTree) >>>> set (GOOGLE_TEST_INC_DIR >>>> ${CMAKE_CURRENT_SOURCE_DIR}/../../googletest-master/googletest/include) >>>> set (IMUSANT_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../../libIMUSANT) >>>> >>>> >>>> set (LIBMUSICXML_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../../libMusicXMLv3) >>>> >>>> >>>> #### SET SOURCES EXPLICITLY ##### >>>> >>>> set(SRC >>>> >>>> ${CATSMAT_DIR}/Analysis/src/IMUSANT_contour_suffixtree_builder.cpp >>>> ${CATSMAT_DIR}/Analysis/src/IMUSANT_generalised_interval_suffixtree_builder.cpp >>>> ${CATSMAT_DIR}/Analysis/src/IMUSANT_interval_suffixtree_builder.cpp >>>> ${CATSMAT_DIR}/Analysis/src/IMUSANT_pitch_suffixtree_builder.cpp >>>> ${CATSMAT_DIR}/Analysis/src/IMUSANT_repeated_interval_substring.cpp >>>> ${CATSMAT_DIR}/Analysis/src/IMUSANT_t_repeated_substring.cpp >>>> ${CATSMAT_DIR}/Analysis/src/IMUSANT_VectorMapAnalysisTypes.cpp >>>> >>>> ${CATSMAT_DIR}/Application/CATSMAT_main.cpp >>>> ${CATSMAT_DIR}/Application/CATSMAT_menu.cpp >>>> >>>> ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_chord.cpp >>>> ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_collectionvisitor.cpp >>>> ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_cp_matrix.cpp >>>> ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_dyad_sequences.cpp >>>> ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_dyadtuple_sequences.cpp >>>> ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_sonority_sequences.cpp >>>> ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_TrigramSequences.cpp >>>> ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_TrigramSuffixTreeBuilder.cpp >>>> >>>> ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_canonic_techniques_tools.cpp >>>> ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_partdata.cpp >>>> ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_processing.cpp >>>> ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_score_profile.tpp >>>> ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_score_splitter.cpp >>>> ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_score_profile_special.cpp >>>> ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_scoredata.cpp >>>> ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_scoredatacollector.cpp >>>> >>>> ${CATSMAT_DIR}/Segmentation/IMUSANT_segment.cpp >>>> ${CATSMAT_DIR}/Segmentation/IMUSANT_set_of_segment.cpp >>>> >>>> ${CATSMAT_DIR}/Segmentation/FixedPeriodDetection/src/IMUSANT_fixed_period_segmenter.cpp >>>> ${CATSMAT_DIR}/Segmentation/FixedPeriodDetection/src/IMUSANT_partlist_ordered_by_part_entry.cpp >>>> ${CATSMAT_DIR}/Segmentation/FixedPeriodDetection/src/IMUSANT_segmented_part_fixed_period.cpp >>>> ${CATSMAT_DIR}/Segmentation/FixedPeriodDetection/src/SegmentedScoreFixedPeriod.cpp >>>> >>>> ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src/IMUSANT_interval_profile_LBDM.cpp >>>> ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src/IMUSANT_LBDM_segmenter.cpp >>>> ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src/IMUSANT_segmented_note_vectors.cpp >>>> ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src/IMUSANT_segmented_part_LBDM.cpp >>>> ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src/IMUSANT_segmented_profile_vectors.cpp >>>> ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src/IMUSANT_weighted_strength_vectors.cpp >>>> >>>> >>>> >>>> >>>> ) >>>> >>>> >>>> >>>> >>>> # old version of adding source code >>>> >>>> #set (SRCFOLDERS >>>> >>>> >>>> # ${CATSMAT_DIR}/Analysis/src >>>> # ${CATSMAT_DIR}/CounterpointAnalysis/src >>>> # ${CATSMAT_DIR}/GeneralAnalysis/src >>>> # ${CATSMAT_DIR}/Segmentation/FixedPeriodDetection/src >>>> # ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src >>>> # ${CATSMAT_DIR}/Application >>>> # ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src >>>> # ${CATSMAT_DIR}/Segmentation >>>> # ${CATSMAT_DIR}/Utilities >>>> #) >>>> >>>> >>>> set (INCFOLDERS >>>> ${libIMUSANT_DIR} >>>> ${CATSMAT_DIR}/Analysis/inc >>>> ${CATSMAT_DIR}/Application >>>> ${CATSMAT_DIR}/CounterpointAnalysis/inc >>>> ${CATSMAT_DIR}/GeneralAnalysis/inc >>>> ${CATSMAT_DIR}/Segmentation >>>> ${CATSMAT_DIR}/Segmentation/FixedPeriodDetection/inc >>>> ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/inc >>>> ${CATSMAT_DIR}/Utilities >>>> ${libIMUSANT_DIR}/DomainObjects/inc >>>> ${libIMUSANT_DIR}/Utilities/inc >>>> ${libIMUSANT_DIR}/FileProcessing/inc >>>> ${libIMUSANT_DIR}/Converters/MusicXML_v3 >>>> ${libIMUSANT_DIR}/Converters/MusicXML_v3/inc >>>> ${libIMUSANT_DIR}/Converters/MusicXML_v3/shared/inc >>>> ${IMUSANT_DIR}/DomainObjects/inc >>>> ${IMUSANT_DIR}/Converters/MusicXML_v3 >>>> ${IMUSANT_DIR}/Converters/MusicXML_v3/inc >>>> ${IMUSANT_DIR}/Converters/Shared/inc >>>> ${IMUSANT_DIR}/FileProcessing/inc >>>> ${IMUSANT_DIR}/FileProcessing/Analysis/Segmentation/FixedPeriodDetection/ >>>> ${IMUSANT_DIR}/Utilities/inc >>>> ${SUFFIXTREE_DIR} >>>> ${LIBMUSICXML_DIR}/libmusicxml-3.00-src/src >>>> ${LIBMUSICXML_DIR}/libmusicxml-3.00-src/src/lib >>>> ${LIBMUSICXML_DIR}/libmusicxml-3.00-src/src/visitors >>>> ${LIBMUSICXML_DIR}/libmusicxml-3.00-src/src/parser >>>> ${LOKI_DIR} >>>> ${SUFFIX_TREE_DIR} >>>> ${GOOGLE_TEST_INC_DIR} >>>> ) >>>> >>>> >>>> #foreach(folder ${SRCFOLDERS}) >>>> # set(SRC ${SRC} "${folder}/*.cpp") # add source files >>>> #endforeach(folder) >>>> #file (GLOB CORESRC RELATIVE ${CMAKE_CURRENT_SOURCE_DIR} ${SRC}) >>>> >>>> >>>> >>>> ## is this necessary I think target link directories might do the job ? >>>> >>>> foreach(folder ${INCFOLDERS}) >>>> set(HEADERS ${HEADERS} "${folder}/*.h") # add header files >>>> set(INCL ${INCL} "${folder}") # add include folders >>>> endforeach(folder) >>>> file (GLOB COREH RELATIVE ${CMAKE_CURRENT_SOURCE_DIR} ${HEADERS}) >>>> >>>> >>>> ####################################### >>>> # set includes ( is this needed ? ) >>>> include_directories( ${INCFOLDERS}) >>>> set_source_files_properties (${COREH} PROPERTIES HEADER_FILE_ONLY TRUE) >>>> >>>> >>>> ####################################### >>>> # set library target >>>> >>>> #if(APPLE OR MSVC) >>>> >>>> set(target catsmat) >>>> >>>> # I don't know why these if statements are included they seem to do nothing ' >>>> #else(APPLE OR MSVC) >>>> # set(target catsmat) >>>> #endif(APPLE OR MSVC) >>>> >>>> ##if(MSVC) >>>> ## enable_language(RC) >>>> ## set(LIBCONTENT ${CORESRC} ${COREH} >>>> ${CATSMAT_DIR}/win32/libIMUSANT/libIMUSANT.rc) >>>> ##else(MSVC) >>>> ## set(LIBCONTENT ${CORESRC} ${COREH}) >>>> ##endif(MSVC) >>>> >>>> add_executable(${target} ${SRC} ) >>>> >>>> #### add include directories >>>> include_directories ( ${INCFOLDERS} ) >>>> >>>> ############### Targeted Libraries ########### >>>> >>>> TARGET_LINK_LIBRARIES(${target} gtest) >>>> TARGET_LINK_LIBRARIES(${target} ${BOOST_FILESYSTEM_LIB}) >>>> TARGET_LINK_LIBRARIES(${target} ${BOOST_SYSTEM_LIB}) >>>> TARGET_LINK_LIBRARIES(${target} libmusicxml2) >>>> TARGET_LINK_LIBRARIES(${target} libIMUSANT) >>>> >>>> >>>> set_target_properties (${target} PROPERTIES >>>> FRAMEWORK TRUE >>>> VERSION ${VERSION} >>>> C_STANDARD 99 >>>> FRAMEWORK_VERSION ${VERSION} >>>> PUBLIC_HEADER "${COREH}" >>>> DEFINE_SYMBOL LIBMUSICXML_EXPORTS >>>> MACOSX_FRAMEWORK_SHORT_VERSION_STRING ${STRVERS} >>>> MACOSX_FRAMEWORK_BUNDLE_VERSION ${SSTRVERS} >>>> ) >>>> >>>> >>>> >>>> ####################################### >>>> # install setup >>>> if(NOT APPLE) >>>> install ( TARGETS ${target} ${TOOLS} >>>> RUNTIME DESTINATION bin >>>> LIBRARY DESTINATION lib >>>> ARCHIVE DESTINATION lib >>>> FRAMEWORK DESTINATION "/Library/Frameworks" CONFIGURATIONS Release >>>> PUBLIC_HEADER DESTINATION include/libmusicxml >>>> ) >>>> endif(NOT APPLE) >>>> >>>> >>>> >>>> >>>> >>>> >>> Hello Sean, >>> >>> Could you try adding a 'project(CATSTMAT)' call right at the top of your >>> CMakeLists.txt? As well as setting a name for the project, this call >>> also enables languages by default. >>> >>> HTH, >>> Micha >>> >>> >>> >>> -- >>> >>> 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 >> >> > Hi Sean, > > I'm also a bit confused as you seem to set 'C_STANDARD 99' as a property > for the target, as well as 'set(CMAKE_CXX_STANDARD 14)'. I don't know if > these two settings interfere with each other. Could you remove one of > the two as an experiment? > > Regards, > Micha > -- www.seanwayland.com Sean Wayland licensed real estate salesperson phone: 3475231455 From mailinglists at xgm.de Fri Jul 7 02:45:35 2017 From: mailinglists at xgm.de (Florian Lindner) Date: Fri, 7 Jul 2017 14:45:35 +0800 Subject: [CMake] Help on first cmake project Message-ID: Hello, coming from scons I want to take a look into cmake... My CMakeList.txt looks like: cmake_minimum_required (VERSION 3.0) project (ASTE) add_executable(readMesh readMesh.cpp) find_library(precice precice PATHS $ENV{PRECICE_ROOT}/build/last) target_link_libraries(readMesh ${precice}) set(CMAKE_LIBRARY_PATH ${CMAKE_LIBRARY_PATH} $ENV{PRECICE_ROOT}/build/last) find_package(Boost 1.60.0 COMPONENTS program_options filesystem REQUIRED) target_link_libraries(readMesh ${Boost_LIBRARIES}) find_package(MPI REQUIRED) target_link_libraries(readMesh ${MPI_LIBRARIES}) set(COMPILE_FLAGS ${COMPILE_FLAGS} ${MPI_COMPILE_FLAGS}) set(LINK_FLAGS ${LINK_FLAGS} ${MPI_LINK_FLAGS}) and does it job, i.e. the target builds. precice is out own, independently build library. However, I have several questions: * Can I make target_link_libraries add a library for all defined targets? At the moment, there is only one, but in the projekt there are multiple, very similiar targets built. * Can I make find_library to treat the library as required, as with find_package? * Can I reused the value of find_library's PATH setting? Especially if there are multiple PATHs, wouldn't it be nice to have a precice-LIBPATH that contains the path, where the library was found? So I can add this to CMAKE_LIBRARY_PATH? Or is there another function that does all that? * Is there a way to clean cmake cache, other than rm -rf CMakeFiles CMakeCache.txt. Would be nice, when playing around and frequently changing the CMakeLists.txt * I am a bit suprised that finding/or not finding MPI or precice is not printed out when executing cmake. * Any other advises you want to give me? Thanks for helping a beginner! Florian From d3ck0r at gmail.com Fri Jul 7 04:47:05 2017 From: d3ck0r at gmail.com (J Decker) Date: Fri, 7 Jul 2017 01:47:05 -0700 Subject: [CMake] Help on first cmake project In-Reply-To: References: Message-ID: On Thu, Jul 6, 2017 at 11:45 PM, Florian Lindner wrote: > Hello, > > coming from scons I want to take a look into cmake... > > My CMakeList.txt looks like: > > > cmake_minimum_required (VERSION 3.0) > project (ASTE) > > add_executable(readMesh readMesh.cpp) > > find_library(precice precice PATHS $ENV{PRECICE_ROOT}/build/last) > target_link_libraries(readMesh ${precice}) > set(CMAKE_LIBRARY_PATH ${CMAKE_LIBRARY_PATH} $ENV{PRECICE_ROOT}/build/last) > > > find_package(Boost 1.60.0 > COMPONENTS program_options filesystem > REQUIRED) > target_link_libraries(readMesh ${Boost_LIBRARIES}) > > find_package(MPI REQUIRED) > target_link_libraries(readMesh ${MPI_LIBRARIES}) > set(COMPILE_FLAGS ${COMPILE_FLAGS} ${MPI_COMPILE_FLAGS}) > set(LINK_FLAGS ${LINK_FLAGS} ${MPI_LINK_FLAGS}) > > > and does it job, i.e. the target builds. precice is out own, independently > build library. > > However, I have several questions: > > * Can I make target_link_libraries add a library for all defined targets? > At the moment, there is only one, but in the > projekt there are multiple, very similiar targets built. > No; each target needs to have target_link_libaries. You can build a list of libs to add like set( common_deps ${Boost_LIBRARIES} ${MPI_LIBRARIES} ) ; or appending to a variable like you did with COMPILE_FLAGS. > * Can I make find_library to treat the library as required, as with > find_package? > can add if( -NOTFOUND ) message( ERROR "xxx not found" ) can wrap that in a macro for simplification... macro( my_find_library var ) find_library( ${var} ${ARGN} ) if( ${var}-NOTFOUND ) message( FATAL_ERROR "${ARG2} was not found" ) endif() endmacro() (assumes that you're using the single name version, and not multiple names using NAME command in find_library) > > * Can I reused the value of find_library's PATH setting? Especially if > there are multiple PATHs, wouldn't it be nice to > have a precice-LIBPATH that contains the path, where the library was > found? So I can add this to CMAKE_LIBRARY_PATH? Or > is there another function that does all that? > > Yes, these become available for all sub projects also. INCLUDE_DIRECTORIES() and LINK_DIRECTORIES() will also get inherited by child projects. > * Is there a way to clean cmake cache, other than rm -rf CMakeFiles > CMakeCache.txt. Would be nice, when playing around > and frequently changing the CMakeLists.txt > > really just remove CMakeCache.txt is sufficient; though generally you won't have to remove the cache; it redoes the generation if one of the cmakelists.txt is updated (or included dependancies). If you're moving librarites to be found, then yes you will have to remove the cmakecache. > * I am a bit suprised that finding/or not finding MPI or precice is not > printed out when executing cmake. > > * Any other advises you want to give me? > > Thanks for helping a beginner! > > Florian > > -- > > 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 bballet at ivsweb.com Fri Jul 7 05:47:20 2017 From: bballet at ivsweb.com (Benjamin Ballet) Date: Fri, 7 Jul 2017 11:47:20 +0200 Subject: [CMake] Parallel moc for Qt files In-Reply-To: <595E96C4.90209@bluequartz.net> References: <595E96C4.90209@bluequartz.net> Message-ID: I don't know how to parallelize moc with CMake though I previously reduce moc time (sometimes it's very slow) : - by replacing as much #include as possible by forward-declaration - wrapping some #include around #ifndef Q_MOC_RUN ... #endif 2017-07-06 22:00 GMT+02:00 Michael Jackson : > I have a large list of files that need to have Qt's 'moc' run on them (107 > headers). I use all the normal CMake facilities for Qt based projects. I > noticed that the generation of the moc files are done serially. Is there a > flag or anything that I can use to run the generation in Parallel? I ask > because each file takes about 3 seconds to run through moc. The code is > heavily C++ templated which I think causes 'moc' to run more slowly. We > have other places in the code where 'moc' must run and it does each file in > the "blink of an eye". > > Just curious. > > -- > Michael A. Jackson > BlueQuartz Software, LLC > [e]: mike.jackson at bluequartz.net > -- > > 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 > -- Benjamin Ballet Ing?nieur R&D 19 rue Klock - 92110 Clichy - FRANCE Standard : +33 1 44 69 37 37 www.activisu.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.jackson at bluequartz.net Fri Jul 7 07:22:30 2017 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Fri, 7 Jul 2017 11:22:30 +0000 Subject: [CMake] Parallel moc for Qt files In-Reply-To: References: <595E96C4.90209@bluequartz.net>, Message-ID: Looks like an interesting project. After reading the blog and reading the GitHub issue pages there seem to be serious issues with MSVC still which is a blocker for us. I will keep an eye on it though. -- Michael A. Jackson ________________________________ From: Cristian Adam Sent: Thursday, July 6, 2017 6:11:50 PM To: Michael Jackson Cc: cmake Subject: Re: [CMake] Parallel moc for Qt files On Thu, Jul 6, 2017 at 10:00 PM, Michael Jackson > wrote: I have a large list of files that need to have Qt's 'moc' run on them (107 headers). I use all the normal CMake facilities for Qt based projects. I noticed that the generation of the moc files are done serially. Is there a flag or anything that I can use to run the generation in Parallel? I ask because each file takes about 3 seconds to run through moc. The code is heavily C++ templated which I think causes 'moc' to run more slowly. We have other places in the code where 'moc' must run and it does each file in the "blink of an eye". Just curious. Have you tried removing moc altogether using Verdigris? I'm curious how this would speed up your compilation time. Cheers, Cristian. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.jackson at bluequartz.net Fri Jul 7 07:25:39 2017 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Fri, 7 Jul 2017 11:25:39 +0000 Subject: [CMake] Parallel moc for Qt files In-Reply-To: References: <595E96C4.90209@bluequartz.net>, Message-ID: Thank you for the suggestions. It is almost like a Jom for moc needs to be written. -Mike Jackson ________________________________ From: Benjamin Ballet Sent: Friday, July 7, 2017 5:47:20 AM To: Michael Jackson Cc: cmake Subject: Re: [CMake] Parallel moc for Qt files I don't know how to parallelize moc with CMake though I previously reduce moc time (sometimes it's very slow) : - by replacing as much #include as possible by forward-declaration - wrapping some #include around #ifndef Q_MOC_RUN ... #endif 2017-07-06 22:00 GMT+02:00 Michael Jackson >: I have a large list of files that need to have Qt's 'moc' run on them (107 headers). I use all the normal CMake facilities for Qt based projects. I noticed that the generation of the moc files are done serially. Is there a flag or anything that I can use to run the generation in Parallel? I ask because each file takes about 3 seconds to run through moc. The code is heavily C++ templated which I think causes 'moc' to run more slowly. We have other places in the code where 'moc' must run and it does each file in the "blink of an eye". Just curious. -- Michael A. Jackson BlueQuartz Software, LLC [e]: mike.jackson at bluequartz.net -- 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 -- Benjamin Ballet Ing?nieur R&D [http://www.activscreen.com/mkg/signature/email_2017/ivs_logo.png] 19 rue Klock - 92110 Clichy - FRANCE Standard : +33 1 44 69 37 37 www.activisu.com [http://www.activscreen.com/mkg/signature/Signature_IVS_MAI_17.png] [http://www.activscreen.com/mkg/signature/email_2017/linkedin.png] -------------- next part -------------- An HTML attachment was scrubbed... URL: From annulen at yandex.ru Fri Jul 7 07:27:14 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Fri, 07 Jul 2017 14:27:14 +0300 Subject: [CMake] Parallel moc for Qt files In-Reply-To: <595E96C4.90209@bluequartz.net> References: <595E96C4.90209@bluequartz.net> Message-ID: <1050911499426834@web19o.yandex.ru> 06.07.2017, 23:00, "Michael Jackson" : > I have a large list of files that need to have Qt's 'moc' run on them > (107 headers). I use all the normal CMake facilities for Qt based > projects. I noticed that the generation of the moc files are done > serially. Is there a flag or anything that I can use to run the > generation in Parallel? I ask because each file takes about 3 seconds to > run through moc. The code is heavily C++ templated which I think causes > 'moc' to run more slowly. We have other places in the code where 'moc' > must run and it does each file in the "blink of an eye". Replace use of AUTOMOC with macros like qt5_generate_moc. Each moc file will be generated by a separate custom command. For example, I wrote 3 macros that wrap qt5_generate_moc for more convenience [1], example usage is at [2]. [1] https://github.com/annulen/webkit/blob/qtwebkit-stable/Source/cmake/OptionsQt.cmake#L63 [2] https://github.com/annulen/webkit/blob/qtwebkit-stable/Source/WebCore/PlatformQt.cmake#L165 > > Just curious. > > -- > Michael A. Jackson > BlueQuartz Software, LLC > [e]: mike.jackson at bluequartz.net > -- > > 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 ggarra13 at gmail.com Fri Jul 7 11:36:56 2017 From: ggarra13 at gmail.com (=?UTF-8?Q?Gonzalo_Garramu=c3=b1o?=) Date: Fri, 7 Jul 2017 12:36:56 -0300 Subject: [CMake] Help on first cmake project In-Reply-To: References: Message-ID: <95a06df0-c32c-1fa6-dee1-2e9e58af4822@gmail.com> El 07/07/17 a las 03:45, Florian Lindner escribi?: > * Any other advises you want to give me? I would advise you try to build out of source tree to keep the source clean. Example: $ mkdir build-linux64 $ cd build-linux64 $ cmake .. -G'Unix Makefiles' $ make $ make install when done, you can then do: $ cd .. $ rm -rf build-linux64 > Thanks for helping a beginner! > > Florian No problem. -- Gonzalo Garramu?o From rcdailey.lists at gmail.com Fri Jul 7 14:13:04 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Fri, 7 Jul 2017 13:13:04 -0500 Subject: [CMake] FindDoxygen is doing find_package() when it is included Message-ID: When I do this: message( "blah1" ) include( FindDoxygen ) message( "blah2" ) find_package( Doxygen 1.8.6 OPTIONAL_COMPONENTS dot ) message( "blah3" ) I get this output: blah1 -- Found Doxygen: C:/Program Files/doxygen/bin/doxygen.exe (found version "1.8.13") found components: doxygen missing components: dot blah2 -- Found Doxygen: C:/Program Files/doxygen/bin/doxygen.exe (found suitable version "1.8.13", minimum required is "1.8.6") found components: doxygen missing components: dot blah3 Two questions: 1. Why is find_package() happening automatically when I include the find module? This is contrary to the behavior of other find modules. I do not want it to find doxygen for me, as I have some minimum version requirements and I do not want it to find dot. How can I disable this implied search behavior? 2. Each time I run my scripts, it keeps searching for doxygen. Even though I've specified dot as an optional component. I do not want it to keep searching for doxygen each time I generate. It should find it once and be done. How can I fix this behavior? From rcdailey.lists at gmail.com Fri Jul 7 14:20:49 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Fri, 7 Jul 2017 13:20:49 -0500 Subject: [CMake] FindDoxygen is doing find_package() when it is included In-Reply-To: References: Message-ID: I actually confused myself a bit... I think the issue is not that finding happens when including it, but that doxygen_add_docs() is bundled with the find module. What is the intended usage of this? If I do find_package() will that also make doxygen_add_docs() available? Or do I have to explicitly include FindDoxygen to get access to the function? On Fri, Jul 7, 2017 at 1:13 PM, Robert Dailey wrote: > When I do this: > > > message( "blah1" ) > include( FindDoxygen ) > > message( "blah2" ) > find_package( Doxygen 1.8.6 OPTIONAL_COMPONENTS dot ) > message( "blah3" ) > > > I get this output: > > > blah1 > -- Found Doxygen: C:/Program Files/doxygen/bin/doxygen.exe (found > version "1.8.13") found components: doxygen missing components: dot > blah2 > -- Found Doxygen: C:/Program Files/doxygen/bin/doxygen.exe (found > suitable version "1.8.13", minimum required is "1.8.6") found > components: doxygen missing components: dot > blah3 > > > Two questions: > > 1. Why is find_package() happening automatically when I include the > find module? This is contrary to the behavior of other find modules. I > do not want it to find doxygen for me, as I have some minimum version > requirements and I do not want it to find dot. How can I disable this > implied search behavior? > > 2. Each time I run my scripts, it keeps searching for doxygen. Even > though I've specified dot as an optional component. I do not want it > to keep searching for doxygen each time I generate. It should find it > once and be done. How can I fix this behavior? From rcdailey.lists at gmail.com Fri Jul 7 14:28:15 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Fri, 7 Jul 2017 13:28:15 -0500 Subject: [CMake] FindDoxygen is doing find_package() when it is included In-Reply-To: References: Message-ID: Apologies for the confusion and spam: I figured out that when you do a find_package(), it also implicitly includes the contents of that module into your list file so you can access its functions. I was under the impression I had to include FindDoxygen.cmake explicitly to access the functions it provides. I'm guessing this is supported behavior. If so, I'll rely on it. On Fri, Jul 7, 2017 at 1:20 PM, Robert Dailey wrote: > I actually confused myself a bit... I think the issue is not that > finding happens when including it, but that doxygen_add_docs() is > bundled with the find module. What is the intended usage of this? If I > do find_package() will that also make doxygen_add_docs() available? Or > do I have to explicitly include FindDoxygen to get access to the > function? > > On Fri, Jul 7, 2017 at 1:13 PM, Robert Dailey wrote: >> When I do this: >> >> >> message( "blah1" ) >> include( FindDoxygen ) >> >> message( "blah2" ) >> find_package( Doxygen 1.8.6 OPTIONAL_COMPONENTS dot ) >> message( "blah3" ) >> >> >> I get this output: >> >> >> blah1 >> -- Found Doxygen: C:/Program Files/doxygen/bin/doxygen.exe (found >> version "1.8.13") found components: doxygen missing components: dot >> blah2 >> -- Found Doxygen: C:/Program Files/doxygen/bin/doxygen.exe (found >> suitable version "1.8.13", minimum required is "1.8.6") found >> components: doxygen missing components: dot >> blah3 >> >> >> Two questions: >> >> 1. Why is find_package() happening automatically when I include the >> find module? This is contrary to the behavior of other find modules. I >> do not want it to find doxygen for me, as I have some minimum version >> requirements and I do not want it to find dot. How can I disable this >> implied search behavior? >> >> 2. Each time I run my scripts, it keeps searching for doxygen. Even >> though I've specified dot as an optional component. I do not want it >> to keep searching for doxygen each time I generate. It should find it >> once and be done. How can I fix this behavior? From timothydlegg at gmail.com Sat Jul 8 09:06:45 2017 From: timothydlegg at gmail.com (timothylegg .) Date: Sat, 8 Jul 2017 08:06:45 -0500 Subject: [CMake] Using CMake for the first time on an established project Message-ID: Hello, I have CMake installed via apt-get on a few Debian-derived operating systems. My question is version independent, and I haven't checked, but I think version 2.8.0+ describes all the machines. There is a software project that I am wanting to become involved in that uses cmake, but I have never used makefiles of any sort within the last 20 years. I have a vague understanding of how they function and what their goals are, it's just that I've never written anything that had a level of complexity to require it. I don't necessarily need to be able to create any kind of makefiles, but I only need to know how to use them at compile time. I could be talked into authoring them in the future, but presently there is no need. The software project I am interested in has very few members where forum questions can take several days to answer (there seems to be only 1 or 2 active participants whom are mostly absent) So lets get to the specifics, the project is open62541.org. Somebody wrote a wonderful PDF tutorial (link below) that suggests that compilation flags, such as BUILD_SHARED_LIBS, UA_ENABLE_METHODCALLS, or UA_ENABLE_AMALGAMATION, but fails to explain exactly how they are enabled. Would these be passed as parameters to cmake or would they have to be inserted into a file that the CMake tool suite expects to find upon execution of cmake? Thanks, Timothy D Legg References: Documentation - refer to pages: 9-10 of 154, 13 of 154 https://open62541.org/doc/open62541-0.2.pdf Mailing list question I posted two days ago: https://groups.google.com/forum/#!topic/open62541/Ifkzrn-k-2s From AlbrechtS.fltk at online.de Sat Jul 8 09:50:48 2017 From: AlbrechtS.fltk at online.de (Albrecht Schlosser) Date: Sat, 8 Jul 2017 15:50:48 +0200 Subject: [CMake] Using CMake for the first time on an established project In-Reply-To: References: Message-ID: On 08.07.2017 15:06 timothylegg . wrote: > I have CMake installed via apt-get on a few Debian-derived operating > systems. My question is version independent, and I haven't checked, > but I think version 2.8.0+ describes all the machines. > > There is a software project that I am wanting to become involved in > that uses cmake, but I have never used makefiles of any sort within > the last 20 years. I have a vague understanding of how they function > and what their goals are, it's just that I've never written anything > that had a level of complexity to require it. First thing to know here is that CMake is not another kind of make. It's a build system generator that can - among others - generate Makefiles for you to run 'make' to build your project. > So lets get to the specifics, the project is open62541.org. Somebody > wrote a wonderful PDF tutorial (link below) that suggests that > compilation flags, such as BUILD_SHARED_LIBS, UA_ENABLE_METHODCALLS, > or UA_ENABLE_AMALGAMATION, but fails to explain exactly how they are > enabled. Would these be passed as parameters to cmake or would they > have to be inserted into a file that the CMake tool suite expects to > find upon execution of cmake? These are CMake options (aka "cache variables") that can either be specified on the cmake command line [1] or changed later in one of the GUI tools that come with CMake. On page 7 in the mentioned PDF file you can see (for Linux builds): # select additional features ccmake .. make So you need ccmake to be installed with cmake. On Ubuntu the package name is "cmake-curses-gui", so if you can't run 'ccmake' you need to install this. Another option is mentioned under the "Windows" section in the tutorial, but this is also availabel under Linux: cmake-gui (Ubuntu package name: "cmake-qt-gui"). Once you launch one of these GUI tools (after running the initial 'cmake' command, but optionally before 'make' you'll see the mentioned CMake options/variables and can change them interactively. After changing variables, be sure to run 'configure' and 'generate' within cmake-gui or ccmake. Then, exit the GUI and run 'make'. [1] to specify CMake options on the command line use this syntax: cmake -D"OPTION=value" -D"OTHER_OPTION=other_value" .. From timothydlegg at gmail.com Sat Jul 8 10:11:04 2017 From: timothydlegg at gmail.com (timothylegg .) Date: Sat, 8 Jul 2017 09:11:04 -0500 Subject: [CMake] Using CMake for the first time on an established project In-Reply-To: References: Message-ID: Thanks for the great tips, and I welcome more suggestions too from others. I saw the ccmake command in the tutorial, but not having ccmake, I thought it was a typo in the documentation. I am eager to reproduce this. Thank you very much! Timothy D Legg On Sat, Jul 8, 2017 at 8:50 AM, Albrecht Schlosser wrote: > On 08.07.2017 15:06 timothylegg . wrote: > >> I have CMake installed via apt-get on a few Debian-derived operating >> systems. My question is version independent, and I haven't checked, >> but I think version 2.8.0+ describes all the machines. >> >> There is a software project that I am wanting to become involved in >> that uses cmake, but I have never used makefiles of any sort within >> the last 20 years. I have a vague understanding of how they function >> and what their goals are, it's just that I've never written anything >> that had a level of complexity to require it. > > > First thing to know here is that CMake is not another kind of make. It's a > build system generator that can - among others - generate Makefiles for you > to run 'make' to build your project. > >> So lets get to the specifics, the project is open62541.org. Somebody >> wrote a wonderful PDF tutorial (link below) that suggests that >> compilation flags, such as BUILD_SHARED_LIBS, UA_ENABLE_METHODCALLS, >> or UA_ENABLE_AMALGAMATION, but fails to explain exactly how they are >> enabled. Would these be passed as parameters to cmake or would they >> have to be inserted into a file that the CMake tool suite expects to >> find upon execution of cmake? > > > These are CMake options (aka "cache variables") that can either be specified > on the cmake command line [1] or changed later in one of the GUI tools that > come with CMake. On page 7 in the mentioned PDF file you can see (for Linux > builds): > > # select additional features > ccmake .. > make > > So you need ccmake to be installed with cmake. On Ubuntu the package name is > "cmake-curses-gui", so if you can't run 'ccmake' you need to install this. > Another option is mentioned under the "Windows" section in the tutorial, but > this is also availabel under Linux: cmake-gui (Ubuntu package name: > "cmake-qt-gui"). > > Once you launch one of these GUI tools (after running the initial 'cmake' > command, but optionally before 'make' you'll see the mentioned CMake > options/variables and can change them interactively. After changing > variables, be sure to run 'configure' and 'generate' within cmake-gui or > ccmake. > > Then, exit the GUI and run 'make'. > > [1] to specify CMake options on the command line use this syntax: > > cmake -D"OPTION=value" -D"OTHER_OPTION=other_value" .. > -- > > 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 mailinglists at xgm.de Sun Jul 9 05:45:05 2017 From: mailinglists at xgm.de (Florian Lindner) Date: Sun, 9 Jul 2017 17:45:05 +0800 Subject: [CMake] Help on first cmake project In-Reply-To: References: Message-ID: <0e1c1c35-52d1-4396-da55-5d22301c34c5@xgm.de> Am 07.07.2017 um 16:47 schrieb J Decker: > > > On Thu, Jul 6, 2017 at 11:45 PM, Florian Lindner > wrote: > > Hello, > > coming from scons I want to take a look into cmake... > > My CMakeList.txt looks like: > > > cmake_minimum_required (VERSION 3.0) > project (ASTE) > > add_executable(readMesh readMesh.cpp) > > find_library(precice precice PATHS $ENV{PRECICE_ROOT}/build/last) > target_link_libraries(readMesh ${precice}) > set(CMAKE_LIBRARY_PATH ${CMAKE_LIBRARY_PATH} $ENV{PRECICE_ROOT}/build/last) > > > find_package(Boost 1.60.0 > COMPONENTS program_options filesystem > REQUIRED) > target_link_libraries(readMesh ${Boost_LIBRARIES}) > > find_package(MPI REQUIRED) > target_link_libraries(readMesh ${MPI_LIBRARIES}) > set(COMPILE_FLAGS ${COMPILE_FLAGS} ${MPI_COMPILE_FLAGS}) > set(LINK_FLAGS ${LINK_FLAGS} ${MPI_LINK_FLAGS}) > > > and does it job, i.e. the target builds. precice is out own, independently build library. > > However, I have several questions: > > * Can I make target_link_libraries add a library for all defined targets? At the moment, there is only one, but in the > projekt there are multiple, very similiar targets built. > > No; each target needs to have target_link_libaries. You can build a list of libs to add like set( common_deps > ${Boost_LIBRARIES} ${MPI_LIBRARIES} ) ; or appending to a variable like you did with COMPILE_FLAGS. Ok, that would be nice feature I think. > * Can I make find_library to treat the library as required, as with find_package? > > > can add if( -NOTFOUND ) message( ERROR "xxx not found" ) Ok. I am a bit surprised, that there is no REQUIRED flag, just like it is with the similar find_package. > can wrap that in a macro for simplification... > > macro( my_find_library var ) > find_library( ${var} ${ARGN} ) > if( ${var}-NOTFOUND ) > message( FATAL_ERROR "${ARG2} was not found" ) > endif() > endmacro() find_library(precice precice PATHS $ENV{PRECICE_ROOT}/build/last) if( precice-NOTFOUND ) message(FATAL_ERROR "preCICE was not found") endif() but the missing library is not caught and the subsequent call to target_link_libraries fails. Using if(NOT precice) instead made it working. > (assumes that you're using the single name version, and not multiple names using NAME command in find_library) > > > * Can I reused the value of find_library's PATH setting? Especially if there are multiple PATHs, wouldn't it be nice to > have a precice-LIBPATH that contains the path, where the library was found? So I can add this to CMAKE_LIBRARY_PATH? Or > is there another function that does all that? > > Yes, these become available for all sub projects also. INCLUDE_DIRECTORIES() and LINK_DIRECTORIES() will also get > inherited by child projects. Not sure if I got that, but we'll see... Best, Florian From larry at larryhynes.com Sun Jul 9 07:16:08 2017 From: larry at larryhynes.com (Larry Hynes) Date: Sun, 9 Jul 2017 12:16:08 +0100 Subject: [CMake] Tell cmake use /usr/include/db.h, not /usr/local/include/db.h Message-ID: Hi I'm building nvi2[0], on (Mac OS X Yosemite (10.10.5)), which uses cmake. nvi2 depends on a reasonably sane BSD environment, which would include Berkeley DB V1 which is found at /usr/include/db.h. I also have installed BDB V4, which lives at /usr/local/include/db.h, for use by other programs. The only way I can get nvi2 to build, is to uninstall BDB V4, in which case cmake picks up V1 and all is well. Otherwise cmake resolutely picks up V4 and the build fails. I'm trying to figure out if it is possible to tell cmake to use the V1 that is at /usr/include/db.h. I've tried various invocations of find_path and find_library in CMakeLists.txt, with and without appeals to default paths and such like, to no avail. I've tried any variation of -DCMAKE_XXXFLAGS I can think of, in CMakeLists.txt and on the command line, to no avail. (When using find_XXX, cmake tells me they're found, but still uses DB4. In the case of passing flags, cmake tells me that it is ignoring them.) Now, at day's end, this is not A Big Deal; I uninstall BDB4, build nvi2, reinstall BDB4. But one would imagine that there is some (simple) way to instruct cmake to use X over Y when building Z? [0] https://github.com/lichray/nvi2 From mellery451 at gmail.com Sun Jul 9 10:45:06 2017 From: mellery451 at gmail.com (Michael Ellery) Date: Sun, 9 Jul 2017 07:45:06 -0700 Subject: [CMake] Tell cmake use /usr/include/db.h, not /usr/local/include/db.h In-Reply-To: References: Message-ID: <265573B7-D62C-4C6C-83E1-0CD213F7DFAE@gmail.com> > On Jul 9, 2017, at 4:16 AM, Larry Hynes wrote: > > Hi > > I'm building nvi2[0], on (Mac OS X Yosemite (10.10.5)), which uses > cmake. > > nvi2 depends on a reasonably sane BSD environment, which would > include Berkeley DB V1 which is found at /usr/include/db.h. > > I also have installed BDB V4, which lives at /usr/local/include/db.h, > for use by other programs. > > The only way I can get nvi2 to build, is to uninstall BDB V4, in > which case cmake picks up V1 and all is well. Otherwise cmake > resolutely picks up V4 and the build fails. > > I'm trying to figure out if it is possible to tell cmake to use the > V1 that is at /usr/include/db.h. > > I've tried various invocations of find_path and find_library in > CMakeLists.txt, with and without appeals to default paths and such > like, to no avail. I've tried any variation of -DCMAKE_XXXFLAGS I > can think of, in CMakeLists.txt and on the command line, to no > avail. (When using find_XXX, cmake tells me they're found, but still > uses DB4. In the case of passing flags, cmake tells me that it > is ignoring them.) > > Now, at day's end, this is not A Big Deal; I uninstall BDB4, build > nvi2, reinstall BDB4. But one would imagine that there is some > (simple) way to instruct cmake to use X over Y when building Z? > > [0] https://github.com/lichray/nvi2 > system include order path is implementation defined, but it sounds to me like your compiler (clang) is behaving in a fairly normal way - that is, it checks /usr/local/include before /usr/include, which allows you to have newer versions of libs in local. This has nothing to do with CMake - this is standard compiler behavior. So, now it sounds like you want to change that default behavior for this target. If you can figure out the right set of flags to pass to clang to get it to find the right header, then it?s possible to convince CMake to pass those flags using something like target_compile_options(). The CMake find_path and find_library functions don?t do anything magical?they just simplify the process of searching various locations on your filesystem for the specified files, and conveniently find_library knows about library file naming convention. When those functions are used, they just end-up setting some variables to tell you what it found and where, but they don?t do anything special with compiler flags. It?s up to you to take the results (variables) of those functions and pass them along to your compiler/toolchain as you see fit. So that?s the challenge here - figure out how to convince your compiler to ignore /usr/local/include, at least of this one dependency. If you have other things in /usr/local/include that you depend on, then this might be very tricky. It looks like the -include option to clang might allow you to specify a full path to a file to include before preprocessing, but that might also require that you remove all #include from your sources - I don?t know if that?s feasible. If it were up to me, I?d probably choose to not install the newer lib to /usr/local because fighting the compiler regarding system include paths is not fun. If/when I needed the newer version, I?d put it in some non-system path (like /opt) and then tell the compiler to treat that alternate path with top precedence if/when I need to use the newer version. That?s just my 2 cents. -Mike From larry at larryhynes.com Sun Jul 9 12:22:20 2017 From: larry at larryhynes.com (Larry Hynes) Date: Sun, 9 Jul 2017 17:22:20 +0100 Subject: [CMake] Tell cmake use /usr/include/db.h, not /usr/local/include/db.h References: <265573B7-D62C-4C6C-83E1-0CD213F7DFAE@gmail.com> Message-ID: Michael Ellery wrote: >> On Jul 9, 2017, at 4:16 AM, Larry Hynes wrote: >> >> Hi >> >> I'm building nvi2[0], on (Mac OS X Yosemite (10.10.5)), which uses >> cmake. >> >> nvi2 depends on a reasonably sane BSD environment, which would >> include Berkeley DB V1 which is found at /usr/include/db.h. >> >> I also have installed BDB V4, which lives at /usr/local/include/db.h, >> for use by other programs. >> >> The only way I can get nvi2 to build, is to uninstall BDB V4, in >> which case cmake picks up V1 and all is well. Otherwise cmake >> resolutely picks up V4 and the build fails. >> >> I'm trying to figure out if it is possible to tell cmake to use the >> V1 that is at /usr/include/db.h. >> >> I've tried various invocations of find_path and find_library in >> CMakeLists.txt, with and without appeals to default paths and such >> like, to no avail. I've tried any variation of -DCMAKE_XXXFLAGS I >> can think of, in CMakeLists.txt and on the command line, to no >> avail. (When using find_XXX, cmake tells me they're found, but still >> uses DB4. In the case of passing flags, cmake tells me that it >> is ignoring them.) >> >> Now, at day's end, this is not A Big Deal; I uninstall BDB4, build >> nvi2, reinstall BDB4. But one would imagine that there is some >> (simple) way to instruct cmake to use X over Y when building Z? >> >> [0] https://github.com/lichray/nvi2 >> > system include order path is implementation defined, but it sounds > to me like your compiler (clang) is behaving in a fairly normal way > - that is, it checks /usr/local/include before /usr/include, which > allows you to have newer versions of libs in local. This has nothing > to do with CMake - this is standard compiler behavior. So, now it > sounds like you want to change that default behavior for this target. > If you can figure out the right set of flags to pass to clang to get > it to find the right header, then it?s possible to convince CMake to > pass those flags using something like target_compile_options(). > > The CMake find_path and find_library functions don?t do anything > magical?they just simplify the process of searching various locations > on your filesystem for the specified files, and conveniently > find_library knows about library file naming convention. When those > functions are used, they just end-up setting some variables to tell > you what it found and where, but they don?t do anything special with > compiler flags. It?s up to you to take the results (variables) of > those functions and pass them along to your compiler/toolchain as you > see fit. > > So that?s the challenge here - figure out how to convince your > compiler to ignore /usr/local/include, at least of this one > dependency. If you have other things in /usr/local/include that you > depend on, then this might be very tricky. It looks like the -include > option to clang might allow you to specify a full path to a file to > include before preprocessing, but that might also require that you > remove all #include from your sources - I don?t know if that?s > feasible. Thanks Mike - you gave me an idea here, and it works. Turns out is only included from one file - common/common.h - and changing it to '#include "/usr/include/db.h"' does the trick. Yes, it's a little hacky and amateurish and will probably anger the Gods, but it takes less time than the uninstall / reinstall dance, so we'll call it a victory. From davidhunter22 at gmail.com Mon Jul 10 13:41:13 2017 From: davidhunter22 at gmail.com (David Hunter) Date: Mon, 10 Jul 2017 11:41:13 -0600 Subject: [CMake] Non OBJECT libraries and population of $ Message-ID: Currently you can create an OBJECT library using "add_library( OBJECT ...)" this populates $ which can then later be used using something like "target_sources(name PUBLIC $)". I am wondering if there is some reason that $ can't be populated when you create a shared or static library, for instance using "add_library( SHARED ...)". Looking at the output the VS 2017 generators for "add_library( OBJECT ...)" it seems to actually build a static library anyway. I suspect that all the files are compiled to object files somewhere for both STATIC and SHARED libraries, if so would it not be possible to point $ as these object files? The reason I ask is that we have a a bunch of source code that builds in about 100 projects. These projects have a normal hierarchical dependency tree. However when distributing we want to create larger libraries that are the combination of various subsets of the smaller ones. In automake these are called convenience libraries and I suspect they may have been the reason for CMake OBJECT in the first place. Given the current behaviour we have to build all the projects twice once in SHARED library form on once in OBJECT library form. If TARGET_OBJECTS was populated for SHARED libraries we would not need to build everything twice as we could build everything SHARED but still use TARGET_OBJECTS to build combination convenience libraries. Of course maybe there's already a way to do this without having to build twice which I don't know about. From cerobison at utexas.edu Mon Jul 10 13:46:23 2017 From: cerobison at utexas.edu (Christopher E Robison) Date: Mon, 10 Jul 2017 17:46:23 +0000 Subject: [CMake] How to have build steps operate on files in a copied directory? Message-ID: I've recently begun using CMake on an existing project I've taken over, and I feel like I'm mostly getting used to it, though there is still a vast amount to learn. I've got nearly the entire project building successfully, with the exception of a directory of external scripts that need to be configured at the end of the install process to create some index files. So, in a nutshell, there's a script that takes care of this post-install configuration, that needs to be executed once the target tree of directories and script files are in place, copied from the source tree. And I'm finding that when the script is called during the build, the INSTALL(DIRECTORY ...) command from the CMakeLists.txt directory hasn't been run yet, so the tree of script files hasn't been put in place yet and the script (and the build) fails. FWIW, if I leave out the add_custom_command and add_custom_target that execute the script, the directory tree does copy correctly. I have not found any guidance on how to specify that the directory tree gets copied first. How is this normally done? Thanks, CR -------------- next part -------------- An HTML attachment was scrubbed... URL: From mellery451 at gmail.com Mon Jul 10 14:04:26 2017 From: mellery451 at gmail.com (Michael Ellery) Date: Mon, 10 Jul 2017 11:04:26 -0700 Subject: [CMake] How to have build steps operate on files in a copied directory? In-Reply-To: References: Message-ID: > On Jul 10, 2017, at 10:46 AM, Christopher E Robison wrote: > > I've recently begun using CMake on an existing project I've taken over, and I feel like I'm mostly getting used to it, though there is still a vast amount to learn. I've got nearly the entire project building successfully, with the exception of a directory of external scripts that need to be configured at the end of the install process to create some index files. > > So, in a nutshell, there's a script that takes care of this post-install configuration, that needs to be executed once the target tree of directories and script files are in place, copied from the source tree. And I'm finding that when the script is called during the build, the INSTALL(DIRECTORY ...) command from the CMakeLists.txt directory hasn't been run yet, so the tree of script files hasn't been put in place yet and the script (and the build) fails. > > FWIW, if I leave out the add_custom_command and add_custom_target that execute the script, the directory tree does copy correctly. > > I have not found any guidance on how to specify that the directory tree gets copied first. How is this normally done? > > > Thanks, > CR > > > I think you might be getting confused by two distinct phases: BUILD and INSTALL. BUILD is what happens when building your sources and all the results of this step are in your build directory (or source directory if you do in-source building). Both add_custom_command and add_custom_target are evaluated (and potentially executed) at BUILD time. The BUILD phase is what is processed when you just do ?make? in Makefile terms. INSTALL is what happens when you request your project to be installed. The various install() directives in your CMake files will be processed during INSTALL. In Makefile terms, this what happens when you do ?make install? (BUILD is also done in that case since INSTALL always depends on BUILD) So the first question is: does this custom step need to be done at BUILD time or INSTALL time? Running custom code is easier at BUILD time since you have the add_custom_command and the like. If you need to run custom code at INSTALL time, maybe consider this: https://stackoverflow.com/questions/41254902/cmake-run-script-for-install-target ?although I have not done something like this myself. I suspect it is difficult to get just right, depending on the various platforms you support. Does that make sense? -Mike From petr.kmoch at gmail.com Mon Jul 10 14:09:44 2017 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Mon, 10 Jul 2017 20:09:44 +0200 Subject: [CMake] Non OBJECT libraries and population of $ In-Reply-To: References: Message-ID: Hi David. In your particular case, you don't have build everything twice. Just make the SHARED libraries thin wrappers around the OBJECT libraries. Like this: add_library(obj1 OBJECT a.cpp b.cpp ...) add_library(lib1 SHARED $) add_library(obj2 OBJECT c.cpp d.cpp ...) add_library(lib2 SHARED $) add_library(combined SHARED $ $) Petr On 10 July 2017 at 19:41, David Hunter wrote: > Currently you can create an OBJECT library using "add_library( > OBJECT ...)" this populates $ which can then > later be used using something like > "target_sources(name PUBLIC $)". I am wondering if > there is some reason that $ can't be populated when > you create a shared or static library, for instance using > "add_library( SHARED ...)". Looking at the output the VS 2017 > generators for "add_library( OBJECT ...)" it seems to actually > build a static library anyway. I suspect that all the files are > compiled to object files somewhere for both STATIC and SHARED libraries, > if so would it not be possible to point $ as these > object files? > > The reason I ask is that we have a a bunch of source code that builds > in about 100 projects. These projects have a normal hierarchical > dependency tree. However when distributing we want to create larger > libraries that are the combination of various subsets of the smaller ones. > In automake these are called convenience libraries and I suspect they may > have been the reason for CMake OBJECT in the first place. Given the current > behaviour we have to build all the projects twice once in SHARED library > form on once in OBJECT library form. If TARGET_OBJECTS was populated for > SHARED libraries we would not need to build everything twice as we could > build everything SHARED but still use TARGET_OBJECTS to build combination > convenience libraries. > > Of course maybe there's already a way to do this without having to > build twice which I don't know about. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cerobison at utexas.edu Mon Jul 10 14:19:46 2017 From: cerobison at utexas.edu (Christopher E Robison) Date: Mon, 10 Jul 2017 18:19:46 +0000 Subject: [CMake] How to have build steps operate on files in a copied directory? In-Reply-To: References: Message-ID: The INSTALL(SCRIPT ...) syntax might be just the answer I need, thanks!. As I mentioned, the index creating script in the custom step needs to operate on the copied directory tree in its final location, so if it's not all there yet it will fail. So, if CMake has some distinction between "build" and "install" (I'm familiar with Makefiles, where the syntax enforces no such separation -- just targets, dependencies, and commands), then this would mean the step has to be executed at the end of the "install" phase. Can I specify somehow that this install command must be executed after the INSTALL(DIRECTORY ...) command has completed? Thanks, CR On Mon, Jul 10, 2017 at 6:04 PM, Michael Ellery wrote: > > > On Jul 10, 2017, at 10:46 AM, Christopher E Robison < > cerobison at utexas.edu> wrote: > > > > I've recently begun using CMake on an existing project I've taken over, > and I feel like I'm mostly getting used to it, though there is still a vast > amount to learn. I've got nearly the entire project building successfully, > with the exception of a directory of external scripts that need to be > configured at the end of the install process to create some index files. > > > > So, in a nutshell, there's a script that takes care of this post-install > configuration, that needs to be executed once the target tree of > directories and script files are in place, copied from the source tree. And > I'm finding that when the script is called during the build, the > INSTALL(DIRECTORY ...) command from the CMakeLists.txt directory hasn't > been run yet, so the tree of script files hasn't been put in place yet and > the script (and the build) fails. > > > > FWIW, if I leave out the add_custom_command and add_custom_target that > execute the script, the directory tree does copy correctly. > > > > I have not found any guidance on how to specify that the directory tree > gets copied first. How is this normally done? > > > > > > Thanks, > > CR > > > > > > > > I think you might be getting confused by two distinct phases: BUILD and > INSTALL. > > BUILD is what happens when building your sources and all the results of > this step are in your build directory (or source directory if you do > in-source building). Both add_custom_command and add_custom_target are > evaluated (and potentially executed) at BUILD time. The BUILD phase is > what is processed when you just do ?make? in Makefile terms. > > INSTALL is what happens when you request your project to be installed. The > various install() directives in your CMake files will be processed during > INSTALL. In Makefile terms, this what happens when you do ?make install? > (BUILD is also done in that case since INSTALL always depends on BUILD) > > So the first question is: does this custom step need to be done at BUILD > time or INSTALL time? Running custom code is easier at BUILD time since you > have the add_custom_command and the like. If you need to run custom code at > INSTALL time, maybe consider this: > > https://stackoverflow.com/questions/41254902/cmake-run- > script-for-install-target > > ?although I have not done something like this myself. I suspect it is > difficult to get just right, depending on the various platforms you support. > > Does that make sense? > > -Mike > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mellery451 at gmail.com Mon Jul 10 14:25:17 2017 From: mellery451 at gmail.com (Michael Ellery) Date: Mon, 10 Jul 2017 11:25:17 -0700 Subject: [CMake] How to have build steps operate on files in a copied directory? In-Reply-To: References: Message-ID: <874F7AA0-CA6B-4A3A-BD83-31A694FE7D6A@gmail.com> > On Jul 10, 2017, at 11:19 AM, Christopher E Robison wrote: > > The INSTALL(SCRIPT ...) syntax might be just the answer I need, thanks!. > > As I mentioned, the index creating script in the custom step needs to operate on the copied directory tree in its final location, so if it's not all there yet it will fail. So, if CMake has some distinction between "build" and "install" (I'm familiar with Makefiles, where the syntax enforces no such separation -- just targets, dependencies, and commands), then this would mean the step has to be executed at the end of the "install" phase. > > Can I specify somehow that this install command must be executed after the INSTALL(DIRECTORY ...) command has completed? > > > Thanks, > CR > > I *believe* the install directives are executed in the order they are encountered in the processing of CMakeLists files, so putting the custom step as the last item in your top level CMake file might do the trick. From cerobison at utexas.edu Mon Jul 10 14:45:16 2017 From: cerobison at utexas.edu (Christopher E Robison) Date: Mon, 10 Jul 2017 18:45:16 +0000 Subject: [CMake] How to have build steps operate on files in a copied directory? In-Reply-To: <874F7AA0-CA6B-4A3A-BD83-31A694FE7D6A@gmail.com> References: <874F7AA0-CA6B-4A3A-BD83-31A694FE7D6A@gmail.com> Message-ID: It appears to be so -- the install directives execute in incident order, at least from within a single CMakeLists.txt file. The solution ended up being INSTALL(CODE "execute_process(COMMAND ...)"). Feels like a bit of a hack, but the install works on two different platforms -- I'm satisfied for now. Thanks again for the help! CR On Mon, Jul 10, 2017 at 6:25 PM, Michael Ellery wrote: > > > On Jul 10, 2017, at 11:19 AM, Christopher E Robison < > cerobison at utexas.edu> wrote: > > > Can I specify somehow that this install command must be executed after > the INSTALL(DIRECTORY ...) command has completed? > > I *believe* the install directives are executed in the order they are > encountered in the processing of CMakeLists files, so putting the custom > step as the last item in your top level CMake file might do the trick. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From micha.hergarden at gmail.com Mon Jul 10 15:22:04 2017 From: micha.hergarden at gmail.com (Micha Hergarden) Date: Mon, 10 Jul 2017 21:22:04 +0200 Subject: [CMake] cmake create executable Undefined symbols for architecture x86_64: In-Reply-To: References: <14d703d8-bfa9-2bbc-4ca5-e251ece61b92@gmail.com> <466bb2e6-1603-c860-e99b-4642b847f425@gmail.com> Message-ID: <54f08895-d081-420f-bb36-b370483a12db@gmail.com> On 07-07-17 05:14, Sean Wayland wrote: > Hi Micha, > Thanks very much for the email. That seemed to make a small > difference! With both those lines commented out these errors are > generated ( below my email ) . > I still have included > project(CATSMAT) > at the top line of the cmake file in the catsmat directory > > I tried commenting out each of those language type definitions > separately but it didn't seem to help. > The code compiles under xcode. Those language types ( C++14) are > specified in Xcode so I was trying to find a way to copy what is in > xcode. > > Is there a maximum number of "errors" before the clion compiler will > spit the dummy ? > > Another executable will compile with lots and lots of warnings but no "errors" > > I don't know much about C++ unfortunately. These errors look like > simple errors which I could see might be generated if the syntax of > the language had changed slightly from one version to the next .. > > Thanks for you help! > > Sean > > > /Users/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat/cmake/../../libIMUSANT/DomainObjects/inc/IMUSANT_interval.h:78:14: > error: ISO C++ forbids forward references to 'enum' types > > enum direction : int { descending=-1, repeat=0, ascending = 1, > vertical_bottomtotop }; > > > /Users/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat/cmake/../../libIMUSANT/DomainObjects/inc/IMUSANT_interval.h:78:30: > error: expected '(' for function-style cast or type construction > > enum direction : int { descending=-1, repeat=0, ascending = 1, > vertical_bottomtotop }; > > ~~~ ^ > > /Users/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat/cmake/../../libIMUSANT/DomainObjects/inc/IMUSANT_interval.h:78:24: > error: field has incomplete type 'enum direction' > > enum direction : int { descending=-1, repeat=0, ascending = 1, > vertical_bottomtotop }; > > > /Users/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat/cmake/../../libIMUSANT/DomainObjects/inc/IMUSANT_interval.h:78:14: > error: ISO C++ forbids forward references to 'enum' types > > enum direction : int { descending=-1, repeat=0, ascending = 1, > vertical_bottomtotop }; > > ^ > > /Users/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat/cmake/../../libIMUSANT/DomainObjects/inc/IMUSANT_interval.h:78:30: > error: expected '(' for function-style cast or type construction > > enum direction : int { descending=-1, repeat=0, ascending = 1, > vertical_bottomtotop }; > > ~~~ ^ > > /Users/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat/cmake/../../libIMUSANT/DomainObjects/inc/IMUSANT_interval.h:78:24: > error: field has incomplete type 'enum direction' > > enum direction : int { descending=-1, repeat=0, ascending = 1, > vertical_bottomtotop }; > > ^ > > /Users/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat/cmake/../../libIMUSANT/DomainObjects/inc/IMUSANT_interval.h:78:14: > note: forward declaration of 'IMUSANT::direction' > > enum direction : int { descending=-1, repeat=0, ascending = 1, > vertical_bottomtotop }; > > ^ > > /Users/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat/cmake/../../libIMUSANT/DomainObjects/inc/IMUSANT_interval.h:80:14: > error: ISO C++ forbids forward references to 'enum' types > > enum basic : int { unison = 0, second=1, third, fourth, fifth, > sixth, seventh }; > > ^ > > /Users/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat/cmake/../../libIMUSANT/DomainObjects/inc/IMUSANT_interval.h:80:26: > error: expected '(' for function-style cast or type construction > > enum basic : int { unison = 0, second=1, third, fourth, fifth, > sixth, seventh }; > > ~~~ ^ > > /Users/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat/cmake/../../libIMUSANT/DomainObjects/inc/IMUSANT_interval.h:80:20: > error: field has incomplete type 'enum basic' > > enum basic : int { unison = 0, second=1, third, fourth, fifth, > sixth, seventh }; > > > sers/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat/cmake/../../libIMUSANT/DomainObjects/inc/IMUSANT_interval.h:80:14: > error: ISO C++ forbids forward references to 'enum' types > > enum basic : int { unison = 0, second=1, third, fourth, fifth, > sixth, seventh }; > > ^ > > /Users/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat/cmake/../../libIMUSANT/DomainObjects/inc/IMUSANT_interval.h:80:26: > error: expected '(' for function-style cast or type construction > > enum basic : int { unison = 0, second=1, third, fourth, fifth, > sixth, seventh }; > > ~~~ ^ > > /Users/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat/cmake/../../libIMUSANT/DomainObjects/inc/IMUSANT_interval.h:80:20: > error: field has incomplete type 'enum basic' > > enum basic : int { unison = 0, second=1, third, fourth, fifth, > sixth, seventh }; > > > > > /Users/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat/cmake/../../libIMUSANT/FileProcessing/inc/IMUSANT_processing.h:61:35: > error: expected ';' at end of declaration list > > const char * what () const noexcept > > ^ > > ^ > > > > 22 warnings and 12 errors generated. > > make[3]: *** [catsmat/catsmat/cmake/CMakeFiles/catsmat.dir/__/Application/CATSMAT_main.cpp.o] > Error 1 > > make[2]: *** [catsmat/catsmat/cmake/CMakeFiles/catsmat.dir/all] Error 2 > > make[1]: *** [catsmat/catsmat/cmake/CMakeFiles/catsmat.dir/rule] Error 2 > > On Thu, Jul 6, 2017 at 3:12 PM, Micha Hergarden > wrote: >> On 06-07-17 15:59, Sean Wayland wrote: >>> Hi Micha, >>> Thanks very much I tried that .. I added it to the application >>> directory cmakelists.txt file . Same issue .. It's already in the top >>> level cmake file which looks like this .. >>> >>> project(CATSMAT) >>> cmake_minimum_required(VERSION 3.6.3) >>> >>> >>> if (APPLE) >>> >>> set(CMAKE_C++_FLAGS -mmacosx-version-min=10.4) >>> endif (APPLE) >>> >>> >>> include_directories("catsmat/libIMUSANT") >>> >>> add_subdirectory (catsmat/googletest-master/googletest) >>> add_subdirectory (catsmat/libMusicXMLv3/libmusicxml-3.00-src/cmake) >>> add_subdirectory (catsmat/libIMUSANT/cmake) >>> add_subdirectory (catsmat/libIMUSANT_Tests/cmake) >>> add_subdirectory (catsmat/catsmat/cmake) >>> >>> set(CMAKE_CXX_STANDARD 14) >>> >>> On Thu, Jul 6, 2017 at 2:48 AM, Micha Hergarden >>> wrote: >>>> On 05-07-17 22:50, Sean Wayland wrote: >>>>> I am attempting to write a cmakelists.txt file for an application. >>>>> The application has a couple of dependencies. >>>>> I have been able to build targets for the dependencies but when I try >>>>> and add an executable for the main application I encounter this error. >>>>> >>>>> Undefined symbols for architecture x86_64: >>>>> >>>>> "_main", referenced from: >>>>> >>>>> implicit entry/start for main executable >>>>> >>>>> ld: symbol(s) not found for architecture x86_64 >>>>> >>>>> clang: error: linker command failed with exit code 1 (use -v to see invocation) >>>>> >>>>> >>>>> Googling the error and looking on stack exchange suggests that I don't >>>>> have a main function in the implicit entry/start . >>>>> >>>>> Where does it look for this function ? >>>>> Does that file need to be first in the list of sources ? >>>>> >>>>> >>>>> >>>>> This function is included here : >>>>> ${CATSMAT_DIR}/Application/CATSMAT_main.cpp >>>>> >>>>> My cmake file is below. >>>>> >>>>> Any advice would be appreciated I have been stuck here for a while! >>>>> >>>>> Best Sean >>>>> >>>>> >>>>> ####################################### >>>>> # CMAKE CATSTMAT >>>>> ####################################### >>>>> cmake_minimum_required(VERSION 3.6.3) >>>>> set(CMAKE_CXX_STANDARD 14) >>>>> if(CMAKE_CONFIGURATION_TYPES) >>>>> set(CMAKE_CONFIGURATION_TYPES Debug Release) >>>>> endif() >>>>> >>>>> if(UNIX) >>>>> add_definitions(-Wall -DGCC) >>>>> endif(UNIX) >>>>> >>>>> ##### RPATH SETTING ##### >>>>> set(CMAKE_MACOSX_RPATH 1) >>>>> >>>>> #if(APPLE) >>>>> # set (CMAKE_OSX_ARCHITECTURES "x86_64 i386") >>>>> # if (${CMAKE_SYSTEM_VERSION} VERSION_LESS 9.0.0) >>>>> # set (CMAKE_OSX_SYSROOT /Developer/SDKs/MacOSX10.4u.sdk) >>>>> # elseif (${CMAKE_SYSTEM_VERSION} VERSION_LESS 10.8.0) >>>>> # set (CMAKE_OSX_SYSROOT /Developer/SDKs/MacOSX10.5.sdk) >>>>> # elseif (${XCODE_VERSION} VERSION_LESS 4.0.0) >>>>> # set (CMAKE_OSX_SYSROOT /Developer/SDKs/MacOSX10.6.sdk) >>>>> # else () >>>>> # set (CMAKE_OSX_SYSROOT "macosx10.7") >>>>> # endif () >>>>> # set (CMAKE_C++_FLAGS -mmacosx-version-min=10.4) >>>>> #endif(APPLE) >>>>> # >>>>> #if(WIN32) >>>>> # add_definitions(-DWINVER=0x0400 -DWIN32) >>>>> # if(${CMAKE_GENERATOR} STREQUAL "Visual Studio 6") >>>>> # add_definitions(-DVC6) >>>>> # elseif(${CMAKE_GENERATOR} STREQUAL "Visual Studio 8 2005") >>>>> # add_definitions(-DVC2005) >>>>> # endif(${CMAKE_GENERATOR} STREQUAL "Visual Studio 6") >>>>> #endif(WIN32) >>>>> >>>>> ############### BOOST LIBRARIES ########### >>>>> if (APPLE) >>>>> set(BOOST_ROOT "/usr/local/boost") >>>>> set(BOOST_FILESYSTEM_LIB /usr/local/boost/lib/libboost_filesystem.dylib) >>>>> set(BOOST_SYSTEM_LIB /usr/local/boost/lib/libboost_system.dylib) >>>>> >>>>> else (NOT APPLE) >>>>> set(BOOST_ROOT "C:/local/boost_1_58_0") >>>>> set(BOOST_FILESYSTEM_LIB C:/local/boost_1_58_0/lib64-msvc-12.0) >>>>> set(BOOST_SYSTEM_LIB C:/local/boost_1_58_0/lib64-msvc-12.0) >>>>> endif (APPLE) >>>>> >>>>> FIND_PACKAGE( Boost 1.58.0 REQUIRED ) >>>>> INCLUDE_DIRECTORIES( ${Boost_INCLUDE_DIR} ) >>>>> >>>>> >>>>> ####################################### >>>>> # set directories, src and headers. >>>>> >>>>> set (CATSMAT_DIR /Users/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat ) >>>>> set (libIMUSANT_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../../libIMUSANT) >>>>> set (LOKI_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../../Loki) >>>>> set (SUFFIX_TREE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../../SuffixTree) >>>>> set (GOOGLE_TEST_INC_DIR >>>>> ${CMAKE_CURRENT_SOURCE_DIR}/../../googletest-master/googletest/include) >>>>> set (IMUSANT_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../../libIMUSANT) >>>>> >>>>> >>>>> set (LIBMUSICXML_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../../libMusicXMLv3) >>>>> >>>>> >>>>> #### SET SOURCES EXPLICITLY ##### >>>>> >>>>> set(SRC >>>>> >>>>> ${CATSMAT_DIR}/Analysis/src/IMUSANT_contour_suffixtree_builder.cpp >>>>> ${CATSMAT_DIR}/Analysis/src/IMUSANT_generalised_interval_suffixtree_builder.cpp >>>>> ${CATSMAT_DIR}/Analysis/src/IMUSANT_interval_suffixtree_builder.cpp >>>>> ${CATSMAT_DIR}/Analysis/src/IMUSANT_pitch_suffixtree_builder.cpp >>>>> ${CATSMAT_DIR}/Analysis/src/IMUSANT_repeated_interval_substring.cpp >>>>> ${CATSMAT_DIR}/Analysis/src/IMUSANT_t_repeated_substring.cpp >>>>> ${CATSMAT_DIR}/Analysis/src/IMUSANT_VectorMapAnalysisTypes.cpp >>>>> >>>>> ${CATSMAT_DIR}/Application/CATSMAT_main.cpp >>>>> ${CATSMAT_DIR}/Application/CATSMAT_menu.cpp >>>>> >>>>> ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_chord.cpp >>>>> ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_collectionvisitor.cpp >>>>> ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_cp_matrix.cpp >>>>> ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_dyad_sequences.cpp >>>>> ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_dyadtuple_sequences.cpp >>>>> ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_sonority_sequences.cpp >>>>> ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_TrigramSequences.cpp >>>>> ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_TrigramSuffixTreeBuilder.cpp >>>>> >>>>> ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_canonic_techniques_tools.cpp >>>>> ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_partdata.cpp >>>>> ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_processing.cpp >>>>> ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_score_profile.tpp >>>>> ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_score_splitter.cpp >>>>> ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_score_profile_special.cpp >>>>> ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_scoredata.cpp >>>>> ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_scoredatacollector.cpp >>>>> >>>>> ${CATSMAT_DIR}/Segmentation/IMUSANT_segment.cpp >>>>> ${CATSMAT_DIR}/Segmentation/IMUSANT_set_of_segment.cpp >>>>> >>>>> ${CATSMAT_DIR}/Segmentation/FixedPeriodDetection/src/IMUSANT_fixed_period_segmenter.cpp >>>>> ${CATSMAT_DIR}/Segmentation/FixedPeriodDetection/src/IMUSANT_partlist_ordered_by_part_entry.cpp >>>>> ${CATSMAT_DIR}/Segmentation/FixedPeriodDetection/src/IMUSANT_segmented_part_fixed_period.cpp >>>>> ${CATSMAT_DIR}/Segmentation/FixedPeriodDetection/src/SegmentedScoreFixedPeriod.cpp >>>>> >>>>> ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src/IMUSANT_interval_profile_LBDM.cpp >>>>> ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src/IMUSANT_LBDM_segmenter.cpp >>>>> ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src/IMUSANT_segmented_note_vectors.cpp >>>>> ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src/IMUSANT_segmented_part_LBDM.cpp >>>>> ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src/IMUSANT_segmented_profile_vectors.cpp >>>>> ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src/IMUSANT_weighted_strength_vectors.cpp >>>>> >>>>> >>>>> >>>>> >>>>> ) >>>>> >>>>> >>>>> >>>>> >>>>> # old version of adding source code >>>>> >>>>> #set (SRCFOLDERS >>>>> >>>>> >>>>> # ${CATSMAT_DIR}/Analysis/src >>>>> # ${CATSMAT_DIR}/CounterpointAnalysis/src >>>>> # ${CATSMAT_DIR}/GeneralAnalysis/src >>>>> # ${CATSMAT_DIR}/Segmentation/FixedPeriodDetection/src >>>>> # ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src >>>>> # ${CATSMAT_DIR}/Application >>>>> # ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src >>>>> # ${CATSMAT_DIR}/Segmentation >>>>> # ${CATSMAT_DIR}/Utilities >>>>> #) >>>>> >>>>> >>>>> set (INCFOLDERS >>>>> ${libIMUSANT_DIR} >>>>> ${CATSMAT_DIR}/Analysis/inc >>>>> ${CATSMAT_DIR}/Application >>>>> ${CATSMAT_DIR}/CounterpointAnalysis/inc >>>>> ${CATSMAT_DIR}/GeneralAnalysis/inc >>>>> ${CATSMAT_DIR}/Segmentation >>>>> ${CATSMAT_DIR}/Segmentation/FixedPeriodDetection/inc >>>>> ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/inc >>>>> ${CATSMAT_DIR}/Utilities >>>>> ${libIMUSANT_DIR}/DomainObjects/inc >>>>> ${libIMUSANT_DIR}/Utilities/inc >>>>> ${libIMUSANT_DIR}/FileProcessing/inc >>>>> ${libIMUSANT_DIR}/Converters/MusicXML_v3 >>>>> ${libIMUSANT_DIR}/Converters/MusicXML_v3/inc >>>>> ${libIMUSANT_DIR}/Converters/MusicXML_v3/shared/inc >>>>> ${IMUSANT_DIR}/DomainObjects/inc >>>>> ${IMUSANT_DIR}/Converters/MusicXML_v3 >>>>> ${IMUSANT_DIR}/Converters/MusicXML_v3/inc >>>>> ${IMUSANT_DIR}/Converters/Shared/inc >>>>> ${IMUSANT_DIR}/FileProcessing/inc >>>>> ${IMUSANT_DIR}/FileProcessing/Analysis/Segmentation/FixedPeriodDetection/ >>>>> ${IMUSANT_DIR}/Utilities/inc >>>>> ${SUFFIXTREE_DIR} >>>>> ${LIBMUSICXML_DIR}/libmusicxml-3.00-src/src >>>>> ${LIBMUSICXML_DIR}/libmusicxml-3.00-src/src/lib >>>>> ${LIBMUSICXML_DIR}/libmusicxml-3.00-src/src/visitors >>>>> ${LIBMUSICXML_DIR}/libmusicxml-3.00-src/src/parser >>>>> ${LOKI_DIR} >>>>> ${SUFFIX_TREE_DIR} >>>>> ${GOOGLE_TEST_INC_DIR} >>>>> ) >>>>> >>>>> >>>>> #foreach(folder ${SRCFOLDERS}) >>>>> # set(SRC ${SRC} "${folder}/*.cpp") # add source files >>>>> #endforeach(folder) >>>>> #file (GLOB CORESRC RELATIVE ${CMAKE_CURRENT_SOURCE_DIR} ${SRC}) >>>>> >>>>> >>>>> >>>>> ## is this necessary I think target link directories might do the job ? >>>>> >>>>> foreach(folder ${INCFOLDERS}) >>>>> set(HEADERS ${HEADERS} "${folder}/*.h") # add header files >>>>> set(INCL ${INCL} "${folder}") # add include folders >>>>> endforeach(folder) >>>>> file (GLOB COREH RELATIVE ${CMAKE_CURRENT_SOURCE_DIR} ${HEADERS}) >>>>> >>>>> >>>>> ####################################### >>>>> # set includes ( is this needed ? ) >>>>> include_directories( ${INCFOLDERS}) >>>>> set_source_files_properties (${COREH} PROPERTIES HEADER_FILE_ONLY TRUE) >>>>> >>>>> >>>>> ####################################### >>>>> # set library target >>>>> >>>>> #if(APPLE OR MSVC) >>>>> >>>>> set(target catsmat) >>>>> >>>>> # I don't know why these if statements are included they seem to do nothing ' >>>>> #else(APPLE OR MSVC) >>>>> # set(target catsmat) >>>>> #endif(APPLE OR MSVC) >>>>> >>>>> ##if(MSVC) >>>>> ## enable_language(RC) >>>>> ## set(LIBCONTENT ${CORESRC} ${COREH} >>>>> ${CATSMAT_DIR}/win32/libIMUSANT/libIMUSANT.rc) >>>>> ##else(MSVC) >>>>> ## set(LIBCONTENT ${CORESRC} ${COREH}) >>>>> ##endif(MSVC) >>>>> >>>>> add_executable(${target} ${SRC} ) >>>>> >>>>> #### add include directories >>>>> include_directories ( ${INCFOLDERS} ) >>>>> >>>>> ############### Targeted Libraries ########### >>>>> >>>>> TARGET_LINK_LIBRARIES(${target} gtest) >>>>> TARGET_LINK_LIBRARIES(${target} ${BOOST_FILESYSTEM_LIB}) >>>>> TARGET_LINK_LIBRARIES(${target} ${BOOST_SYSTEM_LIB}) >>>>> TARGET_LINK_LIBRARIES(${target} libmusicxml2) >>>>> TARGET_LINK_LIBRARIES(${target} libIMUSANT) >>>>> >>>>> >>>>> set_target_properties (${target} PROPERTIES >>>>> FRAMEWORK TRUE >>>>> VERSION ${VERSION} >>>>> C_STANDARD 99 >>>>> FRAMEWORK_VERSION ${VERSION} >>>>> PUBLIC_HEADER "${COREH}" >>>>> DEFINE_SYMBOL LIBMUSICXML_EXPORTS >>>>> MACOSX_FRAMEWORK_SHORT_VERSION_STRING ${STRVERS} >>>>> MACOSX_FRAMEWORK_BUNDLE_VERSION ${SSTRVERS} >>>>> ) >>>>> >>>>> >>>>> >>>>> ####################################### >>>>> # install setup >>>>> if(NOT APPLE) >>>>> install ( TARGETS ${target} ${TOOLS} >>>>> RUNTIME DESTINATION bin >>>>> LIBRARY DESTINATION lib >>>>> ARCHIVE DESTINATION lib >>>>> FRAMEWORK DESTINATION "/Library/Frameworks" CONFIGURATIONS Release >>>>> PUBLIC_HEADER DESTINATION include/libmusicxml >>>>> ) >>>>> endif(NOT APPLE) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> Hello Sean, >>>> >>>> Could you try adding a 'project(CATSTMAT)' call right at the top of your >>>> CMakeLists.txt? As well as setting a name for the project, this call >>>> also enables languages by default. >>>> >>>> HTH, >>>> Micha >>>> >>>> >>>> >>>> -- >>>> >>>> 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 >>> >> Hi Sean, >> >> I'm also a bit confused as you seem to set 'C_STANDARD 99' as a property >> for the target, as well as 'set(CMAKE_CXX_STANDARD 14)'. I don't know if >> these two settings interfere with each other. Could you remove one of >> the two as an experiment? >> >> Regards, >> Micha >> > > Hello Sean, Unfortunately I don't have experience with the clion compiler, so I can't help you with that. Is there any way I could access this project to see if I can compile it? Does a simple 'hello world' project compile at all? Regards, Micha -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 525 bytes Desc: OpenPGP digital signature URL: From amsabuncu at gmail.com Mon Jul 10 16:06:29 2017 From: amsabuncu at gmail.com (A.M. Sabuncu) Date: Mon, 10 Jul 2017 23:06:29 +0300 Subject: [CMake] Cannot get a 64-bit build of MySQL on a 64-bit Windows machine Message-ID: I am completely new to CMake, and am using to build MySQL 5.7.18 on Windows 10 x64, using the following command: cmake .. -DDOWNLOAD_BOOST=1 -DWITH_BOOST="C:\Boost" -DENABLE_DOWNLOADS=1 I have VS 2017 installed, and I am on 64 bit machine, but for some reason, the above command produces the following output: The CXX compiler identification is MSVC 19.10.25019.0 -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Professional/VC/Tools/MSVC/14.10.25017/bin/HostX86/x86/cl.exe -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Professional/VC/Tools/MSVC/14.10.25017/bin/HostX86/x86/cl.exe -- works The correct compiler is in the HostX64/x64 folder. Thinking that CMake might be looking it up from there, I checked the processor architecture environment variable from the same cmd.exe that I launched the CMake command from, and here's the result: PROCESSOR_ARCHITECTURE=AMD64 When I follow the above CMake command with the following: devenv MySQL.sln /build RelWithDebInfo I get 32-bit results generated, which is not what I want. How can I get CMake to generate a 64-bit build? Thanks so much. -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidhunter22 at gmail.com Mon Jul 10 16:32:36 2017 From: davidhunter22 at gmail.com (David Hunter) Date: Mon, 10 Jul 2017 14:32:36 -0600 Subject: [CMake] Non OBJECT libraries and population of $ In-Reply-To: References: Message-ID: Thanks for the excellent suggestion. Unfortunately we can't really use for Visual Studio. The problem is that the two "add_library" calls result in two visual studio projects. The problem with this is that our generated Visual Studio solution already has 300 odd projects, using you suggestion would result in maybe 500 odd. We are already on the limit of projects in Visual Studio before the IDE becomes unusable. We could of course split the software up into multiple solutions but we are very loath to do this. However it's a great solution for our Ninja builds, so thanks. On Mon, Jul 10, 2017 at 12:09 PM, Petr Kmoch wrote: > Hi David. > > In your particular case, you don't have build everything twice. Just make > the SHARED libraries thin wrappers around the OBJECT libraries. Like this: > > add_library(obj1 OBJECT a.cpp b.cpp ...) > add_library(lib1 SHARED $) > > add_library(obj2 OBJECT c.cpp d.cpp ...) > add_library(lib2 SHARED $) > > add_library(combined SHARED $ $) > > Petr > > On 10 July 2017 at 19:41, David Hunter wrote: >> >> Currently you can create an OBJECT library using "add_library( >> OBJECT ...)" this populates $ which can then >> later be used using something like >> "target_sources(name PUBLIC $)". I am wondering if >> there is some reason that $ can't be populated when >> you create a shared or static library, for instance using >> "add_library( SHARED ...)". Looking at the output the VS 2017 >> generators for "add_library( OBJECT ...)" it seems to actually >> build a static library anyway. I suspect that all the files are >> compiled to object files somewhere for both STATIC and SHARED libraries, >> if so would it not be possible to point $ as these >> object files? >> >> The reason I ask is that we have a a bunch of source code that builds >> in about 100 projects. These projects have a normal hierarchical >> dependency tree. However when distributing we want to create larger >> libraries that are the combination of various subsets of the smaller ones. >> In automake these are called convenience libraries and I suspect they may >> have been the reason for CMake OBJECT in the first place. Given the >> current >> behaviour we have to build all the projects twice once in SHARED library >> form on once in OBJECT library form. If TARGET_OBJECTS was populated for >> SHARED libraries we would not need to build everything twice as we could >> build everything SHARED but still use TARGET_OBJECTS to build combination >> convenience libraries. >> >> Of course maybe there's already a way to do this without having to >> build twice which I don't know about. > > From mailinglists at xgm.de Tue Jul 11 01:07:19 2017 From: mailinglists at xgm.de (Florian Lindner) Date: Tue, 11 Jul 2017 13:07:19 +0800 Subject: [CMake] Can not get C++ 11 support enabled Message-ID: <04458f7e-bada-5ba3-0a4d-993679e2079f@xgm.de> Hello, my complete cmake file looks like that: cmake_minimum_required (VERSION 3.1) project(Preallocation) add_executable(prealloc prealloc_parallel.cpp) set(CMAKE_CXX_STANDARD 11) set(CMAKE_CXX_STANDARD_REQUIRED ON) add_compile_options(-std=c++11) find_library(petsc petsc PATHS $ENV{PETSC_DIR}/$ENV{PETSC_ARCH}/lib) if(NOT petsc) message(FATAL_ERROR "petsc was not found") endif() target_link_libraries(prealloc ${petsc}) find_package(Boost 1.60.0 REQUIRED COMPONENTS program_options) target_link_libraries(prealloc ${Boost_LIBRARIES}) find_package(MPI REQUIRED) target_link_libraries(prealloc ${MPI_LIBRARIES}) set(COMPILE_FLAGS ${COMPILE_FLAGS} ${MPI_COMPILE_FLAGS}) set(LINK_FLAGS ${LINK_FLAGS} ${MPI_LINK_FLAGS}) but still, cmake refused to enable c++11 support, make VERBOSE=1 shows [ 50%] Building CXX object CMakeFiles/prealloc.dir/prealloc_parallel.cpp.o /usr/bin/c++ -O3 -DNDEBUG -o CMakeFiles/prealloc.dir/prealloc_parallel.cpp.o -c /data/scratch/lindnefn/petsc_prealloc/prealloc_parallel.cpp In file included from /usr/include/c++/5/random:35:0, from /data/scratch/lindnefn/petsc_prealloc/prealloc_parallel.cpp:4: /usr/include/c++/5/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support must be enabled with the -std=c++11 or -std=gnu++11 compiler options. #error This file requires compiler and library support \ ^ In file included from /data/scratch/lindnefn/software/petsc/include/petscis.h:7:0, from /data/scratch/lindnefn/software/petsc/include/petscvec.h:9, from /data/scratch/lindnefn/software/petsc/include/petscmat.h:6, from /data/scratch/lindnefn/petsc_prealloc/prealloc_parallel.cpp:7: /data/scratch/lindnefn/software/petsc/include/petscsys.h:130:17: fatal error: mpi.h: No such file or directory compilation terminated. What is wrong here+ cmake 3.5.1 Thanks, Florian From mellery451 at gmail.com Tue Jul 11 01:11:59 2017 From: mellery451 at gmail.com (Michael Ellery) Date: Mon, 10 Jul 2017 22:11:59 -0700 Subject: [CMake] Can not get C++ 11 support enabled In-Reply-To: <04458f7e-bada-5ba3-0a4d-993679e2079f@xgm.de> References: <04458f7e-bada-5ba3-0a4d-993679e2079f@xgm.de> Message-ID: <23190A6D-7C40-4911-8E86-0F8037125747@gmail.com> > On Jul 10, 2017, at 10:07 PM, Florian Lindner wrote: > > Hello, > > my complete cmake file looks like that: > > cmake_minimum_required (VERSION 3.1) > project(Preallocation) > add_executable(prealloc prealloc_parallel.cpp) > > set(CMAKE_CXX_STANDARD 11) > set(CMAKE_CXX_STANDARD_REQUIRED ON) > add_compile_options(-std=c++11) > > find_library(petsc petsc > PATHS $ENV{PETSC_DIR}/$ENV{PETSC_ARCH}/lib) > if(NOT petsc) > message(FATAL_ERROR "petsc was not found") > endif() > target_link_libraries(prealloc ${petsc}) > > find_package(Boost 1.60.0 > REQUIRED > COMPONENTS program_options) > target_link_libraries(prealloc ${Boost_LIBRARIES}) > > find_package(MPI > REQUIRED) > target_link_libraries(prealloc ${MPI_LIBRARIES}) > > set(COMPILE_FLAGS ${COMPILE_FLAGS} ${MPI_COMPILE_FLAGS}) > set(LINK_FLAGS ${LINK_FLAGS} ${MPI_LINK_FLAGS}) > I would try moving the add_executable() to the end of the CMakeLists file (after the set() and find_library calls?) -Mike From craig.scott at crascit.com Tue Jul 11 01:21:35 2017 From: craig.scott at crascit.com (Craig Scott) Date: Tue, 11 Jul 2017 15:21:35 +1000 Subject: [CMake] Can not get C++ 11 support enabled In-Reply-To: <23190A6D-7C40-4911-8E86-0F8037125747@gmail.com> References: <04458f7e-bada-5ba3-0a4d-993679e2079f@xgm.de> <23190A6D-7C40-4911-8E86-0F8037125747@gmail.com> Message-ID: As well as moving the add_executable() call after you set the various CMAKE_CXX... variables, you should also replace the call to add_compile_options(-std=c++11) with the following: set(CMAKE_CXX_EXTENSIONS OFF) On Tue, Jul 11, 2017 at 3:11 PM, Michael Ellery wrote: > > > On Jul 10, 2017, at 10:07 PM, Florian Lindner > wrote: > > > > Hello, > > > > my complete cmake file looks like that: > > > > cmake_minimum_required (VERSION 3.1) > > project(Preallocation) > > add_executable(prealloc prealloc_parallel.cpp) > > > > set(CMAKE_CXX_STANDARD 11) > > set(CMAKE_CXX_STANDARD_REQUIRED ON) > > add_compile_options(-std=c++11) > > > > find_library(petsc petsc > > PATHS $ENV{PETSC_DIR}/$ENV{PETSC_ARCH}/lib) > > if(NOT petsc) > > message(FATAL_ERROR "petsc was not found") > > endif() > > target_link_libraries(prealloc ${petsc}) > > > > find_package(Boost 1.60.0 > > REQUIRED > > COMPONENTS program_options) > > target_link_libraries(prealloc ${Boost_LIBRARIES}) > > > > find_package(MPI > > REQUIRED) > > target_link_libraries(prealloc ${MPI_LIBRARIES}) > > > > set(COMPILE_FLAGS ${COMPILE_FLAGS} ${MPI_COMPILE_FLAGS}) > > set(LINK_FLAGS ${LINK_FLAGS} ${MPI_LINK_FLAGS}) > > > > I would try moving the add_executable() to the end of the CMakeLists file > (after the set() and find_library calls?) > > -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/ > 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 petr.kmoch at gmail.com Tue Jul 11 03:12:12 2017 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Tue, 11 Jul 2017 09:12:12 +0200 Subject: [CMake] Cannot get a 64-bit build of MySQL on a 64-bit Windows machine In-Reply-To: References: Message-ID: Hi, when generating a Visual Studio buildsystem with CMake, you can specify the target architecture. If you don't, the default is 32-bit. To specify the architecture, either put it into the generator name: cmake .. -G "Visual Studio 15 2017 Win64" .... or specify just the architecture using -A: cmake .. -A Win64 .... See description of -G and -A in CMake docs: https://cmake.org/cmake/help/latest/manual/cmake.1.html Petr On 10 July 2017 at 22:06, A.M. Sabuncu wrote: > I am completely new to CMake, and am using to build MySQL 5.7.18 on > Windows 10 x64, using the following command: > > cmake .. -DDOWNLOAD_BOOST=1 -DWITH_BOOST="C:\Boost" -DENABLE_DOWNLOADS=1 > > I have VS 2017 installed, and I am on 64 bit machine, but for some reason, > the above command produces the following output: > > The CXX compiler identification is MSVC 19.10.25019.0 > -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual > Studio/2017/Professional/VC/Tools/MSVC/14.10.25017/bin/HostX86/x86/cl.exe > -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual > Studio/2017/Professional/VC/Tools/MSVC/14.10.25017/bin/HostX86/x86/cl.exe > -- works > > The correct compiler is in the HostX64/x64 folder. > > Thinking that CMake might be looking it up from there, I checked the > processor architecture environment variable from the same cmd.exe that I > launched the CMake command from, and here's the result: > > PROCESSOR_ARCHITECTURE=AMD64 > > When I follow the above CMake command with the following: > > devenv MySQL.sln /build RelWithDebInfo > > I get 32-bit results generated, which is not what I want. > > How can I get CMake to generate a 64-bit build? > > Thanks so much. > > > -- > > 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 petr.kmoch at gmail.com Tue Jul 11 03:18:19 2017 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Tue, 11 Jul 2017 09:18:19 +0200 Subject: [CMake] Can not get C++ 11 support enabled In-Reply-To: References: <04458f7e-bada-5ba3-0a4d-993679e2079f@xgm.de> <23190A6D-7C40-4911-8E86-0F8037125747@gmail.com> Message-ID: As others have suggested, moving the add_executable() after the set() calls is the correct solution. The reason is that variables like CMAKE_CXX_STANDARD are used to pre-initialise a target's properties when the target is created. In other words, at the time add_executable() is called, CMake will inspect variables like CMAKE_CXX_STANDARD and use them to initialise the target's properties like CXX_STANDARD. It's the properties which really control the target's build. See https://cmake.org/cmake/help/latest/variable/CMAKE_CXX_STANDARD.html and https://cmake.org/cmake/help/latest/prop_tgt/CXX_STANDARD.html for details. The same applies to add_compile_options(). From its docs ( https://cmake.org/cmake/help/latest/command/add_compile_options.html ): "Adds options to the compiler command line for targets in the current directory and below that are added after this command is invoked" But Craig is right that you shouldn't add `-std` directly, but use CXX_STANDARD and CXX_EXTENSIONS instead. Petr On 11 July 2017 at 07:21, Craig Scott wrote: > As well as moving the add_executable() call after you set the various > CMAKE_CXX... variables, you should also replace the call to > add_compile_options(-std=c++11) with the following: > > set(CMAKE_CXX_EXTENSIONS OFF) > > > On Tue, Jul 11, 2017 at 3:11 PM, Michael Ellery > wrote: > >> >> > On Jul 10, 2017, at 10:07 PM, Florian Lindner >> wrote: >> > >> > Hello, >> > >> > my complete cmake file looks like that: >> > >> > cmake_minimum_required (VERSION 3.1) >> > project(Preallocation) >> > add_executable(prealloc prealloc_parallel.cpp) >> > >> > set(CMAKE_CXX_STANDARD 11) >> > set(CMAKE_CXX_STANDARD_REQUIRED ON) >> > add_compile_options(-std=c++11) >> > >> > find_library(petsc petsc >> > PATHS $ENV{PETSC_DIR}/$ENV{PETSC_ARCH}/lib) >> > if(NOT petsc) >> > message(FATAL_ERROR "petsc was not found") >> > endif() >> > target_link_libraries(prealloc ${petsc}) >> > >> > find_package(Boost 1.60.0 >> > REQUIRED >> > COMPONENTS program_options) >> > target_link_libraries(prealloc ${Boost_LIBRARIES}) >> > >> > find_package(MPI >> > REQUIRED) >> > target_link_libraries(prealloc ${MPI_LIBRARIES}) >> > >> > set(COMPILE_FLAGS ${COMPILE_FLAGS} ${MPI_COMPILE_FLAGS}) >> > set(LINK_FLAGS ${LINK_FLAGS} ${MPI_LINK_FLAGS}) >> > >> >> I would try moving the add_executable() to the end of the CMakeLists file >> (after the set() and find_library calls?) >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jakub.Zakrzewski at scheer-group.com Tue Jul 11 03:34:16 2017 From: Jakub.Zakrzewski at scheer-group.com (Zakrzewski, Jakub) Date: Tue, 11 Jul 2017 07:34:16 +0000 Subject: [CMake] [DKIM] Re: cmake create executable Undefined symbols for architecture x86_64: In-Reply-To: <54f08895-d081-420f-bb36-b370483a12db@gmail.com> References: <14d703d8-bfa9-2bbc-4ca5-e251ece61b92@gmail.com> <466bb2e6-1603-c860-e99b-4642b847f425@gmail.com> , <54f08895-d081-420f-bb36-b370483a12db@gmail.com> Message-ID: <1499758456023.52005@scheer-group.com> ________________________________________ From: CMake on behalf of Micha Hergarden Sent: 10 July 2017 21:22 To: seanwayland at gmail.com Cc: cmake at cmake.org Subject: [DKIM] Re: [CMake] cmake create executable Undefined symbols for architecture x86_64: On 07-07-17 05:14, Sean Wayland wrote: > Hi Micha, > Thanks very much for the email. That seemed to make a small > difference! With both those lines commented out these errors are > generated ( below my email ) . > I still have included > project(CATSMAT) > at the top line of the cmake file in the catsmat directory > > I tried commenting out each of those language type definitions > separately but it didn't seem to help. > The code compiles under xcode. Those language types ( C++14) are > specified in Xcode so I was trying to find a way to copy what is in > xcode. > > Is there a maximum number of "errors" before the clion compiler will > spit the dummy ? > > Another executable will compile with lots and lots of warnings but no "errors" > > I don't know much about C++ unfortunately. These errors look like > simple errors which I could see might be generated if the syntax of > the language had changed slightly from one version to the next .. > > Thanks for you help! > > Sean > > > /Users/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat/cmake/../../libIMUSANT/DomainObjects/inc/IMUSANT_interval.h:78:14: > error: ISO C++ forbids forward references to 'enum' types > > enum direction : int { descending=-1, repeat=0, ascending = 1, > vertical_bottomtotop }; > > > /Users/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat/cmake/../../libIMUSANT/DomainObjects/inc/IMUSANT_interval.h:78:30: > error: expected '(' for function-style cast or type construction > > enum direction : int { descending=-1, repeat=0, ascending = 1, > vertical_bottomtotop }; > > ~~~ ^ > > /Users/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat/cmake/../../libIMUSANT/DomainObjects/inc/IMUSANT_interval.h:78:24: > error: field has incomplete type 'enum direction' > > enum direction : int { descending=-1, repeat=0, ascending = 1, > vertical_bottomtotop }; > > > /Users/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat/cmake/../../libIMUSANT/DomainObjects/inc/IMUSANT_interval.h:78:14: > error: ISO C++ forbids forward references to 'enum' types > > enum direction : int { descending=-1, repeat=0, ascending = 1, > vertical_bottomtotop }; > > ^ > > /Users/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat/cmake/../../libIMUSANT/DomainObjects/inc/IMUSANT_interval.h:78:30: > error: expected '(' for function-style cast or type construction > > enum direction : int { descending=-1, repeat=0, ascending = 1, > vertical_bottomtotop }; > > ~~~ ^ > > /Users/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat/cmake/../../libIMUSANT/DomainObjects/inc/IMUSANT_interval.h:78:24: > error: field has incomplete type 'enum direction' > > enum direction : int { descending=-1, repeat=0, ascending = 1, > vertical_bottomtotop }; > > ^ > > /Users/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat/cmake/../../libIMUSANT/DomainObjects/inc/IMUSANT_interval.h:78:14: > note: forward declaration of 'IMUSANT::direction' > > enum direction : int { descending=-1, repeat=0, ascending = 1, > vertical_bottomtotop }; > > ^ > > /Users/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat/cmake/../../libIMUSANT/DomainObjects/inc/IMUSANT_interval.h:80:14: > error: ISO C++ forbids forward references to 'enum' types > > enum basic : int { unison = 0, second=1, third, fourth, fifth, > sixth, seventh }; > > ^ > > /Users/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat/cmake/../../libIMUSANT/DomainObjects/inc/IMUSANT_interval.h:80:26: > error: expected '(' for function-style cast or type construction > > enum basic : int { unison = 0, second=1, third, fourth, fifth, > sixth, seventh }; > > ~~~ ^ > > /Users/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat/cmake/../../libIMUSANT/DomainObjects/inc/IMUSANT_interval.h:80:20: > error: field has incomplete type 'enum basic' > > enum basic : int { unison = 0, second=1, third, fourth, fifth, > sixth, seventh }; > > > sers/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat/cmake/../../libIMUSANT/DomainObjects/inc/IMUSANT_interval.h:80:14: > error: ISO C++ forbids forward references to 'enum' types > > enum basic : int { unison = 0, second=1, third, fourth, fifth, > sixth, seventh }; > > ^ > > /Users/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat/cmake/../../libIMUSANT/DomainObjects/inc/IMUSANT_interval.h:80:26: > error: expected '(' for function-style cast or type construction > > enum basic : int { unison = 0, second=1, third, fourth, fifth, > sixth, seventh }; > > ~~~ ^ > > /Users/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat/cmake/../../libIMUSANT/DomainObjects/inc/IMUSANT_interval.h:80:20: > error: field has incomplete type 'enum basic' > > enum basic : int { unison = 0, second=1, third, fourth, fifth, > sixth, seventh }; > > > > > /Users/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat/cmake/../../libIMUSANT/FileProcessing/inc/IMUSANT_processing.h:61:35: > error: expected ';' at end of declaration list > > const char * what () const noexcept > > ^ > > ^ > > > > 22 warnings and 12 errors generated. > > make[3]: *** [catsmat/catsmat/cmake/CMakeFiles/catsmat.dir/__/Application/CATSMAT_main.cpp.o] > Error 1 > > make[2]: *** [catsmat/catsmat/cmake/CMakeFiles/catsmat.dir/all] Error 2 > > make[1]: *** [catsmat/catsmat/cmake/CMakeFiles/catsmat.dir/rule] Error 2 > > On Thu, Jul 6, 2017 at 3:12 PM, Micha Hergarden > wrote: >> On 06-07-17 15:59, Sean Wayland wrote: >>> Hi Micha, >>> Thanks very much I tried that .. I added it to the application >>> directory cmakelists.txt file . Same issue .. It's already in the top >>> level cmake file which looks like this .. >>> >>> project(CATSMAT) >>> cmake_minimum_required(VERSION 3.6.3) >>> >>> >>> if (APPLE) >>> >>> set(CMAKE_C++_FLAGS -mmacosx-version-min=10.4) >>> endif (APPLE) >>> >>> >>> include_directories("catsmat/libIMUSANT") >>> >>> add_subdirectory (catsmat/googletest-master/googletest) >>> add_subdirectory (catsmat/libMusicXMLv3/libmusicxml-3.00-src/cmake) >>> add_subdirectory (catsmat/libIMUSANT/cmake) >>> add_subdirectory (catsmat/libIMUSANT_Tests/cmake) >>> add_subdirectory (catsmat/catsmat/cmake) >>> >>> set(CMAKE_CXX_STANDARD 14) >>> >>> On Thu, Jul 6, 2017 at 2:48 AM, Micha Hergarden >>> wrote: >>>> On 05-07-17 22:50, Sean Wayland wrote: >>>>> I am attempting to write a cmakelists.txt file for an application. >>>>> The application has a couple of dependencies. >>>>> I have been able to build targets for the dependencies but when I try >>>>> and add an executable for the main application I encounter this error. >>>>> >>>>> Undefined symbols for architecture x86_64: >>>>> >>>>> "_main", referenced from: >>>>> >>>>> implicit entry/start for main executable >>>>> >>>>> ld: symbol(s) not found for architecture x86_64 >>>>> >>>>> clang: error: linker command failed with exit code 1 (use -v to see invocation) >>>>> >>>>> >>>>> Googling the error and looking on stack exchange suggests that I don't >>>>> have a main function in the implicit entry/start . >>>>> >>>>> Where does it look for this function ? >>>>> Does that file need to be first in the list of sources ? >>>>> >>>>> >>>>> >>>>> This function is included here : >>>>> ${CATSMAT_DIR}/Application/CATSMAT_main.cpp >>>>> >>>>> My cmake file is below. >>>>> >>>>> Any advice would be appreciated I have been stuck here for a while! >>>>> >>>>> Best Sean >>>>> >>>>> >>>>> ####################################### >>>>> # CMAKE CATSTMAT >>>>> ####################################### >>>>> cmake_minimum_required(VERSION 3.6.3) >>>>> set(CMAKE_CXX_STANDARD 14) >>>>> if(CMAKE_CONFIGURATION_TYPES) >>>>> set(CMAKE_CONFIGURATION_TYPES Debug Release) >>>>> endif() >>>>> >>>>> if(UNIX) >>>>> add_definitions(-Wall -DGCC) >>>>> endif(UNIX) >>>>> >>>>> ##### RPATH SETTING ##### >>>>> set(CMAKE_MACOSX_RPATH 1) >>>>> >>>>> #if(APPLE) >>>>> # set (CMAKE_OSX_ARCHITECTURES "x86_64 i386") >>>>> # if (${CMAKE_SYSTEM_VERSION} VERSION_LESS 9.0.0) >>>>> # set (CMAKE_OSX_SYSROOT /Developer/SDKs/MacOSX10.4u.sdk) >>>>> # elseif (${CMAKE_SYSTEM_VERSION} VERSION_LESS 10.8.0) >>>>> # set (CMAKE_OSX_SYSROOT /Developer/SDKs/MacOSX10.5.sdk) >>>>> # elseif (${XCODE_VERSION} VERSION_LESS 4.0.0) >>>>> # set (CMAKE_OSX_SYSROOT /Developer/SDKs/MacOSX10.6.sdk) >>>>> # else () >>>>> # set (CMAKE_OSX_SYSROOT "macosx10.7") >>>>> # endif () >>>>> # set (CMAKE_C++_FLAGS -mmacosx-version-min=10.4) >>>>> #endif(APPLE) >>>>> # >>>>> #if(WIN32) >>>>> # add_definitions(-DWINVER=0x0400 -DWIN32) >>>>> # if(${CMAKE_GENERATOR} STREQUAL "Visual Studio 6") >>>>> # add_definitions(-DVC6) >>>>> # elseif(${CMAKE_GENERATOR} STREQUAL "Visual Studio 8 2005") >>>>> # add_definitions(-DVC2005) >>>>> # endif(${CMAKE_GENERATOR} STREQUAL "Visual Studio 6") >>>>> #endif(WIN32) >>>>> >>>>> ############### BOOST LIBRARIES ########### >>>>> if (APPLE) >>>>> set(BOOST_ROOT "/usr/local/boost") >>>>> set(BOOST_FILESYSTEM_LIB /usr/local/boost/lib/libboost_filesystem.dylib) >>>>> set(BOOST_SYSTEM_LIB /usr/local/boost/lib/libboost_system.dylib) >>>>> >>>>> else (NOT APPLE) >>>>> set(BOOST_ROOT "C:/local/boost_1_58_0") >>>>> set(BOOST_FILESYSTEM_LIB C:/local/boost_1_58_0/lib64-msvc-12.0) >>>>> set(BOOST_SYSTEM_LIB C:/local/boost_1_58_0/lib64-msvc-12.0) >>>>> endif (APPLE) >>>>> >>>>> FIND_PACKAGE( Boost 1.58.0 REQUIRED ) >>>>> INCLUDE_DIRECTORIES( ${Boost_INCLUDE_DIR} ) >>>>> >>>>> >>>>> ####################################### >>>>> # set directories, src and headers. >>>>> >>>>> set (CATSMAT_DIR /Users/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat ) >>>>> set (libIMUSANT_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../../libIMUSANT) >>>>> set (LOKI_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../../Loki) >>>>> set (SUFFIX_TREE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../../SuffixTree) >>>>> set (GOOGLE_TEST_INC_DIR >>>>> ${CMAKE_CURRENT_SOURCE_DIR}/../../googletest-master/googletest/include) >>>>> set (IMUSANT_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../../libIMUSANT) >>>>> >>>>> >>>>> set (LIBMUSICXML_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../../libMusicXMLv3) >>>>> >>>>> >>>>> #### SET SOURCES EXPLICITLY ##### >>>>> >>>>> set(SRC >>>>> >>>>> ${CATSMAT_DIR}/Analysis/src/IMUSANT_contour_suffixtree_builder.cpp >>>>> ${CATSMAT_DIR}/Analysis/src/IMUSANT_generalised_interval_suffixtree_builder.cpp >>>>> ${CATSMAT_DIR}/Analysis/src/IMUSANT_interval_suffixtree_builder.cpp >>>>> ${CATSMAT_DIR}/Analysis/src/IMUSANT_pitch_suffixtree_builder.cpp >>>>> ${CATSMAT_DIR}/Analysis/src/IMUSANT_repeated_interval_substring.cpp >>>>> ${CATSMAT_DIR}/Analysis/src/IMUSANT_t_repeated_substring.cpp >>>>> ${CATSMAT_DIR}/Analysis/src/IMUSANT_VectorMapAnalysisTypes.cpp >>>>> >>>>> ${CATSMAT_DIR}/Application/CATSMAT_main.cpp >>>>> ${CATSMAT_DIR}/Application/CATSMAT_menu.cpp >>>>> >>>>> ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_chord.cpp >>>>> ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_collectionvisitor.cpp >>>>> ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_cp_matrix.cpp >>>>> ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_dyad_sequences.cpp >>>>> ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_dyadtuple_sequences.cpp >>>>> ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_sonority_sequences.cpp >>>>> ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_TrigramSequences.cpp >>>>> ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_TrigramSuffixTreeBuilder.cpp >>>>> >>>>> ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_canonic_techniques_tools.cpp >>>>> ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_partdata.cpp >>>>> ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_processing.cpp >>>>> ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_score_profile.tpp >>>>> ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_score_splitter.cpp >>>>> ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_score_profile_special.cpp >>>>> ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_scoredata.cpp >>>>> ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_scoredatacollector.cpp >>>>> >>>>> ${CATSMAT_DIR}/Segmentation/IMUSANT_segment.cpp >>>>> ${CATSMAT_DIR}/Segmentation/IMUSANT_set_of_segment.cpp >>>>> >>>>> ${CATSMAT_DIR}/Segmentation/FixedPeriodDetection/src/IMUSANT_fixed_period_segmenter.cpp >>>>> ${CATSMAT_DIR}/Segmentation/FixedPeriodDetection/src/IMUSANT_partlist_ordered_by_part_entry.cpp >>>>> ${CATSMAT_DIR}/Segmentation/FixedPeriodDetection/src/IMUSANT_segmented_part_fixed_period.cpp >>>>> ${CATSMAT_DIR}/Segmentation/FixedPeriodDetection/src/SegmentedScoreFixedPeriod.cpp >>>>> >>>>> ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src/IMUSANT_interval_profile_LBDM.cpp >>>>> ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src/IMUSANT_LBDM_segmenter.cpp >>>>> ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src/IMUSANT_segmented_note_vectors.cpp >>>>> ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src/IMUSANT_segmented_part_LBDM.cpp >>>>> ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src/IMUSANT_segmented_profile_vectors.cpp >>>>> ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src/IMUSANT_weighted_strength_vectors.cpp >>>>> >>>>> >>>>> >>>>> >>>>> ) >>>>> >>>>> >>>>> >>>>> >>>>> # old version of adding source code >>>>> >>>>> #set (SRCFOLDERS >>>>> >>>>> >>>>> # ${CATSMAT_DIR}/Analysis/src >>>>> # ${CATSMAT_DIR}/CounterpointAnalysis/src >>>>> # ${CATSMAT_DIR}/GeneralAnalysis/src >>>>> # ${CATSMAT_DIR}/Segmentation/FixedPeriodDetection/src >>>>> # ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src >>>>> # ${CATSMAT_DIR}/Application >>>>> # ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src >>>>> # ${CATSMAT_DIR}/Segmentation >>>>> # ${CATSMAT_DIR}/Utilities >>>>> #) >>>>> >>>>> >>>>> set (INCFOLDERS >>>>> ${libIMUSANT_DIR} >>>>> ${CATSMAT_DIR}/Analysis/inc >>>>> ${CATSMAT_DIR}/Application >>>>> ${CATSMAT_DIR}/CounterpointAnalysis/inc >>>>> ${CATSMAT_DIR}/GeneralAnalysis/inc >>>>> ${CATSMAT_DIR}/Segmentation >>>>> ${CATSMAT_DIR}/Segmentation/FixedPeriodDetection/inc >>>>> ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/inc >>>>> ${CATSMAT_DIR}/Utilities >>>>> ${libIMUSANT_DIR}/DomainObjects/inc >>>>> ${libIMUSANT_DIR}/Utilities/inc >>>>> ${libIMUSANT_DIR}/FileProcessing/inc >>>>> ${libIMUSANT_DIR}/Converters/MusicXML_v3 >>>>> ${libIMUSANT_DIR}/Converters/MusicXML_v3/inc >>>>> ${libIMUSANT_DIR}/Converters/MusicXML_v3/shared/inc >>>>> ${IMUSANT_DIR}/DomainObjects/inc >>>>> ${IMUSANT_DIR}/Converters/MusicXML_v3 >>>>> ${IMUSANT_DIR}/Converters/MusicXML_v3/inc >>>>> ${IMUSANT_DIR}/Converters/Shared/inc >>>>> ${IMUSANT_DIR}/FileProcessing/inc >>>>> ${IMUSANT_DIR}/FileProcessing/Analysis/Segmentation/FixedPeriodDetection/ >>>>> ${IMUSANT_DIR}/Utilities/inc >>>>> ${SUFFIXTREE_DIR} >>>>> ${LIBMUSICXML_DIR}/libmusicxml-3.00-src/src >>>>> ${LIBMUSICXML_DIR}/libmusicxml-3.00-src/src/lib >>>>> ${LIBMUSICXML_DIR}/libmusicxml-3.00-src/src/visitors >>>>> ${LIBMUSICXML_DIR}/libmusicxml-3.00-src/src/parser >>>>> ${LOKI_DIR} >>>>> ${SUFFIX_TREE_DIR} >>>>> ${GOOGLE_TEST_INC_DIR} >>>>> ) >>>>> >>>>> >>>>> #foreach(folder ${SRCFOLDERS}) >>>>> # set(SRC ${SRC} "${folder}/*.cpp") # add source files >>>>> #endforeach(folder) >>>>> #file (GLOB CORESRC RELATIVE ${CMAKE_CURRENT_SOURCE_DIR} ${SRC}) >>>>> >>>>> >>>>> >>>>> ## is this necessary I think target link directories might do the job ? >>>>> >>>>> foreach(folder ${INCFOLDERS}) >>>>> set(HEADERS ${HEADERS} "${folder}/*.h") # add header files >>>>> set(INCL ${INCL} "${folder}") # add include folders >>>>> endforeach(folder) >>>>> file (GLOB COREH RELATIVE ${CMAKE_CURRENT_SOURCE_DIR} ${HEADERS}) >>>>> >>>>> >>>>> ####################################### >>>>> # set includes ( is this needed ? ) >>>>> include_directories( ${INCFOLDERS}) >>>>> set_source_files_properties (${COREH} PROPERTIES HEADER_FILE_ONLY TRUE) >>>>> >>>>> >>>>> ####################################### >>>>> # set library target >>>>> >>>>> #if(APPLE OR MSVC) >>>>> >>>>> set(target catsmat) >>>>> >>>>> # I don't know why these if statements are included they seem to do nothing ' >>>>> #else(APPLE OR MSVC) >>>>> # set(target catsmat) >>>>> #endif(APPLE OR MSVC) >>>>> >>>>> ##if(MSVC) >>>>> ## enable_language(RC) >>>>> ## set(LIBCONTENT ${CORESRC} ${COREH} >>>>> ${CATSMAT_DIR}/win32/libIMUSANT/libIMUSANT.rc) >>>>> ##else(MSVC) >>>>> ## set(LIBCONTENT ${CORESRC} ${COREH}) >>>>> ##endif(MSVC) >>>>> >>>>> add_executable(${target} ${SRC} ) >>>>> >>>>> #### add include directories >>>>> include_directories ( ${INCFOLDERS} ) >>>>> >>>>> ############### Targeted Libraries ########### >>>>> >>>>> TARGET_LINK_LIBRARIES(${target} gtest) >>>>> TARGET_LINK_LIBRARIES(${target} ${BOOST_FILESYSTEM_LIB}) >>>>> TARGET_LINK_LIBRARIES(${target} ${BOOST_SYSTEM_LIB}) >>>>> TARGET_LINK_LIBRARIES(${target} libmusicxml2) >>>>> TARGET_LINK_LIBRARIES(${target} libIMUSANT) >>>>> >>>>> >>>>> set_target_properties (${target} PROPERTIES >>>>> FRAMEWORK TRUE >>>>> VERSION ${VERSION} >>>>> C_STANDARD 99 >>>>> FRAMEWORK_VERSION ${VERSION} >>>>> PUBLIC_HEADER "${COREH}" >>>>> DEFINE_SYMBOL LIBMUSICXML_EXPORTS >>>>> MACOSX_FRAMEWORK_SHORT_VERSION_STRING ${STRVERS} >>>>> MACOSX_FRAMEWORK_BUNDLE_VERSION ${SSTRVERS} >>>>> ) >>>>> >>>>> >>>>> >>>>> ####################################### >>>>> # install setup >>>>> if(NOT APPLE) >>>>> install ( TARGETS ${target} ${TOOLS} >>>>> RUNTIME DESTINATION bin >>>>> LIBRARY DESTINATION lib >>>>> ARCHIVE DESTINATION lib >>>>> FRAMEWORK DESTINATION "/Library/Frameworks" CONFIGURATIONS Release >>>>> PUBLIC_HEADER DESTINATION include/libmusicxml >>>>> ) >>>>> endif(NOT APPLE) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> Hello Sean, >>>> >>>> Could you try adding a 'project(CATSTMAT)' call right at the top of your >>>> CMakeLists.txt? As well as setting a name for the project, this call >>>> also enables languages by default. >>>> >>>> HTH, >>>> Micha >>>> >>>> >>>> >>>> -- >>>> >>>> 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 >>> >> Hi Sean, >> >> I'm also a bit confused as you seem to set 'C_STANDARD 99' as a property >> for the target, as well as 'set(CMAKE_CXX_STANDARD 14)'. I don't know if >> these two settings interfere with each other. Could you remove one of >> the two as an experiment? >> >> Regards, >> Micha >> > > > Hello Sean, > >Unfortunately I don't have experience with the clion compiler, so I >can't help you with that. Is there any way I could access this project >t.o see if I can compile it? Does a simple 'hello world' project compile >at all? > >Regards, >Micha There's no "clion compiler". Clion uses CMake to generate makefiles. It works either with GCC, clang or (recently) MSVC. So there's no magic here. From amsabuncu at gmail.com Tue Jul 11 06:13:11 2017 From: amsabuncu at gmail.com (A.M. Sabuncu) Date: Tue, 11 Jul 2017 13:13:11 +0300 Subject: [CMake] Cannot get a 64-bit build of MySQL on a 64-bit Windows machine In-Reply-To: References: Message-ID: Petr, Thank you so much. The following command you suggested fixed the problem, and I was able to run a successful build: cmake .. -G "Visual Studio 15 2017 Win64" I am grateful for your help. This may have been a minor item for you, but for me, it was a real stumbling block. By the way, the other alternative you suggested did not work: cmake .. -A Win64 (or "Win64") The result was: -- Building for: Visual Studio 15 2017 -- Running cmake version 3.8.2 -- Found Git: C:/Program Files/Git/cmd/git.exe (found version "2.10.2.windows.1") -- Configuring with MAX_INDEXES = 64U -- The C compiler identification is unknown -- The CXX compiler identification is unknown CMake Error at CMakeLists.txt:126 (PROJECT): No CMAKE_C_COMPILER could be found. The funny thing is that the use of the -G flag does not issue a "Building for..." message, but correctly locates the necessary compiler, whereas the -A flag seems to know what target it is building for, but cannot find the compiler! Thank you again, A. M. Sabuncu On Tue, Jul 11, 2017 at 10:12 AM, Petr Kmoch wrote: > Hi, > > when generating a Visual Studio buildsystem with CMake, you can specify > the target architecture. If you don't, the default is 32-bit. > > To specify the architecture, either put it into the generator name: > > cmake .. -G "Visual Studio 15 2017 Win64" .... > > or specify just the architecture using -A: > > cmake .. -A Win64 .... > > See description of -G and -A in CMake docs: https://cmake.org/cmake/help/ > latest/manual/cmake.1.html > > Petr > > On 10 July 2017 at 22:06, A.M. Sabuncu wrote: > >> I am completely new to CMake, and am using to build MySQL 5.7.18 on >> Windows 10 x64, using the following command: >> >> cmake .. -DDOWNLOAD_BOOST=1 -DWITH_BOOST="C:\Boost" -DENABLE_DOWNLOADS=1 >> >> I have VS 2017 installed, and I am on 64 bit machine, but for some >> reason, the above command produces the following output: >> >> The CXX compiler identification is MSVC 19.10.25019.0 >> -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual >> Studio/2017/Professional/VC/Tools/MSVC/14.10.25017/bin/HostX86/x86/cl.exe >> -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual >> Studio/2017/Professional/VC/Tools/MSVC/14.10.25017/bin/HostX86/x86/cl.exe >> -- works >> >> The correct compiler is in the HostX64/x64 folder. >> >> Thinking that CMake might be looking it up from there, I checked the >> processor architecture environment variable from the same cmd.exe that I >> launched the CMake command from, and here's the result: >> >> PROCESSOR_ARCHITECTURE=AMD64 >> >> When I follow the above CMake command with the following: >> >> devenv MySQL.sln /build RelWithDebInfo >> >> I get 32-bit results generated, which is not what I want. >> >> How can I get CMake to generate a 64-bit build? >> >> Thanks so much. >> >> >> -- >> >> 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 d3ck0r at gmail.com Tue Jul 11 06:50:33 2017 From: d3ck0r at gmail.com (J Decker) Date: Tue, 11 Jul 2017 03:50:33 -0700 Subject: [CMake] Cannot get a 64-bit build of MySQL on a 64-bit Windows machine In-Reply-To: References: Message-ID: Alternatively you could use cmake-gui and on first generation in an empty directoy, a popup window appears allowing you to select the generator. mkdir build2 cd build2 cmake-gui .. then set the various flags in the gui. On Tue, Jul 11, 2017 at 3:13 AM, A.M. Sabuncu wrote: > Petr, > > Thank you so much. The following command you suggested fixed the problem, > and I was able to run a successful build: > > cmake .. -G "Visual Studio 15 2017 Win64" > > I am grateful for your help. This may have been a minor item for you, but > for me, it was a real stumbling block. > > By the way, the other alternative you suggested did not work: > > cmake .. -A Win64 (or "Win64") > > The result was: > > -- Building for: Visual Studio 15 2017 > -- Running cmake version 3.8.2 > -- Found Git: C:/Program Files/Git/cmd/git.exe (found version > "2.10.2.windows.1") > -- Configuring with MAX_INDEXES = 64U > -- The C compiler identification is unknown > -- The CXX compiler identification is unknown > CMake Error at CMakeLists.txt:126 (PROJECT): > No CMAKE_C_COMPILER could be found. > > The funny thing is that the use of the -G flag does not issue a "Building > for..." message, but correctly locates the necessary compiler, whereas the > -A flag seems to know what target it is building for, but cannot find the > compiler! > > Thank you again, > > A. M. Sabuncu > > On Tue, Jul 11, 2017 at 10:12 AM, Petr Kmoch wrote: > >> Hi, >> >> when generating a Visual Studio buildsystem with CMake, you can specify >> the target architecture. If you don't, the default is 32-bit. >> >> To specify the architecture, either put it into the generator name: >> >> cmake .. -G "Visual Studio 15 2017 Win64" .... >> >> or specify just the architecture using -A: >> >> cmake .. -A Win64 .... >> >> See description of -G and -A in CMake docs: >> https://cmake.org/cmake/help/latest/manual/cmake.1.html >> >> Petr >> >> On 10 July 2017 at 22:06, A.M. Sabuncu wrote: >> >>> I am completely new to CMake, and am using to build MySQL 5.7.18 on >>> Windows 10 x64, using the following command: >>> >>> cmake .. -DDOWNLOAD_BOOST=1 -DWITH_BOOST="C:\Boost" -DENABLE_DOWNLOADS=1 >>> >>> I have VS 2017 installed, and I am on 64 bit machine, but for some >>> reason, the above command produces the following output: >>> >>> The CXX compiler identification is MSVC 19.10.25019.0 >>> -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual >>> Studio/2017/Professional/VC/Tools/MSVC/14.10.25017/bin/HostX >>> 86/x86/cl.exe >>> -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual >>> Studio/2017/Professional/VC/Tools/MSVC/14.10.25017/bin/HostX86/x86/cl.exe >>> -- works >>> >>> The correct compiler is in the HostX64/x64 folder. >>> >>> Thinking that CMake might be looking it up from there, I checked the >>> processor architecture environment variable from the same cmd.exe that I >>> launched the CMake command from, and here's the result: >>> >>> PROCESSOR_ARCHITECTURE=AMD64 >>> >>> When I follow the above CMake command with the following: >>> >>> devenv MySQL.sln /build RelWithDebInfo >>> >>> I get 32-bit results generated, which is not what I want. >>> >>> How can I get CMake to generate a 64-bit build? >>> >>> Thanks so much. >>> >>> >>> -- >>> >>> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From amsabuncu at gmail.com Tue Jul 11 06:58:41 2017 From: amsabuncu at gmail.com (A.M. Sabuncu) Date: Tue, 11 Jul 2017 13:58:41 +0300 Subject: [CMake] Cannot get a 64-bit build of MySQL on a 64-bit Windows machine In-Reply-To: References: Message-ID: J Decker, thank you. I honestly didn't even know of its existence. I ran it as you suggested, and it's great to be able to see all the flags. Thanks so much again. [image: Inline image 1] On Tue, Jul 11, 2017 at 1:50 PM, J Decker wrote: > Alternatively you could use cmake-gui and on first generation in an empty > directoy, a popup window appears allowing you to select the generator. > > mkdir build2 > cd build2 > cmake-gui .. > > then set the various flags in the gui. > > > On Tue, Jul 11, 2017 at 3:13 AM, A.M. Sabuncu wrote: > >> Petr, >> >> Thank you so much. The following command you suggested fixed the >> problem, and I was able to run a successful build: >> >> cmake .. -G "Visual Studio 15 2017 Win64" >> >> I am grateful for your help. This may have been a minor item for you, >> but for me, it was a real stumbling block. >> >> By the way, the other alternative you suggested did not work: >> >> cmake .. -A Win64 (or "Win64") >> >> The result was: >> >> -- Building for: Visual Studio 15 2017 >> -- Running cmake version 3.8.2 >> -- Found Git: C:/Program Files/Git/cmd/git.exe (found version >> "2.10.2.windows.1") >> -- Configuring with MAX_INDEXES = 64U >> -- The C compiler identification is unknown >> -- The CXX compiler identification is unknown >> CMake Error at CMakeLists.txt:126 (PROJECT): >> No CMAKE_C_COMPILER could be found. >> >> The funny thing is that the use of the -G flag does not issue a "Building >> for..." message, but correctly locates the necessary compiler, whereas the >> -A flag seems to know what target it is building for, but cannot find the >> compiler! >> >> Thank you again, >> >> A. M. Sabuncu >> >> On Tue, Jul 11, 2017 at 10:12 AM, Petr Kmoch >> wrote: >> >>> Hi, >>> >>> when generating a Visual Studio buildsystem with CMake, you can specify >>> the target architecture. If you don't, the default is 32-bit. >>> >>> To specify the architecture, either put it into the generator name: >>> >>> cmake .. -G "Visual Studio 15 2017 Win64" .... >>> >>> or specify just the architecture using -A: >>> >>> cmake .. -A Win64 .... >>> >>> See description of -G and -A in CMake docs: >>> https://cmake.org/cmake/help/latest/manual/cmake.1.html >>> >>> Petr >>> >>> On 10 July 2017 at 22:06, A.M. Sabuncu wrote: >>> >>>> I am completely new to CMake, and am using to build MySQL 5.7.18 on >>>> Windows 10 x64, using the following command: >>>> >>>> cmake .. -DDOWNLOAD_BOOST=1 -DWITH_BOOST="C:\Boost" -DENABLE_DOWNLOADS=1 >>>> >>>> I have VS 2017 installed, and I am on 64 bit machine, but for some >>>> reason, the above command produces the following output: >>>> >>>> The CXX compiler identification is MSVC 19.10.25019.0 >>>> -- Check for working C compiler: C:/Program Files (x86)/Microsoft >>>> Visual Studio/2017/Professional/VC/Tools/MSVC/14.10.25017/bin/HostX >>>> 86/x86/cl.exe >>>> -- Check for working C compiler: C:/Program Files (x86)/Microsoft >>>> Visual Studio/2017/Professional/VC/Tools/MSVC/14.10.25017/bin/HostX86/x86/cl.exe >>>> -- works >>>> >>>> The correct compiler is in the HostX64/x64 folder. >>>> >>>> Thinking that CMake might be looking it up from there, I checked the >>>> processor architecture environment variable from the same cmd.exe that I >>>> launched the CMake command from, and here's the result: >>>> >>>> PROCESSOR_ARCHITECTURE=AMD64 >>>> >>>> When I follow the above CMake command with the following: >>>> >>>> devenv MySQL.sln /build RelWithDebInfo >>>> >>>> I get 32-bit results generated, which is not what I want. >>>> >>>> How can I get CMake to generate a 64-bit build? >>>> >>>> Thanks so much. >>>> >>>> >>>> -- >>>> >>>> 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 >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 2017-07-11 13_58_01-CMake 3.8.2 - C__mysql-server-5.7_bld6.png Type: image/png Size: 36500 bytes Desc: not available URL: From seanwayland at gmail.com Tue Jul 11 08:43:40 2017 From: seanwayland at gmail.com (Sean Wayland) Date: Tue, 11 Jul 2017 08:43:40 -0400 Subject: [CMake] cmake create executable Undefined symbols for architecture x86_64: In-Reply-To: <54f08895-d081-420f-bb36-b370483a12db@gmail.com> References: <14d703d8-bfa9-2bbc-4ca5-e251ece61b92@gmail.com> <466bb2e6-1603-c860-e99b-4642b847f425@gmail.com> <54f08895-d081-420f-bb36-b370483a12db@gmail.com> Message-ID: Thanks Micha, The head developer managed to get it to compile under clion on the weekend, I suspect he may have cleaned up his source code a little bit. I also suspect listing the source code and targeted libraries in the correct order may have helped. Thanks for all your help! Best Sean On Mon, Jul 10, 2017 at 3:22 PM, Micha Hergarden wrote: > On 07-07-17 05:14, Sean Wayland wrote: >> Hi Micha, >> Thanks very much for the email. That seemed to make a small >> difference! With both those lines commented out these errors are >> generated ( below my email ) . >> I still have included >> project(CATSMAT) >> at the top line of the cmake file in the catsmat directory >> >> I tried commenting out each of those language type definitions >> separately but it didn't seem to help. >> The code compiles under xcode. Those language types ( C++14) are >> specified in Xcode so I was trying to find a way to copy what is in >> xcode. >> >> Is there a maximum number of "errors" before the clion compiler will >> spit the dummy ? >> >> Another executable will compile with lots and lots of warnings but no "errors" >> >> I don't know much about C++ unfortunately. These errors look like >> simple errors which I could see might be generated if the syntax of >> the language had changed slightly from one version to the next .. >> >> Thanks for you help! >> >> Sean >> >> >> /Users/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat/cmake/../../libIMUSANT/DomainObjects/inc/IMUSANT_interval.h:78:14: >> error: ISO C++ forbids forward references to 'enum' types >> >> enum direction : int { descending=-1, repeat=0, ascending = 1, >> vertical_bottomtotop }; >> >> >> /Users/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat/cmake/../../libIMUSANT/DomainObjects/inc/IMUSANT_interval.h:78:30: >> error: expected '(' for function-style cast or type construction >> >> enum direction : int { descending=-1, repeat=0, ascending = 1, >> vertical_bottomtotop }; >> >> ~~~ ^ >> >> /Users/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat/cmake/../../libIMUSANT/DomainObjects/inc/IMUSANT_interval.h:78:24: >> error: field has incomplete type 'enum direction' >> >> enum direction : int { descending=-1, repeat=0, ascending = 1, >> vertical_bottomtotop }; >> >> >> /Users/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat/cmake/../../libIMUSANT/DomainObjects/inc/IMUSANT_interval.h:78:14: >> error: ISO C++ forbids forward references to 'enum' types >> >> enum direction : int { descending=-1, repeat=0, ascending = 1, >> vertical_bottomtotop }; >> >> ^ >> >> /Users/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat/cmake/../../libIMUSANT/DomainObjects/inc/IMUSANT_interval.h:78:30: >> error: expected '(' for function-style cast or type construction >> >> enum direction : int { descending=-1, repeat=0, ascending = 1, >> vertical_bottomtotop }; >> >> ~~~ ^ >> >> /Users/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat/cmake/../../libIMUSANT/DomainObjects/inc/IMUSANT_interval.h:78:24: >> error: field has incomplete type 'enum direction' >> >> enum direction : int { descending=-1, repeat=0, ascending = 1, >> vertical_bottomtotop }; >> >> ^ >> >> /Users/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat/cmake/../../libIMUSANT/DomainObjects/inc/IMUSANT_interval.h:78:14: >> note: forward declaration of 'IMUSANT::direction' >> >> enum direction : int { descending=-1, repeat=0, ascending = 1, >> vertical_bottomtotop }; >> >> ^ >> >> /Users/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat/cmake/../../libIMUSANT/DomainObjects/inc/IMUSANT_interval.h:80:14: >> error: ISO C++ forbids forward references to 'enum' types >> >> enum basic : int { unison = 0, second=1, third, fourth, fifth, >> sixth, seventh }; >> >> ^ >> >> /Users/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat/cmake/../../libIMUSANT/DomainObjects/inc/IMUSANT_interval.h:80:26: >> error: expected '(' for function-style cast or type construction >> >> enum basic : int { unison = 0, second=1, third, fourth, fifth, >> sixth, seventh }; >> >> ~~~ ^ >> >> /Users/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat/cmake/../../libIMUSANT/DomainObjects/inc/IMUSANT_interval.h:80:20: >> error: field has incomplete type 'enum basic' >> >> enum basic : int { unison = 0, second=1, third, fourth, fifth, >> sixth, seventh }; >> >> >> sers/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat/cmake/../../libIMUSANT/DomainObjects/inc/IMUSANT_interval.h:80:14: >> error: ISO C++ forbids forward references to 'enum' types >> >> enum basic : int { unison = 0, second=1, third, fourth, fifth, >> sixth, seventh }; >> >> ^ >> >> /Users/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat/cmake/../../libIMUSANT/DomainObjects/inc/IMUSANT_interval.h:80:26: >> error: expected '(' for function-style cast or type construction >> >> enum basic : int { unison = 0, second=1, third, fourth, fifth, >> sixth, seventh }; >> >> ~~~ ^ >> >> /Users/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat/cmake/../../libIMUSANT/DomainObjects/inc/IMUSANT_interval.h:80:20: >> error: field has incomplete type 'enum basic' >> >> enum basic : int { unison = 0, second=1, third, fourth, fifth, >> sixth, seventh }; >> >> >> >> >> /Users/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat/cmake/../../libIMUSANT/FileProcessing/inc/IMUSANT_processing.h:61:35: >> error: expected ';' at end of declaration list >> >> const char * what () const noexcept >> >> ^ >> >> ^ >> >> >> >> 22 warnings and 12 errors generated. >> >> make[3]: *** [catsmat/catsmat/cmake/CMakeFiles/catsmat.dir/__/Application/CATSMAT_main.cpp.o] >> Error 1 >> >> make[2]: *** [catsmat/catsmat/cmake/CMakeFiles/catsmat.dir/all] Error 2 >> >> make[1]: *** [catsmat/catsmat/cmake/CMakeFiles/catsmat.dir/rule] Error 2 >> >> On Thu, Jul 6, 2017 at 3:12 PM, Micha Hergarden >> wrote: >>> On 06-07-17 15:59, Sean Wayland wrote: >>>> Hi Micha, >>>> Thanks very much I tried that .. I added it to the application >>>> directory cmakelists.txt file . Same issue .. It's already in the top >>>> level cmake file which looks like this .. >>>> >>>> project(CATSMAT) >>>> cmake_minimum_required(VERSION 3.6.3) >>>> >>>> >>>> if (APPLE) >>>> >>>> set(CMAKE_C++_FLAGS -mmacosx-version-min=10.4) >>>> endif (APPLE) >>>> >>>> >>>> include_directories("catsmat/libIMUSANT") >>>> >>>> add_subdirectory (catsmat/googletest-master/googletest) >>>> add_subdirectory (catsmat/libMusicXMLv3/libmusicxml-3.00-src/cmake) >>>> add_subdirectory (catsmat/libIMUSANT/cmake) >>>> add_subdirectory (catsmat/libIMUSANT_Tests/cmake) >>>> add_subdirectory (catsmat/catsmat/cmake) >>>> >>>> set(CMAKE_CXX_STANDARD 14) >>>> >>>> On Thu, Jul 6, 2017 at 2:48 AM, Micha Hergarden >>>> wrote: >>>>> On 05-07-17 22:50, Sean Wayland wrote: >>>>>> I am attempting to write a cmakelists.txt file for an application. >>>>>> The application has a couple of dependencies. >>>>>> I have been able to build targets for the dependencies but when I try >>>>>> and add an executable for the main application I encounter this error. >>>>>> >>>>>> Undefined symbols for architecture x86_64: >>>>>> >>>>>> "_main", referenced from: >>>>>> >>>>>> implicit entry/start for main executable >>>>>> >>>>>> ld: symbol(s) not found for architecture x86_64 >>>>>> >>>>>> clang: error: linker command failed with exit code 1 (use -v to see invocation) >>>>>> >>>>>> >>>>>> Googling the error and looking on stack exchange suggests that I don't >>>>>> have a main function in the implicit entry/start . >>>>>> >>>>>> Where does it look for this function ? >>>>>> Does that file need to be first in the list of sources ? >>>>>> >>>>>> >>>>>> >>>>>> This function is included here : >>>>>> ${CATSMAT_DIR}/Application/CATSMAT_main.cpp >>>>>> >>>>>> My cmake file is below. >>>>>> >>>>>> Any advice would be appreciated I have been stuck here for a while! >>>>>> >>>>>> Best Sean >>>>>> >>>>>> >>>>>> ####################################### >>>>>> # CMAKE CATSTMAT >>>>>> ####################################### >>>>>> cmake_minimum_required(VERSION 3.6.3) >>>>>> set(CMAKE_CXX_STANDARD 14) >>>>>> if(CMAKE_CONFIGURATION_TYPES) >>>>>> set(CMAKE_CONFIGURATION_TYPES Debug Release) >>>>>> endif() >>>>>> >>>>>> if(UNIX) >>>>>> add_definitions(-Wall -DGCC) >>>>>> endif(UNIX) >>>>>> >>>>>> ##### RPATH SETTING ##### >>>>>> set(CMAKE_MACOSX_RPATH 1) >>>>>> >>>>>> #if(APPLE) >>>>>> # set (CMAKE_OSX_ARCHITECTURES "x86_64 i386") >>>>>> # if (${CMAKE_SYSTEM_VERSION} VERSION_LESS 9.0.0) >>>>>> # set (CMAKE_OSX_SYSROOT /Developer/SDKs/MacOSX10.4u.sdk) >>>>>> # elseif (${CMAKE_SYSTEM_VERSION} VERSION_LESS 10.8.0) >>>>>> # set (CMAKE_OSX_SYSROOT /Developer/SDKs/MacOSX10.5.sdk) >>>>>> # elseif (${XCODE_VERSION} VERSION_LESS 4.0.0) >>>>>> # set (CMAKE_OSX_SYSROOT /Developer/SDKs/MacOSX10.6.sdk) >>>>>> # else () >>>>>> # set (CMAKE_OSX_SYSROOT "macosx10.7") >>>>>> # endif () >>>>>> # set (CMAKE_C++_FLAGS -mmacosx-version-min=10.4) >>>>>> #endif(APPLE) >>>>>> # >>>>>> #if(WIN32) >>>>>> # add_definitions(-DWINVER=0x0400 -DWIN32) >>>>>> # if(${CMAKE_GENERATOR} STREQUAL "Visual Studio 6") >>>>>> # add_definitions(-DVC6) >>>>>> # elseif(${CMAKE_GENERATOR} STREQUAL "Visual Studio 8 2005") >>>>>> # add_definitions(-DVC2005) >>>>>> # endif(${CMAKE_GENERATOR} STREQUAL "Visual Studio 6") >>>>>> #endif(WIN32) >>>>>> >>>>>> ############### BOOST LIBRARIES ########### >>>>>> if (APPLE) >>>>>> set(BOOST_ROOT "/usr/local/boost") >>>>>> set(BOOST_FILESYSTEM_LIB /usr/local/boost/lib/libboost_filesystem.dylib) >>>>>> set(BOOST_SYSTEM_LIB /usr/local/boost/lib/libboost_system.dylib) >>>>>> >>>>>> else (NOT APPLE) >>>>>> set(BOOST_ROOT "C:/local/boost_1_58_0") >>>>>> set(BOOST_FILESYSTEM_LIB C:/local/boost_1_58_0/lib64-msvc-12.0) >>>>>> set(BOOST_SYSTEM_LIB C:/local/boost_1_58_0/lib64-msvc-12.0) >>>>>> endif (APPLE) >>>>>> >>>>>> FIND_PACKAGE( Boost 1.58.0 REQUIRED ) >>>>>> INCLUDE_DIRECTORIES( ${Boost_INCLUDE_DIR} ) >>>>>> >>>>>> >>>>>> ####################################### >>>>>> # set directories, src and headers. >>>>>> >>>>>> set (CATSMAT_DIR /Users/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat ) >>>>>> set (libIMUSANT_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../../libIMUSANT) >>>>>> set (LOKI_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../../Loki) >>>>>> set (SUFFIX_TREE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../../SuffixTree) >>>>>> set (GOOGLE_TEST_INC_DIR >>>>>> ${CMAKE_CURRENT_SOURCE_DIR}/../../googletest-master/googletest/include) >>>>>> set (IMUSANT_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../../libIMUSANT) >>>>>> >>>>>> >>>>>> set (LIBMUSICXML_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../../libMusicXMLv3) >>>>>> >>>>>> >>>>>> #### SET SOURCES EXPLICITLY ##### >>>>>> >>>>>> set(SRC >>>>>> >>>>>> ${CATSMAT_DIR}/Analysis/src/IMUSANT_contour_suffixtree_builder.cpp >>>>>> ${CATSMAT_DIR}/Analysis/src/IMUSANT_generalised_interval_suffixtree_builder.cpp >>>>>> ${CATSMAT_DIR}/Analysis/src/IMUSANT_interval_suffixtree_builder.cpp >>>>>> ${CATSMAT_DIR}/Analysis/src/IMUSANT_pitch_suffixtree_builder.cpp >>>>>> ${CATSMAT_DIR}/Analysis/src/IMUSANT_repeated_interval_substring.cpp >>>>>> ${CATSMAT_DIR}/Analysis/src/IMUSANT_t_repeated_substring.cpp >>>>>> ${CATSMAT_DIR}/Analysis/src/IMUSANT_VectorMapAnalysisTypes.cpp >>>>>> >>>>>> ${CATSMAT_DIR}/Application/CATSMAT_main.cpp >>>>>> ${CATSMAT_DIR}/Application/CATSMAT_menu.cpp >>>>>> >>>>>> ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_chord.cpp >>>>>> ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_collectionvisitor.cpp >>>>>> ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_cp_matrix.cpp >>>>>> ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_dyad_sequences.cpp >>>>>> ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_dyadtuple_sequences.cpp >>>>>> ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_sonority_sequences.cpp >>>>>> ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_TrigramSequences.cpp >>>>>> ${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_TrigramSuffixTreeBuilder.cpp >>>>>> >>>>>> ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_canonic_techniques_tools.cpp >>>>>> ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_partdata.cpp >>>>>> ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_processing.cpp >>>>>> ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_score_profile.tpp >>>>>> ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_score_splitter.cpp >>>>>> ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_score_profile_special.cpp >>>>>> ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_scoredata.cpp >>>>>> ${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_scoredatacollector.cpp >>>>>> >>>>>> ${CATSMAT_DIR}/Segmentation/IMUSANT_segment.cpp >>>>>> ${CATSMAT_DIR}/Segmentation/IMUSANT_set_of_segment.cpp >>>>>> >>>>>> ${CATSMAT_DIR}/Segmentation/FixedPeriodDetection/src/IMUSANT_fixed_period_segmenter.cpp >>>>>> ${CATSMAT_DIR}/Segmentation/FixedPeriodDetection/src/IMUSANT_partlist_ordered_by_part_entry.cpp >>>>>> ${CATSMAT_DIR}/Segmentation/FixedPeriodDetection/src/IMUSANT_segmented_part_fixed_period.cpp >>>>>> ${CATSMAT_DIR}/Segmentation/FixedPeriodDetection/src/SegmentedScoreFixedPeriod.cpp >>>>>> >>>>>> ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src/IMUSANT_interval_profile_LBDM.cpp >>>>>> ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src/IMUSANT_LBDM_segmenter.cpp >>>>>> ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src/IMUSANT_segmented_note_vectors.cpp >>>>>> ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src/IMUSANT_segmented_part_LBDM.cpp >>>>>> ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src/IMUSANT_segmented_profile_vectors.cpp >>>>>> ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src/IMUSANT_weighted_strength_vectors.cpp >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> # old version of adding source code >>>>>> >>>>>> #set (SRCFOLDERS >>>>>> >>>>>> >>>>>> # ${CATSMAT_DIR}/Analysis/src >>>>>> # ${CATSMAT_DIR}/CounterpointAnalysis/src >>>>>> # ${CATSMAT_DIR}/GeneralAnalysis/src >>>>>> # ${CATSMAT_DIR}/Segmentation/FixedPeriodDetection/src >>>>>> # ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src >>>>>> # ${CATSMAT_DIR}/Application >>>>>> # ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/src >>>>>> # ${CATSMAT_DIR}/Segmentation >>>>>> # ${CATSMAT_DIR}/Utilities >>>>>> #) >>>>>> >>>>>> >>>>>> set (INCFOLDERS >>>>>> ${libIMUSANT_DIR} >>>>>> ${CATSMAT_DIR}/Analysis/inc >>>>>> ${CATSMAT_DIR}/Application >>>>>> ${CATSMAT_DIR}/CounterpointAnalysis/inc >>>>>> ${CATSMAT_DIR}/GeneralAnalysis/inc >>>>>> ${CATSMAT_DIR}/Segmentation >>>>>> ${CATSMAT_DIR}/Segmentation/FixedPeriodDetection/inc >>>>>> ${CATSMAT_DIR}/Segmentation/LocalBoundaryDetectionModel/inc >>>>>> ${CATSMAT_DIR}/Utilities >>>>>> ${libIMUSANT_DIR}/DomainObjects/inc >>>>>> ${libIMUSANT_DIR}/Utilities/inc >>>>>> ${libIMUSANT_DIR}/FileProcessing/inc >>>>>> ${libIMUSANT_DIR}/Converters/MusicXML_v3 >>>>>> ${libIMUSANT_DIR}/Converters/MusicXML_v3/inc >>>>>> ${libIMUSANT_DIR}/Converters/MusicXML_v3/shared/inc >>>>>> ${IMUSANT_DIR}/DomainObjects/inc >>>>>> ${IMUSANT_DIR}/Converters/MusicXML_v3 >>>>>> ${IMUSANT_DIR}/Converters/MusicXML_v3/inc >>>>>> ${IMUSANT_DIR}/Converters/Shared/inc >>>>>> ${IMUSANT_DIR}/FileProcessing/inc >>>>>> ${IMUSANT_DIR}/FileProcessing/Analysis/Segmentation/FixedPeriodDetection/ >>>>>> ${IMUSANT_DIR}/Utilities/inc >>>>>> ${SUFFIXTREE_DIR} >>>>>> ${LIBMUSICXML_DIR}/libmusicxml-3.00-src/src >>>>>> ${LIBMUSICXML_DIR}/libmusicxml-3.00-src/src/lib >>>>>> ${LIBMUSICXML_DIR}/libmusicxml-3.00-src/src/visitors >>>>>> ${LIBMUSICXML_DIR}/libmusicxml-3.00-src/src/parser >>>>>> ${LOKI_DIR} >>>>>> ${SUFFIX_TREE_DIR} >>>>>> ${GOOGLE_TEST_INC_DIR} >>>>>> ) >>>>>> >>>>>> >>>>>> #foreach(folder ${SRCFOLDERS}) >>>>>> # set(SRC ${SRC} "${folder}/*.cpp") # add source files >>>>>> #endforeach(folder) >>>>>> #file (GLOB CORESRC RELATIVE ${CMAKE_CURRENT_SOURCE_DIR} ${SRC}) >>>>>> >>>>>> >>>>>> >>>>>> ## is this necessary I think target link directories might do the job ? >>>>>> >>>>>> foreach(folder ${INCFOLDERS}) >>>>>> set(HEADERS ${HEADERS} "${folder}/*.h") # add header files >>>>>> set(INCL ${INCL} "${folder}") # add include folders >>>>>> endforeach(folder) >>>>>> file (GLOB COREH RELATIVE ${CMAKE_CURRENT_SOURCE_DIR} ${HEADERS}) >>>>>> >>>>>> >>>>>> ####################################### >>>>>> # set includes ( is this needed ? ) >>>>>> include_directories( ${INCFOLDERS}) >>>>>> set_source_files_properties (${COREH} PROPERTIES HEADER_FILE_ONLY TRUE) >>>>>> >>>>>> >>>>>> ####################################### >>>>>> # set library target >>>>>> >>>>>> #if(APPLE OR MSVC) >>>>>> >>>>>> set(target catsmat) >>>>>> >>>>>> # I don't know why these if statements are included they seem to do nothing ' >>>>>> #else(APPLE OR MSVC) >>>>>> # set(target catsmat) >>>>>> #endif(APPLE OR MSVC) >>>>>> >>>>>> ##if(MSVC) >>>>>> ## enable_language(RC) >>>>>> ## set(LIBCONTENT ${CORESRC} ${COREH} >>>>>> ${CATSMAT_DIR}/win32/libIMUSANT/libIMUSANT.rc) >>>>>> ##else(MSVC) >>>>>> ## set(LIBCONTENT ${CORESRC} ${COREH}) >>>>>> ##endif(MSVC) >>>>>> >>>>>> add_executable(${target} ${SRC} ) >>>>>> >>>>>> #### add include directories >>>>>> include_directories ( ${INCFOLDERS} ) >>>>>> >>>>>> ############### Targeted Libraries ########### >>>>>> >>>>>> TARGET_LINK_LIBRARIES(${target} gtest) >>>>>> TARGET_LINK_LIBRARIES(${target} ${BOOST_FILESYSTEM_LIB}) >>>>>> TARGET_LINK_LIBRARIES(${target} ${BOOST_SYSTEM_LIB}) >>>>>> TARGET_LINK_LIBRARIES(${target} libmusicxml2) >>>>>> TARGET_LINK_LIBRARIES(${target} libIMUSANT) >>>>>> >>>>>> >>>>>> set_target_properties (${target} PROPERTIES >>>>>> FRAMEWORK TRUE >>>>>> VERSION ${VERSION} >>>>>> C_STANDARD 99 >>>>>> FRAMEWORK_VERSION ${VERSION} >>>>>> PUBLIC_HEADER "${COREH}" >>>>>> DEFINE_SYMBOL LIBMUSICXML_EXPORTS >>>>>> MACOSX_FRAMEWORK_SHORT_VERSION_STRING ${STRVERS} >>>>>> MACOSX_FRAMEWORK_BUNDLE_VERSION ${SSTRVERS} >>>>>> ) >>>>>> >>>>>> >>>>>> >>>>>> ####################################### >>>>>> # install setup >>>>>> if(NOT APPLE) >>>>>> install ( TARGETS ${target} ${TOOLS} >>>>>> RUNTIME DESTINATION bin >>>>>> LIBRARY DESTINATION lib >>>>>> ARCHIVE DESTINATION lib >>>>>> FRAMEWORK DESTINATION "/Library/Frameworks" CONFIGURATIONS Release >>>>>> PUBLIC_HEADER DESTINATION include/libmusicxml >>>>>> ) >>>>>> endif(NOT APPLE) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> Hello Sean, >>>>> >>>>> Could you try adding a 'project(CATSTMAT)' call right at the top of your >>>>> CMakeLists.txt? As well as setting a name for the project, this call >>>>> also enables languages by default. >>>>> >>>>> HTH, >>>>> Micha >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> 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 >>>> >>> Hi Sean, >>> >>> I'm also a bit confused as you seem to set 'C_STANDARD 99' as a property >>> for the target, as well as 'set(CMAKE_CXX_STANDARD 14)'. I don't know if >>> these two settings interfere with each other. Could you remove one of >>> the two as an experiment? >>> >>> Regards, >>> Micha >>> >> >> > Hello Sean, > > Unfortunately I don't have experience with the clion compiler, so I > can't help you with that. Is there any way I could access this project > to see if I can compile it? Does a simple 'hello world' project compile > at all? > > Regards, > Micha > -- www.seanwayland.com Sean Wayland licensed real estate salesperson phone: 3475231455 From victor.lamoine at institutmaupertuis.fr Tue Jul 11 09:18:11 2017 From: victor.lamoine at institutmaupertuis.fr (Victor Lamoine) Date: Tue, 11 Jul 2017 15:18:11 +0200 Subject: [CMake] How do I specify VTK minimum version? Message-ID: <2517bc18-50d1-cfca-59c5-1ee0805c3fa8@institutmaupertuis.fr> Hi, I am using CMake to set up a VTK project. Our project requires VTK to be version 7.1 or newer. I'm using Ubuntu 16.04 with CMake 3.5.1. My CMakeLists.txt looks like this: cmake_minimum_required(VERSION 2.8) project(test_vtk_versions) find_package(VTK 7.1 REQUIRED) include(${VTK_USE_FILE}) add_executable(test_vtk_1 test_vtk_1) target_link_libraries(test_vtk_1 ${VTK_LIBRARIES}) I have several versions of VTK installed on my machine: * VTK 6.2 from the Ubuntu repositories * VTK 7.1 compiled/installed from sources * VTK 8.0 compiled/installed from sources $ ls /usr/local/lib/cmake/vtk* /usr/lib/cmake/vtk* /usr/lib/cmake/vtk-6.2: exportheader.cmake.in UseVTK.cmake vtkJavaWrapping.cmake vtkModuleMacros.cmake VTKTargets.cmake vtkThirdParty.cmake vtkWrapPython.sip.in (... list was manually shortened ...) /usr/local/lib/cmake/vtk-7.1: FindTCL.cmake VTKConfigVersion.cmake vtkGroups.cmake vtkModuleHeaders.cmake.in vtkObjectFactory.h.in vtkTclWrapping.cmake vtkWrapPython.cmake (... list was manually shortened ...) /usr/local/lib/cmake/vtk-8.0: FindTCL.cmake VTKConfigVersion.cmake vtkGroups.cmake vtkModuleHeaders.cmake.in vtkObjectFactory.h.in vtkTclTkMacros.cmake vtkWrapping.cmake (... list was manually shortened ...) The project can be configured (Unix Makefile) and compiled, it is compiled against VTK 7.1 in this configuration. However if I remove VTK 7.1 from the system (using sudo xargs rm < "install_manifest.txt") then I end with this this error: CMake Error at CMakeLists.txt:4 (find_package): Could not find a configuration file for package "VTK" that is compatible with requested version "7.1". The following configuration files were considered but not accepted: /usr/local/lib/cmake/vtk-8.0/VTKConfig.cmake, version: 8.0.0 /usr/lib/cmake/vtk-6.2/VTKConfig.cmake, version: 6.2.0 I have also tried find_package(VTK 7.1*.0* REQUIRED), without success. Why isn't VTK 8.0.0 accepted? It is a greater version number so I expected it to be ok. How do I specify that I want VTK 7.1 OR newer? Thank you for your time Bye -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidhunter22 at gmail.com Tue Jul 11 13:35:07 2017 From: davidhunter22 at gmail.com (David Hunter) Date: Tue, 11 Jul 2017 11:35:07 -0600 Subject: [CMake] OBJECT libraries and working around lake of target_link_libraries Message-ID: We recently converted some software, comprising about 300 projects, to use OBJECT libraries from SHARED libraries so we could create "conveneince" libraries that were cominations of some of the 300 projects. Not being able to use target_link_libraries with thier transitive nature made this very painful, many days of work. Supporting OBJECT libraries in target_link_libraries calls was mentioned mentioned right back here https://cmake.org/pipermail/cmake-developers/2012-March/015422.html but sadly seems still to be on the back burner. We are faced with a project hierarchy re-org and wanted to try to automate generation of the dependencies. So we are thinking of doing the following. 1) Remove all the target_sources stuff from all CMakeLists.txt 2) Add add_dependencies calls to specify the project dependencies 3) run cmake with the --graphviz=graphviz.dot 4) Write a program that reads the resultant graphviz.dot and generate a file for each project that contain a target_sources call specifying all the dependencies for that project 5) In the CMakeLists.txt for each project include the relevant generated target_sources file 6) Rerun cmake Note the first time cmake gets run all the generated dependency files are empty so the only dependencies are those specified by add_dependencies calls. Obviously the above is a bit convoluted, although we already have a program to read and use the data in graphviz.dot file for other reason. So my question is will the above approach work and is there a better one? From jmajors at google.com Tue Jul 11 16:37:15 2017 From: jmajors at google.com (Jason Majors) Date: Tue, 11 Jul 2017 13:37:15 -0700 Subject: [CMake] Prevent linebreaks in cmake output Message-ID: Is there a way to have each message from cmake appear on a single line? Currently my output seems to break like this: CMake Error: Error in cmake code at /path/to/CMakeLists.txt:48: Parse error. Function missing ending ")". End of file reached. I'm trying to parse the error messages in a program that reads cmake's stderr and stdout. Rather than trying to decide which lines should go together, and building all the scanning that would be required for that, I was hoping there might just be a flag I could set to do the work for me. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjvbertin at gmail.com Wed Jul 12 07:38:25 2017 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Wed, 12 Jul 2017 13:38:25 +0200 Subject: [CMake] /path/to/libpng.so automatic conversion to -lpng ? Message-ID: <5397309.4dvKn07gbZ@bola> Hi, I have a target_link_libraries command that uses ${PNG_LIBRARIES} and thus *should* add something like `/path/to/libpng.so /path/to/libz.so` to the linker command. Instead, I am getting a linker command line that has `-lpng -lz`, which fails for me because the `/path/to` in question isn't on the standard library search path. Is there a cmake feature that does this automatic conversion, and if so how can I turn it off? Thanks, Ren? From Andreas-Naumann at gmx.net Wed Jul 12 09:31:21 2017 From: Andreas-Naumann at gmx.net (Andreas Naumann) Date: Wed, 12 Jul 2017 15:31:21 +0200 Subject: [CMake] /path/to/libpng.so automatic conversion to -lpng ? In-Reply-To: <5397309.4dvKn07gbZ@bola> References: <5397309.4dvKn07gbZ@bola> Message-ID: Dear Rene, cmake instrospects your compiler and asks for system directories. Only these system directories will be removed and the corresponding libraries will be linked by -l<...>. So, you should check your compiler and the environment. I had several problems years ago with the environment variable LIBRARY_PATH, which leads to such a behavior. Regards, Andreas Am 12.07.2017 um 13:38 schrieb Ren? J.V. Bertin: > Hi, > > I have a target_link_libraries command that uses ${PNG_LIBRARIES} and thus *should* add something like `/path/to/libpng.so /path/to/libz.so` to the linker command. Instead, I am getting a linker command line that has `-lpng -lz`, which fails for me because the `/path/to` in question isn't on the standard library search path. > > Is there a cmake feature that does this automatic conversion, and if so how can I turn it off? > > Thanks, > Ren? From rjvbertin at gmail.com Wed Jul 12 12:31:56 2017 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Wed, 12 Jul 2017 18:31:56 +0200 Subject: [CMake] /path/to/libpng.so automatic conversion to -lpng ? References: <5397309.4dvKn07gbZ@bola> Message-ID: <2778594.yIuJqfDBxI@patux.local> Andreas Naumann wrote: > cmake instrospects your compiler and asks for system directories. Only > these system directories will be removed and the corresponding libraries > will be linked by -l<...>. So, you should check your compiler and the > environment. I had several problems years ago with the environment > variable LIBRARY_PATH, which leads to such a behavior. Hello Andreas, Aha, I indeed have LIBRARY_PATH=/opt/local/lib set (by the build scripts I use). >From what I understand, that variable allows you to specify a set of -L directories via an env. variable (other than LDFLAGS). It seems that clang handles that variable in a somewhat different manner than GCC does. Even in a very simple call on the commandline (including the -v option) I see it adds -L/opt/local/lib AFTER the user-supplied libraries, where GCC puts it before the 1st -l option. R. From rjvbertin at gmail.com Wed Jul 12 12:40:08 2017 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Wed, 12 Jul 2017 18:40:08 +0200 Subject: [CMake] /path/to/libpng.so automatic conversion to -lpng ? References: <5397309.4dvKn07gbZ@bola> Message-ID: <3303475.IsOCqSlrph@patux.local> FWIW, I do question this rewriting feature, because it clearly can go wrong. I'd argue that programmers (or build script/cmake modules/...) usually have good reason when they give the absolute path to a library: making darn sure it's indeed that one that gets linked. While I agree that replacing a full path with the -lfoo notation makes the final command shorter and thus more readable it can also introduce subtle bugs. The fact that a library can be found by the linker because it's on the search path doesn't mean that the linker will find the right, intended library. In my case I could get the correct linking by just adding -L/opt/local/lib, but what if for some reason I had wanted to include the system libpng, i.e. if PNG_LIBRARIES had pointed to /usr/lib/libpng.so? I hope this is not such a corner case that Kitware haven't foreseen it and implemented a way to deactivate the rewriting? R. From eike at sf-mail.de Wed Jul 12 13:08:08 2017 From: eike at sf-mail.de (Rolf Eike Beer) Date: Wed, 12 Jul 2017 19:08:08 +0200 Subject: [CMake] /path/to/libpng.so automatic conversion to -lpng ? In-Reply-To: <2778594.yIuJqfDBxI@patux.local> References: <5397309.4dvKn07gbZ@bola> <2778594.yIuJqfDBxI@patux.local> Message-ID: <1623841.1qftnlEELx@daneel.sf-tec.de> Am Mittwoch, 12. Juli 2017, 18:31:56 schrieb Ren? J. V. Bertin: > Andreas Naumann wrote: > > cmake instrospects your compiler and asks for system directories. Only > > these system directories will be removed and the corresponding libraries > > will be linked by -l<...>. So, you should check your compiler and the > > environment. I had several problems years ago with the environment > > variable LIBRARY_PATH, which leads to such a behavior. > > Hello Andreas, > > Aha, I indeed have LIBRARY_PATH=/opt/local/lib set (by the build scripts I > use). From what I understand, that variable allows you to specify a set of > -L directories via an env. variable (other than LDFLAGS). > > It seems that clang handles that variable in a somewhat different manner > than GCC does. Even in a very simple call on the commandline (including the > -v option) I see it adds -L/opt/local/lib AFTER the user-supplied > libraries, where GCC puts it before the 1st -l option. Welcome to the work of link_directories(). This is exactly the reason to avoid it: it always causes trouble. Eike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part. URL: From christian.mazakas at gmail.com Wed Jul 12 13:59:59 2017 From: christian.mazakas at gmail.com (Christian Mazakas) Date: Wed, 12 Jul 2017 10:59:59 -0700 Subject: [CMake] Internal Interface Libraries and Header Dependencies Message-ID: To give a brief overview of what I'm trying to do, right now I'm working on a project with tests. I want to abstract my implementation into a library that I can then link to when building both a testing binary and an application binary. The issue is, my library is currently header-only. So I figured that I would generate an interface library out of this. However, the header dependencies are not being propagated out to the resulting executables. This means that any changes in my header files appear to be ignored and don't cause the dependent source files to be recompiled. The only way I can get proper behavior is to call "target_include_directories" directly on each one of my executables. For reference, I'm using the "Visual Studio 14 2015 Win64" generator on Windows 10, building a CUDA project. Does anyone have any insight on this? I can post my CMakeLists.txt file should need be. - Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Wed Jul 12 14:59:10 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 12 Jul 2017 14:59:10 -0400 Subject: [CMake] [ANNOUNCE] CMake 3.9.0-rc6 is ready for testing Message-ID: I am proud to announce the sixth CMake 3.9 release candidate. https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.9 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.9/release/3.9.html Some of the more significant changes in CMake 3.9 are: * An update to Visual Studio 2015 changed the GenerateDebugInformation linker setting it expects in .vcxproj files. CMake 3.9 has been updated to account for this. * "CUDA" is now supported by the Visual Studio Generators for VS 2010 and above. This complements the existing support by the Makefile Generators and the "Ninja" generator. CUDA 8.0.61 or higher is recommended due to known bugs in the VS integration by earlier versions. * CMake is now aware of the "C++ standards" and "C standards" and their associated meta-features for the following "compiler ids": "Cray", "PGI", and "XL". * The "add_library()" command "IMPORTED" option learned to support Object Libraries. * All "find_" commands now have a "PACKAGE_ROOT" search path group that is first in the search heuristics. If a "find_" command is called from inside a find module, then the CMake variable and environment variable named "_ROOT" are used as prefixes and are the first set of paths to be searched. * The "install(TARGETS)" command learned a new "OBJECTS" option to specify where to install Object Libraries. * The "install(EXPORT)" command learned how to export Object Libraries. * A "BUILD_WITH_INSTALL_NAME_DIR" target property and corresponding "CMAKE_BUILD_WITH_INSTALL_NAME_DIR" variable were added to control whether to use the "INSTALL_NAME_DIR" target property value for binaries in the build tree. This is for macOS "install_name" as "BUILD_WITH_INSTALL_RPATH" is for "RPATH". * A "CUDA_PTX_COMPILATION" target property was added to Object Libraries to support compiling to ".ptx" files instead of host object files. * A new "GoogleTest" module was added to provide the "gtest_add_tests()" function independently of the "FindGTest" module. The function was also updated to support keyword arguments, with functionality expanded to allow a test name prefix and suffix to be specified, the dependency on the source files to be optional and the list of discovered test cases to be returned to the caller. * The "Ninja" generator has loosened the dependencies of object compilation. Object compilation now depends only on custom targets and custom commands associated with libraries on which the object's target depends and no longer depends on the libraries themselves. Source files in dependent targets may now compile without waiting for their targets' dependencies to link. * Interprocedural optimization (IPO) is now supported for GNU and Clang compilers using link time optimization (LTO) flags. See the "INTERPROCEDURAL_OPTIMIZATION" target property and "CheckIPOSupported" module. * The "TARGET_OBJECTS" "generator expression" is now supported by the "add_custom_command()" and "file(GENERATE)" commands. CMake 3.9 Release Notes *********************** Changes made since CMake 3.8 include the following. New Features ============ Languages --------- * "CUDA" is now supported by the Visual Studio Generators for VS 2010 and above. This complements the existing support by the Makefile Generators and the "Ninja" generator. CUDA 8.0.61 or higher is recommended due to known bugs in the VS integration by earlier versions. * CMake is now aware of the "C++ standards" and "C standards" and their associated meta-features for the following "compiler ids": "Cray", "PGI", and "XL". Generators ---------- * Visual Studio Generators for VS 2010 and above learned to support the "ASM_NASM" language when "nasm" is installed. * The "Xcode" generator learned to create Xcode schema files. This is an experimental feature and can be activated by setting the "CMAKE_XCODE_GENERATE_SCHEME" variable to a "TRUE" value. Commands -------- * The "add_library()" command "IMPORTED" option learned to support Object Libraries. * All "find_" commands now have a "PACKAGE_ROOT" search path group that is first in the search heuristics. If a "find_" command is called from inside a find module, then the CMake variable and environment variable named "_ROOT" are used as prefixes and are the first set of paths to be searched. * The "find_library()" command learned to search "libx32" paths when the build targets the "x32" ABI. See the "FIND_LIBRARY_USE_LIBX32_PATHS" global property. * The "include_external_msproject()" command learned to use the "MAP_IMPORTED_CONFIG_" target property to map current configurations to the external configurations. * The "install(TARGETS)" command learned a new "OBJECTS" option to specify where to install Object Libraries. * The "install(EXPORT)" command learned how to export Object Libraries. * The "project()" command learned an optional "DESCRIPTION" parameter to set the "PROJECT_DESCRIPTION" variable. * The "separate_arguments()" command gained a "NATIVE_COMMAND" mode that performs argument separation depending on the host operating system. Variables --------- * A "CMAKE_ANDROID_NDK_DEPRECATED_HEADERS" variable was added for use when Cross Compiling for Android with the NDK to request use of the deprecated headers even when unified headers are available. The default is now to use unified headers if available. * A "CMAKE_AUTOMOC_DEPEND_FILTERS" variable was introduced to allow "CMAKE_AUTOMOC" to extract additional dependency file names for "moc" from the contents of source files. * A "CMAKE_AUTOUIC_SEARCH_PATHS" variable was introduced to allow "CMAKE_AUTOUIC" to search for "foo.ui" in more places than the vicinity of the file including "ui_foo.h". * A "CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX" variable was added to tell the "find_library()" command to search in a "lib" directory before each "lib" directory that would normally be searched. * A "CMAKE_INTERPROCEDURAL_OPTIMIZATION" variable was added to initialize the "INTERPROCEDURAL_OPTIMIZATION" property on all targets. * A "CMAKE__COMPILER_AR" variable was added to hold the path to the GCC/Clang wrapper of "ar". * A "CMAKE__COMPILER_RANLIB" variable was added to hold the path to the GCC/Clang wrapper of "ranlib". * The "CMAKE_SYSROOT_COMPILE" and "CMAKE_SYSROOT_LINK" variables were added to use separate sysroots for compiling and linking. Properties ---------- * A new "AUTOGEN_BUILD_DIR" target property was introduced to set a custom output directory for "AUTOMOC", "AUTOUIC", and "AUTORCC". * A new "AUTOMOC_DEPEND_FILTERS" target property was introduced to allow "AUTOMOC" to extract additional dependency file names for "moc" from the contents of source files. * A new "AUTOUIC_SEARCH_PATHS" target property was introduced to allow "AUTOUIC" to search for "foo.ui" in more places than the vicinity of the file including "ui_foo.h". * Global properties "AUTOGEN_SOURCE_GROUP", "AUTOMOC_SOURCE_GROUP" and "AUTORCC_SOURCE_GROUP" were introduced to allow files generated by "AUTOMOC" or "AUTORCC" to be placed in a "source_group()". * A "BUILD_WITH_INSTALL_NAME_DIR" target property and corresponding "CMAKE_BUILD_WITH_INSTALL_NAME_DIR" variable were added to control whether to use the "INSTALL_NAME_DIR" target property value for binaries in the build tree. This is for macOS "install_name" as "BUILD_WITH_INSTALL_RPATH" is for "RPATH". * A "CUDA_PTX_COMPILATION" target property was added to Object Libraries to support compiling to ".ptx" files instead of host object files. * A "GENERATOR_IS_MULTI_CONFIG" global property was added to determine whether the current generator is a multi-configuration generator (such as Visual Studio Generators or "Xcode"). * The "INTERPROCEDURAL_OPTIMIZATION" target property is now enforced when enabled. CMake will add IPO flags unconditionally or produce an error if it does not know the flags for the current compiler. The project is now responsible to use the "CheckIPOSupported" module to check for IPO support before enabling the target property. See policy "CMP0069". * The "WINDOWS_EXPORT_ALL_SYMBOLS" target property may now be used in combination with explicit ".def" files in order to export all symbols from the object files within a target plus an explicit list of symbols that the linker finds in dependencies (e.g. "msvcrt.lib"). Modules ------- * A "CheckIPOSupported" module was added to help projects check whether interprocedural optimization (IPO) is supported by the current toolchain and CMake version. * The "CMakeFindDependencyMacro" module "find_dependency" macro now forwards all arguments to the underlying "find_package()" call. Existing uses will continue to function as before, but callers can now access the full suite of arguments that "find_package" accepts. * The "FeatureSummary" module "feature_summary()" command now accepts the new "DEFAULT_DESCRIPTION" option that will print the default title for the selected package type. * The "FeatureSummary" module gained a new "FeatureSummary__DESCRIPTION" variable that can be defined for each "" to replace the type name with the specified string whenever the package type is used in an output string by the module. * The "FindDoxygen" module learned to control Doxygen behavior using CMake variables and generate documentation via the newly added "doxygen_add_docs()" function. The Doxygen input file ("Doxyfile") is automatically generated and doxygen is run as part of a custom target. Additional components can be specified to find optional tools: "dot", "mscgen" and "dia". * The "FindMPI" module now provides imported targets. * The "FindProtobuf" module "protobuf_generate_cpp()" command gained an "EXPORT_MACRO" option to specify the name of a DLL export markup macro. * The "FindProtobuf" module now supports usage of static libraries for Unix via a new "Protobuf_USE_STATIC_LIBS" input variable. * The "FindProtobuf" module now provides imported targets when the libraries are found. * A new "GoogleTest" module was added to provide the "gtest_add_tests()" function independently of the "FindGTest" module. The function was also updated to support keyword arguments, with functionality expanded to allow a test name prefix and suffix to be specified, the dependency on the source files to be optional and the list of discovered test cases to be returned to the caller. CTest ----- * The "ctest_submit()" command gained a "HTTPHEADER" option to specify custom headers to send during submission. * The "ctest(1)" executable gained new options which allow the developer to disable automatically adding tests to the test set to satisfy fixture dependencies. "-FS" prevents adding setup tests for fixtures matching the provided regular expression, "-FC" prevents adding cleanup tests for matching fixtures and "-FA" prevents adding any test for matching fixtures. * A "DISABLED" test property was added to mark tests that are configured but explicitly disabled so they do not run. CPack ----- * The "CPackArchive" module learned to modify the filename per- component. See the "CPACK_ARCHIVE_FILE_NAME" variable and its per- component version "CPACK_ARCHIVE__FILE_NAME". * The "CPackComponent" module "cpack_add_component()" command gained a new "PLIST " option to specify the "pkgbuild" "-- component-plist" argument when using the "productbuild" generator. * The "CPackIFW" module "cpack_ifw_configure_component()" and "cpack_ifw_configure_component_group()" commands gained internationalization support for "DISPLAY_NAME" and "DESCRIPTION" options. * The "CPackIFW" module learned the new hint "CPACK_IFW_ROOT" variable for finding the QtIFW tool suite installed in a non- standard place. * The "CPackProductBuild" module gained a new "CPACK_PRODUCTBUILD_RESOURCES_DIR" variable to specify resources to be copied into the "Resources" directory. * The "CPackRPM" module learned to modify the "debuginfo" package name. See the "CPACK_RPM_DEBUGINFO_FILE_NAME" variable. * The "CPackWIX" module patching system now has the ability to set additional attributes. This can be done by specifying attributes with the "CPackWiXFragment" XML tag after the "Id" attribute. See the "CPACK_WIX_PATCH_FILE" variable. * The CPack WIX generator implemented a new "CPACK_WIX_ROOT_FOLDER_ID" variable which allows using a custom root folder ID instead of the default "ProgramFilesFolder" / "ProgramFiles64Folder". Other ----- * Interprocedural optimization (IPO) is now supported for GNU and Clang compilers using link time optimization (LTO) flags. See the "INTERPROCEDURAL_OPTIMIZATION" target property and "CheckIPOSupported" module. * The "TARGET_OBJECTS" "generator expression" is now supported by the "add_custom_command()" and "file(GENERATE)" commands. * Two new informational generator expressions to retrieve Apple Bundle directories have been added. The first one "$" outputs the full path to the Bundle directory, the other one "$" outputs the full path to the "Contents" directory of macOS Bundles and App Bundles. For all other bundle types and SDKs it is identical with "$". The new expressions are helpful to query Bundle locations independent of the different Bundle types and layouts on macOS and iOS. Deprecated and Removed Features =============================== * An explicit deprecation diagnostic was added for policies "CMP0036" and below. The "cmake-policies(7)" manual explains that the OLD behaviors of all policies are deprecated and that projects should always port to the NEW behaviors as soon as possible. * The "Visual Studio 8 2005" generator is now deprecated and will be removed in a future version of CMake. * The "Visual Studio 7 .NET 2003" generator has been removed. * The "Xcode" generator dropped support for Xcode versions older than 3. * The "FindDoxygen" module has deprecated several variables. * The version of curl bundled with CMake no longer accepts URLs of the form "file://c:/..." on Windows due to a change in upstream curl 7.52. Use the form "file:///c:/..." instead to work on all versions. Other Changes ============= * When using "AUTOMOC", CMake now scans for the presence of the "Q_PLUGIN_METADATA" macro and reruns moc when the file from the macro's "FILE" argument changes. * When "AUTOMOC" detects an include statement of the form "#include "moc_.cpp"" the search for the respective header file now looks in the "INCLUDE_DIRECTORIES" of the target as well. * When running tests, CTest learned to treat skipped tests (using the "SKIP_RETURN_CODE" property) the same as tests with the new "DISABLED" property. Due to this change, CTest will not indicate failure when all tests are either skipped or pass. * The "Ninja" generator has loosened the dependencies of object compilation. Object compilation now depends only on custom targets and custom commands associated with libraries on which the object's target depends and no longer depends on the libraries themselves. Source files in dependent targets may now compile without waiting for their targets' dependencies to link. * On macOS, the default application bundle "Info.plist" file now enables Hi-DPI support. * On macOS, "RPATH" settings such as "BUILD_WITH_INSTALL_RPATH" no longer affect the "install_name" field. See policy "CMP0068". ---------------------------------------------------------------------------- Changes made since CMake 3.9.0-rc5: Brad King (11): VS: Fix GenerateDebugInformation values for v140 and v141 toolsets Autogen: Skip generated files for compatibility with CMake 3.8 find_package: Restore longer message when config files were considered VS: Choose VS 2017 instance via environment variable bindexplib: Revert support for constants symbols cmFindCommon: Fix typo in PackageName_ROOT path label cmFindCommon: Drop unused FilterPaths method find_*: Honor PATH_SUFFIXES in PackageName_ROOT paths VS: Add SolutionGuid to generated .sln files Android: Link to android_support with c++_shared CMake 3.9.0-rc6 Gregor Jasny (1): Xcode: Use correct Object Library paths for cross-SDK builds Ian Hojnicki (3): VS: Split link flag table between v140 and v141 toolsets VS: Fix GenerateDebugInformation flag map text for v141 toolsets VS: Add v140 and v141 flag table entries for /DEBUG:NONE and /DEBUG:FULL J?r?me Duval (1): curl: Fix build on Haiku Olender, Sebastian D (1): VS: Fix support for '/guard:cf' linker flag Robert Dailey (2): FindDoxygen: Use a stable reference to the location of global resources FindDoxygen: Create DOXYGEN_OUTPUT_DIRECTORY if it doesn't exist Sebastian Holtermann (3): Autogen: Check .moc header name against SKIP list Autogen: Continue search for FOO_p.h when FOO.h was found Autogen: Skip included files on demand From florent.castelli at gmail.com Wed Jul 12 15:00:28 2017 From: florent.castelli at gmail.com (Florent Castelli) Date: Wed, 12 Jul 2017 21:00:28 +0200 Subject: [CMake] Internal Interface Libraries and Header Dependencies In-Reply-To: References: Message-ID: <3512df5e-1dba-b0d3-c03e-2fe8dff0d363@gmail.com> If they were not propagated, it wouldn't compile at all, so they're definitely there somewhere. Can you show your CMakeLists.txt files? /Florent On 12/07/2017 19:59, Christian Mazakas wrote: > To give a brief overview of what I'm trying to do, right now I'm > working on a project with tests. I want to abstract my implementation > into a library that I can then link to when building both a testing > binary and an application binary. > > The issue is, my library is currently header-only. So I figured that I > would generate an interface library out of this. > > However, the header dependencies are not being propagated out to the > resulting executables. This means that any changes in my header files > appear to be ignored and don't cause the dependent source files to be > recompiled. The only way I can get proper behavior is to call > "target_include_directories" directly on each one of my executables. > > For reference, I'm using the "Visual Studio 14 2015 Win64" generator > on Windows 10, building a CUDA project. > > Does anyone have any insight on this? I can post my CMakeLists.txt > file should need be. > > - Chris > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjvbertin at gmail.com Wed Jul 12 15:14:31 2017 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Wed, 12 Jul 2017 21:14:31 +0200 Subject: [CMake] /path/to/libpng.so automatic conversion to -lpng ? References: <5397309.4dvKn07gbZ@bola> <2778594.yIuJqfDBxI@patux.local> <1623841.1qftnlEELx@daneel.sf-tec.de> Message-ID: <28321216.Ad9J4h3AHM@patux.local> Rolf Eike Beer wrote: >> It seems that clang handles that variable in a somewhat different manner >> than GCC does. Even in a very simple call on the commandline (including the >> -v option) I see it adds -L/opt/local/lib AFTER the user-supplied >> libraries, where GCC puts it before the 1st -l option. > > Welcome to the work of link_directories(). This is exactly the reason to avoid > it: it always causes trouble. digikam (that's the project we're talking about) doesn't use neither that nor target_link_directories. And if CMake simply used the libraries as found and specified in the target_link_libraries() call I wouldn't have run into problems either. I did raise a flag on the clang ML though. But whether it's a clang bug or feature the fact remains that ideally one should be able to tell cmake exactly what to do, without it trying to outguess the operator. R. From eric.noulard at gmail.com Wed Jul 12 15:46:25 2017 From: eric.noulard at gmail.com (Eric Noulard) Date: Wed, 12 Jul 2017 21:46:25 +0200 Subject: [CMake] /path/to/libpng.so automatic conversion to -lpng ? In-Reply-To: <28321216.Ad9J4h3AHM@patux.local> References: <5397309.4dvKn07gbZ@bola> <2778594.yIuJqfDBxI@patux.local> <1623841.1qftnlEELx@daneel.sf-tec.de> <28321216.Ad9J4h3AHM@patux.local> Message-ID: 2017-07-12 21:14 GMT+02:00 Ren? J. V. Bertin : > Rolf Eike Beer wrote: > > >> It seems that clang handles that variable in a somewhat different manner > >> than GCC does. Even in a very simple call on the commandline (including > the > >> -v option) I see it adds -L/opt/local/lib AFTER the user-supplied > >> libraries, where GCC puts it before the 1st -l option. > > > > Welcome to the work of link_directories(). This is exactly the reason to > avoid > > it: it always causes trouble. > > digikam (that's the project we're talking about) doesn't use neither that > nor > target_link_directories. And if CMake simply used the libraries as found > and > specified in the target_link_libraries() call I wouldn't have run into > problems > either. > AFAIK the explanation you gave. CMake does not seem to play with -l or -L options. the FindPNG.cmake shipped with CMake does not do that either. Current digikam does use ${PNG_LIBRARIES} where he should now use PNG::PNG imported lib. (introduced in CMake 3.5.0 though) Which version of CMake are you using? Which version of digikam are you trying to compile? Did you try to message(STATUS "show me PNG_LIBRARIES=${PNG_LIBRARIES}") in the digikam CMakeLists.txt in order to be sure of the content of this in your case. > I did raise a flag on the clang ML though. But whether it's a clang bug or > feature the fact remains that ideally one should be able to tell cmake > exactly > what to do, without it trying to outguess the operator. > Now I'm lost. If the culprit is a clang feature/bugs then why did you suspect CMake in the frst place? Does the command line produced by the CMake generator you use (?makefile ?ninja ?) contains the full path to lib or -L + -l flags? -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjvbertin at gmail.com Wed Jul 12 19:55:42 2017 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Thu, 13 Jul 2017 01:55:42 +0200 Subject: [CMake] /path/to/libpng.so automatic conversion to -lpng ? References: <5397309.4dvKn07gbZ@bola> <2778594.yIuJqfDBxI@patux.local> <1623841.1qftnlEELx@daneel.sf-tec.de> <28321216.Ad9J4h3AHM@patux.local> Message-ID: <2630435.p9hGBEdrVQ@portia.local> Eric Noulard wrote: > AFAIK the explanation you gave. CMake does not seem to play with -l or -L > options. As Rolf said above, apparently it does. > the FindPNG.cmake shipped with CMake does not do that either. Indeed, it sets PNG_LIBRARY to the path of libpng, and PNG_LIBRARIES to the 2 required libraries (libpng and libz), both with full path. There would be no problem if that data ended up in the linker command. > Which version of CMake are you using? 3.8.2 > Which version of digikam are you trying to compile? 5.6.0 > Did you try to > > message(STATUS "show me PNG_LIBRARIES=${PNG_LIBRARIES}") Yes, the variable contains the correct 2 paths. > Now I'm lost. If the culprit is a clang feature/bugs then why did you > suspect CMake in the frst place? Because at the end of the day that doesn't matter : CMake must generate Makefiles that work, and thus has to work around known issues or peculiarities in the compilers it support. That could be through hardwired exceptions, but in this case could also be by providing a way to disable rewriting those library specifications. Maybe there is, I haven't yet found any documentation whatsoever about the conditions under which CMake will (supposedly) replace a /path/to/libfoo.so libspec with -lfoo . > Does the command line produced by the CMake generator you use (?makefile > ?ninja ?) contains > the full path to lib or -L + -l flags? No. It contains -lpng -lz but no -L flag. See the more specific discussion in cmake-devel ("FindPNG.cmake doesn't return a LIBRARY_DIR variable"). R. From rjvbertin at gmail.com Wed Jul 12 20:04:43 2017 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Thu, 13 Jul 2017 02:04:43 +0200 Subject: [CMake] /path/to/libpng.so automatic conversion to -lpng ? References: <5397309.4dvKn07gbZ@bola> Message-ID: <93793723.Tgf3vSAAGC@portia.local> Andreas Naumann wrote: > cmake instrospects your compiler and asks for system directories. Just stumbled across this documentation tidbit: >>>>>>> CMAKE__IMPLICIT_LINK_DIRECTORIES -------------------------------------- Implicit linker search path detected for language ````. Compilers typically pass directories containing language runtime libraries and default library search paths when they invoke a linker. These paths are implicit linker search directories for the compiler's language. CMake automatically detects these directories for each language and reports the results in this variable. When a library in one of these directories is given by full path to :command:`target_link_libraries` CMake will generate the ``-l`` form on link lines to ensure the linker searches its implicit directories for the library. Note that some toolchains read implicit directories from an environment variable such as ``LIBRARY_PATH`` so keep its value consistent when operating in a given build tree. <<<<<<< Note the > CMake will generate the ``-l`` form on link lines to ensure the linker > searches its implicit directories What's the point in doing that when a full path is given? Full path means searching isn't required. Full path (probably) means that the operator wants to ensure that a specific library is linked. Full path thus means that searching can even have counterproductive effects. R. From eric.noulard at gmail.com Thu Jul 13 05:36:33 2017 From: eric.noulard at gmail.com (Eric Noulard) Date: Thu, 13 Jul 2017 11:36:33 +0200 Subject: [CMake] /path/to/libpng.so automatic conversion to -lpng ? In-Reply-To: <93793723.Tgf3vSAAGC@portia.local> References: <5397309.4dvKn07gbZ@bola> <93793723.Tgf3vSAAGC@portia.local> Message-ID: 2017-07-13 2:04 GMT+02:00 Ren? J. V. Bertin : > Andreas Naumann wrote: > > > cmake instrospects your compiler and asks for system directories. > > Just stumbled across this documentation tidbit: > Thanks you for digging this. I totally ignored that "feature". > > >>>>>>> > CMAKE__IMPLICIT_LINK_DIRECTORIES > -------------------------------------- > > Implicit linker search path detected for language ````. > > Compilers typically pass directories containing language runtime > libraries and default library search paths when they invoke a linker. > These paths are implicit linker search directories for the compiler's > language. CMake automatically detects these directories for each > language and reports the results in this variable. > > When a library in one of these directories is given by full path to > :command:`target_link_libraries` CMake will generate the ``-l`` > form on > link lines to ensure the linker searches its implicit directories for the > library. Note that some toolchains read implicit directories from an > environment variable such as ``LIBRARY_PATH`` so keep its value consistent > when operating in a given build tree. > <<<<<<< > > Note the > > CMake will generate the ``-l`` form on link lines to ensure the > linker > > searches its implicit directories > > What's the point in doing that when a full path is given? Full path means > searching isn't required. Full path (probably) means that the operator > wants to > ensure that a specific library is linked. Full path thus means that > searching > can even have counterproductive effects > I you have a look at file: https://github.com/Kitware/CMake/blob/master/Source/cmComputeLinkInformation.cxx you may discovered (as I just did) that not all CMake supported systems kindly accept full path to library for linking... so may be the implicit system link dir was introduced for them in the first place. I guess the author/contributor to this part of CMake may certainly explain that better than me. Looking the code is interesting because apparently what you need is to set CMP0060 to NEW: $ cmake --help-policy CMP0060 CMP0060 ------- Link libraries by full path even in implicit directories. .... The OLD behavior for this policy is to ask the linker to search for libraries whose full paths are known to be in implicit link directories. The NEW behavior for this policy is to link libraries by full path even if they are in implicit link directories. This policy was introduced in CMake version 3.3. Unlike most policies, CMake version 3.7.2 does *not* warn by default when this policy is not set and simply uses OLD behavior. See documentation of the ``CMAKE_POLICY_WARNING_CMP0060`` variable to control the warning. The thing I don't understand is that you use CMake 3.8.2 so you should get the new behavior. However since digikam does a cmake_minimum_required(VERSION 3.0.0) which may set the CMP0060 to old. -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjvbertin at gmail.com Thu Jul 13 06:07:48 2017 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Thu, 13 Jul 2017 12:07:48 +0200 Subject: [CMake] /path/to/libpng.so automatic conversion to -lpng ? References: <5397309.4dvKn07gbZ@bola> <93793723.Tgf3vSAAGC@portia.local> Message-ID: <4183791.a8drEJgkA1@portia.local> Eric Noulard wrote: > Thanks you for digging this. > I totally ignored that "feature". I guess most of us did, it's one of those things that usually works just fine but that when it breaks sends you on a nasty quest to figure out WTF is going on (IOW, makes you doubt yourself until you realise you just discovered a hidden feature). I found this only because I searched the CMake source tree for LIBRARY_PATH to see where it does the rewriting. I would never have guessed to find the feature biting me under the concept "implicit directories". > I you have a look at file: > https://github.com/Kitware/CMake/blob/master/Source/cmComputeLinkInformation.cxx > > you may discovered (as I just did) that not all CMake supported systems > kindly accept full path to library for linking... CMake being a system that allows to describe how to build a project in a platform-agnostic way it could easily have handled those systems individually. > I guess the author/contributor to this part of CMake may certainly explain > that better than me. Presumably, and I guess s/he might admit not having thought of (or tested) the kind of situation where rewriting breaks things. Something you said in a mail that apparently didn't go to the list: > OK, but I don't think CMake should "fight" the underlying compiler. No. Clang may have a reason for the different way of handling LIBRARY_PATH which means you'd have to leave a possibility for it to work that way - maybe even by default. But in this case we're not fighting the compiler, we're trying to let it work another way that is just as supported. > Looking the code is interesting because apparently what you need is to set > CMP0060 to NEW: > > $ cmake --help-policy CMP0060 > CMP0060 Ah, great. I would probably have found that by myself, eventually. > ------- > > Link libraries by full path even in implicit directories. > .... > > The OLD behavior for this policy is to ask the linker to search for > libraries whose full paths are known to be in implicit link directories. > The NEW behavior for this policy is to link libraries by full path even > if they are in implicit link directories. > > This policy was introduced in CMake version 3.3. Unlike most policies, > CMake version 3.7.2 does *not* warn by default when this policy > is not set and simply uses OLD behavior. See documentation of the > ``CMAKE_POLICY_WARNING_CMP0060`` > variable to control the warning. > > > The thing I don't understand is that you use CMake 3.8.2 so you should get > the new behavior. Are you sure? I read from the description above that you have to set the policy explicitly. Do you know if one can set policies like this from the commandline rather than through patching each toplevel CMakeLists.txt file? Or can it be set for just a subdirectory? > However since digikam does a cmake_minimum_required(VERSION 3.0.0) which may > set the CMP0060 to old. Quite possible, I've run into naggles with that with another policy on Mac (25). It's annoying that this happens with digikam which is a really cumbersome project (it takes ages just to run make just to confirm that everything has been built). R. From eric.noulard at gmail.com Thu Jul 13 06:32:19 2017 From: eric.noulard at gmail.com (Eric Noulard) Date: Thu, 13 Jul 2017 12:32:19 +0200 Subject: [CMake] /path/to/libpng.so automatic conversion to -lpng ? In-Reply-To: <4183791.a8drEJgkA1@portia.local> References: <5397309.4dvKn07gbZ@bola> <93793723.Tgf3vSAAGC@portia.local> <4183791.a8drEJgkA1@portia.local> Message-ID: 2017-07-13 12:07 GMT+02:00 Ren? J. V. Bertin : [...] > > > > > The thing I don't understand is that you use CMake 3.8.2 so you should > get > > the new behavior. > > Are you sure? I read from the description above that you have to set the > policy > explicitly. > You are right, it depends on the cmake_minimum_required statement you gave. > > Do you know if one can set policies like this from the commandline rather > than > through patching each toplevel CMakeLists.txt file? Or can it be set for > just a > subdirectory? > >From the command line I doubt it. However CMake handles a policy stack: https://cmake.org/cmake/help/v3.7/command/cmake_policy.html so that you can enable the NEW behavior of a policy locally in a particular CMakeLists.txt or function etc... > > However since digikam does a cmake_minimum_required(VERSION 3.0.0) which > may > > set the CMP0060 to old. > > Quite possible, I've run into naggles with that with another policy on Mac > (25). > It's annoying that this happens with digikam which is a really cumbersome > project (it takes ages just to run make just to confirm that everything > has been > built). > Did you try to use ninja generator instead of make ? The no-op build is really faster with ninja. -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjvbertin at gmail.com Thu Jul 13 07:01:09 2017 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Thu, 13 Jul 2017 13:01:09 +0200 Subject: [CMake] /path/to/libpng.so automatic conversion to -lpng ? References: <5397309.4dvKn07gbZ@bola> <93793723.Tgf3vSAAGC@portia.local> <4183791.a8drEJgkA1@portia.local> Message-ID: <12841497.393ny3UNni@patux.local> Eric Noulard wrote: > From the command line I doubt it. Adding -DCMAKE_POLICY_DEFAULT_CMP0060=NEW on the commandline works. But whatever the reason, using PNG::PNG works too. Apparently policy 60 doesn't affect the IMPORTED_LOCATION target property... > Did you try to use ninja generator instead of make ? > The no-op build is really faster with ninja. I compared single full builds with ninja and make yesterday; with ninja it was actually (a bit) slower and required more resources (including a larger build directory). My main gripe with it is that you cannot simply launch a partial build from a subdirectory. R From eric.noulard at gmail.com Thu Jul 13 07:13:42 2017 From: eric.noulard at gmail.com (Eric Noulard) Date: Thu, 13 Jul 2017 13:13:42 +0200 Subject: [CMake] /path/to/libpng.so automatic conversion to -lpng ? In-Reply-To: <12841497.393ny3UNni@patux.local> References: <5397309.4dvKn07gbZ@bola> <93793723.Tgf3vSAAGC@portia.local> <4183791.a8drEJgkA1@portia.local> <12841497.393ny3UNni@patux.local> Message-ID: 2017-07-13 13:01 GMT+02:00 Ren? J. V. Bertin : > Eric Noulard wrote: > > > From the command line I doubt it. > > Adding -DCMAKE_POLICY_DEFAULT_CMP0060=NEW on the commandline works. > Good to know. > > But whatever the reason, using PNG::PNG works too. Apparently policy 60 > doesn't > affect the IMPORTED_LOCATION target property... > I guess this is expected and this is one advantage of imported library vs plain path to lib. > Did you try to use ninja generator instead of make ? > > The no-op build is really faster with ninja. > > I compared single full builds with ninja and make yesterday; with ninja it > was > actually (a bit) slower and required more resources (including a larger > build > directory). Do run make with parallel build? I was speaking of a no-op build but for full build it may depends on your main memory amount. Ninja is parallel by default and in some case if you have many core (like 8 or more) but not so much memory, ninja will generate as many compile/link job as you have core (+2 I think) which may be too much makes your system swap. In that case you can control it yourself using ninja -j or ninja -l My main gripe with it is that you cannot simply launch a partial > build from a subdirectory. > Ninja generator is different is it not directory-based because you have a single build.ninja file. However you can easily build any (sub)directory of your project using: ninja Path/To/Dir/all -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From ghleclerc at gmail.com Thu Jul 13 09:50:56 2017 From: ghleclerc at gmail.com (Ghyslain Leclerc) Date: Thu, 13 Jul 2017 09:50:56 -0400 Subject: [CMake] Ninja generator and showIncludes Message-ID: <7cf1d595-c27a-4b7c-b9bd-1e31db89d5b3@Spark> Hello. I have been searching for a way to prevent the Ninja generator from issuing the showIncludes command to cl. With our update to the latest CMake (3.8.2) on Windows (7 enterprise, at work) with the latest MSVC (2017 community), we now have a ton of messages saying Note: including file: which makes it difficult to see the actual compilation warnings and errors. Turned to Google and found some information about localization potentially being a problem, so I uninstalled MSVC 2017 which was in the French version and installed the English one. Turns out that only made the include messages English. :) I searched the documentation for a target property that I could use but did not find anything. I thought of using target compile flag, but not sure how I would remove a flag. Searched the mailing list for some info, but most of what I have found does not answer my question. For instance : http://cmake.org/pipermail/cmake-developers/2013-November/020782.html I also looked in the bug tracker and there does not seem to be any issue relating to that, so my guess is I am doing something wrong. So if anyone else has had that problem and/or has a solution for me, I'd appreciate any insight. Thanks. Ghyslain Leclerc -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcdailey.lists at gmail.com Thu Jul 13 11:11:42 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Thu, 13 Jul 2017 10:11:42 -0500 Subject: [CMake] GetPrerequisites with Android? Message-ID: Has anyone used GetPrerequisites[1] when cross-compiling a shared library with Android NDK toolchain? I'd like some way to get dependent *.so files (located in the NDK itself and specified on the linker command line when building) so I can copy them to my android java project dir under "libs" so they get packaged when the APK is built. [1]: https://cmake.org/cmake/help/v3.9/module/GetPrerequisites.html From juan.e.sanchez at gmail.com Thu Jul 13 15:29:38 2017 From: juan.e.sanchez at gmail.com (Juan E. Sanchez) Date: Thu, 13 Jul 2017 14:29:38 -0500 Subject: [CMake] fortran linking issue Message-ID: When I set the linker language of a fortran program to "C", it automatically links in -lgfortran, -lquadmath, -lm. SET_TARGET_PROPERTIES(main_f PROPERTIES LINKER_LANGUAGE "C") Unfortunately, that precludes me linking in static versions of -lquadmath. How do I tell CMAKE not to append these libraries when I change the LINKER_LANGUAGE to "C"? Regards, Juan From juan.e.sanchez at gmail.com Thu Jul 13 16:56:19 2017 From: juan.e.sanchez at gmail.com (Juan E. Sanchez) Date: Thu, 13 Jul 2017 15:56:19 -0500 Subject: [CMake] fortran linking issue In-Reply-To: References: Message-ID: It turns out these linker flags were being added by cmake. To disable them, I had to: unset(CMAKE_Fortran_IMPLICIT_LINK_LIBRARIES) I was then able to use SET_TARGET_PROPERTIES to link into the static versions of the code I wanted. This also fixed the issue for the case where I had a C++ exe with a Fortran library. In this case, I only needed to use TARGET_LINK_LIBRARIES to bring in my static gfortran and quadmath libraries. It turns out that libgfortran has its own link to libquadmath, so I was forced to statically link that as well. Regards, Juan On 7/13/17 2:29 PM, Juan E. Sanchez wrote: > When I set the linker language of a fortran program to "C", it > automatically links in -lgfortran, -lquadmath, -lm. > > SET_TARGET_PROPERTIES(main_f PROPERTIES LINKER_LANGUAGE "C") > > Unfortunately, that precludes me linking in static versions of -lquadmath. > > How do I tell CMAKE not to append these libraries when I change the > LINKER_LANGUAGE to "C"? > > Regards, > > Juan From mailinglists at xgm.de Thu Jul 13 22:33:12 2017 From: mailinglists at xgm.de (Florian Lindner) Date: Fri, 14 Jul 2017 10:33:12 +0800 Subject: [CMake] How to add project files? Message-ID: Hello, our project, which is currently using scons is structured like this ROOT - SConstruct - CMakeLists.txt - src/ - SConscript - CMAkeLists.txt - Module1 - somesourcefiles.cpp - tests/ - testsourcefiles.cpp - config/ - configsourcefile.cpp - Module2 (like Module1) - ... Right now the SConstruct calls SConscript sourcesModule1 = [ Glob('Module1/*.cpp'), Glob('Module2/config/*.cpp') ] The test files (Boost Test) are compiled to a standalone executable sourcesTests = [ Glob('*/tests/*.cpp'), File("testing/main.cpp") ] We currently have 4 targets. A static and dynamic lib (comprised of all modules), a binary (comprised of all modules + main.cpp) and the test binary (all modules, tests and test main.cpp). I was able to replicate that structure with CMake and it builds fine: src/CMakeLists.txt: file(GLOB sourcesAllNoMain "Module1/*.cpp" "Module1/config/*.cpp") file(GLOB sourcesTests "*/tests/*.cpp") set (sourcesAllNoMain ${sourcesAllNoMain} PARENT_SCOPE) set (sourcesTests ${sourcesTests} PARENT_SCOPE) ROOT/CMakeLists.txt: add_subdirectory("src") add_library(solib ${sourcesAllNoMain}) set_target_properties(solib PROPERTIES OUTPUT_NAME libprecice) target_link_libraries(solib ${PYTHON_LIBRARIES}) target_link_libraries(solib ${MPI_LIBRARIES}) target_link_libraries(solib ${Boost_LIBRARIES}) target_link_libraries(solib ${petsc}) Now, in the docs I everywhere read not to add the files using GLOB. However, I have found no definitive guide how to add project files in a large project with subdirs like that. How would you do it in cmakeish fashion? I know this might be a FAQ, but googled for days and found no suitable answer. Thanks a lot, Florian From rleigh at codelibre.net Fri Jul 14 06:16:58 2017 From: rleigh at codelibre.net (rleigh at codelibre.net) Date: Fri, 14 Jul 2017 11:16:58 +0100 Subject: [CMake] How to add project files? In-Reply-To: References: Message-ID: <490315604d9a42cce7e4a3ba6aa87eea@codelibre.net> On 2017-07-14 03:33, Florian Lindner wrote: > Now, in the docs I everywhere read not to add the files using GLOB. > However, I have found no definitive guide how to add > project files in a large project with subdirs like that. > > How would you do it in cmakeish fashion? List each file explicitly. For example, see https://github.com/apache/xerces-c/blob/trunk/src/CMakeLists.txt No potential for inclusion of a stray file which gets globbed unintentionally, and any change to the lists will force cmake to be re-run, and the targets rebuilt. Regards, Roger From rcdailey.lists at gmail.com Fri Jul 14 09:14:26 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Fri, 14 Jul 2017 08:14:26 -0500 Subject: [CMake] ExternalProject with toolchain files for cross compiling? Message-ID: So I'd like to use ExternalProject_Add() to pull down an external git repository that builds with CMake. I'd like it to use the same toolchain file that I"m using in my parent projects. However, I do not see any explicit documentation regarding toolchain support for ExternalProject. Do I need to explicitly pass down CMake arguments with the toolchain file? Or does this happen transitively? I'm using CMake 3.9.0 From sergey.nikulov at gmail.com Fri Jul 14 10:05:08 2017 From: sergey.nikulov at gmail.com (Sergei Nikulov) Date: Fri, 14 Jul 2017 17:05:08 +0300 Subject: [CMake] ExternalProject with toolchain files for cross compiling? In-Reply-To: References: Message-ID: 2017-07-14 16:14 GMT+03:00 Robert Dailey : > So I'd like to use ExternalProject_Add() to pull down an external git > repository that builds with CMake. I'd like it to use the same > toolchain file that I"m using in my parent projects. However, I do not > see any explicit documentation regarding toolchain support for > ExternalProject. Do I need to explicitly pass down CMake arguments > with the toolchain file? Or does this happen transitively? I'm using > CMake 3.9.0 I use CMAKE_ARGS option for that https://cmake.org/cmake/help/v3.9/module/ExternalProject.html?highlight=externalproject_add#command:externalproject_add HTH. -- Best Regards, Sergei Nikulov From nicmail777 at yahoo.com Sun Jul 16 07:01:15 2017 From: nicmail777 at yahoo.com (Itzik S) Date: Sun, 16 Jul 2017 11:01:15 +0000 (UTC) Subject: [CMake] Is it possible to add xcconfig file to xcode project using cmake ? References: <1661949697.1477922.1500202875732.ref@mail.yahoo.com> Message-ID: <1661949697.1477922.1500202875732@mail.yahoo.com> Hi, xcconfig files are treated by xcode, as "Build configuration properties", and are an easy way to store all compilation settings in simple text file. I'm working on an a cross platform project,and would like to add this file when targeting mac os. The file and its content, already exist, all I need it, as it when adding it, it will be added as "Build configuration properties" and not as "Source code" Is it possible to do it using cmake ? Thanks for your help, Si. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lp.cordier at dynamixyz.com Mon Jul 17 04:41:13 2017 From: lp.cordier at dynamixyz.com (Louis-Paul CORDIER) Date: Mon, 17 Jul 2017 10:41:13 +0200 Subject: [CMake] DLL handling under CMake In-Reply-To: <612ed9d4-61ce-b3a2-2a39-887deeceb3b2@dynamixyz.com> References: <2114FB31-FF89-4461-8713-75FAA7179E4E@hendrik-sattler.de> <590add90.925c1c0a.632e2.33a2@mx.google.com> <612ed9d4-61ce-b3a2-2a39-887deeceb3b2@dynamixyz.com> Message-ID: Hi, I bump this question again for DLL library handling. Still I have the issue with my dependency "scanner" in my previous email that can't evaluate if a target with a generator expression is a valid one or not. if(NOT TARGET "$<$:Foo_lib>") # will never go into this statement endif() Thanks, LP Le 04/07/2017 ? 10:19, Louis-Paul CORDIER a ?crit : > > Hi, > > Thank you very much for this code snippet. However I don't like the > fixup_bundle function, as it takes the first dll that it found to be > linked against. > > I also did a try with a dependency scanning function. It is quiet long > to write, but I guess it is the cleanest way to handle DLL under Windows. > Note: I still have an issue with this function. Indeed, if user uses > Generator expressions for library dependencies, it will not work. > e.g: > add_library(Foo_lib IMPORTED GLOBAL) > # ... set location properties > target_link_libraries(${PROJECT_NAME} optimized > $<$:Foo_lib>) > > Any idea for a workaround? What do you think about this CMake code? > > Also, I would see a real benefit to add a LINK_DEPENDENT_LIBRARIES > property (inspired of IMPORTED_LINK_DEPENDENT_LIBRARIES) to each > target that could be automatically filled by each > target_link_libraries() calls. > > > > # This function scan all dependencies of a project recursively, and > retrieve all shared > # library associated with it. > # Prerequisite: your upstream CMakeLists.txt must make use of > add_library(foo SHARED IMPORTED GLOBAL), > # and fill the following properties on the imported target: > # set_target_properties(foo PROPERTIES IMPORTED_IMPLIB "path_to_foo.lib") > # set_target_properties(foo PROPERTIES IMPORTED_LOCATION > "path_to_foo.dll") > # set_target_properties(foo PROPERTIES > IMPORTED_LINK_DEPENDENT_LIBRARIES "path_to_dll_on_which_foo_depends.dll") > # GLOBAL keyword is important as it allows downstream CMakeLists.txt > to scan dependencies. > > # Input parameters: > # dep_to_scan: your downstream project > # config_to_scan: configuration to use for the scanning. > # output_variable: variable in which the function stores the result. > > # Usage: > # RECURSIVE_SCAN(my_app Release DLLS) > # install(FILES ${DLLS} > # DESTINATION release > # CONFIGURATIONS Release) > > set(COUNT 0) > function(RECURSIVE_SCAN dep_to_scan config_to_scan output_variable) > > MATH(EXPR COUNT "${COUNT}+1") > string(RANDOM LENGTH ${COUNT} ALPHABET "-" SPACES) > > message("${SPACES} Scanning ${dep_to_scan}") > if(NOT TARGET ${dep_to_scan}) > MATH(EXPR COUNT "${COUNT}-1") > #message("${dep_to_scan} Is not target") > return() > endif() > > > get_target_property(_is_imported ${dep_to_scan} IMPORTED) > if(_is_imported) > > # We need to check if the imported library rely on other shared > libraries. > get_target_property(_dependent_dll ${_lib} > IMPORTED_LINK_DEPENDENT_LIBRARIES_${config_to_scan}) > if(NOT _dependent_dll) > get_target_property(_dependent_dll ${_lib} > IMPORTED_LINK_DEPENDENT_LIBRARIES) > endif() > > if(_dependent_dll) > list(APPEND ${output_variable} ${_dependent_dll}) > endif() > > > #Otherwise, check if it is a shared library. (LOCATION variable > can be > # either .lib or DLL regarding of the type of library.) > get_target_property(_TYPE ${dep_to_scan} TYPE) > > if(NOT _TYPE STREQUAL STATIC_LIBRARY) > get_target_property(_dll_found ${dep_to_scan} > LOCATION_${config_to_scan}) > if(_dll_found) > list(APPEND ${output_variable} ${_dll_found}) > endif() > > endif() > > message("${SPACES}- DLL found: (${${output_variable}})") > > endif(_is_imported) > > get_target_property(_libraries ${dep_to_scan} INTERFACE_LINK_LIBRARIES) > > if(_libraries) > foreach(_lib ${_libraries}) > RECURSIVE_SCAN(${_lib} ${config_to_scan} ${output_variable}) > endforeach() > endif() > > # If we reach our first recursion, we need to clean the list of > # DLL in order to remove duplicates. > MATH(EXPR COUNT "${COUNT}-1") > > if(${COUNT} EQUAL 0) > list(REMOVE_DUPLICATES ${output_variable}) > endif() > > set(${output_variable} ${${output_variable}} PARENT_SCOPE) > > endfunction(RECURSIVE_SCAN) > > > Best regards, > > Louis-Paul CORDIER > > Le 04/05/2017 ? 09:51, lectem at gmail.com a ?crit : >> >> I managed to get it working by using an intermediate script. >> >> One might want to generate the script instead of using the ? RUN_IT ? >> variable trick. >> >> This was only tested on Windows, but seems to work fine. >> >> Put the following code in a xxxxxx.cmake file, include it from your >> CMakeLists.txt and enjoy. >> >> # This is a helper script to run BundleUtilities fixup_bundle as >> postbuild >> >> # for a target. The primary use case is to copy .DLLs to the build >> directory for >> >> # the Windows platform. It allows generator expressions to be used to >> determine >> >> # the binary location >> >> # >> >> # Usage : run_fixup(TARGET LIBS DIRS) >> >> # - TARGET : A cmake target >> >> # - See fixup_bundle for LIBS and DIRS arguments >> >> if(RUN_IT) >> >> # Script ran by the add_custom_command >> >> include(BundleUtilities) >> >> fixup_bundle("${TO_FIXUP_FILE}" "${TO_FIXUP_LIBS}" "${TO_FIXUP_DIRS}") >> >> # End of script ran by the add_custom_command >> >> else() >> >> set(THIS_FILE ${CMAKE_CURRENT_LIST_FILE}) >> >> message(${THIS_FILE}) >> >> function(run_fixup _target _libs _dirs) >> >> message(${THIS_FILE}) >> >> add_custom_command( >> >> TARGET ${_target} POST_BUILD >> >> COMMAND ${CMAKE_COMMAND} >> -DRUN_IT:BOOL=ON -DTO_FIXUP_FILE=$ >> -DTO_FIXUP_LIBS=${_libs} -DTO_FIXUP_DIRS=${_dirs} -P ${THIS_FILE} >> >> COMMENT "Fixing up dependencies for >> ${_target}" >> >> VERBATIM >> >> ) >> >> endfunction() >> >> endif() >> >> *De : *Cl?ment Gregoire >> *Envoy? le :*jeudi 4 mai 2017 08:37 >> *? : *Hendrik Sattler ; Louis-Paul >> CORDIER ; Cmake Mailing List >> >> *Objet :*Re: [CMake] DLL handling under CMake >> >> I'd also be interested in this. I saw an old mail in the ML about >> this, but it seems fixup_bundle is old and cant use generator >> expressions, making it hard to use (I don't want to hardcode the >> executable path). >> >> Do you have a sample for this ? >> >> CMake would really benefit from having those features made more >> accessible instead of everyone having to write its own script >> >> Le sam. 29 avr. 2017 22:10, Hendrik Sattler > > a ?crit : >> >> >> >> Am 27. April 2017 10:43:50 MESZ schrieb Louis-Paul CORDIER >> >: >> >This steps are tedious and I'm wondering if there is a mechanism that >> >exists or that have to be imagined to make the DLL nightmare end. >> >> I use BundleUtilities to achieve the copying of DLL files to the >> installation directory. The main problem for this is to enumerate the >> needed directories. >> >> I use the same for copying DLL files to the output directory to ease >> debugging. >> >> The advantage is the inspection of the exe for really needed DLL >> files. This AUTOMATICALLY handles the case debug vs. release. >> >> 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 >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From deniz.bahadir at benocs.com Mon Jul 17 09:52:12 2017 From: deniz.bahadir at benocs.com (Deniz Bahadir) Date: Mon, 17 Jul 2017 15:52:12 +0200 Subject: [CMake] How to get list of generated object-files of OBJECT-library? Message-ID: Hi list, I have a question regarding "add_custom_command" and OBJECT-libraries: My CMakeLists.txt contains the following (simplified) targets: ``` set ( SOURCE_FILES # ... several C++-source files ) add_library( OBJECT ${PROJECT_NAME}_OBJECTS ${SOURCE_FILES} ) add_library( ${PROJECT_NAME} $ ) ``` This works just fine. However, now I want to add an additional build-step after creation of the object-files and before linking the shared library. (In particular, I want to compress the debug-symbols in the object-files. But that should be irrelevant for my question.) My first attempt was to add the following between the two add_library commands: ``` add_custom_command( TARGET ${PROJECT_NAME}_OBJECTS POST_BUILD COMMAND objcopy --compress-debug-sections $ ) ``` But that results in the following error: ``` (add_custom_command): Target "MyProject_OBJECTS" is an OBJECT library that may not have PRE_BUILD, PRE_LINK, or POST_BUILD commands. ``` So I tried instead to add the following between the two add_library commands: ``` add_custom_command( TARGET ${PROJECT_NAME} PRE_LINK COMMAND objcopy --compress-debug-sections $ ) ``` This then fails when evaluating the generator-expression: ``` (add_custom_command): Error evaluating generator expression: $ The evaluation of the TARGET_OBJECTS generator expression is only suitable for consumption by CMake. It is not suitable for writing out elsewhere. ``` So I am currently out of ideas (which do not make the CMakeLists.txt file completely unmaintainable). Therefore my question is: How can I retrieve the list of generated object-files so that I can pass it to another program that should be run as additional build-step before linking? IMHO, the most comfortable (and syntactically cleanest) way would be my first attempt. But that is probably more a feature-request than a simple question. Thanks for your help. Deniz Bahadir From nilsgladitz at gmail.com Mon Jul 17 10:47:00 2017 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Mon, 17 Jul 2017 16:47:00 +0200 Subject: [CMake] How to get list of generated object-files of OBJECT-library? In-Reply-To: References: Message-ID: <596CCDE4.6050000@gmail.com> On 7/17/2017 3:52 PM, Deniz Bahadir wrote: > > This works just fine. However, now I want to add an additional > build-step after creation of the object-files and before linking the > shared library. (In particular, I want to compress the debug-symbols > in the object-files. But that should be irrelevant for my question.) > > My first attempt was to add the following between the two add_library > commands: > ``` > add_custom_command( TARGET ${PROJECT_NAME}_OBJECTS POST_BUILD > COMMAND objcopy --compress-debug-sections > $ > ) > ``` > But that results in the following error: > ``` > (add_custom_command): > Target "MyProject_OBJECTS" is an OBJECT library that may not > have PRE_BUILD, PRE_LINK, or POST_BUILD commands. > ``` > > So I tried instead to add the following between the two add_library > commands: > ``` > add_custom_command( TARGET ${PROJECT_NAME} PRE_LINK > COMMAND objcopy --compress-debug-sections > $ > ) > ``` > This then fails when evaluating the generator-expression: > ``` > (add_custom_command): > Error evaluating generator expression: > > $ > > The evaluation of the TARGET_OBJECTS generator expression is only > suitable > for consumption by CMake. It is not suitable for writing out > elsewhere. > ``` > > So I am currently out of ideas (which do not make the CMakeLists.txt > file completely unmaintainable). Therefore my question is: > > How can I retrieve the list of generated object-files so that I can > pass it to another program that should be run as additional build-step > before linking? > > IMHO, the most comfortable (and syntactically cleanest) way would be > my first attempt. But that is probably more a feature-request than a > simple question. FWIW this was implemented in the upcoming 3.9: https://cmake.org/cmake/help/latest/module/CPackIFW.html#command:cpack_ifw_configure_component Nils From rcdailey.lists at gmail.com Mon Jul 17 10:58:57 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Mon, 17 Jul 2017 09:58:57 -0500 Subject: [CMake] Built-in way to detect if a root script is standalone or not? Message-ID: I have logic similar to this in some of my middleware libraries' root CMakeLists.txt: if( CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR ) set( STANDALONE TRUE ) endif() Is there a built-in way to detect this? From deniz.bahadir at benocs.com Mon Jul 17 11:13:00 2017 From: deniz.bahadir at benocs.com (Deniz Bahadir) Date: Mon, 17 Jul 2017 17:13:00 +0200 Subject: [CMake] How to get list of generated object-files of OBJECT-library? In-Reply-To: <596CCDE4.6050000@gmail.com> References: <596CCDE4.6050000@gmail.com> Message-ID: <093d520b-6cb7-b0bd-c926-64cf1362d845@benocs.com> Am 17.07.2017 um 16:47 schrieb Nils Gladitz: > On 7/17/2017 3:52 PM, Deniz Bahadir wrote: >> >> This works just fine. However, now I want to add an additional >> build-step after creation of the object-files and before linking the >> shared library. (In particular, I want to compress the debug-symbols >> in the object-files. But that should be irrelevant for my question.) >> >> My first attempt was to add the following between the two add_library >> commands: >> ``` >> add_custom_command( TARGET ${PROJECT_NAME}_OBJECTS POST_BUILD >> COMMAND objcopy --compress-debug-sections >> $ >> ) >> ``` >> But that results in the following error: >> ``` >> (add_custom_command): >> Target "MyProject_OBJECTS" is an OBJECT library that may not >> have PRE_BUILD, PRE_LINK, or POST_BUILD commands. >> ``` >> >> So I tried instead to add the following between the two add_library >> commands: >> ``` >> add_custom_command( TARGET ${PROJECT_NAME} PRE_LINK >> COMMAND objcopy --compress-debug-sections >> $ >> ) >> ``` >> This then fails when evaluating the generator-expression: >> ``` >> (add_custom_command): >> Error evaluating generator expression: >> >> $ >> >> The evaluation of the TARGET_OBJECTS generator expression is only >> suitable >> for consumption by CMake. It is not suitable for writing out >> elsewhere. >> ``` >> >> So I am currently out of ideas (which do not make the CMakeLists.txt >> file completely unmaintainable). Therefore my question is: >> >> How can I retrieve the list of generated object-files so that I can >> pass it to another program that should be run as additional build-step >> before linking? >> >> IMHO, the most comfortable (and syntactically cleanest) way would be >> my first attempt. But that is probably more a feature-request than a >> simple question. > > FWIW this was implemented in the upcoming 3.9: > https://cmake.org/cmake/help/latest/module/CPackIFW.html#command:cpack_ifw_configure_component > Thank you for your answer, Nils, but I do not really see how this relates. This command seems to address CPack, while I am still struggling with CMake building files (that later might be installed by CPack). > > Nils Deniz From nilsgladitz at gmail.com Mon Jul 17 11:15:29 2017 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Mon, 17 Jul 2017 17:15:29 +0200 Subject: [CMake] How to get list of generated object-files of OBJECT-library? In-Reply-To: <093d520b-6cb7-b0bd-c926-64cf1362d845@benocs.com> References: <596CCDE4.6050000@gmail.com> <093d520b-6cb7-b0bd-c926-64cf1362d845@benocs.com> Message-ID: <75dad08d-0c12-1225-e324-3c1cfc31153b@gmail.com> On 17.07.2017 17:13, Deniz Bahadir wrote: > Am 17.07.2017 um 16:47 schrieb Nils Gladitz: >> On 7/17/2017 3:52 PM, Deniz Bahadir wrote: >>> >>> This works just fine. However, now I want to add an additional >>> build-step after creation of the object-files and before linking the >>> shared library. (In particular, I want to compress the debug-symbols >>> in the object-files. But that should be irrelevant for my question.) >>> >>> My first attempt was to add the following between the two >>> add_library commands: >>> ``` >>> add_custom_command( TARGET ${PROJECT_NAME}_OBJECTS POST_BUILD >>> COMMAND objcopy --compress-debug-sections >>> $ >>> ) >>> ``` >>> But that results in the following error: >>> ``` >>> (add_custom_command): >>> Target "MyProject_OBJECTS" is an OBJECT library that may not >>> have PRE_BUILD, PRE_LINK, or POST_BUILD commands. >>> ``` >>> >>> So I tried instead to add the following between the two add_library >>> commands: >>> ``` >>> add_custom_command( TARGET ${PROJECT_NAME} PRE_LINK >>> COMMAND objcopy --compress-debug-sections >>> $ >>> ) >>> ``` >>> This then fails when evaluating the generator-expression: >>> ``` >>> (add_custom_command): >>> Error evaluating generator expression: >>> >>> $ >>> >>> The evaluation of the TARGET_OBJECTS generator expression is only >>> suitable >>> for consumption by CMake. It is not suitable for writing out >>> elsewhere. >>> ``` >>> >>> So I am currently out of ideas (which do not make the CMakeLists.txt >>> file completely unmaintainable). Therefore my question is: >>> >>> How can I retrieve the list of generated object-files so that I can >>> pass it to another program that should be run as additional >>> build-step before linking? >>> >>> IMHO, the most comfortable (and syntactically cleanest) way would be >>> my first attempt. But that is probably more a feature-request than a >>> simple question. >> >> FWIW this was implemented in the upcoming 3.9: >> https://cmake.org/cmake/help/latest/module/CPackIFW.html#command:cpack_ifw_configure_component >> > > Thank you for your answer, Nils, but I do not really see how this > relates. > This command seems to address CPack, while I am still struggling with > CMake building files (that later might be installed by CPack). So sorry about that. Must have gotten the wrong link in my clipboard. The correct link is: https://cmake.org/cmake/help/latest/release/3.9.html#other Nils From rcdailey.lists at gmail.com Mon Jul 17 11:31:11 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Mon, 17 Jul 2017 10:31:11 -0500 Subject: [CMake] Transitive behavior of target_link_libraries between shared/static Message-ID: Suppose I have the following: ``` add_library( A STATIC ${files} ) add_library( B SHARED ${more_files} ) target_link_libraries( B PUBLIC A ) add_library( C STATIC ${even_more_files} ) target_link_libraries( C PUBLIC B ) add_executable( D ${exe_files} ) target_link_libraries( D PRIVATE C ) ``` Does the linker command for target `D` ever see target A's static link library? I'm hoping the only thing the linker gets is `libB.so` and `libC.a`, without `libA.a`. It seems like A to everyone outside of B should just be a set of public include directories and compile definitions, since the link file aspect of it should be hidden across shared library boundaries. Hoping someone can explain how this works. I want to make sure static libs sitting behind shared libs in the dependency tree do not get exposed. From chuck.atkins at kitware.com Mon Jul 17 11:38:05 2017 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Mon, 17 Jul 2017 11:38:05 -0400 Subject: [CMake] OBJECT libraries and working around lake of target_link_libraries In-Reply-To: References: Message-ID: Hi David, > Supporting OBJECT libraries in > target_link_libraries calls was mentioned mentioned right back here > https://cmake.org/pipermail/cmake-developers/2012-March/015422.html but > sadly seems still to be on the back burner. > It's not on the back burner! There has been progress on desiging the rest of the implementation to make OBJECT libraries "first class citizens" and I can't give you actual dates I do believe you can probably expect it some time this year. > > Not being > able to use target_link_libraries with thier transitive nature made this > very painful, many days of work. I actually just recently went through the exercise of creating a workaround for this in one of my projects so I can certainly understand the gaping hole that is currently present. The workaround I ended up with was to create three seperate libraries: one for the objects, one for the usage requirements, and then a third that combines them. add_library(foo_objects OBJECT foo_src1.cxx foo_src2.cxx ...) add_library(foo_interface INTERFACE) target_link_libraries(foo_interface INTERFACE FooDepend1 FooDepend2 ...) target_include_directories(foo_interface INTERFACE $ $) add_library(foo INTERFACE) target_sources(foo INTERFACE $) target_link_libraries(foo INTERFACE foo_interface) The interface sources property on "foo" will populate the object files into whatever uses "foo" in its target_link_libraries and then the usage requirements in foo_interface will populate transitively. The only problem with this approach, and the reason for creating three separate libraries instead of just adding the objects to the sources on foo_interface, is that INTERFACE_SOURCES will continue to get propagated transitively potentially causing duplicate symbols upstream, so it's really only appropriate for private linking so you want to link publically then add the objects manually and pass the interface publically. This essentially means you need to use it like this: // Use foo privately, so just put "foo" in TLL and it just works add_library(bar1 bar1_src1.cxx bar1_src2.cxx) target_link_libraries(bar1 PRIVATE foo) // Use foo publicly so we need to separately grab the objects and // their usage requirements. add_library(bar2 bar2_src1.cxx bar2_src2.cxx $) target_link_libraries(bar2 PUBLIC foo_interface) This is effectively what the current plan is for the upstream implementation, just all rolled into one; i.e. the objects get added to whatever is explicitly linking with target_link_libraries, but all transitive linkage only uses the interface usage requirements. Plans, of course, may change but that's what it's looking like right now, we just need to find the time and funding to implement it. - Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From zahid.iqbal at gmail.com Mon Jul 17 12:42:06 2017 From: zahid.iqbal at gmail.com (Zahid Iqbal) Date: Mon, 17 Jul 2017 17:42:06 +0100 Subject: [CMake] problem linking a library and addressing cross dependency Message-ID: Hi, I have started using *cmake* recently. I have the following question: For building my system, I am working with two directories. Let's call them *my_application_directory* and *protocol_source_directory. * The code relating to my application resides under *my_application_directory*. In fact, my application needs to interact with *protocol_source_directory*. My application needs some functions from *protocol_source_directory *as well as it can provide some functionality to some process that is within the *protocol_source_directory. * *protocol_source_directory *is an existing protocol suite with its own top-level *makefile *that compiles and builds the protocol and generates a static library. The directory structure for *protocol_source_directory *is as follows: *protocol_source_directory* *|* *|*___ *dir1* * |* * |__ config* * |__ include* * |__ libs* * |__ misc* * |__ src* * |* * |__ modules* *|** |* *|** |__ layerA* *|** |__ layerB* *|** |__ layerC* *|** |__ layerD* * |* * |* * |__ debug_tests* *|* * |__ **my_application_directory* Imagine a scenario in which there was no *my_application_directory. *In this case, *protocol_source_directory *builds and compiles with the *makefile* under *protocol_source_directory/**dir1. *The static library generated (e.g. protocol_lib.a) is available under *protocol_source_directory/dir1/libs/. * Purpose of developing an application is to add some functionality in the protocol and then develop an application to test that functionality. To fulfill this purpose, new files are added, - Few of new files are added at the location *protocol_source_directory/dir1/src/modules/layerC/. *There is a *local makefile* at this level which is updated to reflect these new files. - some of the files need some definitions from *my_application_directory. *Therefore, I update the *local makefile* to include the needed paths to *my_application_directory. *so that I can use necessary headers inside ".c" files without path qualifiers. *Having done this, * *protocol_source_directory *builds and compiles with the *makefile* under *protocol_source_directory/**dir1 *and generates the static library e.g. protocol_lib.a. - Remaining functionality is implemented in files that reside under *my_application_directory. *It is important to note that *my_application_directory *can be at location *protocol_source_directory/dir1/src/debug_tests/my_application_directory/ *or it can exists separately at the same level as the *protocol_source_directory* Imagine a scenario where, my *my_application_directory *is separate (not inside) the *protocol_source_directory. *Here is the* CMakeLists.txt *that I am using to build my* application *while interacting with* protocol source. * project(PS_TEST) cmake_minimum_required(VERSION 2.8) # manually adding the sources using the set command as follows: set(SRC_LIST main.c ISH.c ish_db.c ish_generator.c messages.c my_string_help.c populate_ish.c ISH.h ish_db.h ish_generator.h messages.h my_string_help.h populate_ish.h my_types.h) add_executable(${PROJECT_NAME} ${SRC_LIST}) # adding c99 style options set_property(TARGET ${PROJECT_NAME} PROPERTY C_STANDARD 99) set(FTT_BASE *protocol_source_directory*/*dir1*) set(CORE_INCLUDES ${FTT_BASE}/src/modules/layerC/include/) set(ETH_INCLUDES ${FTT_BASE}/src/modules/layerA/include/) set(CORE_COMMONS ${FTT_BASE}/src/modules/layerC/common/) set(MASTER_INCLUDES ${FTT_BASE}/src/modules/layerC/master/) include_directories(include ${FTT_BASE}/config/ ${FTT_BASE}/misc/make-rules/ ${FTT_BASE}/misc/arch-ports/ ${CORE_INCLUDES} ${ETH_INCLUDES} ${CORE_COMMONS} ${MASTER_INCLUDES}) add_definitions(${FTT_COMPILE_OPT}$) # linking to the protocl library code find_library (FTT_LIB protocol_lib.a *protocol_source_directory*/*dir1**/libs/*) target_link_libraries(${PROJECT_NAME} ${FTT_LIB}) Having done all this, when I build my application using cmake, it gives me the following error: my_types.h no such file and directory please note that* my_types.h* is in *my_application_directory. *But, since, some definitions are needed, I have included this file (i.e., include "my_types.h") in some .c files which are at *protocol_source_directory/dir1/src/modules/layerC/.* *Question: *What I am doing wrong here, I have included the needed paths* to **my_application_directory, *in the* local makefile *at *protocol_source_directory/dir1/src/modules/layerC/. **protocol_source_directory *is compiling ok*, *why I receive this error after I link with static project libray. thanks for your help and time. Regards, zahid -------------- next part -------------- An HTML attachment was scrubbed... URL: From deniz.bahadir at benocs.com Mon Jul 17 12:41:45 2017 From: deniz.bahadir at benocs.com (Deniz Bahadir) Date: Mon, 17 Jul 2017 18:41:45 +0200 Subject: [CMake] How to get list of generated object-files of OBJECT-library? In-Reply-To: <75dad08d-0c12-1225-e324-3c1cfc31153b@gmail.com> References: <596CCDE4.6050000@gmail.com> <093d520b-6cb7-b0bd-c926-64cf1362d845@benocs.com> <75dad08d-0c12-1225-e324-3c1cfc31153b@gmail.com> Message-ID: <3bc1235a-75db-ef14-a2fd-179400677c69@benocs.com> Am 17.07.2017 um 17:15 schrieb Nils Gladitz: > On 17.07.2017 17:13, Deniz Bahadir wrote: >> Am 17.07.2017 um 16:47 schrieb Nils Gladitz: >>> On 7/17/2017 3:52 PM, Deniz Bahadir wrote: >>>> >>>> This works just fine. However, now I want to add an additional >>>> build-step after creation of the object-files and before linking the >>>> shared library. (In particular, I want to compress the debug-symbols >>>> in the object-files. But that should be irrelevant for my question.) >>>> >>>> My first attempt was to add the following between the two >>>> add_library commands: >>>> ``` >>>> add_custom_command( TARGET ${PROJECT_NAME}_OBJECTS POST_BUILD >>>> COMMAND objcopy --compress-debug-sections >>>> $ >>>> ) >>>> ``` >>>> But that results in the following error: >>>> ``` >>>> (add_custom_command): >>>> Target "MyProject_OBJECTS" is an OBJECT library that may not >>>> have PRE_BUILD, PRE_LINK, or POST_BUILD commands. >>>> ``` >>>> >>>> So I tried instead to add the following between the two add_library >>>> commands: >>>> ``` >>>> add_custom_command( TARGET ${PROJECT_NAME} PRE_LINK >>>> COMMAND objcopy --compress-debug-sections >>>> $ >>>> ) >>>> ``` >>>> This then fails when evaluating the generator-expression: >>>> ``` >>>> (add_custom_command): >>>> Error evaluating generator expression: >>>> >>>> $ >>>> >>>> The evaluation of the TARGET_OBJECTS generator expression is only >>>> suitable >>>> for consumption by CMake. It is not suitable for writing out >>>> elsewhere. >>>> ``` >>>> >>>> So I am currently out of ideas (which do not make the CMakeLists.txt >>>> file completely unmaintainable). Therefore my question is: >>>> >>>> How can I retrieve the list of generated object-files so that I can >>>> pass it to another program that should be run as additional >>>> build-step before linking? >>>> >>>> IMHO, the most comfortable (and syntactically cleanest) way would be >>>> my first attempt. But that is probably more a feature-request than a >>>> simple question. >>> >>> FWIW this was implemented in the upcoming 3.9: >>> https://cmake.org/cmake/help/latest/module/CPackIFW.html#command:cpack_ifw_configure_component >>> >> >> Thank you for your answer, Nils, but I do not really see how this >> relates. >> This command seems to address CPack, while I am still struggling with >> CMake building files (that later might be installed by CPack). > > So sorry about that. > Must have gotten the wrong link in my clipboard. > > The correct link is: > https://cmake.org/cmake/help/latest/release/3.9.html#other Thanks a lot. That makes more sense now. So I will wait for CMake 3.9 to automagically fix my problem. :-) > > Nils Thanks again, Deniz From robert.maynard at kitware.com Mon Jul 17 16:26:52 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Mon, 17 Jul 2017 16:26:52 -0400 Subject: [CMake] Built-in way to detect if a root script is standalone or not? In-Reply-To: References: Message-ID: That is about the easiest way to check if you are standalone. On Mon, Jul 17, 2017 at 10:58 AM, Robert Dailey wrote: > I have logic similar to this in some of my middleware libraries' root > CMakeLists.txt: > > if( CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR ) > set( STANDALONE TRUE ) > endif() > > Is there a built-in way to detect 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 alfred at huji.fr Mon Jul 17 16:54:06 2017 From: alfred at huji.fr (Alfred Sawaya) Date: Mon, 17 Jul 2017 20:54:06 +0000 Subject: [CMake] ExternalProject + PREFIX + CPACK - cannot get the good path Message-ID: Hello folks, I am trying to create a package with CPack from an External Project using the autotools. The make install part try to copy files to /usr/local/lib, but I do not want to package as root, so it fails. The cpack works because (I think) it create a temp dir and set it as environment variable before issuing the make install. But if I do a "make package", then it fails with permissions denied. I am not the first to get stuck with this issue ( https://stackoverflow.com/questions/44724281/cpack-building-external-autogen-project-with-bad-output-location ) So I do not think that there is a direct solution ? Anyway, I can implement one and send the patch. I see only one solution to this issue: actually set a prefix on the external project and implement a boolean variable CPACK_IGNORE_INSTALL_PREFIX to remove it into the package. I tihnk it is the most consistent way to resolve this ? Do you have other ideas before I start implementing it ? Thank you all, Alfred The CMakeLists.txt: (usable as is) << From mailinglists at xgm.de Mon Jul 17 22:56:23 2017 From: mailinglists at xgm.de (Florian Lindner) Date: Tue, 18 Jul 2017 10:56:23 +0800 Subject: [CMake] Append to property COMPILE_DEFINITIONS Message-ID: <54d1cf26-73f3-3fb1-9b17-ce459b7b6cb3@xgm.de> Hello, I want to add compile definitions. Since I want to use generator expressions, I can't use add_definitions, but have to use the COMPILE_DEFINITIONS property, but neither: set_property(GLOBAL APPEND PROPERTY COMPILE_DEFINITIONS "-DFOO") for testing or set_property(GLOBAL APPEND PROPERTY COMPILE_DEFINITIONS $<$:-DDebug>) which should be final result, produces any -DFOO compiler switches. I also tried placing it before and after the add_executable call. What is wrong with that call? Thanks, Florian From craig.scott at crascit.com Mon Jul 17 22:59:34 2017 From: craig.scott at crascit.com (Craig Scott) Date: Tue, 18 Jul 2017 12:59:34 +1000 Subject: [CMake] Append to property COMPILE_DEFINITIONS In-Reply-To: <54d1cf26-73f3-3fb1-9b17-ce459b7b6cb3@xgm.de> References: <54d1cf26-73f3-3fb1-9b17-ce459b7b6cb3@xgm.de> Message-ID: You appear to be setting a GLOBAL property where you probably meant DIRECTORY. You could also consider setting the target property instead rather than applying it to all targets (unless that's what you want). On Tue, Jul 18, 2017 at 12:56 PM, Florian Lindner wrote: > Hello, > > I want to add compile definitions. Since I want to use generator > expressions, I can't use add_definitions, but have to > use the COMPILE_DEFINITIONS property, but neither: > > set_property(GLOBAL APPEND > PROPERTY COMPILE_DEFINITIONS "-DFOO") > > for testing > > or > > set_property(GLOBAL APPEND > PROPERTY COMPILE_DEFINITIONS $<$:-DDebug>) > > which should be final result, produces any -DFOO compiler switches. > > I also tried placing it before and after the add_executable call. > > What is wrong with that call? > > Thanks, > Florian > -- > > 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 mailinglists at xgm.de Mon Jul 17 23:21:08 2017 From: mailinglists at xgm.de (Florian Lindner) Date: Tue, 18 Jul 2017 11:21:08 +0800 Subject: [CMake] Append to property COMPILE_DEFINITIONS In-Reply-To: References: <54d1cf26-73f3-3fb1-9b17-ce459b7b6cb3@xgm.de> Message-ID: <5fb55910-c604-f279-4e07-9974724b72ce@xgm.de> Am 18.07.2017 um 10:59 schrieb Craig Scott: > You appear to be setting a GLOBAL property where you probably meant DIRECTORY. You could also consider setting the > target property instead rather than applying it to all targets (unless that's what you want). I tried to set the property on all targets, therefore I thought GLOBAL is the right thing. However, set_property(DIRECTORY "${CMAKE_SOURCE_DIR}/src" APPEND PROPERTY COMPILE_DEFINITIONS "-DFOO") hasn't had any effect either. set_property(TARGET testprecice APPEND PROPERTY COMPILE_DEFINITIONS "FOO") works. But setting it on all targets is exactly what I want. How can I do that? Best, Florian > > > On Tue, Jul 18, 2017 at 12:56 PM, Florian Lindner > wrote: > > Hello, > > I want to add compile definitions. Since I want to use generator expressions, I can't use add_definitions, but have to > use the COMPILE_DEFINITIONS property, but neither: > > set_property(GLOBAL APPEND > PROPERTY COMPILE_DEFINITIONS "-DFOO") > > for testing > > or > > set_property(GLOBAL APPEND > PROPERTY COMPILE_DEFINITIONS $<$:-DDebug>) > > which should be final result, produces any -DFOO compiler switches. > > I also tried placing it before and after the add_executable call. > > What is wrong with that call? > > Thanks, > Florian > -- > > 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 From eric.noulard at gmail.com Tue Jul 18 03:31:56 2017 From: eric.noulard at gmail.com (Eric Noulard) Date: Tue, 18 Jul 2017 09:31:56 +0200 Subject: [CMake] ExternalProject + PREFIX + CPACK - cannot get the good path In-Reply-To: References: Message-ID: 2017-07-17 22:54 GMT+02:00 Alfred Sawaya : > Hello folks, > > I am trying to create a package with CPack from an External Project using > the autotools. The make install part try to copy files to /usr/local/lib, > but I do not want to package as root, so it fails. The cpack works because > (I think) it create a temp dir and set it as environment variable before > issuing the make install. > Yes it does, in fact some CPack generator automatically set the DESTDIR var in order to tolerate files installed with absolute path. This is the case (at least) of RPM and DEB generator. In fact in your case if you try e.g. ZIP generator with cpack -G ZIP it will fail as with "make package". > But if I do a "make package", then it fails with permissions denied. > Yep. Because the pre-install target required by cpack does not use DESTDIR mechanism and thus uses the default prefix from /configure which is probably /usr/local Note that the very simple "make" which tries to BUILD and INSTALL the external project fails as well because it wants to install is /usr/local. e.g. note that with your current setup if you do: DESTDIR=/tmp make package you get what you want in the DEB file. > > I am not the first to get stuck with this issue ( > https://stackoverflow.com/questions/44724281/cpack- > building-external-autogen-project-with-bad-output-location) > So I do not think that there is a direct solution ? Anyway, I can > implement one and send the patch. > > I see only one solution to this issue: actually set a prefix on the > external project and implement a boolean variable > CPACK_IGNORE_INSTALL_PREFIX to remove it into the package. I tihnk it is > the most consistent way to resolve this ? > I would say you should find a way to have 2 differents prefixes. The first should be used when doing "make" The second one used when cpack runs. All that said, may be you can "simply" craft an install_command script you can call in the INSTALL_COMMAND argument of ExternalProject_Add and which verifies if DESTDIR is already set or not in order to call "make install" or "DESTDIR=/choose/your/path make install". However this is kind of workaround to throw away the first install step done when doing make while keeping the second one done by cpack... Which makes me think, if you primary goal is to package an external project, wouldn't it be simpler to add support for a "PACKAGE" step to ExternalProject ? Or is this external project meant to be packaged in the same package as the project using it? -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From alfred at huji.fr Tue Jul 18 05:03:02 2017 From: alfred at huji.fr (Alfred Sawaya) Date: Tue, 18 Jul 2017 09:03:02 +0000 Subject: [CMake] ExternalProject + PREFIX + CPACK - cannot get the good path In-Reply-To: References: Message-ID: Bonjour Eric, Thank you for you answer. > e.g. note that with your current setup if you do: > DESTDIR=/tmp make package > > you get what you want in the DEB file. > Yes, it works. > >> I see only one solution to this issue: actually set a prefix on the >> external project and implement a boolean variable >> CPACK_IGNORE_INSTALL_PREFIX to remove it into the package. I tihnk it is >> the most consistent way to resolve this ? >> > > I would say you should find a way to have 2 differents prefixes. > > The first should be used when doing "make" > The second one used when cpack runs. > An option like "CMAKE_ONLY_PREFIX" in the ExternalProject ? A third solution could be: An option like "CPACK_OVERRIDE_DEST_DIR" could detect if 'DESTDIR=' is issued in the INSTALL_COMMAND of the external project. If the option is true, it overrides it with the CPACK_INSTALL_PREFIX. > All that said, may be you can "simply" craft an install_command script you > can call in the > INSTALL_COMMAND argument of ExternalProject_Add and which verifies if > DESTDIR is already set or not > in order to call "make install" or "DESTDIR=/choose/your/path make > install". > > However this is kind of workaround to throw away the first install step > done when doing make while keeping the second one done by cpack... > Actually it would work for me as I do not use the first make install. It is the same as DESTDIR=/tmp make package, but integrated into the CMakeLists. > Which makes me think, if you primary goal is to package an external > project, wouldn't it be simpler to add support for a "PACKAGE" step to > ExternalProject ? Or is this external project meant to be packaged in the > same package as the project using it? > I cannot add a package step as the external project do not support packaging, it is only a configure / make / make install project. That is why I use CPack. But I package it as a separate package. Anyway, the DESTDIR=/tmp make package does the trick for me but I still can implement an integrated solution if it is useful for others ? > > -- > Eric > > -- Cordialement, Alfred Sawaya -------------- next part -------------- An HTML attachment was scrubbed... URL: From zahid.iqbal at gmail.com Tue Jul 18 05:15:01 2017 From: zahid.iqbal at gmail.com (Zahid Iqbal) Date: Tue, 18 Jul 2017 10:15:01 +0100 Subject: [CMake] how to specify static library dependency on current project in CMakeLists.txt Message-ID: Hi List, Previously, I posted a question, I will rephrase it here. I am building a simple project "my_application". I have all source (.c, and .h files) under "my_application". My CMakeLists.txt file is under "my_application". In this project, I need to link to a static library called "example_library.a". The way, I generate "example_library.a" is as follows. "example_library.a" needs some definition from "my_application". In the makefile which is used to generate "example_library.a" , I add the needed paths to "my_application". It compiles fine and result is "example_library.a". After linking to "example_library.a" in CMakeLists.txt, when I run cmake, it reports an error from linked static library. ~/IMPLEMENTATIONS/PollingServer/ftt-se/src/modules/ftt-core.layer/master/M_Server.h:5: error: my_types.h: No such file or directory #include "my_types.h" ^ Please note that "my_types.h" is found under "my_application". thanks, Zahid -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Tue Jul 18 06:08:25 2017 From: craig.scott at crascit.com (Craig Scott) Date: Tue, 18 Jul 2017 20:08:25 +1000 Subject: [CMake] Append to property COMPILE_DEFINITIONS In-Reply-To: <5fb55910-c604-f279-4e07-9974724b72ce@xgm.de> References: <54d1cf26-73f3-3fb1-9b17-ce459b7b6cb3@xgm.de> <5fb55910-c604-f279-4e07-9974724b72ce@xgm.de> Message-ID: It might be easier if you showed the whole CMakeLists.txt file so we can see the full picture. Is it available somewhere you can link to, or even better if it's small enough, just post it inline here. On Tue, Jul 18, 2017 at 1:21 PM, Florian Lindner wrote: > Am 18.07.2017 um 10:59 schrieb Craig Scott: > > You appear to be setting a GLOBAL property where you probably meant > DIRECTORY. You could also consider setting the > > target property instead rather than applying it to all targets (unless > that's what you want). > > I tried to set the property on all targets, therefore I thought GLOBAL is > the right thing. > > However, > > set_property(DIRECTORY "${CMAKE_SOURCE_DIR}/src" APPEND > PROPERTY COMPILE_DEFINITIONS "-DFOO") > > hasn't had any effect either. > > set_property(TARGET testprecice APPEND > PROPERTY COMPILE_DEFINITIONS "FOO") > > works. But setting it on all targets is exactly what I want. How can I do > that? > > Best, > Florian > > > > > > > On Tue, Jul 18, 2017 at 12:56 PM, Florian Lindner > wrote: > > > > Hello, > > > > I want to add compile definitions. Since I want to use generator > expressions, I can't use add_definitions, but have to > > use the COMPILE_DEFINITIONS property, but neither: > > > > set_property(GLOBAL APPEND > > PROPERTY COMPILE_DEFINITIONS "-DFOO") > > > > for testing > > > > or > > > > set_property(GLOBAL APPEND > > PROPERTY COMPILE_DEFINITIONS $<$:-DDebug>) > > > > which should be final result, produces any -DFOO compiler switches. > > > > I also tried placing it before and after the add_executable call. > > > > What is wrong with that call? > > > > Thanks, > > Florian > > -- > > > > 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 < > http://cmake.org/cmake/help/support.html> > > CMake Consulting: http://cmake.org/cmake/help/consulting.html < > http://cmake.org/cmake/help/consulting.html> > > CMake Training Courses: http://cmake.org/cmake/help/training.html < > 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 < > 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 Jul 18 06:14:25 2017 From: craig.scott at crascit.com (Craig Scott) Date: Tue, 18 Jul 2017 20:14:25 +1000 Subject: [CMake] Append to property COMPILE_DEFINITIONS In-Reply-To: <5fb55910-c604-f279-4e07-9974724b72ce@xgm.de> References: <54d1cf26-73f3-3fb1-9b17-ce459b7b6cb3@xgm.de> <5fb55910-c604-f279-4e07-9974724b72ce@xgm.de> Message-ID: On Tue, Jul 18, 2017 at 1:21 PM, Florian Lindner wrote: > Am 18.07.2017 um 10:59 schrieb Craig Scott: > > You appear to be setting a GLOBAL property where you probably meant > DIRECTORY. You could also consider setting the > > target property instead rather than applying it to all targets (unless > that's what you want). > > I tried to set the property on all targets, therefore I thought GLOBAL is > the right thing. > > However, > > set_property(DIRECTORY "${CMAKE_SOURCE_DIR}/src" APPEND > PROPERTY COMPILE_DEFINITIONS "-DFOO") > > hasn't had any effect either. > BTW, you don't include the -D when adding to COMPILE_DEFINITIONS, just put FOO, not -DFOO. Have a read of the docs , they may give you other clues for this property (e.g. using the ..._CONFIG variant of it). -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailinglists at xgm.de Tue Jul 18 06:50:28 2017 From: mailinglists at xgm.de (Florian Lindner) Date: Tue, 18 Jul 2017 18:50:28 +0800 Subject: [CMake] Append to property COMPILE_DEFINITIONS In-Reply-To: References: <54d1cf26-73f3-3fb1-9b17-ce459b7b6cb3@xgm.de> <5fb55910-c604-f279-4e07-9974724b72ce@xgm.de> Message-ID: <62824131-1bbb-72f0-b7d3-454223ad2f4c@xgm.de> Am 18.07.2017 um 18:08 schrieb Craig Scott: > It might be easier if you showed the whole CMakeLists.txt file so we can see the full picture. Is it available somewhere > you can link to, or even better if it's small enough, just post it inline here. Sure! It's not too long, so I'll paste it here cmake_minimum_required (VERSION 3.1) project(preCICE) set(CMAKE_MODULE_PATH ${PROJECT_SOURCE_DIR/CMake}) set(CMAKE_CXX_STANDARD 11) set(CMAKE_CXX_STANDARD_REQUIRED ON) set(CMAKE_CXX_EXTENSIONS OFF) if("${CMAKE_CXX_COMPILER_ID}" STREQUAL "GNU" OR "${CMAKE_CXX_COMPILER_ID}" STREQUAL "Clang") set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall") endif() # set_property(GLOBAL APPEND # PROPERTY COMPILE_DEFINITIONS $<$:-DDebug>) option(PETSC "Enable use of the PETSc linear algebra library." ON) if (PETSC) find_library(petsc petsc PATHS $ENV{PETSC_DIR}/$ENV{PETSC_ARCH}/lib) if(NOT petsc) message(FATAL_ERROR "PETSc was not found") else() message(STATUS "Using PETSc: $ENV{PETSC_ARCH}") endif() endif() find_package (Threads REQUIRED) find_package(Boost 1.60.0 REQUIRED COMPONENTS log log_setup program_options system thread unit_test_framework) add_definitions(-DBOOST_SPIRIT_USE_PHOENIX_V3 -DBOOST_ALL_DYN_LINK) option(MPI "Enables MPI-based communication and running coupling tests." ON) if (MPI) find_package(MPI REQUIRED) include_directories(${MPI_INCLUDE_PATH}) set(COMPILE_FLAGS ${COMPILE_FLAGS} ${MPI_COMPILE_FLAGS}) set(LINK_FLAGS ${LINK_FLAGS} ${MPI_LINK_FLAGS}) endif() find_package(Eigen3 REQUIRED) include_directories(${EIGEN3_INCLUDE_DIR}) option(PYTHON "Python support" ON) if (PYTHON) set(Python_ADDITIONAL_VERSIONS "2.7") find_package(PythonLibs 2.7 REQUIRED) include_directories(${PYTHON_INCLUDE_DIRS}) add_definitions(-DNPY_NO_DEPRECATED_API=NPY_1_7_API_VERSION) else() add_definitions(-DPRECICE_NO_PYTHON) endif() # Fills the sources* variables add_subdirectory("src") # Much target_link_libraries boilerplate add_library(solib ${sourcesAllNoMain}) set_target_properties(solib PROPERTIES OUTPUT_NAME libprecice) target_link_libraries(solib ${PYTHON_LIBRARIES}) target_link_libraries(solib ${MPI_LIBRARIES}) target_link_libraries(solib ${Boost_LIBRARIES}) target_link_libraries(solib ${petsc}) add_library(staticlib ${sourcesAllNoMain}) set_target_properties(staticlib PROPERTIES OUTPUT_NAME libprecice) target_link_libraries(staticlib ${PYTHON_LIBRARIES}) target_link_libraries(staticlib ${MPI_LIBRARIES}) target_link_libraries(staticlib ${Boost_LIBRARIES}) target_link_libraries(staticlib ${petsc}) add_executable(precice "src/drivers/main.cpp" ${sourcesAllNoMain} ${sourcesTarchTests}) target_link_libraries(precice Threads::Threads) target_link_libraries(precice ${PYTHON_LIBRARIES}) target_link_libraries(precice ${MPI_LIBRARIES}) target_link_libraries(precice ${Boost_LIBRARIES}) target_link_libraries(precice ${petsc}) add_executable(testprecice "src/testing/main.cpp" ${sourcesAllNoMain} ${sourcesTests}) target_link_libraries(testprecice Threads::Threads) target_link_libraries(testprecice ${PYTHON_LIBRARIES}) target_link_libraries(testprecice ${MPI_LIBRARIES}) target_link_libraries(testprecice ${Boost_LIBRARIES}) target_link_libraries(testprecice ${petsc}) #Works, but I would prefer to have it just once for all targets and at the top of the file set_property(TARGET testprecice APPEND PROPERTY COMPILE_DEFINITIONS "FOO") > BTW, you don't include the -D when adding to COMPILE_DEFINITIONS, just put FOO, not -DFOO. Have a read of the docs, they may give you other clues for this property (e.g. using the ..._CONFIG variant of it). Yeah, I found out that I don't have to add -D. The docs say that generator expressions are preferable to using _CONFIG variant. Best, Florian > > > On Tue, Jul 18, 2017 at 1:21 PM, Florian Lindner > wrote: > > Am 18.07.2017 um 10:59 schrieb Craig Scott: > > You appear to be setting a GLOBAL property where you probably meant DIRECTORY. You could also consider setting the > > target property instead rather than applying it to all targets (unless that's what you want). > > I tried to set the property on all targets, therefore I thought GLOBAL is the right thing. > > However, > > set_property(DIRECTORY "${CMAKE_SOURCE_DIR}/src" APPEND > PROPERTY COMPILE_DEFINITIONS "-DFOO") > > hasn't had any effect either. > > set_property(TARGET testprecice APPEND > PROPERTY COMPILE_DEFINITIONS "FOO") > > works. But setting it on all targets is exactly what I want. How can I do that? > > Best, > Florian > > > > > > > On Tue, Jul 18, 2017 at 12:56 PM, Florian Lindner > >> wrote: > > > > Hello, > > > > I want to add compile definitions. Since I want to use generator expressions, I can't use add_definitions, but > have to > > use the COMPILE_DEFINITIONS property, but neither: > > > > set_property(GLOBAL APPEND > > PROPERTY COMPILE_DEFINITIONS "-DFOO") > > > > for testing > > > > or > > > > set_property(GLOBAL APPEND > > PROPERTY COMPILE_DEFINITIONS $<$:-DDebug>) > > > > which should be final result, produces any -DFOO compiler switches. > > > > I also tried placing it before and after the add_executable call. > > > > What is wrong with that call? > > > > Thanks, > > Florian > > -- > > > > 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 From dbahadir at benocs.com Tue Jul 18 07:46:47 2017 From: dbahadir at benocs.com (Deniz Bahadir) Date: Tue, 18 Jul 2017 13:46:47 +0200 Subject: [CMake] How to get list of generated object-files of OBJECT-library? In-Reply-To: <3bc1235a-75db-ef14-a2fd-179400677c69@benocs.com> References: <596CCDE4.6050000@gmail.com> <093d520b-6cb7-b0bd-c926-64cf1362d845@benocs.com> <75dad08d-0c12-1225-e324-3c1cfc31153b@gmail.com> <3bc1235a-75db-ef14-a2fd-179400677c69@benocs.com> Message-ID: <37ce2524-6e99-edb8-5ac3-a8fcd8ad8e3a@benocs.com> Am 17.07.2017 um 18:41 schrieb Deniz Bahadir: > Am 17.07.2017 um 17:15 schrieb Nils Gladitz: >> On 17.07.2017 17:13, Deniz Bahadir wrote: >>> Am 17.07.2017 um 16:47 schrieb Nils Gladitz: >>>> On 7/17/2017 3:52 PM, Deniz Bahadir wrote: >>>>> >>>>> This works just fine. However, now I want to add an additional >>>>> build-step after creation of the object-files and before linking >>>>> the shared library. (In particular, I want to compress the >>>>> debug-symbols in the object-files. But that should be irrelevant >>>>> for my question.) >>>>> >>>>> My first attempt was to add the following between the two >>>>> add_library commands: >>>>> ``` >>>>> add_custom_command( TARGET ${PROJECT_NAME}_OBJECTS POST_BUILD >>>>> COMMAND objcopy --compress-debug-sections >>>>> $ >>>>> ) >>>>> ``` >>>>> But that results in the following error: >>>>> ``` >>>>> (add_custom_command): >>>>> Target "MyProject_OBJECTS" is an OBJECT library that may not >>>>> have PRE_BUILD, PRE_LINK, or POST_BUILD commands. >>>>> ``` >>>>> >>>>> So I tried instead to add the following between the two add_library >>>>> commands: >>>>> ``` >>>>> add_custom_command( TARGET ${PROJECT_NAME} PRE_LINK >>>>> COMMAND objcopy --compress-debug-sections >>>>> $ >>>>> ) >>>>> ``` >>>>> This then fails when evaluating the generator-expression: >>>>> ``` >>>>> (add_custom_command): >>>>> Error evaluating generator expression: >>>>> >>>>> $ >>>>> >>>>> The evaluation of the TARGET_OBJECTS generator expression is only >>>>> suitable >>>>> for consumption by CMake. It is not suitable for writing out >>>>> elsewhere. >>>>> ``` >>>>> >>>>> So I am currently out of ideas (which do not make the >>>>> CMakeLists.txt file completely unmaintainable). Therefore my >>>>> question is: >>>>> >>>>> How can I retrieve the list of generated object-files so that I can >>>>> pass it to another program that should be run as additional >>>>> build-step before linking? >>>>> >>>>> IMHO, the most comfortable (and syntactically cleanest) way would >>>>> be my first attempt. But that is probably more a feature-request >>>>> than a simple question. >>>> >>>> FWIW this was implemented in the upcoming 3.9: >>>> https://cmake.org/cmake/help/latest/module/CPackIFW.html#command:cpack_ifw_configure_component >>>> >>> >>> Thank you for your answer, Nils, but I do not really see how this >>> relates. >>> This command seems to address CPack, while I am still struggling with >>> CMake building files (that later might be installed by CPack). >> >> So sorry about that. >> Must have gotten the wrong link in my clipboard. >> >> The correct link is: >> https://cmake.org/cmake/help/latest/release/3.9.html#other > > Thanks a lot. That makes more sense now. > So I will wait for CMake 3.9 to automagically fix my problem. :-) > I just realized that CMake 3.9 does actually support my second attempt (with some modifications), not my first attempt. The first one still fails with the same reason: An OBJECT-library does not support add_custom_command with POST_BUILD. The working solution is to use the following command (which is a slightly modification of my second attempt from above): ``` add_custom_command( TARGET ${PROJECT_NAME} PRE_LINK COMMAND bash -c "for i in $(echo '$' | tr '[;]' ' '); do objcopy --compress-debug-sections $i; done" VERBATIM ) ``` (Note, that I had to somehow get rid of the semicolon which was used as delimiter in the list of target-objects because in bash a semicolon is seen as a command-delimiter.) However, although that worked, it led to another problem: objcopy is modifying the object-files so that at least ninja thinks they need to be rebuild the next time it is run. (Probably due to the fact, that the hashes changed. make might be fine because it just looks at the modification-date.) If I would have been able to use my first attempt, that means associating the object-files manipulation with the OBJECT-library directly, that might not have been a problem, because the hash of the object-files would not change and only be taken into consideration after the OBJECT-library would have been created. Is that observation correct!? Are there any plans to support OBJECT-libraries with add_custom_command and PRE_BUILD/POST_BUILD commands? Or does anyone have another idea how to prevent ninja from rebuilding all object-files after they were modified? Thanks in advance, Deniz PS: Just letting objcopy modify copies of the object-files is no valid workaround as it defeats its purpose in the fist place, which is to reduce the space needed for the build-products on the harddrive. From eric.noulard at gmail.com Tue Jul 18 10:23:00 2017 From: eric.noulard at gmail.com (Eric Noulard) Date: Tue, 18 Jul 2017 16:23:00 +0200 Subject: [CMake] ExternalProject + PREFIX + CPACK - cannot get the good path In-Reply-To: References: Message-ID: > > >> Which makes me think, if you primary goal is to package an external >> project, wouldn't it be simpler to add support for a "PACKAGE" step to >> ExternalProject ? Or is this external project meant to be packaged in the >> same package as the project using it? >> > > I cannot add a package step as the external project do not support > packaging, it is only a configure / make / make install project. That is > why I use CPack. > But I package it as a separate package. > Yep I understand that. My suggestion was precisely to **add** a package step to ExternalProject unless it doesn't make sense for ExternalProject_Add May be you can do that with ExternalProject_Add_Step in your own CMakeLists.txt ? Something like (untested): ExternalProject_Add_Step(sqlcipher package COMMAND "cpack" WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR} COMMENT "Package with cpack" DEPENDEES "install" ) I don't know much about ExternalProject internals so I may be wrong. Anyway, the DESTDIR=/tmp make package does the trick for me but I still can > implement an integrated solution if it is useful for others ? > As I said this trick is only a way to throw away (in /tmp) the default install command which is called by make (or make package) as the part of the install step of ExternalProject_Add. -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcdailey.lists at gmail.com Tue Jul 18 10:44:21 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Tue, 18 Jul 2017 09:44:21 -0500 Subject: [CMake] Copying target output file to another directory Message-ID: So I need to copy the output *.so from a target to an arbitrary directory outside the CMAKE_BINARY_DIR. I tried doing this as a post build event using generator expressions: add_custom_command( TARGET ${target} POST_BUILD VERBATIM COMMAND ${CMAKE_COMMAND} -E copy "$" ${dir} ) This fails because I'm running it outside of the directory where ${target} is defined: CMake Error at Core/CMake/third-party.cmake:86 (add_custom_command): TARGET 'MagickCore' was not created in this directory. How can I do this without moving my add_custom_command() to the same directory that created the target? I need to add all the custom commands at the end of generation because it depends on certain global properties which are not completely done being set until the very end. From alfred at huji.fr Tue Jul 18 10:44:49 2017 From: alfred at huji.fr (Alfred Sawaya) Date: Tue, 18 Jul 2017 14:44:49 +0000 Subject: [CMake] ExternalProject + PREFIX + CPACK - cannot get the good path In-Reply-To: References: Message-ID: > > May be you can do that with ExternalProject_Add_Step in your own > CMakeLists.txt ? > > Something like (untested): > > ExternalProject_Add_Step(sqlcipher package > COMMAND "cpack" > WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR} > COMMENT "Package with cpack" > DEPENDEES "install" > ) > It does not work because the install step still tries to install files to /usr/local/lib and if I set INSTALL_COMMAND at "", CPack will produce an empty package. So I would still need to play with DESTDIR the same way as if I use include(CPack). > > I don't know much about ExternalProject internals so I may be wrong. > > Anyway, the DESTDIR=/tmp make package does the trick for me but I still >> can implement an integrated solution if it is useful for others ? >> > > As I said this trick is only a way to throw away (in /tmp) the default > install command which is called by > make (or make package) as the part of the install step > of ExternalProject_Add. > > -- > Eric > -- Cordialement, Alfred Sawaya -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Tue Jul 18 11:54:55 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 18 Jul 2017 11:54:55 -0400 Subject: [CMake] Copying target output file to another directory In-Reply-To: References: Message-ID: Question: Is there a specific reason why you don't want to do this as part of the install step? If this can't be done at install time, you can look at using add_custom_command Generating File signature with a target dependency on ${target} On Tue, Jul 18, 2017 at 10:44 AM, Robert Dailey wrote: > So I need to copy the output *.so from a target to an arbitrary > directory outside the CMAKE_BINARY_DIR. I tried doing this as a post > build event using generator expressions: > > add_custom_command( > TARGET ${target} POST_BUILD VERBATIM > COMMAND ${CMAKE_COMMAND} -E copy "$" ${dir} > ) > > This fails because I'm running it outside of the directory where > ${target} is defined: > > CMake Error at Core/CMake/third-party.cmake:86 (add_custom_command): > TARGET 'MagickCore' was not created in this directory. > > > How can I do this without moving my add_custom_command() to the same > directory that created the target? I need to add all the custom > commands at the end of generation because it depends on certain global > properties which are not completely done being set until the very end. > -- > > 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 eric.noulard at gmail.com Tue Jul 18 12:02:40 2017 From: eric.noulard at gmail.com (Eric Noulard) Date: Tue, 18 Jul 2017 18:02:40 +0200 Subject: [CMake] Transitive behavior of target_link_libraries between shared/static In-Reply-To: References: Message-ID: 2017-07-17 17:31 GMT+02:00 Robert Dailey : > Suppose I have the following: > > ``` > add_library( A STATIC ${files} ) > > add_library( B SHARED ${more_files} ) > target_link_libraries( B PUBLIC A ) > > add_library( C STATIC ${even_more_files} ) > target_link_libraries( C PUBLIC B ) > > > add_executable( D ${exe_files} ) > target_link_libraries( D PRIVATE C ) > ``` > > Does the linker command for target `D` ever see target A's static link > library? I'm hoping the only thing the linker gets is `libB.so` and > `libC.a`, without `libA.a`. > I guess it does otherwise you may be missing symbols. As explain by Peter some time ago: https://cmake.org/pipermail/cmake/2017-April/065347.html when you target_link_libraries( B PUBLIC A ) with A being STATIC you do not really link A into B (which is shared in your example) but you add A as a PUBLIC item of the link interface of B such that when actual linking occurs if you build an executable linked to B then A is automagically brought to the link step. More info on that topic by Craig: https://cmake.org/pipermail/cmake/2016-May/063400.html > It seems like A to everyone outside of B should just be a set of > public include directories and compile definitions, since the link > file aspect of it should be hidden across shared library boundaries. > No it is not, because the binary object inside A are NOT embedded into B. If you want that then you need to make A an OBJECT library and not a STATIC library. > Hoping someone can explain how this works. I want to make sure static > libs sitting behind shared libs in the dependency tree do not get > exposed. > My understanding is that you cannot do what you want with static lib. You can do that with OBJECT lib though. Knowing that you cannot use target_link_libraries with OBJECT lib: https://cmake.org/cmake/help/v3.9/manual/cmake-buildsystem.7.html#object-libraries Hope this helps. -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From post at hendrik-sattler.de Tue Jul 18 13:15:36 2017 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Tue, 18 Jul 2017 19:15:36 +0200 Subject: [CMake] Transitive behavior of target_link_libraries between shared/static In-Reply-To: References: Message-ID: <24EF3E3B-44E2-4548-B46B-F0B8D6A06EDC@hendrik-sattler.de> Am 18. Juli 2017 18:02:40 MESZ schrieb Eric Noulard : >2017-07-17 17:31 GMT+02:00 Robert Dailey : > >> Suppose I have the following: >> >> ``` >> add_library( A STATIC ${files} ) >> >> add_library( B SHARED ${more_files} ) >> target_link_libraries( B PUBLIC A ) >> >> add_library( C STATIC ${even_more_files} ) >> target_link_libraries( C PUBLIC B ) >> >> >> add_executable( D ${exe_files} ) >> target_link_libraries( D PRIVATE C ) >> ``` >> >> Does the linker command for target `D` ever see target A's static >link >> library? I'm hoping the only thing the linker gets is `libB.so` and >> `libC.a`, without `libA.a`. >> > >I guess it does otherwise you may be missing symbols. >As explain by Peter some time ago: > https://cmake.org/pipermail/cmake/2017-April/065347.html >when you >target_link_libraries( B PUBLIC A ) > >with A being STATIC you do not really link A into B (which is shared in >your example) You confused PUBLIC and INTERFACE in your response. target_link_libraries( B PUBLIC A ) DOES link A into B but only the symbols needed by B. The link to the old post has it all right. HS -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. From rcdailey.lists at gmail.com Tue Jul 18 13:28:05 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Tue, 18 Jul 2017 12:28:05 -0500 Subject: [CMake] Copying target output file to another directory In-Reply-To: References: Message-ID: This is part of a lot of complex logic to integrate ANT into CMake as transparently as possible to assist in integrating Android support (building Java and APK). So I do not use INSTALL targets. This is an implementation detail since the libs are required in a specific directory so that ANT can package them into the APK for distribution to Android devices. On Tue, Jul 18, 2017 at 10:54 AM, Robert Maynard wrote: > Question: Is there a specific reason why you don't want to do this as > part of the install step? > > If this can't be done at install time, you can look at using > add_custom_command Generating File signature with a target dependency > on ${target} > > On Tue, Jul 18, 2017 at 10:44 AM, Robert Dailey > wrote: >> So I need to copy the output *.so from a target to an arbitrary >> directory outside the CMAKE_BINARY_DIR. I tried doing this as a post >> build event using generator expressions: >> >> add_custom_command( >> TARGET ${target} POST_BUILD VERBATIM >> COMMAND ${CMAKE_COMMAND} -E copy "$" ${dir} >> ) >> >> This fails because I'm running it outside of the directory where >> ${target} is defined: >> >> CMake Error at Core/CMake/third-party.cmake:86 (add_custom_command): >> TARGET 'MagickCore' was not created in this directory. >> >> >> How can I do this without moving my add_custom_command() to the same >> directory that created the target? I need to add all the custom >> commands at the end of generation because it depends on certain global >> properties which are not completely done being set until the very end. >> -- >> >> 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 Tue Jul 18 13:48:09 2017 From: ggarra13 at gmail.com (=?UTF-8?Q?Gonzalo_Garramu=c3=b1o?=) Date: Tue, 18 Jul 2017 14:48:09 -0300 Subject: [CMake] Boost moves to CMake Message-ID: Just posted in the boost mailing list. Congratulations to both teams! -- Gonzalo Garramu?o From robert.maynard at kitware.com Tue Jul 18 14:28:24 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 18 Jul 2017 14:28:24 -0400 Subject: [CMake] [ANNOUNCE] CMake 3.9.0 available for download Message-ID: I am proud to announce that CMake 3.9.0 is now available for download at: https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.9 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.9/release/3.9.html Some of the more significant changes in CMake 3.9 are: * The "Visual Studio 14 2015" generator has been taught about a change to the "v140" toolset made by a VS 2015 update. VS changed the set of values it understands for the "GenerateDebugInformation" linker setting that produces the "-DEBUG" linker flag variants. * "CUDA" is now supported by the Visual Studio Generators for VS 2010 and above. This complements the existing support by the Makefile Generators and the "Ninja" generator. CUDA 8.0.61 or higher is recommended due to known bugs in the VS integration by earlier versions. * CMake is now aware of the "C++ standards" and "C standards" and their associated meta-features for the following "compiler ids": "Cray", "PGI", and "XL". * The "add_library()" command "IMPORTED" option learned to support Object Libraries. * All "find_" commands now have a "PACKAGE_ROOT" search path group that is first in the search heuristics. If a "find_" command is called from inside a find module, then the CMake variable and environment variable named "_ROOT" are used as prefixes and are the first set of paths to be searched. * The "install(TARGETS)" command learned a new "OBJECTS" option to specify where to install Object Libraries. * The "install(EXPORT)" command learned how to export Object Libraries. * A "BUILD_WITH_INSTALL_NAME_DIR" target property and corresponding "CMAKE_BUILD_WITH_INSTALL_NAME_DIR" variable were added to control whether to use the "INSTALL_NAME_DIR" target property value for binaries in the build tree. This is for macOS "install_name" as "BUILD_WITH_INSTALL_RPATH" is for "RPATH". * A "CUDA_PTX_COMPILATION" target property was added to Object Libraries to support compiling to ".ptx" files instead of host object files. * A new "GoogleTest" module was added to provide the "gtest_add_tests()" function independently of the "FindGTest" module. The function was also updated to support keyword arguments, with functionality expanded to allow a test name prefix and suffix to be specified, the dependency on the source files to be optional and the list of discovered test cases to be returned to the caller. * The "Ninja" generator has loosened the dependencies of object compilation. Object compilation now depends only on custom targets and custom commands associated with libraries on which the object's target depends and no longer depends on the libraries themselves. Source files in dependent targets may now compile without waiting for their targets' dependencies to link. * Interprocedural optimization (IPO) is now supported for GNU and Clang compilers using link time optimization (LTO) flags. See the "INTERPROCEDURAL_OPTIMIZATION" target property and "CheckIPOSupported" module. * The "TARGET_OBJECTS" "generator expression" is now supported by the "add_custom_command()" and "file(GENERATE)" commands. CMake 3.9 Release Notes *********************** Changes made since CMake 3.8 include the following. New Features ============ Languages --------- * "CUDA" is now supported by the Visual Studio Generators for VS 2010 and above. This complements the existing support by the Makefile Generators and the "Ninja" generator. CUDA 8.0.61 or higher is recommended due to known bugs in the VS integration by earlier versions. * CMake is now aware of the "C++ standards" and "C standards" and their associated meta-features for the following "compiler ids": "Cray", "PGI", and "XL". Generators ---------- * Visual Studio Generators for VS 2010 and above learned to support the "ASM_NASM" language when "nasm" is installed. * The "Xcode" generator learned to create Xcode schema files. This is an experimental feature and can be activated by setting the "CMAKE_XCODE_GENERATE_SCHEME" variable to a "TRUE" value. * The "Xcode" generator now supports Xcode 9. Commands -------- * The "add_library()" command "IMPORTED" option learned to support Object Libraries. * All "find_" commands now have a "PACKAGE_ROOT" search path group that is first in the search heuristics. If a "find_" command is called from inside a find module, then the CMake variable and environment variable named "_ROOT" are used as prefixes and are the first set of paths to be searched. * The "find_library()" command learned to search "libx32" paths when the build targets the "x32" ABI. See the "FIND_LIBRARY_USE_LIBX32_PATHS" global property. * The "include_external_msproject()" command learned to use the "MAP_IMPORTED_CONFIG_" target property to map current configurations to the external configurations. * The "install(TARGETS)" command learned a new "OBJECTS" option to specify where to install Object Libraries. * The "install(EXPORT)" command learned how to export Object Libraries. * The "project()" command learned an optional "DESCRIPTION" parameter to set the "PROJECT_DESCRIPTION" variable. * The "separate_arguments()" command gained a "NATIVE_COMMAND" mode that performs argument separation depending on the host operating system. Variables --------- * A "CMAKE_ANDROID_NDK_DEPRECATED_HEADERS" variable was added for use when Cross Compiling for Android with the NDK to request use of the deprecated headers even when unified headers are available. The default is now to use unified headers if available. * A "CMAKE_AUTOMOC_DEPEND_FILTERS" variable was introduced to allow "CMAKE_AUTOMOC" to extract additional dependency file names for "moc" from the contents of source files. * A "CMAKE_AUTOUIC_SEARCH_PATHS" variable was introduced to allow "CMAKE_AUTOUIC" to search for "foo.ui" in more places than the vicinity of the file including "ui_foo.h". * A "CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX" variable was added to tell the "find_library()" command to search in a "lib" directory before each "lib" directory that would normally be searched. * A "CMAKE_INTERPROCEDURAL_OPTIMIZATION" variable was added to initialize the "INTERPROCEDURAL_OPTIMIZATION" property on all targets. * A "CMAKE__COMPILER_AR" variable was added to hold the path to the GCC/Clang wrapper of "ar". * A "CMAKE__COMPILER_RANLIB" variable was added to hold the path to the GCC/Clang wrapper of "ranlib". * The "CMAKE_SYSROOT_COMPILE" and "CMAKE_SYSROOT_LINK" variables were added to use separate sysroots for compiling and linking. Properties ---------- * A new "AUTOGEN_BUILD_DIR" target property was introduced to set a custom output directory for "AUTOMOC", "AUTOUIC", and "AUTORCC". * A new "AUTOMOC_DEPEND_FILTERS" target property was introduced to allow "AUTOMOC" to extract additional dependency file names for "moc" from the contents of source files. * A new "AUTOUIC_SEARCH_PATHS" target property was introduced to allow "AUTOUIC" to search for "foo.ui" in more places than the vicinity of the file including "ui_foo.h". * Global properties "AUTOGEN_SOURCE_GROUP", "AUTOMOC_SOURCE_GROUP" and "AUTORCC_SOURCE_GROUP" were introduced to allow files generated by "AUTOMOC" or "AUTORCC" to be placed in a "source_group()". * A "BUILD_WITH_INSTALL_NAME_DIR" target property and corresponding "CMAKE_BUILD_WITH_INSTALL_NAME_DIR" variable were added to control whether to use the "INSTALL_NAME_DIR" target property value for binaries in the build tree. This is for macOS "install_name" as "BUILD_WITH_INSTALL_RPATH" is for "RPATH". * A "CUDA_PTX_COMPILATION" target property was added to Object Libraries to support compiling to ".ptx" files instead of host object files. * A "GENERATOR_IS_MULTI_CONFIG" global property was added to determine whether the current generator is a multi-configuration generator (such as Visual Studio Generators or "Xcode"). * The "INTERPROCEDURAL_OPTIMIZATION" target property is now enforced when enabled. CMake will add IPO flags unconditionally or produce an error if it does not know the flags for the current compiler. The project is now responsible to use the "CheckIPOSupported" module to check for IPO support before enabling the target property. See policy "CMP0069". * The "WINDOWS_EXPORT_ALL_SYMBOLS" target property may now be used in combination with explicit ".def" files in order to export all symbols from the object files within a target plus an explicit list of symbols that the linker finds in dependencies (e.g. "msvcrt.lib"). Modules ------- * A "CheckIPOSupported" module was added to help projects check whether interprocedural optimization (IPO) is supported by the current toolchain and CMake version. * The "CMakeFindDependencyMacro" module "find_dependency" macro now forwards all arguments to the underlying "find_package()" call. Existing uses will continue to function as before, but callers can now access the full suite of arguments that "find_package" accepts. * The "FeatureSummary" module "feature_summary()" command now accepts the new "DEFAULT_DESCRIPTION" option that will print the default title for the selected package type. * The "FeatureSummary" module gained a new "FeatureSummary__DESCRIPTION" variable that can be defined for each "" to replace the type name with the specified string whenever the package type is used in an output string by the module. * The "FindDoxygen" module learned to control Doxygen behavior using CMake variables and generate documentation via the newly added "doxygen_add_docs()" function. The Doxygen input file ("Doxyfile") is automatically generated and doxygen is run as part of a custom target. Additional components can be specified to find optional tools: "dot", "mscgen" and "dia". * The "FindMPI" module now provides imported targets. * The "FindProtobuf" module "protobuf_generate_cpp()" command gained an "EXPORT_MACRO" option to specify the name of a DLL export markup macro. * The "FindProtobuf" module now supports usage of static libraries for Unix via a new "Protobuf_USE_STATIC_LIBS" input variable. * The "FindProtobuf" module now provides imported targets when the libraries are found. * A new "GoogleTest" module was added to provide the "gtest_add_tests()" function independently of the "FindGTest" module. The function was also updated to support keyword arguments, with functionality expanded to allow a test name prefix and suffix to be specified, the dependency on the source files to be optional and the list of discovered test cases to be returned to the caller. CTest ----- * The "ctest_submit()" command gained a "HTTPHEADER" option to specify custom headers to send during submission. * The "ctest(1)" executable gained new options which allow the developer to disable automatically adding tests to the test set to satisfy fixture dependencies. "-FS" prevents adding setup tests for fixtures matching the provided regular expression, "-FC" prevents adding cleanup tests for matching fixtures and "-FA" prevents adding any test for matching fixtures. * A "DISABLED" test property was added to mark tests that are configured but explicitly disabled so they do not run. CPack ----- * The "CPackArchive" module learned to modify the filename per- component. See the "CPACK_ARCHIVE_FILE_NAME" variable and its per- component version "CPACK_ARCHIVE__FILE_NAME". * The "CPackComponent" module "cpack_add_component()" command gained a new "PLIST " option to specify the "pkgbuild" "-- component-plist" argument when using the "productbuild" generator. * The "CPackIFW" module "cpack_ifw_configure_component()" and "cpack_ifw_configure_component_group()" commands gained internationalization support for "DISPLAY_NAME" and "DESCRIPTION" options. * The "CPackIFW" module learned the new hint "CPACK_IFW_ROOT" variable for finding the QtIFW tool suite installed in a non- standard place. * The "CPackProductBuild" module gained a new "CPACK_PRODUCTBUILD_RESOURCES_DIR" variable to specify resources to be copied into the "Resources" directory. * The "CPackRPM" module learned to modify the "debuginfo" package name. See the "CPACK_RPM_DEBUGINFO_FILE_NAME" variable. * The "CPackWIX" module patching system now has the ability to set additional attributes. This can be done by specifying attributes with the "CPackWiXFragment" XML tag after the "Id" attribute. See the "CPACK_WIX_PATCH_FILE" variable. * The CPack WIX generator implemented a new "CPACK_WIX_ROOT_FOLDER_ID" variable which allows using a custom root folder ID instead of the default "ProgramFilesFolder" / "ProgramFiles64Folder". Other ----- * Interprocedural optimization (IPO) is now supported for GNU and Clang compilers using link time optimization (LTO) flags. See the "INTERPROCEDURAL_OPTIMIZATION" target property and "CheckIPOSupported" module. * The "TARGET_OBJECTS" "generator expression" is now supported by the "add_custom_command()" and "file(GENERATE)" commands. * Two new informational generator expressions to retrieve Apple Bundle directories have been added. The first one "$" outputs the full path to the Bundle directory, the other one "$" outputs the full path to the "Contents" directory of macOS Bundles and App Bundles. For all other bundle types and SDKs it is identical with "$". The new expressions are helpful to query Bundle locations independent of the different Bundle types and layouts on macOS and iOS. Deprecated and Removed Features =============================== * An explicit deprecation diagnostic was added for policies "CMP0036" and below. The "cmake-policies(7)" manual explains that the OLD behaviors of all policies are deprecated and that projects should always port to the NEW behaviors as soon as possible. * The "Visual Studio 8 2005" generator is now deprecated and will be removed in a future version of CMake. * The "Visual Studio 7 .NET 2003" generator has been removed. * The "Xcode" generator dropped support for Xcode versions older than 3. * The "FindDoxygen" module has deprecated several variables. * The version of curl bundled with CMake no longer accepts URLs of the form "file://c:/..." on Windows due to a change in upstream curl 7.52. Use the form "file:///c:/..." instead to work on all versions. Other Changes ============= * When using "AUTOMOC", CMake now scans for the presence of the "Q_PLUGIN_METADATA" macro and reruns moc when the file from the macro's "FILE" argument changes. * When "AUTOMOC" detects an include statement of the form "#include "moc_.cpp"" the search for the respective header file now looks in the "INCLUDE_DIRECTORIES" of the target as well. * When running tests, CTest learned to treat skipped tests (using the "SKIP_RETURN_CODE" property) the same as tests with the new "DISABLED" property. Due to this change, CTest will not indicate failure when all tests are either skipped or pass. * The "Ninja" generator has loosened the dependencies of object compilation. Object compilation now depends only on custom targets and custom commands associated with libraries on which the object's target depends and no longer depends on the libraries themselves. Source files in dependent targets may now compile without waiting for their targets' dependencies to link. * On macOS, the default application bundle "Info.plist" file now enables Hi-DPI support. * On macOS, "RPATH" settings such as "BUILD_WITH_INSTALL_RPATH" no longer affect the "install_name" field. See policy "CMP0068". * The "Visual Studio 14 2015" generator has been taught about a change to the "v140" toolset made by a VS 2015 update. VS changed the set of values it understands for the "GenerateDebugInformation" linker setting that produces the "-DEBUG" linker flag variants. ---------------------------------------------------------------------------- Changes made since CMake 3.9.0-rc6: Brad King (6): Android: Always add standard include directories last TestDriver: Fix -Wconversion warning Features: Fix support for a list of language standard options Help: Add a 3.9 release note about the VS GenerateDebugInformation update Diagnose object library self-reference CMake 3.9.0 Harry Mallon (1): Xcode: Add "outputPaths" to custom command script build phase Robert Maynard (1): CUDA: CMAKE_EXPORT_COMPILE_COMMANDS now works with CUDA and Ninja From rcdailey.lists at gmail.com Tue Jul 18 14:33:16 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Tue, 18 Jul 2017 13:33:16 -0500 Subject: [CMake] Transitive behavior of target_link_libraries between shared/static In-Reply-To: <24EF3E3B-44E2-4548-B46B-F0B8D6A06EDC@hendrik-sattler.de> References: <24EF3E3B-44E2-4548-B46B-F0B8D6A06EDC@hendrik-sattler.de> Message-ID: Maybe I'm missing something here, but that linked article doesn't really address my specific case. And his definition is technically correct, as long as CMake is smart enough to handle the case where (again in my example) A does not need to be explicitly linked to D because they were already linked into B (since it's a shared library). Link dependencies of B should be firewalled to downstream targets. However, include dependencies for example may be needed downstream since B's public headers may require them. I could create a sandbox using my example to verify the behavior, but i thought it would be quicker to ask here to see if anyone knew. On Tue, Jul 18, 2017 at 12:15 PM, Hendrik Sattler wrote: > > > Am 18. Juli 2017 18:02:40 MESZ schrieb Eric Noulard : >>2017-07-17 17:31 GMT+02:00 Robert Dailey : >> >>> Suppose I have the following: >>> >>> ``` >>> add_library( A STATIC ${files} ) >>> >>> add_library( B SHARED ${more_files} ) >>> target_link_libraries( B PUBLIC A ) >>> >>> add_library( C STATIC ${even_more_files} ) >>> target_link_libraries( C PUBLIC B ) >>> >>> >>> add_executable( D ${exe_files} ) >>> target_link_libraries( D PRIVATE C ) >>> ``` >>> >>> Does the linker command for target `D` ever see target A's static >>link >>> library? I'm hoping the only thing the linker gets is `libB.so` and >>> `libC.a`, without `libA.a`. >>> >> >>I guess it does otherwise you may be missing symbols. >>As explain by Peter some time ago: >> https://cmake.org/pipermail/cmake/2017-April/065347.html >>when you >>target_link_libraries( B PUBLIC A ) >> >>with A being STATIC you do not really link A into B (which is shared in >>your example) > > You confused PUBLIC and INTERFACE in your response. > target_link_libraries( B PUBLIC A ) DOES link A into B but only the symbols needed by B. > > The link to the old post has it all right. > > HS > > > -- > Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. From konstantin at podsvirov.pro Tue Jul 18 15:04:13 2017 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Tue, 18 Jul 2017 22:04:13 +0300 Subject: [CMake] Boost moves to CMake In-Reply-To: References: Message-ID: <222361500404653@web9g.yandex.ru> An HTML attachment was scrubbed... URL: From rcdailey.lists at gmail.com Tue Jul 18 16:38:31 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Tue, 18 Jul 2017 15:38:31 -0500 Subject: [CMake] Best way to append "--no-undefined" to shared link flags? Message-ID: For only compilers that support it (I guess any clang/gcc compiler?), I want my shared libs to link with "--no-undefined". What is the best (most modern) way using CMake 3.9.0 and forward to do this? Is it still to explicitly set CMAKE_SHARED_LINKER_FLAGS? How does this impact using toolchain files and cross compiling? I don't want to wipe out any existing flags, and I'm not sure of the exact syntax the command line options need to follow. From tzsariysk at gmail.com Tue Jul 18 16:46:12 2017 From: tzsariysk at gmail.com (T.Sariyski) Date: Tue, 18 Jul 2017 14:46:12 -0600 Subject: [CMake] How to make a Fortran file dependent on #inclde files Message-ID: <020c01d30006$e52f9160$af8eb420$@gmail.com> Hi, I have a Fortran project with numerous #include files. When a #include file is changed, CMake does not detect the change, and does not rebuild the objects using this include file. In order to reflect the change, currently I ?make clean; make?, which rebuilds the entire project. Is there a way to tell CMake that a Fortran file depends from its #include files? Thanks in advance, Ted P.S. I use cmake-3.4.3 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcdailey.lists at gmail.com Tue Jul 18 16:52:23 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Tue, 18 Jul 2017 15:52:23 -0500 Subject: [CMake] Best way to append "--no-undefined" to shared link flags? In-Reply-To: References: Message-ID: +CMake dev list After googling I came up with this: set( CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -Wl,--no-undefined" ) After talking more with the NDK devs on github though, they seem to indicate this should happen by default (or at least, it does with the CMake that ships with the NDK according to Dan Albert). Does --no-defined get specified by default for other platforms? Or is it just Android that isn't getting it? On Tue, Jul 18, 2017 at 3:38 PM, Robert Dailey wrote: > For only compilers that support it (I guess any clang/gcc compiler?), > I want my shared libs to link with "--no-undefined". What is the best > (most modern) way using CMake 3.9.0 and forward to do this? Is it > still to explicitly set CMAKE_SHARED_LINKER_FLAGS? How does this > impact using toolchain files and cross compiling? I don't want to wipe > out any existing flags, and I'm not sure of the exact syntax the > command line options need to follow. From eric.noulard at gmail.com Wed Jul 19 02:38:49 2017 From: eric.noulard at gmail.com (Eric Noulard) Date: Wed, 19 Jul 2017 08:38:49 +0200 Subject: [CMake] Transitive behavior of target_link_libraries between shared/static In-Reply-To: <24EF3E3B-44E2-4548-B46B-F0B8D6A06EDC@hendrik-sattler.de> References: <24EF3E3B-44E2-4548-B46B-F0B8D6A06EDC@hendrik-sattler.de> Message-ID: 2017-07-18 19:15 GMT+02:00 Hendrik Sattler : > > > Am 18. Juli 2017 18:02:40 MESZ schrieb Eric Noulard < > eric.noulard at gmail.com>: > >2017-07-17 17:31 GMT+02:00 Robert Dailey : > > > >> Suppose I have the following: > >> > >> ``` > >> add_library( A STATIC ${files} ) > >> > >> add_library( B SHARED ${more_files} ) > >> target_link_libraries( B PUBLIC A ) > >> > >> add_library( C STATIC ${even_more_files} ) > >> target_link_libraries( C PUBLIC B ) > >> > >> > >> add_executable( D ${exe_files} ) > >> target_link_libraries( D PRIVATE C ) > >> ``` > >> > >> Does the linker command for target `D` ever see target A's static > >link > >> library? I'm hoping the only thing the linker gets is `libB.so` and > >> `libC.a`, without `libA.a`. > >> > > > >I guess it does otherwise you may be missing symbols. > >As explain by Peter some time ago: > > https://cmake.org/pipermail/cmake/2017-April/065347.html > >when you > >target_link_libraries( B PUBLIC A ) > > > >with A being STATIC you do not really link A into B (which is shared in > >your example) > > You confused PUBLIC and INTERFACE in your response. > target_link_libraries( B PUBLIC A ) DOES link A into B but only the > symbols needed by B. > > The link to the old post has it all right. > > Thanks for the clarification Hendrik, The thing I wasn't sure is that when B is shared and A is static target_link_libraries(B PUBLIC A) or even target_link_libraries(B PRIVATE A) was effectively putting objects from A needed by B into B. My use case was when B and A were STATIC. I'll try an example in order to have concrete example at hand. -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From roman.wueger at gmx.at Wed Jul 19 04:24:36 2017 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Wed, 19 Jul 2017 10:24:36 +0200 Subject: [CMake] CPack install 3rd party shared libraries Message-ID: Hello, I have a project which depends on a self compiled 3rd party project (boost) Boost is here only an example, there are other 3rd party libraries too. If I call the "install" command on the target, then it would be packaged. But how could I add the shared libraries and especially the links for the shared libraries? E.g.: libboost_filesystem.so -> libboost_filesystem.so.1.48.0 libboost_filesystem.so.1.48.0 Thanks in advance Best Regards Roman From volker.enderlein at ifm-chemnitz.de Wed Jul 19 05:41:51 2017 From: volker.enderlein at ifm-chemnitz.de (Volker Enderlein) Date: Wed, 19 Jul 2017 11:41:51 +0200 Subject: [CMake] How to properly use AUTOGEN_BUILD_DIR property? Message-ID: <0699c728-c004-efbc-57f5-7cf867713d79@ifm-chemnitz.de> Hi, our project contains lots of autogenerated Qt files and when reading the 3.9 Release notes I was very excited about the new AUTOGEN_BUILD_DIR property to speed up the build times (for constantly bulding debug and release versions in case nothing has changed). But it seems I cannot get it to work properly with MSVC 14 2015 and a config dependent AUTOGEN_BUILD_DIR. My CMakeLists.txt basically looks the following way: cmake_minimum_required (VERSION 3.9) project(AUTOGEN_Test) find_package(Qt5 COMPONENTS Core Gui Widgets REQUIRED) set(HEADERS file.h main.h) set(SOURCES file.cpp main.cpp) set(CMAKE_AUTOMOC TRUE) set(CMAKE_AUTOUIC TRUE) set(CMAKE_AUTORCC TRUE) add_executable(TargetName ${HEADERS} ${SOURCES}) set_target_properties(TargetName PROPERTIES AUTOGEN_BUILD_DIR ${CMAKE_CURRENT_BINARY_DIR}/TargetName_autogen_$<$:Debug>$<$>:Release>) target_link_libraries(TargetName Qt5:Qt5Core Qt5:Qt5Gui Qt5:Qt5Widgets ) The resulting error messages are as follows: CMake Error at C:/Temp/AUTOGEN_Test/CMakeLists.txt:14 (add_executable): Cannot find source file: C:/Temp/AUTOGEN_Test_build/TargetName_autogen_Debug/mocs_compilation.cpp Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp.hxx .in .txx and respectively for the Release version. What am I doing wrong?Thanks in advance, Cheers, Volker -- From elvis.stansvik at orexplore.com Wed Jul 19 06:40:57 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Wed, 19 Jul 2017 12:40:57 +0200 Subject: [CMake] CPack install 3rd party shared libraries In-Reply-To: References: Message-ID: 2017-07-19 10:24 GMT+02:00 Roman W?ger : > Hello, > > I have a project which depends on a self compiled 3rd party project (boost) > Boost is here only an example, there are other 3rd party libraries too. > > If I call the "install" command on the target, then it would be packaged. > But how could I add the shared libraries and especially the links for the shared libraries? > > E.g.: > libboost_filesystem.so -> libboost_filesystem.so.1.48.0 > libboost_filesystem.so.1.48.0 > > Thanks in advance I think fixup_bundle() from BundleUtilities is what you want [1]. We're using it to make our Windows and macOS installs standalone, but (I think) it should work on Linux as well. [1] https://cmake.org/cmake/help/v3.8/module/BundleUtilities.html > > Best Regards > Roman > -- > > 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 roman.wueger at gmx.at Wed Jul 19 07:42:51 2017 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Wed, 19 Jul 2017 13:42:51 +0200 Subject: [CMake] CPack install 3rd party shared libraries In-Reply-To: References: Message-ID: <84FEA0E6-A45E-4E79-85AA-84B8A643FD55@gmx.at> The problem with BundleUtilities which Inder is that it doesn't support generator expressions. Maybe I do something wrong? But I need to specify the path to the executable (generator expression) and the paths where to look for dependencies. Right? Please, could you give me a hint? Regards Roman > Am 19.07.2017 um 12:40 schrieb Elvis Stansvik : > > 2017-07-19 10:24 GMT+02:00 Roman W?ger : >> Hello, >> >> I have a project which depends on a self compiled 3rd party project (boost) >> Boost is here only an example, there are other 3rd party libraries too. >> >> If I call the "install" command on the target, then it would be packaged. >> But how could I add the shared libraries and especially the links for the shared libraries? >> >> E.g.: >> libboost_filesystem.so -> libboost_filesystem.so.1.48.0 >> libboost_filesystem.so.1.48.0 >> >> Thanks in advance > > I think fixup_bundle() from BundleUtilities is what you want [1]. > > We're using it to make our Windows and macOS installs standalone, but > (I think) it should work on Linux as well. > > [1] https://cmake.org/cmake/help/v3.8/module/BundleUtilities.html > >> >> Best Regards >> Roman >> -- >> >> 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 elvis.stansvik at orexplore.com Wed Jul 19 09:57:30 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Wed, 19 Jul 2017 15:57:30 +0200 Subject: [CMake] CPack install 3rd party shared libraries In-Reply-To: <84FEA0E6-A45E-4E79-85AA-84B8A643FD55@gmx.at> References: <84FEA0E6-A45E-4E79-85AA-84B8A643FD55@gmx.at> Message-ID: 2017-07-19 13:42 GMT+02:00 Roman W?ger : > The problem with BundleUtilities which Inder is that it doesn't support generator expressions. > > Maybe I do something wrong? > But I need to specify the path to the executable (generator expression) and the paths where to look for dependencies. Right? You don't need to use a generator to fetch the executable path. You will know the path, since you installed the executable with install(..) :) I think most people essentially hardcode the executable path in their call to fixup_bundle(..). If you really want to, I think there is a way to use generator expressions, and that is to put the fixup_bundle(..) call in a separate file (say InstallStuff.cmake.in), and then process that file with file(GENERATE OUTPUT ...) [1] to produce InstallStuff.cmake with generator expressions evaluated and then use install(SCRIPT InstallStuff.cmake). But that's much too complicated IMHO, and I would avoid it. I made a minimal example that links against zlib and also the Boost library you mentioned: cmake_minimum_required(VERSION 2.8) project(bundletest) find_package(ZLIB REQUIRED) find_package(Boost REQUIRED COMPONENTS filesystem) add_executable(bundletest main.cpp) target_include_directories(bundletest PRIVATE ${ZLIB_INCLUDE_DIRS} ${Boost_INCLUDE_DIRS}) target_link_libraries(bundletest ${ZLIB_LIBRARIES} ${Boost_LIBRARIES}) install(TARGETS bundletest RUNTIME DESTINATION "bin" ) install(CODE " function(gp_resolved_file_type_override resolved_file type_var) set(\${type_var} local PARENT_SCOPE) endfunction() include(BundleUtilities) fixup_bundle(\"\${CMAKE_INSTALL_PREFIX}/bin/bundletest\" \"\" \"\") " COMPONENT Runtime) main.cpp: #include #include #include using namespace boost::filesystem; int main (int argc, char *argv[]) { // Pretend we're using zlib and Boost deflateInit(0, 0); std::cout << file_size(argv[1]) << std::endl; return 0; } The overriding of the gp_resolved_file_type_override was necessary, to make it treat all libraries as local (otherwise it skips "system" libraries). See the docs for GetPrerequisites. Building/installing this with mkdir build cd build cmake -DCMAKE_INSTALL_PREFIX=~/bundletest_install .. make install produces: /home/estan/bundletest_install /home/estan/bundletest_install/bin /home/estan/bundletest_install/bin/bundletest /home/estan/bundletest_install/bin/libm.so.6 /home/estan/bundletest_install/bin/libstdc++.so.6 /home/estan/bundletest_install/bin/libc.so.6 /home/estan/bundletest_install/bin/libz.so.1 /home/estan/bundletest_install/bin/libpthread.so.0 /home/estan/bundletest_install/bin/libboost_system.so.1.58.0 /home/estan/bundletest_install/bin/libgcc_s.so.1 /home/estan/bundletest_install/bin/libboost_filesystem.so.1.58.0 I did the build on Ubuntu, and tested that it also runs in a clean Fedora 24 Docker container. Hope that helps some. Elvis [1] https://cmake.org/cmake/help/v3.9/command/file.html > > Please, could you give me a hint? > > Regards > Roman > >> Am 19.07.2017 um 12:40 schrieb Elvis Stansvik : >> >> 2017-07-19 10:24 GMT+02:00 Roman W?ger : >>> Hello, >>> >>> I have a project which depends on a self compiled 3rd party project (boost) >>> Boost is here only an example, there are other 3rd party libraries too. >>> >>> If I call the "install" command on the target, then it would be packaged. >>> But how could I add the shared libraries and especially the links for the shared libraries? >>> >>> E.g.: >>> libboost_filesystem.so -> libboost_filesystem.so.1.48.0 >>> libboost_filesystem.so.1.48.0 >>> >>> Thanks in advance >> >> I think fixup_bundle() from BundleUtilities is what you want [1]. >> >> We're using it to make our Windows and macOS installs standalone, but >> (I think) it should work on Linux as well. >> >> [1] https://cmake.org/cmake/help/v3.8/module/BundleUtilities.html >> >>> >>> Best Regards >>> Roman >>> -- >>> >>> 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 elvis.stansvik at orexplore.com Wed Jul 19 10:33:35 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Wed, 19 Jul 2017 16:33:35 +0200 Subject: [CMake] CPack install 3rd party shared libraries In-Reply-To: References: <84FEA0E6-A45E-4E79-85AA-84B8A643FD55@gmx.at> Message-ID: 2017-07-19 15:57 GMT+02:00 Elvis Stansvik : > 2017-07-19 13:42 GMT+02:00 Roman W?ger : >> The problem with BundleUtilities which Inder is that it doesn't support generator expressions. >> >> Maybe I do something wrong? >> But I need to specify the path to the executable (generator expression) and the paths where to look for dependencies. Right? And right, if your dependencies are in some place not searched by fixup_bundle by default, you need to supply those directories in the third parameter ("dirs"). In my example below, both zlib and boost were in standard locations on my system, so I didn't have to. Elvis > > You don't need to use a generator to fetch the executable path. You > will know the path, since you installed the executable with > install(..) :) I think most people essentially hardcode the executable > path in their call to fixup_bundle(..). > > If you really want to, I think there is a way to use generator > expressions, and that is to put the fixup_bundle(..) call in a > separate file (say InstallStuff.cmake.in), and then process that file > with file(GENERATE OUTPUT ...) [1] to produce InstallStuff.cmake with > generator expressions evaluated and then use install(SCRIPT > InstallStuff.cmake). But that's much too complicated IMHO, and I would > avoid it. > > I made a minimal example that links against zlib and also the Boost > library you mentioned: > > cmake_minimum_required(VERSION 2.8) > > project(bundletest) > > find_package(ZLIB REQUIRED) > find_package(Boost REQUIRED COMPONENTS filesystem) > > add_executable(bundletest main.cpp) > > target_include_directories(bundletest PRIVATE ${ZLIB_INCLUDE_DIRS} > ${Boost_INCLUDE_DIRS}) > > target_link_libraries(bundletest ${ZLIB_LIBRARIES} ${Boost_LIBRARIES}) > > install(TARGETS bundletest > RUNTIME DESTINATION "bin" > ) > > install(CODE " > function(gp_resolved_file_type_override resolved_file type_var) > set(\${type_var} local PARENT_SCOPE) > endfunction() > include(BundleUtilities) > fixup_bundle(\"\${CMAKE_INSTALL_PREFIX}/bin/bundletest\" \"\" \"\") > " COMPONENT Runtime) > > main.cpp: > > #include > #include > #include > > using namespace boost::filesystem; > > int main (int argc, char *argv[]) { > // Pretend we're using zlib and Boost > deflateInit(0, 0); > std::cout << file_size(argv[1]) << std::endl; > return 0; > } > > The overriding of the gp_resolved_file_type_override was necessary, to > make it treat all libraries as local (otherwise it skips "system" > libraries). See the docs for GetPrerequisites. > > Building/installing this with > > mkdir build > cd build > cmake -DCMAKE_INSTALL_PREFIX=~/bundletest_install .. > make install > > produces: > > /home/estan/bundletest_install > /home/estan/bundletest_install/bin > /home/estan/bundletest_install/bin/bundletest > /home/estan/bundletest_install/bin/libm.so.6 > /home/estan/bundletest_install/bin/libstdc++.so.6 > /home/estan/bundletest_install/bin/libc.so.6 > /home/estan/bundletest_install/bin/libz.so.1 > /home/estan/bundletest_install/bin/libpthread.so.0 > /home/estan/bundletest_install/bin/libboost_system.so.1.58.0 > /home/estan/bundletest_install/bin/libgcc_s.so.1 > /home/estan/bundletest_install/bin/libboost_filesystem.so.1.58.0 > > I did the build on Ubuntu, and tested that it also runs in a clean > Fedora 24 Docker container. > > Hope that helps some. > > Elvis > > [1] https://cmake.org/cmake/help/v3.9/command/file.html > >> >> Please, could you give me a hint? >> >> Regards >> Roman >> >>> Am 19.07.2017 um 12:40 schrieb Elvis Stansvik : >>> >>> 2017-07-19 10:24 GMT+02:00 Roman W?ger : >>>> Hello, >>>> >>>> I have a project which depends on a self compiled 3rd party project (boost) >>>> Boost is here only an example, there are other 3rd party libraries too. >>>> >>>> If I call the "install" command on the target, then it would be packaged. >>>> But how could I add the shared libraries and especially the links for the shared libraries? >>>> >>>> E.g.: >>>> libboost_filesystem.so -> libboost_filesystem.so.1.48.0 >>>> libboost_filesystem.so.1.48.0 >>>> >>>> Thanks in advance >>> >>> I think fixup_bundle() from BundleUtilities is what you want [1]. >>> >>> We're using it to make our Windows and macOS installs standalone, but >>> (I think) it should work on Linux as well. >>> >>> [1] https://cmake.org/cmake/help/v3.8/module/BundleUtilities.html >>> >>>> >>>> Best Regards >>>> Roman >>>> -- >>>> >>>> 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 DLRdave at aol.com Wed Jul 19 10:42:58 2017 From: DLRdave at aol.com (David Cole) Date: Wed, 19 Jul 2017 10:42:58 -0400 Subject: [CMake] CPack install 3rd party shared libraries In-Reply-To: References: <84FEA0E6-A45E-4E79-85AA-84B8A643FD55@gmx.at> Message-ID: Very nice example. Does CMake have a place to put examples like VTK does...? If so, where is it? And if not, it would be super useful to start one somewhere "official." However, one word of caution on the example. I know it was targeted at Linux, and perhaps for a very simple case it's proper, but using an unconditional "local" for everything in a gp_resolved_file_type_override would not be something you'd want to do in general, especially on Windows. You would end up with probably on the order of a hundred (or maybe nowadays even a few hundred) DLLs from the Windows system directories inside your bundle. Almost certainly not what you intended. Cheers, David C. On Wed, Jul 19, 2017 at 9:57 AM, Elvis Stansvik wrote: > 2017-07-19 13:42 GMT+02:00 Roman W?ger : >> The problem with BundleUtilities which Inder is that it doesn't support generator expressions. >> >> Maybe I do something wrong? >> But I need to specify the path to the executable (generator expression) and the paths where to look for dependencies. Right? > > You don't need to use a generator to fetch the executable path. You > will know the path, since you installed the executable with > install(..) :) I think most people essentially hardcode the executable > path in their call to fixup_bundle(..). > > If you really want to, I think there is a way to use generator > expressions, and that is to put the fixup_bundle(..) call in a > separate file (say InstallStuff.cmake.in), and then process that file > with file(GENERATE OUTPUT ...) [1] to produce InstallStuff.cmake with > generator expressions evaluated and then use install(SCRIPT > InstallStuff.cmake). But that's much too complicated IMHO, and I would > avoid it. > > I made a minimal example that links against zlib and also the Boost > library you mentioned: > > cmake_minimum_required(VERSION 2.8) > > project(bundletest) > > find_package(ZLIB REQUIRED) > find_package(Boost REQUIRED COMPONENTS filesystem) > > add_executable(bundletest main.cpp) > > target_include_directories(bundletest PRIVATE ${ZLIB_INCLUDE_DIRS} > ${Boost_INCLUDE_DIRS}) > > target_link_libraries(bundletest ${ZLIB_LIBRARIES} ${Boost_LIBRARIES}) > > install(TARGETS bundletest > RUNTIME DESTINATION "bin" > ) > > install(CODE " > function(gp_resolved_file_type_override resolved_file type_var) > set(\${type_var} local PARENT_SCOPE) > endfunction() > include(BundleUtilities) > fixup_bundle(\"\${CMAKE_INSTALL_PREFIX}/bin/bundletest\" \"\" \"\") > " COMPONENT Runtime) > > main.cpp: > > #include > #include > #include > > using namespace boost::filesystem; > > int main (int argc, char *argv[]) { > // Pretend we're using zlib and Boost > deflateInit(0, 0); > std::cout << file_size(argv[1]) << std::endl; > return 0; > } > > The overriding of the gp_resolved_file_type_override was necessary, to > make it treat all libraries as local (otherwise it skips "system" > libraries). See the docs for GetPrerequisites. > > Building/installing this with > > mkdir build > cd build > cmake -DCMAKE_INSTALL_PREFIX=~/bundletest_install .. > make install > > produces: > > /home/estan/bundletest_install > /home/estan/bundletest_install/bin > /home/estan/bundletest_install/bin/bundletest > /home/estan/bundletest_install/bin/libm.so.6 > /home/estan/bundletest_install/bin/libstdc++.so.6 > /home/estan/bundletest_install/bin/libc.so.6 > /home/estan/bundletest_install/bin/libz.so.1 > /home/estan/bundletest_install/bin/libpthread.so.0 > /home/estan/bundletest_install/bin/libboost_system.so.1.58.0 > /home/estan/bundletest_install/bin/libgcc_s.so.1 > /home/estan/bundletest_install/bin/libboost_filesystem.so.1.58.0 > > I did the build on Ubuntu, and tested that it also runs in a clean > Fedora 24 Docker container. > > Hope that helps some. > > Elvis > > [1] https://cmake.org/cmake/help/v3.9/command/file.html > >> >> Please, could you give me a hint? >> >> Regards >> Roman >> >>> Am 19.07.2017 um 12:40 schrieb Elvis Stansvik : >>> >>> 2017-07-19 10:24 GMT+02:00 Roman W?ger : >>>> Hello, >>>> >>>> I have a project which depends on a self compiled 3rd party project (boost) >>>> Boost is here only an example, there are other 3rd party libraries too. >>>> >>>> If I call the "install" command on the target, then it would be packaged. >>>> But how could I add the shared libraries and especially the links for the shared libraries? >>>> >>>> E.g.: >>>> libboost_filesystem.so -> libboost_filesystem.so.1.48.0 >>>> libboost_filesystem.so.1.48.0 >>>> >>>> Thanks in advance >>> >>> I think fixup_bundle() from BundleUtilities is what you want [1]. >>> >>> We're using it to make our Windows and macOS installs standalone, but >>> (I think) it should work on Linux as well. >>> >>> [1] https://cmake.org/cmake/help/v3.8/module/BundleUtilities.html >>> >>>> >>>> Best Regards >>>> Roman >>>> -- >>>> >>>> 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 From elvis.stansvik at orexplore.com Wed Jul 19 10:51:28 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Wed, 19 Jul 2017 16:51:28 +0200 Subject: [CMake] CPack install 3rd party shared libraries In-Reply-To: References: <84FEA0E6-A45E-4E79-85AA-84B8A643FD55@gmx.at> Message-ID: 2017-07-19 16:42 GMT+02:00 David Cole : > Very nice example. Does CMake have a place to put examples like VTK > does...? If so, where is it? And if not, it would be super useful to > start one somewhere "official." I guess the wiki is for that? Though I think my example should be cleaned up before being put up anywhere. > > However, one word of caution on the example. I know it was targeted at > Linux, and perhaps for a very simple case it's proper, but using an > unconditional "local" for everything in a > gp_resolved_file_type_override would not be something you'd want to do > in general, especially on Windows. You would end up with probably on > the order of a hundred (or maybe nowadays even a few hundred) DLLs > from the Windows system directories inside your bundle. Almost > certainly not what you intended. Yes, good point and I should have said something about that. My example was quick and dirty. In my real projects, I've so far always ended up with separate calls to fixup_bundle for the different platforms anyway (though never used fixup_bundle on Linux before), so I guess my mind was thinking "oh well, this is just for Linux" when I wrote it. Elvis > > > Cheers, > David C. > > > > On Wed, Jul 19, 2017 at 9:57 AM, Elvis Stansvik > wrote: >> 2017-07-19 13:42 GMT+02:00 Roman W?ger : >>> The problem with BundleUtilities which Inder is that it doesn't support generator expressions. >>> >>> Maybe I do something wrong? >>> But I need to specify the path to the executable (generator expression) and the paths where to look for dependencies. Right? >> >> You don't need to use a generator to fetch the executable path. You >> will know the path, since you installed the executable with >> install(..) :) I think most people essentially hardcode the executable >> path in their call to fixup_bundle(..). >> >> If you really want to, I think there is a way to use generator >> expressions, and that is to put the fixup_bundle(..) call in a >> separate file (say InstallStuff.cmake.in), and then process that file >> with file(GENERATE OUTPUT ...) [1] to produce InstallStuff.cmake with >> generator expressions evaluated and then use install(SCRIPT >> InstallStuff.cmake). But that's much too complicated IMHO, and I would >> avoid it. >> >> I made a minimal example that links against zlib and also the Boost >> library you mentioned: >> >> cmake_minimum_required(VERSION 2.8) >> >> project(bundletest) >> >> find_package(ZLIB REQUIRED) >> find_package(Boost REQUIRED COMPONENTS filesystem) >> >> add_executable(bundletest main.cpp) >> >> target_include_directories(bundletest PRIVATE ${ZLIB_INCLUDE_DIRS} >> ${Boost_INCLUDE_DIRS}) >> >> target_link_libraries(bundletest ${ZLIB_LIBRARIES} ${Boost_LIBRARIES}) >> >> install(TARGETS bundletest >> RUNTIME DESTINATION "bin" >> ) >> >> install(CODE " >> function(gp_resolved_file_type_override resolved_file type_var) >> set(\${type_var} local PARENT_SCOPE) >> endfunction() >> include(BundleUtilities) >> fixup_bundle(\"\${CMAKE_INSTALL_PREFIX}/bin/bundletest\" \"\" \"\") >> " COMPONENT Runtime) >> >> main.cpp: >> >> #include >> #include >> #include >> >> using namespace boost::filesystem; >> >> int main (int argc, char *argv[]) { >> // Pretend we're using zlib and Boost >> deflateInit(0, 0); >> std::cout << file_size(argv[1]) << std::endl; >> return 0; >> } >> >> The overriding of the gp_resolved_file_type_override was necessary, to >> make it treat all libraries as local (otherwise it skips "system" >> libraries). See the docs for GetPrerequisites. >> >> Building/installing this with >> >> mkdir build >> cd build >> cmake -DCMAKE_INSTALL_PREFIX=~/bundletest_install .. >> make install >> >> produces: >> >> /home/estan/bundletest_install >> /home/estan/bundletest_install/bin >> /home/estan/bundletest_install/bin/bundletest >> /home/estan/bundletest_install/bin/libm.so.6 >> /home/estan/bundletest_install/bin/libstdc++.so.6 >> /home/estan/bundletest_install/bin/libc.so.6 >> /home/estan/bundletest_install/bin/libz.so.1 >> /home/estan/bundletest_install/bin/libpthread.so.0 >> /home/estan/bundletest_install/bin/libboost_system.so.1.58.0 >> /home/estan/bundletest_install/bin/libgcc_s.so.1 >> /home/estan/bundletest_install/bin/libboost_filesystem.so.1.58.0 >> >> I did the build on Ubuntu, and tested that it also runs in a clean >> Fedora 24 Docker container. >> >> Hope that helps some. >> >> Elvis >> >> [1] https://cmake.org/cmake/help/v3.9/command/file.html >> >>> >>> Please, could you give me a hint? >>> >>> Regards >>> Roman >>> >>>> Am 19.07.2017 um 12:40 schrieb Elvis Stansvik : >>>> >>>> 2017-07-19 10:24 GMT+02:00 Roman W?ger : >>>>> Hello, >>>>> >>>>> I have a project which depends on a self compiled 3rd party project (boost) >>>>> Boost is here only an example, there are other 3rd party libraries too. >>>>> >>>>> If I call the "install" command on the target, then it would be packaged. >>>>> But how could I add the shared libraries and especially the links for the shared libraries? >>>>> >>>>> E.g.: >>>>> libboost_filesystem.so -> libboost_filesystem.so.1.48.0 >>>>> libboost_filesystem.so.1.48.0 >>>>> >>>>> Thanks in advance >>>> >>>> I think fixup_bundle() from BundleUtilities is what you want [1]. >>>> >>>> We're using it to make our Windows and macOS installs standalone, but >>>> (I think) it should work on Linux as well. >>>> >>>> [1] https://cmake.org/cmake/help/v3.8/module/BundleUtilities.html >>>> >>>>> >>>>> Best Regards >>>>> Roman >>>>> -- >>>>> >>>>> 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 From roman.wueger at gmx.at Wed Jul 19 13:13:45 2017 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Wed, 19 Jul 2017 19:13:45 +0200 Subject: [CMake] CPack install 3rd party shared libraries In-Reply-To: References: <84FEA0E6-A45E-4E79-85AA-84B8A643FD55@gmx.at> Message-ID: <024001d300b2$61a24700$24e6d500$@gmx.at> Thank you Elvis for the awesome example. Best Regards Roman -----Urspr?ngliche Nachricht----- Von: Elvis Stansvik [mailto:elvis.stansvik at orexplore.com] Gesendet: Mittwoch, 19. Juli 2017 16:51 An: David Cole Cc: Roman W?ger ; CMake MailingList Betreff: Re: [CMake] CPack install 3rd party shared libraries 2017-07-19 16:42 GMT+02:00 David Cole : > Very nice example. Does CMake have a place to put examples like VTK > does...? If so, where is it? And if not, it would be super useful to > start one somewhere "official." I guess the wiki is for that? Though I think my example should be cleaned up before being put up anywhere. > > However, one word of caution on the example. I know it was targeted at > Linux, and perhaps for a very simple case it's proper, but using an > unconditional "local" for everything in a > gp_resolved_file_type_override would not be something you'd want to do > in general, especially on Windows. You would end up with probably on > the order of a hundred (or maybe nowadays even a few hundred) DLLs > from the Windows system directories inside your bundle. Almost > certainly not what you intended. Yes, good point and I should have said something about that. My example was quick and dirty. In my real projects, I've so far always ended up with separate calls to fixup_bundle for the different platforms anyway (though never used fixup_bundle on Linux before), so I guess my mind was thinking "oh well, this is just for Linux" when I wrote it. Elvis > > > Cheers, > David C. > > > > On Wed, Jul 19, 2017 at 9:57 AM, Elvis Stansvik > wrote: >> 2017-07-19 13:42 GMT+02:00 Roman W?ger : >>> The problem with BundleUtilities which Inder is that it doesn't support generator expressions. >>> >>> Maybe I do something wrong? >>> But I need to specify the path to the executable (generator expression) and the paths where to look for dependencies. Right? >> >> You don't need to use a generator to fetch the executable path. You >> will know the path, since you installed the executable with >> install(..) :) I think most people essentially hardcode the >> executable path in their call to fixup_bundle(..). >> >> If you really want to, I think there is a way to use generator >> expressions, and that is to put the fixup_bundle(..) call in a >> separate file (say InstallStuff.cmake.in), and then process that file >> with file(GENERATE OUTPUT ...) [1] to produce InstallStuff.cmake with >> generator expressions evaluated and then use install(SCRIPT >> InstallStuff.cmake). But that's much too complicated IMHO, and I >> would avoid it. >> >> I made a minimal example that links against zlib and also the Boost >> library you mentioned: >> >> cmake_minimum_required(VERSION 2.8) >> >> project(bundletest) >> >> find_package(ZLIB REQUIRED) >> find_package(Boost REQUIRED COMPONENTS filesystem) >> >> add_executable(bundletest main.cpp) >> >> target_include_directories(bundletest PRIVATE ${ZLIB_INCLUDE_DIRS} >> ${Boost_INCLUDE_DIRS}) >> >> target_link_libraries(bundletest ${ZLIB_LIBRARIES} >> ${Boost_LIBRARIES}) >> >> install(TARGETS bundletest >> RUNTIME DESTINATION "bin" >> ) >> >> install(CODE " >> function(gp_resolved_file_type_override resolved_file type_var) >> set(\${type_var} local PARENT_SCOPE) >> endfunction() >> include(BundleUtilities) >> fixup_bundle(\"\${CMAKE_INSTALL_PREFIX}/bin/bundletest\" \"\" >> \"\") " COMPONENT Runtime) >> >> main.cpp: >> >> #include >> #include >> #include >> >> using namespace boost::filesystem; >> >> int main (int argc, char *argv[]) { >> // Pretend we're using zlib and Boost >> deflateInit(0, 0); >> std::cout << file_size(argv[1]) << std::endl; >> return 0; >> } >> >> The overriding of the gp_resolved_file_type_override was necessary, >> to make it treat all libraries as local (otherwise it skips "system" >> libraries). See the docs for GetPrerequisites. >> >> Building/installing this with >> >> mkdir build >> cd build >> cmake -DCMAKE_INSTALL_PREFIX=~/bundletest_install .. >> make install >> >> produces: >> >> /home/estan/bundletest_install >> /home/estan/bundletest_install/bin >> /home/estan/bundletest_install/bin/bundletest >> /home/estan/bundletest_install/bin/libm.so.6 >> /home/estan/bundletest_install/bin/libstdc++.so.6 >> /home/estan/bundletest_install/bin/libc.so.6 >> /home/estan/bundletest_install/bin/libz.so.1 >> /home/estan/bundletest_install/bin/libpthread.so.0 >> /home/estan/bundletest_install/bin/libboost_system.so.1.58.0 >> /home/estan/bundletest_install/bin/libgcc_s.so.1 >> /home/estan/bundletest_install/bin/libboost_filesystem.so.1.58.0 >> >> I did the build on Ubuntu, and tested that it also runs in a clean >> Fedora 24 Docker container. >> >> Hope that helps some. >> >> Elvis >> >> [1] https://cmake.org/cmake/help/v3.9/command/file.html >> >>> >>> Please, could you give me a hint? >>> >>> Regards >>> Roman >>> >>>> Am 19.07.2017 um 12:40 schrieb Elvis Stansvik : >>>> >>>> 2017-07-19 10:24 GMT+02:00 Roman W?ger : >>>>> Hello, >>>>> >>>>> I have a project which depends on a self compiled 3rd party >>>>> project (boost) Boost is here only an example, there are other 3rd party libraries too. >>>>> >>>>> If I call the "install" command on the target, then it would be packaged. >>>>> But how could I add the shared libraries and especially the links for the shared libraries? >>>>> >>>>> E.g.: >>>>> libboost_filesystem.so -> libboost_filesystem.so.1.48.0 >>>>> libboost_filesystem.so.1.48.0 >>>>> >>>>> Thanks in advance >>>> >>>> I think fixup_bundle() from BundleUtilities is what you want [1]. >>>> >>>> We're using it to make our Windows and macOS installs standalone, >>>> but (I think) it should work on Linux as well. >>>> >>>> [1] https://cmake.org/cmake/help/v3.8/module/BundleUtilities.html >>>> >>>>> >>>>> Best Regards >>>>> Roman >>>>> -- >>>>> >>>>> 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 From elvis.stansvik at orexplore.com Wed Jul 19 14:06:44 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Wed, 19 Jul 2017 20:06:44 +0200 Subject: [CMake] CPack install 3rd party shared libraries In-Reply-To: <025401d300b4$b4b91ca0$1e2b55e0$@gmx.at> References: <84FEA0E6-A45E-4E79-85AA-84B8A643FD55@gmx.at> <024001d300b2$61a24700$24e6d500$@gmx.at> <025401d300b4$b4b91ca0$1e2b55e0$@gmx.at> Message-ID: (Adding the mailing list back to the list of recepients - It's always good to keep the discussion on the list) 2017-07-19 19:30 GMT+02:00 Roman W?ger : > Hello Elvis, > > I tried you solution, but I get always the message: > > CMake Error at /opt/cmake-3.8.2-Linux-x86_64/share/cmake-3.8/Modules/BundleUtilities.cmake:956 (message): > error: fixup_bundle: not a valid bundle It would help to see your full CMake code. Was there no warning printed before this error? Something like "warning: *NOT* handled - " followed by an explanation? Elvis > > Regards > Roman > > -----Urspr?ngliche Nachricht----- > Von: CMake [mailto:cmake-bounces at cmake.org] Im Auftrag von Roman W?ger > Gesendet: Mittwoch, 19. Juli 2017 19:14 > An: 'Elvis Stansvik' > Cc: 'CMake MailingList' > Betreff: Re: [CMake] CPack install 3rd party shared libraries > > Thank you Elvis for the awesome example. > > Best Regards > Roman > > -----Urspr?ngliche Nachricht----- > Von: Elvis Stansvik [mailto:elvis.stansvik at orexplore.com] > Gesendet: Mittwoch, 19. Juli 2017 16:51 > An: David Cole > Cc: Roman W?ger ; CMake MailingList > Betreff: Re: [CMake] CPack install 3rd party shared libraries > > 2017-07-19 16:42 GMT+02:00 David Cole : >> Very nice example. Does CMake have a place to put examples like VTK >> does...? If so, where is it? And if not, it would be super useful to >> start one somewhere "official." > > I guess the wiki is for that? Though I think my example should be cleaned up before being put up anywhere. > >> >> However, one word of caution on the example. I know it was targeted at >> Linux, and perhaps for a very simple case it's proper, but using an >> unconditional "local" for everything in a >> gp_resolved_file_type_override would not be something you'd want to do >> in general, especially on Windows. You would end up with probably on >> the order of a hundred (or maybe nowadays even a few hundred) DLLs >> from the Windows system directories inside your bundle. Almost >> certainly not what you intended. > > Yes, good point and I should have said something about that. My example was quick and dirty. > > In my real projects, I've so far always ended up with separate calls to fixup_bundle for the different platforms anyway (though never used fixup_bundle on Linux before), so I guess my mind was thinking "oh well, this is just for Linux" when I wrote it. > > Elvis > >> >> >> Cheers, >> David C. >> >> >> >> On Wed, Jul 19, 2017 at 9:57 AM, Elvis Stansvik >> wrote: >>> 2017-07-19 13:42 GMT+02:00 Roman W?ger : >>>> The problem with BundleUtilities which Inder is that it doesn't support generator expressions. >>>> >>>> Maybe I do something wrong? >>>> But I need to specify the path to the executable (generator expression) and the paths where to look for dependencies. Right? >>> >>> You don't need to use a generator to fetch the executable path. You >>> will know the path, since you installed the executable with >>> install(..) :) I think most people essentially hardcode the >>> executable path in their call to fixup_bundle(..). >>> >>> If you really want to, I think there is a way to use generator >>> expressions, and that is to put the fixup_bundle(..) call in a >>> separate file (say InstallStuff.cmake.in), and then process that file >>> with file(GENERATE OUTPUT ...) [1] to produce InstallStuff.cmake with >>> generator expressions evaluated and then use install(SCRIPT >>> InstallStuff.cmake). But that's much too complicated IMHO, and I >>> would avoid it. >>> >>> I made a minimal example that links against zlib and also the Boost >>> library you mentioned: >>> >>> cmake_minimum_required(VERSION 2.8) >>> >>> project(bundletest) >>> >>> find_package(ZLIB REQUIRED) >>> find_package(Boost REQUIRED COMPONENTS filesystem) >>> >>> add_executable(bundletest main.cpp) >>> >>> target_include_directories(bundletest PRIVATE ${ZLIB_INCLUDE_DIRS} >>> ${Boost_INCLUDE_DIRS}) >>> >>> target_link_libraries(bundletest ${ZLIB_LIBRARIES} >>> ${Boost_LIBRARIES}) >>> >>> install(TARGETS bundletest >>> RUNTIME DESTINATION "bin" >>> ) >>> >>> install(CODE " >>> function(gp_resolved_file_type_override resolved_file type_var) >>> set(\${type_var} local PARENT_SCOPE) >>> endfunction() >>> include(BundleUtilities) >>> fixup_bundle(\"\${CMAKE_INSTALL_PREFIX}/bin/bundletest\" \"\" >>> \"\") " COMPONENT Runtime) >>> >>> main.cpp: >>> >>> #include >>> #include >>> #include >>> >>> using namespace boost::filesystem; >>> >>> int main (int argc, char *argv[]) { >>> // Pretend we're using zlib and Boost >>> deflateInit(0, 0); >>> std::cout << file_size(argv[1]) << std::endl; >>> return 0; >>> } >>> >>> The overriding of the gp_resolved_file_type_override was necessary, >>> to make it treat all libraries as local (otherwise it skips "system" >>> libraries). See the docs for GetPrerequisites. >>> >>> Building/installing this with >>> >>> mkdir build >>> cd build >>> cmake -DCMAKE_INSTALL_PREFIX=~/bundletest_install .. >>> make install >>> >>> produces: >>> >>> /home/estan/bundletest_install >>> /home/estan/bundletest_install/bin >>> /home/estan/bundletest_install/bin/bundletest >>> /home/estan/bundletest_install/bin/libm.so.6 >>> /home/estan/bundletest_install/bin/libstdc++.so.6 >>> /home/estan/bundletest_install/bin/libc.so.6 >>> /home/estan/bundletest_install/bin/libz.so.1 >>> /home/estan/bundletest_install/bin/libpthread.so.0 >>> /home/estan/bundletest_install/bin/libboost_system.so.1.58.0 >>> /home/estan/bundletest_install/bin/libgcc_s.so.1 >>> /home/estan/bundletest_install/bin/libboost_filesystem.so.1.58.0 >>> >>> I did the build on Ubuntu, and tested that it also runs in a clean >>> Fedora 24 Docker container. >>> >>> Hope that helps some. >>> >>> Elvis >>> >>> [1] https://cmake.org/cmake/help/v3.9/command/file.html >>> >>>> >>>> Please, could you give me a hint? >>>> >>>> Regards >>>> Roman >>>> >>>>> Am 19.07.2017 um 12:40 schrieb Elvis Stansvik : >>>>> >>>>> 2017-07-19 10:24 GMT+02:00 Roman W?ger : >>>>>> Hello, >>>>>> >>>>>> I have a project which depends on a self compiled 3rd party >>>>>> project (boost) Boost is here only an example, there are other 3rd party libraries too. >>>>>> >>>>>> If I call the "install" command on the target, then it would be packaged. >>>>>> But how could I add the shared libraries and especially the links for the shared libraries? >>>>>> >>>>>> E.g.: >>>>>> libboost_filesystem.so -> libboost_filesystem.so.1.48.0 >>>>>> libboost_filesystem.so.1.48.0 >>>>>> >>>>>> Thanks in advance >>>>> >>>>> I think fixup_bundle() from BundleUtilities is what you want [1]. >>>>> >>>>> We're using it to make our Windows and macOS installs standalone, >>>>> but (I think) it should work on Linux as well. >>>>> >>>>> [1] https://cmake.org/cmake/help/v3.8/module/BundleUtilities.html >>>>> >>>>>> >>>>>> Best Regards >>>>>> Roman >>>>>> -- >>>>>> >>>>>> 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 > > -- > > 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 roman.wueger at gmx.at Wed Jul 19 14:56:35 2017 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Wed, 19 Jul 2017 20:56:35 +0200 Subject: [CMake] CPack install 3rd party shared libraries In-Reply-To: References: <84FEA0E6-A45E-4E79-85AA-84B8A643FD55@gmx.at> <024001d300b2$61a24700$24e6d500$@gmx.at> <025401d300b4$b4b91ca0$1e2b55e0$@gmx.at> Message-ID: <026401d300c0$bf114fe0$3d33efa0$@gmx.at> Sorry for the MailingList thing, it was a reply mistake. So, here is the complete output: CPack: Enable Verbose CPack Verbose: Read CPack config file: CPack Verbose: Read CPack configuration file: /home/rowu/MyPackage/CPackConfig.cmake CPack Verbose: Specified generator: DEB CPack Verbose: Use generator: cmCPackDebGenerator CPack Verbose: For project: MyPackage CPack: Create package using DEB CPack Verbose: Read description file: /opt/cmake-3.8.2-Linux-x86_64/share/cmake-3.8/Templates/CPack.GenericDescription.txt CPack Verbose: [DEB] requested component grouping = ONE_PER_GROUP CPack Verbose: Remove toplevel directory: /home/rowu/MyPackage/_CPack_Packages/Linux/DEB CPack: Install projects CPack: - Run preinstall target for: MyPackage CPack: - Install project: MyPackage CPack Verbose: Install configuration: "Release" CPack Verbose: Installing: /home/rowu/MyPackage/_CPack_Packages/Linux/DEB/MyPackage-0.0.0.1499458629/opt/MyPackage-0.0.0.1499458629/./testprog CPack Verbose: Set runtime path of "/home/rowu/MyPackage/_CPack_Packages/Linux/DEB/MyPackage-0.0.0.1499458629/opt/MyPackage-0.0.0.1499458629/bin/testprog" to "" CPack Verbose: Installing: /home/rowu/MyPackage/_CPack_Packages/Linux/DEB/MyPackage-0.0.0.1499458629/opt/MyPackage-0.0.0.1499458629/./file1.dat CPack Verbose: Installing: /home/rowu/MyPackage/_CPack_Packages/Linux/DEB/MyPackage-0.0.0.1499458629/opt/MyPackage-0.0.0.1499458629/./file2.dat CPack Verbose: fixup_bundle CPack Verbose: app='/opt/MyPackage-0.0.0.1499458629/bin/testprog' CPack Verbose: libs='' CPack Verbose: dirs='/usr/local/lib' CPack Verbose: ignoreItems='' CPack Verbose: warning: *NOT* handled - directory/file does not exist... CMake Error at /opt/cmake-3.8.2-Linux-x86_64/share/cmake-3.8/Modules/BundleUtilities.cmake:956 (message): error: fixup_bundle: not a valid bundle Call Stack (most recent call first): /home/rowu/MyPackage/app/testprog/cmake_install.cmake:68 (fixup_bundle) /home/rowu/MyPackage/app/cmake_install.cmake:37 (include) /home/rowu/MyPackage/cmake_install.cmake:37 (include) CPack Verbose: fixup_bundle: done CPack Error: Error when generating package: MyPackage Regards Roman -----Urspr?ngliche Nachricht----- Von: Elvis Stansvik [mailto:elvis.stansvik at orexplore.com] Gesendet: Mittwoch, 19. Juli 2017 20:07 An: Roman W?ger ; CMake MailingList Betreff: Re: [CMake] CPack install 3rd party shared libraries (Adding the mailing list back to the list of recepients - It's always good to keep the discussion on the list) 2017-07-19 19:30 GMT+02:00 Roman W?ger < roman.wueger at gmx.at>: > Hello Elvis, > > I tried you solution, but I get always the message: > > CMake Error at /opt/cmake-3.8.2-Linux-x86_64/share/cmake-3.8/Modules/BundleUtilities.cmake:956 (message): > error: fixup_bundle: not a valid bundle It would help to see your full CMake code. Was there no warning printed before this error? Something like "warning: *NOT* handled - " followed by an explanation? Elvis > > Regards > Roman > > -----Urspr?ngliche Nachricht----- > Von: CMake [ mailto:cmake-bounces at cmake.org] Im Auftrag von Roman W?ger > Gesendet: Mittwoch, 19. Juli 2017 19:14 > An: 'Elvis Stansvik' < elvis.stansvik at orexplore.com> > Cc: 'CMake MailingList' < cmake at cmake.org> > Betreff: Re: [CMake] CPack install 3rd party shared libraries > > Thank you Elvis for the awesome example. > > Best Regards > Roman > > -----Urspr?ngliche Nachricht----- > Von: Elvis Stansvik [ mailto:elvis.stansvik at orexplore.com] > Gesendet: Mittwoch, 19. Juli 2017 16:51 > An: David Cole < DLRdave at aol.com> > Cc: Roman W?ger < roman.wueger at gmx.at>; CMake MailingList > < cmake at cmake.org> > Betreff: Re: [CMake] CPack install 3rd party shared libraries > > 2017-07-19 16:42 GMT+02:00 David Cole < DLRdave at aol.com>: >> Very nice example. Does CMake have a place to put examples like VTK >> does...? If so, where is it? And if not, it would be super useful to >> start one somewhere "official." > > I guess the wiki is for that? Though I think my example should be cleaned up before being put up anywhere. > >> >> However, one word of caution on the example. I know it was targeted >> at Linux, and perhaps for a very simple case it's proper, but using >> an unconditional "local" for everything in a >> gp_resolved_file_type_override would not be something you'd want to >> do in general, especially on Windows. You would end up with probably >> on the order of a hundred (or maybe nowadays even a few hundred) DLLs >> from the Windows system directories inside your bundle. Almost >> certainly not what you intended. > > Yes, good point and I should have said something about that. My example was quick and dirty. > > In my real projects, I've so far always ended up with separate calls to fixup_bundle for the different platforms anyway (though never used fixup_bundle on Linux before), so I guess my mind was thinking "oh well, this is just for Linux" when I wrote it. > > Elvis > >> >> >> Cheers, >> David C. >> >> >> >> On Wed, Jul 19, 2017 at 9:57 AM, Elvis Stansvik >> < elvis.stansvik at orexplore.com> wrote: >>> 2017-07-19 13:42 GMT+02:00 Roman W?ger < roman.wueger at gmx.at>: >>>> The problem with BundleUtilities which Inder is that it doesn't support generator expressions. >>>> >>>> Maybe I do something wrong? >>>> But I need to specify the path to the executable (generator expression) and the paths where to look for dependencies. Right? >>> >>> You don't need to use a generator to fetch the executable path. You >>> will know the path, since you installed the executable with >>> install(..) :) I think most people essentially hardcode the >>> executable path in their call to fixup_bundle(..). >>> >>> If you really want to, I think there is a way to use generator >>> expressions, and that is to put the fixup_bundle(..) call in a >>> separate file (say InstallStuff.cmake.in), and then process that >>> file with file(GENERATE OUTPUT ...) [1] to produce >>> InstallStuff.cmake with generator expressions evaluated and then use >>> install(SCRIPT InstallStuff.cmake). But that's much too complicated >>> IMHO, and I would avoid it. >>> >>> I made a minimal example that links against zlib and also the Boost >>> library you mentioned: >>> >>> cmake_minimum_required(VERSION 2.8) >>> >>> project(bundletest) >>> >>> find_package(ZLIB REQUIRED) >>> find_package(Boost REQUIRED COMPONENTS filesystem) >>> >>> add_executable(bundletest main.cpp) >>> >>> target_include_directories(bundletest PRIVATE ${ZLIB_INCLUDE_DIRS} >>> ${Boost_INCLUDE_DIRS}) >>> >>> target_link_libraries(bundletest ${ZLIB_LIBRARIES} >>> ${Boost_LIBRARIES}) >>> >>> install(TARGETS bundletest >>> RUNTIME DESTINATION "bin" >>> ) >>> >>> install(CODE " >>> function(gp_resolved_file_type_override resolved_file type_var) >>> set(\${type_var} local PARENT_SCOPE) >>> endfunction() >>> include(BundleUtilities) >>> fixup_bundle(\"\${CMAKE_INSTALL_PREFIX}/bin/bundletest\" \"\" >>> \"\") " COMPONENT Runtime) >>> >>> main.cpp: >>> >>> #include >>> #include >>> #include >>> >>> using namespace boost::filesystem; >>> >>> int main (int argc, char *argv[]) { >>> // Pretend we're using zlib and Boost >>> deflateInit(0, 0); >>> std::cout << file_size(argv[1]) << std::endl; >>> return 0; >>> } >>> >>> The overriding of the gp_resolved_file_type_override was necessary, >>> to make it treat all libraries as local (otherwise it skips "system" >>> libraries). See the docs for GetPrerequisites. >>> >>> Building/installing this with >>> >>> mkdir build >>> cd build >>> cmake -DCMAKE_INSTALL_PREFIX=~/bundletest_install .. >>> make install >>> >>> produces: >>> >>> /home/estan/bundletest_install >>> /home/estan/bundletest_install/bin >>> /home/estan/bundletest_install/bin/bundletest >>> /home/estan/bundletest_install/bin/libm.so.6 >>> /home/estan/bundletest_install/bin/libstdc++.so.6 >>> /home/estan/bundletest_install/bin/libc.so.6 >>> /home/estan/bundletest_install/bin/libz.so.1 >>> /home/estan/bundletest_install/bin/libpthread.so.0 >>> /home/estan/bundletest_install/bin/libboost_system.so.1.58.0 >>> /home/estan/bundletest_install/bin/libgcc_s.so.1 >>> /home/estan/bundletest_install/bin/libboost_filesystem.so.1.58.0 >>> >>> I did the build on Ubuntu, and tested that it also runs in a clean >>> Fedora 24 Docker container. >>> >>> Hope that helps some. >>> >>> Elvis >>> >>> [1] https://cmake.org/cmake/help/v3.9/command/file.html >>> >>>> >>>> Please, could you give me a hint? >>>> >>>> Regards >>>> Roman >>>> >>>>> Am 19.07.2017 um 12:40 schrieb Elvis Stansvik < elvis.stansvik at orexplore.com>: >>>>> >>>>> 2017-07-19 10:24 GMT+02:00 Roman W?ger < roman.wueger at gmx.at>: >>>>>> Hello, >>>>>> >>>>>> I have a project which depends on a self compiled 3rd party >>>>>> project (boost) Boost is here only an example, there are other 3rd party libraries too. >>>>>> >>>>>> If I call the "install" command on the target, then it would be packaged. >>>>>> But how could I add the shared libraries and especially the links for the shared libraries? >>>>>> >>>>>> E.g.: >>>>>> libboost_filesystem.so -> libboost_filesystem.so.1.48.0 >>>>>> libboost_filesystem.so.1.48.0 >>>>>> >>>>>> Thanks in advance >>>>> >>>>> I think fixup_bundle() from BundleUtilities is what you want [1]. >>>>> >>>>> We're using it to make our Windows and macOS installs standalone, >>>>> but (I think) it should work on Linux as well. >>>>> >>>>> [1] https://cmake.org/cmake/help/v3.8/module/BundleUtilities.html >>>>> >>>>>> >>>>>> Best Regards >>>>>> Roman >>>>>> -- >>>>>> >>>>>> 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 > > -- > > 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 rcdailey.lists at gmail.com Wed Jul 19 15:22:30 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Wed, 19 Jul 2017 14:22:30 -0500 Subject: [CMake] How to do platform specific setup? Message-ID: So in one of my top level CMake scripts, I have this: ``` if( ANDROID ) include( android ) _setup_android_platform() elseif( UNIX ) include( unix ) _setup_unix_platform() endif() if( CMAKE_CXX_COMPILER_ID STREQUAL "Clang" ) include( clang ) _setup_clang_toolchain() elseif( CMAKE_CXX_COMPILER_ID STREQUAL "MSVC" ) include( msvc ) _setup_msvc_toolchain() endif() ``` This allows me to set up various global things used by all targets defined by CMake. An example of what android's does: ``` macro( _setup_android_platform ) # Forward the android ABI from CMake to a custom variable for portability to other toolchains if( CMAKE_ANDROID_ARCH_ABI ) set( ANDROID_ABI ${CMAKE_ANDROID_ARCH_ABI} ) endif() # Forcefully disable testing while cross compiling for Android platform. It doesn't make sense # to build tests, since we can't run them natively. We build tests on a separate platform. set( BUILD_TESTING OFF CACHE BOOL "Do not build unit tests when cross compiling for Android" FORCE ) android_ndk_import_module_cpufeatures() android_ndk_import_module_native_app_glue() # Export ANativeActivity_onCreate(), # Refer to: https://github.com/android-ndk/ndk/issues/381. set( CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -u ANativeActivity_onCreate" ) add_definitions( -DANDROID ) endmacro() ``` And clang: ``` macro( _setup_clang_toolchain ) # Disable certain clang warnings # These spam like crazy; disable for now add_compile_options( -Wno-inconsistent-missing-override ) # Clang 3.8.0 on Ubuntu was failing with -Wno-expansion-to-defined. # Version 3.8.2 in NDK r14b seems ok with it. if( CMAKE_CXX_COMPILER_VERSION VERSION_GREATER_EQUAL 3.8.2 ) add_compile_options( -Wno-expansion-to-defined ) endif() set( CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -Wl,--no-undefined" ) endmacro() ``` I feel like there is a better way. I recall there being some built-in way to override CMake's platform specific setup modules, but I don't know anything about it. Can someone offer some advice on if there is a built in way to do this? From rcdailey.lists at gmail.com Wed Jul 19 17:04:47 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Wed, 19 Jul 2017 16:04:47 -0500 Subject: [CMake] file(COPY) is copying even if file hasn't changed Message-ID: According to the documentation for file(COPY) [1]: "Copying preserves input file timestamps, and optimizes out a file if it exists at the destination with the same timestamp" However this is not the case. My host OS is Windows 10 and I'm using CMake 3.9.0-rc5. Each time my CMakeLists.txt is run, the file(COPY) is copying over the file even if it didn't change. The "date modified" timestamp for the destination file is updated. I do not want the copy to occur if the source file has not changed (this appears to be the intended behavior based on the documentation). Am I understanding this correctly or is this a bug? [1]: https://cmake.org/cmake/help/latest/command/file.html From rcdailey.lists at gmail.com Wed Jul 19 17:05:39 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Wed, 19 Jul 2017 16:05:39 -0500 Subject: [CMake] file(COPY) is copying even if file hasn't changed In-Reply-To: References: Message-ID: Oh also file(INSTALL) does the same thing; the "Installing:" message gets printed each time for the same file, and never says that it is "up to date". On Wed, Jul 19, 2017 at 4:04 PM, Robert Dailey wrote: > According to the documentation for file(COPY) [1]: "Copying preserves > input file timestamps, and optimizes out a file if it exists at the > destination with the same timestamp" > > However this is not the case. My host OS is Windows 10 and I'm using > CMake 3.9.0-rc5. Each time my CMakeLists.txt is run, the file(COPY) is > copying over the file even if it didn't change. The "date modified" > timestamp for the destination file is updated. I do not want the copy > to occur if the source file has not changed (this appears to be the > intended behavior based on the documentation). > > Am I understanding this correctly or is this a bug? > > [1]: https://cmake.org/cmake/help/latest/command/file.html From elvis.stansvik at orexplore.com Thu Jul 20 01:39:11 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Thu, 20 Jul 2017 07:39:11 +0200 Subject: [CMake] CPack install 3rd party shared libraries In-Reply-To: <026401d300c0$bf114fe0$3d33efa0$@gmx.at> References: <84FEA0E6-A45E-4E79-85AA-84B8A643FD55@gmx.at> <024001d300b2$61a24700$24e6d500$@gmx.at> <025401d300b4$b4b91ca0$1e2b55e0$@gmx.at> <026401d300c0$bf114fe0$3d33efa0$@gmx.at> Message-ID: 2017-07-19 20:56 GMT+02:00 Roman W?ger : > Sorry for the MailingList thing, it was a reply mistake. > > > > So, here is the complete output: > > > > CPack: Enable Verbose > > CPack Verbose: Read CPack config file: > > CPack Verbose: Read CPack configuration file: > /home/rowu/MyPackage/CPackConfig.cmake > > CPack Verbose: Specified generator: DEB > > CPack Verbose: Use generator: cmCPackDebGenerator > > CPack Verbose: For project: MyPackage > > CPack: Create package using DEB > > CPack Verbose: Read description file: > /opt/cmake-3.8.2-Linux-x86_64/share/cmake-3.8/Templates/CPack.GenericDescription.txt > > CPack Verbose: [DEB] requested component grouping = ONE_PER_GROUP > > CPack Verbose: Remove toplevel directory: > /home/rowu/MyPackage/_CPack_Packages/Linux/DEB > > CPack: Install projects > > CPack: - Run preinstall target for: MyPackage > > CPack: - Install project: MyPackage > > CPack Verbose: Install configuration: "Release" > > CPack Verbose: Installing: > /home/rowu/MyPackage/_CPack_Packages/Linux/DEB/MyPackage-0.0.0.1499458629/opt/MyPackage-0.0.0.1499458629/./testprog > > CPack Verbose: Set runtime path of > "/home/rowu/MyPackage/_CPack_Packages/Linux/DEB/MyPackage-0.0.0.1499458629/opt/MyPackage-0.0.0.1499458629/bin/testprog" > to "" This is probably unrelated, but: These two paths look strange to me. One of them suggests you're installing the executable directly to ${CMAKE_INSTALL_PREFIX}, while the other suggests there's a ${CMAKE_INSTALL_PREFIX}/bin path involved as well. Anyway, see below. > > CPack Verbose: Installing: > /home/rowu/MyPackage/_CPack_Packages/Linux/DEB/MyPackage-0.0.0.1499458629/opt/MyPackage-0.0.0.1499458629/./file1.dat > > CPack Verbose: Installing: > /home/rowu/MyPackage/_CPack_Packages/Linux/DEB/MyPackage-0.0.0.1499458629/opt/MyPackage-0.0.0.1499458629/./file2.dat > > CPack Verbose: fixup_bundle > > CPack Verbose: app='/opt/MyPackage-0.0.0.1499458629/bin/testprog' > > CPack Verbose: libs='' > > CPack Verbose: dirs='/usr/local/lib' > > CPack Verbose: ignoreItems='' > > CPack Verbose: warning: *NOT* handled - directory/file does not exist... This means the executable path you passed in as the first argument to fixup_bundle(..) doesn't exist, and is why you get the error below. It would help to see your full CMake code (any CMakeLists.txt involved). Elvis > > CMake Error at > /opt/cmake-3.8.2-Linux-x86_64/share/cmake-3.8/Modules/BundleUtilities.cmake:956 > (message): > > error: fixup_bundle: not a valid bundle > > Call Stack (most recent call first): > > /home/rowu/MyPackage/app/testprog/cmake_install.cmake:68 (fixup_bundle) > > /home/rowu/MyPackage/app/cmake_install.cmake:37 (include) > > /home/rowu/MyPackage/cmake_install.cmake:37 (include) > > > > CPack Verbose: fixup_bundle: done > > CPack Error: Error when generating package: MyPackage > > > > > > Regards > > Roman > > > > -----Urspr?ngliche Nachricht----- > Von: Elvis Stansvik [mailto:elvis.stansvik at orexplore.com] > Gesendet: Mittwoch, 19. Juli 2017 20:07 > An: Roman W?ger ; CMake MailingList > > > Betreff: Re: [CMake] CPack install 3rd party shared libraries > > > > (Adding the mailing list back to the list of recepients - It's always good > to keep the discussion on the list) > > > > 2017-07-19 19:30 GMT+02:00 Roman W?ger : > >> Hello Elvis, > >> > >> I tried you solution, but I get always the message: > >> > >> CMake Error at >> /opt/cmake-3.8.2-Linux-x86_64/share/cmake-3.8/Modules/BundleUtilities.cmake:956 >> (message): > >> error: fixup_bundle: not a valid bundle > > > > It would help to see your full CMake code. > > > > Was there no warning printed before this error? Something like > > "warning: *NOT* handled - " followed by an explanation? > > > > Elvis > > > >> > >> Regards > >> Roman > >> > >> -----Urspr?ngliche Nachricht----- > >> Von: CMake [mailto:cmake-bounces at cmake.org] Im Auftrag von Roman W?ger > >> Gesendet: Mittwoch, 19. Juli 2017 19:14 > >> An: 'Elvis Stansvik' > >> Cc: 'CMake MailingList' > >> Betreff: Re: [CMake] CPack install 3rd party shared libraries > >> > >> Thank you Elvis for the awesome example. > >> > >> Best Regards > >> Roman > >> > >> -----Urspr?ngliche Nachricht----- > >> Von: Elvis Stansvik [mailto:elvis.stansvik at orexplore.com] > >> Gesendet: Mittwoch, 19. Juli 2017 16:51 > >> An: David Cole > >> Cc: Roman W?ger ; CMake MailingList > >> > >> Betreff: Re: [CMake] CPack install 3rd party shared libraries > >> > >> 2017-07-19 16:42 GMT+02:00 David Cole : > >>> Very nice example. Does CMake have a place to put examples like VTK > >>> does...? If so, where is it? And if not, it would be super useful to > >>> start one somewhere "official." > >> > >> I guess the wiki is for that? Though I think my example should be cleaned >> up before being put up anywhere. > >> > >>> > >>> However, one word of caution on the example. I know it was targeted > >>> at Linux, and perhaps for a very simple case it's proper, but using > >>> an unconditional "local" for everything in a > >>> gp_resolved_file_type_override would not be something you'd want to > >>> do in general, especially on Windows. You would end up with probably > >>> on the order of a hundred (or maybe nowadays even a few hundred) DLLs > >>> from the Windows system directories inside your bundle. Almost > >>> certainly not what you intended. > >> > >> Yes, good point and I should have said something about that. My example >> was quick and dirty. > >> > >> In my real projects, I've so far always ended up with separate calls to >> fixup_bundle for the different platforms anyway (though never used >> fixup_bundle on Linux before), so I guess my mind was thinking "oh well, >> this is just for Linux" when I wrote it. > >> > >> Elvis > >> > >>> > >>> > >>> Cheers, > >>> David C. > >>> > >>> > >>> > >>> On Wed, Jul 19, 2017 at 9:57 AM, Elvis Stansvik > >>> wrote: > >>>> 2017-07-19 13:42 GMT+02:00 Roman W?ger : > >>>>> The problem with BundleUtilities which Inder is that it doesn't support >>>>> generator expressions. > >>>>> > >>>>> Maybe I do something wrong? > >>>>> But I need to specify the path to the executable (generator expression) >>>>> and the paths where to look for dependencies. Right? > >>>> > >>>> You don't need to use a generator to fetch the executable path. You > >>>> will know the path, since you installed the executable with > >>>> install(..) :) I think most people essentially hardcode the > >>>> executable path in their call to fixup_bundle(..). > >>>> > >>>> If you really want to, I think there is a way to use generator > >>>> expressions, and that is to put the fixup_bundle(..) call in a > >>>> separate file (say InstallStuff.cmake.in), and then process that > >>>> file with file(GENERATE OUTPUT ...) [1] to produce > >>>> InstallStuff.cmake with generator expressions evaluated and then use > >>>> install(SCRIPT InstallStuff.cmake). But that's much too complicated > >>>> IMHO, and I would avoid it. > >>>> > >>>> I made a minimal example that links against zlib and also the Boost > >>>> library you mentioned: > >>>> > >>>> cmake_minimum_required(VERSION 2.8) > >>>> > >>>> project(bundletest) > >>>> > >>>> find_package(ZLIB REQUIRED) > >>>> find_package(Boost REQUIRED COMPONENTS filesystem) > >>>> > >>>> add_executable(bundletest main.cpp) > >>>> > >>>> target_include_directories(bundletest PRIVATE ${ZLIB_INCLUDE_DIRS} > >>>> ${Boost_INCLUDE_DIRS}) > >>>> > >>>> target_link_libraries(bundletest ${ZLIB_LIBRARIES} > >>>> ${Boost_LIBRARIES}) > >>>> > >>>> install(TARGETS bundletest > >>>> RUNTIME DESTINATION "bin" > >>>> ) > >>>> > >>>> install(CODE " > >>>> function(gp_resolved_file_type_override resolved_file type_var) > >>>> set(\${type_var} local PARENT_SCOPE) > >>>> endfunction() > >>>> include(BundleUtilities) > >>>> fixup_bundle(\"\${CMAKE_INSTALL_PREFIX}/bin/bundletest\" \"\" > >>>> \"\") " COMPONENT Runtime) > >>>> > >>>> main.cpp: > >>>> > >>>> #include > >>>> #include > >>>> #include > >>>> > >>>> using namespace boost::filesystem; > >>>> > >>>> int main (int argc, char *argv[]) { > >>>> // Pretend we're using zlib and Boost > >>>> deflateInit(0, 0); > >>>> std::cout << file_size(argv[1]) << std::endl; > >>>> return 0; > >>>> } > >>>> > >>>> The overriding of the gp_resolved_file_type_override was necessary, > >>>> to make it treat all libraries as local (otherwise it skips "system" > >>>> libraries). See the docs for GetPrerequisites. > >>>> > >>>> Building/installing this with > >>>> > >>>> mkdir build > >>>> cd build > >>>> cmake -DCMAKE_INSTALL_PREFIX=~/bundletest_install .. > >>>> make install > >>>> > >>>> produces: > >>>> > >>>> /home/estan/bundletest_install > >>>> /home/estan/bundletest_install/bin > >>>> /home/estan/bundletest_install/bin/bundletest > >>>> /home/estan/bundletest_install/bin/libm.so.6 > >>>> /home/estan/bundletest_install/bin/libstdc++.so.6 > >>>> /home/estan/bundletest_install/bin/libc.so.6 > >>>> /home/estan/bundletest_install/bin/libz.so.1 > >>>> /home/estan/bundletest_install/bin/libpthread.so.0 > >>>> /home/estan/bundletest_install/bin/libboost_system.so.1.58.0 > >>>> /home/estan/bundletest_install/bin/libgcc_s.so.1 > >>>> /home/estan/bundletest_install/bin/libboost_filesystem.so.1.58.0 > >>>> > >>>> I did the build on Ubuntu, and tested that it also runs in a clean > >>>> Fedora 24 Docker container. > >>>> > >>>> Hope that helps some. > >>>> > >>>> Elvis > >>>> > >>>> [1] https://cmake.org/cmake/help/v3.9/command/file.html > >>>> > >>>>> > >>>>> Please, could you give me a hint? > >>>>> > >>>>> Regards > >>>>> Roman > >>>>> > >>>>>> Am 19.07.2017 um 12:40 schrieb Elvis Stansvik >>>>>> : > >>>>>> > >>>>>> 2017-07-19 10:24 GMT+02:00 Roman W?ger : > >>>>>>> Hello, > >>>>>>> > >>>>>>> I have a project which depends on a self compiled 3rd party > >>>>>>> project (boost) Boost is here only an example, there are other 3rd >>>>>>> party libraries too. > >>>>>>> > >>>>>>> If I call the "install" command on the target, then it would be >>>>>>> packaged. > >>>>>>> But how could I add the shared libraries and especially the links for >>>>>>> the shared libraries? > >>>>>>> > >>>>>>> E.g.: > >>>>>>> libboost_filesystem.so -> libboost_filesystem.so.1.48.0 > >>>>>>> libboost_filesystem.so.1.48.0 > >>>>>>> > >>>>>>> Thanks in advance > >>>>>> > >>>>>> I think fixup_bundle() from BundleUtilities is what you want [1]. > >>>>>> > >>>>>> We're using it to make our Windows and macOS installs standalone, > >>>>>> but (I think) it should work on Linux as well. > >>>>>> > >>>>>> [1] https://cmake.org/cmake/help/v3.8/module/BundleUtilities.html > >>>>>> > >>>>>>> > >>>>>>> Best Regards > >>>>>>> Roman > >>>>>>> -- > >>>>>>> > >>>>>>> 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 > >> > >> -- > >> > >> 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 j.kreuzberger at procitec.de Thu Jul 20 04:15:17 2017 From: j.kreuzberger at procitec.de (=?utf-8?Q?J=C3=B6rg_Kreuzberger?=) Date: Thu, 20 Jul 2017 10:15:17 +0200 Subject: [CMake] CPack Multicore Usage Message-ID: Hi My Project is compiling multicore without any problems using Unix makefiles or ninja. In calls to cpack only one core is used if Makefiles are used. Is there any option to enable multicore? If i use ninja in cpack builds, the cpack build is broken, cause there seems no dependencies considered? Is ninja use in cpack intended? Or are there any contraints using ninja and cpack? Greetz, Joerg From kristianonline28 at gmail.com Thu Jul 20 04:39:12 2017 From: kristianonline28 at gmail.com (Kristian) Date: Thu, 20 Jul 2017 10:39:12 +0200 Subject: [CMake] Create user and group with CPack Message-ID: Hi, I create a RPM package with CPack. When installing this package on a target system, it should create an additional user and group. My current solution is a postinstall script, wich runs at the end of the installation. There, I added commands to create a user and a group (groupadd, useradd). But somehow, they aren't created when installing this RPM package. For testing, I install this RPM package in a docker container. I also tried, if these commands (groupadd, useradd) are working on the docker container and they are, so this shouldn't be a problem. So, how can I create a user and a group with CPack / CMake? From annulen at yandex.ru Thu Jul 20 04:32:49 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Thu, 20 Jul 2017 11:32:49 +0300 Subject: [CMake] CPack Multicore Usage In-Reply-To: References: Message-ID: <832321500539569@web20m.yandex.ru> 20.07.2017, 11:22, "J?rg Kreuzberger" : > Hi > > My Project is compiling multicore without any problems using Unix makefiles or ninja. > > In calls to cpack only one core is used if Makefiles are used. Is there any option to enable multicore? Yes, you should run make -jN, where N is a number of your cores or slightly larger > If i use ninja in cpack builds, the cpack build is broken, cause there seems no dependencies considered? > > Is ninja use in cpack intended? Or are there any contraints using ninja and cpack? > > Greetz, Joerg > > -- > > 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 eric.noulard at gmail.com Thu Jul 20 05:17:45 2017 From: eric.noulard at gmail.com (Eric Noulard) Date: Thu, 20 Jul 2017 11:17:45 +0200 Subject: [CMake] Create user and group with CPack In-Reply-To: References: Message-ID: 2017-07-20 10:39 GMT+02:00 Kristian : > Hi, > > I create a RPM package with CPack. When installing this package on a > target system, it should create an additional user and group. > > My current solution is a postinstall script, wich runs at the end of > the installation. There, I added commands to create a user and a group > (groupadd, useradd). But somehow, they aren't created when installing > this RPM package. Did you specify this post install script to CPackRPM? https://cmake.org/cmake/help/v3.7/module/CPackRPM.html#variable:CPACK_RPM_POST_INSTALL_SCRIPT_FILE You can check that the generated RPM does include the script with: rpm -qp --scripts .rpm > For testing, I install this RPM package in a docker > container. > > I also tried, if these commands (groupadd, useradd) are working on the > docker container and they are, so this shouldn't be a problem. > > So, how can I create a user and a group with CPack / 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 > -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From kristianonline28 at gmail.com Thu Jul 20 06:01:34 2017 From: kristianonline28 at gmail.com (Kristian) Date: Thu, 20 Jul 2017 12:01:34 +0200 Subject: [CMake] Create user and group with CPack In-Reply-To: References: Message-ID: Hi, thank you for your reply. Yes, I add the script with > set(CPACK_RPM_POST_INSTALL_SCRIPT_FILE "${CMAKE_CURRENT_SOURCE_DIR}/postinstall") and it basically works, because this file is changing a settings file without any problems. Only the add of the group and the user does not work, somehow. This is the part in the postinstall script, which should add group and user: ===== WEB_USER=web1 WEB_GROUP=web1 # create group groupadd "${WEB_GROUP}" --force --system # retrieve group id WEB_GROUP_ID="$(getent group '$WEB_GROUP' | cut -d: -f3)" echo "Group '${WEB_GROUP}' added with id '${WEB_GROUP_ID}'" # create user useradd "$WEB_USER" -g "${WEB_GROUP_ID}" -M -r -s /sbin/nologin -c "Web user - created during the installation." echo "User '${WEB_USER}' added." ===== And this is, what is being printed during installation: ===== Group 'web1' added with id '' useradd: group '' does not exist User 'web1' added. ===== 2017-07-20 11:17 GMT+02:00 Eric Noulard : > > > > 2017-07-20 10:39 GMT+02:00 Kristian : >> >> Hi, >> >> I create a RPM package with CPack. When installing this package on a >> target system, it should create an additional user and group. >> >> My current solution is a postinstall script, wich runs at the end of >> the installation. There, I added commands to create a user and a group >> (groupadd, useradd). But somehow, they aren't created when installing >> this RPM package. > > > Did you specify this post install script to CPackRPM? > https://cmake.org/cmake/help/v3.7/module/CPackRPM.html#variable:CPACK_RPM_POST_INSTALL_SCRIPT_FILE > > You can check that the generated RPM does include the script with: > > rpm -qp --scripts .rpm > >> >> For testing, I install this RPM package in a docker >> container. >> >> I also tried, if these commands (groupadd, useradd) are working on the >> docker container and they are, so this shouldn't be a problem. >> >> So, how can I create a user and a group with CPack / 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 > > > > > -- > Eric From eric.noulard at gmail.com Thu Jul 20 06:35:06 2017 From: eric.noulard at gmail.com (Eric Noulard) Date: Thu, 20 Jul 2017 12:35:06 +0200 Subject: [CMake] Create user and group with CPack In-Reply-To: References: Message-ID: 2017-07-20 12:01 GMT+02:00 Kristian : > Hi, > > thank you for your reply. Yes, I add the script with > > set(CPACK_RPM_POST_INSTALL_SCRIPT_FILE "${CMAKE_CURRENT_SOURCE_DIR}/ > postinstall") > > and it basically works, because this file is changing a settings file > without any problems. Only the add of the group and the user does not > work, somehow. > > This is the part in the postinstall script, which should add group and > user: > > ===== > WEB_USER=web1 > WEB_GROUP=web1 > > # create group > groupadd "${WEB_GROUP}" --force --system > # retrieve group id > WEB_GROUP_ID="$(getent group '$WEB_GROUP' | cut -d: -f3)" > echo "Group '${WEB_GROUP}' added with id '${WEB_GROUP_ID}'" > # create user > useradd "$WEB_USER" -g "${WEB_GROUP_ID}" -M -r -s /sbin/nologin -c > "Web user - created during the installation." > echo "User '${WEB_USER}' added." > ===== > > And this is, what is being printed during installation: > ===== > Group 'web1' added with id '' > useradd: group '' does not exist > User 'web1' added. > ===== > What is the shebang your ar using at the top of this script? this syntax: WEB_GROUP_ID="$(getent group '$WEB_GROUP' | cut -d: -f3)" may be bash only. not sure it makes a difference but you could try: WEB_GROUP_ID="$(getent group '${WEB_GROUP}' | cut -d: -f3)" note that getting the numeric group id seems unecessary. useradd "$WEB_USER" -g "${WEB_GROUP}" -M -r -s /sbin/nologin -c should work, useradd should work equally well with numeric or symbolic id of a group. -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From kristianonline28 at gmail.com Thu Jul 20 07:48:30 2017 From: kristianonline28 at gmail.com (Kristian) Date: Thu, 20 Jul 2017 13:48:30 +0200 Subject: [CMake] Create user and group with CPack In-Reply-To: References: Message-ID: Ok, I changed the postinstall script based on your suggestions: i.e. I changed these two lines: > WEB_GROUP_ID="$(getent group "${WEB_GROUP}" | cut -d: -f3)" and > useradd "$WEB_USER" -g "${WEB_GROUP}" -M -r -s /sbin/nologin -c And it worked now. Thank you for your help. :) 2017-07-20 12:35 GMT+02:00 Eric Noulard : > > > 2017-07-20 12:01 GMT+02:00 Kristian : >> >> Hi, >> >> thank you for your reply. Yes, I add the script with >> > set(CPACK_RPM_POST_INSTALL_SCRIPT_FILE >> > "${CMAKE_CURRENT_SOURCE_DIR}/postinstall") >> >> and it basically works, because this file is changing a settings file >> without any problems. Only the add of the group and the user does not >> work, somehow. >> >> This is the part in the postinstall script, which should add group and >> user: >> >> ===== >> WEB_USER=web1 >> WEB_GROUP=web1 >> >> # create group >> groupadd "${WEB_GROUP}" --force --system >> # retrieve group id >> WEB_GROUP_ID="$(getent group '$WEB_GROUP' | cut -d: -f3)" >> echo "Group '${WEB_GROUP}' added with id '${WEB_GROUP_ID}'" >> # create user >> useradd "$WEB_USER" -g "${WEB_GROUP_ID}" -M -r -s /sbin/nologin -c >> "Web user - created during the installation." >> echo "User '${WEB_USER}' added." >> ===== >> >> And this is, what is being printed during installation: >> ===== >> Group 'web1' added with id '' >> useradd: group '' does not exist >> User 'web1' added. >> ===== > > > What is the shebang your ar using at the top of this script? > > this syntax: > WEB_GROUP_ID="$(getent group '$WEB_GROUP' | cut -d: -f3)" > > may be bash only. > > not sure it makes a difference but you could try: > > WEB_GROUP_ID="$(getent group '${WEB_GROUP}' | cut -d: -f3)" > > note that getting the numeric group id seems unecessary. > > useradd "$WEB_USER" -g "${WEB_GROUP}" -M -r -s /sbin/nologin -c > > should work, useradd should work equally well with numeric or symbolic id of > a group. > > > -- > Eric From eric.noulard at gmail.com Thu Jul 20 08:45:19 2017 From: eric.noulard at gmail.com (Eric Noulard) Date: Thu, 20 Jul 2017 14:45:19 +0200 Subject: [CMake] Create user and group with CPack In-Reply-To: References: Message-ID: 2017-07-20 13:48 GMT+02:00 Kristian : > Ok, I changed the postinstall script based on your suggestions: > > i.e. I changed these two lines: > > WEB_GROUP_ID="$(getent group "${WEB_GROUP}" | cut -d: -f3)" > and > > useradd "$WEB_USER" -g "${WEB_GROUP}" -M -r -s /sbin/nologin -c > > And it worked now. Thank you for your help. :) > You are welcome. As you may have guessed the first line WEB_GROUP_ID="$(getent group "${WEB_GROUP}" | cut -d: -f3)" may be suppressed if useradd "$WEB_USER" -g "${WEB_GROUP}" -M -r -s /sbin/nologin -c is OK. -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Thu Jul 20 09:59:46 2017 From: brad.king at kitware.com (Brad King) Date: Thu, 20 Jul 2017 09:59:46 -0400 Subject: [CMake] [cmake-developers] Best way to append "--no-undefined" to shared link flags? In-Reply-To: References: Message-ID: On 07/18/2017 04:52 PM, Robert Dailey wrote: > set( CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} > -Wl,--no-undefined" ) That's fine, but you can use `string(APPEND)` to shorten the code: string(APPEND CMAKE_SHARED_LINKER_FLAGS " -Wl,--no-undefined") > After talking more with the NDK devs on github though, they seem to > indicate this should happen by default (or at least, it does with the > CMake that ships with the NDK according to Dan Albert). I don't think the NDK build system itself did that back when we first developed CMake's NDK support. It looks like their NDK-provided toolchain does do it by default, but with an option to turn it off. > Does --no-defined get specified by default for other platforms? > Or is it just Android that isn't getting it? CMake doesn't add --no-undefined by default on any platform. -Brad From rcdailey.lists at gmail.com Thu Jul 20 12:00:37 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Thu, 20 Jul 2017 11:00:37 -0500 Subject: [CMake] file(COPY) is copying even if file hasn't changed In-Reply-To: References: Message-ID: FYI I decided to file an issue for this here: https://gitlab.kitware.com/cmake/cmake/issues/17087 On Wed, Jul 19, 2017 at 4:05 PM, Robert Dailey wrote: > Oh also file(INSTALL) does the same thing; the "Installing:" message > gets printed each time for the same file, and never says that it is > "up to date". > > On Wed, Jul 19, 2017 at 4:04 PM, Robert Dailey wrote: >> According to the documentation for file(COPY) [1]: "Copying preserves >> input file timestamps, and optimizes out a file if it exists at the >> destination with the same timestamp" >> >> However this is not the case. My host OS is Windows 10 and I'm using >> CMake 3.9.0-rc5. Each time my CMakeLists.txt is run, the file(COPY) is >> copying over the file even if it didn't change. The "date modified" >> timestamp for the destination file is updated. I do not want the copy >> to occur if the source file has not changed (this appears to be the >> intended behavior based on the documentation). >> >> Am I understanding this correctly or is this a bug? >> >> [1]: https://cmake.org/cmake/help/latest/command/file.html From ndevenish at gmail.com Thu Jul 20 12:52:27 2017 From: ndevenish at gmail.com (Nicholas Devenish) Date: Thu, 20 Jul 2017 17:52:27 +0100 Subject: [CMake] file(COPY) is copying even if file hasn't changed In-Reply-To: References: Message-ID: For what it's worth, I'm not seeing this on Sierra 10.12.5, CMake 3.9.0 on a simple test case of: cmake_minimum_required(VERSION 3.5 FATAL_ERROR) file(COPY afile DESTINATION .) I ran through Instruments to check the otherwise silent copy, it copies the first time but thereafter only stat calls are ever made, the file timestamp stays matching the source, and even the INSTALL option also gives the "Up-to-date" message. It looks as though a chmod might be run, but that doesn't seem to affect the output stamp. So it must be something more complicated. Are you able to reduce the behaviour to a simple test-case? Completely wild guess: Are you running on something different from HFS, like APFS? If my reading of the chmod isn't wrong, I suppose *in theory* a different filesystem could treat a chmod attempt as a modification.... Nick On Thu, Jul 20, 2017 at 5:00 PM, Robert Dailey wrote: > FYI I decided to file an issue for this here: > https://gitlab.kitware.com/cmake/cmake/issues/17087 > > On Wed, Jul 19, 2017 at 4:05 PM, Robert Dailey wrote: >> Oh also file(INSTALL) does the same thing; the "Installing:" message >> gets printed each time for the same file, and never says that it is >> "up to date". >> >> On Wed, Jul 19, 2017 at 4:04 PM, Robert Dailey wrote: >>> According to the documentation for file(COPY) [1]: "Copying preserves >>> input file timestamps, and optimizes out a file if it exists at the >>> destination with the same timestamp" >>> >>> However this is not the case. My host OS is Windows 10 and I'm using >>> CMake 3.9.0-rc5. Each time my CMakeLists.txt is run, the file(COPY) is >>> copying over the file even if it didn't change. The "date modified" >>> timestamp for the destination file is updated. I do not want the copy >>> to occur if the source file has not changed (this appears to be the >>> intended behavior based on the documentation). >>> >>> Am I understanding this correctly or is this a bug? >>> >>> [1]: https://cmake.org/cmake/help/latest/command/file.html > -- > > 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 eldlistmailingz at tropicsoft.com Thu Jul 20 16:57:00 2017 From: eldlistmailingz at tropicsoft.com (Edward Diener) Date: Thu, 20 Jul 2017 16:57:00 -0400 Subject: [CMake] Referencing an OBJECT library Message-ID: According to the CMake docs for an OBJECT library called, let's say, 'xxx', the reference to that OBJECT library is through $. I understand this but I am curious about the reason for such syntax. After all a STATIC or SHARED library 'xxx' you can just use xxx to refer to the library. Why the difference in CMake syntax reference between OBJECT libraries added with the add_library command and STATIC or SHARED libraries added with the add_library command ? From alexvilchansky at yahoo.com Fri Jul 21 13:01:16 2017 From: alexvilchansky at yahoo.com (Oleksii Vilchanskyi) Date: Fri, 21 Jul 2017 19:01:16 +0200 Subject: [CMake] POSITION_INDEPENDENT_CODE's [un]expected behaviour Message-ID: Hello, I would like to ask about POSITION_INDEPENDENT_CODE target property. As of CMake 3.8.2 POSITION_INDEPENDENT_CODE appends -fPIE or -fPIC to CMAKE__FLAGS and CMAKE_EXE_LINKER_FLAGS when building an executable or a library respectively. However, to build a PIE -pie linker flag is additionally required. Thus POSITION_INDEPENDENT_CODE is not behaving as expected being a really easy to fix for someone aware with CMake codebase. Is there any reason why it wasn't added when the property was introduced? Somebody proposed introducing POSITION_INDEPENDENT_EXECUTABLE later on in addition to POSITION_INDEPENDENT_CODE to maintain backwards compatibility (I suppose policies are also a solution?). This email is the result of the thread and the message by Juan Navarro (big thanks to him), which fully summarizes CMake's POSITION_INDEPENDENT_CODE treatment and links to multiple bugs: this one , so far without attention, and this one , resolved for Android. Thank you. Regards, Oleksii Vilchanskyi -------------- next part -------------- An HTML attachment was scrubbed... URL: From chuck.atkins at kitware.com Fri Jul 21 15:29:38 2017 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Fri, 21 Jul 2017 15:29:38 -0400 Subject: [CMake] CPack Multicore Usage In-Reply-To: <832321500539569@web20m.yandex.ru> References: <832321500539569@web20m.yandex.ru> Message-ID: > > In calls to cpack only one core is used if Makefiles are used. Is there > any option to enable multicore? > It depends on what your trying to achieve. Typically the bottleneck for CPack is in the compression step of the resulting tar (or rpm, etc.). In that case, CMake is limited by the libarchive, libz, libbz2, liblzma, etc. implementations it's linked to, which are typically single threaded. It's really no different than taking an install tree and running "tar -czf foo.tgz /path/t/foo-prefix". So in that sense, even if you can parallelizes the "temporary" install step where it collects the files to packages, actually generating and compressing the package, which is the costly part, will likely remain a single process. -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidklind at gmail.com Fri Jul 21 19:55:22 2017 From: davidklind at gmail.com (DKLind) Date: Fri, 21 Jul 2017 16:55:22 -0700 (MST) Subject: [CMake] CPack: Create debian packge for each sub-project Message-ID: <1500681322140-7595889.post@n2.nabble.com> I have a large project and I need to create a Debian package for each sub-project (essentially each add_subdirectory). I have been experimenting with CPack components as outlined here: https://cmake.org/cmake/help/v3.8/module/CPackComponent.html?highlight=cpack_components_grouping#variable:CPACK_COMPONENTS_GROUPING I haven't been able to get any CPACK_DEBIAN__PACKAGE_XXX variables to work. I've been using the syntax CPACK_DEBIAN_${PROJECT_NAME}_PACKAGE_XXX. I'm calling install as: install(TARGETS ${PROGRAM_NAME} DESTINATION lib COMPONENT ${PROGRAM_NAME}) This way each sub-project is a unique component. I would expect that CPackConfig.cmake would contain an entry for each CPACK_DEBIAN__PACKAGE_XXX variable. But, I'm seeing only variables for the last sub-project that called "include(CPack)". Here are my requrements: 1. Each package must have a unique control file info (version, description, etc). 2. Each package filename must be ${PROGRAM_NAME}_${VERSION}_${ARCHITECTURE}.deb -- View this message in context: http://cmake.3232098.n2.nabble.com/CPack-Create-debian-packge-for-each-sub-project-tp7595889.html Sent from the CMake mailing list archive at Nabble.com. From domen.vrankar at gmail.com Fri Jul 21 20:18:57 2017 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Sat, 22 Jul 2017 02:18:57 +0200 Subject: [CMake] CPack: Create debian packge for each sub-project In-Reply-To: <1500681322140-7595889.post@n2.nabble.com> References: <1500681322140-7595889.post@n2.nabble.com> Message-ID: 2017-07-22 1:55 GMT+02:00 DKLind : > I have a large project and I need to create a Debian package for each > sub-project (essentially each add_subdirectory). > > I have been experimenting with CPack components as outlined here: > https://cmake.org/cmake/help/v3.8/module/CPackComponent. > html?highlight=cpack_components_grouping#variable: > CPACK_COMPONENTS_GROUPING > Debian packaging generator specific variables are described here: https://cmake.org/cmake/help/v3.8/module/CPackDeb.html > I haven't been able to get any CPACK_DEBIAN__PACKAGE_XXX > variables to work. I've been using the syntax > CPACK_DEBIAN_${PROJECT_NAME}_PACKAGE_XXX. > I'm guessing that ${PROJECT_NAME} contains lower case characters - (called in documentation) part of the variable name is supposed to be in upper case. > I'm calling install as: > install(TARGETS ${PROGRAM_NAME} DESTINATION lib COMPONENT ${PROGRAM_NAME}) > This way each sub-project is a unique component. > This looks fine. > I would expect that CPackConfig.cmake would contain an entry for each > CPACK_DEBIAN__PACKAGE_XXX variable. But, I'm seeing only > variables for the last sub-project that called "include(CPack)". > Only the top level CMakeLists.txt should call 'include(CPack)' and the rest of the CMakeLists.txt (if they can be used stand alone) should only call it if they are the base binary dir: if(CMAKE_CURRENT_BINARY_DIR STREQUAL CMAKE_BINARY_DIR) include(CPack) endif() The reason is that including this script generates CPackConfig.cmake and CPackSourceConfig.cmake files from already set variables. Here are my requrements: > 1. Each package must have a unique control file info (version, description, > etc). > Description part is not a problem but the version part is - currently only one version for all packages is used and can't be set per component. Using ExternalProject instead of subdirectories would be one solution, the other would be extending CPackDeb.cmake module (contribution would be welcome). > 2. Each package filename must be > ${PROGRAM_NAME}_${VERSION}_${ARCHITECTURE}.deb > For package names I'd suggest using: set(CPACK_DEBIAN_FILE_NAME "DEB-DEFAULT") to get the default deb package file name format but if you wish to use your naming convention you can set the per component version for each package. Regards, Domen -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Sat Jul 22 03:36:07 2017 From: craig.scott at crascit.com (Craig Scott) Date: Sat, 22 Jul 2017 17:36:07 +1000 Subject: [CMake] Append to property COMPILE_DEFINITIONS In-Reply-To: <62824131-1bbb-72f0-b7d3-454223ad2f4c@xgm.de> References: <54d1cf26-73f3-3fb1-9b17-ce459b7b6cb3@xgm.de> <5fb55910-c604-f279-4e07-9974724b72ce@xgm.de> <62824131-1bbb-72f0-b7d3-454223ad2f4c@xgm.de> Message-ID: On Tue, Jul 18, 2017 at 8:50 PM, Florian Lindner wrote: > #Works, but I would prefer to have it just once for all targets and at the > top of the file > set_property(TARGET testprecice APPEND > PROPERTY COMPILE_DEFINITIONS "FOO") > > > BTW, you don't include the -D when adding to COMPILE_DEFINITIONS, just > put FOO, not -DFOO. Have a read of the docs, they may give you other clues > for this property (e.g. using the ..._CONFIG variant of it). > > Yeah, I found out that I don't have to add -D. The docs say that generator > expressions are preferable to using _CONFIG > variant. > So just to be crystal clear, this is what I would have expected to work if you wanted the symbol FOO to be defined for Debug builds for all targets in the current directory and below: set_property(DIRECTORY APPEND PROPERTY COMPILE_DEFINITIONS $<$:FOO>) Note that this directory property is NOT used to initialise the corresponding target property. Rather, BOTH are combined to give the final set of command line compile definitions. It does not matter whether this directory property is set before or after you call add_executable() within the same CMakeLists.txt file (or more accurately, within the same directory scope). > > > > > On Tue, Jul 18, 2017 at 1:21 PM, Florian Lindner > wrote: > > > > Am 18.07.2017 um 10:59 schrieb Craig Scott: > > > You appear to be setting a GLOBAL property where you probably > meant DIRECTORY. You could also consider setting the > > > target property instead rather than applying it to all targets > (unless that's what you want). > > > > I tried to set the property on all targets, therefore I thought > GLOBAL is the right thing. > > > > However, > > > > set_property(DIRECTORY "${CMAKE_SOURCE_DIR}/src" APPEND > > PROPERTY COMPILE_DEFINITIONS "-DFOO") > > > > hasn't had any effect either. > > > > set_property(TARGET testprecice APPEND > > PROPERTY COMPILE_DEFINITIONS "FOO") > > > > works. But setting it on all targets is exactly what I want. How can > I do that? > > > > Best, > > Florian > > > > > > > > > > > On Tue, Jul 18, 2017 at 12:56 PM, Florian Lindner < > mailinglists at xgm.de > > >> wrote: > > > > > > Hello, > > > > > > I want to add compile definitions. Since I want to use > generator expressions, I can't use add_definitions, but > > have to > > > use the COMPILE_DEFINITIONS property, but neither: > > > > > > set_property(GLOBAL APPEND > > > PROPERTY COMPILE_DEFINITIONS "-DFOO") > > > > > > for testing > > > > > > or > > > > > > set_property(GLOBAL APPEND > > > PROPERTY COMPILE_DEFINITIONS $<$:-DDebug>) > > > > > > which should be final result, produces any -DFOO compiler > switches. > > > > > > I also tried placing it before and after the add_executable > call. > > > > > > What is wrong with that call? > > > > > > Thanks, > > > Florian > -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Sat Jul 22 04:38:08 2017 From: craig.scott at crascit.com (Craig Scott) Date: Sat, 22 Jul 2017 18:38:08 +1000 Subject: [CMake] POSITION_INDEPENDENT_CODE's [un]expected behaviour In-Reply-To: References: Message-ID: Thanks for the links. I've updated the relevant issue in gitlab and also added links to other related ones so that the full picture is captured more or less in one place. I'll ping the dev list to see if anyone has further updates or thoughts on the PIE picture for executables. From a very quick look, it may be non-trivial to get all compilers/platforms updated with the correct options and at least one issue talks about problems with QT and having PIE being enabled, but I'll defer to the dev list to provide further insights. You can see the updated issue with links here: https://gitlab.kitware.com/cmake/cmake/issues/14983 On Sat, Jul 22, 2017 at 3:01 AM, Oleksii Vilchanskyi via CMake < cmake at cmake.org> wrote: > Hello, > > I would like to ask about POSITION_INDEPENDENT_CODE target property. As > of CMake 3.8.2 POSITION_INDEPENDENT_CODE appends -fPIE or -fPIC to > CMAKE__FLAGS and CMAKE_EXE_LINKER_FLAGS when building an executable > or a library respectively. However, to build a PIE -pie linker flag is > additionally required. Thus POSITION_INDEPENDENT_CODE is not behaving as > expected being a really easy to fix for someone aware with CMake codebase. > > Is there any reason why it wasn't added when the property was introduced? > Somebody proposed introducing POSITION_INDEPENDENT_EXECUTABLE later on in > addition to POSITION_INDEPENDENT_CODE to maintain backwards compatibility > (I suppose policies are also a solution?). > > This email is the result of the thread > and the message > > by Juan Navarro (big thanks to him), which fully summarizes CMake's > POSITION_INDEPENDENT_CODE treatment and links to multiple bugs: this one > , so far without attention, and this > one , resolved for > Android. > > Thank you. > > Regards, > Oleksii Vilchanskyi > > -- > > 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 lectem at gmail.com Sat Jul 22 07:33:01 2017 From: lectem at gmail.com (lectem at gmail.com) Date: Sat, 22 Jul 2017 13:33:01 +0200 Subject: [CMake] INTERPROCEDURAL_OPTIMIZATION still not using CMAKE__COMPILER_AR In-Reply-To: References: Message-ID: <597337ee.c7331c0a.1dac4.a299@mx.google.com> Hello guys, So I downloaded the 3.9 release and thought my LTO nightmares were over but? cmake still isn?t using CMAKE__COMPILER_AR when linking?on MSYS. I?m using the ??MSYS Makefiles?? generator, and when building an executable it still uses the plain ar instead of gcc-ar? CMAKE_CXX_COMPILER_AR is correctly set to C:/msys64/mingw64/bin/gcc-ar.exe but won?t use it? I also tried to set CMAKE_AR to C:/msys64/mingw64/bin/gcc-ar.exe from cmake-gui but it?s not taken into account Here?s the output?: [100%] Linking CXX executable BoilerPlate.exe "/C/Program Files/CMake/bin/cmake.exe" -E remove -f CMakeFiles/BoilerPlate.dir/objects.a /C/msys64/mingw64/bin/ar.exe cr CMakeFiles/BoilerPlate.dir/objects.a @CMakeFiles/BoilerPlate.dir/objects1.rsp C:\msys64\mingw64\bin\ar.exe: CMakeFiles/BoilerPlate.dir/source/main.cpp.obj: plugin needed to handle lto object /C/msys64/mingw64/bin/g++.exe -flto -fno-fat-lto-objects -Wl,--whole-archive CMakeFiles/BoilerPlate.dir/objects.a -Wl,--no-whole-archive -o BoilerPlate.exe -Wl,--out-implib,libBoilerPlate.dll.a -Wl,--major-image-version,0,--minor-image-version,0 @CMakeFiles/BoilerPlate.dir/linklibs.rsp I?m not sure if it is a Windows/MSYS related problem (I think it is), but I really don?t understand why CMAKE wants to use C:/msys64/mingw64/bin/ar.exe so much and not the one in CMAKE_AR / CMAKE_CXX_COMPILER_AR? If you guys have any idea. Thanks, Lectem -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidklind at gmail.com Sun Jul 23 11:19:43 2017 From: davidklind at gmail.com (DKLind) Date: Sun, 23 Jul 2017 08:19:43 -0700 (MST) Subject: [CMake] CPack: Create debian packge for each sub-project In-Reply-To: References: <1500681322140-7595889.post@n2.nabble.com> Message-ID: <1500823183792-7595895.post@n2.nabble.com> Domen, Thanks for the reply to my question. I was aware of the Debian packaging generator page and I also was already setting the component value to uppercase. As documented, I had to use PARENT_SCOPE when setting CPACK_DEBIAN__PACKAGE_XXX values from sub-projects' CMakeLists.txt. Also, curious why CPACK_*COMPONENT*__DESCRIPTION is different from the other CPACK_*DEBIAN*__PACKAGE_XXX? With your help, I have individual packaging working now, except for unique version. I also realize that I would like to be able to set the contributor for some packages to be unique. I would like to contribute to CMake. I see the page https://cmake.org/gitweb?p=cmake.git;a=blob_plain;f=CONTRIBUTING.rst;hb=master. It mentions submitting contributions in patch form. Are pull requests also accepted? -- View this message in context: http://cmake.3232098.n2.nabble.com/CPack-Create-debian-packge-for-each-sub-project-tp7595889p7595895.html Sent from the CMake mailing list archive at Nabble.com. From rcdailey.lists at gmail.com Sun Jul 23 11:35:59 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Sun, 23 Jul 2017 10:35:59 -0500 Subject: [CMake] Boost is planning to switch from bjam to CMake! Message-ID: Very exciting news... hopefully it works out! Congratulations to CMake for this; this is huge support for CMake and shows it is becoming way more popular (not that it wasn't already!) https://lists.boost.org/boost-interest/2017/07/0162.php?utm_content=buffera6a82&utm_medium=social&utm_source=plus.google.com&utm_campaign=buffer From davidklind at gmail.com Sun Jul 23 11:37:35 2017 From: davidklind at gmail.com (DKLind) Date: Sun, 23 Jul 2017 08:37:35 -0700 (MST) Subject: [CMake] CPack: Create debian packge for each sub-project In-Reply-To: <1500823183792-7595895.post@n2.nabble.com> References: <1500681322140-7595889.post@n2.nabble.com> <1500823183792-7595895.post@n2.nabble.com> Message-ID: <1500824255449-7595897.post@n2.nabble.com> I forgot, I also have a question about "make package". How do I build and package just an individual sub-project. As expected, "make " works to build, but there isn't a default target to package an individual sub-project. -- View this message in context: http://cmake.3232098.n2.nabble.com/CPack-Create-debian-packge-for-each-sub-project-tp7595889p7595897.html Sent from the CMake mailing list archive at Nabble.com. From domen.vrankar at gmail.com Sun Jul 23 13:12:42 2017 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Sun, 23 Jul 2017 19:12:42 +0200 Subject: [CMake] CPack: Create debian packge for each sub-project In-Reply-To: <1500823183792-7595895.post@n2.nabble.com> References: <1500681322140-7595889.post@n2.nabble.com> <1500823183792-7595895.post@n2.nabble.com> Message-ID: 2017-07-23 17:19 GMT+02:00 DKLind : > Also, curious why CPACK_*COMPONENT*__DESCRIPTION is different > from the other CPACK_*DEBIAN*__PACKAGE_XXX? > Most variables are debian package specific/allow to override general CPack variables specifically for debian packages. For e.g. package description is set to: if CPACK_DEBIAN_PACKAGE_DESCRIPTION # debian specific override else if CPACK_PACKAGE_DESCRIPTION_SUMMARY # general package description There is no particular reason why per component version can't be overridden by a debian packager specific variable - you would usually want to have a single description for the same component no matter the package format (deb, rpm, ...). With your help, I have individual packaging working now, except for unique > version. I also realize that I would like to be able to set the contributor > for some packages to be unique. > Per component variable for these variables was not introduced since > I would like to contribute to CMake. I see the page > https://cmake.org/gitweb?p=cmake.git;a=blob_plain;f= > CONTRIBUTING.rst;hb=master. > It mentions submitting contributions in patch form. Are pull requests also > accepted? > As described in the link that you've provided create a gitlab account here: https://gitlab.kitware.com/cmake/cmake and create a merge request (gitlab equivalent to pull request on github). 2017-07-23 17:37 GMT+02:00 DKLind : > I forgot, I also have a question about "make package". How do I build and > package just an individual sub-project. As expected, "make " > works to build, but there isn't a default target to package an individual > sub-project. > You can set CPACK_COMPONENTS_ALL variable to contain only the components that you wish to package: set(CPACK_COMPONENTS_ALL applications libraries headers) By default it's set by CPack to contain all components. Regards, Domen -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggarra13 at gmail.com Sun Jul 23 16:13:57 2017 From: ggarra13 at gmail.com (=?UTF-8?Q?Gonzalo_Garramu=c3=b1o?=) Date: Sun, 23 Jul 2017 17:13:57 -0300 Subject: [CMake] CPack: Create debian packge for each sub-project In-Reply-To: <1500824255449-7595897.post@n2.nabble.com> References: <1500681322140-7595889.post@n2.nabble.com> <1500823183792-7595895.post@n2.nabble.com> <1500824255449-7595897.post@n2.nabble.com> Message-ID: <790164f4-ac2d-8b41-4a77-d00ab7737a6e@gmail.com> El 23/07/17 a las 12:37, DKLind escribi?: > I forgot, I also have a question about "make package". How do I build and > package just an individual sub-project. As expected, "make " > works to build, but there isn't a default target to package an individual > sub-project. AFAIK, it is not possible. I would also like to know this for separate packager generators. How to call "make package" on just one package generator (like build just DEB and not RPM). -- Gonzalo Garramu?o From craig.scott at crascit.com Sun Jul 23 17:10:37 2017 From: craig.scott at crascit.com (Craig Scott) Date: Mon, 24 Jul 2017 07:10:37 +1000 Subject: [CMake] CPack: Create debian packge for each sub-project In-Reply-To: <790164f4-ac2d-8b41-4a77-d00ab7737a6e@gmail.com> References: <1500681322140-7595889.post@n2.nabble.com> <1500823183792-7595895.post@n2.nabble.com> <1500824255449-7595897.post@n2.nabble.com> <790164f4-ac2d-8b41-4a77-d00ab7737a6e@gmail.com> Message-ID: On Mon, Jul 24, 2017 at 6:13 AM, Gonzalo Garramu?o wrote: > > > El 23/07/17 a las 12:37, DKLind escribi?: > >> I forgot, I also have a question about "make package". How do I build and >> package just an individual sub-project. As expected, "make " >> works to build, but there isn't a default target to package an individual >> sub-project. >> > AFAIK, it is not possible. I would also like to know this for separate > packager generators. How to call "make package" on just one package > generator (like build just DEB and not RPM). > > If you want to pick the package generator, run cpack directly rather than "make package". You'd need to manually run just "make" first to ensure the packaged targets are built. You may want/need other options too when using some CMake generators (e.g. -C for the build configuration with Xcode or Visual Studio most likely). make cpack -G RPM -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From boxerab at gmail.com Sun Jul 23 20:35:30 2017 From: boxerab at gmail.com (Aaron Boxer) Date: Sun, 23 Jul 2017 20:35:30 -0400 Subject: [CMake] Exception handling warning on windows Message-ID: Hello, I am getting the following warning when building my project on Visual Studio 14: warning C4530: C++ exception handler used, but unwind semantics are not enabled. Specify /EHsc Is there a cmake option to enable unwind semantics on windows ? Thanks, Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: From boxerab at gmail.com Sun Jul 23 21:06:15 2017 From: boxerab at gmail.com (Aaron Boxer) Date: Sun, 23 Jul 2017 21:06:15 -0400 Subject: [CMake] Exception handling warning on windows In-Reply-To: References: Message-ID: Never mind, figured it out :) IF(MSVC) SET(CMAKE_CXX_FLAGS "/EHsc") ENDIF(MSVC) On Sun, Jul 23, 2017 at 8:35 PM, Aaron Boxer wrote: > Hello, > > I am getting the following warning when building my project on Visual > Studio 14: > > warning C4530: C++ exception handler used, but unwind semantics are not > enabled. Specify /EHsc > > Is there a cmake option to enable unwind semantics on windows ? > > Thanks, > Aaron > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailinglists at xgm.de Sun Jul 23 22:32:03 2017 From: mailinglists at xgm.de (Florian Lindner) Date: Mon, 24 Jul 2017 10:32:03 +0800 Subject: [CMake] Append to property COMPILE_DEFINITIONS In-Reply-To: References: <54d1cf26-73f3-3fb1-9b17-ce459b7b6cb3@xgm.de> <5fb55910-c604-f279-4e07-9974724b72ce@xgm.de> <62824131-1bbb-72f0-b7d3-454223ad2f4c@xgm.de> Message-ID: Am 22.07.2017 um 15:36 schrieb Craig Scott: > > On Tue, Jul 18, 2017 at 8:50 PM, Florian Lindner > wrote: > > #Works, but I would prefer to have it just once for all targets and at the top of the file > set_property(TARGET testprecice APPEND > PROPERTY COMPILE_DEFINITIONS "FOO") > > > BTW, you don't include the -D when adding to COMPILE_DEFINITIONS, just put FOO, not -DFOO. Have a read of the docs, they may give you other clues for this property (e.g. using the ..._CONFIG variant of it). > > Yeah, I found out that I don't have to add -D. The docs say that generator expressions are preferable to using _CONFIG > variant. > > > So just to be crystal clear, this is what I would have expected to work if you wanted the symbol FOO to be defined for > Debug builds for all targets in the current directory and below: > > set_property(DIRECTORY APPEND PROPERTY COMPILE_DEFINITIONS $<$:FOO>) Put that in my CMakeLists.txt. Works, but only when I build in the same directory where the CMakeLists.txt file is located, i.e. in source builds. That way: set_property(DIRECTORY ${CMAKE_SOURCE_DIR} APPEND PROPERTY COMPILE_DEFINITIONS $<$:FOO>) it works also out of tree. Still, I don't undertand what is wrong with: set_property(GLOBAL APPEND PROPERTY COMPILE_DEFINITIONS $<$:-FOO>) ? Best, Florian > > Note that this directory property is NOT used to initialise the corresponding target property. Rather, BOTH are combined > to give the final set of command line compile definitions. It does not matter whether this directory property is set > before or after you call add_executable() within the same CMakeLists.txt file (or more accurately, within the same > directory scope). > > > > > > > > > On Tue, Jul 18, 2017 at 1:21 PM, Florian Lindner >> wrote: > > > > Am 18.07.2017 um 10:59 schrieb Craig Scott: > > > You appear to be setting a GLOBAL property where you probably meant DIRECTORY. You could also consider setting the > > > target property instead rather than applying it to all targets (unless that's what you want). > > > > I tried to set the property on all targets, therefore I thought GLOBAL is the right thing. > > > > However, > > > > set_property(DIRECTORY "${CMAKE_SOURCE_DIR}/src" APPEND > > PROPERTY COMPILE_DEFINITIONS "-DFOO") > > > > hasn't had any effect either. > > > > set_property(TARGET testprecice APPEND > > PROPERTY COMPILE_DEFINITIONS "FOO") > > > > works. But setting it on all targets is exactly what I want. How can I do that? > > > > Best, > > Florian > > > > > > > > > > > On Tue, Jul 18, 2017 at 12:56 PM, Florian Lindner > > > >>> wrote: > > > > > > Hello, > > > > > > I want to add compile definitions. Since I want to use generator expressions, I can't use add_definitions, but > > have to > > > use the COMPILE_DEFINITIONS property, but neither: > > > > > > set_property(GLOBAL APPEND > > > PROPERTY COMPILE_DEFINITIONS "-DFOO") > > > > > > for testing > > > > > > or > > > > > > set_property(GLOBAL APPEND > > > PROPERTY COMPILE_DEFINITIONS $<$:-DDebug>) > > > > > > which should be final result, produces any -DFOO compiler switches. > > > > > > I also tried placing it before and after the add_executable call. > > > > > > What is wrong with that call? > > > > > > Thanks, > > > Florian > > > -- > Craig Scott > Melbourne, Australia > https://crascit.com From bo.schwarzstein at gmail.com Mon Jul 24 00:03:34 2017 From: bo.schwarzstein at gmail.com (Bo Zhou) Date: Mon, 24 Jul 2017 13:03:34 +0900 Subject: [CMake] Boost is planning to switch from bjam to CMake! In-Reply-To: References: Message-ID: Good news ! Hopefully the bcp would also work with CMake so only requires component would be installed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From j.kreuzberger at procitec.de Mon Jul 24 04:07:14 2017 From: j.kreuzberger at procitec.de (=?utf-8?Q?J=C3=B6rg_Kreuzberger?=) Date: Mon, 24 Jul 2017 10:07:14 +0200 Subject: [CMake] =?utf-8?q?CPack_Multicore_Usage?= Message-ID: I think i had a wrong understanding of the cpack process itself. so i did a cmake configure and called cpack to build the software and generate the packages (deb, tgz) but better would be to configure, build with make -jx and then call cpack, cause cpack does not "rebuild" the software again, it uses the compiled software and just starts the "install" into its _CPack_Packages subdirectories Thank for your patience :-) -----Urspr?ngliche Nachricht----- Von: Chuck Atkins Gesendet: Fr 21.07.2017 21:32 Betreff: Re: [CMake] CPack Multicore Usage An: Konstantin Tokarev ; CC: J?rg Kreuzberger ; cmake at cmake.org; > ? > > In calls to cpack only one core is used if Makefiles are used. Is there any > option to enable multicore? > > It depends on what your trying to achieve.? Typically the bottleneck for CPack > is in the compression step of the resulting tar (or rpm, etc.).? In that case, > CMake is limited by the libarchive, libz, libbz2, liblzma, etc. implementations > it's linked to, which are typically single threaded.? It's really no different > than taking an install tree and running "tar -czf foo.tgz /path/t/foo-prefix".? > So in that sense, even if you can parallelizes the "temporary" install step > where it collects the files to packages, actually generating and compressing > the package, which is the costly part, will likely remain a single process. > > > > From victor.lamoine at institutmaupertuis.fr Mon Jul 24 05:23:30 2017 From: victor.lamoine at institutmaupertuis.fr (Victor Lamoine) Date: Mon, 24 Jul 2017 11:23:30 +0200 Subject: [CMake] How do I specify VTK minimum version? In-Reply-To: <2517bc18-50d1-cfca-59c5-1ee0805c3fa8@institutmaupertuis.fr> References: <2517bc18-50d1-cfca-59c5-1ee0805c3fa8@institutmaupertuis.fr> Message-ID: Hello, I am still stuck with this problem, I don't understand what's wrong. Is my question unclear? Do I not provide enough information? Please ask for additional information if I forgot something. Bye From ndevenish at gmail.com Mon Jul 24 05:46:19 2017 From: ndevenish at gmail.com (Nicholas Devenish) Date: Mon, 24 Jul 2017 10:46:19 +0100 Subject: [CMake] "Modern" approach to optional/multiple configurations? Message-ID: Seen in the boost discussions on the CMake announcements: > > The rest can be implemented straightforwardly as cache options so that > > you can run cmake with options like > > > > -Dvalgrind=OFF -Dtransactional-memory=ON -Dsegmented-stacks=ON [-D?] > ... Secondly, in cmake 3 we try not to configure things using -D as we did > in cmake 2. Instead we make targets customised for that build > combination. The user then chooses to make or link to those targets if > they want those targets. > Is this true, and is there a good example of a project with such a configuration? I've been trying to learn the more modern approaches to writing CMakeLists recently, and haven't come across such advice - I was under the impression that cache-set options (that the build can make decisions on) was still the recommended 'clean' way, and then options (and even extra sources, dependencies) can be added to each target as required. As I imagine what this is saying, It seems that target-per-configuration would just lead to an explosion of duplicated targets and duplicated code, especially through every permutation of several different options? Part of the niceness of target-oriented dependencies was just having one thing to link to and depending on the configuration, that target would be the correct one (and pass through it's configuration). Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: From eike at sf-mail.de Mon Jul 24 06:23:48 2017 From: eike at sf-mail.de (Rolf Eike Beer) Date: Mon, 24 Jul 2017 12:23:48 +0200 Subject: [CMake] How do I specify VTK minimum version? In-Reply-To: <2517bc18-50d1-cfca-59c5-1ee0805c3fa8@institutmaupertuis.fr> References: <2517bc18-50d1-cfca-59c5-1ee0805c3fa8@institutmaupertuis.fr> Message-ID: <2483289.AM3RLOqoUM@daneel.sf-tec.de> Am Dienstag, 11. Juli 2017, 15:18:11 schrieb Victor Lamoine: > Hi, > > I am using CMake to set up a VTK project. Our project requires VTK to be > version 7.1 or newer. I'm using Ubuntu 16.04 with CMake 3.5.1. > > find_package(VTK 7.1 REQUIRED) [?] > The following configuration files were considered but not accepted: > > /usr/local/lib/cmake/vtk-8.0/VTKConfig.cmake, version: 8.0.0 > /usr/lib/cmake/vtk-6.2/VTKConfig.cmake, version: 6.2.0 > > I have also tried find_package(VTK 7.1*.0* REQUIRED), without success. > > Why isn't VTK 8.0.0 accepted? It is a greater version number so I expected > it to be ok. How do I specify that I want VTK 7.1 OR newer? It could be that VTK sets in it's config file "same major version" compatibility. Eike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part. URL: From elvis.stansvik at orexplore.com Mon Jul 24 06:54:04 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Mon, 24 Jul 2017 12:54:04 +0200 Subject: [CMake] How do I specify VTK minimum version? In-Reply-To: <2483289.AM3RLOqoUM@daneel.sf-tec.de> References: <2517bc18-50d1-cfca-59c5-1ee0805c3fa8@institutmaupertuis.fr> <2483289.AM3RLOqoUM@daneel.sf-tec.de> Message-ID: 2017-07-24 12:23 GMT+02:00 Rolf Eike Beer : > Am Dienstag, 11. Juli 2017, 15:18:11 schrieb Victor Lamoine: >> Hi, >> >> I am using CMake to set up a VTK project. Our project requires VTK to be >> version 7.1 or newer. I'm using Ubuntu 16.04 with CMake 3.5.1. >> > >> find_package(VTK 7.1 REQUIRED) > [?] >> The following configuration files were considered but not accepted: >> >> /usr/local/lib/cmake/vtk-8.0/VTKConfig.cmake, version: 8.0.0 >> /usr/lib/cmake/vtk-6.2/VTKConfig.cmake, version: 6.2.0 >> >> I have also tried find_package(VTK 7.1*.0* REQUIRED), without success. >> >> Why isn't VTK 8.0.0 accepted? It is a greater version number so I expected >> it to be ok. How do I specify that I want VTK 7.1 OR newer? > > It could be that VTK sets in it's config file "same major version" > compatibility. Indeed. This comment from VTKConfigVersion.cmake explains it: # The created file sets PACKAGE_VERSION_EXACT if the current version string and # the requested version string are exactly the same and it sets # PACKAGE_VERSION_COMPATIBLE if the current version is >= requested version, # but only if the requested major version is the same as the current one. Elvis > > Eike > -- > > 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 mike.jackson at bluequartz.net Mon Jul 24 09:00:22 2017 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Mon, 24 Jul 2017 09:00:22 -0400 Subject: [CMake] Boost is planning to switch from bjam to CMake! In-Reply-To: References: Message-ID: <5975EF66.3050406@bluequartz.net> Let's hope this try actually works. It was tried 8 years ago but some of the boost developers really fought the transition. Hopefully with the support of the steering committee it will work. Let's all welcome the boost devs into the CMake community with wide open arms. -- Mike Jackson [mike.jackson at bluequartz.net] Bo Zhou wrote: > Good news ! > > Hopefully the bcp would also work with CMake so only requires component > would be installed. > From craig.scott at crascit.com Mon Jul 24 09:03:01 2017 From: craig.scott at crascit.com (Craig Scott) Date: Mon, 24 Jul 2017 23:03:01 +1000 Subject: [CMake] Append to property COMPILE_DEFINITIONS In-Reply-To: References: <54d1cf26-73f3-3fb1-9b17-ce459b7b6cb3@xgm.de> <5fb55910-c604-f279-4e07-9974724b72ce@xgm.de> <62824131-1bbb-72f0-b7d3-454223ad2f4c@xgm.de> Message-ID: On Mon, Jul 24, 2017 at 12:32 PM, Florian Lindner wrote: > > > Am 22.07.2017 um 15:36 schrieb Craig Scott: > > > > On Tue, Jul 18, 2017 at 8:50 PM, Florian Lindner > wrote: > > > > #Works, but I would prefer to have it just once for all targets and > at the top of the file > > set_property(TARGET testprecice APPEND > > PROPERTY COMPILE_DEFINITIONS "FOO") > > > > > BTW, you don't include the -D when adding to COMPILE_DEFINITIONS, > just put FOO, not -DFOO. Have a read of the docs, they may give you other > clues for this property (e.g. using the ..._CONFIG variant of it). > > > > Yeah, I found out that I don't have to add -D. The docs say that > generator expressions are preferable to using _CONFIG > > variant. > > > > > > So just to be crystal clear, this is what I would have expected to work > if you wanted the symbol FOO to be defined for > > Debug builds for all targets in the current directory and below: > > > > set_property(DIRECTORY APPEND PROPERTY COMPILE_DEFINITIONS > $<$:FOO>) > > Put that in my CMakeLists.txt. Works, but only when I build in the same > directory where the CMakeLists.txt file is > located, i.e. in source builds. That way: > > set_property(DIRECTORY ${CMAKE_SOURCE_DIR} APPEND PROPERTY > COMPILE_DEFINITIONS $<$:FOO>) > > it works also out of tree. > Not sure why you had to do that, but at least you found a way to get it to work. There's probably something in your directory structure or something else I'm not seeing which is causing the appearance of this directory property to only work if you set it for the top of your source tree. > > Still, I don't undertand what is wrong with: > > set_property(GLOBAL APPEND PROPERTY COMPILE_DEFINITIONS > $<$:-FOO>) > Properties can be defined with an INHERITED option . If a directory property is defined with that option, then if you try to get the directory property's value but it is not set, then CMake will look for a global property with the same name instead and return that value. In this case though, the COMPILE_DEFINITIONS directory property does not behave as though it was defined with the INHERITED option, so you don't get that fallback behaviour. I'm not sure if any of CMake's predefined properties behave as though they supported INHERITED, but doing a quick test just now confirms that it isn't supported for COMPILE_DEFINITIONS at least. Note that properties like COMPILE_DEFINITIONS are set up internally within CMake's C++ code, not via modules where the define_property() command would be relevant. I mention it here just so you get the full picture in case you see the fallback behaviour somewhere else and wonder why it doesn't apply here. > > > Note that this directory property is NOT used to initialise the > corresponding target property. Rather, BOTH are combined > > to give the final set of command line compile definitions. It does not > matter whether this directory property is set > > before or after you call add_executable() within the same CMakeLists.txt > file (or more accurately, within the same > > directory scope). > > > > > > > > > > > > > > > On Tue, Jul 18, 2017 at 1:21 PM, Florian Lindner < > mailinglists at xgm.de mailinglists at xgm.de >> wrote: > > > > > > Am 18.07.2017 um 10:59 schrieb Craig Scott: > > > > You appear to be setting a GLOBAL property where you > probably meant DIRECTORY. You could also consider setting the > > > > target property instead rather than applying it to all > targets (unless that's what you want). > > > > > > I tried to set the property on all targets, therefore I > thought GLOBAL is the right thing. > > > > > > However, > > > > > > set_property(DIRECTORY "${CMAKE_SOURCE_DIR}/src" APPEND > > > PROPERTY COMPILE_DEFINITIONS "-DFOO") > > > > > > hasn't had any effect either. > > > > > > set_property(TARGET testprecice APPEND > > > PROPERTY COMPILE_DEFINITIONS "FOO") > > > > > > works. But setting it on all targets is exactly what I want. > How can I do that? > > > > > > Best, > > > Florian > > > > > > > > > > > > > > > On Tue, Jul 18, 2017 at 12:56 PM, Florian Lindner < > mailinglists at xgm.de mailinglists at xgm.de > > > > > >>> wrote: > > > > > > > > Hello, > > > > > > > > I want to add compile definitions. Since I want to use > generator expressions, I can't use add_definitions, but > > > have to > > > > use the COMPILE_DEFINITIONS property, but neither: > > > > > > > > set_property(GLOBAL APPEND > > > > PROPERTY COMPILE_DEFINITIONS "-DFOO") > > > > > > > > for testing > > > > > > > > or > > > > > > > > set_property(GLOBAL APPEND > > > > PROPERTY COMPILE_DEFINITIONS > $<$:-DDebug>) > > > > > > > > which should be final result, produces any -DFOO > compiler switches. > > > > > > > > I also tried placing it before and after the > add_executable call. > > > > > > > > What is wrong with that call? > > > > -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidklind at gmail.com Mon Jul 24 10:30:40 2017 From: davidklind at gmail.com (DKLind) Date: Mon, 24 Jul 2017 07:30:40 -0700 (MST) Subject: [CMake] CPack: Create debian packge for each sub-project In-Reply-To: References: <1500681322140-7595889.post@n2.nabble.com> <1500823183792-7595895.post@n2.nabble.com> Message-ID: <1500906640142-7595912.post@n2.nabble.com> Here's a little trick I learned. Executing the custom target, "make package_target target=xyz", will build the target and call cpack to create the package. Additional parameters can be passed by putting the target value in quotes (make package_target target="xyz -j4"). Executing cpack causes the target to be built. But, if you want to see the output of make, before cpack, "COMMAND make ${PARAMS}" will do that. set(PARAMS "$(if $(target),$(target))" ) string(REPLACE " " ";" PARAMS ${PARAMS}) add_custom_target(package_target COMMAND make ${PARAMS} COMMAND cpack -D CPACK_COMPONENTS_ALL=${PARAMS} ) -- View this message in context: http://cmake.3232098.n2.nabble.com/CPack-Create-debian-packge-for-each-sub-project-tp7595889p7595912.html Sent from the CMake mailing list archive at Nabble.com. From ndevenish at gmail.com Mon Jul 24 10:40:35 2017 From: ndevenish at gmail.com (Nicholas Devenish) Date: Mon, 24 Jul 2017 15:40:35 +0100 Subject: [CMake] "Modern" approach to optional/multiple configurations? In-Reply-To: References: Message-ID: Hi Again, I was asked to link to the background discussion for this (good point!). The actual post was: https://lists.boost.org/Archives/boost/2017/07/237490.php and there's quite a bit of talk in that thread and a few similarly-named others about CMake. This announcement seems to have stirred up some old/new controversies, and I'm pretty sure there is a decent amount of misunderstanding/old assumptions about CMake. I was just rather taken back by this statement because I've been trying to research "Modern" CMake and hadn't encountered anything like this. Perhaps I'm merely imagining something wildly different from the intention. Nick On Mon, Jul 24, 2017 at 7:46 PM, Nicholas Devenish > wrote: > >> Seen in the boost discussions on the CMake announcements: >> >> >>> > The rest can be implemented straightforwardly as cache options so that >>> > you can run cmake with options like >>> > >>> > -Dvalgrind=OFF -Dtransactional-memory=ON -Dsegmented-stacks=ON [-D?] >>> ... >> >> Secondly, in cmake 3 we try not to configure things using -D as we did >>> in cmake 2. Instead we make targets customised for that build >>> combination. The user then chooses to make or link to those targets if >>> they want those targets. >>> >> >> Is this true, and is there a good example of a project with such a >> configuration? >> >> I've been trying to learn the more modern approaches to writing >> CMakeLists recently, and haven't come across such advice - I was under the >> impression that cache-set options (that the build can make decisions on) >> was still the recommended 'clean' way, and then options (and even extra >> sources, dependencies) can be added to each target as required. >> >> As I imagine what this is saying, It seems that target-per-configuration >> would just lead to an explosion of duplicated targets and duplicated code, >> especially through every permutation of several different options? >> >> Part of the niceness of target-oriented dependencies was just having one >> thing to link to and depending on the configuration, that target would be >> the correct one (and pass through it's configuration). >> >> Nick >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From victor.lamoine at institutmaupertuis.fr Mon Jul 24 10:52:21 2017 From: victor.lamoine at institutmaupertuis.fr (Victor Lamoine) Date: Mon, 24 Jul 2017 16:52:21 +0200 Subject: [CMake] How do I specify VTK minimum version? In-Reply-To: References: <2517bc18-50d1-cfca-59c5-1ee0805c3fa8@institutmaupertuis.fr> <2483289.AM3RLOqoUM@daneel.sf-tec.de> Message-ID: <12a6c9df-297e-202b-2b1f-58c5e1b2b152@institutmaupertuis.fr> Thank you for the answers. I used this script to fix my problem: find_package(VTK 7.1.0 QUIET) if (NOT VTK_FOUND) find_package(VTK 8.0.0 REQUIRED) endif() include(${VTK_USE_FILE}) Of course this will only work until there is a VTK 9.x.x version. From DLRdave at aol.com Mon Jul 24 10:57:41 2017 From: DLRdave at aol.com (David Cole) Date: Mon, 24 Jul 2017 10:57:41 -0400 Subject: [CMake] How do I specify VTK minimum version? In-Reply-To: <12a6c9df-297e-202b-2b1f-58c5e1b2b152@institutmaupertuis.fr> References: <2517bc18-50d1-cfca-59c5-1ee0805c3fa8@institutmaupertuis.fr> <2483289.AM3RLOqoUM@daneel.sf-tec.de> <12a6c9df-297e-202b-2b1f-58c5e1b2b152@institutmaupertuis.fr> Message-ID: You don't have to ask for a specific version. You can just do: find_package(VTK REQUIRED) if you don't really care what version is found. Or if you need >= 7, you can do it like that and then check what version was actually found, and error out yourself if it is too old. HTH, David C. On Mon, Jul 24, 2017 at 10:52 AM, Victor Lamoine wrote: > Thank you for the answers. > > I used this script to fix my problem: > > find_package(VTK 7.1.0 QUIET) > if (NOT VTK_FOUND) > find_package(VTK 8.0.0 REQUIRED) > endif() > include(${VTK_USE_FILE}) > > Of course this will only work until there is a VTK 9.x.x version. > > -- > > 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 chuck.atkins at kitware.com Mon Jul 24 12:48:58 2017 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Mon, 24 Jul 2017 12:48:58 -0400 Subject: [CMake] CPack Multicore Usage In-Reply-To: References: Message-ID: > > cause cpack does not "rebuild" the software again, it uses the compiled > software and just starts the "install" into its _CPack_Packages > subdirectories > Just running `cpack` does not. However, CMake does generate a "package" make target that is tied into your dependencies, so if instead of running `make -jN; cpack` you could also run 'make -jN package' which will run the build, since it's a dependency of the package target. - Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From bavay at slf.ch Tue Jul 25 06:08:13 2017 From: bavay at slf.ch (Mathias Bavay) Date: Tue, 25 Jul 2017 12:08:13 +0200 Subject: [CMake] CDash upgrade Message-ID: <0731b33d-6210-a5de-19c2-bc150606b5ab@slf.ch> Hi! I've just upgraded CDash from version 2.3.0 (git) to the latest git version (2.6 but reporting 2.5 on its front page). Everything worked, I see my projects and their configuration (icons, descriptions, etc) but no builds are shown... I've checked in the database itself, the table cdash/build is full of data (ie builds) but they don't shown up in cdash. What could be the reason? Thanks! Mathias From roman.wueger at gmx.at Tue Jul 25 11:43:03 2017 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Tue, 25 Jul 2017 17:43:03 +0200 Subject: [CMake] Signing of DEB and RPM packages Message-ID: Hello, is the signing of DEB packages (debsigs) and RPM packages (rpmsign or rpm --addsign) supported at the moment? Best Regards Roman From i.zaufi at gmail.com Tue Jul 25 12:11:45 2017 From: i.zaufi at gmail.com (Alex Turbov) Date: Tue, 25 Jul 2017 19:11:45 +0300 Subject: [CMake] How to install custom target Message-ID: Hi list, What is the "right" way to install a custom target, when you don't know the result file name? E.g. I have a sample project: cmake_minimum_required(VERSION 3.9) project(custom_target) add_custom_target( log ALL COMMAND ${CMAKE_COMMAND} -E environment > sample-$.log ) # install(... ??? ...) In a multi-configuration build, how can I get the resulting filename to use `install(FILES...)` (as it recommended by CMake wiki) ?? Or is there any other way to use `install()` (maybe `TARGETS`...) ? Best, -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Tue Jul 25 14:40:48 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Tue, 25 Jul 2017 14:40:48 -0400 Subject: [CMake] [cmake-developers] Signing of DEB and RPM packages In-Reply-To: References: Message-ID: <20170725184048.GA5482@megas.kitware.com> On Tue, Jul 25, 2017 at 17:43:03 +0200, Roman W?ger wrote: > is the signing of DEB packages (debsigs) and RPM packages (rpmsign or > rpm --addsign) supported at the moment? It doesn't appear to be supported right now (no results from grep'ing for "debsig" or "addsign"). --Ben From zack.galbreath at kitware.com Tue Jul 25 15:01:26 2017 From: zack.galbreath at kitware.com (Zack Galbreath) Date: Tue, 25 Jul 2017 15:01:26 -0400 Subject: [CMake] CDash upgrade In-Reply-To: <0731b33d-6210-a5de-19c2-bc150606b5ab@slf.ch> References: <0731b33d-6210-a5de-19c2-bc150606b5ab@slf.ch> Message-ID: On Tue, Jul 25, 2017 at 6:08 AM, Mathias Bavay wrote: > Hi! > > I've just upgraded CDash from version 2.3.0 (git) to the latest git > version (2.6 but reporting 2.5 on its front page). Everything worked, I see > my projects and their configuration (icons, descriptions, etc) but no > builds are shown... I've checked in the database itself, the table > cdash/build is full of data (ie builds) but they don't shown up in cdash. > What could be the reason? > This is most likely due to database schema changes. Go to CDash/upgrade.php and click the "Upgrade CDash" button. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.hoffman at kitware.com Tue Jul 25 17:19:54 2017 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Tue, 25 Jul 2017 17:19:54 -0400 Subject: [CMake] Kitware is hiring Message-ID: <5adefde2-8496-aea4-09c0-24d906475c20@kitware.com> Kitware is currently looking for a software developer in our Clifton Park NY office. We are looking for someone with C++ and CMake experience. Here is the job posting: https://www.smartrecruiters.com/kitware/743999656184083-software-developer Thanks. -Bill -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 bill.hoffman at kitware.com http://www.kitware.com 518 881-4905 (Direct) 518 371-3971 x105 Fax (518) 371-4573 From mario.werner at iaik.tugraz.at Wed Jul 26 11:29:20 2017 From: mario.werner at iaik.tugraz.at (Mario Werner) Date: Wed, 26 Jul 2017 17:29:20 +0200 Subject: [CMake] How to do platform specific setup? In-Reply-To: References: Message-ID: Hi Robert, I usually do all my platform and compiler specific customization in a toolchain file [1]. Such a toolchain file is more or less standard CMake script which get executed before the root CMakeLists.txt from the project is processed. When invoking cmake for the first time you simply specify which toolchain file you want to use by adding `-DCMAKE_TOOLCHAIN_FILE=` as parameter. Note that the idea of a toolchain file is that the file is customized exactly for your environment. Best regards, Mario [1] https://cmake.org/Wiki/CMake_Cross_Compiling#The_toolchain_file On 2017-07-19 21:22, Robert Dailey wrote: > So in one of my top level CMake scripts, I have this: > > ``` > if( ANDROID ) > include( android ) > _setup_android_platform() > elseif( UNIX ) > include( unix ) > _setup_unix_platform() > endif() > > if( CMAKE_CXX_COMPILER_ID STREQUAL "Clang" ) > include( clang ) > _setup_clang_toolchain() > elseif( CMAKE_CXX_COMPILER_ID STREQUAL "MSVC" ) > include( msvc ) > _setup_msvc_toolchain() > endif() > ``` > > This allows me to set up various global things used by all targets > defined by CMake. An example of what android's does: > > ``` > macro( _setup_android_platform ) > # Forward the android ABI from CMake to a custom variable for > portability to other toolchains > if( CMAKE_ANDROID_ARCH_ABI ) > set( ANDROID_ABI ${CMAKE_ANDROID_ARCH_ABI} ) > endif() > > # Forcefully disable testing while cross compiling for Android > platform. It doesn't make sense > # to build tests, since we can't run them natively. We build tests > on a separate platform. > set( BUILD_TESTING OFF CACHE BOOL "Do not build unit tests when > cross compiling for Android" FORCE ) > > android_ndk_import_module_cpufeatures() > android_ndk_import_module_native_app_glue() > > # Export ANativeActivity_onCreate(), > # Refer to: https://github.com/android-ndk/ndk/issues/381. > set( CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -u > ANativeActivity_onCreate" ) > > add_definitions( > -DANDROID > ) > endmacro() > ``` > > And clang: > > ``` > macro( _setup_clang_toolchain ) > # Disable certain clang warnings > # These spam like crazy; disable for now > add_compile_options( > -Wno-inconsistent-missing-override > ) > > # Clang 3.8.0 on Ubuntu was failing with -Wno-expansion-to-defined. > # Version 3.8.2 in NDK r14b seems ok with it. > if( CMAKE_CXX_COMPILER_VERSION VERSION_GREATER_EQUAL 3.8.2 ) > add_compile_options( > -Wno-expansion-to-defined > ) > endif() > > set( CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} > -Wl,--no-undefined" ) > endmacro() > ``` > > I feel like there is a better way. I recall there being some built-in > way to override CMake's platform specific setup modules, but I don't > know anything about it. Can someone offer some advice on if there is a > built in way to do this? > From rcdailey.lists at gmail.com Wed Jul 26 12:14:29 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Wed, 26 Jul 2017 11:14:29 -0500 Subject: [CMake] How to do platform specific setup? In-Reply-To: References: Message-ID: According to Brad King, toolchain files are not intended for what I'm asking about. I recall someone mentioning some built-in modules in CMake that are responsible for toolchain and platform setup, that can be overridden somehow. This is different from toolchain files AFAIK. I apologize for being vague, but I was hoping someone would recognize what I'm talking about. On Wed, Jul 26, 2017 at 10:29 AM, Mario Werner wrote: > Hi Robert, > > I usually do all my platform and compiler specific customization in a > toolchain file [1]. Such a toolchain file is more or less standard CMake > script which get executed before the root CMakeLists.txt from the > project is processed. When invoking cmake for the first time you simply > specify which toolchain file you want to use by adding > `-DCMAKE_TOOLCHAIN_FILE=` as parameter. > > Note that the idea of a toolchain file is that the file is customized > exactly for your environment. > > Best regards, > Mario > > > [1] https://cmake.org/Wiki/CMake_Cross_Compiling#The_toolchain_file > > On 2017-07-19 21:22, Robert Dailey wrote: >> So in one of my top level CMake scripts, I have this: >> >> ``` >> if( ANDROID ) >> include( android ) >> _setup_android_platform() >> elseif( UNIX ) >> include( unix ) >> _setup_unix_platform() >> endif() >> >> if( CMAKE_CXX_COMPILER_ID STREQUAL "Clang" ) >> include( clang ) >> _setup_clang_toolchain() >> elseif( CMAKE_CXX_COMPILER_ID STREQUAL "MSVC" ) >> include( msvc ) >> _setup_msvc_toolchain() >> endif() >> ``` >> >> This allows me to set up various global things used by all targets >> defined by CMake. An example of what android's does: >> >> ``` >> macro( _setup_android_platform ) >> # Forward the android ABI from CMake to a custom variable for >> portability to other toolchains >> if( CMAKE_ANDROID_ARCH_ABI ) >> set( ANDROID_ABI ${CMAKE_ANDROID_ARCH_ABI} ) >> endif() >> >> # Forcefully disable testing while cross compiling for Android >> platform. It doesn't make sense >> # to build tests, since we can't run them natively. We build tests >> on a separate platform. >> set( BUILD_TESTING OFF CACHE BOOL "Do not build unit tests when >> cross compiling for Android" FORCE ) >> >> android_ndk_import_module_cpufeatures() >> android_ndk_import_module_native_app_glue() >> >> # Export ANativeActivity_onCreate(), >> # Refer to: https://github.com/android-ndk/ndk/issues/381. >> set( CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -u >> ANativeActivity_onCreate" ) >> >> add_definitions( >> -DANDROID >> ) >> endmacro() >> ``` >> >> And clang: >> >> ``` >> macro( _setup_clang_toolchain ) >> # Disable certain clang warnings >> # These spam like crazy; disable for now >> add_compile_options( >> -Wno-inconsistent-missing-override >> ) >> >> # Clang 3.8.0 on Ubuntu was failing with -Wno-expansion-to-defined. >> # Version 3.8.2 in NDK r14b seems ok with it. >> if( CMAKE_CXX_COMPILER_VERSION VERSION_GREATER_EQUAL 3.8.2 ) >> add_compile_options( >> -Wno-expansion-to-defined >> ) >> endif() >> >> set( CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} >> -Wl,--no-undefined" ) >> endmacro() >> ``` >> >> I feel like there is a better way. I recall there being some built-in >> way to override CMake's platform specific setup modules, but I don't >> know anything about it. Can someone offer some advice on if there is a >> built in way to do 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 bavay at slf.ch Wed Jul 26 12:36:49 2017 From: bavay at slf.ch (Mathias Bavay) Date: Wed, 26 Jul 2017 18:36:49 +0200 Subject: [CMake] CDash upgrade In-Reply-To: References: <0731b33d-6210-a5de-19c2-bc150606b5ab@slf.ch> Message-ID: <3217d6ec-e529-b5a4-4df4-141418277c55@slf.ch> Hi! I did click on "Upgrade CDash", but that did not solve the problem. After some investigations, I realized that the table cdash.dynamicanalysissummary was missing (so the migration script did not create it or failed to do so for any other reason). Once I created it, everything worked. Mathias From chris at macolighting.com Wed Jul 26 23:30:30 2017 From: chris at macolighting.com (Christopher Broadbent) Date: Thu, 27 Jul 2017 13:30:30 +1000 Subject: [CMake] Android NDK, clang, and ODR violations Message-ID: <50de80a5-610a-4c90-320a-b8956dd00148@macolighting.com> I'm in the progress of updating some code to clang in the NDK (since they are not longer supporting GCC), and getting some ODR errors which seem to be caused by a bad link configuration. The generated executables / shared libraries seem to link to both the selected standard library, and libstdc++.so (android's minimal 'system' standard lib, not gcc's c++ standard lib). This causes multiple definitions of new/delete, triggering ODR warnings between 'libc++abi.a' and 'libstdc++.so' When using the gnustl_static, there's similar issues on the members of 'std::type_info', 'std::basic_string', and 'std::shared_ptr', but this is now between our code and 'libgnustl_static.a' (possibly a clang vs gcc code gen difference?) This happens in cmake 3.7.2 and cmake 3.8 Is anyone successfully using cmake + clang on android, or have an idea of where the configuration script might be wrong? Here is my reproduction: --- toolchain.cmake set(CMAKE_SYSTEM_NAME Android) set(CMAKE_SYSTEM_VERSION 19) set(CMAKE_ANDROID_ARCH_ABI armeabi-v7a) set(CMAKE_ANDROID_NDK_TOOLCHAIN_VERSION clang) set(CMAKE_ANDROID_STL_TYPE c++_static) --- CMakeLists.txt cmake_minimum_required(VERSION 3.7.2) cmake_policy(VERSION 3.7.2) project(reproduction) string(APPEND CMAKE_EXE_LINKER_FLAGS " -Wl,--detect-odr-violations") add_executable(main main.cpp) --- main.cpp #include int main() { std::cout << "hello, world!\n"; } --- Thanks, Chris From demelier.david at gmail.com Thu Jul 27 06:28:41 2017 From: demelier.david at gmail.com (David Demelier) Date: Thu, 27 Jul 2017 12:28:41 +0200 Subject: [CMake] Correct handling of absolute/relative installation paths Message-ID: <29c7445d-8c2c-9d05-9d40-9365c0805d0d@gmail.com> Hello, I'm still trying to find a correct solution to handle user specified installation paths. Let's consider two kind of paths: - WITH_BINDIR (default: bin/) where to install executables, - WITH_DATADIR (default: share/project_name/) where to install extra data. I want to let the user configuring those paths because not all distributions use the same paths (e.g. bin vs usr/bin). Then, I also like to build the whole CMake project by creating the hierarchy as it would be installed like: /WITH_BINDIR/myapp /WITH_DATADIR/somestuff.txt Using relative paths makes the application relocatable, if I keep WITH_BINDIR set as "bin" I can get the executable path at runtime, going through its parent (bin/../) and then I can go share/project_name. Obviously this is only valid for relative paths. However, a very high number of package managers build programs by specifying absolute paths, it is not an issue: instead of getting the directories at runtime, I use directly the absolute ones. On unix it can still work because it will just be translated as: /usr/local/bin/myapp /usr/local/share/project_name/somestuff.txt This is much bigger an issue on Windows if the user set WITH_BINDIR to something like D:/alt/bin The path would be translated to D:/alt/bin which is invalid on Windows. I like very much having this kind of `fakeroot' directory where you can have a preview on how the project looks like but I don't know what to do if paths are absolute, especially on Windows. What are your thoughts on that, recommandations? Regards, -- David Demelier From eric.noulard at gmail.com Thu Jul 27 07:08:54 2017 From: eric.noulard at gmail.com (Eric Noulard) Date: Thu, 27 Jul 2017 13:08:54 +0200 Subject: [CMake] Correct handling of absolute/relative installation paths In-Reply-To: <29c7445d-8c2c-9d05-9d40-9365c0805d0d@gmail.com> References: <29c7445d-8c2c-9d05-9d40-9365c0805d0d@gmail.com> Message-ID: 2017-07-27 12:28 GMT+02:00 David Demelier : > Hello, > > I'm still trying to find a correct solution to handle user specified > installation paths. > > Let's consider two kind of paths: > > - WITH_BINDIR (default: bin/) where to install executables, > - WITH_DATADIR (default: share/project_name/) where to install extra > data. > > I want to let the user configuring those paths because not all > distributions use the same paths (e.g. bin vs usr/bin). > > Then, I also like to build the whole CMake project by creating the > hierarchy as it would be installed like: > > /WITH_BINDIR/myapp > /WITH_DATADIR/somestuff.txt > Do you mean here that you setup CMAKE__OUTPUT_DIRECTORY (variable or target property) to your favorite value or You build and then install with the / prefix? > > Using relative paths makes the application relocatable, if I keep > WITH_BINDIR set as "bin" I can get the executable path at runtime, going > through its parent (bin/../) and then I can go share/project_name. > Obviously this is only valid for relative paths. > > However, a very high number of package managers build programs by > specifying absolute paths, it is not an issue: instead of getting the > directories at runtime, I use directly the absolute ones. > > On unix it can still work because it will just be translated as: > > /usr/local/bin/myapp > /usr/local/share/project_name/somestuff.txt > > This is much bigger an issue on Windows if the user set WITH_BINDIR to > something like D:/alt/bin > > The path would be translated to > > D:/alt/bin > > which is invalid on Windows. > > I like very much having this kind of `fakeroot' directory where you can > have a preview on how the project looks like but I don't know what to do if > paths are absolute, especially on Windows. > My opinion is that you should never use absolute path (besides some very specific case on unix where you want to put something in /etc/...) You should ask your user for DATADIR BINDIR etc... all those var should be relative path. and an eventual INSTALL_PREFIX which could be absolute. In any case if you really want to tolerate absolute path given by the user, but still want to mimic install location during the build then you'll have to escape it. For each path you expect from the user: check the path with if(IS_ABSOLUTE path) and compute some relative path a) if you are on Windows remove the drive letter, i.e. D:/alt/bin becomes alt/bin (or network drive share name //shairedisk/alt/bin becomes alt/bin) b) if you are on Unix > > What are your thoughts on that, recommandations? > I wouldn't try to mimic install tree during the build (if it is what you are doing), If I have a need to "verify" install tree structure then **after the build** I would do a fake install with a particular local prefix (as CPack does before packaging). Note that for similar reason CPack has to track files installed with absolute destination and possibly error out when it cannot handle it, particularly on Windows oriented generator: see e.g.: https://cmake.org/cmake/help/v3.7/variable/CPACK_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION.html AFAIK, IFW and NSIS do not work with, absolute installed files. -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Thu Jul 27 07:45:46 2017 From: d3ck0r at gmail.com (J Decker) Date: Thu, 27 Jul 2017 04:45:46 -0700 Subject: [CMake] Correct handling of absolute/relative installation paths In-Reply-To: References: <29c7445d-8c2c-9d05-9d40-9365c0805d0d@gmail.com> Message-ID: It's also handy to get installation paths from GNUInstallDirs https://cmake.org/cmake/help/v3.4/module/GNUInstallDirs.html especially if you expect to install libs on linux which either go to lib or lib64. many things that install to windows just supply a standard base path (/program files/) and then still use bin, lib, share, etc in that path... It is an annoyance to have to override dll installation to bin instead of lib on windows.... include( GNUInstallDirs ) if( WIN32 ) set( BINARY_OUTPUT_DIR ${CMAKE_INSTALL_BINDIR} ) set( SHARED_LIBRARY_OUTPUT_DIR ${CMAKE_INSTALL_BINDIR} ) set( SHARED_LIBRARY_LINK_DIR ${CMAKE_INSTALL_LIBDIR} ) else( WIN32 ) set( BINARY_OUTPUT_DIR ${CMAKE_INSTALL_BINDIR} ) set( SHARED_LIBRARY_OUTPUT_DIR ${CMAKE_INSTALL_LIBDIR} ) set( SHARED_LIBRARY_LINK_DIR ${CMAKE_INSTALL_LIBDIR} ) endif( WIN32 ) and then use the aliased path instead macro( install_my_thing ) install( TARGETS ${ARGV} RUNTIME DESTINATION ${BINARY_OUTPUT_DIR} LIBRARY DESTINATION ${SHARED_LIBRARY_OUTPUT_DIR} ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR} ) endmacro( install_my_thing ) People will inevitably also respond and say 'but dlls install as runtime' which is probably true these days. All I can do is copy the cmake stuff I have that definitely works; which has been around since 2.6 or something... So it's probably simpler than what I've shared above. On Thu, Jul 27, 2017 at 4:08 AM, Eric Noulard wrote: > > > 2017-07-27 12:28 GMT+02:00 David Demelier : > >> Hello, >> >> I'm still trying to find a correct solution to handle user specified >> installation paths. >> >> Let's consider two kind of paths: >> >> - WITH_BINDIR (default: bin/) where to install executables, >> - WITH_DATADIR (default: share/project_name/) where to install extra >> data. >> >> I want to let the user configuring those paths because not all >> distributions use the same paths (e.g. bin vs usr/bin). >> >> Then, I also like to build the whole CMake project by creating the >> hierarchy as it would be installed like: >> >> /WITH_BINDIR/myapp >> /WITH_DATADIR/somestuff.txt >> > > Do you mean here that you setup CMAKE__OUTPUT_DIRECTORY (variable or > target property) to your favorite value > or > You build and then install with the / prefix? > > >> >> Using relative paths makes the application relocatable, if I keep >> WITH_BINDIR set as "bin" I can get the executable path at runtime, going >> through its parent (bin/../) and then I can go share/project_name. >> Obviously this is only valid for relative paths. >> >> However, a very high number of package managers build programs by >> specifying absolute paths, it is not an issue: instead of getting the >> directories at runtime, I use directly the absolute ones. >> >> On unix it can still work because it will just be translated as: >> >> /usr/local/bin/myapp >> /usr/local/share/project_name/somestuff.txt >> >> This is much bigger an issue on Windows if the user set WITH_BINDIR to >> something like D:/alt/bin >> >> The path would be translated to >> >> D:/alt/bin >> >> which is invalid on Windows. >> >> I like very much having this kind of `fakeroot' directory where you can >> have a preview on how the project looks like but I don't know what to do if >> paths are absolute, especially on Windows. >> > > My opinion is that you should never use absolute path (besides some very > specific case on unix where you want to put something in /etc/...) > You should ask your user for > > DATADIR > BINDIR > etc... > > all those var should be relative path. > > and an eventual > INSTALL_PREFIX > which could be absolute. > > In any case if you really want to tolerate absolute path given by the > user, but still want to mimic install location during the build > then you'll have to escape it. > > For each path you expect from the user: > > check the path with if(IS_ABSOLUTE path) and compute some relative path > a) if you are on Windows remove the drive letter, i.e. D:/alt/bin > becomes alt/bin > (or network drive share name //shairedisk/alt/bin becomes > alt/bin) > b) if you are on Unix > > >> >> What are your thoughts on that, recommandations? >> > > I wouldn't try to mimic install tree during the build (if it is what you > are doing), > If I have a need to "verify" install tree structure then **after the > build** I would do a fake install with a particular > local prefix (as CPack does before packaging). > > Note that for similar reason CPack has to track files installed with > absolute destination and > possibly error out when it cannot handle it, particularly on Windows > oriented generator: > see e.g.: > https://cmake.org/cmake/help/v3.7/variable/CPACK_ERROR_ON_ > ABSOLUTE_INSTALL_DESTINATION.html > > AFAIK, IFW and NSIS do not work with, absolute installed files. > > > -- > Eric > > -- > > 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 demelier.david at gmail.com Thu Jul 27 07:55:24 2017 From: demelier.david at gmail.com (David Demelier) Date: Thu, 27 Jul 2017 13:55:24 +0200 Subject: [CMake] Correct handling of absolute/relative installation paths In-Reply-To: References: <29c7445d-8c2c-9d05-9d40-9365c0805d0d@gmail.com> Message-ID: <31d93f21-fb5a-aad4-ad32-b6d5f531c9f9@gmail.com> Le 27/07/2017 ? 13:08, Eric Noulard a ?crit : > > > 2017-07-27 12:28 GMT+02:00 David Demelier >: > > Hello, > > I'm still trying to find a correct solution to handle user specified > installation paths. > > Let's consider two kind of paths: > > - WITH_BINDIR (default: bin/) where to install executables, > - WITH_DATADIR (default: share/project_name/) where to install > extra data. > > I want to let the user configuring those paths because not all > distributions use the same paths (e.g. bin vs usr/bin). > > Then, I also like to build the whole CMake project by creating the > hierarchy as it would be installed like: > > /WITH_BINDIR/myapp > /WITH_DATADIR/somestuff.txt > > > Do you mean here that you setup CMAKE__OUTPUT_DIRECTORY (variable > or target property) to your favorite value > or > Both, I set the output directory for executable to WITH_BINDIR value and also install it as destination. > My opinion is that you should never use absolute path (besides some very > specific case on unix where you want to put something in /etc/...) > You should ask your user for > > DATADIR > BINDIR > etc... > This is what I have done in my CMakeLists.txt, the cmake invocation fails if BINDIR and/or DATADIR are absolute. But again, then with some package managers you get in troubles because they specify absolute path. See the RPM default macro: /usr/bin/cmake \ -DCMAKE_C_FLAGS_RELEASE:STRING="-DNDEBUG" \ -DCMAKE_CXX_FLAGS_RELEASE:STRING="-DNDEBUG" \ -DCMAKE_Fortran_FLAGS_RELEASE:STRING="-DNDEBUG" \ -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON \ -DCMAKE_INSTALL_PREFIX:PATH=/usr \ -DINCLUDE_INSTALL_DIR:PATH=/usr/include \ -DLIB_INSTALL_DIR:PATH=/usr/lib64 \ -DSYSCONF_INSTALL_DIR:PATH=/etc \ -DSHARE_INSTALL_PREFIX:PATH=/usr/share \ And if you add any new variable, you should prefix by %{prefix} which is also absolute... > I wouldn't try to mimic install tree during the build (if it is what you > are doing), The nice thing is that you can easily run/debug the application especially if that application needs to find some plugins/data while running by evaluating paths to them. I'll probably go for something like a pre-install target like you said instead of mimic'ing the build tree. And disable that target if any of the paths are absolute. Thanks for the answers! From boxerab at gmail.com Thu Jul 27 09:23:15 2017 From: boxerab at gmail.com (Aaron Boxer) Date: Thu, 27 Jul 2017 09:23:15 -0400 Subject: [CMake] cmakedefine based on find_package Message-ID: Hello, I am using find_package to find the OpenCL install on my system. Finding the package sets OPENCL_FOUND to true. I would like to create a #define in the code that will match this cmake variable, so I have set #cmakedefine HAVE_OPENCL @OPENCL_FOUND@ in my config.h.cmake.in file. However, I get /* #undef HAVE_OPENCL */ in the corresponding include file. Thanks, Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: From boxerab at gmail.com Thu Jul 27 09:39:10 2017 From: boxerab at gmail.com (Aaron Boxer) Date: Thu, 27 Jul 2017 09:39:10 -0400 Subject: [CMake] cmakedefine based on find_package In-Reply-To: References: Message-ID: Never mind, figured it out :) #cmakedefine OPENCL_FOUND On Thu, Jul 27, 2017 at 9:23 AM, Aaron Boxer wrote: > Hello, > > I am using find_package to find the OpenCL install on my system. > Finding the package sets OPENCL_FOUND to true. > I would like to create a #define in the code that will match this cmake > variable, > so I have set > > #cmakedefine HAVE_OPENCL @OPENCL_FOUND@ > > in my config.h.cmake.in file. > > However, I get > > /* #undef HAVE_OPENCL */ > > in the corresponding include file. > > Thanks, > Aaron > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bfgorski at gmail.com Thu Jul 27 14:36:26 2017 From: bfgorski at gmail.com (Ben Gregorski) Date: Thu, 27 Jul 2017 11:36:26 -0700 Subject: [CMake] Incorrect path to network drive location when installing libraries Message-ID: Hello, I have a library project (headers + libs) that I want to install onto a Windows network drive location. The project is created on my local drive as an out-of-source build. When I use install(DIRECTORY ...) the network location is written correctly into the cmake_install.cmake file as //foo/headers. When I use install(TARGETS ...) the network location is written as /foo/lib_32.lib which does not seem to work. Any idea how I can fix this? I am using cmake 3.9 Thanks. Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at macolighting.com Thu Jul 27 19:22:16 2017 From: chris at macolighting.com (Christopher Broadbent) Date: Fri, 28 Jul 2017 09:22:16 +1000 Subject: [CMake] Android NDK, clang, and ODR violations In-Reply-To: References: Message-ID: <93b220ca-d804-9786-fdb2-2afbff73dd91@macolighting.com> On 28/07/2017 02:28, Dan Albert wrote: > (in case threading doesn't work since I'm not a list member and can't > reply to the original message: > https://cmake.org/pipermail/cmake/2017-July/065886.html) > > I'm pretty sure -Wl,--detect-odr-violations is just giving you false > positives. Note that the warning message says "/possible/ ODR > violation". We tried using this flag in the Android platform recently > and found lots of false positives too. > > Those symbols are weak in libc++abi, so this is not an ODR violation > (they're not weak in libstdc++.so, and that's a bug, but not a harmful > one; I'm fixing it right now either way). > > FWIW, CMake shouldn't be linking libstdc++.so /and/ libc++_static.a in > the same link either way, but this is actually something that both > upstream CMake, the NDK's CMake toolchain file, and ndk-build all get > wrong. It's something that we should resolve eventually, but it doesn't > actually cause any problems so it hasn't been prioritized. Could argue > that it has caused this problem, but this would still be firing on false > positives if you'd added your own new/delete replacements, and this > warning is still pretty much guaranteed to fire for libc++ because > libandroid_support will do exactly the same thing and try to replace a > bunch of things in libc. Thanks, I'll move ahead with the switch, and look in to filtering out the warnings on these symbols, rather than disabling the ODR checks entirely. From PuetzKevinA at JohnDeere.com Thu Jul 27 19:10:24 2017 From: PuetzKevinA at JohnDeere.com (Puetz Kevin A) Date: Thu, 27 Jul 2017 23:10:24 +0000 Subject: [CMake] CMake 3.9 change to dependencies of object compilation Message-ID: <74B7C9CD2B43054BA63CDE61908202D96648B196@EDXMB90.jdnet.deere.com> I saw the following in the CMake 3.9 release notes, but didn't immediately realize all the implications. Sorry for not catching this during the -rc phase... . The?Ninja?generator has loosened the dependencies of object compilation. Object compilation now depends only on custom targets and custom commands associated with libraries on which the object's target depends and no longer depends on the libraries themselves. Source files in dependent targets may now compile without waiting for their targets' dependencies to link. We have a few cases where the object compilation really does depend on the TARGET_FILE itself, e.g. 1. An RC compiler embedding the resulting file of a custom target (I think this one may still work, since custom targets appear to have been exempted from the change) 2. MSVC's #import construct which needs the indirect dependencies (dependencies of the #import-ed dependency) be registered, which is handled as part of the target using add_custom_command(TARGET foo POST_BUILD COMMAND ...) So. I appreciate this loosening in most cases, it's greatly fixed some unnecessary stalls in our parallel build, and for dependencies acquired target_link_libraries this seems 100% correct to apply them only to the linker rule. But it seems the changes impacted add_dependencies as well, so now how do I now express a real dependency between a compile rule and another target (i.e. get a target listed at the same level as cmake_object_order_depend_*? add_custom_command(OUTPUT... DEPENDS...) seemingly still allows target-level dependencies for a file compilation step, but I can't figure out what property has the same effect on a normal source file (that's going to be built by a "built-in" rule like CMAKE_RC_COMPILE_OBJECT, CMAKE_CXX_COMPILE_OBJECT, etc). AddFileDependencies(.) (aka OBJECT_DEPENDS) doesn't allow say it allows target-level dependencies, and it doesn't seem to work in practice either. The best I've been able to come up with far requires an indirect SYMBOLIC output file to carry the dependency between a phony add_custom_command and the real source's OBJECT_DEPENDS ADD_CUSTOM_COMMAND(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/foo.depends DEPENDS bar) SET_PROPERTY(SOURCE ${CMAKE_CURRENT_BINARY_DIR}/foo.depends PROPERTY SYMBOLIC 1) SET_PROPERTY(SOURCE source.cpp APPEND PROPERTY OBJECT_DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/foo.depends) That works, but it definitely feels more like a workaround than the intended solution. If the generators can handle this for add_custom_command, it seems like they should be able to handle it for language compile rules too. Any better suggestions? From bitminer at gmail.com Thu Jul 27 20:48:07 2017 From: bitminer at gmail.com (Brian Davis) Date: Thu, 27 Jul 2017 19:48:07 -0500 Subject: [CMake] CMake and Learning from bad examples Message-ID: In latest CMake Doc for cmake modules at: https://cmake.org/cmake/help/v3.0/module/CMakePackageConfigHelpers.html#module:CMakePackageConfigHelpers I find: Example using both configure_package_config_file() and write_basic_package_version_file(): CMakeLists.txt: set(INCLUDE_INSTALL_DIR include/ ... CACHE ) set(LIB_INSTALL_DIR lib/ ... CACHE ) set(SYSCONFIG_INSTALL_DIR etc/foo/ ... CACHE ) ... include(CMakePackageConfigHelpers) configure_package_config_file(FooConfig.cmake.in ${CMAKE_CURRENT_BINARY_DIR}/FooConfig.cmake INSTALL_DESTINATION ${LIB_INSTALL_DIR}/Foo/cmake PATH_VARS INCLUDE_INSTALL_DIR SYSCONFIG_INSTALL_DIR) write_basic_package_version_file(${CMAKE_CURRENT_BINARY_DIR}/FooConfigVersion.cmake VERSION 1.2.3 COMPATIBILITY SameMajorVersion ) install(FILES ${CMAKE_CURRENT_BINARY_DIR}/FooConfig.cmake ${CMAKE_CURRENT_BINARY_DIR}/FooConfigVersion.cmake DESTINATION ${LIB_INSTALL_DIR}/Foo/cmake ) Uses for the install directory INSTALL_DESTINATION ${LIB_INSTALL_DIR}/Foo/cmake which leads me to beleive that install will be to ${CMAKE_INSTALL_PREIX}/lib/Foo/cmake However lets look at where say come projects from a company called Kitware put them: ./lib/cmake ./lib/cmake/ITK-4.8 ./lib/cmake/vtk-7.0 And note the version say ITK-4.8 because if your intalling multiple versions say old on top of new I may be a good idea not to have directories without version info say like lib/Foo better might be lib/cmake/Foo-1.2.3 but hey for documentation stating the "best practices" CMake still appears all over the map when in comes to packages. Thoughts? -------------- next part -------------- An HTML attachment was scrubbed... URL: From bitminer at gmail.com Thu Jul 27 20:56:08 2017 From: bitminer at gmail.com (Brian Davis) Date: Thu, 27 Jul 2017 19:56:08 -0500 Subject: [CMake] CMake 3.8+ and CUDA as a first class language, but not for Visual Studio... err what? Message-ID: Reading: https://cmake.org/cmake/help/latest/release/3.8.html?highlight=cuda Can someone explain to me how CUDA is now supported as a first class language, -------------- next part -------------- An HTML attachment was scrubbed... URL: From bitminer at gmail.com Thu Jul 27 21:01:30 2017 From: bitminer at gmail.com (Brian Davis) Date: Thu, 27 Jul 2017 20:01:30 -0500 Subject: [CMake] CMake CUDA 3.8+/9 support as a first class language with out Visual Studio Support... err what? Message-ID: Can someone explain to me the meaning of the statement at: https://cmake.org/cmake/help/latest/release/3.8.html?highlight=cuda Make learned to support CUDA as a first-class language that can be enabled via the project() and enable_language() commands. CUDA is currently supported by the Makefile Generators and the Ninja generator on Linux, macOS, and Windows. *Support for the Visual Studio IDE is under development but not included in this release.* The NVIDIA CUDA Toolkit compiler (nvcc) is supported. Specifically: *Support for the Visual Studio IDE is under development but not included in this release.* Is CUDA as a first class language not supported for seemingly second class citizens such as Visual Studio? -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.mazakas at gmail.com Thu Jul 27 21:09:20 2017 From: christian.mazakas at gmail.com (Christian Mazakas) Date: Thu, 27 Jul 2017 18:09:20 -0700 Subject: [CMake] CMake CUDA 3.8+/9 support as a first class language with out Visual Studio Support... err what? In-Reply-To: References: Message-ID: Probably means no more hacky MSBuild custom tasks which can't be parallelized. On Jul 27, 2017 6:07 PM, "Brian Davis" wrote: > > Can someone explain to me the meaning of the statement at: > > https://cmake.org/cmake/help/latest/release/3.8.html?highlight=cuda > > > Make learned to support CUDA as a first-class language that can be enabled > via the project() and enable_language() commands. > CUDA is currently supported by the Makefile Generators and the Ninja > generator on Linux, macOS, and Windows. *Support for the Visual Studio IDE > is under development but not included in this release.* > The NVIDIA CUDA Toolkit compiler (nvcc) is supported. > > Specifically: > > *Support for the Visual Studio IDE is under development but not included > in this release.* > > Is CUDA as a first class language not supported for seemingly second class > citizens such as Visual Studio? > > -- > > 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 calebwherry at gmail.com Thu Jul 27 21:28:42 2017 From: calebwherry at gmail.com (J. Caleb Wherry) Date: Fri, 28 Jul 2017 01:28:42 +0000 Subject: [CMake] CMake CUDA 3.8+/9 support as a first class language with out Visual Studio Support... err what? In-Reply-To: References: Message-ID: Not sure I understand your question but Visual Studio support just lagged a version for that feature. It is available in CMake 3.9: https://cmake.org/cmake/help/v3.9/release/3.9.html Or are you asking before this version how was CUDA supported? -Caleb On Thu, Jul 27, 2017 at 9:07 PM Brian Davis wrote: > > Can someone explain to me the meaning of the statement at: > > https://cmake.org/cmake/help/latest/release/3.8.html?highlight=cuda > > > Make learned to support CUDA as a first-class language that can be enabled > via the project() and enable_language() commands. > CUDA is currently supported by the Makefile Generators and the Ninja > generator on Linux, macOS, and Windows. *Support for the Visual Studio IDE > is under development but not included in this release.* > The NVIDIA CUDA Toolkit compiler (nvcc) is supported. > > Specifically: > > *Support for the Visual Studio IDE is under development but not included > in this release.* > > Is CUDA as a first class language not supported for seemingly second class > citizens such as Visual Studio? > -- > > 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 -- Sent from my iPhone 4s -------------- next part -------------- An HTML attachment was scrubbed... URL: From bitminer at gmail.com Thu Jul 27 21:58:45 2017 From: bitminer at gmail.com (Brian J. Davis) Date: Thu, 27 Jul 2017 20:58:45 -0500 Subject: [CMake] CMake and Learning from bad examples In-Reply-To: References: Message-ID: <576531d6-e1ec-af2b-d916-1ecce995a2cb@gmail.com> Also at https://cmake.org/cmake/help/latest/module/CMakePackageConfigHelpers.html?highlight=configure_package_config_file set(INCLUDE_INSTALL_DIR include/ ... CACHE ) set(LIB_INSTALL_DIR lib/ ... CACHE ) set(SYSCONFIG_INSTALL_DIR etc/foo/ ... CACHE ) #... include(CMakePackageConfigHelpers) configure_package_config_file(FooConfig.cmake.in ${CMAKE_CURRENT_BINARY_DIR}/FooConfig.cmake INSTALL_DESTINATION ${LIB_INSTALL_DIR}/Foo/cmake PATH_VARS INCLUDE_INSTALL_DIR SYSCONFIG_INSTALL_DIR) write_basic_package_version_file( ${CMAKE_CURRENT_BINARY_DIR}/FooConfigVersion.cmake VERSION 1.2.3 COMPATIBILITY SameMajorVersion ) install(FILES ${CMAKE_CURRENT_BINARY_DIR}/FooConfig.cmake ${CMAKE_CURRENT_BINARY_DIR}/FooConfigVersion.cmake DESTINATION ${LIB_INSTALL_DIR}/Foo/cmake ) Does INSTALL_DESTINATION ${LIB_INSTALL_DIR}/Foo/cmake from configure_package_config_file and install(FILES ${CMAKE_CURRENT_BINARY_DIR}/FooConfig.cmake .... install the file twice? Is this from department of redundancy department department?. -------------- next part -------------- An HTML attachment was scrubbed... URL: From 1026863114 at qq.com Fri Jul 28 02:20:34 2017 From: 1026863114 at qq.com (=?gb18030?B?Yw==?=) Date: Fri, 28 Jul 2017 14:20:34 +0800 Subject: [CMake] error on using cmake Message-ID: Hello. I tried to compile LTP using cmake on Windows 10 with Visual Studio compiler ... However, "CMakeOutput.log" says that The system is: Windows - 10.0.14393 - AMD64. And I Installed Windows 10 SDK but the same error keeps occurring. Hope your help. Waiting for your reply. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ????_20170720112854.png Type: application/octet-stream Size: 28627 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ????_20170718231211.png Type: application/octet-stream Size: 38231 bytes Desc: not available URL: From d3ck0r at gmail.com Fri Jul 28 02:32:34 2017 From: d3ck0r at gmail.com (J Decker) Date: Thu, 27 Jul 2017 23:32:34 -0700 Subject: [CMake] error on using cmake In-Reply-To: References: Message-ID: You need visual studio build tools... https://www.visualstudio.com/downloads/ way at the bottom of the page... Build Tools for Visual Studio 2017 or for 2015... https://www.microsoft.com/en-us/download/details.aspx?id= 48159 On Thu, Jul 27, 2017 at 11:20 PM, c <1026863114 at qq.com> wrote: > Hello. > I tried to compile LTP using cmake on Windows 10 with Visual Studio > compiler ... > However, "CMakeOutput.log" says that The system is: Windows - 10.0.14393 > - AMD64. > And I Installed Windows 10 SDK but the same error keeps occurring. > Hope your help. > Waiting for your reply. > > -- > > 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 robert.maynard at kitware.com Fri Jul 28 12:05:11 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 28 Jul 2017 12:05:11 -0400 Subject: [CMake] CMake CUDA 3.8+/9 support as a first class language with out Visual Studio Support... err what? In-Reply-To: References: Message-ID: Just to clarify the CUDA and CMake situation. CMake 3.8 added the initial first class support of CUDA to CMake ( instead of using FindCUDA ). This work only supports the makefile and ninja generators, which means that the visual studio IDE generator is not supported. This doesn't mean that the Visual Studio compiler isn't supported, as you still could use ninja or makefile with the VS compiler. CMake 3.9 added the support for the visual studio generator for CUDA. The approach that was used was to call out to the existing MSBuild CUDA extensions that NVIDIA provides. With 3.9 all generators are considered to be 'first class' in regards to CUDA. On Thu, Jul 27, 2017 at 9:28 PM, J. Caleb Wherry wrote: > Not sure I understand your question but Visual Studio support just lagged a > version for that feature. It is available in CMake 3.9: > > https://cmake.org/cmake/help/v3.9/release/3.9.html > > Or are you asking before this version how was CUDA supported? > > -Caleb > > On Thu, Jul 27, 2017 at 9:07 PM Brian Davis wrote: >> >> >> Can someone explain to me the meaning of the statement at: >> >> https://cmake.org/cmake/help/latest/release/3.8.html?highlight=cuda >> >> >> Make learned to support CUDA as a first-class language that can be enabled >> via the project() and enable_language() commands. >> CUDA is currently supported by the Makefile Generators and the Ninja >> generator on Linux, macOS, and Windows. *Support for the Visual Studio IDE >> is under development but not included in this release.* >> The NVIDIA CUDA Toolkit compiler (nvcc) is supported. >> >> Specifically: >> >> *Support for the Visual Studio IDE is under development but not included >> in this release.* >> >> Is CUDA as a first class language not supported for seemingly second class >> citizens such as Visual Studio? >> -- >> >> 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 > > -- > Sent from my iPhone 4s > > -- > > 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 christian.mazakas at gmail.com Fri Jul 28 12:23:40 2017 From: christian.mazakas at gmail.com (Christian Mazakas) Date: Fri, 28 Jul 2017 09:23:40 -0700 Subject: [CMake] CMake CUDA 3.8+/9 support as a first class language with out Visual Studio Support... err what? In-Reply-To: References: Message-ID: I tried using VS solutions and MSBuild but building was still serialized. Ninja is just better for Windows. On Jul 28, 2017 9:06 AM, "Robert Maynard" wrote: > Just to clarify the CUDA and CMake situation. > > CMake 3.8 added the initial first class support of CUDA to CMake ( > instead of using FindCUDA ). This work only supports the makefile and > ninja generators, which means that the visual studio IDE generator is > not supported. This doesn't mean that the Visual Studio compiler isn't > supported, as you still could use ninja or makefile with the VS > compiler. > > CMake 3.9 added the support for the visual studio generator for CUDA. > The approach that was used was to call out to the existing MSBuild > CUDA extensions that NVIDIA provides. With 3.9 all generators are > considered to be 'first class' in regards to CUDA. > > > On Thu, Jul 27, 2017 at 9:28 PM, J. Caleb Wherry > wrote: > > Not sure I understand your question but Visual Studio support just > lagged a > > version for that feature. It is available in CMake 3.9: > > > > https://cmake.org/cmake/help/v3.9/release/3.9.html > > > > Or are you asking before this version how was CUDA supported? > > > > -Caleb > > > > On Thu, Jul 27, 2017 at 9:07 PM Brian Davis wrote: > >> > >> > >> Can someone explain to me the meaning of the statement at: > >> > >> https://cmake.org/cmake/help/latest/release/3.8.html?highlight=cuda > >> > >> > >> Make learned to support CUDA as a first-class language that can be > enabled > >> via the project() and enable_language() commands. > >> CUDA is currently supported by the Makefile Generators and the Ninja > >> generator on Linux, macOS, and Windows. *Support for the Visual Studio > IDE > >> is under development but not included in this release.* > >> The NVIDIA CUDA Toolkit compiler (nvcc) is supported. > >> > >> Specifically: > >> > >> *Support for the Visual Studio IDE is under development but not included > >> in this release.* > >> > >> Is CUDA as a first class language not supported for seemingly second > class > >> citizens such as Visual Studio? > >> -- > >> > >> 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 > > > > -- > > Sent from my iPhone 4s > > > > -- > > > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bitminer at gmail.com Fri Jul 28 12:45:31 2017 From: bitminer at gmail.com (Brian J. Davis) Date: Fri, 28 Jul 2017 11:45:31 -0500 Subject: [CMake] CMake CUDA 3.8+/9 support as a first class language with out Visual Studio Support... err what? In-Reply-To: References: Message-ID: <03ef217a-8b17-88fa-468e-94ef5ed74423@gmail.com> @Robert So how do I go about using it in 3.9? And more importantly does it work? Does it generate hybrid CPP/CU projects that can be compiled in visual studio the way FindCUDA (did/does?). Currently using FindCUDA, but I have had some CUDA 7.5 / 8.0 and VS 13/15 cats in a bag trouble. Finally uninstalled CUDA 8.0 and had to reinstall/repair VS13 due to .NET goop removal with 8.0 somehow. Then reinstalled 7.5, but still no luck with SampleProjects from NVIDIA. Then removed 7.5 and reinstalled 8.0 and sample projects then built the 8.0 projects and ran successfully with VS13. NVIDIA states that cross mojonation with runtimes and drivers would work just swimmingly... and well I got news for them on that one. FindCUDA during 7.5 yeiled confusing warning saying that I was specifying 7.5, but it found 8.0 even though 7.5 was installed as though FindCUDA did not seem to listen to the version I was specifying. I upgraded CMake from 3.2 to 3.9 so I could set env{var} and use CMake's Open Project to set env build vars for VS to be used in project settings with outthe need for my run_vs.bat script CMake used to have to generate with configure_file. So with CMake, CUDA and Visual Studio it's like three cats in a bag and one is a like bobcat (CUDA) so it's kinda messy. From bitminer at gmail.com Fri Jul 28 12:55:18 2017 From: bitminer at gmail.com (Brian J. Davis) Date: Fri, 28 Jul 2017 11:55:18 -0500 Subject: [CMake] CMake CUDA 3.8+/9 support as a first class language with out Visual Studio Support... err what? In-Reply-To: <7992f9fe-f801-4f9a-d4d7-d9ec69274c73@wisc.edu> References: <7992f9fe-f801-4f9a-d4d7-d9ec69274c73@wisc.edu> Message-ID: <116cb9ee-91aa-63c8-fd06-aebd9a902e0e@gmail.com> @Caleb I am asking how do I get it to work in post 3.8 or 3.9. Does it work. I know how it worked before CMake 3.2 and prior both on Linux and windows... ie ... it did not without considerable manual futzing due to NVIDIA's inability to put their goop in a standard location that they would be internally consistent with... as though they always picked the "new person" to do the release and that person never spoke with the person who released the previous version. Believe me I know how it ?worked? in prior versions... a term used loosely here. : resend to do T-Bird picking wrong send from addr apologies if you get 2 of these. From robert.maynard at kitware.com Fri Jul 28 13:39:07 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 28 Jul 2017 13:39:07 -0400 Subject: [CMake] CMake CUDA 3.8+/9 support as a first class language with out Visual Studio Support... err what? In-Reply-To: <03ef217a-8b17-88fa-468e-94ef5ed74423@gmail.com> References: <03ef217a-8b17-88fa-468e-94ef5ed74423@gmail.com> Message-ID: > So how do I go about using it in 3.9? And more importantly does it work? Does it generate hybrid CPP/CU projects that can be compiled in visual studio the way FindCUDA (did/does?). It works and will generate hybrid C++ and CUDA projects. A very simple example of making a library and an executable that uses both languages can be seen at: https://gitlab.kitware.com/cmake/cmake/blob/v3.9.0/Tests/Cuda/ConsumeCompileFeatures/CMakeLists.txt On Fri, Jul 28, 2017 at 12:45 PM, Brian J. Davis wrote: > > @Robert > > So how do I go about using it in 3.9? And more importantly does it work? > Does it generate hybrid CPP/CU projects that can be compiled in visual > studio the way FindCUDA (did/does?). > > Currently using FindCUDA, but I have had some CUDA 7.5 / 8.0 and VS 13/15 > cats in a bag trouble. Finally uninstalled CUDA 8.0 and had to > reinstall/repair VS13 due to .NET goop removal with 8.0 somehow. Then > reinstalled 7.5, but still no luck with SampleProjects from NVIDIA. Then > removed 7.5 and reinstalled 8.0 and sample projects then built the 8.0 > projects and ran successfully with VS13. NVIDIA states that cross > mojonation with runtimes and drivers would work just swimmingly... and well > I got news for them on that one. FindCUDA during 7.5 yeiled confusing > warning saying that I was specifying 7.5, but it found 8.0 even though 7.5 > was installed as though FindCUDA did not seem to listen to the version I was > specifying. > > I upgraded CMake from 3.2 to 3.9 so I could set env{var} and use CMake's > Open Project to set env build vars for VS to be used in project settings > with outthe need for my run_vs.bat script CMake used to have to generate > with configure_file. So with CMake, CUDA and Visual Studio it's like three > cats in a bag and one is a like bobcat (CUDA) so it's kinda messy. > > -- > > 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 sdg31 at zips.uakron.edu Fri Jul 28 14:43:55 2017 From: sdg31 at zips.uakron.edu (Samuel Goodrick) Date: Fri, 28 Jul 2017 14:43:55 -0400 Subject: [CMake] Unable to Change Default Linker in CMake 3.5.1 Message-ID: Hello, I am trying to change my linker to ld.gold so that I can build LLVM and CLANG faster. I have changed my environment variable with: export LD=ld.gold and I have changed CMAKE_LINKER in ccmake to /usr/bin/ld.gold. However, when I generate the files, my linker is detected as GNU ld. Running top during compilation confirms that ld is running rather than gold. I'm on Ubuntu 16.04, but I have had the same problem on Arch Linux. Thank You. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bitminer at gmail.com Fri Jul 28 20:29:35 2017 From: bitminer at gmail.com (Brian J. Davis) Date: Fri, 28 Jul 2017 19:29:35 -0500 Subject: [CMake] Fwd: Re: CMake CUDA 3.8+/9 support as a first class language with out Visual Studio Support... err what? In-Reply-To: <5c3a4169-13b7-4ccb-eafd-81a9125b8dbb@wisc.edu> References: <5c3a4169-13b7-4ccb-eafd-81a9125b8dbb@wisc.edu> Message-ID: <74ccfa0f-5941-6d24-21ff-636e63ca124f@gmail.com> @Robert >> It works and will generate hybrid C++ and CUDA projects. A very simple example of making a library and an executable that uses both languages can be seen at: https://gitlab.kitware.com/cmake/cmake/blob/v3.9.0/Tests/Cuda/ConsumeCompileFeatures/CMakeLists.txt Thanks for the example I'll try that. It's been ages since I even looked at my project call From: https://cmake.org/cmake/help/latest/command/project.html?highlight=project Specifically: "Optionally you can specify which languages your project supports. Example languages are C, CXX (i.e. C++), Fortran, etc. *By default C and CXX are enabled if no language options are given.* Specify language NONE, or use the LANGUAGES keyword and list no languages, to skip enabling any languages. " Looks as though c and cxx are the 1%'ers in the "class" system. Might be good to update this documentation whenever Kitware gets around to it. From bitminer at gmail.com Fri Jul 28 20:40:01 2017 From: bitminer at gmail.com (Brian J. Davis) Date: Fri, 28 Jul 2017 19:40:01 -0500 Subject: [CMake] CMake CUDA 3.8+/9 support as a first class language with out Visual Studio Support... err what? In-Reply-To: References: Message-ID: @Robert Adding CUDA to my PROJECT(4DRTProto CXX CUDA) Yields: CMake Error at C:/projects/4DRTProto/4DRTProto_3rdParty/platform/tools/cmake-3.9.0-rc6-win64-x64/share/cmake-3.9/Modules/CMakeTestCUDACompiler.cmake:45 (message): The CUDA compiler "C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v8.0/bin/nvcc.exe" is not able to compile a simple test program. It fails with the following output: Change Dir: C:/projects/4DRTProto/4DRTProto/build/CMakeFiles/CMakeTmp Run Build Command:"C:/Program Files (x86)/MSBuild/12.0/bin/MSBuild.exe" "cmTC_20a4f.vcxproj" "/p:Configuration=Debug" "/p:VisualStudioVersion=12.0" Microsoft (R) Build Engine version 12.0.31101.0 [Microsoft .NET Framework, version 4.0.30319.42000] Copyright (C) Microsoft Corporation. All rights reserved. Build started 7/28/2017 7:33:34 PM. Project "C:\projects\4DRTProto\4DRTProto\build\CMakeFiles\CMakeTmp\cmTC_20a4f.vcxproj" on node 1 (default targets). PrepareForBuild: Creating directory "cmTC_20a4f.dir\Debug\". Creating directory "C:\projects\4DRTProto\4DRTProto\build\CMakeFiles\CMakeTmp\Debug\". Creating directory "cmTC_20a4f.dir\Debug\cmTC_20a4f.tlog\". InitializeBuildStatus: Creating "cmTC_20a4f.dir\Debug\cmTC_20a4f.tlog\unsuccessfulbuild" because "AlwaysCreate" was specified. C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\BuildCustomizations\CUDA 8.0.targets(216,9): error : Item 'main.cu' Code Generation value is not in the expected format '[Arch],[Code]'. [C:\projects\4DRTProto\4DRTProto\build\CMakeFiles\CMakeTmp\cmTC_20a4f.vcxproj] Done Building Project "C:\projects\4DRTProto\4DRTProto\build\CMakeFiles\CMakeTmp\cmTC_20a4f.vcxproj" (default targets) -- FAILED. Build FAILED. "C:\projects\4DRTProto\4DRTProto\build\CMakeFiles\CMakeTmp\cmTC_20a4f.vcxproj" (default target) (1) -> (AddCudaCompileMetadata target) -> C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\BuildCustomizations\CUDA 8.0.targets(216,9): error : Item 'main.cu' Code Generation value is not in the expected format '[Arch],[Code]'. [C:\projects\4DRTProto\4DRTProto\build\CMakeFiles\CMakeTmp\cmTC_20a4f.vcxproj] 0 Warning(s) 1 Error(s) Time Elapsed 00:00:00.35 CMake will not be able to correctly generate this project. Call Stack (most recent call first): CMakeLists.txt:14 (PROJECT) And so it goes the CMake, CUDA, Visual Studio Experience. Maybe time to revert back to FindCUDA in CMAKE version 3.2. Sure is awesome. From bitminer at gmail.com Sat Jul 29 02:44:01 2017 From: bitminer at gmail.com (Brian J. Davis) Date: Sat, 29 Jul 2017 01:44:01 -0500 Subject: [CMake] CMake CUDA 3.8+/9 support as a first class language with out Visual Studio Support... err what? In-Reply-To: References: Message-ID: <4ef4fb0a-8d61-2c08-f525-ae07f79cd227@gmail.com> Saying I could get this to work, which it is not how, would one using project: Project( myproject CXX CUDA) specify the version of CUDA to use if I have CUDA 7.5 and 8 installed simultaneously. FindCUDA could do it. And say if version of cuda could be specified why not c++ 0x or 11... Ya know cuz if we are going to be able to specify the version of one "first class" language we should be able to specify the version of each.... yeah I am guessing I know the answer to this already. I just had this burning desire to ask this question. From tzsariysk at gmail.com Sat Jul 29 12:25:10 2017 From: tzsariysk at gmail.com (T.Sariyski) Date: Sat, 29 Jul 2017 10:25:10 -0600 Subject: [CMake] ExternalProject_Add fails with gcc-4.9.3 Message-ID: <01b901d30887$40054250$c00fc6f0$@gmail.com> cmake version 3.4.3 Hi, I have ExternalProject_Add (attached), which works with gcc-4.4.7, but fails with gcc-4.9.3: ... ... [100%] Performing build step for 'ep_netcdf' CMake Error at /scratch/tesari/build/cee/gnu.dbg/netcdf/src/ep_netcdf-stamp/ep_netcdf-build -DEBUG.cmake:16 (message): Command failed: 2 'make' See also /scratch/tesari/build/cee/gnu.dbg/netcdf/src/ep_netcdf-stamp/ep_netcdf-build -*.log (attached). If I execute configure and make, as defined in ${CONFIGURE_COMMAND}, it works. What is the meaning of "Command failed: 2 'make'" error message, and how should I track it down? Any help is highly appreciated. Thanks in advance, Ted ExternalProject_Add( ep_netcdf URL ${CMAKE_SOURCE_DIR}/src/netcdf/netcdf_distro.tar PREFIX ${CMAKE_CURRENT_BINARY_DIR}/netcdf LOG_CONFIGURE 1 LOG_BUILD 1 LOG_INSTALL 1 LOG_DOWNLOAD 0 LOG_UPDATE 0 BUILD_IN_SOURCE 1 CONFIGURE_COMMAND ${CMAKE_CURRENT_BINARY_DIR}/netcdf/src/ep_netcdf/configure --enable-64bit FC=" " F90=${CMAKE_Fortran_COMPILER} CXX=${CMAKE_CXX_COMPILER} CC=${CMAKE_C_COMPILER} BUILD_COMMAND ${MAKE} ) ep_netcdf-build-DEBUG.cmake -------------------------------------------------------- set(command "${make}") execute_process( COMMAND ${command} RESULT_VARIABLE result OUTPUT_FILE "/scratch/tesari/build/cee/gnu.dbg/netcdf/src/ep_netcdf-stamp/ep_netcdf-buil d-out.log" ERROR_FILE "/scratch/tesari/build/cee/gnu.dbg/netcdf/src/ep_netcdf-stamp/ep_netcdf-buil d-err.log" ) if(result) set(msg "Command failed: ${result}\n") foreach(arg IN LISTS command) set(msg "${msg} '${arg}'") endforeach() set(msg "${msg}\nSee also\n /scratch/tesari/build/cee/gnu.dbg/netcdf/src/ep_netcdf-stamp/ep_netcdf-build -*.log") message(FATAL_ERROR "${msg}") else() set(msg "ep_netcdf build command succeeded. See also /scratch/tesari/build/cee/gnu.dbg/netcdf/src/ep_netcdf-stamp/ep_netcdf-build -*.log") message(STATUS "${msg}") endif() From robert.maynard at kitware.com Sat Jul 29 16:54:50 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Sat, 29 Jul 2017 16:54:50 -0400 Subject: [CMake] CMake CUDA 3.8+/9 support as a first class language with out Visual Studio Support... err what? In-Reply-To: <4ef4fb0a-8d61-2c08-f525-ae07f79cd227@gmail.com> References: <4ef4fb0a-8d61-2c08-f525-ae07f79cd227@gmail.com> Message-ID: The way to control which CUDA version to use is by setting the CUDACXX environment variable, or by setting the CMAKE_CUDA_COMPILER cache variable. To specify which CUDA compilation language you want 98/11/14 you can use any of methods that are possible by compile features ( https://cmake.org/cmake/help/latest/manual/cmake-compile-features.7.html ). That means you can do: - set(CMAKE_CUDA_STANDARD 11) - set_property(TARGET PROPERTY CUDA_STANDARD 11) or if you have C++ enabled at the project level - target_compile_features( PUBLIC cxx_std_11) On Sat, Jul 29, 2017 at 2:44 AM, Brian J. Davis wrote: > > Saying I could get this to work, which it is not how, would one using > project: > > Project( myproject CXX CUDA) > > specify the version of CUDA to use if I have CUDA 7.5 and 8 installed > simultaneously. FindCUDA could do it. And say if version of cuda could be > specified why not c++ 0x or 11... Ya know cuz if we are going to be able to > specify the version of one "first class" language we should be able to > specify the version of each.... yeah I am guessing I know the answer to this > already. I just had this burning desire to ask this question. > > -- > > 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 robert.maynard at kitware.com Sat Jul 29 16:56:12 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Sat, 29 Jul 2017 16:56:12 -0400 Subject: [CMake] CMake CUDA 3.8+/9 support as a first class language with out Visual Studio Support... err what? In-Reply-To: References: Message-ID: Hi, Can you please provide run from the build directory cmake --system-information and send the resulting file? That will help me track down why CUDA is failing for you. On Fri, Jul 28, 2017 at 8:40 PM, Brian J. Davis wrote: > > @Robert > > Adding CUDA to my PROJECT(4DRTProto CXX CUDA) > > Yields: > > > CMake Error at > C:/projects/4DRTProto/4DRTProto_3rdParty/platform/tools/cmake-3.9.0-rc6-win64-x64/share/cmake-3.9/Modules/CMakeTestCUDACompiler.cmake:45 > (message): > The CUDA compiler "C:/Program Files/NVIDIA GPU Computing > Toolkit/CUDA/v8.0/bin/nvcc.exe" is not able to compile a simple test > program. > > It fails with the following output: > > Change Dir: C:/projects/4DRTProto/4DRTProto/build/CMakeFiles/CMakeTmp > > > > Run Build Command:"C:/Program Files (x86)/MSBuild/12.0/bin/MSBuild.exe" > "cmTC_20a4f.vcxproj" "/p:Configuration=Debug" > "/p:VisualStudioVersion=12.0" > > Microsoft (R) Build Engine version 12.0.31101.0 > > > [Microsoft .NET Framework, version 4.0.30319.42000] > > > Copyright (C) Microsoft Corporation. All rights reserved. > > > > > > Build started 7/28/2017 7:33:34 PM. > > > Project > "C:\projects\4DRTProto\4DRTProto\build\CMakeFiles\CMakeTmp\cmTC_20a4f.vcxproj" > on node 1 (default targets). > > > PrepareForBuild: > > > Creating directory "cmTC_20a4f.dir\Debug\". > > Creating directory > "C:\projects\4DRTProto\4DRTProto\build\CMakeFiles\CMakeTmp\Debug\". > > Creating directory "cmTC_20a4f.dir\Debug\cmTC_20a4f.tlog\". > > > InitializeBuildStatus: > > > Creating "cmTC_20a4f.dir\Debug\cmTC_20a4f.tlog\unsuccessfulbuild" > because "AlwaysCreate" was specified. > > > C:\Program Files > (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\BuildCustomizations\CUDA > 8.0.targets(216,9): error : Item 'main.cu' Code Generation value is not in > the expected format '[Arch],[Code]'. > [C:\projects\4DRTProto\4DRTProto\build\CMakeFiles\CMakeTmp\cmTC_20a4f.vcxproj] > > > > Done Building Project > "C:\projects\4DRTProto\4DRTProto\build\CMakeFiles\CMakeTmp\cmTC_20a4f.vcxproj" > (default targets) -- FAILED. > > > > > > Build FAILED. > > > > > > > "C:\projects\4DRTProto\4DRTProto\build\CMakeFiles\CMakeTmp\cmTC_20a4f.vcxproj" > (default target) (1) -> > > > (AddCudaCompileMetadata target) -> > > > C:\Program Files > (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\BuildCustomizations\CUDA > 8.0.targets(216,9): error : Item 'main.cu' Code Generation value is not in > the expected format '[Arch],[Code]'. > [C:\projects\4DRTProto\4DRTProto\build\CMakeFiles\CMakeTmp\cmTC_20a4f.vcxproj] > > > > > > 0 Warning(s) > > 1 Error(s) > > > > > > Time Elapsed 00:00:00.35 > > > > > > > CMake will not be able to correctly generate this project. > Call Stack (most recent call first): > CMakeLists.txt:14 (PROJECT) > > > And so it goes the CMake, CUDA, Visual Studio Experience. Maybe time to > revert back to FindCUDA in CMAKE version 3.2. Sure is awesome. > > > > > > -- > > 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 bitminer at gmail.com Sat Jul 29 19:00:53 2017 From: bitminer at gmail.com (Brian J. Davis) Date: Sat, 29 Jul 2017 18:00:53 -0500 Subject: [CMake] CMake CUDA 3.8+/9 support as a first class language with out Visual Studio Support... err what? In-Reply-To: References: Message-ID: @Robert I created a fresh simple cmake project in 3.9. This appeared to find CUDA 8.0 successfully so it may have something do with my other project settings that I am trying to get to work with 3.9, VS13, CUDA 7.5/8.0. Using: message( CUDACXX = ${CUDACXX}) message( CMAKE_CUDA_COMPILER = ${CMAKE_CUDA_COMPILER}) Reports CUDACXX= CMAKE_CUDA_COMPILER=C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v8.0/bin/nvcc.exe Configuring done Generating done The question was at setting the CUDA version say 7.5 or 8.0. I search doc for CUDACXX and CMAKE_CUDA_COMPILER with no hits. Is this stuff documented anywhere. Do I really need to say set: CMAKE_CUDA_COMPILER=C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v7.5/bin/nvcc.exe To get CMake to compile for 7.5? I mean: find_package(CUDA 7.5) you could agree is/was much simpler. I am becoming frustrated and confused by these changes. I can't even get a simple CUDA app to run using FindCUDA (will compile) or compile using v3.9 and new project( CXX CUDA). Your example at: https://cmake.org/cmake/help/latest/manual/cmake-compile-features.7.html Used: add_executable(CudaConsumeCompileFeatures main.cu) Is is required now that main.cpp be a .cu file now? I wouldn't think so, but I am so lost in the woods on this that I am not sure of anything anymore. How do I get all the toolkit and sdk include and lib dir variables now as FindCUDA provided? I am so curfuffled by these changes. Can I get the CMake doc in one (1) html page again... those were the good old days when scanning back and forth I would stumble on some good bits ... not that I can seemly find the doc for the new CUDA changes. This reminds me of the days when I could only get doc on things like ExternalProject_Add at the command prompt. From bitminer at gmail.com Sat Jul 29 19:41:25 2017 From: bitminer at gmail.com (Brian J. Davis) Date: Sat, 29 Jul 2017 18:41:25 -0500 Subject: [CMake] CMake CUDA 3.8+/9 support as a first class language with out Visual Studio Support... err what? In-Reply-To: References: Message-ID: With simple stand alone cmake 3.9 project using cmake_minimum_required(VERSION 3.9) project(cmake_testing CXX CUDA) I can get a simple app to compile. It however fails to run with: GPU Device 0: "GeForce GTX 960M" with compute capability 5.0 Current device is [0] Current device is [0] CUDA error at C:\projects\cmake\cmaketesting\v3.9\cuda_basic\src\cuda_basic_test.cpp:67 code=46(cudaErrorDevicesUnavailable) "cudaMalloc((void **)&d_volume, size)" When trying to call cudaMalloc. When trying to actually use the device. checkCudaErrors(cudaMalloc((void **)&d_volume, size)); So I am right back I started in the new simple project. I am able to complle and run SDK examples say nbody. it can only be two things right??? compile args and runtime environment (dll paths). right? err well or gremlins. NBody compile important bits: 1> C:\ProgramData\NVIDIA Corporation\CUDA Samples\v8.0\5_Simulations\nbody>"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v8.0\bin\nvcc.exe" -gencode=arch=compute_20,code=\"sm_20,compute_20\" -gencode=arch=compute_30,code=\"sm_30,compute_30\" -gencode=arch=compute_35,code=\"sm_35,compute_35\" -gencode=arch=compute_37,code=\"sm_37,compute_37\" -gencode=arch=compute_50,code=\"sm_50,compute_50\" -gencode=arch=compute_52,code=\"sm_52,compute_52\" -gencode=arch=compute_60,code=\"sm_60,compute_60\" --use-local-env --cl-version 2013 -ccbin "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\x86_amd64" -I./ -I../../common/inc -I./ -I"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v8.0\/include" -I../../common/inc -I"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v8.0\include" -G --keep-dir x64\Debug -maxrregcount=0 --machine 64 --compile -cudart static -Xcompiler "/wd 4819" -g -DWIN32 -DWIN32 -D_MBCS -D_MBCS -Xcompiler "/EHsc /W3 /nologo /Od /FS /Zi /RTC1 /MTd " -o x64/Debug/bodysystemcuda.cu.obj "C:\ProgramData\NVIDIA Corporation\CUDA Samples\v8.0\5_Simulations\nbody\bodysystemcuda.cu" My simple test app compile bits: 2> C:\projects\cmake\cmaketesting\v3.9\build\cuda_basic\src>"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v8.0\bin\nvcc.exe" -ccbin "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\x86_amd64" -I"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v8.0\include" -I"C:\ProgramData\NVIDIA Corporation\CUDA Samples\v8.0\common\inc" -I"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v8.0\include" -I"C:\ProgramData\NVIDIA Corporation\CUDA Samples\v8.0\common\inc" -I"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v8.0\include" -I"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v8.0\include" -G --keep-dir x64\Debug -maxrregcount=0 --machine 64 --compile -Xcompiler="/EHsc -Zi -Ob0" -g -D_WINDOWS -D"CMAKE_INTDIR=\"Debug\"" -DWIN32 -D_WINDOWS -D"CMAKE_INTDIR=\"Debug\"" -D_MBCS -Xcompiler "/EHsc /W3 /nologo /Od /FS /Zi /RTC1 /MDd /GR" -o cuda_basic_test.dir\Debug\cuda_basic_test.cu.obj "C:\projects\cmake\cmaketesting\v3.9\cuda_basic\src\cuda_basic_test.cu" -clean 2>CUDACOMPILE : nvcc warning : The 'compute_20', 'sm_20', and 'sm_21' architectures are deprecated, and may be removed in a future release (Use -Wno-deprecated-gpu-targets to suppress warning). 2> cuda_basic_test.cu 2> Building Custom Rule C:/projects/cmake/cmaketesting/v3.9/cuda_basic/src/CMakeLists.txt 2> CMake does not need to re-run because C:/projects/cmake/cmaketesting/v3.9/build/cuda_basic/src/CMakeFiles/generate.stamp is up-to-date. 2> Compiling CUDA source file ..\..\..\cuda_basic\src\cuda_basic_test.cu... 2> 2> C:\projects\cmake\cmaketesting\v3.9\build\cuda_basic\src>"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v8.0\bin\nvcc.exe" -gencode=arch=compute_20,code=\"sm_20,compute_20\" --use-local-env --cl-version 2013 -ccbin "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\x86_amd64" -I"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v8.0\include" -I"C:\ProgramData\NVIDIA Corporation\CUDA Samples\v8.0\common\inc" -I"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v8.0\include" -I"C:\ProgramData\NVIDIA Corporation\CUDA Samples\v8.0\common\inc" -I"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v8.0\include" -I"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v8.0\include" -G --keep-dir x64\Debug -maxrregcount=0 --machine 64 --compile -cudart static -Xcompiler="/EHsc -Zi -Ob0" -g -D_WINDOWS -D"CMAKE_INTDIR=\"Debug\"" -DWIN32 -D_WINDOWS -D"CMAKE_INTDIR=\"Debug\"" -D_MBCS -Xcompiler "/EHsc /W3 /nologo /Od /FS /Zi /RTC1 /MDd /GR" -o cuda_basic_test.dir\Debug\cuda_basic_test.cu.obj "C:\projects\cmake\cmaketesting\v3.9\cuda_basic\src\cuda_basic_test.cu" From kris.f.thielemans at gmail.com Sat Jul 29 21:22:02 2017 From: kris.f.thielemans at gmail.com (Kris Thielemans) Date: Sun, 30 Jul 2017 02:22:02 +0100 Subject: [CMake] setting PYTHONPATH for test Message-ID: <015401d308d2$3fd563a0$bf802ae0$@gmail.com> Hi I'm trying to add to the PYTHONPATH for a test that uses Python. I do that using set_test_properties. When using the makefile generator, I need to add ${CMAKE_CURRENT_BINARY_DIR}. However, for Visual Studio I also need to add for instance ${CMAKE_CURRENT_BINARY_DIR}/Release. My current CMakeLists.txt works only on Windows and when building Release mode: add_test(${name} "${PYTHON_EXECUTABLE}" ${testfile} ) set_tests_properties ( ${name} PROPERTIES ENVIRONMENT "PYTHONPATH=${CMAKE_CURRENT_BINARY_DIR}/Release\;${CMAKE_CURRENT_BINARY_DIR} ") I have 2 problems: * How do I figure out which configuration is being used? $ doesn't seem to work inside set_test_properties (it just gets passed verbatim) * In most cases, I need to use a colon as path-separator for PYTHONPATH, but on Windows I need to use a semi-colon when using Anaconda, but probably not when using Cygwin's python. Any suggestions? (I'm using CMake 3.8 currently but would like to be able to support (much) older versions) Thanks Kris PS: In case you're interested, I'm trying to get the CMake build for SWIG running. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jupiter.hce at gmail.com Sat Jul 29 21:51:35 2017 From: jupiter.hce at gmail.com (jupiter) Date: Sun, 30 Jul 2017 11:51:35 +1000 Subject: [CMake] The C compiler "/usr/bin/cc" is not able to compile a simple test program. Message-ID: Hi, How can I set up the cmake not to check /usr/bin/cc but to check $CC (which link to gcc without hard corded path in the environment)? Thank you. Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From jupiter.hce at gmail.com Sat Jul 29 22:36:34 2017 From: jupiter.hce at gmail.com (jupiter) Date: Sun, 30 Jul 2017 12:36:34 +1000 Subject: [CMake] The C compiler "/usr/bin/cc" is not able to compile a simple test program. In-Reply-To: References: Message-ID: I thought if I add -DCMAKE_CC_COMPILER=gcc that error should go, no, it still compile with the specific default cc: /usr/bin/cc .... How could I fix it? Thank you. On Sun, Jul 30, 2017 at 11:51 AM, jupiter wrote: > Hi, > > How can I set up the cmake not to check /usr/bin/cc but to check $CC > (which link to gcc without hard corded path in the environment)? > > Thank you. > > Regards > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From micha.hergarden at gmail.com Sun Jul 30 04:54:45 2017 From: micha.hergarden at gmail.com (Micha Hergarden) Date: Sun, 30 Jul 2017 10:54:45 +0200 Subject: [CMake] The C compiler "/usr/bin/cc" is not able to compile a simple test program. In-Reply-To: References: Message-ID: On 30-07-17 04:36, jupiter wrote: > I thought if I add -DCMAKE_CC_COMPILER=gcc that error should go, no, > it still compile with the specific default cc: > > /usr/bin/cc .... > > How could I fix it? > > Thank you. > > On Sun, Jul 30, 2017 at 11:51 AM, jupiter > wrote: > > Hi, > > How can I set up the cmake not to check /usr/bin/cc but to check > $CC (which link to gcc without hard corded path in the environment)? > > Thank you. > > Regards > > > > > Hello Jupiter, Running the following sets the compiler to gcov: CC=/usr/bin/gcov cmake ../ This outputs: -- The C compiler identification is unknown -- The CXX compiler identification is GNU 7.1.1 -- Check for working C compiler: /usr/bin/gcov -- Check for working C compiler: /usr/bin/gcov -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - failed -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Configuring done -- Generating done As you can see cmake definitely uses the CC environment variable. What is your OS? What do you set $CC to? What is the full commandline you use to call cmake? What happens if you set it the way I did? Regards, Micha -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 525 bytes Desc: OpenPGP digital signature URL: From nilsgladitz at gmail.com Sun Jul 30 05:28:34 2017 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Sun, 30 Jul 2017 11:28:34 +0200 Subject: [CMake] setting PYTHONPATH for test In-Reply-To: <015401d308d2$3fd563a0$bf802ae0$@gmail.com> References: <015401d308d2$3fd563a0$bf802ae0$@gmail.com> Message-ID: On 30.07.2017 03:22, Kris Thielemans wrote: > > Hi > > I?m trying to add to the PYTHONPATH for a test that uses Python. I do > that using set_test_properties. When using the makefile generator, I > need to add ${CMAKE_CURRENT_BINARY_DIR}. However, for Visual Studio I > also need to add for instance ${CMAKE_CURRENT_BINARY_DIR}/Release. > > My current CMakeLists.txt works only on Windows and when building > Release mode: > > add_test(${name} ?${PYTHON_EXECUTABLE}" ${testfile} ) > > set_tests_properties ( ${name} PROPERTIES ENVIRONMENT > > "PYTHONPATH=${CMAKE_CURRENT_BINARY_DIR}/Release\;${CMAKE_CURRENT_BINARY_DIR}") > > I have 2 problems: > > * How do I figure out which configuration is being used? > $ doesn?t seem to work inside > set_test_properties (it just gets passed verbatim) > Try using the NAME/COMMAND signature of add_test() e.g. add_test(NAME ${name} COMMAND ?${PYTHON_EXECUTABLE}" ${testfile}) It should enable generator expression processing in test properties. Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Sun Jul 30 05:38:01 2017 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Sun, 30 Jul 2017 11:38:01 +0200 Subject: [CMake] The C compiler "/usr/bin/cc" is not able to compile a simple test program. In-Reply-To: References: Message-ID: On 30.07.2017 10:54, Micha Hergarden wrote: > On 30-07-17 04:36, jupiter wrote: >> I thought if I add -DCMAKE_CC_COMPILER=gcc that error should go, no, >> it still compile with the specific default cc: The corresponding CMake cache variable for the C compiler is CMAKE_C_COMPILER (note C not CC). Also note if the C compiler has already been configured for a build tree it can not simply be changed. Which is also why the CC environment variable has no effect on build trees where the C compiler is already configured. Nils From bitminer at gmail.com Sun Jul 30 16:32:24 2017 From: bitminer at gmail.com (Brian J. Davis) Date: Sun, 30 Jul 2017 15:32:24 -0500 Subject: [CMake] CMake CUDA 3.8+/9 support as a first class language with out Visual Studio Support... err what? In-Reply-To: References: Message-ID: Things I have tried: Install Visual Studio 15 Install CUDA 8.0 + patch Install Visual Studio 13 <- Yes Nvidia / CMake'ers sometimes we have to do back ports Install CUDA 7.5 VS 13 will run CUDA 8.0 samples nbody/deviceQuery VS 13 does not run CUDA 7.5 samples nbody or any example attempting to actually use the GPU. deviceQuery worked. CMake v3.2/3.9 compiles with either FindCUDA approach v3.2 or new "project" approach v3.9, but neither is able to access the deivce. Devcie query code such as in deviceQuery works stating there is a CUDA cable device ready and waiting but fails on device access like cudaMalloc calls. Reinstalled CUDA 7.5 Still only VS with 8.0 works with samples. Used NVIDIA Control panel to assign every program to run on NVIDIA GPU such as VS and CMake instead of Integrated graphics through Nvidia Optimus Interface. Used GeForce Experience to get latest driver. VS, CUDA, CMake is at same state. Removed all CUDA 8.0 goop Forced to reinstall/repair VS 13 due to .NET not sure why this happened. VS unable to run nbody in VS 13 CUDA 7.5 Reinstall CUDA 7.5 Same state Reinstall CUDA 8.0 VS 13 works with CUDA 8.0 but still will not run nbody with 7.5 will run deviceQuery and report happily there a a CUDA device just beckoning to be used. Removed CUDA 8.0 Removed CUDA 7.5 Removed GeForce Experience to keep it from mucking about in the background with what ever driver version shenanigans it may be performing. Device Manager -> NVIDIA GeForce GTX 960M -> Uninstall device. Device keeps cumming back across reboots as it appears, may be due to NVIDIA Graphics Driver 353.90 in "Add remove programs" Reinstalled CUDA 7.5 VS 13 runs successfully deviceQuery and nbody with 7.5. Oddly deviceQuery reports driver version at 9.0 ??? Not sure how that's possible. My understanding/experience has been Driver version / Runtime match after install say like 7.5 / 7.5, but hey this has gone completely off the rails. C:\ProgramData\NVIDIA Corporation\CUDA Samples\v7.5\bin\win64\Debug>deviceQuery.exe deviceQuery.exe Starting... CUDA Device Query (Runtime API) version (CUDART static linking) Detected 1 CUDA Capable device(s) Device 0: "GeForce GTX 960M" CUDA Driver Version / Runtime Version 9.0 / 7.5 CUDA Capability Major/Minor version number: 5.0 Total amount of global memory: 4096 MBytes (4294967296 bytes) ( 5) Multiprocessors, (128) CUDA Cores/MP: 640 CUDA Cores GPU Max Clock rate: 1176 MHz (1.18 GHz) Memory Clock rate: 2505 Mhz Memory Bus Width: 128-bit L2 Cache Size: 2097152 bytes Maximum Texture Dimension Size (x,y,z) 1D=(65536), 2D=(65536, 65536), 3D=(4096, 4096, 4096) Maximum Layered 1D Texture Size, (num) layers 1D=(16384), 2048 layers Maximum Layered 2D Texture Size, (num) layers 2D=(16384, 16384), 2048 layers Total amount of constant memory: 65536 bytes Total amount of shared memory per block: 49152 bytes Total number of registers available per block: 65536 Warp size: 32 Maximum number of threads per multiprocessor: 2048 Maximum number of threads per block: 1024 Max dimension size of a thread block (x,y,z): (1024, 1024, 64) Max dimension size of a grid size (x,y,z): (2147483647, 65535, 65535) Maximum memory pitch: 2147483647 bytes Texture alignment: 512 bytes Concurrent copy and kernel execution: Yes with 1 copy engine(s) Run time limit on kernels: Yes Integrated GPU sharing Host Memory: No Support host page-locked memory mapping: Yes Alignment requirement for Surfaces: Yes Device has ECC support: Disabled CUDA Device Driver Mode (TCC or WDDM): WDDM (Windows Display Driver Model) Device supports Unified Addressing (UVA): Yes Device PCI Domain ID / Bus ID / location ID: 0 / 2 / 0 Compute Mode: < Default (multiple host threads can use ::cudaSetDevice() with device simultaneously) > deviceQuery, CUDA Driver = CUDART, CUDA Driver Version = 9.0, CUDA Runtime Version = 7.5, NumDevs = 1, Device0 = GeForce GTX 960M Device Manager -> NVIDIA GeForce GTX 960M -> Properties reports: NVidia GeForce GTX 960M Driver provider: NVIDIA Driver Date: 7/18/2017 Driver Version: 22.21.13.8494 Digital Signer: Microsoft Windows Hardware Compatibility Publisher Note: Driver Date: 7/18/2017 Could this mean there is a 9.0 driver in the wild that I cannot download from NVIDIA or through GeForce Experience, but may be delivered via OS? Posted @ https://devtalk.nvidia.com/default/board/58/ to see if anyone knows what is going on here. CMake 3.2/3.9 still fail to run (again compiles fine) What It appears I am experiencing is some CUDA 7.5 / 8.0 driver version conflicts where 7.5 does not seem to play nice with 8.0 drivers, but *might* be working with 9.0 driver... I say might as I am not sure what is going on there. I have some bad news for NVIDIA their driver "API Backward/Not Forward Compatible" diagram may have been accurate from 1.0 to 2.0, but 7.5 8.0 is shaping up to need a whole new diagram of broken links and end around curvy arrows. file:///C:/Program%20Files/NVIDIA%20GPU%20Computing%20Toolkit/CUDA/v7.5/doc/html/common/graphics/compatibility-of-cuda-versions.png CMake is still a dysfunctional hot mess. It does not work in any scenario. That's not to say I can't get it to work as I have on a Dell M4700 with a Quadro and 7.5 with CMake 3.2 and VS12/13. Thought I would try upgrade to 3.9 on new laptop, but hey I can't seem to get any version to work on the new laptop and I can only get Samples in 7.5 to work if I seemingly uninstall all CUDA 8.0 related bits, most notable of which appears/seems to be the driver. Next I am going to remove all NVIDA drivers and try reinstall of CUDA 7.5 see if I can get deviceQuery to report 7.5/7.5. Also looking into a mooc course on weaving to make something useful out of this pile of hair I have pulled out. Thoughts on how to get CMake to work at all in any scenario. From laurent.berger at univ-lemans.fr Sun Jul 30 17:35:16 2017 From: laurent.berger at univ-lemans.fr (Laurent Berger) Date: Sun, 30 Jul 2017 23:35:16 +0200 Subject: [CMake] Using caffe in my own project In-Reply-To: References: Message-ID: <8a353c92-f30a-ab46-f463-b1da1053e154@univ-lemans.fr> Hi, OS windows 10. Visual Studio 14 2015 win 64. CMake 3.7.1 I have got some problem to use Caffe in my own project. My cmakelists.txt is cmake_minimum_required(VERSION 2.8) PROJECT (HelloWorld) find_package(opencv REQUIRED) find_package(Caffe REQUIRED) file(GLOB HelloWorld_srcs "*.h" "*.cpp") ADD_EXECUTABLE (HelloWorld ${HelloWorld_srcs}) if (OpenCV_FOUND) include_directories( ${OpenCV_INCLUDE_DIRS} ) target_link_libraries( HelloWorld ${OpenCV_LIBS} ) else (OpenCV_FOUND) message("PB->OPENCV not found= ${OpenCV_INCLUDE_DIRS}") endif (OpenCV_FOUND) if (Caffe_FOUND) include_directories( ${Caffe_INCLUDE_DIRS} ) target_link_libraries( HelloWorld ${Caffe_LIBS} ) else (Caffe_FOUND) message("PB->Caffe_ not found= ${Caffe_INCLUDE_DIRS} ${Caffe_LIBS} end variable") endif (Caffe_FOUND) When I open my solution in VS 8I can opencv include but nothing about caffe (my first line in my c++ program is #include ) In CaffeConfig.cmake I can read : # Config file for the Caffe package. # # Note: # Caffe and this config file depends on opencv, # so put `find_package(OpenCV)` before searching Caffe # via `find_package(Caffe)`. All other lib/includes # dependencies are hard coded in the file # # After successful configuration the following variables # will be defined: # # Caffe_LIBRARIES - IMPORTED targets to link against # (There is no Caffe_INCLUDE_DIRS and Caffe_DEFINITIONS # because they are specified in the IMPORTED target interface.) # # Caffe_HAVE_CUDA - signals about CUDA support # Caffe_HAVE_CUDNN - signals about cuDNN support What does it mean There is no Caffe_INCLUDE_DIRS and Caffe_DEFINITIONS because they are specified in the IMPORTED target interface.) How can I insert caffe include and libs in my project using my cmakelists.txt ? Thanks in advance for your answer From bitminer at gmail.com Sun Jul 30 20:15:20 2017 From: bitminer at gmail.com (Brian J. Davis) Date: Sun, 30 Jul 2017 19:15:20 -0500 Subject: [CMake] CMake CUDA 3.8+/9 support as a first class language with out Visual Studio Support... err what? In-Reply-To: References: Message-ID: <001a780f-82ce-e026-82fd-2d4af7819e1b@gmail.com> Saga novella continues: >> Next I am going to remove all NVIDA drivers and try reinstall of CUDA 7.5 see if I can get deviceQuery to report 7.5/7.5. Nvidia 352.65 driver removal from Add/Remove Programs Device Manager -> NVIDIA GeForce GTX 960M -> General reports "device has been disabled" Device Query: C:\ProgramData\NVIDIA Corporation\CUDA Samples\v7.5\bin\win64\Debug>rem start "Device Query" deviceQuery.exe C:\ProgramData\NVIDIA Corporation\CUDA Samples\v7.5\bin\win64\Debug>deviceQuery.exe deviceQuery.exe Starting... CUDA Device Query (Runtime API) version (CUDART static linking) cudaGetDeviceCount returned 35 -> CUDA driver version is insufficient for CUDA runtime version Result = FAIL Ok so great no driver installed! Reinstall of CUDA 7.5.18 Run of DeviceQuery: C:\ProgramData\NVIDIA Corporation\CUDA Samples\v7.5\bin\win64\Debug>rem start "Device Query" deviceQuery.exe C:\ProgramData\NVIDIA Corporation\CUDA Samples\v7.5\bin\win64\Debug>deviceQuery.exe deviceQuery.exe Starting... CUDA Device Query (Runtime API) version (CUDART static linking) Detected 1 CUDA Capable device(s) Device 0: "GeForce GTX 960M" CUDA Driver Version / Runtime Version 7.5 / 7.5 CUDA Capability Major/Minor version number: 5.0 Total amount of global memory: 4096 MBytes (4294967296 bytes) ( 5) Multiprocessors, (128) CUDA Cores/MP: 640 CUDA Cores GPU Max Clock rate: 1176 MHz (1.18 GHz) Memory Clock rate: 2505 Mhz Memory Bus Width: 128-bit L2 Cache Size: 2097152 bytes Maximum Texture Dimension Size (x,y,z) 1D=(65536), 2D=(65536, 65536), 3D=(4096, 4096, 4096) Maximum Layered 1D Texture Size, (num) layers 1D=(16384), 2048 layers Maximum Layered 2D Texture Size, (num) layers 2D=(16384, 16384), 2048 layers Total amount of constant memory: 65536 bytes Total amount of shared memory per block: 49152 bytes Total number of registers available per block: 65536 Warp size: 32 Maximum number of threads per multiprocessor: 2048 Maximum number of threads per block: 1024 Max dimension size of a thread block (x,y,z): (1024, 1024, 64) Max dimension size of a grid size (x,y,z): (2147483647, 65535, 65535) Maximum memory pitch: 2147483647 bytes Texture alignment: 512 bytes Concurrent copy and kernel execution: Yes with 1 copy engine(s) Run time limit on kernels: Yes Integrated GPU sharing Host Memory: No Support host page-locked memory mapping: Yes Alignment requirement for Surfaces: Yes Device has ECC support: Disabled CUDA Device Driver Mode (TCC or WDDM): WDDM (Windows Display Driver Model) Device supports Unified Addressing (UVA): Yes Device PCI Domain ID / Bus ID / location ID: 0 / 2 / 0 Compute Mode: < Default (multiple host threads can use ::cudaSetDevice() with device simultaneously) > deviceQuery, CUDA Driver = CUDART, CUDA Driver Version = 7.5, CUDA Runtime Version = 7.5, NumDevs = 1, Device0 = GeForce GTX 960M Result = PASS Ok return to sanity with 7.5/7.5 Return to insanity as NBody still does not work with: Run "nbody -benchmark [-numbodies=]" to measure performance. -fullscreen (run n-body simulation in fullscreen mode) -fp64 (use double precision floating point values for simulation) -hostmem (stores simulation data in host memory) -benchmark (run benchmark to measure performance) -numbodies= (number of bodies (>= 1) to run in simulation) -device= (where d=0,1,2.... for the CUDA device to use) -numdevices= (where i=(number of CUDA devices > 0) to use for simulation) -compare (compares simulation results running once on the default GPU and once on the CPU) -cpu (run n-body simulation on the CPU) -tipsy= (load a tipsy model file for simulation) NOTE: The CUDA Samples are not meant for performance measurements. Results may vary when GPU Boost is enabled. > Windowed mode > Simulation data stored in video memory > Single precision floating point simulation > 1 Devices used for simulation > Compute 5.0 CUDA device: [GeForce GTX 960M] CUDA error at c:\programdata\nvidia corporation\cuda samples\v7.5\5_simulations\nbody\bodysystemcuda_impl.h:160 code=46(cudaErrorDevicesUnavailable) "cudaEventCreate(&m_deviceData[0].event)" There is at this point clearly some very odd behavior with CUDA 7.5 and GeForce 960M. CMake still can build a project, but will not run or create memory with cudaMalloc etc. Installed driver at this point is 353.90. GeForce Experience reports 381.65 driver but I have downloaded: 384.94-notebook-win10-64bit-international-whql.exe So I try that and driver installed is now 384.94 CUDA 7.5 works with new driver, but not seemingly driver shipped with 7.5 or 8.0. NBody Runs. CMake 3.9 still fails to build a runable project with: GPU Device 0: "GeForce GTX 960M" with compute capability 5.0 Current device is [0] Current device is [0] CUDA error at C:\projects\cmake\cmaketesting\v3.9\cuda_basic\src\cuda_basic_test.cpp:66 code=46(cudaErrorDevicesUnavailable) "cudaMalloc((void **)&dev_mem_ptr, size)" DeviceQuery now reports: C:\ProgramData\NVIDIA Corporation\CUDA Samples\v7.5\bin\win64\Debug>deviceQuery.exe deviceQuery.exe Starting... CUDA Device Query (Runtime API) version (CUDART static linking) Detected 1 CUDA Capable device(s) Device 0: "GeForce GTX 960M" CUDA Driver Version / Runtime Version 9.0 / 7.5 CUDA Capability Major/Minor version number: 5.0 Total amount of global memory: 4096 MBytes (4294967296 bytes) ( 5) Multiprocessors, (128) CUDA Cores/MP: 640 CUDA Cores GPU Max Clock rate: 1176 MHz (1.18 GHz) Memory Clock rate: 2505 Mhz Memory Bus Width: 128-bit L2 Cache Size: 2097152 bytes Maximum Texture Dimension Size (x,y,z) 1D=(65536), 2D=(65536, 65536), 3D=(4096, 4096, 4096) Maximum Layered 1D Texture Size, (num) layers 1D=(16384), 2048 layers Maximum Layered 2D Texture Size, (num) layers 2D=(16384, 16384), 2048 layers Total amount of constant memory: 65536 bytes Total amount of shared memory per block: 49152 bytes Total number of registers available per block: 65536 Warp size: 32 Maximum number of threads per multiprocessor: 2048 Maximum number of threads per block: 1024 Max dimension size of a thread block (x,y,z): (1024, 1024, 64) Max dimension size of a grid size (x,y,z): (2147483647, 65535, 65535) Maximum memory pitch: 2147483647 bytes Texture alignment: 512 bytes Concurrent copy and kernel execution: Yes with 1 copy engine(s) Run time limit on kernels: Yes Integrated GPU sharing Host Memory: No Support host page-locked memory mapping: Yes Alignment requirement for Surfaces: Yes Device has ECC support: Disabled CUDA Device Driver Mode (TCC or WDDM): WDDM (Windows Display Driver Model) Device supports Unified Addressing (UVA): Yes Device PCI Domain ID / Bus ID / location ID: 0 / 2 / 0 Compute Mode: < Default (multiple host threads can use ::cudaSetDevice() with device simultaneously) > deviceQuery, CUDA Driver = CUDART, CUDA Driver Version = 9.0, CUDA Runtime Version = 7.5, NumDevs = 1, Device0 = GeForce GTX 960M Result = PASS Which is how seemingly CUDA 9 driver support was installed. Tried CMake 3.2 with CUDA 7.5 GPU Device 0: "GeForce GTX 960M" with compute capability 5.0 Current device is [0] Current device is [0] CUDA error at C:\projects\cmake\cmaketesting\v3.2\cuda_basic\src\cuda_basic_test.cpp:67 code=46(cudaErrorDevicesUnavailable) "cudaMalloc((void **)&d_volume, size)" and sigh! There is some bizarre behavior going on here. So CMake/Kitware I can get CUDA 7.5 to run samples with 384.94 driver and CUDA 8.0 uninstalled but I cannot get CMake 3.2 using FindCUDA or CMake 3.9 using project calls to build a simple CUDA app to allocate memory on the device. What gives? I have been using CMake since 2.8 and CUDA since 1.3 on C1060's and mobile Quadros and never experienced this. Clearly NVIDIA is to blame for the 7.5/8.0 cats in a bag fighting and 7.5 not working with itself and only working with 9.0 driver, but I cannot get any 3.2 or 3.9 to generate a project I can run... this is really strange... it's always just worked. If I could compile and run a CUDA sdk app then I knew CMake would and has worked. What could possibly be going on here? From pfultz2 at yahoo.com Mon Jul 31 10:41:40 2017 From: pfultz2 at yahoo.com (paul) Date: Mon, 31 Jul 2017 09:41:40 -0500 Subject: [CMake] "Modern" approach to optional/multiple configurations? In-Reply-To: References: Message-ID: <1501512100.4133.122.camel@yahoo.com> On Mon, 2017-07-24 at 10:46 +0100, Nicholas Devenish wrote: > Seen in the boost discussions on the CMake announcements: > ? > > > The rest can be implemented straightforwardly as cache options so that > > > you can run cmake with options like > > > > > > ? -Dvalgrind=OFF -Dtransactional-memory=ON -Dsegmented-stacks=ON [-D?] > > ... > > Secondly, in cmake 3 we try not to configure things using -D as we did > in cmake 2. Instead we make targets customised for that build > combination. The user then chooses to make or link to those targets if > they want those targets. > ? > Is this true, and is there a good example of a project with such a > configuration? > > I've been trying to learn the more modern approaches to writing CMakeLists > recently, and haven't come across such advice - I was under the impression > that cache-set options (that the build can make decisions on) was still the > recommended 'clean' way, and then options (and even extra sources, > dependencies) can be added to each target as required. > > As I imagine what this is saying, It seems that target-per-configuration > would just lead to an explosion of duplicated targets and duplicated code, > especially through every permutation of several different options?? > > Part of the niceness of target-oriented dependencies was just having one > thing to link to and depending on the configuration, that target would be > the correct one (and pass through it's configuration). At least Daniel Pfeifer's presentation of best practices here: https://www.slideshare.net/DanielPfeifer1/cmake-48475415 Says: * Dont?t make libraries STATIC/SHARED unless they cannot be built otherwise. * Leave the control of BUILD_SHARED_LIBS to your clients! Which would imply a build tree per configuration. I have never seen any information of best practices that suggests creating multiple targets for each variant in cmake 2 or 3. From bitminer at gmail.com Mon Jul 31 13:09:50 2017 From: bitminer at gmail.com (Brian J. Davis) Date: Mon, 31 Jul 2017 12:09:50 -0500 Subject: [CMake] CMake CUDA 3.8+/9 support as a first class language with out Visual Studio Support... err what? In-Reply-To: <001a780f-82ce-e026-82fd-2d4af7819e1b@gmail.com> References: <001a780f-82ce-e026-82fd-2d4af7819e1b@gmail.com> Message-ID: Could this be a Win 10 Pro/Enterprise CMake combo issue. I brought over demo project to OS refreshed M4700. Was Win7 Pro now Windows 10 Enterprise. Dell M4700 combo is: Device 0: "Quadro K1000M" CUDA Driver Version / Runtime Version 8.0 / 7.5 CMake 3.2 or 3.9 will build but not run which is the same as on the Dell 7559 w 960M. I am rebuilding, due to OS change a rebuild in CMake is necessary, my existing project that was working and will test that. Though simple 3.2 project does not work so my hopes are not high that my existing project will fair any better. Samples such as NBody work on M4700. All worked on M4700 Win7 before OS refresh with exception of 3.9 attempts as I started trying 3.9 on 7559 w/Win10Pro. Why would it be that CMake can compile an executable but not run it when the CUDA samples work? CUDA SDK Samples run just fine from VS (well when driver run time is 9.0/7.5 on 7559 w 960M), but simple CMake generated app does not. Simple in that it only finds device (0) and calls cudaMalloc... ya know... the ultra basic. From robert.maynard at kitware.com Mon Jul 31 15:35:56 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Mon, 31 Jul 2017 15:35:56 -0400 Subject: [CMake] CMake CUDA 3.8+/9 support as a first class language with out Visual Studio Support... err what? In-Reply-To: References: Message-ID: My responses are inline. On Sat, Jul 29, 2017 at 7:00 PM, Brian J. Davis wrote: > @Robert > > I created a fresh simple cmake project in 3.9. This appeared to find CUDA > 8.0 successfully so it may have something do with my other project settings > that I am trying to get to work with 3.9, VS13, CUDA 7.5/8.0. > > Using: > > message( CUDACXX = ${CUDACXX}) > message( CMAKE_CUDA_COMPILER = ${CMAKE_CUDA_COMPILER}) > > > Reports > > CUDACXX= > CMAKE_CUDA_COMPILER=C:/Program Files/NVIDIA GPU Computing > Toolkit/CUDA/v8.0/bin/nvcc.exe > Configuring done > Generating done > > The question was at setting the CUDA version say 7.5 or 8.0. > > I search doc for CUDACXX and CMAKE_CUDA_COMPILER with no hits. Is this > stuff documented anywhere. Unfortunately the environment variables are not documented anywhere and this is a known issue that I hope to have fixed in CMake 3.10. The CMAKE_CUDA_COMPILER falls under the the CMAKE__COMPILER documentation now with the new CUDA support ( https://cmake.org/cmake/help/v3.8/variable/CMAKE_LANG_COMPILER.html ). > > Do I really need to say set: > > CMAKE_CUDA_COMPILER=C:/Program Files/NVIDIA GPU Computing > Toolkit/CUDA/v7.5/bin/nvcc.exe > > To get CMake to compile for 7.5? I mean: > > find_package(CUDA 7.5) > > you could agree is/was much simpler. I am becoming frustrated and confused > by these changes. It might be possible in the future to provide other hint controls to tell CMake which version of CUDA you would like to use before the project / enable_language call. This would be something that is best addressed on the cmake developer list or as a gitlab issue ( https://gitlab.kitware.com/cmake/cmake/issues ) > > I can't even get a simple CUDA app to run using FindCUDA (will compile) or > compile using v3.9 and new project( CXX CUDA). > > Your example at: > > https://cmake.org/cmake/help/latest/manual/cmake-compile-features.7.html > > > Used: > > add_executable(CudaConsumeCompileFeatures main.cu) > > Is is required now that main.cpp be a .cu file now? I wouldn't think so, > but I am so lost in the woods on this that I am not sure of anything > anymore. So with the new CUDA support you can mix C/C++/CUDA sources together inside a single library or executable. This example was only using CUDA in the executable to reduce the complexity of the test. > > How do I get all the toolkit and sdk include and lib dir variables now as > FindCUDA provided? The toolkit include directory can be found by querying CMAKE_CUDA_TOOLKIT_INCLUDE_DIRECTORIES As far as CUDA SDK libraries those can simply used with target_link_libraries as the SDK library path is considered to be an implicit link directory, and will always be on the link line. This is actually the same for the CUDA sdk include directory ( it will be placed on the include line when building ). > > I am so curfuffled by these changes. These changes are needed to allow targets using CUDA to properly work with 'Modern' CMake (https://cmake.org/cmake/help/v3.8/manual/cmake-buildsystem.7.html#build-specification-and-usage-requirements). Without these changes usage requirements and CUDA would never work together. > > Can I get the CMake doc in one (1) html page again... those were the good > old days when scanning back and forth I would stumble on some good bits ... > not that I can seemly find the doc for the new CUDA changes. This reminds > me of the days when I could only get doc on things like ExternalProject_Add > at the command prompt. > > > > > > > -- > > 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 bitminer at gmail.com Mon Jul 31 20:25:00 2017 From: bitminer at gmail.com (Brian J. Davis) Date: Mon, 31 Jul 2017 19:25:00 -0500 Subject: [CMake] CMake CUDA 3.8+/9 support as a first class language with out Visual Studio Support... err what? In-Reply-To: <7ca86101-dfe0-957f-182f-cde17d4f83c4@wisc.edu> References: <7ca86101-dfe0-957f-182f-cde17d4f83c4@wisc.edu> Message-ID: <150725ad-ac46-b99e-8fa1-e86bf8ee9175@gmail.com> > > My responses are inline. As are mine. > On Sat, Jul 29, 2017 at 7:00 PM, Brian J. Davis > wrote: > >/@Robert />//>/I created a fresh simple cmake project in 3.9. This appeared to find > CUDA />/8.0 successfully so it may have something do with my other project > settings />/that I am trying to get to work with 3.9, VS13, CUDA 7.5/8.0. />//>/Using: />//>/message( CUDACXX = ${CUDACXX}) />/message( CMAKE_CUDA_COMPILER = ${CMAKE_CUDA_COMPILER}) />//>//>/Reports />//>/CUDACXX= />/CMAKE_CUDA_COMPILER=C:/Program Files/NVIDIA GPU Computing />/Toolkit/CUDA/v8.0/bin/nvcc.exe />/Configuring done />/Generating done />//>/The question was at setting the CUDA version say 7.5 or 8.0. />//>/I search doc for CUDACXX and CMAKE_CUDA_COMPILER with no hits. Is this />/stuff documented anywhere. / > Unfortunately the environment variables are not documented anywhere > and this is a known issue > that I hope to have fixed in CMake 3.10. > > The CMAKE_CUDA_COMPILER falls under the the CMAKE__COMPILER documentation > now with the new CUDA support ( > https://cmake.org/cmake/help/v3.8/variable/CMAKE_LANG_COMPILER.html ). > So let me get this straight. Changes appear to begin in 3.7 / 3.8 with VS started to be supported in 3.9, but the only way us schleps on the internet know how to use it is to wait until 3.10. Wow... seriously. And well I am not holding out *hope*. > >//>/Do I really need to say set: />//>/CMAKE_CUDA_COMPILER=C:/Program Files/NVIDIA GPU Computing />/Toolkit/CUDA/v7.5/bin/nvcc.exe />//>/To get CMake to compile for 7.5? I mean: />//>/find_package(CUDA 7.5) />//>/you could agree is/was much simpler. I am becoming frustrated and > confused />/by these changes. / > It might be possible in the future to provide other hint controls to > tell CMake which > version of CUDA you would like to use before the project / > enable_language call. This > would be something that is best addressed on the cmake developer list or as > a gitlab issue (https://gitlab.kitware.com/cmake/cmake/issues ) In the future with the robots... anything is possible... provided they are not out to kill us. Why would I bother to seemingly point out the obvious @developers list or issue tracker. Hopefully anyone reading this can tell I am a bit frustrated at this point. Huh here's how that would go: Me: Hey Devs you forgot to document how to use the tool. Do you expect anyone but you to know how to use it? Devs: Huh yea we know... Ugh ... errr... Huhhh were getting to that. Me: sigh... > >//>/I can't even get a simple CUDA app to run using FindCUDA (will > compile) or />/compile using v3.9 and new project( CXX CUDA). />//>/Your example at: />//>/https://cmake.org/cmake/help/latest/manual/cmake-compile-features.7.html />//>//>/Used: />//>/add_executable(CudaConsumeCompileFeatures main.cu) />//>/Is is required now that main.cpp be a .cu file now? I wouldn't think so, />/but I am so lost in the woods on this that I am not sure of anything />/anymore. / > So with the new CUDA support you can mix C/C++/CUDA sources together > inside a single library or executable. This example was only using CUDA > in the executable to reduce the complexity of the test. > Only if I can get it to work. Which I can't ... and would not know how anyway as well it is not documented... so why waste my time. > >//>/How do I get all the toolkit and sdk include and lib dir variables now > as />/FindCUDA provided? / > The toolkit include directory can be found by querying > CMAKE_CUDA_TOOLKIT_INCLUDE_DIRECTORIES > As far as CUDA SDK libraries those can simply used with target_link_libraries > as the SDK library path is considered to be an implicit link directory, and will > always be on the link line. This is actually the same for the CUDA sdk include > directory ( it will be placed on the include line when building ). > > >//>/I am so curfuffled by these changes. / > These changes are needed to allow targets using CUDA to properly work with > 'Modern' CMake (https://cmake.org/cmake/help/v3.8/manual/cmake-buildsystem.7.html#build-specification-and-usage-requirements). > Without these changes usage requirements and CUDA would never work together. > I assume the term *work* is used loosely.... VERY loosely. I hate to point out the obvious, but I can't get it to work now and have not clue or seemingly hope on figuring it out other than to check out CMake and roll my own version after reading impl in order to figure out how it does and how to get it to work. By that time I'd rather revert to writing VS xml project file by hand. Regarding 960M and CUDA 7.5/7.5, 8.0/7.5, and 7.7/9.0 Answer is: 960M was likely released post CUDA 7.5 driver and possibly post 8.0. Seems that architecture differences do not allow old drivers to work on newer arch cards. Once 9.0 driver was released... 7.5 run time worked with 9.0 driver, but for some reason not 8.0. Seems CUDA and Nvidia Runtime/Drivers have a dirty little secret much like Java and the runtimes. At this point I cannot get CMake 3.2 or 3.9 to work with CUDA 7.5/9.0, VS 13, on Win10Pro/Enterprise. And from the state of doc it seems not worth my effort to even try anymore. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jupiter.hce at gmail.com Mon Jul 31 21:42:11 2017 From: jupiter.hce at gmail.com (jupiter) Date: Tue, 1 Aug 2017 11:42:11 +1000 Subject: [CMake] The C compiler "/usr/bin/cc" is not able to compile a simple test program. In-Reply-To: References: Message-ID: Thanks Micha and Nils. Cheers. On Sun, Jul 30, 2017 at 6:54 PM, Micha Hergarden wrote: > On 30-07-17 04:36, jupiter wrote: > > I thought if I add -DCMAKE_CC_COMPILER=gcc that error should go, no, it > still compile with the specific default cc: > > /usr/bin/cc .... > > How could I fix it? > > Thank you. > > On Sun, Jul 30, 2017 at 11:51 AM, jupiter wrote: > >> Hi, >> >> How can I set up the cmake not to check /usr/bin/cc but to check $CC >> (which link to gcc without hard corded path in the environment)? >> >> Thank you. >> >> Regards >> >> >> > > > Hello Jupiter, > > Running the following sets the compiler to gcov: > > CC=/usr/bin/gcov cmake ../ > > This outputs: > > -- The C compiler identification is unknown > -- The CXX compiler identification is GNU 7.1.1 > -- Check for working C compiler: /usr/bin/gcov > -- Check for working C compiler: /usr/bin/gcov -- works > -- Detecting C compiler ABI info > -- Detecting C compiler ABI info - failed > -- Check for working CXX compiler: /usr/bin/c++ > -- Check for working CXX compiler: /usr/bin/c++ -- works > -- Detecting CXX compiler ABI info > -- Detecting CXX compiler ABI info - done > -- Detecting CXX compile features > -- Detecting CXX compile features - done > -- Configuring done > -- Generating done > > > As you can see cmake definitely uses the CC environment variable. What is > your OS? What do you set $CC to? What is the full commandline you use to > call cmake? > What happens if you set it the way I did? > > Regards, > Micha > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailinglists at xgm.de Mon Jul 31 23:48:18 2017 From: mailinglists at xgm.de (Florian Lindner) Date: Tue, 1 Aug 2017 11:48:18 +0800 Subject: [CMake] What is the default build type? Message-ID: Hello ccmake shows CMAKE_BUILD_TYPE as unset. From the compile commands it looks like also nothing like Debug nor Release. Why is there no well-defined default set? How can I set a default? Thanks, Florian