From jsvanbethlehem at gmail.com Wed Jun 1 03:02:41 2016 From: jsvanbethlehem at gmail.com (Jakob van Bethlehem) Date: Wed, 1 Jun 2016 09:02:41 +0200 Subject: [CMake] CMake+QT always failed for the first build, and succeeded for second build or later. In-Reply-To: References: Message-ID: Hej, Some things that come to mind: * You're generating files *inside* the source tree - you're not supposed to do that * Why do you want to have a special Qt_tmp directory? I don't see the benefit, and without that requirement you can simply use the qt4_wrap_cpp macro explicitly and you still are not forced to use the automoc feature And now for what is probably wrong in your CMakeLists.txt: * It seems you made an important mistake regarding the behaviour of 'file(GLOB)'. That function will do the expansion *while running CMake*. But at that time the moc_* files *don't exist!* (as a matter of fact, the tmp directory doesn't even exist). In other words, your ${Moc_SOURCES} will be empty, and hence they are not compiled, and hence you get precisely the linker errors you see (because these sources implement the functions that are listed as missing by the linker) If you would use the qt4_wrap_cpp() macro you don't run into this problem, so I'd strongly suggest using it. Sincerely, Jakob van Bethlehem On Tue, May 31, 2016 at 4:52 PM, irene w wrote: > It seems CMakw could not find the generated moc_xxx files. I modified the > scripts to specify moc_xxx files is generated, but it still has same errors. > > ADD_CUSTOM_COMMAND ( OUTPUT ${Qt_tmp}/moc_GMWindow.cpp > COMMAND ${QT_MOC_CMD} ${GM_DIR}/GMWindow.h -o > ${Qt_tmp}/moc_GMWindow.cpp > DEPENDS ${GM_DIR}/GMWindow.h > ) > ADD_CUSTOM_TARGET(generate_foo DEPENDS ${Qt_tmp}/moc_GMWindow.cpp) > SET_SOURCE_FILES_PROPERTIES(${Qt_tmp}/moc_GMWindow.cpp PROPERTIES > GENERATED 1) > SET_PROPERTY(SOURCE ${GM_DIR}/GMWindow.cpp APPEND PROPERTY OBJECT_DEPENDS > ${Qt_tmp}/moc_GMWindow.cpp) > > ..... > add_dependencies (GM generate_foo) > > > Does the Macro "SET_SOURCE_FILES_PROPERTIES" with "GENERATED" > setting work for this purposes? Any help would be greatly appreciated ! > > > On Wed, May 25, 2016 at 12:48 PM, irene w wrote: > >> Hi, >> >> I am compiling a simple Qt3 application on Linux using CMake. In my case, >> I need to build moc_xxx files with custom options and output to a specified >> directory, So, I was not using CAMKE_AUTO macros. My cmake scripts create a >> "Qt_tmp" directory and output moc_xxx there. >> >> It looked it always failed to link the moc_xxx files for the first time >> build when there is no "Qt_tmp" directory, and succeeded if I ran build >> again if the "Qt_tmp" directory and moc_xxx files created by the failed >> build were kept without removing. However, it'll fail if I delete >> the "Qt_tmp" directory. >> >> Even it failed at the first build, the moc_xxx files were >> successfully created in the "Qt_tmp" directory. >> >> Here is my cmake scripts and the errors I got. Can anyone help me to >> figure out the issues? Any help would be greatly appreciated. Thanks. >> >> CMakeLists.txt >> >> --------------------------------------------------------------------------------------------- >> cmake_minimum_required(VERSION 3.4.1) >> project (GM_Application CXX) >> SET (CMAKE_SYSTEM_NAME Linux) >> SET (CMAKE_CXX_COMPILER ${COMPILER_PATH}${CROSS_COMPILE}g++) >> set (GM_DIR ${CMAKE_CURRENT_SOURCE_DIR}) >> set (QT_DIR ${CMAKE_CURRENT_SOURCE_DIR}/ThirdParty/Qt/4.8.6) >> LINK_DIRECTORIES (${QT_DIR}/lib) >> INCLUDE_DIRECTORIES ("${QT_DIR}/include" >> "${GM_DIR}" >> ) >> ##### Compiling QT moc and ui ##### >> set (QT_MOC_CMD ${QT_DIR}/bin/moc -I$(QT_DIR)/mkspecs/linux-g++ >> -I${QT_DIR}/include -I${QT_DIR}/include/QtGui) >> file (MAKE_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/Qt_tmp) >> set (Qt_tmp ${CMAKE_CURRENT_SOURCE_DIR}/Qt_tmp) >> add_custom_target (Moc_GMWindows >> COMMAND ${QT_MOC_CMD} ${GM_DIR}/GMWindow.h -o >> ${Qt_tmp}/moc_GMWindow.cpp >> ) >> >> ##### Compiling application ##### >> file (GLOB GM_SOURCES ${GM_DIR}/*.h ${GM_DIR}/*.cpp) >> file (GLOB Moc_SOURCES ${Qt_tmp}/*.h ${Qt_tmp}/*.cpp) >> add_executable (GM ${GM_SOURCES} ${Moc_SOURCES}) >> target_include_directories (GM PRIVATE ${Qt_tmp}) >> add_dependencies (GM Moc_GMWindows) >> target_link_libraries (GM QtGui) >> >> >> ------------------------------------------------------------------------------------------- >> Errors: >> >> Scanning dependencies of target Moc_GMWindows >> [ 0%] Built target Moc_GMWindows >> Scanning dependencies of target GM >> [ 14%] Building CXX object GM/CMakeFiles/GM.dir/GM/GM.cpp.o >> [ 42%] Building CXX object GM/CMakeFiles/GM.dir/GM/GMService.cpp.o >> [ 67%] Building CXX object GM/CMakeFiles/GM.dir/GM/GMWindow.cpp.o >> [ 85%] Building CXX object GM/CMakeFiles/GM.dir/GM/main.cpp.o >> [100%] Linking CXX executable ../bin/GM >> CMakeFiles/GM.dir/GM/GMWindow.cpp.o: In function >> `GM::GMWindow::emitAppendMessage(QStrin >> g)': >> /GM/GMWindow.cpp:217: undefined reference to >> `GM::GMWindow::appendMessage(QString)' >> CMakeFiles/GM.dir/GM/GMWindow.cpp.o:(.rodata._ZTVN2GM8GMWindowE[vtable >> for GM::GMWindow] >> +0x8): undefined reference to `GM::GMWindow::metaObject() const' >> CMakeFiles/GM.dir/GM/GMWindow.cpp.o:(.rodata._ZTVN2GM8GMWindowE[vtable >> for GM::GMWindow] >> +0xc): undefined reference to `GM::GMWindow::qt_metacast(char const*)' >> CMakeFiles/GM.dir/GM/GMWindow.cpp.o:(.rodata._ZTVN2GM8GMWindowE[vtable >> for GM::GMWindow] >> +0x10): undefined reference to >> `GM::GMWindow::qt_metacall(QMetaObject::Call, int, void**)' >> collect2: ld returned 1 exit status >> make[2]: *** [bin/GM] Error 1 >> make[1]: *** [GM/CMakeFiles/GM.dir/all] Error 2 >> make: *** [all] Error 2 >> >> >> >> Virus-free. >> www.avast.com >> >> <#m_3542150497808946122_m_6400203814648417669_DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2> >> > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From post at hendrik-sattler.de Wed Jun 1 03:09:08 2016 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Wed, 01 Jun 2016 09:09:08 +0200 Subject: [CMake] CMake+QT always failed for the first build, and succeeded for second build or later. In-Reply-To: References: Message-ID: <01BD4CB5-3C50-4F7E-8942-AEFEA725FC80@hendrik-sattler.de> Am 1. Juni 2016 09:02:41 MESZ, schrieb Jakob van Bethlehem : >Hej, > >Some things that come to mind: >* You're generating files *inside* the source tree - you're not >supposed to >do that >* Why do you want to have a special Qt_tmp directory? I don't see the >benefit, and without that requirement you can simply use the >qt4_wrap_cpp >macro explicitly and you still are not forced to use the automoc >feature > >And now for what is probably wrong in your CMakeLists.txt: >* It seems you made an important mistake regarding the behaviour of >'file(GLOB)'. That function will do the expansion *while running >CMake*. >But at that time the moc_* files *don't exist!* (as a matter of fact, >the >tmp directory doesn't even exist). In other words, your ${Moc_SOURCES} >will >be empty, and hence they are not compiled, and hence you get precisely >the >linker errors you see (because these sources implement the functions >that >are listed as missing by the linker) > >If you would use the qt4_wrap_cpp() macro you don't run into this >problem, >so I'd strongly suggest using it. Except that he is using Qt3. >Sincerely, >Jakob van Bethlehem > > > > >On Tue, May 31, 2016 at 4:52 PM, irene w wrote: > >> It seems CMakw could not find the generated moc_xxx files. I >modified the >> scripts to specify moc_xxx files is generated, but it still has same >errors. >> >> ADD_CUSTOM_COMMAND ( OUTPUT ${Qt_tmp}/moc_GMWindow.cpp >> COMMAND ${QT_MOC_CMD} ${GM_DIR}/GMWindow.h -o >> ${Qt_tmp}/moc_GMWindow.cpp >> DEPENDS ${GM_DIR}/GMWindow.h >> ) >> ADD_CUSTOM_TARGET(generate_foo DEPENDS ${Qt_tmp}/moc_GMWindow.cpp) >> SET_SOURCE_FILES_PROPERTIES(${Qt_tmp}/moc_GMWindow.cpp PROPERTIES >> GENERATED 1) >> SET_PROPERTY(SOURCE ${GM_DIR}/GMWindow.cpp APPEND PROPERTY >OBJECT_DEPENDS >> ${Qt_tmp}/moc_GMWindow.cpp) >> >> ..... >> add_dependencies (GM generate_foo) >> >> >> Does the Macro "SET_SOURCE_FILES_PROPERTIES" with "GENERATED" >> setting work for this purposes? Any help would be greatly >appreciated ! >> >> >> On Wed, May 25, 2016 at 12:48 PM, irene w >wrote: >> >>> Hi, >>> >>> I am compiling a simple Qt3 application on Linux using CMake. In my >case, >>> I need to build moc_xxx files with custom options and output to a >specified >>> directory, So, I was not using CAMKE_AUTO macros. My cmake scripts >create a >>> "Qt_tmp" directory and output moc_xxx there. >>> >>> It looked it always failed to link the moc_xxx files for the first >time >>> build when there is no "Qt_tmp" directory, and succeeded if I ran >build >>> again if the "Qt_tmp" directory and moc_xxx files created by the >failed >>> build were kept without removing. However, it'll fail if I delete >>> the "Qt_tmp" directory. >>> >>> Even it failed at the first build, the moc_xxx files were >>> successfully created in the "Qt_tmp" directory. >>> >>> Here is my cmake scripts and the errors I got. Can anyone help me >to >>> figure out the issues? Any help would be greatly appreciated. >Thanks. >>> >>> CMakeLists.txt >>> >>> >--------------------------------------------------------------------------------------------- >>> cmake_minimum_required(VERSION 3.4.1) >>> project (GM_Application CXX) >>> SET (CMAKE_SYSTEM_NAME Linux) >>> SET (CMAKE_CXX_COMPILER ${COMPILER_PATH}${CROSS_COMPILE}g++) >>> set (GM_DIR ${CMAKE_CURRENT_SOURCE_DIR}) >>> set (QT_DIR ${CMAKE_CURRENT_SOURCE_DIR}/ThirdParty/Qt/4.8.6) >>> LINK_DIRECTORIES (${QT_DIR}/lib) >>> INCLUDE_DIRECTORIES ("${QT_DIR}/include" >>> "${GM_DIR}" >>> ) >>> ##### Compiling QT moc and ui ##### >>> set (QT_MOC_CMD ${QT_DIR}/bin/moc -I$(QT_DIR)/mkspecs/linux-g++ >>> -I${QT_DIR}/include -I${QT_DIR}/include/QtGui) >>> file (MAKE_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/Qt_tmp) >>> set (Qt_tmp ${CMAKE_CURRENT_SOURCE_DIR}/Qt_tmp) >>> add_custom_target (Moc_GMWindows >>> COMMAND ${QT_MOC_CMD} ${GM_DIR}/GMWindow.h -o >>> ${Qt_tmp}/moc_GMWindow.cpp >>> ) >>> >>> ##### Compiling application ##### >>> file (GLOB GM_SOURCES ${GM_DIR}/*.h ${GM_DIR}/*.cpp) >>> file (GLOB Moc_SOURCES ${Qt_tmp}/*.h ${Qt_tmp}/*.cpp) >>> add_executable (GM ${GM_SOURCES} ${Moc_SOURCES}) >>> target_include_directories (GM PRIVATE ${Qt_tmp}) >>> add_dependencies (GM Moc_GMWindows) >>> target_link_libraries (GM QtGui) >>> >>> >>> >------------------------------------------------------------------------------------------- >>> Errors: >>> >>> Scanning dependencies of target Moc_GMWindows >>> [ 0%] Built target Moc_GMWindows >>> Scanning dependencies of target GM >>> [ 14%] Building CXX object GM/CMakeFiles/GM.dir/GM/GM.cpp.o >>> [ 42%] Building CXX object GM/CMakeFiles/GM.dir/GM/GMService.cpp.o >>> [ 67%] Building CXX object GM/CMakeFiles/GM.dir/GM/GMWindow.cpp.o >>> [ 85%] Building CXX object GM/CMakeFiles/GM.dir/GM/main.cpp.o >>> [100%] Linking CXX executable ../bin/GM >>> CMakeFiles/GM.dir/GM/GMWindow.cpp.o: In function >>> `GM::GMWindow::emitAppendMessage(QStrin >>> g)': >>> /GM/GMWindow.cpp:217: undefined reference to >>> `GM::GMWindow::appendMessage(QString)' >>> >CMakeFiles/GM.dir/GM/GMWindow.cpp.o:(.rodata._ZTVN2GM8GMWindowE[vtable >>> for GM::GMWindow] >>> +0x8): undefined reference to `GM::GMWindow::metaObject() const' >>> >CMakeFiles/GM.dir/GM/GMWindow.cpp.o:(.rodata._ZTVN2GM8GMWindowE[vtable >>> for GM::GMWindow] >>> +0xc): undefined reference to `GM::GMWindow::qt_metacast(char >const*)' >>> >CMakeFiles/GM.dir/GM/GMWindow.cpp.o:(.rodata._ZTVN2GM8GMWindowE[vtable >>> for GM::GMWindow] >>> +0x10): undefined reference to >>> `GM::GMWindow::qt_metacall(QMetaObject::Call, int, void**)' >>> collect2: ld returned 1 exit status >>> make[2]: *** [bin/GM] Error 1 >>> make[1]: *** [GM/CMakeFiles/GM.dir/all] Error 2 >>> make: *** [all] Error 2 >>> >>> >>> >>> > >Virus-free. >>> www.avast.com >>> > >>> ><#m_3542150497808946122_m_6400203814648417669_DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2> >>> >> >> >> -- >> >> 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 >> > > >------------------------------------------------------------------------ -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. From jsvanbethlehem at gmail.com Wed Jun 1 03:26:18 2016 From: jsvanbethlehem at gmail.com (Jakob van Bethlehem) Date: Wed, 1 Jun 2016 09:26:18 +0200 Subject: [CMake] CMake+QT always failed for the first build, and succeeded for second build or later. In-Reply-To: <01BD4CB5-3C50-4F7E-8942-AEFEA725FC80@hendrik-sattler.de> References: <01BD4CB5-3C50-4F7E-8942-AEFEA725FC80@hendrik-sattler.de> Message-ID: That is what he said, but it seems to be a typo, because the CMakeLists.txt file clearly states 'set(QT_DIR ${CMAKE_CURRENT_SOURCE_DIR}/ThirdParty/Qt/4.8.6)' - still a stone-age version of Qt actually :( Sincerely, Jakob van Bethlehem On Wed, Jun 1, 2016 at 9:09 AM, Hendrik Sattler wrote: > > > Am 1. Juni 2016 09:02:41 MESZ, schrieb Jakob van Bethlehem < > jsvanbethlehem at gmail.com>: > >Hej, > > > >Some things that come to mind: > >* You're generating files *inside* the source tree - you're not > >supposed to > >do that > >* Why do you want to have a special Qt_tmp directory? I don't see the > >benefit, and without that requirement you can simply use the > >qt4_wrap_cpp > >macro explicitly and you still are not forced to use the automoc > >feature > > > >And now for what is probably wrong in your CMakeLists.txt: > >* It seems you made an important mistake regarding the behaviour of > >'file(GLOB)'. That function will do the expansion *while running > >CMake*. > >But at that time the moc_* files *don't exist!* (as a matter of fact, > >the > >tmp directory doesn't even exist). In other words, your ${Moc_SOURCES} > >will > >be empty, and hence they are not compiled, and hence you get precisely > >the > >linker errors you see (because these sources implement the functions > >that > >are listed as missing by the linker) > > > >If you would use the qt4_wrap_cpp() macro you don't run into this > >problem, > >so I'd strongly suggest using it. > > Except that he is using Qt3. > > >Sincerely, > >Jakob van Bethlehem > > > > > > > > > >On Tue, May 31, 2016 at 4:52 PM, irene w wrote: > > > >> It seems CMakw could not find the generated moc_xxx files. I > >modified the > >> scripts to specify moc_xxx files is generated, but it still has same > >errors. > >> > >> ADD_CUSTOM_COMMAND ( OUTPUT ${Qt_tmp}/moc_GMWindow.cpp > >> COMMAND ${QT_MOC_CMD} ${GM_DIR}/GMWindow.h -o > >> ${Qt_tmp}/moc_GMWindow.cpp > >> DEPENDS ${GM_DIR}/GMWindow.h > >> ) > >> ADD_CUSTOM_TARGET(generate_foo DEPENDS ${Qt_tmp}/moc_GMWindow.cpp) > >> SET_SOURCE_FILES_PROPERTIES(${Qt_tmp}/moc_GMWindow.cpp PROPERTIES > >> GENERATED 1) > >> SET_PROPERTY(SOURCE ${GM_DIR}/GMWindow.cpp APPEND PROPERTY > >OBJECT_DEPENDS > >> ${Qt_tmp}/moc_GMWindow.cpp) > >> > >> ..... > >> add_dependencies (GM generate_foo) > >> > >> > >> Does the Macro "SET_SOURCE_FILES_PROPERTIES" with "GENERATED" > >> setting work for this purposes? Any help would be greatly > >appreciated ! > >> > >> > >> On Wed, May 25, 2016 at 12:48 PM, irene w > >wrote: > >> > >>> Hi, > >>> > >>> I am compiling a simple Qt3 application on Linux using CMake. In my > >case, > >>> I need to build moc_xxx files with custom options and output to a > >specified > >>> directory, So, I was not using CAMKE_AUTO macros. My cmake scripts > >create a > >>> "Qt_tmp" directory and output moc_xxx there. > >>> > >>> It looked it always failed to link the moc_xxx files for the first > >time > >>> build when there is no "Qt_tmp" directory, and succeeded if I ran > >build > >>> again if the "Qt_tmp" directory and moc_xxx files created by the > >failed > >>> build were kept without removing. However, it'll fail if I delete > >>> the "Qt_tmp" directory. > >>> > >>> Even it failed at the first build, the moc_xxx files were > >>> successfully created in the "Qt_tmp" directory. > >>> > >>> Here is my cmake scripts and the errors I got. Can anyone help me > >to > >>> figure out the issues? Any help would be greatly appreciated. > >Thanks. > >>> > >>> CMakeLists.txt > >>> > >>> > > >--------------------------------------------------------------------------------------------- > >>> cmake_minimum_required(VERSION 3.4.1) > >>> project (GM_Application CXX) > >>> SET (CMAKE_SYSTEM_NAME Linux) > >>> SET (CMAKE_CXX_COMPILER ${COMPILER_PATH}${CROSS_COMPILE}g++) > >>> set (GM_DIR ${CMAKE_CURRENT_SOURCE_DIR}) > >>> set (QT_DIR ${CMAKE_CURRENT_SOURCE_DIR}/ThirdParty/Qt/4.8.6) > >>> LINK_DIRECTORIES (${QT_DIR}/lib) > >>> INCLUDE_DIRECTORIES ("${QT_DIR}/include" > >>> "${GM_DIR}" > >>> ) > >>> ##### Compiling QT moc and ui ##### > >>> set (QT_MOC_CMD ${QT_DIR}/bin/moc -I$(QT_DIR)/mkspecs/linux-g++ > >>> -I${QT_DIR}/include -I${QT_DIR}/include/QtGui) > >>> file (MAKE_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/Qt_tmp) > >>> set (Qt_tmp ${CMAKE_CURRENT_SOURCE_DIR}/Qt_tmp) > >>> add_custom_target (Moc_GMWindows > >>> COMMAND ${QT_MOC_CMD} ${GM_DIR}/GMWindow.h -o > >>> ${Qt_tmp}/moc_GMWindow.cpp > >>> ) > >>> > >>> ##### Compiling application ##### > >>> file (GLOB GM_SOURCES ${GM_DIR}/*.h ${GM_DIR}/*.cpp) > >>> file (GLOB Moc_SOURCES ${Qt_tmp}/*.h ${Qt_tmp}/*.cpp) > >>> add_executable (GM ${GM_SOURCES} ${Moc_SOURCES}) > >>> target_include_directories (GM PRIVATE ${Qt_tmp}) > >>> add_dependencies (GM Moc_GMWindows) > >>> target_link_libraries (GM QtGui) > >>> > >>> > >>> > > >------------------------------------------------------------------------------------------- > >>> Errors: > >>> > >>> Scanning dependencies of target Moc_GMWindows > >>> [ 0%] Built target Moc_GMWindows > >>> Scanning dependencies of target GM > >>> [ 14%] Building CXX object GM/CMakeFiles/GM.dir/GM/GM.cpp.o > >>> [ 42%] Building CXX object GM/CMakeFiles/GM.dir/GM/GMService.cpp.o > >>> [ 67%] Building CXX object GM/CMakeFiles/GM.dir/GM/GMWindow.cpp.o > >>> [ 85%] Building CXX object GM/CMakeFiles/GM.dir/GM/main.cpp.o > >>> [100%] Linking CXX executable ../bin/GM > >>> CMakeFiles/GM.dir/GM/GMWindow.cpp.o: In function > >>> `GM::GMWindow::emitAppendMessage(QStrin > >>> g)': > >>> /GM/GMWindow.cpp:217: undefined reference to > >>> `GM::GMWindow::appendMessage(QString)' > >>> > >CMakeFiles/GM.dir/GM/GMWindow.cpp.o:(.rodata._ZTVN2GM8GMWindowE[vtable > >>> for GM::GMWindow] > >>> +0x8): undefined reference to `GM::GMWindow::metaObject() const' > >>> > >CMakeFiles/GM.dir/GM/GMWindow.cpp.o:(.rodata._ZTVN2GM8GMWindowE[vtable > >>> for GM::GMWindow] > >>> +0xc): undefined reference to `GM::GMWindow::qt_metacast(char > >const*)' > >>> > >CMakeFiles/GM.dir/GM/GMWindow.cpp.o:(.rodata._ZTVN2GM8GMWindowE[vtable > >>> for GM::GMWindow] > >>> +0x10): undefined reference to > >>> `GM::GMWindow::qt_metacall(QMetaObject::Call, int, void**)' > >>> collect2: ld returned 1 exit status > >>> make[2]: *** [bin/GM] Error 1 > >>> make[1]: *** [GM/CMakeFiles/GM.dir/all] Error 2 > >>> make: *** [all] Error 2 > >>> > >>> > >>> > >>> > >< > https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail > > > >Virus-free. > >>> www.avast.com > >>> > >< > https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail > > > >>> > > ><#m_3542150497808946122_m_6400203814648417669_DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > >>> > >> > >> > >> -- > >> > >> 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 > >> > > > > > >------------------------------------------------------------------------ > > -- > 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 post at hendrik-sattler.de Wed Jun 1 04:47:24 2016 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Wed, 01 Jun 2016 10:47:24 +0200 Subject: [CMake] CMake+QT always failed for the first build, and succeeded for second build or later. In-Reply-To: References: <01BD4CB5-3C50-4F7E-8942-AEFEA725FC80@hendrik-sattler.de> Message-ID: Am 1. Juni 2016 09:26:18 MESZ, schrieb Jakob van Bethlehem : >That is what he said, but it seems to be a typo, because the >CMakeLists.txt >file clearly states 'set(QT_DIR >${CMAKE_CURRENT_SOURCE_DIR}/ThirdParty/Qt/4.8.6)' Ok, I overlooked that one... >- still a stone-age version of Qt actually :( Hey, that was the LTS release until 1 or 2 month ago! And they made Qt 5.6 an LTS release also to quieten people that complain about dropping modules without proper replacement (means feature parity) and dropping compiler support. You will see users of Qt 5.6 for a loooooong time. >On Wed, Jun 1, 2016 at 9:09 AM, Hendrik Sattler > >wrote: > >> >> >> Am 1. Juni 2016 09:02:41 MESZ, schrieb Jakob van Bethlehem < >> jsvanbethlehem at gmail.com>: >> >Hej, >> > >> >Some things that come to mind: >> >* You're generating files *inside* the source tree - you're not >> >supposed to >> >do that >> >* Why do you want to have a special Qt_tmp directory? I don't see >the >> >benefit, and without that requirement you can simply use the >> >qt4_wrap_cpp >> >macro explicitly and you still are not forced to use the automoc >> >feature >> > >> >And now for what is probably wrong in your CMakeLists.txt: >> >* It seems you made an important mistake regarding the behaviour of >> >'file(GLOB)'. That function will do the expansion *while running >> >CMake*. >> >But at that time the moc_* files *don't exist!* (as a matter of >fact, >> >the >> >tmp directory doesn't even exist). In other words, your >${Moc_SOURCES} >> >will >> >be empty, and hence they are not compiled, and hence you get >precisely >> >the >> >linker errors you see (because these sources implement the functions >> >that >> >are listed as missing by the linker) >> > >> >If you would use the qt4_wrap_cpp() macro you don't run into this >> >problem, >> >so I'd strongly suggest using it. >> >> Except that he is using Qt3. >> >> >Sincerely, >> >Jakob van Bethlehem >> > >> > >> > >> > >> >On Tue, May 31, 2016 at 4:52 PM, irene w >wrote: >> > >> >> It seems CMakw could not find the generated moc_xxx files. I >> >modified the >> >> scripts to specify moc_xxx files is generated, but it still has >same >> >errors. >> >> >> >> ADD_CUSTOM_COMMAND ( OUTPUT ${Qt_tmp}/moc_GMWindow.cpp >> >> COMMAND ${QT_MOC_CMD} ${GM_DIR}/GMWindow.h -o >> >> ${Qt_tmp}/moc_GMWindow.cpp >> >> DEPENDS ${GM_DIR}/GMWindow.h >> >> ) >> >> ADD_CUSTOM_TARGET(generate_foo DEPENDS ${Qt_tmp}/moc_GMWindow.cpp) >> >> SET_SOURCE_FILES_PROPERTIES(${Qt_tmp}/moc_GMWindow.cpp PROPERTIES >> >> GENERATED 1) >> >> SET_PROPERTY(SOURCE ${GM_DIR}/GMWindow.cpp APPEND PROPERTY >> >OBJECT_DEPENDS >> >> ${Qt_tmp}/moc_GMWindow.cpp) >> >> >> >> ..... >> >> add_dependencies (GM generate_foo) >> >> >> >> >> >> Does the Macro "SET_SOURCE_FILES_PROPERTIES" with "GENERATED" >> >> setting work for this purposes? Any help would be greatly >> >appreciated ! >> >> >> >> >> >> On Wed, May 25, 2016 at 12:48 PM, irene w >> >wrote: >> >> >> >>> Hi, >> >>> >> >>> I am compiling a simple Qt3 application on Linux using CMake. In >my >> >case, >> >>> I need to build moc_xxx files with custom options and output to a >> >specified >> >>> directory, So, I was not using CAMKE_AUTO macros. My cmake >scripts >> >create a >> >>> "Qt_tmp" directory and output moc_xxx there. >> >>> >> >>> It looked it always failed to link the moc_xxx files for the >first >> >time >> >>> build when there is no "Qt_tmp" directory, and succeeded if I ran >> >build >> >>> again if the "Qt_tmp" directory and moc_xxx files created by the >> >failed >> >>> build were kept without removing. However, it'll fail if I >delete >> >>> the "Qt_tmp" directory. >> >>> >> >>> Even it failed at the first build, the moc_xxx files were >> >>> successfully created in the "Qt_tmp" directory. >> >>> >> >>> Here is my cmake scripts and the errors I got. Can anyone help >me >> >to >> >>> figure out the issues? Any help would be greatly appreciated. >> >Thanks. >> >>> >> >>> CMakeLists.txt >> >>> >> >>> >> >> >>--------------------------------------------------------------------------------------------- >> >>> cmake_minimum_required(VERSION 3.4.1) >> >>> project (GM_Application CXX) >> >>> SET (CMAKE_SYSTEM_NAME Linux) >> >>> SET (CMAKE_CXX_COMPILER ${COMPILER_PATH}${CROSS_COMPILE}g++) >> >>> set (GM_DIR ${CMAKE_CURRENT_SOURCE_DIR}) >> >>> set (QT_DIR ${CMAKE_CURRENT_SOURCE_DIR}/ThirdParty/Qt/4.8.6) >> >>> LINK_DIRECTORIES (${QT_DIR}/lib) >> >>> INCLUDE_DIRECTORIES ("${QT_DIR}/include" >> >>> "${GM_DIR}" >> >>> ) >> >>> ##### Compiling QT moc and ui ##### >> >>> set (QT_MOC_CMD ${QT_DIR}/bin/moc -I$(QT_DIR)/mkspecs/linux-g++ >> >>> -I${QT_DIR}/include -I${QT_DIR}/include/QtGui) >> >>> file (MAKE_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/Qt_tmp) >> >>> set (Qt_tmp ${CMAKE_CURRENT_SOURCE_DIR}/Qt_tmp) >> >>> add_custom_target (Moc_GMWindows >> >>> COMMAND ${QT_MOC_CMD} ${GM_DIR}/GMWindow.h -o >> >>> ${Qt_tmp}/moc_GMWindow.cpp >> >>> ) >> >>> >> >>> ##### Compiling application ##### >> >>> file (GLOB GM_SOURCES ${GM_DIR}/*.h ${GM_DIR}/*.cpp) >> >>> file (GLOB Moc_SOURCES ${Qt_tmp}/*.h ${Qt_tmp}/*.cpp) >> >>> add_executable (GM ${GM_SOURCES} ${Moc_SOURCES}) >> >>> target_include_directories (GM PRIVATE ${Qt_tmp}) >> >>> add_dependencies (GM Moc_GMWindows) >> >>> target_link_libraries (GM QtGui) >> >>> >> >>> >> >>> >> >> >>------------------------------------------------------------------------------------------- >> >>> Errors: >> >>> >> >>> Scanning dependencies of target Moc_GMWindows >> >>> [ 0%] Built target Moc_GMWindows >> >>> Scanning dependencies of target GM >> >>> [ 14%] Building CXX object GM/CMakeFiles/GM.dir/GM/GM.cpp.o >> >>> [ 42%] Building CXX object >GM/CMakeFiles/GM.dir/GM/GMService.cpp.o >> >>> [ 67%] Building CXX object GM/CMakeFiles/GM.dir/GM/GMWindow.cpp.o >> >>> [ 85%] Building CXX object GM/CMakeFiles/GM.dir/GM/main.cpp.o >> >>> [100%] Linking CXX executable ../bin/GM >> >>> CMakeFiles/GM.dir/GM/GMWindow.cpp.o: In function >> >>> `GM::GMWindow::emitAppendMessage(QStrin >> >>> g)': >> >>> /GM/GMWindow.cpp:217: undefined reference to >> >>> `GM::GMWindow::appendMessage(QString)' >> >>> >> >>CMakeFiles/GM.dir/GM/GMWindow.cpp.o:(.rodata._ZTVN2GM8GMWindowE[vtable >> >>> for GM::GMWindow] >> >>> +0x8): undefined reference to `GM::GMWindow::metaObject() const' >> >>> >> >>CMakeFiles/GM.dir/GM/GMWindow.cpp.o:(.rodata._ZTVN2GM8GMWindowE[vtable >> >>> for GM::GMWindow] >> >>> +0xc): undefined reference to `GM::GMWindow::qt_metacast(char >> >const*)' >> >>> >> >>CMakeFiles/GM.dir/GM/GMWindow.cpp.o:(.rodata._ZTVN2GM8GMWindowE[vtable >> >>> for GM::GMWindow] >> >>> +0x10): undefined reference to >> >>> `GM::GMWindow::qt_metacall(QMetaObject::Call, int, void**)' >> >>> collect2: ld returned 1 exit status >> >>> make[2]: *** [bin/GM] Error 1 >> >>> make[1]: *** [GM/CMakeFiles/GM.dir/all] Error 2 >> >>> make: *** [all] Error 2 >> >>> >> >>> >> >>> >> >>> >> >< >> >https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail >> > >> >Virus-free. >> >>> www.avast.com >> >>> >> >< >> >https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail >> > >> >>> >> >> >><#m_3542150497808946122_m_6400203814648417669_DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2> >> >>> >> >> >> >> >> >> -- >> >> >> >> 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 >> >> >> > >> > >> >>------------------------------------------------------------------------ >> >> -- >> 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 >> > > >------------------------------------------------------------------------ -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. From Jakub.Golebiewski at dnvgl.com Wed Jun 1 05:16:48 2016 From: Jakub.Golebiewski at dnvgl.com (Golebiewski, Jakub) Date: Wed, 1 Jun 2016 09:16:48 +0000 Subject: [CMake] CMake error output and .vcxproj.filters files. Message-ID: Hi, We've recently switched to using cmake and I've got some 'issues'. We use Windows with Visual Studio and MSVC (Visual Studio 10 2010 Win64 generator). 1. In cmake error output the output format is not compatible with VS so when the VS console displays it, you cannot click on the filename to open it: I get this: 1> CMake Error at D:/depot/ef/wrk/CMakeLists.txt:210 (GET_TARGET_PROPERTY): And it should look like this for VS to work: 1> CMake Error at D:/depot/ef/wrk/CMakeLists.txt(210) (GET_TARGET_PROPERTY): Can I change the format in CMakeLists.txt or do I need to patch the sources? In the case of the latter could you point me to right place in the code? 2. When I get an error in CMake it displays the CMakeListst.txt file, the error occurred in and the root file. Is this possible to get the whole 'stack trace' with all the files That are involved (through ADD_SUBDIRECTORY)? 3. CMake seems to generate .vcxproj.filters files as well as .vcxproj files. Is there a way to turn this off so people could use their own .filters files? Thanks for help! Best regards for Det Norske Veritas Poland Sp. z o.o. Jakub Golebiewski M.Sc Software Engineer, Development Gdynia E-mail jakub.golebiewski at dnvgl.com Mobile +48 606 33 66 59 www.dnvgl.com | LinkedIn [DNV GL] ************************************************************************************** This e-mail and any attachments thereto may contain confidential information and/or information protected by intellectual property rights for the exclusive attention of the intended addressees named above. If you have received this transmission in error, please immediately notify the sender by return e-mail and delete this message and its attachments. Unauthorized use, copying or further full or partial distribution of this e-mail or its contents is prohibited. ************************************************************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2815 bytes Desc: image001.gif URL: From zhangpeixuan.cn at gmail.com Wed Jun 1 05:50:31 2016 From: zhangpeixuan.cn at gmail.com (Zhang Peixuan) Date: Wed, 1 Jun 2016 17:50:31 +0800 Subject: [CMake] How to use CMAKE_MFC_FLAG for only one on executables? Message-ID: Hello All, I want to use CMake to manage my MFC projects, and I added the following code: set( CMAKE_MFC_FLAG 2) add_executable(MFCDemo WIN32 ${MFC_RESOURCE_FILES} ${MFC_HEADER_FILES} ${MFC_SOURCE_FILES} ) target_compile_definitions(MFCDemo PUBLIC -D_AFXDLL=1 PUBLIC -D_UNICODE PUBLIC -DUNICODE ) It works. However, my question is that: In addition to the MFC executable, I still have some non-MFC executables, and once CMAKE_MFC_FLAG is set, all the add_executables' property should be "Use MFC in a Shared DLL". In fact, I want only one MFC executable, and make sure all other executables are "Use Standard Windows Library". Is there any way to implement it? It seems CMAKE_MFC_FLAG does not work with set_target_property or other commands. Thanks, Peixuan Zhang -------------- next part -------------- An HTML attachment was scrubbed... URL: From chrysalisx at gmail.com Wed Jun 1 06:10:22 2016 From: chrysalisx at gmail.com (Walter Gray) Date: Wed, 01 Jun 2016 10:10:22 +0000 Subject: [CMake] Unit Testing for CMake Scripts Message-ID: I was about to ask the list, but some googling lead me to this: https://github.com/polysquare/cmake-unit I am not the developer, but he doesn't appear to be on here so I thought I should share. This looks incredibly useful -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsvanbethlehem at gmail.com Wed Jun 1 07:08:23 2016 From: jsvanbethlehem at gmail.com (Jakob van Bethlehem) Date: Wed, 1 Jun 2016 13:08:23 +0200 Subject: [CMake] CMake+QT always failed for the first build, and succeeded for second build or later. In-Reply-To: References: <01BD4CB5-3C50-4F7E-8942-AEFEA725FC80@hendrik-sattler.de> Message-ID: > Hey, that was the LTS release until 1 or 2 month ago! Oops, you're right, my mistake. Somewhere in the back of my head was that the 4-series was in the 4.12.x or so version, not sure where that came from. I haven't worked with Qt4 ever, but have become extremely experienced with Qt5 from Qt 5.4 onwards. Nevertheless, I should've checked before mentioning it :P. Sincerely, Jakob van Bethlehem On Wed, Jun 1, 2016 at 10:47 AM, Hendrik Sattler wrote: > > > Am 1. Juni 2016 09:26:18 MESZ, schrieb Jakob van Bethlehem < > jsvanbethlehem at gmail.com>: > >That is what he said, but it seems to be a typo, because the > >CMakeLists.txt > >file clearly states 'set(QT_DIR > >${CMAKE_CURRENT_SOURCE_DIR}/ThirdParty/Qt/4.8.6)' > > Ok, I overlooked that one... > > >- still a stone-age version of Qt actually :( > > Hey, that was the LTS release until 1 or 2 month ago! > And they made Qt 5.6 an LTS release also to quieten people that complain > about dropping modules without proper replacement (means feature parity) > and dropping compiler support. > You will see users of Qt 5.6 for a loooooong time. > > >On Wed, Jun 1, 2016 at 9:09 AM, Hendrik Sattler > > > >wrote: > > > >> > >> > >> Am 1. Juni 2016 09:02:41 MESZ, schrieb Jakob van Bethlehem < > >> jsvanbethlehem at gmail.com>: > >> >Hej, > >> > > >> >Some things that come to mind: > >> >* You're generating files *inside* the source tree - you're not > >> >supposed to > >> >do that > >> >* Why do you want to have a special Qt_tmp directory? I don't see > >the > >> >benefit, and without that requirement you can simply use the > >> >qt4_wrap_cpp > >> >macro explicitly and you still are not forced to use the automoc > >> >feature > >> > > >> >And now for what is probably wrong in your CMakeLists.txt: > >> >* It seems you made an important mistake regarding the behaviour of > >> >'file(GLOB)'. That function will do the expansion *while running > >> >CMake*. > >> >But at that time the moc_* files *don't exist!* (as a matter of > >fact, > >> >the > >> >tmp directory doesn't even exist). In other words, your > >${Moc_SOURCES} > >> >will > >> >be empty, and hence they are not compiled, and hence you get > >precisely > >> >the > >> >linker errors you see (because these sources implement the functions > >> >that > >> >are listed as missing by the linker) > >> > > >> >If you would use the qt4_wrap_cpp() macro you don't run into this > >> >problem, > >> >so I'd strongly suggest using it. > >> > >> Except that he is using Qt3. > >> > >> >Sincerely, > >> >Jakob van Bethlehem > >> > > >> > > >> > > >> > > >> >On Tue, May 31, 2016 at 4:52 PM, irene w > >wrote: > >> > > >> >> It seems CMakw could not find the generated moc_xxx files. I > >> >modified the > >> >> scripts to specify moc_xxx files is generated, but it still has > >same > >> >errors. > >> >> > >> >> ADD_CUSTOM_COMMAND ( OUTPUT ${Qt_tmp}/moc_GMWindow.cpp > >> >> COMMAND ${QT_MOC_CMD} ${GM_DIR}/GMWindow.h -o > >> >> ${Qt_tmp}/moc_GMWindow.cpp > >> >> DEPENDS ${GM_DIR}/GMWindow.h > >> >> ) > >> >> ADD_CUSTOM_TARGET(generate_foo DEPENDS ${Qt_tmp}/moc_GMWindow.cpp) > >> >> SET_SOURCE_FILES_PROPERTIES(${Qt_tmp}/moc_GMWindow.cpp PROPERTIES > >> >> GENERATED 1) > >> >> SET_PROPERTY(SOURCE ${GM_DIR}/GMWindow.cpp APPEND PROPERTY > >> >OBJECT_DEPENDS > >> >> ${Qt_tmp}/moc_GMWindow.cpp) > >> >> > >> >> ..... > >> >> add_dependencies (GM generate_foo) > >> >> > >> >> > >> >> Does the Macro "SET_SOURCE_FILES_PROPERTIES" with "GENERATED" > >> >> setting work for this purposes? Any help would be greatly > >> >appreciated ! > >> >> > >> >> > >> >> On Wed, May 25, 2016 at 12:48 PM, irene w > >> >wrote: > >> >> > >> >>> Hi, > >> >>> > >> >>> I am compiling a simple Qt3 application on Linux using CMake. In > >my > >> >case, > >> >>> I need to build moc_xxx files with custom options and output to a > >> >specified > >> >>> directory, So, I was not using CAMKE_AUTO macros. My cmake > >scripts > >> >create a > >> >>> "Qt_tmp" directory and output moc_xxx there. > >> >>> > >> >>> It looked it always failed to link the moc_xxx files for the > >first > >> >time > >> >>> build when there is no "Qt_tmp" directory, and succeeded if I ran > >> >build > >> >>> again if the "Qt_tmp" directory and moc_xxx files created by the > >> >failed > >> >>> build were kept without removing. However, it'll fail if I > >delete > >> >>> the "Qt_tmp" directory. > >> >>> > >> >>> Even it failed at the first build, the moc_xxx files were > >> >>> successfully created in the "Qt_tmp" directory. > >> >>> > >> >>> Here is my cmake scripts and the errors I got. Can anyone help > >me > >> >to > >> >>> figure out the issues? Any help would be greatly appreciated. > >> >Thanks. > >> >>> > >> >>> CMakeLists.txt > >> >>> > >> >>> > >> > >> > > >>--------------------------------------------------------------------------------------------- > >> >>> cmake_minimum_required(VERSION 3.4.1) > >> >>> project (GM_Application CXX) > >> >>> SET (CMAKE_SYSTEM_NAME Linux) > >> >>> SET (CMAKE_CXX_COMPILER ${COMPILER_PATH}${CROSS_COMPILE}g++) > >> >>> set (GM_DIR ${CMAKE_CURRENT_SOURCE_DIR}) > >> >>> set (QT_DIR ${CMAKE_CURRENT_SOURCE_DIR}/ThirdParty/Qt/4.8.6) > >> >>> LINK_DIRECTORIES (${QT_DIR}/lib) > >> >>> INCLUDE_DIRECTORIES ("${QT_DIR}/include" > >> >>> "${GM_DIR}" > >> >>> ) > >> >>> ##### Compiling QT moc and ui ##### > >> >>> set (QT_MOC_CMD ${QT_DIR}/bin/moc -I$(QT_DIR)/mkspecs/linux-g++ > >> >>> -I${QT_DIR}/include -I${QT_DIR}/include/QtGui) > >> >>> file (MAKE_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/Qt_tmp) > >> >>> set (Qt_tmp ${CMAKE_CURRENT_SOURCE_DIR}/Qt_tmp) > >> >>> add_custom_target (Moc_GMWindows > >> >>> COMMAND ${QT_MOC_CMD} ${GM_DIR}/GMWindow.h -o > >> >>> ${Qt_tmp}/moc_GMWindow.cpp > >> >>> ) > >> >>> > >> >>> ##### Compiling application ##### > >> >>> file (GLOB GM_SOURCES ${GM_DIR}/*.h ${GM_DIR}/*.cpp) > >> >>> file (GLOB Moc_SOURCES ${Qt_tmp}/*.h ${Qt_tmp}/*.cpp) > >> >>> add_executable (GM ${GM_SOURCES} ${Moc_SOURCES}) > >> >>> target_include_directories (GM PRIVATE ${Qt_tmp}) > >> >>> add_dependencies (GM Moc_GMWindows) > >> >>> target_link_libraries (GM QtGui) > >> >>> > >> >>> > >> >>> > >> > >> > > >>------------------------------------------------------------------------------------------- > >> >>> Errors: > >> >>> > >> >>> Scanning dependencies of target Moc_GMWindows > >> >>> [ 0%] Built target Moc_GMWindows > >> >>> Scanning dependencies of target GM > >> >>> [ 14%] Building CXX object GM/CMakeFiles/GM.dir/GM/GM.cpp.o > >> >>> [ 42%] Building CXX object > >GM/CMakeFiles/GM.dir/GM/GMService.cpp.o > >> >>> [ 67%] Building CXX object GM/CMakeFiles/GM.dir/GM/GMWindow.cpp.o > >> >>> [ 85%] Building CXX object GM/CMakeFiles/GM.dir/GM/main.cpp.o > >> >>> [100%] Linking CXX executable ../bin/GM > >> >>> CMakeFiles/GM.dir/GM/GMWindow.cpp.o: In function > >> >>> `GM::GMWindow::emitAppendMessage(QStrin > >> >>> g)': > >> >>> /GM/GMWindow.cpp:217: undefined reference to > >> >>> `GM::GMWindow::appendMessage(QString)' > >> >>> > >> > >>CMakeFiles/GM.dir/GM/GMWindow.cpp.o:(.rodata._ZTVN2GM8GMWindowE[vtable > >> >>> for GM::GMWindow] > >> >>> +0x8): undefined reference to `GM::GMWindow::metaObject() const' > >> >>> > >> > >>CMakeFiles/GM.dir/GM/GMWindow.cpp.o:(.rodata._ZTVN2GM8GMWindowE[vtable > >> >>> for GM::GMWindow] > >> >>> +0xc): undefined reference to `GM::GMWindow::qt_metacast(char > >> >const*)' > >> >>> > >> > >>CMakeFiles/GM.dir/GM/GMWindow.cpp.o:(.rodata._ZTVN2GM8GMWindowE[vtable > >> >>> for GM::GMWindow] > >> >>> +0x10): undefined reference to > >> >>> `GM::GMWindow::qt_metacall(QMetaObject::Call, int, void**)' > >> >>> collect2: ld returned 1 exit status > >> >>> make[2]: *** [bin/GM] Error 1 > >> >>> make[1]: *** [GM/CMakeFiles/GM.dir/all] Error 2 > >> >>> make: *** [all] Error 2 > >> >>> > >> >>> > >> >>> > >> >>> > >> >< > >> > > > https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail > >> > > >> >Virus-free. > >> >>> www.avast.com > >> >>> > >> >< > >> > > > https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail > >> > > >> >>> > >> > >> > > >><#m_3542150497808946122_m_6400203814648417669_DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > >> >>> > >> >> > >> >> > >> >> -- > >> >> > >> >> 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 > >> >> > >> > > >> > > >> > >>------------------------------------------------------------------------ > >> > >> -- > >> 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 > >> > > > > > >------------------------------------------------------------------------ > > -- > Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail > gesendet. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From annulen at yandex.ru Wed Jun 1 07:16:43 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Wed, 01 Jun 2016 14:16:43 +0300 Subject: [CMake] CMake+QT always failed for the first build, and succeeded for second build or later. In-Reply-To: References: <01BD4CB5-3C50-4F7E-8942-AEFEA725FC80@hendrik-sattler.de> Message-ID: <223791464779803@web16j.yandex.ru> 01.06.2016, 14:09, "Jakob van Bethlehem" : >>?Hey, that was the LTS release until 1 or 2 month ago! > > Oops, you're right, my mistake. Somewhere in the back of my head was that the 4-series was in the 4.12.x or so version, not sure where that came from. KDE 4 I guess (it went up to 4.14) > I haven't worked with Qt4 ever, but have become extremely experienced with Qt5 from Qt 5.4 onwards. Nevertheless, I should've checked before mentioning it :P. > > Sincerely, > Jakob van Bethlehem > > On Wed, Jun 1, 2016 at 10:47 AM, Hendrik Sattler wrote: >> Am 1. Juni 2016 09:26:18 MESZ, schrieb Jakob van Bethlehem : >>>That is what he said, but it seems to be a typo, because the >>>CMakeLists.txt >>>file clearly states 'set(QT_DIR >>>${CMAKE_CURRENT_SOURCE_DIR}/ThirdParty/Qt/4.8.6)' >> >> Ok, I overlooked that one... >> >>>- still a stone-age version of Qt actually :( >> >> Hey, that was the LTS release until 1 or 2 month ago! >> And they made Qt 5.6 an LTS release also to quieten people that complain about dropping modules without proper replacement (means feature parity) and dropping compiler support. >> You will see users of Qt 5.6 for a loooooong time. >> >>>On Wed, Jun 1, 2016 at 9:09 AM, Hendrik Sattler >>> >>>wrote: >>> >>>> >>>> >>>> Am 1. Juni 2016 09:02:41 MESZ, schrieb Jakob van Bethlehem < >>>> jsvanbethlehem at gmail.com>: >>>> >Hej, >>>> > >>>> >Some things that come to mind: >>>> >* You're generating files *inside* the source tree - you're not >>>> >supposed to >>>> >do that >>>> >* Why do you want to have a special Qt_tmp directory? I don't see >>>the >>>> >benefit, and without that requirement you can simply use the >>>> >qt4_wrap_cpp >>>> >macro explicitly and you still are not forced to use the automoc >>>> >feature >>>> > >>>> >And now for what is probably wrong in your CMakeLists.txt: >>>> >* It seems you made an important mistake regarding the behaviour of >>>> >'file(GLOB)'. That function will do the expansion *while running >>>> >CMake*. >>>> >But at that time the moc_* files *don't exist!* (as a matter of >>>fact, >>>> >the >>>> >tmp directory doesn't even exist). In other words, your >>>${Moc_SOURCES} >>>> >will >>>> >be empty, and hence they are not compiled, and hence you get >>>precisely >>>> >the >>>> >linker errors you see (because these sources implement the functions >>>> >that >>>> >are listed as missing by the linker) >>>> > >>>> >If you would use the qt4_wrap_cpp() macro you don't run into this >>>> >problem, >>>> >so I'd strongly suggest using it. >>>> >>>> Except that he is using Qt3. >>>> >>>> >Sincerely, >>>> >Jakob van Bethlehem >>>> > >>>> > >>>> > >>>> > >>>> >On Tue, May 31, 2016 at 4:52 PM, irene w >>>wrote: >>>> > >>>> >> It seems CMakw could not find the generated moc_xxx files.? I >>>> >modified the >>>> >> scripts to specify moc_xxx files is generated, but it still has >>>same >>>> >errors. >>>> >> >>>> >> ADD_CUSTOM_COMMAND ( OUTPUT ${Qt_tmp}/moc_GMWindow.cpp >>>> >>? ? ? ? ? ? ? ? ? ? ? COMMAND ${QT_MOC_CMD} ${GM_DIR}/GMWindow.h -o >>>> >> ${Qt_tmp}/moc_GMWindow.cpp >>>> >>? ? ? ? ? ? ? ? ? ? ? DEPENDS ${GM_DIR}/GMWindow.h >>>> >>? ? ? ? ? ? ? ? ? ? ) >>>> >> ADD_CUSTOM_TARGET(generate_foo DEPENDS ${Qt_tmp}/moc_GMWindow.cpp) >>>> >> SET_SOURCE_FILES_PROPERTIES(${Qt_tmp}/moc_GMWindow.cpp PROPERTIES >>>> >> GENERATED 1) >>>> >> SET_PROPERTY(SOURCE ${GM_DIR}/GMWindow.cpp APPEND PROPERTY >>>> >OBJECT_DEPENDS >>>> >> ${Qt_tmp}/moc_GMWindow.cpp) >>>> >> >>>> >> ..... >>>> >> add_dependencies (GM generate_foo) >>>> >> >>>> >> >>>> >> Does the Macro? "SET_SOURCE_FILES_PROPERTIES" with "GENERATED" >>>> >> setting work for this purposes?? Any help would be greatly >>>> >appreciated ! >>>> >> >>>> >> >>>> >> On Wed, May 25, 2016 at 12:48 PM, irene w >>>> >wrote: >>>> >> >>>> >>> Hi, >>>> >>> >>>> >>> I am compiling a simple Qt3 application on Linux using CMake. In >>>my >>>> >case, >>>> >>> I need to build moc_xxx files with custom options and output to a >>>> >specified >>>> >>> directory, So, I was not using CAMKE_AUTO macros. My cmake >>>scripts >>>> >create a >>>> >>> "Qt_tmp" directory and output moc_xxx there. >>>> >>> >>>> >>> It looked it always failed to link the moc_xxx files for the >>>first >>>> >time >>>> >>> build when there is no "Qt_tmp" directory, and succeeded if I ran >>>> >build >>>> >>> again if the "Qt_tmp" directory and moc_xxx files created by the >>>> >failed >>>> >>> build were kept without removing.? However, it'll fail if I >>>delete >>>> >>> the "Qt_tmp" directory. >>>> >>> >>>> >>> Even it failed at the first build, the moc_xxx files were >>>> >>> successfully created in the "Qt_tmp" directory. >>>> >>> >>>> >>> Here is my cmake scripts and the errors I got.? Can anyone help >>>me >>>> >to >>>> >>> figure out the issues? Any help would be greatly appreciated. >>>> >Thanks. >>>> >>> >>>> >>> CMakeLists.txt >>>> >>> >>>> >>> >>>> >>>> >>>>--------------------------------------------------------------------------------------------- >>>> >>> cmake_minimum_required(VERSION 3.4.1) >>>> >>> project (GM_Application CXX) >>>> >>> SET (CMAKE_SYSTEM_NAME Linux) >>>> >>> SET (CMAKE_CXX_COMPILER ${COMPILER_PATH}${CROSS_COMPILE}g++) >>>> >>> set (GM_DIR ${CMAKE_CURRENT_SOURCE_DIR}) >>>> >>> set (QT_DIR ${CMAKE_CURRENT_SOURCE_DIR}/ThirdParty/Qt/4.8.6) >>>> >>> LINK_DIRECTORIES (${QT_DIR}/lib) >>>> >>> INCLUDE_DIRECTORIES ("${QT_DIR}/include" >>>> >>>? ? ? ? ? ? ? ? ? ? ? "${GM_DIR}" >>>> >>> ) >>>> >>> ##### Compiling QT moc and ui? ##### >>>> >>> set (QT_MOC_CMD ${QT_DIR}/bin/moc -I$(QT_DIR)/mkspecs/linux-g++ >>>> >>> -I${QT_DIR}/include -I${QT_DIR}/include/QtGui) >>>> >>> file (MAKE_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/Qt_tmp) >>>> >>> set (Qt_tmp ${CMAKE_CURRENT_SOURCE_DIR}/Qt_tmp) >>>> >>> add_custom_target (Moc_GMWindows >>>> >>>? ? ? ? ? ? ? ? ? ? COMMAND ${QT_MOC_CMD} ${GM_DIR}/GMWindow.h -o >>>> >>> ${Qt_tmp}/moc_GMWindow.cpp >>>> >>>? ? ? ? ? ? ? ? ? ?) >>>> >>> >>>> >>> ##### Compiling application? ##### >>>> >>> file (GLOB GM_SOURCES ${GM_DIR}/*.h ${GM_DIR}/*.cpp) >>>> >>> file (GLOB Moc_SOURCES ${Qt_tmp}/*.h ${Qt_tmp}/*.cpp) >>>> >>> add_executable (GM ${GM_SOURCES} ${Moc_SOURCES}) >>>> >>> target_include_directories (GM PRIVATE ${Qt_tmp}) >>>> >>> add_dependencies (GM Moc_GMWindows) >>>> >>> target_link_libraries (GM QtGui) >>>> >>> >>>> >>> >>>> >>> >>>> >>>> >>>>------------------------------------------------------------------------------------------- >>>> >>> Errors: >>>> >>> >>>> >>> Scanning dependencies of target Moc_GMWindows >>>> >>> [? 0%] Built target Moc_GMWindows >>>> >>> Scanning dependencies of target GM >>>> >>> [ 14%] Building CXX object GM/CMakeFiles/GM.dir/GM/GM.cpp.o >>>> >>> [ 42%] Building CXX object >>>GM/CMakeFiles/GM.dir/GM/GMService.cpp.o >>>> >>> [ 67%] Building CXX object GM/CMakeFiles/GM.dir/GM/GMWindow.cpp.o >>>> >>> [ 85%] Building CXX object GM/CMakeFiles/GM.dir/GM/main.cpp.o >>>> >>> [100%] Linking CXX executable ../bin/GM >>>> >>> CMakeFiles/GM.dir/GM/GMWindow.cpp.o: In function >>>> >>> `GM::GMWindow::emitAppendMessage(QStrin >>>> >>> g)': >>>> >>> /GM/GMWindow.cpp:217: undefined reference to >>>> >>> `GM::GMWindow::appendMessage(QString)' >>>> >>> >>>> >>>>CMakeFiles/GM.dir/GM/GMWindow.cpp.o:(.rodata._ZTVN2GM8GMWindowE[vtable >>>> >>> for GM::GMWindow] >>>> >>> +0x8): undefined reference to `GM::GMWindow::metaObject() const' >>>> >>> >>>> >>>>CMakeFiles/GM.dir/GM/GMWindow.cpp.o:(.rodata._ZTVN2GM8GMWindowE[vtable >>>> >>> for GM::GMWindow] >>>> >>> +0xc): undefined reference to `GM::GMWindow::qt_metacast(char >>>> >const*)' >>>> >>> >>>> >>>>CMakeFiles/GM.dir/GM/GMWindow.cpp.o:(.rodata._ZTVN2GM8GMWindowE[vtable >>>> >>> for GM::GMWindow] >>>> >>> +0x10): undefined reference to >>>> >>> `GM::GMWindow::qt_metacall(QMetaObject::Call, int, void**)' >>>> >>> collect2: ld returned 1 exit status >>>> >>> make[2]: *** [bin/GM] Error 1 >>>> >>> make[1]: *** [GM/CMakeFiles/GM.dir/all] Error 2 >>>> >>> make: *** [all] Error 2 >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >< >>>> >>>https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail >>>> > >>>> >Virus-free. >>>> >>> www.avast.com >>>> >>> >>>> >< >>>> >>>https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail >>>> > >>>> >>> >>>> >>>> >>>><#m_3542150497808946122_m_6400203814648417669_DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2> >>>> >>> >>>> >> >>>> >> >>>> >> -- >>>> >> >>>> >> 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 >>>> >> >>>> > >>>> > >>>> >>>>------------------------------------------------------------------------ >>>> >>>> -- >>>> 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 >>>> >>> >>> >>>------------------------------------------------------------------------ >> >> -- >> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. > ,-- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -- Regards, Konstantin From eschnigma at openmailbox.org Wed Jun 1 08:10:41 2016 From: eschnigma at openmailbox.org (Esch Nigma) Date: Wed, 01 Jun 2016 15:10:41 +0300 Subject: [CMake] No debugging symbols found when using -DCMAKE_BUILD_TYPE=Debug Message-ID: <5355465.egJ6labZND@manjaro> Hello all, I just registered to this mailing list, my apologies if this was already discussed. I'm experiencing an issue where I'm unable to debug my code when the project is configured with CMake. When running gdb on the final binary, it mentions that no debugging symbols are found. I tried this via the command line, and through QT Creator. After asking on StackOverflow, I was given a workaround - Cmake fails to figure out the compiler identification automatically. Adding -DCMAKE_CXX_COMPILER_ID:STRING=GNU makes it all work just fine. However, it should still detect it automatically. I've built an empty Hello world to display this: [eschnigma at manjaro quicktest]$ cat main.cpp #include using namespace std; int main(){ cout << "Hello there"; } When I build into a subdirectory and try to debug, this is the output: [eschnigma at manjaro build]$ cmake .. -DCMAKE_BUILD_TYPE:STRING="Debug" *Scanning dependencies of target qtest* [100%] Building CXX object CMakeFiles/qtest.dir/main.cpp.o *Linking CXX executable qtest* [100%] Built target qtest [eschnigma at manjaro build]$ gdb qtest GNU gdb (GDB) 7.11 Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from qtest...(no debugging symbols found)...done. (gdb) However - when I compile manually, it works fine: [eschnigma at manjaro quicktest]$ c++ -g main.cpp [eschnigma at manjaro quicktest]$ gdb a.out GNU gdb (GDB) 7.11 Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from a.out...done. (gdb) quit I have tested this on cmake version 2.8.11.2 and 3.5.2. This problem started happening a few days ago, on two different machines, both running Manjaro Linux. I'll be able to continue coding for now, but I wanted to report on this anyway - as far as I know, it should all be automatic. Thanks, Esch -------------- next part -------------- An HTML attachment was scrubbed... URL: From masariello+cmake.org at gmail.com Wed Jun 1 08:26:57 2016 From: masariello+cmake.org at gmail.com (Alessio) Date: Wed, 1 Jun 2016 13:26:57 +0100 Subject: [CMake] CPack with BZIP2 is a lot slower than GNU tar Message-ID: Hi All Is anyone else having problems with the speed of cpack? Out of one of our code bases we produce two packages on Linux using the BZIP2 generator with CMake 3.4.0. I provide a few stats on the packages below. They are not particularly fat. GNU tar will take ~1min to tar the biggest one up with the same compression tech. CPack takes a good 4~5min for each of them. I do realize cpack does a lot more than just "tar'ring", but I was wondering if people had any pointers on how to make it run faster. Things to avoid, etc. Any advice greatly appreciated. Thank you Main package file# size file type ------------------------------------ 131 33MB binaries 7591 376MB pythonscripts Unit tests package file# size file type -------------------------------- 23 129MB binaries -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicholas11braden at gmail.com Wed Jun 1 08:34:59 2016 From: nicholas11braden at gmail.com (Nicholas Braden) Date: Wed, 1 Jun 2016 07:34:59 -0500 Subject: [CMake] How to use CMAKE_MFC_FLAG for only one on executables? In-Reply-To: References: Message-ID: Have you tried unsetting it after adding the executable in question? If that doesn't work, is it possible to make the MFX executable be the very last executable added in your project? On Wed, Jun 1, 2016 at 4:50 AM, Zhang Peixuan wrote: > Hello All, > > I want to use CMake to manage my MFC projects, and I added the following > code: > > set( CMAKE_MFC_FLAG 2) > add_executable(MFCDemo WIN32 > ${MFC_RESOURCE_FILES} > ${MFC_HEADER_FILES} > ${MFC_SOURCE_FILES} > ) > target_compile_definitions(MFCDemo > PUBLIC -D_AFXDLL=1 > PUBLIC -D_UNICODE > PUBLIC -DUNICODE > ) > > It works. > However, my question is that: In addition to the MFC executable, I still > have some non-MFC executables, > and once CMAKE_MFC_FLAG is set, all the add_executables' property should be > "Use MFC in a Shared DLL". > In fact, I want only one MFC executable, and make sure all other executables > are "Use Standard Windows Library". > Is there any way to implement it? It seems CMAKE_MFC_FLAG does not work with > set_target_property or other commands. > > Thanks, > Peixuan Zhang > > -- > > 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 ire866306 at gmail.com Wed Jun 1 10:01:54 2016 From: ire866306 at gmail.com (irene w) Date: Wed, 1 Jun 2016 10:01:54 -0400 Subject: [CMake] CMake+QT always failed for the first build, and succeeded for second build or later. In-Reply-To: References: Message-ID: Thank you very much for your help, Jakob, I replace file(GLOB) with set() macro. It works now. I'll look at qt4_wrap_cpp macro and see if I can use it. In my case, Qt may not be installed on the system with the default location, it is under the Thirdparty directory. I am not sure if the macro can automatically find Qt. Thanks again, On Wed, Jun 1, 2016 at 3:02 AM, Jakob van Bethlehem < jsvanbethlehem at gmail.com> wrote: > Hej, > > Some things that come to mind: > * You're generating files *inside* the source tree - you're not supposed > to do that > * Why do you want to have a special Qt_tmp directory? I don't see the > benefit, and without that requirement you can simply use the qt4_wrap_cpp > macro explicitly and you still are not forced to use the automoc feature > > And now for what is probably wrong in your CMakeLists.txt: > * It seems you made an important mistake regarding the behaviour of > 'file(GLOB)'. That function will do the expansion *while running CMake*. > But at that time the moc_* files *don't exist!* (as a matter of fact, the > tmp directory doesn't even exist). In other words, your ${Moc_SOURCES} will > be empty, and hence they are not compiled, and hence you get precisely the > linker errors you see (because these sources implement the functions that > are listed as missing by the linker) > > If you would use the qt4_wrap_cpp() macro you don't run into this problem, > so I'd strongly suggest using it. > > Sincerely, > Jakob van Bethlehem > > > > > On Tue, May 31, 2016 at 4:52 PM, irene w wrote: > >> It seems CMakw could not find the generated moc_xxx files. I modified >> the scripts to specify moc_xxx files is generated, but it still has same >> errors. >> >> ADD_CUSTOM_COMMAND ( OUTPUT ${Qt_tmp}/moc_GMWindow.cpp >> COMMAND ${QT_MOC_CMD} ${GM_DIR}/GMWindow.h -o >> ${Qt_tmp}/moc_GMWindow.cpp >> DEPENDS ${GM_DIR}/GMWindow.h >> ) >> ADD_CUSTOM_TARGET(generate_foo DEPENDS ${Qt_tmp}/moc_GMWindow.cpp) >> SET_SOURCE_FILES_PROPERTIES(${Qt_tmp}/moc_GMWindow.cpp PROPERTIES >> GENERATED 1) >> SET_PROPERTY(SOURCE ${GM_DIR}/GMWindow.cpp APPEND PROPERTY OBJECT_DEPENDS >> ${Qt_tmp}/moc_GMWindow.cpp) >> >> ..... >> add_dependencies (GM generate_foo) >> >> >> Does the Macro "SET_SOURCE_FILES_PROPERTIES" with "GENERATED" >> setting work for this purposes? Any help would be greatly appreciated ! >> >> >> On Wed, May 25, 2016 at 12:48 PM, irene w wrote: >> >>> Hi, >>> >>> I am compiling a simple Qt3 application on Linux using CMake. In my >>> case, I need to build moc_xxx files with custom options and output to >>> a specified directory, So, I was not using CAMKE_AUTO macros. My cmake >>> scripts create a "Qt_tmp" directory and output moc_xxx there. >>> >>> It looked it always failed to link the moc_xxx files for the first time >>> build when there is no "Qt_tmp" directory, and succeeded if I ran build >>> again if the "Qt_tmp" directory and moc_xxx files created by the failed >>> build were kept without removing. However, it'll fail if I delete >>> the "Qt_tmp" directory. >>> >>> Even it failed at the first build, the moc_xxx files were >>> successfully created in the "Qt_tmp" directory. >>> >>> Here is my cmake scripts and the errors I got. Can anyone help me to >>> figure out the issues? Any help would be greatly appreciated. Thanks. >>> >>> CMakeLists.txt >>> >>> --------------------------------------------------------------------------------------------- >>> cmake_minimum_required(VERSION 3.4.1) >>> project (GM_Application CXX) >>> SET (CMAKE_SYSTEM_NAME Linux) >>> SET (CMAKE_CXX_COMPILER ${COMPILER_PATH}${CROSS_COMPILE}g++) >>> set (GM_DIR ${CMAKE_CURRENT_SOURCE_DIR}) >>> set (QT_DIR ${CMAKE_CURRENT_SOURCE_DIR}/ThirdParty/Qt/4.8.6) >>> LINK_DIRECTORIES (${QT_DIR}/lib) >>> INCLUDE_DIRECTORIES ("${QT_DIR}/include" >>> "${GM_DIR}" >>> ) >>> ##### Compiling QT moc and ui ##### >>> set (QT_MOC_CMD ${QT_DIR}/bin/moc -I$(QT_DIR)/mkspecs/linux-g++ >>> -I${QT_DIR}/include -I${QT_DIR}/include/QtGui) >>> file (MAKE_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/Qt_tmp) >>> set (Qt_tmp ${CMAKE_CURRENT_SOURCE_DIR}/Qt_tmp) >>> add_custom_target (Moc_GMWindows >>> COMMAND ${QT_MOC_CMD} ${GM_DIR}/GMWindow.h -o >>> ${Qt_tmp}/moc_GMWindow.cpp >>> ) >>> >>> ##### Compiling application ##### >>> file (GLOB GM_SOURCES ${GM_DIR}/*.h ${GM_DIR}/*.cpp) >>> file (GLOB Moc_SOURCES ${Qt_tmp}/*.h ${Qt_tmp}/*.cpp) >>> add_executable (GM ${GM_SOURCES} ${Moc_SOURCES}) >>> target_include_directories (GM PRIVATE ${Qt_tmp}) >>> add_dependencies (GM Moc_GMWindows) >>> target_link_libraries (GM QtGui) >>> >>> >>> ------------------------------------------------------------------------------------------- >>> Errors: >>> >>> Scanning dependencies of target Moc_GMWindows >>> [ 0%] Built target Moc_GMWindows >>> Scanning dependencies of target GM >>> [ 14%] Building CXX object GM/CMakeFiles/GM.dir/GM/GM.cpp.o >>> [ 42%] Building CXX object GM/CMakeFiles/GM.dir/GM/GMService.cpp.o >>> [ 67%] Building CXX object GM/CMakeFiles/GM.dir/GM/GMWindow.cpp.o >>> [ 85%] Building CXX object GM/CMakeFiles/GM.dir/GM/main.cpp.o >>> [100%] Linking CXX executable ../bin/GM >>> CMakeFiles/GM.dir/GM/GMWindow.cpp.o: In function >>> `GM::GMWindow::emitAppendMessage(QStrin >>> g)': >>> /GM/GMWindow.cpp:217: undefined reference to >>> `GM::GMWindow::appendMessage(QString)' >>> CMakeFiles/GM.dir/GM/GMWindow.cpp.o:(.rodata._ZTVN2GM8GMWindowE[vtable >>> for GM::GMWindow] >>> +0x8): undefined reference to `GM::GMWindow::metaObject() const' >>> CMakeFiles/GM.dir/GM/GMWindow.cpp.o:(.rodata._ZTVN2GM8GMWindowE[vtable >>> for GM::GMWindow] >>> +0xc): undefined reference to `GM::GMWindow::qt_metacast(char const*)' >>> CMakeFiles/GM.dir/GM/GMWindow.cpp.o:(.rodata._ZTVN2GM8GMWindowE[vtable >>> for GM::GMWindow] >>> +0x10): undefined reference to >>> `GM::GMWindow::qt_metacall(QMetaObject::Call, int, void**)' >>> collect2: ld returned 1 exit status >>> make[2]: *** [bin/GM] Error 1 >>> make[1]: *** [GM/CMakeFiles/GM.dir/all] Error 2 >>> make: *** [all] Error 2 >>> >>> >>> >>> Virus-free. >>> www.avast.com >>> >>> <#m_6851439966933586043_m_3542150497808946122_m_6400203814648417669_DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2> >>> >> >> >> -- >> >> 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 chuck.atkins at kitware.com Wed Jun 1 10:05:21 2016 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Wed, 1 Jun 2016 10:05:21 -0400 Subject: [CMake] No debugging symbols found when using -DCMAKE_BUILD_TYPE=Debug In-Reply-To: <5355465.egJ6labZND@manjaro> References: <5355465.egJ6labZND@manjaro> Message-ID: > > [eschnigma at manjaro build]$ cmake .. -DCMAKE_BUILD_TYPE:STRING="Debug" > -- The C compiler identification is unknown > -- The CXX compiler identification is unknown > This is definitely the reason for no debug symbols. If the compiler is unknown then CMake won't know the right flags to pass to generate debug info. The more important question though is why the compiler can't be identified. What compiler is being used? Can check with /usr/bin/c++ --version ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From eschnigma at openmailbox.org Wed Jun 1 10:49:54 2016 From: eschnigma at openmailbox.org (Esch Nigma) Date: Wed, 01 Jun 2016 17:49:54 +0300 Subject: [CMake] No debugging symbols found when using -DCMAKE_BUILD_TYPE=Debug In-Reply-To: References: <5355465.egJ6labZND@manjaro> Message-ID: <2757745.3M4lAMPy81@manjaro> The standard choice is c++ [eschnigma at manjaro ~]$ c++ --version c++ (GCC) 6.1.1 20160501 Copyright (C) 2016 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. But I've tried enforcing g++ as such: -DCMAKE_C_COMPILER:FILEPATH=/usr/bin/gcc -DCMAKE_CXX_COMPILER:STRING=/usr/ bin/g++ And that has the same results. Version: [eschnigma at manjaro ~]$ g++ --version g++ (GCC) 6.1.1 20160501 Copyright (C) 2016 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. On Wednesday, June 1, 2016 10:05:21 AM EEST Chuck Atkins wrote: [eschnigma at manjaro build]$ cmake .. -DCMAKE_BUILD_TYPE:STRING="Debug" This is definitely the reason for no debug symbols. If the compiler is unknown then CMake won't know the right flags to pass to generate debug info. The more important question though is why the compiler can't be identified. What compiler is being used? Can check with /usr/bin/c++ --version ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From Martin.Wagner at neuberger.net Wed Jun 1 10:58:53 2016 From: Martin.Wagner at neuberger.net (Wagner Martin) Date: Wed, 1 Jun 2016 14:58:53 +0000 Subject: [CMake] C header file cross dependency In-Reply-To: <20160525113902.0eb6f70d@posteo.de> References: <56E920142ED81D4FBE3260E4B9D1DB3E97208951@ROTSRV13.Neuberger.local> <20160525113902.0eb6f70d@posteo.de> Message-ID: <56E920142ED81D4FBE3260E4B9D1DB3E97208FAB@ROTSRV13.Neuberger.local> > > Could you provide a working, stripped down example to show the problem > provided via github (in an example repo). > I've added a simple test project to https://github.com/martinwag/test_cmake/tree/master Note that this example does not need cross gcc for ARM. It doesn't implement any useful functionality! Regards, Martin From juanprietob at gmail.com Wed Jun 1 11:36:33 2016 From: juanprietob at gmail.com (Juan Carlos Prieto) Date: Wed, 1 Jun 2016 11:36:33 -0400 Subject: [CMake] Running OSX Bundle via open after creation with CMake/CPack Message-ID: Dear all, I have generated a bundle for MacOS as follows: if(APPLE) set(OS_BUNDLE MACOSX_BUNDLE) elseif(WIN32) set(OS_BUNDLE WIN32) endif() include_directories(${CMAKE_CURRENT_BINARY_DIR}) add_executable(FADTTSter ${OS_BUNDLE} ${FADTTS_src} ) target_link_libraries(FADTTSter ${QT_LIBRARIES} ${VTK_LIBRARIES}) #-------------------------------------------------------------------------------- # Install the QtTest application, on Apple, the bundle is at the root of the # install tree, and on other platforms it'll go into the bin directory. INSTALL(TARGETS FADTTSter DESTINATION . COMPONENT Runtime RUNTIME DESTINATION bin COMPONENT Runtime ) macro(install_qt5_plugin _qt_plugin_name _qt_plugins_var) get_target_property(_qt_plugin_path "${_qt_plugin_name}" LOCATION) if(EXISTS "${_qt_plugin_path}") get_filename_component(_qt_plugin_file "${_qt_plugin_path}" NAME) get_filename_component(_qt_plugin_type "${_qt_plugin_path}" PATH) get_filename_component(_qt_plugin_type "${_qt_plugin_type}" NAME) set(_qt_plugin_dest "${CMAKE_INSTALL_PREFIX}/FADTTSter.app/Contents/PlugIns/${_qt_plugin_type}") install(FILES "${_qt_plugin_path}" DESTINATION "${_qt_plugin_dest}" COMPONENT Runtime) set(${_qt_plugins_var} "${${_qt_plugins_var}};${_qt_plugin_dest}/${_qt_plugin_file}") else() message(FATAL_ERROR "QT plugin ${_qt_plugin_name} not found") endif() endmacro() install_qt5_plugin("Qt5::QCocoaIntegrationPlugin" QT_PLUGINS) #-------------------------------------------------------------------------------- # install a qt.conf file # this inserts some cmake code into the install script to write the file INSTALL(CODE " file(WRITE \"\${CMAKE_INSTALL_PREFIX}/${qtconf_dest_dir}/qt.conf\" \"[Paths]\nPlugins = PlugIns\n\") " COMPONENT Runtime) install(CODE " include(BundleUtilities) fixup_bundle(\"${APPS}\" \"${QT_PLUGINS};\" \"${QT_LIBRARY_DIR};${QT_BINARY_DIR};\") " COMPONENT Runtime) The bundle will not run if executed through finder or in command line as $ open FADTTSter.app. LSOpenURLsWithRole() failed with error -10810 for the file /path/to/FADTTSter.app However, if the executable inside FADTTSter.app/Contents/MacOS/FADTTSter is executed, the application works fine. Does any body knows how to solve this issue? Any help will be greatly appreciated. Best regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.chebotarev at gmail.com Wed Jun 1 11:46:49 2016 From: vladimir.chebotarev at gmail.com (Vladimir Chebotarev) Date: Wed, 1 Jun 2016 18:46:49 +0300 Subject: [CMake] add_custom_command, POST_BUILD In-Reply-To: References: Message-ID: Hi there. At the moment one can add a command executing after a build of a target using: add_custom_command(... POST_BUILD...) However if the command have a dependencies which build after the target, there is practically no way to specify it. Simple case: we have a library and tests for it. E.g. I want them to run in POST_BUILD of a library. But, tests already depends on the library so I can't make them built before it. There are few possible solutions to that: 1) add possibility to set dependencies for add_custom_command in POST_BUILD mode; 2) add possibility to populate list of targets if we have specified ones in list. Or maybe correct me if I miss something. Kind regards, Vladimir. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chuck.atkins at kitware.com Wed Jun 1 11:46:40 2016 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Wed, 1 Jun 2016 11:46:40 -0400 Subject: [CMake] No debugging symbols found when using -DCMAKE_BUILD_TYPE=Debug In-Reply-To: <2757745.3M4lAMPy81@manjaro> References: <5355465.egJ6labZND@manjaro> <2757745.3M4lAMPy81@manjaro> Message-ID: Interesting. It seems CMake is having trouble identifying GCC in 6.1.1. Do you have a 5.x compiler available? If so does it work with that? That would help narrow it down to a gcc6 issue vs something about how Manjaro packages compilers. - Chuck On Wed, Jun 1, 2016 at 10:49 AM, Esch Nigma wrote: > The standard choice is c++ > > > > [eschnigma at manjaro ~]$ c++ --version > c++ (GCC) 6.1.1 20160501 > Copyright (C) 2016 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > But I've tried enforcing g++ as such: > > > > -DCMAKE_C_COMPILER:FILEPATH=/usr/bin/gcc > -DCMAKE_CXX_COMPILER:STRING=/usr/bin/g++ > > > > And that has the same results. > > > > Version: > > > > [eschnigma at manjaro ~]$ g++ --version > g++ (GCC) 6.1.1 20160501 > Copyright (C) 2016 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > On Wednesday, June 1, 2016 10:05:21 AM EEST Chuck Atkins wrote: > > [eschnigma at manjaro build]$ cmake .. -DCMAKE_BUILD_TYPE:STRING="Debug" > -- The C compiler identification is unknown > -- The CXX compiler identification is unknown > > > This is definitely the reason for no debug symbols. If the compiler is > unknown then CMake won't know the right flags to pass to generate debug > info. The more important question though is why the compiler can't be > identified. What compiler is being used? Can check with /usr/bin/c++ > --version ? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Wed Jun 1 12:13:15 2016 From: DLRdave at aol.com (David Cole) Date: Wed, 1 Jun 2016 12:13:15 -0400 Subject: [CMake] How to use CMAKE_MFC_FLAG for only one on executables? In-Reply-To: References: Message-ID: Or just isolate it into its own CMakeLists.txt file in a sub-directory? On Wed, Jun 1, 2016 at 8:34 AM, Nicholas Braden wrote: > Have you tried unsetting it after adding the executable in question? > If that doesn't work, is it possible to make the MFX executable be the > very last executable added in your project? > > On Wed, Jun 1, 2016 at 4:50 AM, Zhang Peixuan wrote: >> Hello All, >> >> I want to use CMake to manage my MFC projects, and I added the following >> code: >> >> set( CMAKE_MFC_FLAG 2) >> add_executable(MFCDemo WIN32 >> ${MFC_RESOURCE_FILES} >> ${MFC_HEADER_FILES} >> ${MFC_SOURCE_FILES} >> ) >> target_compile_definitions(MFCDemo >> PUBLIC -D_AFXDLL=1 >> PUBLIC -D_UNICODE >> PUBLIC -DUNICODE >> ) >> >> It works. >> However, my question is that: In addition to the MFC executable, I still >> have some non-MFC executables, >> and once CMAKE_MFC_FLAG is set, all the add_executables' property should be >> "Use MFC in a Shared DLL". >> In fact, I want only one MFC executable, and make sure all other executables >> are "Use Standard Windows Library". >> Is there any way to implement it? It seems CMAKE_MFC_FLAG does not work with >> set_target_property or other commands. >> >> Thanks, >> Peixuan Zhang >> >> -- >> >> 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 philip.pfaffe at gmail.com Wed Jun 1 12:26:07 2016 From: philip.pfaffe at gmail.com (Philip Pfaffe) Date: Wed, 1 Jun 2016 18:26:07 +0200 Subject: [CMake] RPATH of imported targets Message-ID: Hi Folks, I'm linking a target against libraries from an imported package. The resulting linker invocation then will link against the libs using the full path, but it will not set the RPATH accordingly. How to I enable RPATH? I suspect the reason is, that, in the package's Exports.cmake, it sets the IMPORTED_LOCATION property. My cmake version is 3.2.2. - Philip -------------- next part -------------- An HTML attachment was scrubbed... URL: From eschnigma at openmailbox.org Wed Jun 1 13:59:45 2016 From: eschnigma at openmailbox.org (Esch Nigma) Date: Wed, 01 Jun 2016 20:59:45 +0300 Subject: [CMake] No debugging symbols found when using -DCMAKE_BUILD_TYPE=Debug In-Reply-To: References: <5355465.egJ6labZND@manjaro> <2757745.3M4lAMPy81@manjaro> Message-ID: <3060435.q23ZzKDfkT@manjaro> I tried it out just now. I pulled and installed a couple 5.x packages from the Arch archive: https://archive.archlinux.org/packages/l/ The packages: gcc-libs-multilib-5.3.0-4-x86_64.pkg.tar.xz gcc-multilib-5.3.0-4-x86_64.pkg.tar.xz lib32-gcc-libs-5.3.0-4-x86_64.p The downgrade didn't change anything for my Hello World program. For the project I'm actively working on, it broke everything, since C++11 is no longer recognized. On my system I had to pull the 'multilib' versions, as this is what my system seems to be using. If requested, I can try to switch to normal gcc to test that out. Interesting. It seems CMake is having trouble identifying GCC in 6.1.1. Do you have a 5.x compiler available? If so does it work with that? That would help narrow it down to a gcc6 issue vs something about how Manjaro packages compilers. - Chuck On Wed, Jun 1, 2016 at 10:49 AM, Esch Nigma wrote: The standard choice is c++ [eschnigma at manjaro ~]$ c++ --version c++ (GCC) 6.1.1 20160501 Copyright (C) 2016 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. But I've tried enforcing g++ as such: -DCMAKE_C_COMPILER:FILEPATH=/usr/bin/gcc -DCMAKE_CXX_COMPILER:STRING=/usr/ bin/g++ And that has the same results. Version: [eschnigma at manjaro ~]$ g++ --version g++ (GCC) 6.1.1 20160501 Copyright (C) 2016 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. On Wednesday, June 1, 2016 10:05:21 AM EEST Chuck Atkins wrote: [eschnigma at manjaro build]$ cmake .. -DCMAKE_BUILD_TYPE:STRING="Debug" This is definitely the reason for no debug symbols. If the compiler is unknown then CMake won't know the right flags to pass to generate debug info. The more important question though is why the compiler can't be identified. What compiler is being used? Can check with /usr/bin/c++ --version ? -------- [1] mailto:eschnigma at openmailbox.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus at therning.org Wed Jun 1 16:01:05 2016 From: magnus at therning.org (Magnus Therning) Date: Wed, 01 Jun 2016 22:01:05 +0200 Subject: [CMake] add_custom_command, POST_BUILD In-Reply-To: References: Message-ID: <87pos01xxa.fsf@therning.org> Vladimir Chebotarev writes: > Hi there. > > At the moment one can add a command executing after a build of a target > using: > add_custom_command(... POST_BUILD...) > > However if the command have a dependencies which build after the target, > there is practically no way to specify it. > > Simple case: we have a library and tests for it. E.g. I want them to run in > POST_BUILD of a library. But, tests already depends on the library so I > can't make them built before it. > > There are few possible solutions to that: > 1) add possibility to set dependencies for add_custom_command in POST_BUILD > mode; > 2) add possibility to populate list of targets if we have specified ones in > list. > > Or maybe correct me if I miss something. Have you not simply missed add_test()? ;) What's the reason for wanting the tests to run post-build, rather than on `make test`? /M -- Magnus Therning OpenPGP: 0x927912051716CE39 email: magnus at therning.org jabber: magnus at therning.org twitter: magthe http://therning.org/magnus A system is composed of components: a component is something you understand. ? Professor Howard Aiken -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 800 bytes Desc: not available URL: From markysays at yahoo.com Wed Jun 1 16:21:54 2016 From: markysays at yahoo.com (Mark Thomas) Date: Wed, 1 Jun 2016 20:21:54 +0000 (UTC) Subject: [CMake] CMake searching for shared libraries in invalid paths References: <899025384.2491267.1464812514327.JavaMail.yahoo.ref@mail.yahoo.com> Message-ID: <899025384.2491267.1464812514327.JavaMail.yahoo@mail.yahoo.com> Hi cmake users,?? ? Reposting question from stackoverflow (http://stackoverflow.com/questions/37449511/cmake-searching-for-shared-libraries-in-invalid-paths) since I didn't get a good answer there: I noticed that the cmake generation step in my project was taking a long time and so I ran cmake through strace to figure out the root cause. I found that cmake was trying to find internal shared libraries in the wrong locations repeatedly, which was causing a lot of unnecessary file system lookups. Here is a simple project that illustrates the problem: ? ? $ ll -R ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??? ? .:? ? total 20K? ? drwxr-xr-x 2 mark mark 4.0K May 25 16:22 alpha? ? drwxr-xr-x 2 mark mark 4.0K May 25 16:22 beta? ? drwxr-xr-x 2 mark mark 4.0K May 25 16:42 build? ? -rw-r--r-- 1 mark mark ?185 May 25 16:20 CMakeLists.txt? ? -rw-r--r-- 1 mark mark ? ?0 May 25 16:16 dummy.cc? ? drwxr-xr-x 2 mark mark 4.0K May 25 16:22 gamma? ??? ? ./alpha:? ? total 4.0K? ? -rw-r--r-- 1 mark mark ?0 May 25 16:16 alpha.cc? ? -rw-r--r-- 1 mark mark 69 May 25 16:20 CMakeLists.txt? ??? ? ./beta:? ? total 4.0K? ? -rw-r--r-- 1 mark mark ?0 May 25 16:16 beta.cc? ? -rw-r--r-- 1 mark mark 67 May 25 16:18 CMakeLists.txt? ??? ? ./build:? ? total 0? ??? ? ./gamma:? ? total 4.0K? ? -rw-r--r-- 1 mark mark 35 May 25 16:19 CMakeLists.txt? ? -rw-r--r-- 1 mark mark ?0 May 25 16:16 gamma.cc? alpha.cc, beta.cc, gamma.cc and dummy.cc are all empty cc files. Here are the contents of all the CMakLists.txt files: Top level CMakeLists.txt ? ? $ cat CMakeLists.txt?? ? cmake_minimum_required(VERSION 2.8) ? ? add_subdirectory(alpha)? ? add_subdirectory(beta)? ? add_subdirectory(gamma) ? ? add_executable(dummy_exec dummy.cc)? ? target_link_libraries(dummy_exec alpha) alpha/CMakeLists.txt? ? ? $ cat alpha/CMakeLists.txt?? ? add_library(alpha SHARED alpha.cc)? ? target_link_libraries(alpha beta) beta/CMakeLists.txt ? ? $ cat beta/CMakeLists.txt?? ? add_library(beta SHARED beta.cc)? ? target_link_libraries(beta gamma) gamma/CMakeLists.txt? ? ? $ cat gamma/CMakeLists.txt?? ? add_library(gamma SHARED gamma.cc) I invoke cmake (through strace) as follows: ? ? $ cd build/? ? $ strace -f -o /tmp/s.out ?cmake ?.. ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? ? -- The C compiler identification is GNU 4.8.4? ? -- The CXX compiler identification is GNU 4.8.4? ? -- Check for working C compiler: /usr/bin/cc? ? -- Check for working C compiler: /usr/bin/cc -- works? ? -- Detecting C compiler ABI info? ? -- Detecting C compiler ABI info - done? ? -- 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? ? -- Configuring done? ? -- Generating done? ? -- Build files have been written to: /home/mark/Downloads/cmake/build When I inspect the strace output, I see it trying to access libalpha in invalid locations (such as under the beta/ and gamma/ sub directories): ? ? 31430 access("/home/mark/Downloads/cmake/build/beta/libalpha.so", R_OK) = -1 ENOENT (No such file or directory)? ? 31430 access("/home/mark/Downloads/cmake/build/gamma/libalpha.so", R_OK) = -1 ENOENT (No such file or directory) Similarly, it is trying to access libbeta and libgamma in invalid locations: ? ? 31430 access("/home/mark/Downloads/cmake/build/alpha/libbeta.so", R_OK) = -1 ENOENT (No such file or directory)? ? 31430 access("/home/mark/Downloads/cmake/build/gamma/libbeta.so", R_OK) = -1 ENOENT (No such file or directory) ? ? 31430 access("/home/mark/Downloads/cmake/build/alpha/libgamma.so", R_OK) = -1 ENOENT (No such file or directory)? ? 31430 access("/home/mark/Downloads/cmake/build/beta/libgamma.so", R_OK) = -1 ENOENT (No such file or directory) For a large project with many shared libraries and many dependencies, these invalid lookups add up and seem to be causing big delays at the makefile generation step. Any idea on why this is happening and how I could prevent cmake from searching in these invalid paths ?? thanksmark -------------- next part -------------- An HTML attachment was scrubbed... URL: From chuck.atkins at kitware.com Wed Jun 1 16:54:02 2016 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Wed, 1 Jun 2016 16:54:02 -0400 Subject: [CMake] No debugging symbols found when using -DCMAKE_BUILD_TYPE=Debug In-Reply-To: <3060435.q23ZzKDfkT@manjaro> References: <5355465.egJ6labZND@manjaro> <2757745.3M4lAMPy81@manjaro> <3060435.q23ZzKDfkT@manjaro> Message-ID: Wow, so this is actually a pretty obscure find. You've definitely stumbled across a bug. It has nothing to do with debug symbols and everything to do with compiler identification. It seems that our binary strings parsing is broken when "[anything]" is in the file path. Without looking at the code too deeply, i imagine something is not getting properly escaped somewhere. As a workaround for now, rename your "[Code]" folder to "Code" and then it should work (lame I know). I would ask you to please file a bug report but new user registration is currently disabled due to some spam issues we were having. I'll put it in the queue for issues to address in future releases but I doubt it will make it into the 3.6 release since it seems to have been there for a long time without affecting too many users but it should be able to get fixed in a future release. Once we open the bug tracker up again then please definitely report the issue (unless you already have an account then go ahead and report it now). Thanks for the find! - Chuck On Wed, Jun 1, 2016 at 1:59 PM, Esch Nigma wrote: > I tried it out just now. > > > > I pulled and installed a couple 5.x packages from the Arch archive: > > https://archive.archlinux.org/packages/l/ > > > > The packages: > > gcc-libs-multilib-5.3.0-4-x86_64.pkg.tar.xz > > gcc-multilib-5.3.0-4-x86_64.pkg.tar.xz > > lib32-gcc-libs-5.3.0-4-x86_64.p > > > > The downgrade didn't change anything for my Hello World program. > > > > For the project I'm actively working on, it broke everything, since C++11 > is no longer recognized. > > On my system I had to pull the 'multilib' versions, as this is what my > system seems to be using. If requested, I can try to switch to normal gcc > to test that out. > > > On Wednesday, June 1, 2016 11:46:40 AM EEST Chuck Atkins wrote: > > Interesting. It seems CMake is having trouble identifying GCC in 6.1.1. > Do you have a 5.x compiler available? If so does it work with that? That > would help narrow it down to a gcc6 issue vs something about how Manjaro > packages compilers. > > > - Chuck > > > On Wed, Jun 1, 2016 at 10:49 AM, Esch Nigma > wrote: > > The standard choice is c++ > > > > [eschnigma at manjaro ~]$ c++ --version > c++ (GCC) 6.1.1 20160501 > Copyright (C) 2016 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > But I've tried enforcing g++ as such: > > > > -DCMAKE_C_COMPILER:FILEPATH=/usr/bin/gcc > -DCMAKE_CXX_COMPILER:STRING=/usr/bin/g++ > > > > And that has the same results. > > > > Version: > > > > [eschnigma at manjaro ~]$ g++ --version > g++ (GCC) 6.1.1 20160501 > Copyright (C) 2016 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > On Wednesday, June 1, 2016 10:05:21 AM EEST Chuck Atkins wrote: > > [eschnigma at manjaro build]$ cmake .. -DCMAKE_BUILD_TYPE:STRING="Debug" > -- The C compiler identification is unknown > -- The CXX compiler identification is unknown > > > This is definitely the reason for no debug symbols. If the compiler is > unknown then CMake won't know the right flags to pass to generate debug > info. The more important question though is why the compiler can't be > identified. What compiler is being used? Can check with /usr/bin/c++ > --version ? > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zhangpeixuan.cn at gmail.com Wed Jun 1 21:05:46 2016 From: zhangpeixuan.cn at gmail.com (Zhang Peixuan) Date: Thu, 2 Jun 2016 09:05:46 +0800 Subject: [CMake] How to use CMAKE_MFC_FLAG for only one on executables? In-Reply-To: References: Message-ID: Thanks for the reply. unset doesn't work at all. So I have to use a own CMakelist.txt in sub-diretory? And other idea? Thanks, Peixuan 2016-06-02 0:13 GMT+08:00 David Cole : > Or just isolate it into its own CMakeLists.txt file in a sub-directory? > > On Wed, Jun 1, 2016 at 8:34 AM, Nicholas Braden > wrote: > > Have you tried unsetting it after adding the executable in question? > > If that doesn't work, is it possible to make the MFX executable be the > > very last executable added in your project? > > > > On Wed, Jun 1, 2016 at 4:50 AM, Zhang Peixuan > wrote: > >> Hello All, > >> > >> I want to use CMake to manage my MFC projects, and I added the following > >> code: > >> > >> set( CMAKE_MFC_FLAG 2) > >> add_executable(MFCDemo WIN32 > >> ${MFC_RESOURCE_FILES} > >> ${MFC_HEADER_FILES} > >> ${MFC_SOURCE_FILES} > >> ) > >> target_compile_definitions(MFCDemo > >> PUBLIC -D_AFXDLL=1 > >> PUBLIC -D_UNICODE > >> PUBLIC -DUNICODE > >> ) > >> > >> It works. > >> However, my question is that: In addition to the MFC executable, I still > >> have some non-MFC executables, > >> and once CMAKE_MFC_FLAG is set, all the add_executables' property > should be > >> "Use MFC in a Shared DLL". > >> In fact, I want only one MFC executable, and make sure all other > executables > >> are "Use Standard Windows Library". > >> Is there any way to implement it? It seems CMAKE_MFC_FLAG does not work > with > >> set_target_property or other commands. > >> > >> Thanks, > >> Peixuan Zhang > >> > >> -- > >> > >> 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 rwan.work at gmail.com Thu Jun 2 01:14:27 2016 From: rwan.work at gmail.com (Raymond Wan) Date: Thu, 2 Jun 2016 13:14:27 +0800 Subject: [CMake] CPack with BZIP2 is a lot slower than GNU tar In-Reply-To: References: Message-ID: Hi, On Wed, Jun 1, 2016 at 8:26 PM, Alessio wrote: > Is anyone else having problems with the speed of cpack? > > Out of one of our code bases we produce two packages on Linux using the > BZIP2 generator with CMake 3.4.0. I provide a few stats on the packages > below. They are not particularly fat. GNU tar will take ~1min to tar the > biggest one up with the same compression tech. > > CPack takes a good 4~5min for each of them. I have to admit that I'm not a cpack user. So, I'm not sure if I can help. But are you comparing: "cmake + bzip" versus "cmake + tar"? By default tar doesn't do any compression. It concatenates all of the files together. That might be why it is so fast. Perhaps you can remove cmake from the equation and compare bzip with tar? I *guess* the speed difference might be the same and perhaps unrelated to cmake. (Just my guess, of course.) On the other hand, if speed is an issue, consider using gzip. It won't compress as well as bzip, but it should be faster in terms of compression time. Ray From masariello+cmake.org at gmail.com Thu Jun 2 05:29:57 2016 From: masariello+cmake.org at gmail.com (Alessio) Date: Thu, 2 Jun 2016 10:29:57 +0100 Subject: [CMake] CPack with BZIP2 is a lot slower than GNU tar In-Reply-To: References: Message-ID: I'm comparing the following two things: 1. cpack TBZ2 generator 2. "tar cjf" the same files as with cpack. (j option = BZIP2 compression) I cannot avoid CPack. It takes care of way too many little details of the packaging. Obviously we use it via lots of install() statements in our CMakeLists.txt files. On 2 June 2016 at 06:14, Raymond Wan wrote: > Hi, > > > On Wed, Jun 1, 2016 at 8:26 PM, Alessio > wrote: > > Is anyone else having problems with the speed of cpack? > > > > Out of one of our code bases we produce two packages on Linux using the > > BZIP2 generator with CMake 3.4.0. I provide a few stats on the packages > > below. They are not particularly fat. GNU tar will take ~1min to tar the > > biggest one up with the same compression tech. > > > > CPack takes a good 4~5min for each of them. > > > I have to admit that I'm not a cpack user. So, I'm not sure if I can help. > > But are you comparing: > > "cmake + bzip" versus "cmake + tar"? > > By default tar doesn't do any compression. It concatenates all of the > files together. That might be why it is so fast. Perhaps you can > remove cmake from the equation and compare bzip with tar? I *guess* > the speed difference might be the same and perhaps unrelated to cmake. > (Just my guess, of course.) > > On the other hand, if speed is an issue, consider using gzip. It > won't compress as well as bzip, but it should be faster in terms of > compression time. > > Ray > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eschnigma at openmailbox.org Thu Jun 2 06:06:50 2016 From: eschnigma at openmailbox.org (eschnigma at openmailbox.org) Date: Thu, 02 Jun 2016 13:06:50 +0300 Subject: [CMake] =?utf-8?q?No_debugging_symbols_found_when_using_-DCMAKE?= =?utf-8?q?=5FBUILD=5FTYPE=3DDebug?= In-Reply-To: References: <5355465.egJ6labZND@manjaro> <2757745.3M4lAMPy81@manjaro> <3060435.q23ZzKDfkT@manjaro> Message-ID: Renaming the folder did indeed fix it here. I tested with g++ and Clang, both work fine. This is on a different machine than I was posting from before, but it's also running Manjaro. I will test this on my main machine once I'm home, which will be be in six hours or so, and I'll let you know the results. On 2016-06-01 23:54, Chuck Atkins wrote: > Wow, so this is actually a pretty obscure find. You've definitely stumbled across a bug. It has nothing to do with debug symbols and everything to do with compiler identification. It seems that our binary strings parsing is broken when "[anything]" is in the file path. Without looking at the code too deeply, i imagine something is not getting properly escaped somewhere. As a workaround for now, rename your "[Code]" folder to "Code" and then it should work (lame I know). I would ask you to please file a bug report but new user registration is currently disabled due to some spam issues we were having. I'll put it in the queue for issues to address in future releases but I doubt it will make it into the 3.6 release since it seems to have been there for a long time without affecting too many users but it should be able to get fixed in a future release. > > Once we open the bug tracker up again then please definitely report the issue (unless you already have an account then go ahead and report it now). > > Thanks for the find! > > - Chuck > > On Wed, Jun 1, 2016 at 1:59 PM, Esch Nigma wrote: > >> I tried it out just now. >> >> I pulled and installed a couple 5.x packages from the Arch archive: >> >> https://archive.archlinux.org/packages/l/ [1] >> >> The packages: >> >> gcc-libs-multilib-5.3.0-4-x86_64.pkg.tar.xz >> >> gcc-multilib-5.3.0-4-x86_64.pkg.tar.xz >> >> lib32-gcc-libs-5.3.0-4-x86_64.p >> >> The downgrade didn't change anything for my Hello World program. >> >> For the project I'm actively working on, it broke everything, since C++11 is no longer recognized. >> >> On my system I had to pull the 'multilib' versions, as this is what my system seems to be using. If requested, I can try to switch to normal gcc to test that out. >> >> On Wednesday, June 1, 2016 11:46:40 AM EEST Chuck Atkins wrote: >> >> Interesting. It seems CMake is having trouble identifying GCC in 6.1.1. Do you have a 5.x compiler available? If so does it work with that? That would help narrow it down to a gcc6 issue vs something about how Manjaro packages compilers. >> >> - Chuck >> >> On Wed, Jun 1, 2016 at 10:49 AM, Esch Nigma wrote: >> >> The standard choice is c++ >> >> [eschnigma at manjaro ~]$ c++ --version >> c++ (GCC) 6.1.1 20160501 >> Copyright (C) 2016 Free Software Foundation, Inc. >> This is free software; see the source for copying conditions. There is NO >> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. >> >> But I've tried enforcing g++ as such: >> >> -DCMAKE_C_COMPILER:FILEPATH=/usr/bin/gcc -DCMAKE_CXX_COMPILER:STRING=/usr/bin/g++ >> >> And that has the same results. >> >> Version: >> >> [eschnigma at manjaro ~]$ g++ --version >> g++ (GCC) 6.1.1 20160501 >> Copyright (C) 2016 Free Software Foundation, Inc. >> This is free software; see the source for copying conditions. There is NO >> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. >> >> On Wednesday, June 1, 2016 10:05:21 AM EEST Chuck Atkins wrote: >> >> [eschnigma at manjaro build]$ cmake .. -DCMAKE_BUILD_TYPE:STRING="Debug" >> -- The C compiler identification is unknown >> -- The CXX compiler identification is unknown >> >> This is definitely the reason for no debug symbols. If the compiler is unknown then CMake won't know the right flags to pass to generate debug info. The more important question though is why the compiler can't be identified. What compiler is being used? Can check with /usr/bin/c++ --version ? Links: ------ [1] https://archive.archlinux.org/packages/l/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Robert.Bielik at dirac.com Thu Jun 2 10:25:33 2016 From: Robert.Bielik at dirac.com (Robert Bielik) Date: Thu, 2 Jun 2016 14:25:33 +0000 Subject: [CMake] MSYS Makefiles generator problem with install/strip Message-ID: <5691c2a1d9164e7a97bcd83a4df4afbf@hosted3-mb01.itm.host> Hi, I have a problem with the install/strip target not working when using the MSYS Makefiles generator. I get the following result in cmake_install.cmake: file(INSTALL DESTINATION "c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a" TYPE SHARED_LIBRARY FILES "C:/Dev/jniAndroid/libapi_native.so") if(EXISTS "$ENV{DESTDIR}/c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a/libapi_native.so " AND NOT IS_SYMLINK "$ENV{DESTDIR}/c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a/libapi_native.so") if(CMAKE_INSTALL_DO_STRIP) execute_process(COMMAND "C:/android/android-ndk-r11c/standalone/arm/bin/arm-linux-androideabi-strip.exe" "$ENV{DESTDIR}/c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a/libapi_native.so") endif() endif() endif() The above should instead look like: file(INSTALL DESTINATION "c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a" TYPE SHARED_LIBRARY FILES "C:/Dev/jniAndroid/libapi_native.so") if(EXISTS "c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a/libapi_native.so" AND NOT IS_SYMLINK "c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a/libapi_native.so") if(CMAKE_INSTALL_DO_STRIP) execute_process(COMMAND "C:/android/android-ndk-r11c/standalone/arm/bin/arm-linux-androideabi-strip.exe" "c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a/libapi_native.so") endif() endif() endif() Then the install/strip target works. Regards /Robert From bill.hoffman at kitware.com Thu Jun 2 11:42:02 2016 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Thu, 2 Jun 2016 11:42:02 -0400 Subject: [CMake] CPack with BZIP2 is a lot slower than GNU tar In-Reply-To: References: Message-ID: <12073046-1bd4-c2c7-be5a-f1d7f3c4ff25@kitware.com> On 6/2/2016 5:29 AM, Alessio wrote: > I'm comparing the following two things: > 1. cpack TBZ2 generator > 2. "tar cjf" the same files as with cpack. (j option = BZIP2 compression) > > I cannot avoid CPack. It takes care of way too many little details of > the packaging. Obviously we use it via lots of install() statements in > our CMakeLists.txt files. > Sounds like it needs some performance testing. One thing to try would be to compare cmake -E tar with tar and see if it is libtar that is slow, or something CPack is doing. After that, maybe calgrind or other tools to profile cpack. -Bill From post at hendrik-sattler.de Thu Jun 2 13:16:10 2016 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Thu, 02 Jun 2016 19:16:10 +0200 Subject: [CMake] MSYS Makefiles generator problem with install/strip In-Reply-To: <5691c2a1d9164e7a97bcd83a4df4afbf@hosted3-mb01.itm.host> References: <5691c2a1d9164e7a97bcd83a4df4afbf@hosted3-mb01.itm.host> Message-ID: <14E3C438-9599-4148-8514-CE5C159629BE@hendrik-sattler.de> Hi, Are you using absolute paths in your install() commands? You better don't. HS Am 2. Juni 2016 16:25:33 MESZ, schrieb Robert Bielik : >Hi, > >I have a problem with the install/strip target not working when using >the MSYS Makefiles generator. I get the following result in >cmake_install.cmake: > >file(INSTALL DESTINATION >"c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a" TYPE >SHARED_LIBRARY FILES "C:/Dev/jniAndroid/libapi_native.so") >if(EXISTS >"$ENV{DESTDIR}/c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a/libapi_native.so >" AND >NOT IS_SYMLINK >"$ENV{DESTDIR}/c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a/libapi_native.so") > if(CMAKE_INSTALL_DO_STRIP) >execute_process(COMMAND >"C:/android/android-ndk-r11c/standalone/arm/bin/arm-linux-androideabi-strip.exe" >"$ENV{DESTDIR}/c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a/libapi_native.so") > endif() > endif() >endif() > >The above should instead look like: > >file(INSTALL DESTINATION >"c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a" TYPE >SHARED_LIBRARY FILES "C:/Dev/jniAndroid/libapi_native.so") >if(EXISTS >"c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a/libapi_native.so" >AND >NOT IS_SYMLINK >"c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a/libapi_native.so") > if(CMAKE_INSTALL_DO_STRIP) >execute_process(COMMAND >"C:/android/android-ndk-r11c/standalone/arm/bin/arm-linux-androideabi-strip.exe" >"c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a/libapi_native.so") > endif() > endif() >endif() > >Then the install/strip target works. > >Regards >/Robert -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. From Robert.Bielik at dirac.com Thu Jun 2 13:23:26 2016 From: Robert.Bielik at dirac.com (Robert Bielik) Date: Thu, 2 Jun 2016 17:23:26 +0000 Subject: [CMake] MSYS Makefiles generator problem with install/strip In-Reply-To: <14E3C438-9599-4148-8514-CE5C159629BE@hendrik-sattler.de> References: <5691c2a1d9164e7a97bcd83a4df4afbf@hosted3-mb01.itm.host>, <14E3C438-9599-4148-8514-CE5C159629BE@hendrik-sattler.de> Message-ID: <000f4250.66fbe3a938f2b637@dirac.se> Hi Hendrik, I think I do, yes. Would this not be a normal use case, specifically on Linux, where the bin library would be /usr/bin? How would that work with relative paths? I think it would be a bug if install cannot handle arbitrary paths. I'll try though to see if I can work around this... behavior... Regards /R Skickat fr?n min LG-Mobil ------ Ursprungligt meddelande------ Fr?n: Hendrik Sattler Datum: tors, 2 jun 2016 19:16 Till: Robert Bielik;cmake at cmake.org; ?mne:Re: [CMake] MSYS Makefiles generator problem with install/strip Hi, Are you using absolute paths in your install() commands? You better don't. HS Am 2. Juni 2016 16:25:33 MESZ, schrieb Robert Bielik : >Hi, > >I have a problem with the install/strip target not working when using >the MSYS Makefiles generator. I get the following result in >cmake_install.cmake: > >file(INSTALL DESTINATION >"c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a" TYPE >SHARED_LIBRARY FILES "C:/Dev/jniAndroid/libapi_native.so") >if(EXISTS >"$ENV{DESTDIR}/c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a/libapi_native.so >" AND >NOT IS_SYMLINK >"$ENV{DESTDIR}/c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a/libapi_native.so") > if(CMAKE_INSTALL_DO_STRIP) >execute_process(COMMAND >"C:/android/android-ndk-r11c/standalone/arm/bin/arm-linux-androideabi-strip.exe" >"$ENV{DESTDIR}/c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a/libapi_native.so") > endif() > endif() >endif() > >The above should instead look like: > >file(INSTALL DESTINATION >"c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a" TYPE >SHARED_LIBRARY FILES "C:/Dev/jniAndroid/libapi_native.so") >if(EXISTS >"c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a/libapi_native.so" >AND >NOT IS_SYMLINK >"c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a/libapi_native.so") > if(CMAKE_INSTALL_DO_STRIP) >execute_process(COMMAND >"C:/android/android-ndk-r11c/standalone/arm/bin/arm-linux-androideabi-strip.exe" >"c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a/libapi_native.so") > endif() > endif() >endif() > >Then the install/strip target works. > >Regards >/Robert -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. -------------- next part -------------- An HTML attachment was scrubbed... URL: From post at hendrik-sattler.de Thu Jun 2 14:32:16 2016 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Thu, 02 Jun 2016 20:32:16 +0200 Subject: [CMake] MSYS Makefiles generator problem with install/strip In-Reply-To: <000f4250.66fbe3a938f2b637@dirac.se> References: <5691c2a1d9164e7a97bcd83a4df4afbf@hosted3-mb01.itm.host>, <14E3C438-9599-4148-8514-CE5C159629BE@hendrik-sattler.de> <000f4250.66fbe3a938f2b637@dirac.se> Message-ID: <2637EBC4-EE53-448C-8A9A-F378ABAD7AEB@hendrik-sattler.de> Hi, Am 2. Juni 2016 19:23:26 MESZ, schrieb Robert Bielik : >Hi Hendrik, > > > >I think I do, yes. Would this not be a normal use case, specifically on >Linux, where the bin library would be /usr/bin? How would that work >with relative paths? Installation is always relative to CMAKE_INSTALL_PREFIX. On Linux, this defaults to /usr/local. Using the variables from GNUInstallDirs module saves you lots of trouble like library locations on Debian or Rehat. It's actually pretty simple and only very special cases differ from this. >I think it would be a bug if install cannot handle arbitrary paths. The problem is the drive letter of the absolute path that can hardly be concatenated with a staging folder that you can define with DESTDIR like make install DESTDIR=mystagedir and the files go to their relative locations in // You gain a lot more flexibility by adopting this than hard encoding path in the install() commands. >I'll try though to see if I can work around this... behavior... Regards, HS >------ Ursprungligt meddelande------ > >Fr?n: Hendrik Sattler > >Datum: tors, 2 jun 2016 19:16 > >Till: Robert Bielik;cmake at cmake.org; > >?mne:Re: [CMake] MSYS Makefiles generator problem with install/strip > > > >Hi, > >Are you using absolute paths in your install() commands? You better >don't. > >HS > > >Am 2. Juni 2016 16:25:33 MESZ, schrieb Robert Bielik >: >>Hi, >> >>I have a problem with the install/strip target not working when using >>the MSYS Makefiles generator. I get the following result in >>cmake_install.cmake: >> >>file(INSTALL DESTINATION >>"c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a" TYPE >>SHARED_LIBRARY FILES "C:/Dev/jniAndroid/libapi_native.so") >>if(EXISTS >>"$ENV{DESTDIR}/c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a/libapi_native.so >>" AND >>NOT IS_SYMLINK >>"$ENV{DESTDIR}/c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a/libapi_native.so") >> if(CMAKE_INSTALL_DO_STRIP) >>execute_process(COMMAND >>"C:/android/android-ndk-r11c/standalone/arm/bin/arm-linux-androideabi-strip.exe" >>"$ENV{DESTDIR}/c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a/libapi_native.so") >> endif() >> endif() >>endif() >> >>The above should instead look like: >> >>file(INSTALL DESTINATION >>"c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a" TYPE >>SHARED_LIBRARY FILES "C:/Dev/jniAndroid/libapi_native.so") >>if(EXISTS >>"c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a/libapi_native.so" >>AND >>NOT IS_SYMLINK >>"c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a/libapi_native.so") >> if(CMAKE_INSTALL_DO_STRIP) >>execute_process(COMMAND >>"C:/android/android-ndk-r11c/standalone/arm/bin/arm-linux-androideabi-strip.exe" >>"c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a/libapi_native.so") >> endif() >> endif() >>endif() >> >>Then the install/strip target works. >> >>Regards >>/Robert > >-- >Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail >gesendet. > > >------------------------------------------------------------------------ -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. From Robert.Bielik at dirac.com Thu Jun 2 14:34:32 2016 From: Robert.Bielik at dirac.com (Robert Bielik) Date: Thu, 2 Jun 2016 18:34:32 +0000 Subject: [CMake] MSYS Makefiles generator problem with install/strip In-Reply-To: <2637EBC4-EE53-448C-8A9A-F378ABAD7AEB@hendrik-sattler.de> References: <5691c2a1d9164e7a97bcd83a4df4afbf@hosted3-mb01.itm.host>, <14E3C438-9599-4148-8514-CE5C159629BE@hendrik-sattler.de> <000f4250.66fbe3a938f2b637@dirac.se>, <2637EBC4-EE53-448C-8A9A-F378ABAD7AEB@hendrik-sattler.de> Message-ID: <000f4250.4ce30063765cf42d@dirac.se> Cheers Hendrik, I'll try to use that approach. Thanx! Regards /R Skickat fr?n min LG-Mobil ------ Ursprungligt meddelande------ Fr?n: Hendrik Sattler Datum: tors, 2 jun 2016 20:32 Till: Robert Bielik;cmake at cmake.org; ?mne:Re: [CMake] MSYS Makefiles generator problem with install/strip Hi, Am 2. Juni 2016 19:23:26 MESZ, schrieb Robert Bielik : >Hi Hendrik, > > > >I think I do, yes. Would this not be a normal use case, specifically on >Linux, where the bin library would be /usr/bin? How would that work >with relative paths? Installation is always relative to CMAKE_INSTALL_PREFIX. On Linux, this defaults to /usr/local. Using the variables from GNUInstallDirs module saves you lots of trouble like library locations on Debian or Rehat. It's actually pretty simple and only very special cases differ from this. >I think it would be a bug if install cannot handle arbitrary paths. The problem is the drive letter of the absolute path that can hardly be concatenated with a staging folder that you can define with DESTDIR like make install DESTDIR=mystagedir and the files go to their relative locations in // You gain a lot more flexibility by adopting this than hard encoding path in the install() commands. >I'll try though to see if I can work around this... behavior... Regards, HS >------ Ursprungligt meddelande------ > >Fr?n: Hendrik Sattler > >Datum: tors, 2 jun 2016 19:16 > >Till: Robert Bielik;cmake at cmake.org; > >?mne:Re: [CMake] MSYS Makefiles generator problem with install/strip > > > >Hi, > >Are you using absolute paths in your install() commands? You better >don't. > >HS > > >Am 2. Juni 2016 16:25:33 MESZ, schrieb Robert Bielik >: >>Hi, >> >>I have a problem with the install/strip target not working when using >>the MSYS Makefiles generator. I get the following result in >>cmake_install.cmake: >> >>file(INSTALL DESTINATION >>"c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a" TYPE >>SHARED_LIBRARY FILES "C:/Dev/jniAndroid/libapi_native.so") >>if(EXISTS >>"$ENV{DESTDIR}/c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a/libapi_native.so >>" AND >>NOT IS_SYMLINK >>"$ENV{DESTDIR}/c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a/libapi_native.so") >> if(CMAKE_INSTALL_DO_STRIP) >>execute_process(COMMAND >>"C:/android/android-ndk-r11c/standalone/arm/bin/arm-linux-androideabi-strip.exe" >>"$ENV{DESTDIR}/c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a/libapi_native.so") >> endif() >> endif() >>endif() >> >>The above should instead look like: >> >>file(INSTALL DESTINATION >>"c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a" TYPE >>SHARED_LIBRARY FILES "C:/Dev/jniAndroid/libapi_native.so") >>if(EXISTS >>"c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a/libapi_native.so" >>AND >>NOT IS_SYMLINK >>"c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a/libapi_native.so") >> if(CMAKE_INSTALL_DO_STRIP) >>execute_process(COMMAND >>"C:/android/android-ndk-r11c/standalone/arm/bin/arm-linux-androideabi-strip.exe" >>"c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a/libapi_native.so") >> endif() >> endif() >>endif() >> >>Then the install/strip target works. >> >>Regards >>/Robert > >-- >Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail >gesendet. > > >------------------------------------------------------------------------ -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Thu Jun 2 14:36:53 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 2 Jun 2016 14:36:53 -0400 Subject: [CMake] No debugging symbols found when using -DCMAKE_BUILD_TYPE=Debug In-Reply-To: References: <5355465.egJ6labZND@manjaro> <2757745.3M4lAMPy81@manjaro> <3060435.q23ZzKDfkT@manjaro> Message-ID: <57507CC5.9020305@kitware.com> On 06/01/2016 04:54 PM, Chuck Atkins wrote: > Wow, so this is actually a pretty obscure find. You've definitely stumbled > across a bug. It has nothing to do with debug symbols and everything to do > with compiler identification. It seems that our binary strings parsing is > broken when "[anything]" is in the file path. This should fix it: CMakeDetermineCompilerId: Fix compiler id with square brackets in the path https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a7d1c4ec -Brad From vladimir.chebotarev at gmail.com Thu Jun 2 15:17:30 2016 From: vladimir.chebotarev at gmail.com (Vladimir Chebotarev) Date: Thu, 02 Jun 2016 22:17:30 +0300 Subject: [CMake] add_custom_command, POST_BUILD In-Reply-To: <87pos01xxa.fsf@therning.org> References: <87pos01xxa.fsf@therning.org> Message-ID: <5c51bec3-78a5-47e5-bf7e-4885d986d886@gmail.com> Hi. The reason is to make build to fail as soon as possible if core library doesn't work properly. In C++ world that could be critical as hell because building process can last hours even on 32 cores. And it will make CMake more ecological tool as it will reduce the energy wasted. :) On Jun 1, 2016, Magnus Therning wrote: > >Vladimir Chebotarev writes: > >> Hi there. >> >> At the moment one can add a command executing after a build of a >target >> using: >> add_custom_command(... POST_BUILD...) >> >> However if the command have a dependencies which build after the >target, >> there is practically no way to specify it. >> >> Simple case: we have a library and tests for it. E.g. I want them to >run in >> POST_BUILD of a library. But, tests already depends on the library so >I >> can't make them built before it. >> >> There are few possible solutions to that: >> 1) add possibility to set dependencies for add_custom_command in >POST_BUILD >> mode; >> 2) add possibility to populate list of targets if we have specified >ones in >> list. >> >> Or maybe correct me if I miss something. > >Have you not simply missed add_test()? ;) > >What's the reason for wanting the tests to run post-build, rather than >on `make test`? > >/M Kind regards, Vladimir. From chuck.atkins at kitware.com Thu Jun 2 15:43:39 2016 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Thu, 2 Jun 2016 15:43:39 -0400 Subject: [CMake] add_custom_command, POST_BUILD In-Reply-To: References: Message-ID: Could you just make the tests run in the post-build of the test? add_library(Foo Foo.cxx) add_executable(FooTest FooTest.cxx) target_link_libraries(FooTest Foo) add_custom_command(TARGET FooTest POST_BUILD COMMAND $ $ ) That way the the test is run as part of it's build. - Chuck On Wed, Jun 1, 2016 at 11:46 AM, Vladimir Chebotarev < vladimir.chebotarev at gmail.com> wrote: > Hi there. > > At the moment one can add a command executing after a build of a target > using: > add_custom_command(... POST_BUILD...) > > However if the command have a dependencies which build after the target, > there is practically no way to specify it. > > Simple case: we have a library and tests for it. E.g. I want them to run > in POST_BUILD of a library. But, tests already depends on the library so I > can't make them built before it. > > There are few possible solutions to that: > 1) add possibility to set dependencies for add_custom_command in > POST_BUILD mode; > 2) add possibility to populate list of targets if we have specified ones > in list. > > Or maybe correct me if I miss something. > > Kind regards, Vladimir. > > -- > > 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 iosif.neitzke+cmake at gmail.com Thu Jun 2 15:49:39 2016 From: iosif.neitzke+cmake at gmail.com (iosif neitzke) Date: Thu, 2 Jun 2016 14:49:39 -0500 Subject: [CMake] add_custom_command, POST_BUILD In-Reply-To: References: Message-ID: On Thu, Jun 2, 2016 at 2:43 PM, Chuck Atkins wrote: > Could you just make the tests run in the post-build of the test? > > add_library(Foo Foo.cxx) > > add_executable(FooTest FooTest.cxx) > target_link_libraries(FooTest Foo) > > add_custom_command(TARGET FooTest POST_BUILD > COMMAND $ $ > ) > > That way the the test is run as part of it's build. > This is what we do for our Unit Test projects. We also register the test executable with CTest's add_test too. > > - Chuck > > On Wed, Jun 1, 2016 at 11:46 AM, Vladimir Chebotarev > wrote: >> >> Hi there. >> >> At the moment one can add a command executing after a build of a target >> using: >> add_custom_command(... POST_BUILD...) >> >> However if the command have a dependencies which build after the target, >> there is practically no way to specify it. >> >> Simple case: we have a library and tests for it. E.g. I want them to run >> in POST_BUILD of a library. But, tests already depends on the library so I >> can't make them built before it. >> >> There are few possible solutions to that: >> 1) add possibility to set dependencies for add_custom_command in >> POST_BUILD mode; >> 2) add possibility to populate list of targets if we have specified ones >> in list. >> >> Or maybe correct me if I miss something. >> >> Kind regards, Vladimir. >> >> >> -- >> >> 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 Miroslav.Ilias at umb.sk Thu Jun 2 16:10:28 2016 From: Miroslav.Ilias at umb.sk (Ilias Miroslav) Date: Thu, 2 Jun 2016 20:10:28 +0000 Subject: [CMake] execute short program during cmake configuration ? Message-ID: <1464898228459.48522@umb.sk> Greetings, dear experts, we have (two) short Fortran programs (detection of integer*4/8 for math libraries) which we would like to build and execute during project's configuration phase. There is the " CheckFortranSourceCompiles" command to compile a Fortran source code during project's configure time. However, we would be glad also to execute the resulting a.out binary and check if it passes or crashes. Any help, please ? Is there a way to compile/execute short program in the configuration stage of the (big) project ? Yours, Miro ( CMake co-builder for http://www.diracprogram.org ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Thu Jun 2 17:13:03 2016 From: craig.scott at crascit.com (Craig Scott) Date: Fri, 3 Jun 2016 07:13:03 +1000 Subject: [CMake] execute short program during cmake configuration ? In-Reply-To: <1464898228459.48522@umb.sk> References: <1464898228459.48522@umb.sk> Message-ID: It might be overkill for what you want, but this stack overflow question deals with a very similar situation. On Fri, Jun 3, 2016 at 6:10 AM, Ilias Miroslav wrote: > > Greetings, dear experts, > > > we have (two) short Fortran programs (detection of integer*4/8 for math > libraries) which we would like to build and execute during project's > configuration phase. > > > There is the " CheckFortranSourceCompiles" command to compile a Fortran > source code during project's configure time. However, we would be glad > also to execute the resulting a.out binary and check if it passes or > crashes. > > > Any help, please ? Is there a way to compile/execute short program in the > configuration stage of the (big) project ? > > > Yours, Miro > > ( CMake co-builder for http://www.diracprogram.org ) > > > > > -- > > 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 http://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From irwin at beluga.phys.uvic.ca Thu Jun 2 17:56:47 2016 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Thu, 2 Jun 2016 14:56:47 -0700 (PDT) Subject: [CMake] execute short program during cmake configuration ? In-Reply-To: <1464898228459.48522@umb.sk> References: <1464898228459.48522@umb.sk> Message-ID: On 2016-06-02 20:10-0000 Ilias Miroslav wrote: > > Greetings, dear experts, > > > we have (two) short Fortran programs (detection of integer*4/8 for math libraries) which we would like to build and execute during project's configuration phase. > > > There is the " CheckFortranSourceCompiles" command to compile a Fortran source code during project's configure time. However, we would be glad also to execute the resulting a.out binary and check if it passes or crashes. > > > Any help, please ? Is there a way to compile/execute short program in the configuration stage of the (big) project ? Hi Ilias: It appears you want the Fortran equivalent of the CHECK_C_SOURCE_RUNS macro. So I suggest you copy that macro (found in Modules/CheckCSourceRuns.cmake) to your own source code where your other home-grown CMake macros are located, rename that macro to CHECK_FORTRAN_SOURCE_RUNS, and make the minor modifications to that macro that are appropriate for the Fortran case. By the way, such copy and modification is permitted/encouraged by the copyright license for CMake as given in Modules/CheckCSourceRuns.cmake although as that source file licensing text summary says you do have to put the full text of the license in that modified file. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From chrysalisx at gmail.com Thu Jun 2 21:06:51 2016 From: chrysalisx at gmail.com (Walter Gray) Date: Fri, 03 Jun 2016 01:06:51 +0000 Subject: [CMake] Calling find_package(self) for in-project builds Message-ID: I'm currently working on protobuf-3.0.0's cmake scripts, and I've hit a bit of a chicken and egg problem. There is an examples directory containing a CMakeLists.txt which we would like to work as both a standalone examples directory and include as a sub directory of the full build. For obvious reasons, the CMakeLists.txt file contains a call to find_package(protobuf). I can call find_package(protobuf HINTS ${CMAKE_BINARY_DIR}) outside of the examples/CMakeLists.txt file to ensure that we've already found the correct version, but the problem is that the protobuf-config.cmake file includes the export-generated file protobuf-targets.cmake, as well as implementing some custom functions that we want to show off as part of the examples. The obvious solution to me was to use the export command to generate protobuf-targets.cmake, but there are 2 problems. First, export(EXPORT) doesn't create a file until generation time, but I can get around this using export(TARGETS). The second is that, reading CMP0024, this appears to be not garunted behavior, and actively discouraged. What would be the suggested way to handle this? -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicholas11braden at gmail.com Thu Jun 2 21:16:13 2016 From: nicholas11braden at gmail.com (Nicholas Braden) Date: Thu, 2 Jun 2016 20:16:13 -0500 Subject: [CMake] Calling find_package(self) for in-project builds In-Reply-To: References: Message-ID: Although not ideal, you could alias the targets to the names they would have when imported with find_package() by using add_library(ALIAS), and then use if(TARGET) to conditionally call find_package(). This also is a step toward supporting using the library via add_subdirectory(), if that ever becomes a goal. On Thu, Jun 2, 2016 at 8:06 PM, Walter Gray wrote: > I'm currently working on protobuf-3.0.0's cmake scripts, and I've hit a bit > of a chicken and egg problem. > > There is an examples directory containing a CMakeLists.txt which we would > like to work as both a standalone examples directory and include as a sub > directory of the full build. For obvious reasons, the CMakeLists.txt file > contains a call to find_package(protobuf). > > I can call find_package(protobuf HINTS ${CMAKE_BINARY_DIR}) outside of the > examples/CMakeLists.txt file to ensure that we've already found the correct > version, but the problem is that the protobuf-config.cmake file includes the > export-generated file protobuf-targets.cmake, as well as implementing some > custom functions that we want to show off as part of the examples. > > The obvious solution to me was to use the export command to generate > protobuf-targets.cmake, but there are 2 problems. First, export(EXPORT) > doesn't create a file until generation time, but I can get around this using > export(TARGETS). The second is that, reading CMP0024, this appears to be not > garunted behavior, and actively discouraged. > > What would be the suggested way to handle 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 guy at alum.mit.edu Thu Jun 2 21:18:39 2016 From: guy at alum.mit.edu (Guy Harris) Date: Thu, 2 Jun 2016 18:18:39 -0700 Subject: [CMake] execute short program during cmake configuration ? In-Reply-To: References: <1464898228459.48522@umb.sk> Message-ID: <8B1EDD3F-45B6-4211-9419-3A0B284682B3@alum.mit.edu> On Jun 2, 2016, at 2:56 PM, Alan W. Irwin wrote: > It appears you want the Fortran equivalent of the CHECK_C_SOURCE_RUNS > macro. So I suggest you copy that macro (found in > Modules/CheckCSourceRuns.cmake) to your own source code where your > other home-grown CMake macros are located, rename that macro to > CHECK_FORTRAN_SOURCE_RUNS, and make the minor modifications to that > macro that are appropriate for the Fortran case. ...and contribute it back to the CMake maintainers to encourage its appearance in future releases? From chrysalisx at gmail.com Thu Jun 2 21:33:58 2016 From: chrysalisx at gmail.com (Walter Gray) Date: Fri, 03 Jun 2016 01:33:58 +0000 Subject: [CMake] Calling find_package(self) for in-project builds In-Reply-To: References: Message-ID: That only gets me part way - there's also the issue of the options & extra functions defined in protobuf-config.in. My best guess ATM would be to do something simmilar and create namespaced aliases, then just not include the protobuf-targets.cmake file from protobuf-config.cmake if CMAKE_CURRENT_LIST_DIR STREQUAL CMAKE_BINARY_DIR. On Thu, Jun 2, 2016 at 6:16 PM Nicholas Braden wrote: > Although not ideal, you could alias the targets to the names they > would have when imported with find_package() by using > add_library(ALIAS), and then use if(TARGET) to conditionally call > find_package(). This also is a step toward supporting using the > library via add_subdirectory(), if that ever becomes a goal. > > On Thu, Jun 2, 2016 at 8:06 PM, Walter Gray wrote: > > I'm currently working on protobuf-3.0.0's cmake scripts, and I've hit a > bit > > of a chicken and egg problem. > > > > There is an examples directory containing a CMakeLists.txt which we would > > like to work as both a standalone examples directory and include as a sub > > directory of the full build. For obvious reasons, the CMakeLists.txt file > > contains a call to find_package(protobuf). > > > > I can call find_package(protobuf HINTS ${CMAKE_BINARY_DIR}) outside of > the > > examples/CMakeLists.txt file to ensure that we've already found the > correct > > version, but the problem is that the protobuf-config.cmake file includes > the > > export-generated file protobuf-targets.cmake, as well as implementing > some > > custom functions that we want to show off as part of the examples. > > > > The obvious solution to me was to use the export command to generate > > protobuf-targets.cmake, but there are 2 problems. First, export(EXPORT) > > doesn't create a file until generation time, but I can get around this > using > > export(TARGETS). The second is that, reading CMP0024, this appears to be > not > > garunted behavior, and actively discouraged. > > > > What would be the suggested way to handle 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan at su-root.co.uk Thu Jun 2 23:45:27 2016 From: dan at su-root.co.uk (Dan Liew) Date: Thu, 2 Jun 2016 20:45:27 -0700 Subject: [CMake] Calling find_package(self) for in-project builds In-Reply-To: References: Message-ID: > What would be the suggested way to handle this? Couldn't you build the examples using CMake's ``ExternalProject`` module [1] and have that build after the main project has finished building? [1] https://cmake.org/cmake/help/v3.5/module/ExternalProject.html From chrysalisx at gmail.com Fri Jun 3 01:33:41 2016 From: chrysalisx at gmail.com (Walter Gray) Date: Fri, 03 Jun 2016 05:33:41 +0000 Subject: [CMake] Calling find_package(self) for in-project builds In-Reply-To: References: Message-ID: Interesting idea, that could be possible. On Thu, Jun 2, 2016 at 8:45 PM Dan Liew wrote: > > What would be the suggested way to handle this? > > Couldn't you build the examples using CMake's ``ExternalProject`` > module [1] and have that build after the main project has finished > building? > > [1] https://cmake.org/cmake/help/v3.5/module/ExternalProject.html > -------------- next part -------------- An HTML attachment was scrubbed... URL: From konstantin at podsvirov.pro Fri Jun 3 01:40:45 2016 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Fri, 03 Jun 2016 08:40:45 +0300 Subject: [CMake] Calling find_package(self) for in-project builds In-Reply-To: References: Message-ID: <6682711464932445@web29g.yandex.ru> An HTML attachment was scrubbed... URL: From petr.kmoch at gmail.com Fri Jun 3 03:51:29 2016 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Fri, 3 Jun 2016 09:51:29 +0200 Subject: [CMake] execute short program during cmake configuration ? In-Reply-To: <1464898228459.48522@umb.sk> References: <1464898228459.48522@umb.sk> Message-ID: Hi Miro, looks like you want to use the try_run() command ( https://cmake.org/cmake/help/latest/command/try_run.html ). Petr On 2 June 2016 at 22:10, Ilias Miroslav wrote: > > Greetings, dear experts, > > > we have (two) short Fortran programs (detection of integer*4/8 for math > libraries) which we would like to build and execute during project's > configuration phase. > > > There is the " CheckFortranSourceCompiles" command to compile a Fortran > source code during project's configure time. However, we would be glad > also to execute the resulting a.out binary and check if it passes or > crashes. > > > Any help, please ? Is there a way to compile/execute short program in the > configuration stage of the (big) project ? > > > Yours, Miro > > ( CMake co-builder for http://www.diracprogram.org ) > > > > > -- > > 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 chrysalisx at gmail.com Fri Jun 3 05:15:04 2016 From: chrysalisx at gmail.com (Walter Gray) Date: Fri, 03 Jun 2016 09:15:04 +0000 Subject: [CMake] Calling find_package(self) for in-project builds In-Reply-To: <6682711464932445@web29g.yandex.ru> References: <6682711464932445@web29g.yandex.ru> Message-ID: Very true, but adding the option of sometimes having the targets be aliases and sometimes having them be imported means that protobuf-module.cmake.in has to get much more complicated and means that we have to conditionally include protobuf-targets.cmake I'd like to minimize the differences between building the examples independently and building them as part of a combined build. On Thu, Jun 2, 2016 at 10:40 PM Konstantin Podsvirov < konstantin at podsvirov.pro> wrote: > Hello. > > 8:34, 3 june 2016 ?., Walter Gray : > > Interesting idea, that could be possible. > > > Possible, but realy need? It can be alternative. Now we can use ALIASES > for build tree configuration - It's work (I check) > > On Thu, Jun 2, 2016 at 8:45 PM Dan Liew wrote: > > > What would be the suggested way to handle this? > > Couldn't you build the examples using CMake's ``ExternalProject`` > module [1] and have that build after the main project has finished > building? > > [1] https://cmake.org/cmake/help/v3.5/module/ExternalProject.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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From blowekamp at mail.nih.gov Fri Jun 3 10:27:55 2016 From: blowekamp at mail.nih.gov (Lowekamp, Bradley (NIH/NLM/LHC) [C]) Date: Fri, 3 Jun 2016 14:27:55 +0000 Subject: [CMake] Problem building CMake with system OPENSSL Message-ID: <82B0E332-2EEF-4F1D-A3FF-389BBFE42211@mail.nih.gov> Hello, I am trying to build CMake on an old system with a new version of openssl. My build script was working with CMake 3.4 but is not working with 3.5.2 or current master. Here is how I am building cmake: cd /tmp/cmake-build && ../${CMAKE_ROOT}/bootstrap && make -j ${NPROC} && ./bin/cmake -DCMAKE_BUILD_TYPE:STRING=Release -DCMAKE_USE_OPENSSL:BOOL=ON -DOPENSSL_ROOT_DIR:PATH=/usr/local/ssl -DCMAKE_USE_SYSTEM_CURL:BOOL=OFF . && make -j${NPROC} ERROR MESSAGE: 41%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_cryptor.c.o cd /tmp/cmake-build/Utilities/cmlibarchive/libarchive && /opt/rh/devtoolset-2/root/usr/bin/gcc -DCURL_STATICLIB -DHAVE_CONFIG_H -DLIBARCHIVE_STATIC -DLZMA_API_STATIC -I/tmp/cmake/Utilities/cmlibarchive/libarchive -I/tmp/cmake-build/Utilities/cmlibarchive -I/tmp/cmake-build/Utilities -I/tmp/cmake/Utilities -I/tmp/cmake/Utilities/cmbzip2 -I/tmp/cmake/Utilities/cmliblzma/liblzma/api -w -O3 -DNDEBUG -std=gnu99 -o CMakeFiles/cmlibarchive.dir/archive_cryptor.c.o -c /tmp/cmake/Utilities/cmlibarchive/libarchive/archive_cryptor.c In file included from /tmp/cmake/Utilities/cmlibarchive/libarchive/archive_cryptor.c:32:0: /tmp/cmake/Utilities/cmlibarchive/libarchive/archive_cryptor_private.h:102:25: fatal error: openssl/evp.h: No such file or directory #include My work around it just to add "-I/usr/local/ssl/include/? to the CMAKE_C_FLAGS. Thanks! Brad -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Fri Jun 3 15:46:12 2016 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 3 Jun 2016 15:46:12 -0400 Subject: [CMake] [ANNOUNCE] CMake 3.6.0-rc1 now ready for testing! Message-ID: I am proud to announce the first CMake 3.6 release candidate. https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.6 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.6/release/3.6.html Some of the more significant features of CMake 3.6 are: * The "Visual Studio 14 2015" generator learned to support the Clang/C2 toolsets, e.g. with the "-T v140_clang_3_7" option. This feature is experimental. * The "list()" command gained a "FILTER" sub-command to filter list elements by regular expression. * A "CMAKE_TRY_COMPILE_TARGET_TYPE" variable was added to optionally tell the "try_compile()" command to build a static library instead of an executable. This is useful for cross-compiling toolchains that cannot link binaries without custom flags or scripts. * A "_CLANG_TIDY" target property and supporting "CMAKE__CLANG_TIDY" variable were introduced to tell the Makefile Generators and the "Ninja" generator to run "clang-tidy" along with the compiler for "C" and "CXX" languages. * The "ExternalProject" module leared the "GIT_SHALLOW 1" option to perform a shallow clone of a Git repository. * The "ExternalProject" module learned to initialize Git submodules recursively and also to initialize new submodules on updates. Use the "GIT_SUBMODULES" option to restrict which submodules are initalized and updated. * The "InstallRequiredSystemLibraries" module learned a new "CMAKE_INSTALL_UCRT_LIBRARIES" option to enable app-local deployment of the Windows Universal CRT libraries with Visual Studio 2015. * The "Compile Features" functionality is now aware of features supported by Intel C++ compilers versions 12.1 through 16.0 on UNIX platforms. Deprecated and Removed Features =============================== * The "CMakeForceCompiler" module and its macros are now deprecated. See module documentation for an explanation. * The "Visual Studio 7 .NET 2003" generator is now deprecated and will be removed in a future version of CMake. * The "Visual Studio 7" generator (for VS .NET 2002) has been removed. It had been deprecated since CMake 3.3. * The "Visual Studio 6" generator has been removed. It had been deprecated since CMake 3.3. CMake 3.6 Release Notes *********************** Changes made since CMake 3.5 include the following. New Features ============ Generators ---------- * The "Ninja" generator learned to produce phony targets of the form "sub/dir/all" to drive the build of a subdirectory. This is equivalent to "cd sub/dir; make all" with Makefile Generators. * The "Ninja" generator now includes system header files in build dependencies to ensure correct re-builds when system packages are updated. * The "Visual Studio 14 2015" generator learned to support the Clang/C2 toolsets, e.g. with the "-T v140_clang_3_7" option. This feature is experimental. Commands -------- * The "add_custom_command()" and "add_custom_target()" commands learned how to use the "CROSSCOMPILING_EMULATOR" executable target property. * The "install()" command learned a new "EXCLUDE_FROM_ALL" option to leave installation rules out of the default installation. * The "list()" command gained a "FILTER" sub-command to filter list elements by regular expression. * The "string(TIMESTAMP)" and "file(TIMESTAMP)" commands gained support for the "%s" placeholder. This is the number of seconds since the UNIX Epoch. * The "try_compile()" command source file signature now honors configuration-specific flags (e.g. "CMAKE__FLAGS_DEBUG") in the generated test project. Previously only the default such flags for the current toolchain were used. Variables --------- * A "CMAKE_DEPENDS_IN_PROJECT_ONLY" variable was introduced to tell Makefile Generators to limit dependency scanning only to files in the project source and build trees. * A new "CMAKE_HOST_SOLARIS" variable was introduced to indicate when CMake is running on an Oracle Solaris host. * A "CMAKE__STANDARD_INCLUDE_DIRECTORIES" variable was added for use by toolchain files to specify system include directories to be appended to all compiler command lines. * The "CMAKE__STANDARD_LIBRARIES" variable is now documented. It is intended for use by toolchain files to specify system libraries to be added to all linker command lines. * A "CMAKE_NINJA_OUTPUT_PATH_PREFIX" variable was introduced to tell the "Ninja" generator to configure the generated "build.ninja" file for use as a "subninja". * A "CMAKE_TRY_COMPILE_PLATFORM_VARIABLES" variable was added for use by toolchain files to specify platform-specific variables that must be propagated by the "try_compile()" command into test projects. * A "CMAKE_TRY_COMPILE_TARGET_TYPE" variable was added to optionally tell the "try_compile()" command to build a static library instead of an executable. This is useful for cross-compiling toolchains that cannot link binaries without custom flags or scripts. Properties ---------- * A "DEPLOYMENT_REMOTE_DIRECTORY" target property was introduced to tell the "Visual Studio 9 2008" and "Visual Studio 8 2005" generators to generate the "remote directory" for WinCE project deployment and debugger settings. * A "_CLANG_TIDY" target property and supporting "CMAKE__CLANG_TIDY" variable were introduced to tell the Makefile Generators and the "Ninja" generator to run "clang-tidy" along with the compiler for "C" and "CXX" languages. * A "TIMEOUT_AFTER_MATCH" test property was introduced to optionally tell CTest to enforce a secondary timeout after matching certain output from a test. * A "VS_CONFIGURATION_TYPE" target property was introduced to specify a custom project file type for Visual Studio Generators supporting VS 2010 and above. * A "VS_STARTUP_PROJECT" directory property was introduced to specify for Visual Studio Generators the default startup project for generated solutions (".sln" files). Modules ------- * The "CMakePushCheckState" module now pushes/pops/resets the variable "CMAKE_EXTRA_INCLUDE_FILE" used in "CheckTypeSize". * The "ExternalProject" module leared the "GIT_SHALLOW 1" option to perform a shallow clone of a Git repository. * The "ExternalProject" module learned to initialize Git submodules recursively and also to initialize new submodules on updates. Use the "GIT_SUBMODULES" option to restrict which submodules are initalized and updated. * The "ExternalProject" module leared the "DOWNLOAD_NO_EXTRACT 1" argument to skip extracting the file that is downloaded (e.g., for self-extracting shell installers or ".msi" files). * The "ExternalProject" module now uses "TLS_VERIFY" when fetching from git repositories. * The "FindBLAS" and "FindLAPACK" modules learned to support OpenBLAS. * The "FindCUDA" module learned to find the "cublas_device" library. * The "FindGTest" module "gtest_add_tests" function now causes CMake to automatically re-run when test sources change so that they can be re-scanned. * The "FindLTTngUST" module was introduced to find the LTTng-UST library. * The "FindPkgConfig" module learned to optionally create imported targets for the libraries it has found. * The "FindProtobuf" module learned to provide a "Protobuf_VERSION" variable and check the version number requested in a "find_package()" call. * The "InstallRequiredSystemLibraries" module learned a new "CMAKE_INSTALL_UCRT_LIBRARIES" option to enable app-local deployment of the Windows Universal CRT libraries with Visual Studio 2015. Platforms --------- * The Clang compiler is now supported on CYGWIN. * Support was added for the Bruce C Compiler with compiler id "Bruce". CTest ----- * The "ctest_update()" command now looks at the "CTEST_GIT_INIT_SUBMODULES" variable to determine whether submodules should be updated or not before updating. * The "ctest_update()" command will now synchronize submodules on an update. Updates which add submodules or change a submodule's URL will now be pulled properly. CPack ----- * The "CPackDeb" module learned how to handle "$ORIGIN" in "CMAKE_INSTALL_RPATH" when "CPACK_DEBIAN_PACKAGE_SHLIBDEPS" is used for dependency auto detection. * The "CPackDeb" module learned how to generate "DEBIAN/shlibs" contorl file when package contains shared libraries. * The "CPackDeb" module learned how to generate "DEBIAN/postinst" and "DEBIAN/postrm" files if the package installs libraries in ldconfig- controlled locations (e.g. "/lib/", "/usr/lib/"). * The "CPackDeb" module learned how to generate dependencies between Debian packages if multi-component setup is used and "CPACK_COMPONENT__DEPENDS" variables are set. For backward compatibility this feature is disabled by default. See "CPACK_DEBIAN_ENABLE_COMPONENT_DEPENDS". * The "CPackDeb" module learned how to set custom package file names including how to generate properly-named Debian packages: _-_.deb For backward compatibility this feature is disabled by default. See "CPACK_DEBIAN_FILE_NAME" and "CPACK_DEBIAN__FILE_NAME". * The "CPackDeb" module learned how to set the package release number ("DebianRevisionNumber" in package file name when used in combination with "DEB-DEFAULT" value set by "CPACK_DEBIAN_FILE_NAME"). See "CPACK_DEBIAN_PACKAGE_RELEASE". * The "CPackDeb" module learned how to set the package architecture per-component. See "CPACK_DEBIAN__PACKAGE_ARCHITECTURE". * The "CPackDMG" module learned a new option to tell the CPack "DragNDrop" generaor to skip the "/Applications" symlink. See the "CPACK_DMG_DISABLE_APPLICATIONS_SYMLINK" variable. * The "CPackIFW" module gained a new "cpack_ifw_update_repository()" command to update a QtIFW-specific repository from a remote repository. * The "CPackRPM" module learned how to set RPM "dist" tag as part of RPM "Release:" tag when enabled (mandatory on some Linux distributions for e.g. on Fedora). See "CPACK_RPM_PACKAGE_RELEASE_DIST". * The "CPackRPM" module learned how to set default values for owning user/group and file/directory permissions of package content. See "CPACK_RPM_DEFAULT_USER", "CPACK_RPM_DEFAULT_GROUP", "CPACK_RPM_DEFAULT_FILE_PERMISSIONS", "CPACK_RPM_DEFAULT_DIR_PERMISSIONS" and their per component counterparts. * The "CPackRPM" module learned how to set user defined package file names, how to specify that rpmbuild should decide on file name format as well as handling of multiple rpm packages generated by a single user defined spec file. See "CPACK_RPM_PACKAGE_NAME" and "CPACK_RPM__PACKAGE_NAME". * The "CPackRPM" module learned how to correctly handle symlinks that are pointing outside generated packages. Other ----- * The "Compile Features" functionality is now aware of features supported by Intel C++ compilers versions 12.1 through 16.0 on UNIX platforms. Deprecated and Removed Features =============================== * The "CMakeForceCompiler" module and its macros are now deprecated. See module documentation for an explanation. * The "find_library()", "find_path()", and "find_file()" commands no longer search in installation prefixes derived from the "PATH" environment variable on non-Windows platforms. This behavior was added in CMake 3.3 to support Windows hosts but has proven problematic on UNIX hosts. Users that keep some "/bin" directories in the "PATH" just for their tools do not necessarily want any supporting "/lib" directories searched. One may set the "CMAKE_PREFIX_PATH" environment variable with a ;-list of prefixes that are to be searched. * The "Visual Studio 7 .NET 2003" generator is now deprecated and will be removed in a future version of CMake. * The "Visual Studio 7" generator (for VS .NET 2002) has been removed. It had been deprecated since CMake 3.3. * The "Visual Studio 6" generator has been removed. It had been deprecated since CMake 3.3. Other Changes ============= * The precompiled OS X binary provided on "cmake.org" now requires OS X 10.7 or newer. * On Linux and FreeBSD platforms, when building CMake itself from source and not using a system-provided libcurl, OpenSSL is now used by default if it is found on the system. This enables SSL/TLS support for commands supporting network communication via "https", such as "file(DOWNLOAD)", "file(UPLOAD)", and "ctest_submit()". * The "cmake(1)" "--build" command-line tool now rejects multiple "-- target" options with an error instead of silently ignoring all but the last one. * "AUTOMOC" now diagnoses name collisions when multiple source files in different directories use "#include " with the same name (because the generated "moc_foo.cpp" files would collide). * The "FindBISON" module "BISON_TARGET" macro now supports special characters by passing the "VERBATIM" option to internal "add_custom_command()" calls. This may break clients that added escaping manually to work around the bug. * The "FindFLEX" module "FLEX_TARGET" macro now supports special characters by passing the "VERBATIM" option to internal "add_custom_command()" calls. This may break clients that added escaping manually to work around the bug. * The "FindProtobuf" module input and output variables were all renamed from "PROTOBUF_" to "Protobuf_" for consistency with other find modules. Input variables of the old case will be honored if provided, and output variables of the old case are always provided. * The "CPackRPM" module now supports upper cased component names in per component CPackRPM specific variables. E.g. component named "foo" now expects component specific variable to be "CPACK_RPM_FOO_PACKAGE_NAME" while before it expected "CPACK_RPM_foo_PACKAGE_NAME". Upper cased component name part in variables is compatible with convention used for other CPack variables. For back compatibility old format of variables is still valid and preferred if both versions of variable are set, but the preferred future use is upper cased component names in variables. New variables that will be added to CPackRPM in later versions will only support upper cased component variable format. From memory_leak at fastmail.fm Sat Jun 4 13:48:53 2016 From: memory_leak at fastmail.fm (smiley) Date: Sat, 04 Jun 2016 10:48:53 -0700 Subject: [CMake] Troulbes with INSTALL_PREFIX Message-ID: <1465062533.2959271.627931257.35ABC600@webmail.messagingengine.com> Hello guys, I have some troubles with CMakes handling of INSTALL_PREFIX. I am not sure if it is CMake or just me being a goof, so I hope somebody more knowledgable can guide me. As a background, I have a project (or rather a list of procets) I wish to do automated compile on. I have set of batch files to load stuff from git, configure, build and finally install everything. I keep two things separate in two separate trees defined by architecture and build. Nothing too fancy, just standard jazz, one tree for x66 and another for x64 and each tree has build and release branch. It works more or less as I wanted it, but one minor annoyance. When CMake does the final install, it seems to use the path from cache file and ignores that I am giving it another install path on the comand line. I have tried to delete CMakeCache.txt before doing build but it didn't help. The only way to get CMake to reflect difference in installation paths is to wipe entire build directory and to reconfigure everything from scratch for every build. That effectively doubles the time for build! CMake correctly builds different configurations but it seems to don't care for possible difference in installation. How it works is that, it always uses path from the first build. Thus if I build release build first it installs all binaries into "release" path, even for debug build, despite that it gets correct path on the command line. And contrary if I build debug build first it will install even binaries from release build into debug path. I can't post all batch files involved, there are several, configuration, driver helper, but some relevant points: Here is how INSTALL_PREFIX is constructed: (...) Set INSTALL_PREFIX=%INSTALL_BASE%\%BUILD_PLATFORM%\%BUILD_CONFIG% if not exist "%INSTALL_PREFIX%" mkdir "%INSTALL_PREFIX%" Set CMAKE_OPT=%CMAKE_OPT% -DCMAKE_INSTALL_PREFIX=%INSTALL_PREFIX% (...) All variables are correctly passed, and it builds everything fine but it refuses to reflect change in installation prefix in different builds. I just wonder if it is me goofing somewhere, or is it the way CMakes operates? Can I change this behaviour anyhow without need to parse CMakeCache.txt manually or as I do now as a quick fix, reconfiguring entire project from scratch for every configuration? As a curiosa, here is a small part of a driver file that actually invoke cmake, don't worry about other script it's just for configuration, so you get an idea of what I'm doing (vs2015 automated build): :dobuild if exist %BUILD_DIR% rd /S /q %BUILD_DIR% call %~dp0\cmake-setvars.bat cd "%BUILD_DIR%" set PATH=%INSTALL_PREFIX%\bin;%PATH%; cmake %CMAKE_OPT% .. MSBuild ALL_BUILD.vcxproj /p:Configuration=%BUILD_CONFIG%,Platform=%BUILD_PLATFORM%,PlatformToolset=v140 MSBuild INSTALL.vcxproj /p:Configuration=%BUILD_CONFIG%,Platform=%BUILD_PLATFORM% cd .. goto:eof All help is appreciated. -- http://www.fastmail.com - A no graphics, no pop-ups email service From Stuart_Mentzer at objexx.com Sat Jun 4 16:47:58 2016 From: Stuart_Mentzer at objexx.com (Stuart Mentzer) Date: Sat, 4 Jun 2016 16:47:58 -0400 Subject: [CMake] FindFreetype.cmake doesn't find debug library freetyped.lib Message-ID: An HTML attachment was scrubbed... URL: From Stuart_Mentzer at objexx.com Sat Jun 4 16:51:38 2016 From: Stuart_Mentzer at objexx.com (Stuart Mentzer) Date: Sat, 4 Jun 2016 16:51:38 -0400 Subject: [CMake] FindFreetype.cmake doesn't find debug library freetyped.lib In-Reply-To: References: Message-ID: <0ae68459-89d9-8157-0c63-2d34af301449@objexx.com> Hello, FindFreetype.cmake is failing to find the debug library on Windows because it is named freetype*d*.lib and freetyped isn't in the NAMES list. Is there some variable I can set to get it found or can freetyped get added to NAMES? Thanks, Stuart From rleigh at codelibre.net Sat Jun 4 17:03:02 2016 From: rleigh at codelibre.net (Roger Leigh) Date: Sat, 4 Jun 2016 21:03:02 +0000 Subject: [CMake] FindFreetype.cmake doesn't find debug library freetyped.lib In-Reply-To: References: Message-ID: <8e8c9b6e-7a39-d38c-86b0-a637c11b2330@codelibre.net> On 04/06/2016 20:47, Stuart Mentzer wrote: > Hello, > > FindFreetype.cmake is failing to find the debug library on Windows > because it is named freetype*d*.lib and freetyped isn't in the NAMES > list. Is there some variable I can set to get it found or can freetyped > get added to NAMES? See how other modules handle this, e.g. https://github.com/Kitware/CMake/blob/master/Modules/FindZLIB.cmake#L77 Note the separate searches for the release and debug libs on lines 88-89 and select_library_configurations on line 93. If you adapt FindFreetype to use the same pattern, it will handle this properly. Regards, Roger From Stuart_Mentzer at objexx.com Sat Jun 4 19:26:22 2016 From: Stuart_Mentzer at objexx.com (Stuart Mentzer) Date: Sat, 4 Jun 2016 19:26:22 -0400 Subject: [CMake] FindFreetype.cmake doesn't find debug library freetyped.lib In-Reply-To: <8e8c9b6e-7a39-d38c-86b0-a637c11b2330@codelibre.net> References: <8e8c9b6e-7a39-d38c-86b0-a637c11b2330@codelibre.net> Message-ID: On 6/4/2016 5:03 PM, Roger Leigh wrote: > On 04/06/2016 20:47, Stuart Mentzer wrote: >> Hello, >> >> FindFreetype.cmake is failing to find the debug library on Windows >> because it is named freetype*d*.lib and freetyped isn't in the NAMES >> list. Is there some variable I can set to get it found or can freetyped >> get added to NAMES? > > See how other modules handle this, e.g. > > https://github.com/Kitware/CMake/blob/master/Modules/FindZLIB.cmake#L77 > > Note the separate searches for the release and debug libs on lines 88-89 and select_library_configurations on line 93. > > If you adapt FindFreetype to use the same pattern, it will handle this properly. > > > Regards, > Roger > Thanks Roger. That looks the right way to do it. Seems odd that it is handled for zlib but not for freetype. Is this something we can just ask the developers to fix or would it be best for me to submit the fix to the developers list? Thanks, Stuart From eike at sf-mail.de Sun Jun 5 04:26:27 2016 From: eike at sf-mail.de (Rolf Eike Beer) Date: Sun, 05 Jun 2016 10:26:27 +0200 Subject: [CMake] FindFreetype.cmake doesn't find debug library freetyped.lib In-Reply-To: References: <8e8c9b6e-7a39-d38c-86b0-a637c11b2330@codelibre.net> Message-ID: <2342858.9Kn4Abo5rH@caliban.sf-tec.de> Am Samstag, 4. Juni 2016, 19:26:22 schrieb Stuart Mentzer: > On 6/4/2016 5:03 PM, Roger Leigh wrote: > > On 04/06/2016 20:47, Stuart Mentzer wrote: > >> Hello, > >> > >> FindFreetype.cmake is failing to find the debug library on Windows > >> because it is named freetype*d*.lib and freetyped isn't in the NAMES > >> list. Is there some variable I can set to get it found or can freetyped > >> get added to NAMES? > > > > See how other modules handle this, e.g. > > > > https://github.com/Kitware/CMake/blob/master/Modules/FindZLIB.cmake#L77 > > > > Note the separate searches for the release and debug libs on lines 88-89 > > and select_library_configurations on line 93. > > > > If you adapt FindFreetype to use the same pattern, it will handle this > > properly. > Thanks Roger. That looks the right way to do it. Seems odd that it is > handled for zlib but not for freetype. Is this something we can just ask > the developers to fix or would it be best for me to submit the fix to the > developers list? It's a reasonable addition, so if you can't come up with a patch yourself I'll have a look if I can do one next week which you can test. Greetings, Eike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From Stuart_Mentzer at objexx.com Sun Jun 5 05:14:25 2016 From: Stuart_Mentzer at objexx.com (Stuart Mentzer) Date: Sun, 5 Jun 2016 05:14:25 -0400 Subject: [CMake] FindFreetype.cmake doesn't find debug library freetyped.lib In-Reply-To: <2342858.9Kn4Abo5rH@caliban.sf-tec.de> References: <8e8c9b6e-7a39-d38c-86b0-a637c11b2330@codelibre.net> <2342858.9Kn4Abo5rH@caliban.sf-tec.de> Message-ID: <459b840a-5926-526e-a34b-93e5f795b415@objexx.com> On 6/5/2016 4:26 AM, Rolf Eike Beer wrote: > Am Samstag, 4. Juni 2016, 19:26:22 schrieb Stuart Mentzer: >> On 6/4/2016 5:03 PM, Roger Leigh wrote: >>> On 04/06/2016 20:47, Stuart Mentzer wrote: >>>> Hello, >>>> >>>> FindFreetype.cmake is failing to find the debug library on Windows >>>> because it is named freetype*d*.lib and freetyped isn't in the NAMES >>>> list. Is there some variable I can set to get it found or can freetyped >>>> get added to NAMES? >>> See how other modules handle this, e.g. >>> >>> https://github.com/Kitware/CMake/blob/master/Modules/FindZLIB.cmake#L77 >>> >>> Note the separate searches for the release and debug libs on lines 88-89 >>> and select_library_configurations on line 93. >>> >>> If you adapt FindFreetype to use the same pattern, it will handle this >>> properly. >> Thanks Roger. That looks the right way to do it. Seems odd that it is >> handled for zlib but not for freetype. Is this something we can just ask >> the developers to fix or would it be best for me to submit the fix to the >> developers list? > It's a reasonable addition, so if you can't come up with a patch yourself I'll > have a look if I can do one next week which you can test. > > Greetings, > > Eike Thanks Eike. The simplest, least invasive patch is just: find_library(FREETYPE_LIBRARY NAMES freetype libfreetype freetype219 to: find_library(FREETYPE_LIBRARY NAMES freetype freetyped libfreetype freetype219 but I understand if you don't want to mix release and debug lib names like that. If so let me know and I'll do it the way it is done for zlib. Problem is that I don't know if freetype219 would also have a d suffix since I'm not sure why that is in there ;-). Stuart From rleigh at codelibre.net Sun Jun 5 05:23:03 2016 From: rleigh at codelibre.net (Roger Leigh) Date: Sun, 5 Jun 2016 09:23:03 +0000 Subject: [CMake] FindFreetype.cmake doesn't find debug library freetyped.lib In-Reply-To: <459b840a-5926-526e-a34b-93e5f795b415@objexx.com> References: <8e8c9b6e-7a39-d38c-86b0-a637c11b2330@codelibre.net> <2342858.9Kn4Abo5rH@caliban.sf-tec.de> <459b840a-5926-526e-a34b-93e5f795b415@objexx.com> Message-ID: <2c217dca-3867-fa4a-4c30-538a08542a70@codelibre.net> On 05/06/2016 09:14, Stuart Mentzer wrote: > On 6/5/2016 4:26 AM, Rolf Eike Beer wrote: >> It's a reasonable addition, so if you can't come up with a patch >> yourself I'll >> have a look if I can do one next week which you can test. >> >> Greetings, >> >> Eike > Thanks Eike. The simplest, least invasive patch is just: > > find_library(FREETYPE_LIBRARY > NAMES > freetype > libfreetype > freetype219 > > to: > > find_library(FREETYPE_LIBRARY > NAMES > freetype > freetyped > libfreetype > freetype219 > > but I understand if you don't want to mix release and debug lib names > like that. If so let me know and I'll do it the way it is done for zlib. > Problem is that I don't know if freetype219 would also have a d suffix > since I'm not sure why that is in there ;-). This won't behave correctly though--you might end up selecting the debug variant for release builds under some circumstances (and vice versa) and end up with a broken build. It really needs to be separate. You can simply add the "d" suffix to all the variants in the current list to the debug list for good measure. Regards, Roger From Stuart_Mentzer at objexx.com Sun Jun 5 08:35:34 2016 From: Stuart_Mentzer at objexx.com (Stuart Mentzer) Date: Sun, 5 Jun 2016 08:35:34 -0400 Subject: [CMake] FindFreetype.cmake doesn't find debug library freetyped.lib In-Reply-To: <2c217dca-3867-fa4a-4c30-538a08542a70@codelibre.net> References: <8e8c9b6e-7a39-d38c-86b0-a637c11b2330@codelibre.net> <2342858.9Kn4Abo5rH@caliban.sf-tec.de> <459b840a-5926-526e-a34b-93e5f795b415@objexx.com> <2c217dca-3867-fa4a-4c30-538a08542a70@codelibre.net> Message-ID: On 6/5/2016 5:23 AM, Roger Leigh wrote: > On 05/06/2016 09:14, Stuart Mentzer wrote: >> On 6/5/2016 4:26 AM, Rolf Eike Beer wrote: >>> It's a reasonable addition, so if you can't come up with a patch >>> yourself I'll >>> have a look if I can do one next week which you can test. >>> >>> Greetings, >>> >>> Eike >> Thanks Eike. The simplest, least invasive patch is just: >> >> find_library(FREETYPE_LIBRARY >> NAMES >> freetype >> libfreetype >> freetype219 >> >> to: >> >> find_library(FREETYPE_LIBRARY >> NAMES >> freetype >> freetyped >> libfreetype >> freetype219 >> >> but I understand if you don't want to mix release and debug lib names >> like that. If so let me know and I'll do it the way it is done for zlib. >> Problem is that I don't know if freetype219 would also have a d suffix >> since I'm not sure why that is in there ;-). > > This won't behave correctly though--you might end up selecting the debug variant for release builds under some circumstances (and vice versa) and end up with a broken build. It really needs to be separate. You can simply add the "d" suffix to all the variants in the current list to the debug list for good measure. > > Regards, > Roger OK. I assumed that doing debug and release builds in the same tree isn't normal or supported, esp. since on Linux they give the same library names so collision and all that. But I'll do it the proper way and post it here. Stuart From kristianonline28 at gmail.com Sun Jun 5 13:49:02 2016 From: kristianonline28 at gmail.com (Kristian) Date: Sun, 5 Jun 2016 13:49:02 -0400 Subject: [CMake] Problem building CMake with system OPENSSL In-Reply-To: <82B0E332-2EEF-4F1D-A3FF-389BBFE42211@mail.nih.gov> References: <82B0E332-2EEF-4F1D-A3FF-389BBFE42211@mail.nih.gov> Message-ID: Maybe you should add something like > include_directories(${OPENSSL_INCLUDE_DIR}) to your CMakeLists.txt ? 2016-06-03 10:27 GMT-04:00 Lowekamp, Bradley (NIH/NLM/LHC) [C] : > Hello, > > I am trying to build CMake on an old system with a new version of openssl. > My build script was working with CMake 3.4 but is not working with 3.5.2 or > current master. Here is how I am building cmake: > > > cd /tmp/cmake-build && > ../${CMAKE_ROOT}/bootstrap && > make -j ${NPROC} && > ./bin/cmake -DCMAKE_BUILD_TYPE:STRING=Release > -DCMAKE_USE_OPENSSL:BOOL=ON -DOPENSSL_ROOT_DIR:PATH=/usr/local/ssl > -DCMAKE_USE_SYSTEM_CURL:BOOL=OFF . && > make -j${NPROC} > > ERROR MESSAGE: > 41%] Building C object > Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_cryptor.c.o > cd /tmp/cmake-build/Utilities/cmlibarchive/libarchive && > /opt/rh/devtoolset-2/root/usr/bin/gcc -DCURL_STATICLIB -DHAVE_CONFIG_H > -DLIBARCHIVE_STATIC -DLZMA_API_STATIC > -I/tmp/cmake/Utilities/cmlibarchive/libarchive > -I/tmp/cmake-build/Utilities/cmlibarchive -I/tmp/cmake-build/Utilities > -I/tmp/cmake/Utilities -I/tmp/cmake/Utilities/cmbzip2 > -I/tmp/cmake/Utilities/cmliblzma/liblzma/api -w -O3 -DNDEBUG -std=gnu99 > -o CMakeFiles/cmlibarchive.dir/archive_cryptor.c.o -c > /tmp/cmake/Utilities/cmlibarchive/libarchive/archive_cryptor.c > In file included from > /tmp/cmake/Utilities/cmlibarchive/libarchive/archive_cryptor.c:32:0: > /tmp/cmake/Utilities/cmlibarchive/libarchive/archive_cryptor_private.h:102:25: > fatal error: openssl/evp.h: No such file or directory > #include > > My work around it just to add "-I/usr/local/ssl/include/? to the > CMAKE_C_FLAGS. > > > Thanks! > Brad > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From bill at classdesign.com Sun Jun 5 13:52:12 2016 From: bill at classdesign.com (Bill Somerville) Date: Sun, 5 Jun 2016 18:52:12 +0100 Subject: [CMake] Mac OS X framework building In-Reply-To: <5984716a-b967-c075-26cc-af179cda9267@classdesign.com> References: <5984716a-b967-c075-26cc-af179cda9267@classdesign.com> Message-ID: On 24/05/2016 21:55, Bill Somerville wrote: > I am trying to make a framework using a shared library. The docs say > that the target property PUBLIC_HEADER should be a list of interface > header files that install(TARGET ...) will populate > .../.framework/Headers/ with but I cannot get that to happen. > I have set the target property FRAMEWORK to TRUE and the target is a > SHARED library. The framework gets created with the Versions and > Resources directories etc. and the .plist file and the dylib is added > with all the relevant symlinks. No headers are being added and the > Headers directory is not being created. > > Can anyone help with what I am missing or provide a link to a project > that creates a Mac OS X framework successfully using install(TARGETS > ...)? Hi again, so no replies here or off list. It would seem that no-one is using CMake to build a framework library that has header files. Just checking one more time before abandoning using a framework library on OS X. Regards Bill. From ewmailing at gmail.com Sun Jun 5 16:03:21 2016 From: ewmailing at gmail.com (Eric Wing) Date: Sun, 5 Jun 2016 13:03:21 -0700 Subject: [CMake] Mac OS X framework building In-Reply-To: References: <5984716a-b967-c075-26cc-af179cda9267@classdesign.com> Message-ID: On 6/5/16, Bill Somerville wrote: > On 24/05/2016 21:55, Bill Somerville wrote: >> I am trying to make a framework using a shared library. The docs say >> that the target property PUBLIC_HEADER should be a list of interface >> header files that install(TARGET ...) will populate >> .../.framework/Headers/ with but I cannot get that to happen. >> I have set the target property FRAMEWORK to TRUE and the target is a >> SHARED library. The framework gets created with the Versions and >> Resources directories etc. and the .plist file and the dylib is added >> with all the relevant symlinks. No headers are being added and the >> Headers directory is not being created. >> >> Can anyone help with what I am missing or provide a link to a project >> that creates a Mac OS X framework successfully using install(TARGETS >> ...)? > I use Frameworks all the time. But you need to use PUBLIC_HEADER in SET_TARGET_PROPERTIES. It is part of the actual build, not part of INSTALL. Try referring to ALmixer as one example. https://bitbucket.org/ewing/almixer -Eric From B00083603 at student.itb.ie Sun Jun 5 13:01:16 2016 From: B00083603 at student.itb.ie (B00083603 Michael O Brien) Date: Sun, 5 Jun 2016 17:01:16 +0000 Subject: [CMake] Make install permissions advice for ubuntu 14.04 with cmake 2.8 Message-ID: I'm trying to install OpenCV2 and the process requires the use of cmake which I'm not familiar with so I was hoping I could ask the cmake mailing list for some advice. I have a virtual machine where I have sudo permissions and I download the OpenCV2 zip file from, create a directory for the build and run the following commands in my Bash terminal cd build cmake -D CUDA_ARCH_BIN=3.2 -D CUDA_ARCH_PTX=3.2 -D CMAKE_BUILD_TYPE=RELEASE -D CMAKE_INSTALL_PREFIX=/usr/local -D WITH_TBB=ON -D BUILD_NEW_PYTHON_SUPPORT=ON -D WITH_V4L=ON -D BUILD_TIFF=ON -D WITH_QT=ON -D WITH_OPENGL=ON .. make -j$(nproc) sudo make install When I run sudo make install I get the error /bin/sh: 1: cd: can't cd to /home/michael.obrien/setups/OpenCV/opencv-2.4.13/build make[2]: *** [3rdparty/libtiff/CMakeFiles/libtiff.dir/depend] Error 2 make[1]: *** [3rdparty/libtiff/CMakeFiles/libtiff.dir/all] Error 2 make: *** [all] Error 2 If I run the command make install the build will complete but I get an error "CMake Error at cmake_install.cmake:36 (FILE): file cannot create directory /usr/local/include/opencv2. Maybe need administrative privileges So I'm confused as to how I can resolve this if sudo can't cd to the folder but I need su(do) to create the directories Any pointers on how to solve this would be very welcome. Michael ITB Email Disclaimer This is a confidential communication and is intended only for the addressee indicated in the message (or duly authorised to be responsible for the delivery of the message to such person). You are specifically prohibited from copying this message or delivering the same, or any part thereof, to any other person, whomsoever or howsoever, unless you receive written authorisation from us to do. If you are anyone other than the intended addressee, or person duly authorised and responsible for the delivery of this message to the intended addressee, you should destroy this message and notify us immediately. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rleigh at codelibre.net Sun Jun 5 16:48:31 2016 From: rleigh at codelibre.net (Roger Leigh) Date: Sun, 5 Jun 2016 20:48:31 +0000 Subject: [CMake] Make install permissions advice for ubuntu 14.04 with cmake 2.8 In-Reply-To: References: Message-ID: <0e165a02-d81d-e7db-4405-ed52e10a6818@codelibre.net> On 05/06/2016 17:01, B00083603 Michael O Brien wrote: > sudo make install > > When I run sudo make install I get the error > /bin/sh: 1: cd: can't cd to > /home/michael.obrien/setups/OpenCV/opencv-2.4.13/build > make[2]: *** [3rdparty/libtiff/CMakeFiles/libtiff.dir/depend] Error 2 > make[1]: *** [3rdparty/libtiff/CMakeFiles/libtiff.dir/all] Error 2 > make: *** [all] Error 2 > > If I run the command make install the build will complete but I get an > error "CMake Error at cmake_install.cmake:36 (FILE): file cannot create > directory /usr/local/include/opencv2. Maybe need administrative privileges > > So I'm confused as to how I can resolve this if sudo can't cd to the > folder but I need su(do) to create the directories > > Any pointers on how to solve this would be very welcome. Can you do this: sudo -s cd /home/michael.obrien/setups/OpenCV/opencv-2.4.13/build That will check that root has permission to cd there. One thought for why this might fail: is your homedir on NFS with root_squash enabled? That might prevent root access. What are the permissions on this directory, and its parents? Regards, Roger From Stuart_Mentzer at objexx.com Sun Jun 5 19:51:06 2016 From: Stuart_Mentzer at objexx.com (Stuart Mentzer) Date: Sun, 5 Jun 2016 19:51:06 -0400 Subject: [CMake] FindFreetype.cmake doesn't find debug library freetyped.lib In-Reply-To: <2342858.9Kn4Abo5rH@caliban.sf-tec.de> References: <8e8c9b6e-7a39-d38c-86b0-a637c11b2330@codelibre.net> <2342858.9Kn4Abo5rH@caliban.sf-tec.de> Message-ID: On 6/5/2016 4:26 AM, Rolf Eike Beer wrote: > Am Samstag, 4. Juni 2016, 19:26:22 schrieb Stuart Mentzer: >> On 6/4/2016 5:03 PM, Roger Leigh wrote: >>> On 04/06/2016 20:47, Stuart Mentzer wrote: >>>> Hello, >>>> >>>> FindFreetype.cmake is failing to find the debug library on Windows >>>> because it is named freetype*d*.lib and freetyped isn't in the NAMES >>>> list. Is there some variable I can set to get it found or can freetyped >>>> get added to NAMES? >>> See how other modules handle this, e.g. >>> >>> https://github.com/Kitware/CMake/blob/master/Modules/FindZLIB.cmake#L77 >>> >>> Note the separate searches for the release and debug libs on lines 88-89 >>> and select_library_configurations on line 93. >>> >>> If you adapt FindFreetype to use the same pattern, it will handle this >>> properly. >> Thanks Roger. That looks the right way to do it. Seems odd that it is >> handled for zlib but not for freetype. Is this something we can just ask >> the developers to fix or would it be best for me to submit the fix to the >> developers list? > It's a reasonable addition, so if you can't come up with a patch yourself I'll > have a look if I can do one next week which you can test. > > Greetings, > > Eike Eike, Here is my patched FindFreetype.cmake that should find the freetyped debug library on Windows. I hope that helps. If you know what version of CMake will get this update that would be great to know. Thanks, Stuart -------------- next part -------------- #.rst: # FindFreetype # ------------ # # Locate FreeType library # # This module defines # # :: # # FREETYPE_LIBRARIES, the library to link against # FREETYPE_FOUND, if false, do not try to link to FREETYPE # FREETYPE_INCLUDE_DIRS, where to find headers. # FREETYPE_VERSION_STRING, the version of freetype found (since CMake 2.8.8) # This is the concatenation of the paths: # FREETYPE_INCLUDE_DIR_ft2build # FREETYPE_INCLUDE_DIR_freetype2 # # # # $FREETYPE_DIR is an environment variable that would correspond to the # ./configure --prefix=$FREETYPE_DIR used in building FREETYPE. #============================================================================= # Copyright 2007-2009 Kitware, Inc. # # Distributed under the OSI-approved BSD License (the "License"); # see accompanying file Copyright.txt for details. # # This software is distributed WITHOUT ANY WARRANTY; without even the # implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. # See the License for more information. #============================================================================= # (To distribute this file outside of CMake, substitute the full # License text for the above reference.) # Created by Eric Wing. # Modifications by Alexander Neundorf. # This file has been renamed to "FindFreetype.cmake" instead of the correct # "FindFreeType.cmake" in order to be compatible with the one from KDE4, Alex. # Ugh, FreeType seems to use some #include trickery which # makes this harder than it should be. It looks like they # put ft2build.h in a common/easier-to-find location which # then contains a #include to a more specific header in a # more specific location (#include ). # Then from there, they need to set a bunch of #define's # so you can do something like: # #include FT_FREETYPE_H # Unfortunately, using CMake's mechanisms like include_directories() # wants explicit full paths and this trickery doesn't work too well. # I'm going to attempt to cut out the middleman and hope # everything still works. find_path( FREETYPE_INCLUDE_DIR_ft2build ft2build.h HINTS ENV FREETYPE_DIR PATHS /usr/X11R6 /usr/local/X11R6 /usr/local/X11 /usr/freeware ENV GTKMM_BASEPATH [HKEY_CURRENT_USER\\SOFTWARE\\gtkmm\\2.4;Path] [HKEY_LOCAL_MACHINE\\SOFTWARE\\gtkmm\\2.4;Path] PATH_SUFFIXES include/freetype2 include freetype2 ) find_path( FREETYPE_INCLUDE_DIR_freetype2 NAMES freetype/config/ftheader.h config/ftheader.h HINTS ENV FREETYPE_DIR PATHS /usr/X11R6 /usr/local/X11R6 /usr/local/X11 /usr/freeware ENV GTKMM_BASEPATH [HKEY_CURRENT_USER\\SOFTWARE\\gtkmm\\2.4;Path] [HKEY_LOCAL_MACHINE\\SOFTWARE\\gtkmm\\2.4;Path] PATH_SUFFIXES include/freetype2 include freetype2 ) set(FREETYPE_NAMES_RELEASE freetype libfreetype freetype219) set(FREETYPE_NAMES_DEBUG freetyped libfreetyped freetype219d) find_library(FREETYPE_LIBRARY_RELEASE NAMES ${FREETYPE_NAMES_RELEASE} HINTS ENV FREETYPE_DIR PATHS /usr/X11R6 /usr/local/X11R6 /usr/local/X11 /usr/freeware ENV GTKMM_BASEPATH [HKEY_CURRENT_USER\\SOFTWARE\\gtkmm\\2.4;Path] [HKEY_LOCAL_MACHINE\\SOFTWARE\\gtkmm\\2.4;Path] PATH_SUFFIXES lib ) find_library(FREETYPE_LIBRARY_DEBUG NAMES ${FREETYPE_NAMES_DEBUG} HINTS ENV FREETYPE_DIR PATHS /usr/X11R6 /usr/local/X11R6 /usr/local/X11 /usr/freeware ENV GTKMM_BASEPATH [HKEY_CURRENT_USER\\SOFTWARE\\gtkmm\\2.4;Path] [HKEY_LOCAL_MACHINE\\SOFTWARE\\gtkmm\\2.4;Path] PATH_SUFFIXES lib ) # set the user variables if(FREETYPE_INCLUDE_DIR_ft2build AND FREETYPE_INCLUDE_DIR_freetype2) set(FREETYPE_INCLUDE_DIRS "${FREETYPE_INCLUDE_DIR_ft2build};${FREETYPE_INCLUDE_DIR_freetype2}") list(REMOVE_DUPLICATES FREETYPE_INCLUDE_DIRS) endif() set(FREETYPE_LIBRARIES "${FREETYPE_LIBRARY}") if(EXISTS "${FREETYPE_INCLUDE_DIR_freetype2}/freetype/freetype.h") set(FREETYPE_H "${FREETYPE_INCLUDE_DIR_freetype2}/freetype/freetype.h") elseif(EXISTS "${FREETYPE_INCLUDE_DIR_freetype2}/freetype.h") set(FREETYPE_H "${FREETYPE_INCLUDE_DIR_freetype2}/freetype.h") endif() if(FREETYPE_INCLUDE_DIR_freetype2 AND FREETYPE_H) file(STRINGS "${FREETYPE_H}" freetype_version_str REGEX "^#[\t ]*define[\t ]+FREETYPE_(MAJOR|MINOR|PATCH)[\t ]+[0-9]+$") unset(FREETYPE_VERSION_STRING) foreach(VPART MAJOR MINOR PATCH) foreach(VLINE ${freetype_version_str}) if(VLINE MATCHES "^#[\t ]*define[\t ]+FREETYPE_${VPART}[\t ]+([0-9]+)$") set(FREETYPE_VERSION_PART "${CMAKE_MATCH_1}") if(FREETYPE_VERSION_STRING) set(FREETYPE_VERSION_STRING "${FREETYPE_VERSION_STRING}.${FREETYPE_VERSION_PART}") else() set(FREETYPE_VERSION_STRING "${FREETYPE_VERSION_PART}") endif() unset(FREETYPE_VERSION_PART) endif() endforeach() endforeach() endif() # handle the QUIETLY and REQUIRED arguments and set FREETYPE_FOUND to TRUE if # all listed variables are TRUE include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake) find_package_handle_standard_args( Freetype REQUIRED_VARS FREETYPE_LIBRARY FREETYPE_INCLUDE_DIRS VERSION_VAR FREETYPE_VERSION_STRING ) mark_as_advanced( FREETYPE_LIBRARY FREETYPE_INCLUDE_DIR_freetype2 FREETYPE_INCLUDE_DIR_ft2build ) From zcsd2012 at gmail.com Mon Jun 6 03:37:42 2016 From: zcsd2012 at gmail.com (Chaos Zhang) Date: Mon, 6 Jun 2016 00:37:42 -0700 (MST) Subject: [CMake] How to set gcc option "-Wl,-rpath-link," in CMake?make Message-ID: <1465198662592-7593638.post@n2.nabble.com> Hi, all, i am trying to converting an existed make project into CMake project, and there are some gcc link options i should convert. Not long ago, Mr. Atkins told me 'RPATHs are automatically added by CMake to executables so they can use libraries from the build tree.'. Now i don't know weather "-Wl,-rpath-link," automatically added by CMake after search for some time. Could you please give me some advice? Best Regards, Chao -- View this message in context: http://cmake.3232098.n2.nabble.com/How-to-set-gcc-option-Wl-rpath-link-in-CMake-make-tp7593638.html Sent from the CMake mailing list archive at Nabble.com. From patrick.boettcher at posteo.de Mon Jun 6 05:36:28 2016 From: patrick.boettcher at posteo.de (Patrick Boettcher) Date: Mon, 6 Jun 2016 11:36:28 +0200 Subject: [CMake] C header file cross dependency In-Reply-To: <56E920142ED81D4FBE3260E4B9D1DB3E97208FAB@ROTSRV13.Neuberger.local> References: <56E920142ED81D4FBE3260E4B9D1DB3E97208951@ROTSRV13.Neuberger.local> <20160525113902.0eb6f70d@posteo.de> <56E920142ED81D4FBE3260E4B9D1DB3E97208FAB@ROTSRV13.Neuberger.local> Message-ID: <20160606113628.6a729d17@posteo.de> Hi Martin, On Wed, 1 Jun 2016 14:58:53 +0000 Wagner Martin wrote: > > > > Could you provide a working, stripped down example to show the > > problem provided via github (in an example repo). > > > > I've added a simple test project to > > https://github.com/martinwag/test_cmake/tree/master > > Note that this example does not need cross gcc for ARM. It doesn't > implement any useful functionality! I forked your repo and played a little bit around. https://github.com/pboettch/test_cmake Here are my conclusions: 1) Due to the use of add_libary(... OBJECTS ...) you cannot link libraries with libraries or interfaces, this is a pity - especially for a complex project with a lot of sub-dirs. There is a possibility to merge STATIC-libraries to generated one big archive using external tools (libtool). If I were you I'd try to this way to profit from the target_*-cmake-features. 2) I created a log-dir with an interface-library - which only carries the log.h and thus the printf-prototypes 3) Both, drivers and terminal link with this interface-library (to get their hands on log.h) 4) In addition I added two libraries to drivers/ uart-logging1 and uart-logging2. This shows how you could compile-configure your printf-function depending on the hardware used. In the main CMakeLists you just need to select one of them - depending on the option's value. Basically I followed the idea of instantiating a print-function 'somewhere' in the project (it could also be done outside) and then select the one you want to use at the final link. Of course this way you could add other ways of printf'ing - logging1 and logging2 are just stupid examples. HTH and sorry for the delay, -- Patrick. From eike at sf-mail.de Mon Jun 6 06:02:21 2016 From: eike at sf-mail.de (Rolf Eike Beer) Date: Mon, 06 Jun 2016 12:02:21 +0200 Subject: [CMake] FindFreetype.cmake doesn't find debug library freetyped.lib In-Reply-To: <393be97e-ff39-bbdb-9dd1-cdde6651fa1b@objexx.com> References: <8e8c9b6e-7a39-d38c-86b0-a637c11b2330@codelibre.net> <2342858.9Kn4Abo5rH@caliban.sf-tec.de> <393be97e-ff39-bbdb-9dd1-cdde6651fa1b@objexx.com> Message-ID: <38c0686fa71e63fee6d877c1b8173d22@sf-mail.de> Stuart Mentzer wrote: > On 6/6/2016 4:21 AM, Rolf Eike Beer wrote: >> You wrote: >>> On 6/5/2016 4:26 AM, Rolf Eike Beer wrote: >>>> Am Samstag, 4. Juni 2016, 19:26:22 schrieb Stuart Mentzer: >>>>> On 6/4/2016 5:03 PM, Roger Leigh wrote: >>>>>> On 04/06/2016 20:47, Stuart Mentzer wrote: >>>>>>> Hello, >>>>>>> >>>>>>> FindFreetype.cmake is failing to find the debug library on >>>>>>> Windows >>>>>>> because it is named freetype*d*.lib and freetyped isn't in the >>>>>>> NAMES >>>>>>> list. Is there some variable I can set to get it found or can >>>>>>> freetyped >>>>>>> get added to NAMES? >>>>>> See how other modules handle this, e.g. >>>>>> >>>>>> https://github.com/Kitware/CMake/blob/master/Modules/FindZLIB.cmake#L77 >>>>>> >>>>>> Note the separate searches for the release and debug libs on lines >>>>>> 88-89 >>>>>> and select_library_configurations on line 93. >>>>>> >>>>>> If you adapt FindFreetype to use the same pattern, it will handle >>>>>> this >>>>>> properly. >>>>> Thanks Roger. That looks the right way to do it. Seems odd that it >>>>> is >>>>> handled for zlib but not for freetype. Is this something we can >>>>> just ask >>>>> the developers to fix or would it be best for me to submit the fix >>>>> to the >>>>> developers list? >>>> It's a reasonable addition, so if you can't come up with a patch >>>> yourself I'll >>>> have a look if I can do one next week which you can test. >> >>> A better(?) version of this is attached. Sorry -- just learning my >>> way >>> around CMake. >> >> This looks quite good, but here are some remarks: > Thanks. Comments below... >> -I guess it was accidentially that you removed the list from CC? > No, I wasn't sure it was cool to send attachments to the general cmake > list. If I should I'm happy to forward these messages to it with > attachments. Yes, please do so. Also please send patch files as it's easier to review what you actually changed. >> -drop the FREETYPE_NAMES_* variables, just put the names in the >> find_library calls > Done. >> -please keep the old name for the release variable for backward >> compatibility. That means that you have to set/unset >> FREETYPE_LIBRARY_RELEASE around the call to >> SelectLibraryConfigurations > Not completely sure about this. I unset them after the > select_library_configurations call but my (shallow) understanding is > that the call sets FREETYPE_LIBRARY from them so I'm not sure what the > backward compatibility issue is. One can call "cmake -D FREETYPE_LIBRARY=..." from the command line and expect that this will end up in the cache as it did before. Otherwise that information would be lost on subsequent CMake runs in the same build directory. And don't unset() the variables used in find_library(), they should be accessible and will end up in the cache. Just add FREETYPE_LIBRARY_DEBUG to the mark_as_advanced() call at the bottom of the file. >> -if you want to de-messify that thing you could put all the HINTS and >> PATHS stuff into a variable as that is shared between all >> find_path/find_library calls > Done for PATHS. Since HINTS is just one item I didn't think it was > worth it. Maybe if the ENV process costs some time it might be though. You can put everything starting at the HINTS into that variable. It will be expanded before calling find_* so the argument list gets restored there. E.g. this is done in FindOpenSSL.cmake. >> -please add a short note in Help/release/dev/ for the changelog > It might be best for you to polish and submit this when you are happy > with it. I'm really a CMake noob! We're just changing that, no? Look here for an example: https://cmake.org/gitweb?p=cmake.git;a=blob;f=Help/release/dev/FindOpenCL-imported-target.rst;h=259c745b0b39c3e83efa051f3dfbcc05787f9a5a;hb=refs/heads/next Greetings, Eike From Stuart_Mentzer at objexx.com Mon Jun 6 07:18:55 2016 From: Stuart_Mentzer at objexx.com (Stuart Mentzer) Date: Mon, 6 Jun 2016 07:18:55 -0400 Subject: [CMake] FindFreetype.cmake doesn't find debug library freetyped.lib In-Reply-To: <38c0686fa71e63fee6d877c1b8173d22@sf-mail.de> References: <8e8c9b6e-7a39-d38c-86b0-a637c11b2330@codelibre.net> <2342858.9Kn4Abo5rH@caliban.sf-tec.de> <393be97e-ff39-bbdb-9dd1-cdde6651fa1b@objexx.com> <38c0686fa71e63fee6d877c1b8173d22@sf-mail.de> Message-ID: <40aacbd5-4f9b-f64c-55b9-d5763f20eacd@objexx.com> On 6/6/2016 6:02 AM, Rolf Eike Beer wrote: > Stuart Mentzer wrote: >> On 6/6/2016 4:21 AM, Rolf Eike Beer wrote: >>> You wrote: >>>> On 6/5/2016 4:26 AM, Rolf Eike Beer wrote: >>>>> Am Samstag, 4. Juni 2016, 19:26:22 schrieb Stuart Mentzer: >>>>>> On 6/4/2016 5:03 PM, Roger Leigh wrote: >>>>>>> On 04/06/2016 20:47, Stuart Mentzer wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> FindFreetype.cmake is failing to find the debug library on Windows >>>>>>>> because it is named freetype*d*.lib and freetyped isn't in the NAMES >>>>>>>> list. Is there some variable I can set to get it found or can freetyped >>>>>>>> get added to NAMES? >>>>>>> See how other modules handle this, e.g. >>>>>>> >>>>>>> https://github.com/Kitware/CMake/blob/master/Modules/FindZLIB.cmake#L77 >>>>>>> >>>>>>> Note the separate searches for the release and debug libs on lines 88-89 >>>>>>> and select_library_configurations on line 93. >>>>>>> >>>>>>> If you adapt FindFreetype to use the same pattern, it will handle this >>>>>>> properly. >>>>>> Thanks Roger. That looks the right way to do it. Seems odd that it is >>>>>> handled for zlib but not for freetype. Is this something we can just ask >>>>>> the developers to fix or would it be best for me to submit the fix to the >>>>>> developers list? >>>>> It's a reasonable addition, so if you can't come up with a patch yourself I'll >>>>> have a look if I can do one next week which you can test. >>> >>>> A better(?) version of this is attached. Sorry -- just learning my way >>>> around CMake. >>> >>> This looks quite good, but here are some remarks: >> Thanks. Comments below... >>> -I guess it was accidentially that you removed the list from CC? >> No, I wasn't sure it was cool to send attachments to the general cmake >> list. If I should I'm happy to forward these messages to it with >> attachments. > > Yes, please do so. Also please send patch files as it's easier to review what you actually changed. > >>> -drop the FREETYPE_NAMES_* variables, just put the names in the find_library calls >> Done. >>> -please keep the old name for the release variable for backward compatibility. That means that you have to set/unset FREETYPE_LIBRARY_RELEASE around the call to SelectLibraryConfigurations >> Not completely sure about this. I unset them after the >> select_library_configurations call but my (shallow) understanding is >> that the call sets FREETYPE_LIBRARY from them so I'm not sure what the >> backward compatibility issue is. > > One can call "cmake -D FREETYPE_LIBRARY=..." from the command line and expect that this will end up in the cache as it did before. Otherwise that information would be lost on subsequent CMake runs in the same build directory. > > And don't unset() the variables used in find_library(), they should be accessible and will end up in the cache. Just add FREETYPE_LIBRARY_DEBUG to the mark_as_advanced() call at the bottom of the file. Do you mean that I should use FREETYPE_LIBRARY instead of FREETYPE_LIBRARY_RELEASE? > >>> -if you want to de-messify that thing you could put all the HINTS and PATHS stuff into a variable as that is shared between all find_path/find_library calls >> Done for PATHS. Since HINTS is just one item I didn't think it was >> worth it. Maybe if the ENV process costs some time it might be though. > > You can put everything starting at the HINTS into that variable. It will be expanded before calling find_* so the argument list gets restored there. E.g. this is done in FindOpenSSL.cmake. OK, but the PATH_SUFFIXES for the find_path and find_library calls are different so I can't include that in this uber-variable. >>> -please add a short note in Help/release/dev/ for the changelog >> It might be best for you to polish and submit this when you are happy >> with it. I'm really a CMake noob! > > We're just changing that, no? > > Look here for an example: > > https://cmake.org/gitweb?p=cmake.git;a=blob;f=Help/release/dev/FindOpenCL-imported-target.rst;h=259c745b0b39c3e83efa051f3dfbcc05787f9a5a;hb=refs/heads/next OK, I can probably figure out how to submit a patch and dev note to the developers mailing list once we resolve these last few (?) issues. > > Greetings, > > Eike Thanks for all the help. Stuart From eike at sf-mail.de Mon Jun 6 08:22:49 2016 From: eike at sf-mail.de (Rolf Eike Beer) Date: Mon, 06 Jun 2016 14:22:49 +0200 Subject: [CMake] FindFreetype.cmake doesn't find debug library freetyped.lib In-Reply-To: <40aacbd5-4f9b-f64c-55b9-d5763f20eacd@objexx.com> References: <8e8c9b6e-7a39-d38c-86b0-a637c11b2330@codelibre.net> <2342858.9Kn4Abo5rH@caliban.sf-tec.de> <393be97e-ff39-bbdb-9dd1-cdde6651fa1b@objexx.com> <38c0686fa71e63fee6d877c1b8173d22@sf-mail.de> <40aacbd5-4f9b-f64c-55b9-d5763f20eacd@objexx.com> Message-ID: <8daa2c67e9d68800767ab67ba3493d82@sf-mail.de> >>>> -drop the FREETYPE_NAMES_* variables, just put the names in the >>>> find_library calls >>> Done. >>>> -please keep the old name for the release variable for backward >>>> compatibility. That means that you have to set/unset >>>> FREETYPE_LIBRARY_RELEASE around the call to >>>> SelectLibraryConfigurations >>> Not completely sure about this. I unset them after the >>> select_library_configurations call but my (shallow) understanding is >>> that the call sets FREETYPE_LIBRARY from them so I'm not sure what >>> the >>> backward compatibility issue is. >> >> One can call "cmake -D FREETYPE_LIBRARY=..." from the command line and >> expect that this will end up in the cache as it did before. Otherwise >> that information would be lost on subsequent CMake runs in the same >> build directory. >> >> And don't unset() the variables used in find_library(), they should be >> accessible and will end up in the cache. Just add >> FREETYPE_LIBRARY_DEBUG to the mark_as_advanced() call at the bottom of >> the file. > Do you mean that I should use FREETYPE_LIBRARY instead of > FREETYPE_LIBRARY_RELEASE? Yes. >>>> -if you want to de-messify that thing you could put all the HINTS >>>> and PATHS stuff into a variable as that is shared between all >>>> find_path/find_library calls >>> Done for PATHS. Since HINTS is just one item I didn't think it was >>> worth it. Maybe if the ENV process costs some time it might be >>> though. >> >> You can put everything starting at the HINTS into that variable. It >> will be expanded before calling find_* so the argument list gets >> restored there. E.g. this is done in FindOpenSSL.cmake. > OK, but the PATH_SUFFIXES for the find_path and find_library calls are > different so I can't include that in this uber-variable. Yes. >>>> -please add a short note in Help/release/dev/ for the changelog >>> It might be best for you to polish and submit this when you are happy >>> with it. I'm really a CMake noob! >> >> We're just changing that, no? >> >> Look here for an example: >> >> https://cmake.org/gitweb?p=cmake.git;a=blob;f=Help/release/dev/FindOpenCL-imported-target.rst;h=259c745b0b39c3e83efa051f3dfbcc05787f9a5a;hb=refs/heads/next > OK, I can probably figure out how to submit a patch and dev note to > the developers mailing list once we resolve these last few (?) issues. Sure. The quick&dirty thing is: git clone git at cmake.org:cmake.git cd cmake git config user.email "Stuart_Mentzer at objexx.com" git config user.name "Stuart Mentzer" # hack on your stuff git add Modules/FindFreetype.cmake Help/release/dev/freetype-debug-libs.rst git commit git format-patch -1 HTH Eike From Stuart_Mentzer at objexx.com Mon Jun 6 08:34:34 2016 From: Stuart_Mentzer at objexx.com (Stuart Mentzer) Date: Mon, 6 Jun 2016 08:34:34 -0400 Subject: [CMake] FindFreetype.cmake doesn't find debug library freetyped.lib In-Reply-To: <8daa2c67e9d68800767ab67ba3493d82@sf-mail.de> References: <8e8c9b6e-7a39-d38c-86b0-a637c11b2330@codelibre.net> <2342858.9Kn4Abo5rH@caliban.sf-tec.de> <393be97e-ff39-bbdb-9dd1-cdde6651fa1b@objexx.com> <38c0686fa71e63fee6d877c1b8173d22@sf-mail.de> <40aacbd5-4f9b-f64c-55b9-d5763f20eacd@objexx.com> <8daa2c67e9d68800767ab67ba3493d82@sf-mail.de> Message-ID: <1d8b7073-0e69-d2e3-1a77-b67c619a0e0c@objexx.com> On 6/6/2016 8:22 AM, Rolf Eike Beer wrote: >>>>> -drop the FREETYPE_NAMES_* variables, just put the names in the find_library calls >>>> Done. >>>>> -please keep the old name for the release variable for backward compatibility. That means that you have to set/unset FREETYPE_LIBRARY_RELEASE around the call to SelectLibraryConfigurations >>>> Not completely sure about this. I unset them after the >>>> select_library_configurations call but my (shallow) understanding is >>>> that the call sets FREETYPE_LIBRARY from them so I'm not sure what the >>>> backward compatibility issue is. >>> >>> One can call "cmake -D FREETYPE_LIBRARY=..." from the command line and expect that this will end up in the cache as it did before. Otherwise that information would be lost on subsequent CMake runs in the same build directory. >>> >>> And don't unset() the variables used in find_library(), they should be accessible and will end up in the cache. Just add FREETYPE_LIBRARY_DEBUG to the mark_as_advanced() call at the bottom of the file. >> Do you mean that I should use FREETYPE_LIBRARY instead of >> FREETYPE_LIBRARY_RELEASE? > > Yes. > >>>>> -if you want to de-messify that thing you could put all the HINTS and PATHS stuff into a variable as that is shared between all find_path/find_library calls >>>> Done for PATHS. Since HINTS is just one item I didn't think it was >>>> worth it. Maybe if the ENV process costs some time it might be though. >>> >>> You can put everything starting at the HINTS into that variable. It will be expanded before calling find_* so the argument list gets restored there. E.g. this is done in FindOpenSSL.cmake. >> OK, but the PATH_SUFFIXES for the find_path and find_library calls are >> different so I can't include that in this uber-variable. > > Yes. > >>>>> -please add a short note in Help/release/dev/ for the changelog >>>> It might be best for you to polish and submit this when you are happy >>>> with it. I'm really a CMake noob! >>> >>> We're just changing that, no? >>> >>> Look here for an example: >>> >>> https://cmake.org/gitweb?p=cmake.git;a=blob;f=Help/release/dev/FindOpenCL-imported-target.rst;h=259c745b0b39c3e83efa051f3dfbcc05787f9a5a;hb=refs/heads/next >> OK, I can probably figure out how to submit a patch and dev note to >> the developers mailing list once we resolve these last few (?) issues. > > Sure. The quick&dirty thing is: > > git clone git at cmake.org:cmake.git > cd cmake > git config user.email "Stuart_Mentzer at objexx.com" > git config user.name "Stuart Mentzer" > # hack on your stuff > git add Modules/FindFreetype.cmake Help/release/dev/freetype-debug-libs.rst > git commit > git format-patch -1 > > HTH > > Eike OK, does this look "done"? Stuart -------------- next part -------------- #.rst: # FindFreetype # ------------ # # Locate FreeType library # # This module defines # # :: # # FREETYPE_LIBRARIES, the library to link against # FREETYPE_FOUND, if false, do not try to link to FREETYPE # FREETYPE_INCLUDE_DIRS, where to find headers. # FREETYPE_VERSION_STRING, the version of freetype found (since CMake 2.8.8) # This is the concatenation of the paths: # FREETYPE_INCLUDE_DIR_ft2build # FREETYPE_INCLUDE_DIR_freetype2 # # # # $FREETYPE_DIR is an environment variable that would correspond to the # ./configure --prefix=$FREETYPE_DIR used in building FREETYPE. #============================================================================= # Copyright 2007-2009 Kitware, Inc. # # Distributed under the OSI-approved BSD License (the "License"); # see accompanying file Copyright.txt for details. # # This software is distributed WITHOUT ANY WARRANTY; without even the # implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. # See the License for more information. #============================================================================= # (To distribute this file outside of CMake, substitute the full # License text for the above reference.) # Created by Eric Wing. # Modifications by Alexander Neundorf. # This file has been renamed to "FindFreetype.cmake" instead of the correct # "FindFreeType.cmake" in order to be compatible with the one from KDE4, Alex. # Ugh, FreeType seems to use some #include trickery which # makes this harder than it should be. It looks like they # put ft2build.h in a common/easier-to-find location which # then contains a #include to a more specific header in a # more specific location (#include ). # Then from there, they need to set a bunch of #define's # so you can do something like: # #include FT_FREETYPE_H # Unfortunately, using CMake's mechanisms like include_directories() # wants explicit full paths and this trickery doesn't work too well. # I'm going to attempt to cut out the middleman and hope # everything still works. set(FREETYPE_FIND_ARGS HINTS ENV FREETYPE_DIR PATHS /usr/X11R6 /usr/local/X11R6 /usr/local/X11 /usr/freeware ENV GTKMM_BASEPATH [HKEY_CURRENT_USER\\SOFTWARE\\gtkmm\\2.4;Path] [HKEY_LOCAL_MACHINE\\SOFTWARE\\gtkmm\\2.4;Path] ) find_path( FREETYPE_INCLUDE_DIR_ft2build ft2build.h ${FREETYPE_FIND_ARGS} PATH_SUFFIXES include/freetype2 include freetype2 ) find_path( FREETYPE_INCLUDE_DIR_freetype2 NAMES freetype/config/ftheader.h config/ftheader.h ${FREETYPE_FIND_ARGS} PATH_SUFFIXES include/freetype2 include freetype2 ) find_library(FREETYPE_LIBRARY NAMES freetype libfreetype freetype219 ${FREETYPE_FIND_ARGS} PATH_SUFFIXES lib ) find_library(FREETYPE_LIBRARY_DEBUG NAMES freetyped libfreetyped freetype219d ${FREETYPE_FIND_ARGS} PATH_SUFFIXES lib ) include(SelectLibraryConfigurations) select_library_configurations(FREETYPE) unset(FREETYPE_FIND_ARGS) # set the user variables if(FREETYPE_INCLUDE_DIR_ft2build AND FREETYPE_INCLUDE_DIR_freetype2) set(FREETYPE_INCLUDE_DIRS "${FREETYPE_INCLUDE_DIR_ft2build};${FREETYPE_INCLUDE_DIR_freetype2}") list(REMOVE_DUPLICATES FREETYPE_INCLUDE_DIRS) endif() set(FREETYPE_LIBRARIES "${FREETYPE_LIBRARY}") if(EXISTS "${FREETYPE_INCLUDE_DIR_freetype2}/freetype/freetype.h") set(FREETYPE_H "${FREETYPE_INCLUDE_DIR_freetype2}/freetype/freetype.h") elseif(EXISTS "${FREETYPE_INCLUDE_DIR_freetype2}/freetype.h") set(FREETYPE_H "${FREETYPE_INCLUDE_DIR_freetype2}/freetype.h") endif() if(FREETYPE_INCLUDE_DIR_freetype2 AND FREETYPE_H) file(STRINGS "${FREETYPE_H}" freetype_version_str REGEX "^#[\t ]*define[\t ]+FREETYPE_(MAJOR|MINOR|PATCH)[\t ]+[0-9]+$") unset(FREETYPE_VERSION_STRING) foreach(VPART MAJOR MINOR PATCH) foreach(VLINE ${freetype_version_str}) if(VLINE MATCHES "^#[\t ]*define[\t ]+FREETYPE_${VPART}[\t ]+([0-9]+)$") set(FREETYPE_VERSION_PART "${CMAKE_MATCH_1}") if(FREETYPE_VERSION_STRING) set(FREETYPE_VERSION_STRING "${FREETYPE_VERSION_STRING}.${FREETYPE_VERSION_PART}") else() set(FREETYPE_VERSION_STRING "${FREETYPE_VERSION_PART}") endif() unset(FREETYPE_VERSION_PART) endif() endforeach() endforeach() endif() # handle the QUIETLY and REQUIRED arguments and set FREETYPE_FOUND to TRUE if # all listed variables are TRUE include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake) find_package_handle_standard_args( Freetype REQUIRED_VARS FREETYPE_LIBRARY FREETYPE_INCLUDE_DIRS VERSION_VAR FREETYPE_VERSION_STRING ) mark_as_advanced( FREETYPE_LIBRARY FREETYPE_LIBRARY_DEBUG FREETYPE_INCLUDE_DIR_freetype2 FREETYPE_INCLUDE_DIR_ft2build ) From blowekamp at mail.nih.gov Mon Jun 6 08:52:23 2016 From: blowekamp at mail.nih.gov (Lowekamp, Bradley (NIH/NLM/LHC) [C]) Date: Mon, 6 Jun 2016 12:52:23 +0000 Subject: [CMake] Problem building CMake with system OPENSSL In-Reply-To: References: <82B0E332-2EEF-4F1D-A3FF-389BBFE42211@mail.nih.gov> Message-ID: Hi, Just to clarify this is a problem building CMake itself not a project with CMake. Brad > On Jun 5, 2016, at 1:49 PM, Kristian wrote: > > Maybe you should add something like > >> include_directories(${OPENSSL_INCLUDE_DIR}) > > to your CMakeLists.txt ? > > 2016-06-03 10:27 GMT-04:00 Lowekamp, Bradley (NIH/NLM/LHC) [C] > : >> Hello, >> >> I am trying to build CMake on an old system with a new version of openssl. >> My build script was working with CMake 3.4 but is not working with 3.5.2 or >> current master. Here is how I am building cmake: >> >> >> cd /tmp/cmake-build && >> ../${CMAKE_ROOT}/bootstrap && >> make -j ${NPROC} && >> ./bin/cmake -DCMAKE_BUILD_TYPE:STRING=Release >> -DCMAKE_USE_OPENSSL:BOOL=ON -DOPENSSL_ROOT_DIR:PATH=/usr/local/ssl >> -DCMAKE_USE_SYSTEM_CURL:BOOL=OFF . && >> make -j${NPROC} >> >> ERROR MESSAGE: >> 41%] Building C object >> Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_cryptor.c.o >> cd /tmp/cmake-build/Utilities/cmlibarchive/libarchive && >> /opt/rh/devtoolset-2/root/usr/bin/gcc -DCURL_STATICLIB -DHAVE_CONFIG_H >> -DLIBARCHIVE_STATIC -DLZMA_API_STATIC >> -I/tmp/cmake/Utilities/cmlibarchive/libarchive >> -I/tmp/cmake-build/Utilities/cmlibarchive -I/tmp/cmake-build/Utilities >> -I/tmp/cmake/Utilities -I/tmp/cmake/Utilities/cmbzip2 >> -I/tmp/cmake/Utilities/cmliblzma/liblzma/api -w -O3 -DNDEBUG -std=gnu99 >> -o CMakeFiles/cmlibarchive.dir/archive_cryptor.c.o -c >> /tmp/cmake/Utilities/cmlibarchive/libarchive/archive_cryptor.c >> In file included from >> /tmp/cmake/Utilities/cmlibarchive/libarchive/archive_cryptor.c:32:0: >> /tmp/cmake/Utilities/cmlibarchive/libarchive/archive_cryptor_private.h:102:25: >> fatal error: openssl/evp.h: No such file or directory >> #include >> >> My work around it just to add "-I/usr/local/ssl/include/? to the >> CMAKE_C_FLAGS. >> >> >> Thanks! >> Brad >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake From rleigh at codelibre.net Mon Jun 6 12:01:34 2016 From: rleigh at codelibre.net (rleigh at codelibre.net) Date: Mon, 06 Jun 2016 17:01:34 +0100 Subject: [CMake] Make install permissions advice for ubuntu 14.04 with cmake 2.8 In-Reply-To: References: , <0e165a02-d81d-e7db-4405-ed52e10a6818@codelibre.net> Message-ID: On 2016-06-06 16:39, B00083603 Michael O Brien wrote: > Hi Roger, > > When I run sudo -s I get bash: /home/myaccount/ : Permission denied > but I get a root prompt on the terminal. I get a permission denied > when I try to cd into anything deeper than /home/myaccount/ > > Yes the /home/ is an NFS mount as its common across all the vm's I'm > assigned to but there isn't an etc/exports file > In /proc/mount the mount details don't mention root_squash just that > its nfs rw relatime vers3 The root squashing is in the exports on the server side. This maps uid 0 to nobody, which is why the access is denied. One solution: make all the files readable by other and the directories are readable and executable by other. However, since this is generally the default it's not clear why this is happening. You didn't show us the permissions as I asked, so it's not possible to do more than speculate. What does this show (with any typos fixed)? ls -ld / /home /home/michael.obrien /home/michael.obrien/setups /home/michael.obrien/setups/OpenCV /home/michael.obrien/setups/OpenCV/opencv-2.4.12 /home/michael.obrien/setups/OpenCV/opencv-2.4.12/build I'll hazard a guess that your homedir is 0700 or 0750; if so it'll need to be 0755 (so that any user can access it, including nobody); likewise for any other directories which you want root to read. Regards, Roger From B00083603 at student.itb.ie Mon Jun 6 11:39:16 2016 From: B00083603 at student.itb.ie (B00083603 Michael O Brien) Date: Mon, 6 Jun 2016 15:39:16 +0000 Subject: [CMake] Make install permissions advice for ubuntu 14.04 with cmake 2.8 In-Reply-To: <0e165a02-d81d-e7db-4405-ed52e10a6818@codelibre.net> References: , <0e165a02-d81d-e7db-4405-ed52e10a6818@codelibre.net> Message-ID: Hi Roger, When I run sudo -s I get bash: /home/myaccount/ : Permission denied but I get a root prompt on the terminal. I get a permission denied when I try to cd into anything deeper than /home/myaccount/ Yes the /home/ is an NFS mount as its common across all the vm's I'm assigned to but there isn't an etc/exports file In /proc/mount the mount details don't mention root_squash just that its nfs rw relatime vers3 Michael ________________________________________ From: CMake on behalf of Roger Leigh Sent: 05 June 2016 21:48 To: cmake at cmake.org Subject: Re: [CMake] Make install permissions advice for ubuntu 14.04 with cmake 2.8 On 05/06/2016 17:01, B00083603 Michael O Brien wrote: > sudo make install > > When I run sudo make install I get the error > /bin/sh: 1: cd: can't cd to > /home/michael.obrien/setups/OpenCV/opencv-2.4.13/build > make[2]: *** [3rdparty/libtiff/CMakeFiles/libtiff.dir/depend] Error 2 > make[1]: *** [3rdparty/libtiff/CMakeFiles/libtiff.dir/all] Error 2 > make: *** [all] Error 2 > > If I run the command make install the build will complete but I get an > error "CMake Error at cmake_install.cmake:36 (FILE): file cannot create > directory /usr/local/include/opencv2. Maybe need administrative privileges > > So I'm confused as to how I can resolve this if sudo can't cd to the > folder but I need su(do) to create the directories > > Any pointers on how to solve this would be very welcome. Can you do this: sudo -s cd /home/michael.obrien/setups/OpenCV/opencv-2.4.13/build That will check that root has permission to cd there. One thought for why this might fail: is your homedir on NFS with root_squash enabled? That might prevent root access. What are the permissions on this directory, and its parents? Regards, Roger -- 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 ITB Email Disclaimer This is a confidential communication and is intended only for the addressee indicated in the message (or duly authorised to be responsible for the delivery of the message to such person). You are specifically prohibited from copying this message or delivering the same, or any part thereof, to any other person, whomsoever or howsoever, unless you receive written authorisation from us to do. If you are anyone other than the intended addressee, or person duly authorised and responsible for the delivery of this message to the intended addressee, you should destroy this message and notify us immediately. From B00083603 at student.itb.ie Mon Jun 6 12:30:55 2016 From: B00083603 at student.itb.ie (B00083603 Michael O Brien) Date: Mon, 6 Jun 2016 16:30:55 +0000 Subject: [CMake] Make install permissions advice for ubuntu 14.04 with cmake 2.8 In-Reply-To: References: , <0e165a02-d81d-e7db-4405-ed52e10a6818@codelibre.net> , Message-ID: drwxr-xr-x 23 root root 4096 Jun 1 17:28 / drwxr-xr-x 208 root root 12288 May 26 19:39 /home drwx------ 25 myaccount Domain Users 3072 Jun 5 14:47 /home/myaccount/ drwxr-xr-x 4 myaccount Domain Users 1024 Jun 6 17:03 /home/myaccount/setups/ drwxr-xr-x 3 michael.obrien Domain Users 1024 Jun 6 17:04 /home/michael.obrien/setups/OpenCV/ drwxr-xr-x 12 michael.obrien Domain Users 1024 Jun 6 17:04 /home/michael.obrien/setups/OpenCV/opencv-2.4.13/ drwxr-xr-x 15 michael.obrien Domain Users 2048 Jun 6 17:28 /home/michael.obrien/setups/OpenCV/opencv-2.4.13/build/ Is there a way to set things up so that I can streamline the install across all the vm's and ensure permissions are set correctly on each vm? ________________________________________ From: rleigh at codelibre.net Sent: 06 June 2016 17:01 To: B00083603 Michael O Brien Cc: cmake at cmake.org Subject: Re: [CMake] Make install permissions advice for ubuntu 14.04 with cmake 2.8 On 2016-06-06 16:39, B00083603 Michael O Brien wrote: > Hi Roger, > > When I run sudo -s I get bash: /home/myaccount/ : Permission denied > but I get a root prompt on the terminal. I get a permission denied > when I try to cd into anything deeper than /home/myaccount/ > > Yes the /home/ is an NFS mount as its common across all the vm's I'm > assigned to but there isn't an etc/exports file > In /proc/mount the mount details don't mention root_squash just that > its nfs rw relatime vers3 The root squashing is in the exports on the server side. This maps uid 0 to nobody, which is why the access is denied. One solution: make all the files readable by other and the directories are readable and executable by other. However, since this is generally the default it's not clear why this is happening. You didn't show us the permissions as I asked, so it's not possible to do more than speculate. What does this show (with any typos fixed)? ls -ld / /home /home/michael.obrien /home/michael.obrien/setups /home/michael.obrien/setups/OpenCV /home/michael.obrien/setups/OpenCV/opencv-2.4.12 /home/michael.obrien/setups/OpenCV/opencv-2.4.12/build I'll hazard a guess that your homedir is 0700 or 0750; if so it'll need to be 0755 (so that any user can access it, including nobody); likewise for any other directories which you want root to read. Regards, Roger ITB Email Disclaimer This is a confidential communication and is intended only for the addressee indicated in the message (or duly authorised to be responsible for the delivery of the message to such person). You are specifically prohibited from copying this message or delivering the same, or any part thereof, to any other person, whomsoever or howsoever, unless you receive written authorisation from us to do. If you are anyone other than the intended addressee, or person duly authorised and responsible for the delivery of this message to the intended addressee, you should destroy this message and notify us immediately. From B00083603 at student.itb.ie Mon Jun 6 13:04:45 2016 From: B00083603 at student.itb.ie (B00083603 Michael O Brien) Date: Mon, 6 Jun 2016 17:04:45 +0000 Subject: [CMake] Make install permissions advice for ubuntu 14.04 with cmake 2.8 In-Reply-To: References: , <0e165a02-d81d-e7db-4405-ed52e10a6818@codelibre.net> , Message-ID: Hi Roger, Apologies I sent the last msg too early drwxr-xr-x 23 root root 4096 Jun 1 17:28 / drwxr-xr-x 208 root root 12288 May 26 19:39 /home drwx------ 25 michael.obrien Domain Users 3072 Jun 5 14:47 /home/michael.obrien/ drwxr-xr-x 4 michael.obrien Domain Users 1024 Jun 6 17:03 /home/michael.obrien/setups/ drwxr-xr-x 3 michael.obrien Domain Users 1024 Jun 6 17:04 /home/michael.obrien/setups/OpenCV/ drwxr-xr-x 12 michael.obrien Domain Users 1024 Jun 6 17:04 /home/michael.obrien/setups/OpenCV/opencv-2.4.13/ drwxr-xr-x 15 michael.obrien Domain Users 2048 Jun 6 17:28 /home/michael.obrien/setups/OpenCV/opencv-2.4.13/build/ Is there a way to set permissions and structures up so that I can streamline the install across all the vm's and ensure permissions are set correctly on each vm? Do I need to have the install script as root owner. I have access to another NFS mount which is shared with each vm as well. Does that complicate matters or provide an opportunity to resolve my issue? ________________________________ From: rleigh at codelibre.net Sent: 06 June 2016 17:01 To: B00083603 Michael O Brien Cc: cmake at cmake.org Subject: Re: [CMake] Make install permissions advice for ubuntu 14.04 with cmake 2.8 On 2016-06-06 16:39, B00083603 Michael O Brien wrote: > Hi Roger, > > When I run sudo -s I get bash: /home/myaccount/ : Permission denied > but I get a root prompt on the terminal. I get a permission denied > when I try to cd into anything deeper than /home/myaccount/ > > Yes the /home/ is an NFS mount as its common across all the vm's I'm > assigned to but there isn't an etc/exports file > In /proc/mount the mount details don't mention root_squash just that > its nfs rw relatime vers3 The root squashing is in the exports on the server side. This maps uid 0 to nobody, which is why the access is denied. One solution: make all the files readable by other and the directories are readable and executable by other. However, since this is generally the default it's not clear why this is happening. You didn't show us the permissions as I asked, so it's not possible to do more than speculate. What does this show (with any typos fixed)? ls -ld / /home /home/michael.obrien /home/michael.obrien/setups /home/michael.obrien/setups/OpenCV /home/michael.obrien/setups/OpenCV/opencv-2.4.12 /home/michael.obrien/setups/OpenCV/opencv-2.4.12/build I'll hazard a guess that your homedir is 0700 or 0750; if so it'll need to be 0755 (so that any user can access it, including nobody); likewise for any other directories which you want root to read. Regards, Roger ITB Email Disclaimer This is a confidential communication and is intended only for the addressee indicated in the message (or duly authorised to be responsible for the delivery of the message to such person). You are specifically prohibited from copying this message or delivering the same, or any part thereof, to any other person, whomsoever or howsoever, unless you receive written authorisation from us to do. If you are anyone other than the intended addressee, or person duly authorised and responsible for the delivery of this message to the intended addressee, you should destroy this message and notify us immediately. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rleigh at codelibre.net Mon Jun 6 14:42:45 2016 From: rleigh at codelibre.net (Roger Leigh) Date: Mon, 6 Jun 2016 18:42:45 +0000 Subject: [CMake] Make install permissions advice for ubuntu 14.04 with cmake 2.8 In-Reply-To: References: <0e165a02-d81d-e7db-4405-ed52e10a6818@codelibre.net> Message-ID: On 06/06/2016 16:30, B00083603 Michael O Brien wrote: > Is there a way to set things up so that I can streamline the install across all the vm's and ensure permissions are set correctly on each vm? > drwx------ 25 myaccount Domain Users 3072 Jun 5 14:47 /home/myaccount/ A simple "chmod 0755 /home/myaccount/" should be sufficient. If it's NFS mounted, all the VMs will have the same permissions here. Regards, Roger From Arjen.Markus at deltares.nl Mon Jun 6 15:23:31 2016 From: Arjen.Markus at deltares.nl (Arjen Markus) Date: Mon, 6 Jun 2016 19:23:31 +0000 Subject: [CMake] Patch for working with the NAG Fortran compiler Message-ID: <8CF085736108634681FD03EC36E6A0724C28BA02@V-EXC-C02.DIRECTORY.INTRA> Hello, I have been using the NAG Fortran compiler under Windows for the PLplot project (http://plplot.sf.net) and I found that I needed a small patch to have shared libraries (DLLs) built with it. I added a file "Windows-NAG-Fortran.cmake" to the Modules/Platform directory (CMake 3.4.3) that I derived from similar files for the NAG compiler for Linux and OSX. It looks like this: set(CMAKE_Fortran_VERBOSE_FLAG "-Wl,-v") # Runs gcc under the hood. set(CMAKE_SHARED_LIBRARY_CREATE_Fortran_FLAGS "-Wl,-shared") set(CMAKE_Fortran_CREATE_SHARED_LIBRARY " -Wl,-o, ") Nothing fanciful, but it definitely helps to get DLLs built with NAG Fortran and the accompanying C compiler. Kind regards, Arjen Markus DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. -------------- next part -------------- An HTML attachment was scrubbed... URL: From B00083603 at student.itb.ie Mon Jun 6 15:44:43 2016 From: B00083603 at student.itb.ie (B00083603 Michael O Brien) Date: Mon, 6 Jun 2016 19:44:43 +0000 Subject: [CMake] Make install permissions advice for ubuntu 14.04 with cmake 2.8 In-Reply-To: References: <0e165a02-d81d-e7db-4405-ed52e10a6818@codelibre.net> , Message-ID: Hi Roger, While that got me further down the line, the script failed with Built target opencv_java /bin/sh: 1: cannot create /home/michael.obrien/setups/OpenCV/opencv-2.4.13/build/modules/java/test/.build/ant-RELEASE.properties: Permission denied make[2]: *** [modules/java/test/CMakeFiles/opencv_test_java_properties] Error 2 make[1]: *** [modules/java/test/CMakeFiles/opencv_test_java_properties.dir/all] Error 2 make: *** [all] Error 2 ________________________________ From: Roger Leigh Sent: 06 June 2016 19:42 To: B00083603 Michael O Brien Cc: cmake at cmake.org Subject: Re: [CMake] Make install permissions advice for ubuntu 14.04 with cmake 2.8 On 06/06/2016 16:30, B00083603 Michael O Brien wrote: > Is there a way to set things up so that I can streamline the install across all the vm's and ensure permissions are set correctly on each vm? > drwx------ 25 myaccount Domain Users 3072 Jun 5 14:47 /home/myaccount/ A simple "chmod 0755 /home/myaccount/" should be sufficient. If it's NFS mounted, all the VMs will have the same permissions here. Regards, Roger ITB Email Disclaimer This is a confidential communication and is intended only for the addressee indicated in the message (or duly authorised to be responsible for the delivery of the message to such person). You are specifically prohibited from copying this message or delivering the same, or any part thereof, to any other person, whomsoever or howsoever, unless you receive written authorisation from us to do. If you are anyone other than the intended addressee, or person duly authorised and responsible for the delivery of this message to the intended addressee, you should destroy this message and notify us immediately. -------------- next part -------------- An HTML attachment was scrubbed... URL: From yaronct at gmail.com Tue Jun 7 03:15:03 2016 From: yaronct at gmail.com (Yaron Cohen-Tal) Date: Tue, 7 Jun 2016 10:15:03 +0300 Subject: [CMake] Build a program and get its output during "cmake" run Message-ID: Hi, I'd like to build a C++ program and get its output during "cmake" run, not during the project build. "CHECK_CXX_SOURCE_RUNS" only gives me the exit code, but I need the output from the program. Anyway to do it? Thanx, Yaron -------------- next part -------------- An HTML attachment was scrubbed... URL: From petr.kmoch at gmail.com Tue Jun 7 03:23:20 2016 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Tue, 7 Jun 2016 09:23:20 +0200 Subject: [CMake] Build a program and get its output during "cmake" run In-Reply-To: References: Message-ID: Hi Yaron, I believe you're looking for CMake's try_run() command: https://cmake.org/cmake/help/latest/command/try_run.html Petr On 7 June 2016 at 09:15, Yaron Cohen-Tal wrote: > Hi, > > I'd like to build a C++ program and get its output during "cmake" run, not > during the project build. "CHECK_CXX_SOURCE_RUNS" only gives me the exit > code, but I need the output from the program. Anyway to do it? > > Thanx, > Yaron > > -- > > 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 yaronct at gmail.com Tue Jun 7 06:14:46 2016 From: yaronct at gmail.com (Yaron Cohen-Tal) Date: Tue, 7 Jun 2016 13:14:46 +0300 Subject: [CMake] Build a program and get its output during "cmake" run In-Reply-To: References: Message-ID: For some reason I was looking for it in the cmake modules, where "CHECK_CXX_SOURCE_RUNS" was.. Thanx! On Tue, Jun 7, 2016 at 10:23 AM, Petr Kmoch wrote: > Hi Yaron, > > I believe you're looking for CMake's try_run() command: > https://cmake.org/cmake/help/latest/command/try_run.html > > Petr > > On 7 June 2016 at 09:15, Yaron Cohen-Tal wrote: > >> Hi, >> >> I'd like to build a C++ program and get its output during "cmake" run, >> not during the project build. "CHECK_CXX_SOURCE_RUNS" only gives me the >> exit code, but I need the output from the program. Anyway to do it? >> >> Thanx, >> Yaron >> >> -- >> >> 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 B00083603 at student.itb.ie Tue Jun 7 08:10:51 2016 From: B00083603 at student.itb.ie (B00083603 Michael O Brien) Date: Tue, 7 Jun 2016 12:10:51 +0000 Subject: [CMake] Build, Make Install for multiple machines - Guidelines for Success Message-ID: Hi all, I have to build OpenCV on multiple machines and I was wondering if the following was possible and advisable or should I use a different method? I'm still learning about the cmake,make, make install way of software installation Environment All the machines (vms) have access to the same shared storage and are all are Ubuntu 14.04 On vm1: run "cmake" on the files stored on the shared storage with the configuration I need then run "make -j$(nproc)" before using "make install" to install OpenCV On vm 2 to vm n: Can I just run make install (assuming all the required software is already installed) or would I be advised to run "cmake" and "make -j" commands again? Also is there any issues (file locks for example) about running the required commands in parallel on multple vms pointing to the same source or would I be advised to run the commands in serial (vm by vm)? Finally can I point "make install" to the directory where cmake created the makefile (apologies if this isn't the correct term, but where cmake did its work) so I can script the" make install" from outside the build directory for a slightly cleaner script Michael ITB Email Disclaimer This is a confidential communication and is intended only for the addressee indicated in the message (or duly authorised to be responsible for the delivery of the message to such person). You are specifically prohibited from copying this message or delivering the same, or any part thereof, to any other person, whomsoever or howsoever, unless you receive written authorisation from us to do. If you are anyone other than the intended addressee, or person duly authorised and responsible for the delivery of this message to the intended addressee, you should destroy this message and notify us immediately. -------------- next part -------------- An HTML attachment was scrubbed... URL: From blowekamp at mail.nih.gov Tue Jun 7 10:58:55 2016 From: blowekamp at mail.nih.gov (Lowekamp, Bradley (NIH/NLM/LHC) [C]) Date: Tue, 7 Jun 2016 14:58:55 +0000 Subject: [CMake] Problem building CMake with system OPENSSL In-Reply-To: References: <82B0E332-2EEF-4F1D-A3FF-389BBFE42211@mail.nih.gov> Message-ID: <5D71CF88-A178-4F6D-A52B-C6FA86C759C0@mail.nih.gov> Hello, I tried out the 3.6.0-rc1 and my problem building CMake still exists. I created a Dockerfile to reproduce my problem: ===Dockerfile=== ROM debian:8 MAINTAINER Bradley Lowekamp RUN apt-get update && apt-get install -y \ build-essential \ curl \ libncurses-dev \ emacs # Install the latest CMake release WORKDIR /tmp/ ADD https://www.openssl.org/source/openssl-1.0.2h.tar.gz \ https://cmake.org/files/v3.6/cmake-3.6.0-rc1.tar.gz /tmp/ RUN tar zxvf openssl-1.0.2h.tar.gz && \ ( cd openssl-1.0.2h && \ ./config no-ssl2 no-shared -fPIC --prefix=/usr/local/ssl && \ make install ) && \ rm -rf openssl-1.0.2h RUN tar xvzf cmake-3.6.0-rc1.tar.gz && \ mkdir /tmp/cmake-build && \ (cd /tmp/cmake-build && \ ../cmake-3.6.0-rc1/bootstrap && \ make -j 10 && \ ./bin/cmake -DCMAKE_BUILD_TYPE:STRING=Release -DCMAKE_USE_OPENSSL:BOOL=ON -DOPENSSL_ROOT_DIR:PATH=/usr/local/ssl . && \ make -j${NPROC} && \ make install) CMD ["/bin/bash?] Build Error: In file included from /tmp/cmake-3.6.0-rc1/Utilities/cmlibarchive/libarchive/archive_read_support_format_zip.c:58:0: /tmp/cmake-3.6.0-rc1/Utilities/cmlibarchive/libarchive/archive_cryptor_private.h:102:25: fatal error: openssl/evp.h: No such file or directory #include ^ compilation terminated. In file included from /tmp/cmake-3.6.0-rc1/Utilities/cmlibarchive/libarchive/archive_write_set_format_zip.c:52:0: /tmp/cmake-3.6.0-rc1/Utilities/cmlibarchive/libarchive/archive_cryptor_private.h:102:25: fatal error: openssl/evp.h: No such file or directory #include ^ compilation terminated. Thanks for the help! Brad > On Jun 6, 2016, at 8:52 AM, Lowekamp, Bradley (NIH/NLM/LHC) [C] wrote: > > Hi, > > Just to clarify this is a problem building CMake itself not a project with CMake. > > Brad > >> On Jun 5, 2016, at 1:49 PM, Kristian wrote: >> >> Maybe you should add something like >> >>> include_directories(${OPENSSL_INCLUDE_DIR}) >> >> to your CMakeLists.txt ? >> >> 2016-06-03 10:27 GMT-04:00 Lowekamp, Bradley (NIH/NLM/LHC) [C] >> : >>> Hello, >>> >>> I am trying to build CMake on an old system with a new version of openssl. >>> My build script was working with CMake 3.4 but is not working with 3.5.2 or >>> current master. Here is how I am building cmake: >>> >>> >>> cd /tmp/cmake-build && >>> ../${CMAKE_ROOT}/bootstrap && >>> make -j ${NPROC} && >>> ./bin/cmake -DCMAKE_BUILD_TYPE:STRING=Release >>> -DCMAKE_USE_OPENSSL:BOOL=ON -DOPENSSL_ROOT_DIR:PATH=/usr/local/ssl >>> -DCMAKE_USE_SYSTEM_CURL:BOOL=OFF . && >>> make -j${NPROC} >>> >>> ERROR MESSAGE: >>> 41%] Building C object >>> Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_cryptor.c.o >>> cd /tmp/cmake-build/Utilities/cmlibarchive/libarchive && >>> /opt/rh/devtoolset-2/root/usr/bin/gcc -DCURL_STATICLIB -DHAVE_CONFIG_H >>> -DLIBARCHIVE_STATIC -DLZMA_API_STATIC >>> -I/tmp/cmake/Utilities/cmlibarchive/libarchive >>> -I/tmp/cmake-build/Utilities/cmlibarchive -I/tmp/cmake-build/Utilities >>> -I/tmp/cmake/Utilities -I/tmp/cmake/Utilities/cmbzip2 >>> -I/tmp/cmake/Utilities/cmliblzma/liblzma/api -w -O3 -DNDEBUG -std=gnu99 >>> -o CMakeFiles/cmlibarchive.dir/archive_cryptor.c.o -c >>> /tmp/cmake/Utilities/cmlibarchive/libarchive/archive_cryptor.c >>> In file included from >>> /tmp/cmake/Utilities/cmlibarchive/libarchive/archive_cryptor.c:32:0: >>> /tmp/cmake/Utilities/cmlibarchive/libarchive/archive_cryptor_private.h:102:25: >>> fatal error: openssl/evp.h: No such file or directory >>> #include >>> >>> My work around it just to add "-I/usr/local/ssl/include/? to the >>> CMAKE_C_FLAGS. >>> >>> >>> Thanks! >>> Brad >>> >>> -- >>> >>> Powered by www.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: >>> http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For more >>> information on each offering, please visit: >>> >>> CMake Support: http://cmake.org/cmake/help/support.html >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/cmake > > -- > > 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 mark.kelly at lexisnexis.com Tue Jun 7 14:43:53 2016 From: mark.kelly at lexisnexis.com (M Kelly) Date: Tue, 7 Jun 2016 18:43:53 +0000 (UTC) Subject: [CMake] =?utf-8?q?cpack_ppc64le_rhel7=2E2_CPACK=5FRPM=5FPACKAGE?= =?utf-8?q?=5FARCHITECTURE?= Message-ID: Hi, I am working on an IBM Power8 RHEL7.2 system and we installed cmake 3.6 (default cmake from repo was 2.8.12?) but it seems when making a package the arch is set incorrectly to x86_64 instead of ppc64le. Anyone have a clue if this cpack on this dist could get its arch wrong ? cmake 3.5.1 on Ubuntu works perfectly. cmake --system-information does print the correct arch, so this happens only during rpm building. thank you, mark From brad.king at kitware.com Tue Jun 7 15:13:26 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 7 Jun 2016 15:13:26 -0400 Subject: [CMake] Problem building CMake with system OPENSSL In-Reply-To: <5D71CF88-A178-4F6D-A52B-C6FA86C759C0@mail.nih.gov> References: <82B0E332-2EEF-4F1D-A3FF-389BBFE42211@mail.nih.gov> <5D71CF88-A178-4F6D-A52B-C6FA86C759C0@mail.nih.gov> Message-ID: <57571CD6.1090707@kitware.com> On 06/07/2016 10:58 AM, Lowekamp, Bradley (NIH/NLM/LHC) [C] wrote: > I tried out the 3.6.0-rc1 and my problem building CMake still exists. Thanks for testing it. > (cd /tmp/cmake-build && \ > ../cmake-3.6.0-rc1/bootstrap && \ > make -j 10 && \ > ./bin/cmake -DCMAKE_BUILD_TYPE:STRING=Release -DCMAKE_USE_OPENSSL:BOOL=ON -DOPENSSL_ROOT_DIR:PATH=/usr/local/ssl . && \ > make -j${NPROC} && \ > make install) That script causes CMake to be configured with itself the second time instead of the bootstrap script. You should be able to pass the config options directly to bootstrap: ../cmake-3.6.0-rc1/bootstrap --parallel=${NPROC} -- \ -DCMAKE_BUILD_TYPE:STRING=Release \ -DCMAKE_USE_OPENSSL:BOOL=ON \ -DOPENSSL_ROOT_DIR:PATH=/usr/local/ssl && make -j ${NPROC} && make install > In file included from /tmp/cmake-3.6.0-rc1/Utilities/cmlibarchive/libarchive/archive_read_support_format_zip.c:58:0: > /tmp/cmake-3.6.0-rc1/Utilities/cmlibarchive/libarchive/archive_cryptor_private.h:102:25: fatal error: openssl/evp.h: No such file or directory This should fix it: libarchive: Restore OpenSSL include directory from upstream https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=dbc9f73d I've queued this for merge to 'release' for 3.6.0-rc2. -Brad K From kristianonline28 at gmail.com Tue Jun 7 16:00:41 2016 From: kristianonline28 at gmail.com (Kristian) Date: Tue, 7 Jun 2016 16:00:41 -0400 Subject: [CMake] Problem building CMake with system OPENSSL In-Reply-To: <57571CD6.1090707@kitware.com> References: <82B0E332-2EEF-4F1D-A3FF-389BBFE42211@mail.nih.gov> <5D71CF88-A178-4F6D-A52B-C6FA86C759C0@mail.nih.gov> <57571CD6.1090707@kitware.com> Message-ID: What's the meaning of the bootstrap executable? I thought, when compiling CMake, it is sufficient to call ./configure and then make... 2016-06-07 15:13 GMT-04:00 Brad King : > On 06/07/2016 10:58 AM, Lowekamp, Bradley (NIH/NLM/LHC) [C] wrote: > > I tried out the 3.6.0-rc1 and my problem building CMake still exists. > > Thanks for testing it. > > > (cd /tmp/cmake-build && \ > > ../cmake-3.6.0-rc1/bootstrap && \ > > make -j 10 && \ > > ./bin/cmake -DCMAKE_BUILD_TYPE:STRING=Release > -DCMAKE_USE_OPENSSL:BOOL=ON -DOPENSSL_ROOT_DIR:PATH=/usr/local/ssl . && \ > > make -j${NPROC} && \ > > make install) > > That script causes CMake to be configured with itself the second time > instead of the bootstrap script. You should be able to pass the config > options directly to bootstrap: > > ../cmake-3.6.0-rc1/bootstrap --parallel=${NPROC} -- \ > -DCMAKE_BUILD_TYPE:STRING=Release \ > -DCMAKE_USE_OPENSSL:BOOL=ON \ > -DOPENSSL_ROOT_DIR:PATH=/usr/local/ssl && > make -j ${NPROC} && > make install > > > In file included from > /tmp/cmake-3.6.0-rc1/Utilities/cmlibarchive/libarchive/archive_read_support_format_zip.c:58:0: > > > /tmp/cmake-3.6.0-rc1/Utilities/cmlibarchive/libarchive/archive_cryptor_private.h:102:25: > fatal error: openssl/evp.h: No such file or directory > > This should fix it: > > libarchive: Restore OpenSSL include directory from upstream > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=dbc9f73d > > I've queued this for merge to 'release' for 3.6.0-rc2. > > -Brad K > > -- > > 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 brad.king at kitware.com Tue Jun 7 16:03:57 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 7 Jun 2016 16:03:57 -0400 Subject: [CMake] Problem building CMake with system OPENSSL In-Reply-To: References: <82B0E332-2EEF-4F1D-A3FF-389BBFE42211@mail.nih.gov> <5D71CF88-A178-4F6D-A52B-C6FA86C759C0@mail.nih.gov> <57571CD6.1090707@kitware.com> Message-ID: <575728AD.1060703@kitware.com> On 06/07/2016 04:00 PM, Kristian wrote: > What's the meaning of the bootstrap executable? I thought, when > compiling CMake, it is sufficient to call ./configure and then make... The bootstrap script is the way to bootstrap CMake. The `configure` script is just a thin wrapper around `bootstrap` for those that expect `./configure` to work. -Brad From s.baars at rug.nl Tue Jun 7 16:07:13 2016 From: s.baars at rug.nl (Baars, S.) Date: Tue, 7 Jun 2016 22:07:13 +0200 Subject: [CMake] How do you handle recursive dependencies in CMake Message-ID: Hey everyone, I posted a question on StackOverflow a while ago, but got no real answer to my question there. I posted an answer there by myself, but this solution does not work on every system. Since it also involves some possible inconsistencies in the CMake documentation, I decided to ask the question here as well. Say I have packages A, B, and C. Package B uses package A and package C uses package B. I create shared libraries. So in package B I do something like find_package(A) ... if(${A_FOUND}) target_link_libraries(B ${A_LIBRARIES}) endif() and in package C I do find_package(B) ... if(${B_FOUND}) target_link_libraries(C ${B_LIBRARIES}) endif() add_executable(main main.cpp) target_link_libraries(main C) where ${B_LIBRARIES} contains only B. The compiler will now complain /usr/bin/ld: cannot find -lA collect2: error: ld returned 1 exit status as long as A is installed in a place that is not in the default directories. I was wondering what is the correct way of handling this. For me using find_package(A) in C (which would work) doesn't seem to be the nice. For me especially, because I don't know in advance if B depends on A or not. It might also depend on a different package. According to the documentation https://cmake.org/cmake/help/v3.0/command/link_directories.html "Library locations returned by find_package() and find_library() are absolute paths.". This is true for system libraries like /usr/lib/libmpi.so. However, this seems not to be true for most other packages that I use. A reason for this might be that I use the FooBarConfig.cmake file for finding the package (not a FindFooBar.cmake file, since that's not always available). I myself create those following this example: https://cmake.org/Wiki/CMake/Tutorials/How_to_create_a_ProjectConfig.cmake_file Here we have the line set(FOOBAR_LIBRARIES foo) which in the end will not use absolute paths. You can, however, use this file for the find_package function, so according to the documentation it should return absolute paths, which it apparently does not. So this results in the error I described above when I compile C (where it links to -lA instead of /custompath/A.so). So what is the correct way of handling this? Thanks in advance and best regards, Sven -------------- next part -------------- An HTML attachment was scrubbed... URL: From kristianonline28 at gmail.com Tue Jun 7 16:47:42 2016 From: kristianonline28 at gmail.com (Kristian) Date: Tue, 7 Jun 2016 16:47:42 -0400 Subject: [CMake] Freetype on linux systems in non-standard directories Message-ID: Hey guys, I wanted to try something out with CMake and latest version of freetype (2.6.3). So I downloaded freetype, compiled it with the commands > ./configure --prefix=/home/kristian/Documents/freetype/freetype > make > make install After that, I created a small C++-file and a CMakeLists.txt. The C++-file depends on freetype, so my CMakeLists.txt looks like this: ===== > cmake_minimum_required(VERSION 3.5) > project(freetype_ex) > > set(FREETYPE_DIR "/home/kristian/Documents/freetype/freetype") > find_package(Freetype) > > set(SOURCES main.cpp) > > include_directories(${FREETYPE_INCLUDE_DIRS}) > > add_executable(${PROJECT_NAME} ${SOURCES}) > target_link_libraries(${PROJECT_NAME} ${FREETYPE_LIBRARIES}) ===== But when calling cmake, I am getting this error: ===== > -- Could NOT find Freetype (missing: FREETYPE_LIBRARY FREETYPE_INCLUDE_DIRS) > CMake Error: The following variables are used in this project, but they are set to NOTFOUND. > Please set them or make sure they are set and tested correctly in the CMake files: > FREETYPE_LIBRARY (ADVANCED) > linked by target "freetype_ex" in directory /home/kristian/Documents/freetype/cmake > > -- Configuring incomplete, errors occurred! > See also "/home/kristian/Documents/freetype/cmake/CMakeFiles/CMakeOutput.log". ===== This sort of error seems for me to be a bug, because I would assume, that when I set the variable FREETYPE_DIR, then CMake would also look at this dir. I looked at the FindFreetype.cmake file ( https://github.com/Kitware/CMake/blob/master/Modules/FindFreetype.cmake) and my first assumption is, that it would help, to add something like ${FREETYPE_DIR} the the find_path calls. What do you think of this? Another idea is, to add another variable instead of FREETYPE_DIR, e.g. FREETYPE_ROOT_DIR... -------------- next part -------------- An HTML attachment was scrubbed... URL: From eike at sf-mail.de Tue Jun 7 16:52:58 2016 From: eike at sf-mail.de (Rolf Eike Beer) Date: Tue, 07 Jun 2016 22:52:58 +0200 Subject: [CMake] Freetype on linux systems in non-standard directories In-Reply-To: References: Message-ID: <12420493.HCKCMse9Hc@caliban.sf-tec.de> Am Dienstag, 7. Juni 2016, 16:47:42 schrieb Kristian: > Hey guys, > > I wanted to try something out with CMake and latest version of freetype > (2.6.3). So I downloaded freetype, compiled it with the commands > > > ./configure --prefix=/home/kristian/Documents/freetype/freetype > > make > > make install [?] > What do you think of this? Another idea is, to add another variable instead > of FREETYPE_DIR, e.g. FREETYPE_ROOT_DIR... That variable is called CMAKE_PREFIX_PATH and already exists. Eike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From Andreas-Naumann at gmx.net Tue Jun 7 16:58:04 2016 From: Andreas-Naumann at gmx.net (Andreas Naumann) Date: Tue, 7 Jun 2016 22:58:04 +0200 Subject: [CMake] Freetype on linux systems in non-standard directories In-Reply-To: References: Message-ID: <5757355C.4000407@gmx.net> Hey Kristian, as the documentation https://github.com/Kitware/CMake/blob/master/Modules/FindFreetype.cmake at line 21 states, FREETYPE_DIR is an environment variable. So, if you change your line set(FREETYPE_DIR "/home/kristian/Documents/freetype/freetype") to set(ENV{FREETYPE_DIR} "/home/kristian/Documents/freetype/freetype") I would assume, your script will work. Hth, Andreas Am 07.06.2016 um 22:47 schrieb Kristian: > Hey guys, > > I wanted to try something out with CMake and latest version of > freetype (2.6.3). So I downloaded freetype, compiled it with the commands > > > ./configure --prefix=/home/kristian/Documents/freetype/freetype > > make > > make install > > After that, I created a small C++-file and a CMakeLists.txt. The > C++-file depends on freetype, so my CMakeLists.txt looks like this: > > ===== > > > cmake_minimum_required(VERSION 3.5) > > project(freetype_ex) > > > > set(FREETYPE_DIR "/home/kristian/Documents/freetype/freetype") > > find_package(Freetype) > > > > set(SOURCES main.cpp) > > > > include_directories(${FREETYPE_INCLUDE_DIRS}) > > > > add_executable(${PROJECT_NAME} ${SOURCES}) > > target_link_libraries(${PROJECT_NAME} ${FREETYPE_LIBRARIES}) > > ===== > > But when calling cmake, I am getting this error: > ===== > > > -- Could NOT find Freetype (missing: FREETYPE_LIBRARY > FREETYPE_INCLUDE_DIRS) > > CMake Error: The following variables are used in this project, but > they are set to NOTFOUND. > > Please set them or make sure they are set and tested correctly in > the CMake files: > > FREETYPE_LIBRARY (ADVANCED) > > linked by target "freetype_ex" in directory > /home/kristian/Documents/freetype/cmake > > > > -- Configuring incomplete, errors occurred! > > See also > "/home/kristian/Documents/freetype/cmake/CMakeFiles/CMakeOutput.log". > > ===== > > This sort of error seems for me to be a bug, because I would assume, > that when I set the variable FREETYPE_DIR, then CMake would also look > at this dir. > > I looked at the FindFreetype.cmake file > (https://github.com/Kitware/CMake/blob/master/Modules/FindFreetype.cmake) > and my first assumption is, that it would help, to add something like > ${FREETYPE_DIR} the the find_path calls. > > What do you think of this? Another idea is, to add another variable > instead of FREETYPE_DIR, e.g. FREETYPE_ROOT_DIR... > > From rabartl at sandia.gov Tue Jun 7 17:04:17 2016 From: rabartl at sandia.gov (Bartlett, Roscoe A) Date: Tue, 7 Jun 2016 21:04:17 +0000 Subject: [CMake] Get ctest -S script to pull from git branch other than 'master'? Message-ID: <94314853e96c474da6673b0d7d112011@ES01AMSNLNT.srn.sandia.gov> Hello, Is there a built-in way to get a ctest -S script to checkout and pull from a git branch other than 'master'? I can't seem to find a way to so this and there is no mention of branches at all in the official documentation: https://cmake.org/cmake/help/v3.6/command/ctest_update.html?highlight=ctest_update and there is no mention of "branch" at: https://cmake.org/Wiki/CMake/Testing_With_CTest Currently, I see code that people have written which is explicitly checking out and updating the desired branch after ctest_update() is called (e.g. this what TribitsCTestDriverCore.cmake does). Therefore, this CTest code is really just using ctest_update() to do a `git fetch` on the external repo. In this case, if the local branch is changed to a tracking branch, then will ctest_update() leave that tracking branch as is and just pull from the tracking branch the next time the ctest -S script is called? If that is the case, then I would expect CTest to report the correct list of "updated files". But if ctest_update() instead switches back to the 'master' branch and then does the pull, then it will likely report the wrong list of "updated files". I can dig into the source code for CTest to see what it actually does but it would be nice to have direct support for choosing the branch or at the very least just documenting the current behavior and describe the best way to work around the issue. Thanks, -Ross Dr. Roscoe A. Bartlett, PhD Sandia National Laboratories Trilinos Software Engineering and Integration Technologies Lead Consortium for the Advanced Simulation of Light Water Reactors (CASL) Physics Integration Infrastructure Lead -------------- next part -------------- An HTML attachment was scrubbed... URL: From kristianonline28 at gmail.com Tue Jun 7 17:16:35 2016 From: kristianonline28 at gmail.com (Kristian) Date: Tue, 7 Jun 2016 17:16:35 -0400 Subject: [CMake] Freetype on linux systems in non-standard directories In-Reply-To: <5757355C.4000407@gmx.net> References: <5757355C.4000407@gmx.net> Message-ID: Hey Andreas, thanks for your answer. Yes, that also works :) 2016-06-07 16:58 GMT-04:00 Andreas Naumann : > Hey Kristian, > > as the documentation > https://github.com/Kitware/CMake/blob/master/Modules/FindFreetype.cmake > at line 21 states, FREETYPE_DIR is an environment variable. > So, if you change your line > set(FREETYPE_DIR "/home/kristian/Documents/freetype/freetype") > to > set(ENV{FREETYPE_DIR} "/home/kristian/Documents/freetype/freetype") > I would assume, your script will work. > > Hth, > Andreas > > Am 07.06.2016 um 22:47 schrieb Kristian: > >> Hey guys, >> >> I wanted to try something out with CMake and latest version of freetype >> (2.6.3). So I downloaded freetype, compiled it with the commands >> >> > ./configure --prefix=/home/kristian/Documents/freetype/freetype >> > make >> > make install >> >> After that, I created a small C++-file and a CMakeLists.txt. The C++-file >> depends on freetype, so my CMakeLists.txt looks like this: >> >> ===== >> >> > cmake_minimum_required(VERSION 3.5) >> > project(freetype_ex) >> > >> > set(FREETYPE_DIR "/home/kristian/Documents/freetype/freetype") >> > find_package(Freetype) >> > >> > set(SOURCES main.cpp) >> > >> > include_directories(${FREETYPE_INCLUDE_DIRS}) >> > >> > add_executable(${PROJECT_NAME} ${SOURCES}) >> > target_link_libraries(${PROJECT_NAME} ${FREETYPE_LIBRARIES}) >> >> ===== >> >> But when calling cmake, I am getting this error: >> ===== >> >> > -- Could NOT find Freetype (missing: FREETYPE_LIBRARY >> FREETYPE_INCLUDE_DIRS) >> > CMake Error: The following variables are used in this project, but they >> are set to NOTFOUND. >> > Please set them or make sure they are set and tested correctly in the >> CMake files: >> > FREETYPE_LIBRARY (ADVANCED) >> > linked by target "freetype_ex" in directory >> /home/kristian/Documents/freetype/cmake >> > >> > -- Configuring incomplete, errors occurred! >> > See also >> "/home/kristian/Documents/freetype/cmake/CMakeFiles/CMakeOutput.log". >> >> ===== >> >> This sort of error seems for me to be a bug, because I would assume, that >> when I set the variable FREETYPE_DIR, then CMake would also look at this >> dir. >> >> I looked at the FindFreetype.cmake file ( >> https://github.com/Kitware/CMake/blob/master/Modules/FindFreetype.cmake) >> and my first assumption is, that it would help, to add something like >> ${FREETYPE_DIR} the the find_path calls. >> >> What do you think of this? Another idea is, to add another variable >> instead of FREETYPE_DIR, e.g. FREETYPE_ROOT_DIR... >> >> >> > -- > > 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 rleigh at codelibre.net Tue Jun 7 17:27:58 2016 From: rleigh at codelibre.net (Roger Leigh) Date: Tue, 7 Jun 2016 21:27:58 +0000 Subject: [CMake] Build, Make Install for multiple machines - Guidelines for Success In-Reply-To: References: Message-ID: On 07/06/2016 12:10, B00083603 Michael O Brien wrote: > Hi all, > > I have to build OpenCV on multiple machines and I was wondering if the > following was possible and advisable or should I use a different method? > I'm still learning about the cmake,make, make install way of software > installation > > *Environment* > > All the machines (vms) have access to the same shared storage and are > all are Ubuntu 14.04 > > *On vm1:* run "cmake" on the files stored on the shared storage with the > configuration I need then run "make -j$(nproc)" before using "make > install" to install OpenCV > > *On vm 2 to vm n*: Can I just run make install (assuming all the > required software is already installed) or would I be advised to run > "cmake" and "make -j" commands again? > > > Also is there any issues (file locks for example) about running the > required commands in parallel on multple vms pointing to the same source > or would I be advised to run the commands in serial (vm by vm)? > > Finally can I point "make install" to the directory where cmake created > the makefile (apologies if this isn't the correct term, but where cmake > did its work) so I can script the" make install" from outside the build > directory for a slightly cleaner script So, I also use NFS (v4) mounted storage with all the sources on there, be it git repositories, unpacked source archives etc. However, the difference is that I don't *build* on NFS. I do it in /tmp, or some other local scratch space: cd /tmp mkdir build cd build cmake [options] /path/to/sources make [sudo] make install This will have the following benefits: - solves all your root-on-nfs permissions issues - the builds will be vastly faster - there won't be any timestamp clock skew issues to confound make - there won't be any NFSv3 locking issues - you can have a separate build tree per VM, so the source tree stays nice and pristine while you build on as many platforms as you desire; I do this with Linux, BSD and Windows VMs all building the same git repo branches For the install, can't you just (cd "$builddir" && make install) i.e. in a subshell? Or cmake --build "$builddir" --target install to be generator-agnostic? Regards, Roger From domen.vrankar at gmail.com Wed Jun 8 03:45:16 2016 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Wed, 8 Jun 2016 09:45:16 +0200 Subject: [CMake] cpack ppc64le rhel7.2 CPACK_RPM_PACKAGE_ARCHITECTURE In-Reply-To: References: Message-ID: > I am working on an IBM Power8 RHEL7.2 system and we installed cmake 3.6 > (default cmake from repo was 2.8.12?) but it seems when making a package > the arch is set incorrectly to x86_64 instead of ppc64le. I don't have access to a ppc with Linux but it seems that 'uname -m' (default that is used for setting CPACK_RPM_PACKAGE_ARCHITECTURE) outputs invalid value on ppc AIX. What's the output output of 'uname -m' on your system? As a workaround you could manually set CPACK_RPM_PACKAGE_ARCHITECTURE in your CMake list. Regards, Domen From eric.noulard at gmail.com Wed Jun 8 04:10:48 2016 From: eric.noulard at gmail.com (Eric Noulard) Date: Wed, 8 Jun 2016 10:10:48 +0200 Subject: [CMake] cpack ppc64le rhel7.2 CPACK_RPM_PACKAGE_ARCHITECTURE In-Reply-To: References: Message-ID: 2016-06-08 9:45 GMT+02:00 Domen Vrankar : > > I am working on an IBM Power8 RHEL7.2 system and we installed cmake 3.6 > > (default cmake from repo was 2.8.12?) but it seems when making a package > > the arch is set incorrectly to x86_64 instead of ppc64le. > > I don't have access to a ppc with Linux but it seems that 'uname -m' > (default that is used for setting CPACK_RPM_PACKAGE_ARCHITECTURE) > outputs invalid value on ppc AIX. > AFAIU the machine is running RHEL not Aix. That said uname -m should be right !! Mark may be you can check what is the value displayed by: uname -m (the one used by CPack RPM) arch (which is an alternative) The strange thing is that CMAKE_HOST_SYSTEM_PROCESSOR (outputed by cmake --system-information) uses the same "uname -m" see Modules/CMakeDetermineSystem.cmake. So there is something odd to have one right and the other wrong... Eric > > What's the output output of 'uname -m' on your system? > > As a workaround you could manually set CPACK_RPM_PACKAGE_ARCHITECTURE > in your CMake list. > > Regards, > Domen > -- > > 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 domen.vrankar at gmail.com Wed Jun 8 04:26:46 2016 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Wed, 8 Jun 2016 10:26:46 +0200 Subject: [CMake] cpack ppc64le rhel7.2 CPACK_RPM_PACKAGE_ARCHITECTURE In-Reply-To: References: Message-ID: > The strange thing is that CMAKE_HOST_SYSTEM_PROCESSOR (outputed by cmake > --system-information) uses the same "uname -m" > see Modules/CMakeDetermineSystem.cmake. > > So there is something odd to have one right and the other wrong... In that case it's quite possible that CPACK_RPM_PACKAGE_ARCHITECTURE is already set to x86_64 somewhere in cmake list which overrides the default. Regards, Domen From w.bekker at vdgsecurity.com Wed Jun 8 04:35:11 2016 From: w.bekker at vdgsecurity.com (Wim Bekker) Date: Wed, 8 Jun 2016 10:35:11 +0200 Subject: [CMake] AUTORCC recompiles unchanged rcc files every build using ninja Message-ID: Hi, In cmake 3.5.0, 3.5.2 and 3.6.0, my resource file is compiled every time I build, even when they are not changed. | cmake_minimum_required(VERSION 3.2)| |project(auto_moc_uic_rcc)set(CMAKE_INCLUDE_CURRENT_DIR ON)set(CMAKE_AUTOMOC ON)set(CMAKE_AUTOUIC ON)set(CMAKE_AUTORCC ON)find_package (Qt5WidgetsREQUIRED)add_executable(${PROJECT_NAME}main.cpp MainWindowMainWindow.ui rcc.qrc )target_link_libraries(${PROJECT_NAME}Qt5::Widgets)| If instead I use |qt5_add_resources(RCC rcc.qrc) and add ${RCC} to add_executable the resource file is not build everytime. I use ninja as generator. Is this a bug or is my cmakelists.txt file not correct? Thanks, Wim | -------------- next part -------------- An HTML attachment was scrubbed... URL: From blowekamp at mail.nih.gov Wed Jun 8 06:58:20 2016 From: blowekamp at mail.nih.gov (Lowekamp, Bradley (NIH/NLM/LHC) [C]) Date: Wed, 8 Jun 2016 10:58:20 +0000 Subject: [CMake] Problem building CMake with system OPENSSL In-Reply-To: <57571CD6.1090707@kitware.com> References: <82B0E332-2EEF-4F1D-A3FF-389BBFE42211@mail.nih.gov> <5D71CF88-A178-4F6D-A52B-C6FA86C759C0@mail.nih.gov>, <57571CD6.1090707@kitware.com> Message-ID: Thanks you for the fix and tips! Brad ________________________________________ From: Brad King [brad.king at kitware.com] Sent: Tuesday, June 07, 2016 3:13 PM To: Lowekamp, Bradley (NIH/NLM/LHC) [C] Cc: CMake at cmake.org Subject: Re: [CMake] Problem building CMake with system OPENSSL On 06/07/2016 10:58 AM, Lowekamp, Bradley (NIH/NLM/LHC) [C] wrote: > I tried out the 3.6.0-rc1 and my problem building CMake still exists. Thanks for testing it. > (cd /tmp/cmake-build && \ > ../cmake-3.6.0-rc1/bootstrap && \ > make -j 10 && \ > ./bin/cmake -DCMAKE_BUILD_TYPE:STRING=Release -DCMAKE_USE_OPENSSL:BOOL=ON -DOPENSSL_ROOT_DIR:PATH=/usr/local/ssl . && \ > make -j${NPROC} && \ > make install) That script causes CMake to be configured with itself the second time instead of the bootstrap script. You should be able to pass the config options directly to bootstrap: ../cmake-3.6.0-rc1/bootstrap --parallel=${NPROC} -- \ -DCMAKE_BUILD_TYPE:STRING=Release \ -DCMAKE_USE_OPENSSL:BOOL=ON \ -DOPENSSL_ROOT_DIR:PATH=/usr/local/ssl && make -j ${NPROC} && make install > In file included from /tmp/cmake-3.6.0-rc1/Utilities/cmlibarchive/libarchive/archive_read_support_format_zip.c:58:0: > /tmp/cmake-3.6.0-rc1/Utilities/cmlibarchive/libarchive/archive_cryptor_private.h:102:25: fatal error: openssl/evp.h: No such file or directory This should fix it: libarchive: Restore OpenSSL include directory from upstream https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=dbc9f73d I've queued this for merge to 'release' for 3.6.0-rc2. -Brad K From chuck.atkins at kitware.com Wed Jun 8 09:11:23 2016 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Wed, 8 Jun 2016 09:11:23 -0400 Subject: [CMake] How do you handle recursive dependencies in CMake In-Reply-To: References: Message-ID: The FooBarConfig.cmake is something that should be generated by FooBar's build. The reason you don't get absolute paths for the "libraries" from a package config file is that they're not actually libraries but imported targets. The imported target let's you treat "foo" as though it were a library built by your project. It then has the appropriate target properties set on it ti define the full path to it's library, etc. That being said, if you're manually creating the FooBarConfig.cmake that's not really the right approach. If the FooBar buil;d doesn't actually generate it's own FooBarConfig.cmake file then you'll want to create you're own FindFooBar.cmake. A bare bones find module that creates an imported target would look something like this: if(NOT FooBar_FOUND AND NOT TARGET FooBar::FooBar) find_path(FooBar_INCLUDE_DIR FooBar.h) find_library(FooBar_LIBRARY FooBar) include(FindPackageHandleStandardArgs) find_package_handle_standard_args(FooBar FOUND_VAR FooBar_FOUND REQUIRED_VARS FooBar_INCLUDE_DIR FooBar_LIBRARY ) endif() if(FooBar_FOUND AND NOT TARGET FooBar::FooBar) add_library(FooBar::FooBar UNKNOWN IMPORTED) set_target_properties(FooBar::FooBar PROPERTIES IMPORTED_LOCATION ${FooBar_LIBRARY} INTERFACE_INCLUDE_DIRECTORIES ${FooBar_INCLUDE_DIR} ) endif() Then in your project you can use: find_package(FooBar) add_library(MyLib supercoolfiles.cxx) target_libkLibraries(MyLib FooBar::FooBar) Where this starts to get really helpful in your situation is if you have an imported target for A, B, and C, then you can create the appropriate dependencies. Say, for example, you have a FindA.cmake that follows the pattern above and generates an A::A target. Then in your FindB.cmake you can have: if(NOT B_FOUND AND NOT TARGET B::B) find_path(B_INCLUDE_DIR B.h) find_library(B_LIBRARY B) include(FindPackageHandleStandardArgs) find_package_handle_standard_args(B FOUND_VAR B_FOUND REQUIRED_VARS B_INCLUDE_DIR B_LIBRARY ) * find_package(A QUIET) if(A_FOUND) set(B_Extra_Deps A::A) endif()* endif() if(B_FOUND AND NOT TARGET B::B) add_library(B::B UNKNOWN IMPORTED) set_target_properties(B::B PROPERTIES IMPORTED_LOCATION ${B_LIBRARY} INTERFACE_INCLUDE_DIRECTORIES ${B_INCLUDE_DIR} ) * if(B_Extra_Deps) set_target_properties(B::B PROPERTIES INTERFACE_LINK_LIBRARIES ${B_Extra_Deps} ) endif()* endif() and similarly for FindC.cmake. Since A::A, B::B, and C::C are actual proper CMake targets and not just library files then they carry with them associated target dependency information. In CMake vernacular we refer this as "target usage requirements" since the target caries with it all the necessary information for something to actually use it, whether that's just extra link libraries or also extra include directories and compile definitions needed. The Package::Target naming convention is the idea that each package has it's own namespace where you may define multiple targets. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.kelly at lexisnexis.com Wed Jun 8 10:33:51 2016 From: mark.kelly at lexisnexis.com (M Kelly) Date: Wed, 8 Jun 2016 14:33:51 +0000 (UTC) Subject: [CMake] =?utf-8?q?cpack_ppc64le_rhel7=2E2_CPACK=5FRPM=5FPACKAGE?= =?utf-8?q?=5FARCHITECTURE?= References: Message-ID: Domen Vrankar writes: > > > The strange thing is that CMAKE_HOST_SYSTEM_PROCESSOR (outputed by cmake > > --system-information) uses the same "uname -m" > > see Modules/CMakeDetermineSystem.cmake. > > > > So there is something odd to have one right and the other wrong... > > In that case it's quite possible that CPACK_RPM_PACKAGE_ARCHITECTURE > is already set to x86_64 somewhere in cmake list which overrides the > default. > > Regards, > Domen Hi, I do think somewhere we are forcing CPACK_RPM_PACKAGE_ARCHITECTURE to x86_64 I will find that and fix. thanks, mark From chuck.atkins at kitware.com Wed Jun 8 10:42:21 2016 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Wed, 8 Jun 2016 10:42:21 -0400 Subject: [CMake] cpack ppc64le rhel7.2 CPACK_RPM_PACKAGE_ARCHITECTURE In-Reply-To: References: Message-ID: I was able to verify, btw, that Fedora 19 + Power8 outputs ppc64le for uname -m so I assume it works correctly on EL7 as well. Testead via an IBM machine hosted at the OSU Open Source Lab that we can access and use for testing. - Chuck On Wed, Jun 8, 2016 at 10:33 AM, M Kelly wrote: > Domen Vrankar writes: > > > > > > The strange thing is that CMAKE_HOST_SYSTEM_PROCESSOR (outputed by > cmake > > > --system-information) uses the same "uname -m" > > > see Modules/CMakeDetermineSystem.cmake. > > > > > > So there is something odd to have one right and the other wrong... > > > > In that case it's quite possible that CPACK_RPM_PACKAGE_ARCHITECTURE > > is already set to x86_64 somewhere in cmake list which overrides the > > default. > > > > Regards, > > Domen > > Hi, > > I do think somewhere we are forcing CPACK_RPM_PACKAGE_ARCHITECTURE to > x86_64 > I will find that and fix. > > thanks, > mark > > > -- > > 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 ggarra13 at gmail.com Wed Jun 8 11:11:10 2016 From: ggarra13 at gmail.com (=?UTF-8?Q?Gonzalo_Garramu=c3=b1o?=) Date: Wed, 8 Jun 2016 12:11:10 -0300 Subject: [CMake] Off-topic? Winmm linking/running problems Message-ID: <5758358E.2090200@gmail.com> I have a multiplatform viewer and recently I started to experience some very weird behavior. I am using the latest cmake 3.5.3 rc1 and the latest released ninja (1.7), albeit the problem appears with NMake Makefiles too. The viewer links against winmm.dll, the windows multimedia library for audio. I am using ffmpeg to decode the audio with /OPT:NOREF. My problem is that the win64 version of my program, while testing in the sandbox, plays all audio in mono. The win32 version of my program (same code) works fine from the sandbox. Also, when I move the win64 version of the program (doing ninja install, package install or even just a plain cp to a new tree), the same win64 version of my program plays audio (stereo, 5:1) just fine. The linux amd64 version of my program also plays audio just fine without installing. All the code lies in an NTFS partition. I am at a loss as to what might the problem be. I am pretty sure all variables are initialized properly and that there's no memory issue, but you never know. I have no spaces in the paths. It is not a driver issue as some other user reported mono playback too. I was wondering if someone has experienced anything like this and how to debug it. From s.baars at rug.nl Wed Jun 8 11:31:50 2016 From: s.baars at rug.nl (Sven Baars) Date: Wed, 8 Jun 2016 17:31:50 +0200 Subject: [CMake] How do you handle recursive dependencies in CMake In-Reply-To: References: Message-ID: <57583A66.1050709@rug.nl> In my case all projects provide their own FooBarConfig.cmake, but not a FindFooBar.cmake. For this reason I wanted to use those, because I thought it saves me the effort of writing a lot of FindFooBar.cmake files, and it also seemed like the right way to do it, because it provides things like FooBar_LIBRARIES, which is what I need. The reason I said that I create my own FooBarConfig.cmake, is because I want to use CMake properly in my own project, so I also want to provide a FoorBarConfig.cmake file for my users. So even if the projects I use don't do everything properly, I still want to do it properly myself. The problem in this case is that I'm not sure what the proper way is. If the FoorBarConfig.cmake file is not enough to handle the dependencies I encounter, should I provide a FindFooBar.cmake file or something, instead of just the FooBarConfig.cmake? And meanwhile also write a FindFooBar.cmake file for all my dependencies? Another reason why this seems odd to me, is because if N different projects use FooBar, then also possibly N different versions of FindFooBar.cmake are created by all the different projects (I have actually already seen this a lot). That is the case, because the FindFooBar.cmake file is not provided by the FooBar project, unlike the FooBarConfig.cmake. Cheers, Sven On 06/08/2016 03:11 PM, Chuck Atkins wrote: > The FooBarConfig.cmake is something that should be generated by > FooBar's build. The reason you don't get absolute paths for the > "libraries" from a package config file is that they're not actually > libraries but imported targets. The imported target let's you treat > "foo" as though it were a library built by your project. It then has > the appropriate target properties set on it ti define the full path to > it's library, etc. That being said, if you're manually creating the > FooBarConfig.cmake that's not really the right approach. If the > FooBar buil;d doesn't actually generate it's own FooBarConfig.cmake > file then you'll want to create you're own FindFooBar.cmake. A bare > bones find module that creates an imported target would look something > like this: > > if(NOT FooBar_FOUND AND NOT TARGET FooBar::FooBar) > find_path(FooBar_INCLUDE_DIR FooBar.h) > find_library(FooBar_LIBRARY FooBar) > > include(FindPackageHandleStandardArgs) > find_package_handle_standard_args(FooBar > FOUND_VAR FooBar_FOUND > REQUIRED_VARS FooBar_INCLUDE_DIR FooBar_LIBRARY > ) > endif() > > if(FooBar_FOUND AND NOT TARGET FooBar::FooBar) > add_library(FooBar::FooBar UNKNOWN IMPORTED) > set_target_properties(FooBar::FooBar PROPERTIES > IMPORTED_LOCATION ${FooBar_LIBRARY} > INTERFACE_INCLUDE_DIRECTORIES ${FooBar_INCLUDE_DIR} > ) > endif() > > Then in your project you can use: > > find_package(FooBar) > add_library(MyLib supercoolfiles.cxx) > target_libkLibraries(MyLib FooBar::FooBar) > > Where this starts to get really helpful in your situation is if you > have an imported target for A, B, and C, then you can create the > appropriate dependencies. Say, for example, you have a FindA.cmake > that follows the pattern above and generates an A::A target. Then in > your FindB.cmake you can have: > > if(NOT B_FOUND AND NOT TARGET B::B) > find_path(B_INCLUDE_DIR B.h) > find_library(B_LIBRARY B) > > include(FindPackageHandleStandardArgs) > find_package_handle_standard_args(B > FOUND_VAR B_FOUND > REQUIRED_VARS B_INCLUDE_DIR B_LIBRARY > ) > > * find_package(A QUIET) > if(A_FOUND) > set(B_Extra_Deps A::A) > endif()* > endif() > > if(B_FOUND AND NOT TARGET B::B) > add_library(B::B UNKNOWN IMPORTED) > set_target_properties(B::B PROPERTIES > IMPORTED_LOCATION ${B_LIBRARY} > INTERFACE_INCLUDE_DIRECTORIES ${B_INCLUDE_DIR} > ) > * if(B_Extra_Deps) > set_target_properties(B::B PROPERTIES > INTERFACE_LINK_LIBRARIES ${B_Extra_Deps} > ) > endif()* > endif() > > and similarly for FindC.cmake. Since A::A, B::B, and C::C are actual > proper CMake targets and not just library files then they carry with > them associated target dependency information. In CMake vernacular we > refer this as "target usage requirements" since the target caries with > it all the necessary information for something to actually use it, > whether that's just extra link libraries or also extra include > directories and compile definitions needed. The Package::Target > naming convention is the idea that each package has it's own namespace > where you may define multiple targets. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kristianonline28 at gmail.com Wed Jun 8 11:58:10 2016 From: kristianonline28 at gmail.com (Kristian) Date: Wed, 8 Jun 2016 17:58:10 +0200 Subject: [CMake] CPack and executable permissions on linux Message-ID: Hey guys, I am creating a RPM package with CMake. Here is a small example of how it looks: ======== cmake_minimum_required(VERSION 3.5) set(BOOST_LIB "${CMAKE_CURRENT_SOURCE_DIR}/boost") file(GLOB_RECURSE BOOST_LIBRARIES ${BOOST_LIB}/*) install(FILES ${CMAKE_CURRENT_SOURCE_DIR}/usr/bin/executable DESTINATION bin) install(FILES ${BOOST_LIBRARIES} DESTINATION lib) set(CPACK_GENERATOR "RPM") set(CPACK_PACKAGE_VERSION 6.5) set(CPACK_PACKAGE_NAME "executable-proj") # set(CPACK_RPM_PACKAGE_NAME "executable-proj") set(CPACK_RPM_PACKAGE_SUMMARY "Simple executable project") set(CPACK_RPM_PACKAGE_ARCHITECTURE x86_64) set(CPACK_PACKAGE_VENDOR "Some Vendor Limited") set(CPACK_RPM_PACKAGE_MAINTAINER "Some Vendor Limited") set(CPACK_RPM_PACKAGE_AUTOREQ "NO") set(CPACK_PACKAGE_EXECUTABLES "executable") INCLUDE(CPack) ====== Before running this cmake script, I am setting executable permissions on the build machine, where the package is created. Then, I create a docker image, where this RPM is downloaded and installed. But when I want to start the executable within a docker container, then I am getting the message "permission denied". When I look at the permissions of my installed package, then I see, I only have read permissions. So the question is: What can I do for getting executable permissions for this executable? Is this a CMake/CPack problem? -------------- next part -------------- An HTML attachment was scrubbed... URL: From chuck.atkins at kitware.com Wed Jun 8 12:07:22 2016 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Wed, 8 Jun 2016 12:07:22 -0400 Subject: [CMake] How do you handle recursive dependencies in CMake In-Reply-To: <57583A66.1050709@rug.nl> References: <57583A66.1050709@rug.nl> Message-ID: If the projects are each providing their own Config.cmake file then you probably will want to use those instead of Find modules. Instead of using the Foo_Bar_LIBRARIES variable though, try using the actual imported targets from the config files. Those should have the appropriate dependency information. If you're not sure what they are you should be able to dig through the provided Config.cmake and Targets.cmake files for FooBar and see which targets are created bu "add_library(FooBar::Foo ... IMPORTED)". - Chuck On Wed, Jun 8, 2016 at 11:31 AM, Sven Baars wrote: > In my case all projects provide their own FooBarConfig.cmake, but not a > FindFooBar.cmake. For this reason I wanted to use those, because I thought > it saves me the effort of writing a lot of FindFooBar.cmake files, and it > also seemed like the right way to do it, because it provides things like > FooBar_LIBRARIES, which is what I need. The reason I said that I create my > own FooBarConfig.cmake, is because I want to use CMake properly in my own > project, so I also want to provide a FoorBarConfig.cmake file for my users. > So even if the projects I use don't do everything properly, I still want to > do it properly myself. The problem in this case is that I'm not sure what > the proper way is. If the FoorBarConfig.cmake file is not enough to handle > the dependencies I encounter, should I provide a FindFooBar.cmake file or > something, instead of just the FooBarConfig.cmake? And meanwhile also write > a FindFooBar.cmake file for all my dependencies? > > Another reason why this seems odd to me, is because if N different > projects use FooBar, then also possibly N different versions of > FindFooBar.cmake are created by all the different projects (I have actually > already seen this a lot). That is the case, because the FindFooBar.cmake > file is not provided by the FooBar project, unlike the FooBarConfig.cmake. > > Cheers, > Sven > > > On 06/08/2016 03:11 PM, Chuck Atkins wrote: > > The FooBarConfig.cmake is something that should be generated by FooBar's > build. The reason you don't get absolute paths for the "libraries" from a > package config file is that they're not actually libraries but imported > targets. The imported target let's you treat "foo" as though it were a > library built by your project. It then has the appropriate target > properties set on it ti define the full path to it's library, etc. That > being said, if you're manually creating the FooBarConfig.cmake that's not > really the right approach. If the FooBar buil;d doesn't actually generate > it's own FooBarConfig.cmake file then you'll want to create you're own > FindFooBar.cmake. A bare bones find module that creates an imported target > would look something like this: > > if(NOT FooBar_FOUND AND NOT TARGET FooBar::FooBar) > find_path(FooBar_INCLUDE_DIR FooBar.h) > find_library(FooBar_LIBRARY FooBar) > > include(FindPackageHandleStandardArgs) > find_package_handle_standard_args(FooBar > FOUND_VAR FooBar_FOUND > REQUIRED_VARS FooBar_INCLUDE_DIR FooBar_LIBRARY > ) > endif() > > if(FooBar_FOUND AND NOT TARGET FooBar::FooBar) > add_library(FooBar::FooBar UNKNOWN IMPORTED) > set_target_properties(FooBar::FooBar PROPERTIES > IMPORTED_LOCATION ${FooBar_LIBRARY} > INTERFACE_INCLUDE_DIRECTORIES ${FooBar_INCLUDE_DIR} > ) > endif() > > Then in your project you can use: > > find_package(FooBar) > add_library(MyLib supercoolfiles.cxx) > target_libkLibraries(MyLib FooBar::FooBar) > > Where this starts to get really helpful in your situation is if you have > an imported target for A, B, and C, then you can create the appropriate > dependencies. Say, for example, you have a FindA.cmake that follows the > pattern above and generates an A::A target. Then in your FindB.cmake you > can have: > > if(NOT B_FOUND AND NOT TARGET B::B) > find_path(B_INCLUDE_DIR B.h) > find_library(B_LIBRARY B) > > include(FindPackageHandleStandardArgs) > find_package_handle_standard_args(B > FOUND_VAR B_FOUND > REQUIRED_VARS B_INCLUDE_DIR B_LIBRARY > ) > > > > > * find_package(A QUIET) if(A_FOUND) set(B_Extra_Deps A::A) > endif()* > endif() > > if(B_FOUND AND NOT TARGET B::B) > add_library(B::B UNKNOWN IMPORTED) > set_target_properties(B::B PROPERTIES > IMPORTED_LOCATION ${B_LIBRARY} > INTERFACE_INCLUDE_DIRECTORIES ${B_INCLUDE_DIR} > ) > > > > > * if(B_Extra_Deps) set_target_properties(B::B PROPERTIES > INTERFACE_LINK_LIBRARIES ${B_Extra_Deps} ) endif()* > endif() > > and similarly for FindC.cmake. Since A::A, B::B, and C::C are actual > proper CMake targets and not just library files then they carry with them > associated target dependency information. In CMake vernacular we refer > this as "target usage requirements" since the target caries with it all the > necessary information for something to actually use it, whether that's just > extra link libraries or also extra include directories and compile > definitions needed. The Package::Target naming convention is the idea > that each package has it's own namespace where you may define multiple > targets. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xavier.besseron at uni.lu Wed Jun 8 12:45:03 2016 From: xavier.besseron at uni.lu (Xavier Besseron) Date: Wed, 8 Jun 2016 18:45:03 +0200 Subject: [CMake] Get ctest -S script to pull from git branch other than 'master'? In-Reply-To: <94314853e96c474da6673b0d7d112011@ES01AMSNLNT.srn.sandia.gov> References: <94314853e96c474da6673b0d7d112011@ES01AMSNLNT.srn.sandia.gov> Message-ID: Hi Ross, Here is how I do it in my case: ... # Initial checkout if no source directory if(NOT EXISTS "${CTEST_SOURCE_DIRECTORY}") message("Initial checkout...") set(CTEST_CHECKOUT_COMMAND "git clone --branch ${GIT_BRANCH} ${REPOSITORY} ${SOURCE_DIR_NAME}") endif() # Initialize testing message("Initialize ${CTEST_MODEL} testing...") ctest_start(${CTEST_MODEL} TRACK "${CTEST_SUBMISSION_TRACK}") message("Update source...") set(CTEST_GIT_COMMAND "git") ctest_update(RETURN_VALUE NB_CHANGED_FILES) message("Found ${NB_CHANGED_FILES} changed file(s)") ... I hope this helps. Best regards, Xavier On Tue, Jun 7, 2016 at 11:04 PM, Bartlett, Roscoe A wrote: > Hello, > > > > Is there a built-in way to get a ctest -S script to checkout and pull from > a git branch other than ?master?? I can?t seem to find a way to so this > and there is no mention of branches at all in the official documentation: > > > > > https://cmake.org/cmake/help/v3.6/command/ctest_update.html?highlight=ctest_update > > > > and there is no mention of ?branch? at: > > > > https://cmake.org/Wiki/CMake/Testing_With_CTest > > > > Currently, I see code that people have written which is explicitly > checking out and updating the desired branch after ctest_update() is called > (e.g. this what TribitsCTestDriverCore.cmake does). Therefore, this CTest > code is really just using ctest_update() to do a `git fetch` on the > external repo. In this case, if the local branch is changed to a tracking > branch, then will ctest_update() leave that tracking branch as is and just > pull from the tracking branch the next time the ctest ?S script is called? > If that is the case, then I would expect CTest to report the correct list > of ?updated files?. But if ctest_update() instead switches back to the > ?master? branch and then does the pull, then it will likely report the > wrong list of ?updated files?. > > > > I can dig into the source code for CTest to see what it actually does but > it would be nice to have direct support for choosing the branch or at the > very least just documenting the current behavior and describe the best way > to work around the issue. > > > > Thanks, > > > > -Ross > > > > > > Dr. Roscoe A. Bartlett, PhD > > Sandia National Laboratories > > Trilinos Software Engineering and Integration Technologies Lead > > Consortium for the Advanced Simulation of Light Water Reactors (CASL) > Physics Integration Infrastructure Lead > > > > -- > > 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 > -- Dr Xavier BESSERON Research associate FSTC, University of Luxembourg Campus Kirchberg, Office E-007 Phone: +352 46 66 44 5418 http://luxdem.uni.lu/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rabartl at sandia.gov Wed Jun 8 12:59:44 2016 From: rabartl at sandia.gov (Bartlett, Roscoe A) Date: Wed, 8 Jun 2016 16:59:44 +0000 Subject: [CMake] [EXTERNAL] Re: Get ctest -S script to pull from git branch other than 'master'? In-Reply-To: References: <94314853e96c474da6673b0d7d112011@ES01AMSNLNT.srn.sandia.gov> Message-ID: Xavier, Thanks for the info. I got another email from Brad King and he also pointed out the same thing: https://cmake.org/cmake/help/v3.6/command/ctest_start.html#command:ctest_start and then Brad updated the documentation for ctest_update() to state that it will just keep you on whatever tracking branch you are on and do a git pull (after doing a reset --hard to wipe out any local changes). With is info, I can do what I need. Thanks, -Ross Dr. Roscoe A. Bartlett, PhD Sandia National Laboratories Trilinos Software Engineering and Integration Technologies Lead Consortium for the Advanced Simulation of Light Water Reactors (CASL) Physics Integration Infrastructure Lead From: xavier.besseron at gmail.com [mailto:xavier.besseron at gmail.com] On Behalf Of Xavier Besseron Sent: Wednesday, June 08, 2016 10:45 AM To: cmake at cmake.org Cc: Bartlett, Roscoe A Subject: [EXTERNAL] Re: [CMake] Get ctest -S script to pull from git branch other than 'master'? Hi Ross, Here is how I do it in my case: ... # Initial checkout if no source directory if(NOT EXISTS "${CTEST_SOURCE_DIRECTORY}") message("Initial checkout...") set(CTEST_CHECKOUT_COMMAND "git clone --branch ${GIT_BRANCH} ${REPOSITORY} ${SOURCE_DIR_NAME}") endif() # Initialize testing message("Initialize ${CTEST_MODEL} testing...") ctest_start(${CTEST_MODEL} TRACK "${CTEST_SUBMISSION_TRACK}") message("Update source...") set(CTEST_GIT_COMMAND "git") ctest_update(RETURN_VALUE NB_CHANGED_FILES) message("Found ${NB_CHANGED_FILES} changed file(s)") ... I hope this helps. Best regards, Xavier On Tue, Jun 7, 2016 at 11:04 PM, Bartlett, Roscoe A > wrote: Hello, Is there a built-in way to get a ctest -S script to checkout and pull from a git branch other than ?master?? I can?t seem to find a way to so this and there is no mention of branches at all in the official documentation: https://cmake.org/cmake/help/v3.6/command/ctest_update.html?highlight=ctest_update and there is no mention of ?branch? at: https://cmake.org/Wiki/CMake/Testing_With_CTest Currently, I see code that people have written which is explicitly checking out and updating the desired branch after ctest_update() is called (e.g. this what TribitsCTestDriverCore.cmake does). Therefore, this CTest code is really just using ctest_update() to do a `git fetch` on the external repo. In this case, if the local branch is changed to a tracking branch, then will ctest_update() leave that tracking branch as is and just pull from the tracking branch the next time the ctest ?S script is called? If that is the case, then I would expect CTest to report the correct list of ?updated files?. But if ctest_update() instead switches back to the ?master? branch and then does the pull, then it will likely report the wrong list of ?updated files?. I can dig into the source code for CTest to see what it actually does but it would be nice to have direct support for choosing the branch or at the very least just documenting the current behavior and describe the best way to work around the issue. Thanks, -Ross Dr. Roscoe A. Bartlett, PhD Sandia National Laboratories Trilinos Software Engineering and Integration Technologies Lead Consortium for the Advanced Simulation of Light Water Reactors (CASL) Physics Integration Infrastructure Lead -- 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 -- Dr Xavier BESSERON Research associate FSTC, University of Luxembourg Campus Kirchberg, Office E-007 Phone: +352 46 66 44 5418 http://luxdem.uni.lu/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.hoffman at kitware.com Wed Jun 8 13:27:55 2016 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Wed, 8 Jun 2016 13:27:55 -0400 Subject: [CMake] [EXTERNAL] Re: Get ctest -S script to pull from git branch other than 'master'? In-Reply-To: References: <94314853e96c474da6673b0d7d112011@ES01AMSNLNT.srn.sandia.gov> Message-ID: <8f35059b-735f-1875-54d7-729684290bff@kitware.com> On 6/8/2016 12:59 PM, Bartlett, Roscoe A wrote: > Xavier, > > > > Thanks for the info. I got another email from Brad King and he also > pointed out the same thing: > > > > > https://cmake.org/cmake/help/v3.6/command/ctest_start.html#command:ctest_start > > > > and then Brad updated the documentation for ctest_update() to state that > it will just keep you on whatever tracking branch you are on and do a > git pull (after doing a reset --hard to wipe out any local changes). > > > > With is info, I can do what I need. > > > If you have something external like jenkins doing the build, you can also use: https://cmake.org/cmake/help/latest/variable/CTEST_UPDATE_VERSION_ONLY.html?highlight=ctest_update_version_only If set in the ctest script the ctest_update command will just get the hash and do nothing else. -Bill From micha.hergarden at gmail.com Wed Jun 8 13:56:53 2016 From: micha.hergarden at gmail.com (Micha Hergarden) Date: Wed, 8 Jun 2016 19:56:53 +0200 Subject: [CMake] CPack and executable permissions on linux In-Reply-To: References: Message-ID: <44c3ebd4-b6ae-8975-f8ef-102c74564fce@gmail.com> On 08/06/16 17:58, Kristian wrote: > Hey guys, > > I am creating a RPM package with CMake. Here is a small example of how > it looks: > > ======== > > cmake_minimum_required(VERSION 3.5) > > set(BOOST_LIB "${CMAKE_CURRENT_SOURCE_DIR}/boost") > > file(GLOB_RECURSE BOOST_LIBRARIES ${BOOST_LIB}/*) > > install(FILES ${CMAKE_CURRENT_SOURCE_DIR}/usr/bin/executable > DESTINATION bin) > install(FILES ${BOOST_LIBRARIES} DESTINATION lib) > > set(CPACK_GENERATOR "RPM") > set(CPACK_PACKAGE_VERSION 6.5) > set(CPACK_PACKAGE_NAME "executable-proj") > # set(CPACK_RPM_PACKAGE_NAME "executable-proj") > set(CPACK_RPM_PACKAGE_SUMMARY "Simple executable project") > set(CPACK_RPM_PACKAGE_ARCHITECTURE x86_64) > set(CPACK_PACKAGE_VENDOR "Some Vendor Limited") > set(CPACK_RPM_PACKAGE_MAINTAINER "Some Vendor Limited") > set(CPACK_RPM_PACKAGE_AUTOREQ "NO") > set(CPACK_PACKAGE_EXECUTABLES "executable") > > INCLUDE(CPack) > > ====== > > Before running this cmake script, I am setting executable permissions > on the build machine, where the package is created. > > Then, I create a docker image, where this RPM is downloaded and > installed. But when I want to start the executable within a docker > container, then I am getting the message "permission denied". > When I look at the permissions of my installed package, then I see, I > only have read permissions. > > So the question is: What can I do for getting executable permissions > for this executable? Is this a CMake/CPack problem? > > Hi Kristian, Did you take a look at the manual page for the install command: cmake --help-command install? I think your issue may be resolved by using the 'install(TARGETS ...' instead of 'install(FILES ...)'. Best 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: 473 bytes Desc: OpenPGP digital signature URL: From domen.vrankar at gmail.com Wed Jun 8 14:01:44 2016 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Wed, 8 Jun 2016 20:01:44 +0200 Subject: [CMake] Fwd: CPack and executable permissions on linux In-Reply-To: References: Message-ID: > Before running this cmake script, I am setting executable permissions on the > build machine, where the package is created. With install(FILES ...) command permissions set to source file will be ignored by default (this is missing from documentation). You could set permissions with PERMISSIONS attribute. See: https://cmake.org/cmake/help/v3.5/command/install.html#installing-files > Then, I create a docker image, where this RPM is downloaded and installed. > But when I want to start the executable within a docker container, then I am > getting the message "permission denied". > When I look at the permissions of my installed package, then I see, I only > have read permissions. Since CPack relies on install commands to set permissions this is expected behaviour. > So the question is: What can I do for getting executable permissions for > this executable? Is this a CMake/CPack problem? For now either set PERMISSIONS or move executable into separate directory and use install(DIRECTORY ... USE_SOURCE_PERMISSIONS) This could probably be supported by adding USE_SOURCE_PERMISSIONS for install(FILES ...) would you be willing to contribute a patch? Regards, Domen From mdrahos at aurisrobotics.com Wed Jun 8 13:34:40 2016 From: mdrahos at aurisrobotics.com (Miroslav Drahos) Date: Wed, 8 Jun 2016 17:34:40 +0000 Subject: [CMake] detect Nightly test run Message-ID: Hi folks, I am wondering if it is possible to detect in CMakeLists.txt whether a Nightly target is being configured? What I am trying to do, is to set extra parameters (--gtest_repeat=200) on some tests; but because this slows things down, I'd like to have this only in the Nightly run. Any and all suggestions are greatly appreciated! Cheers, Miro -------------- next part -------------- An HTML attachment was scrubbed... URL: From domen.vrankar at gmail.com Wed Jun 8 14:09:18 2016 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Wed, 8 Jun 2016 20:09:18 +0200 Subject: [CMake] CPack and executable permissions on linux In-Reply-To: References: Message-ID: > This could probably be supported by adding USE_SOURCE_PERMISSIONS for > install(FILES ...) would you be willing to contribute a patch? Misses that this is not cmake-dev mailing list... Patch would still be appreciated but you could also file a feature request (for extending the documentation regarding default permissions and adding USE_SOURCE_PERMISSIONS) here: https://cmake.org/Bug/view_all_bug_page.php Currently registration is disabled so if you don't have an account I could do it for you. Regards, Domen From ggarra13 at gmail.com Wed Jun 8 18:02:57 2016 From: ggarra13 at gmail.com (=?UTF-8?Q?Gonzalo_Garramu=c3=b1o?=) Date: Wed, 8 Jun 2016 19:02:57 -0300 Subject: [CMake] CMake v3.6.0 rc1 Message-ID: <57589611.2020001@gmail.com> I tried v3.6.0 rc1 but it fails on linking with a message about unknown symbols when doing cmake -E vs_link_dll on a windows library. It seems not to recognize the symbols in, for example, tinyxml2. The same code works just fine under cmake v3.5.2. From ggarra13 at gmail.com Wed Jun 8 19:37:47 2016 From: ggarra13 at gmail.com (=?UTF-8?Q?Gonzalo_Garramu=c3=b1o?=) Date: Wed, 8 Jun 2016 20:37:47 -0300 Subject: [CMake] Off-topic? Winmm linking/running problems In-Reply-To: <5758358E.2090200@gmail.com> References: <5758358E.2090200@gmail.com> Message-ID: <5758AC4B.9090802@gmail.com> On 08/06/2016 12:11 p.m., Gonzalo Garramu?o wrote: > I have a multiplatform viewer and recently I started to experience > some very weird behavior. Found the problem being the volume control not being 32bits. Sorry for the noise. From davidshen84 at gmail.com Wed Jun 8 22:30:57 2016 From: davidshen84 at gmail.com (Xi Shen) Date: Thu, 09 Jun 2016 02:30:57 +0000 Subject: [CMake] How about Windows SDK support in cmake? Message-ID: Hi, Since cmake can generate MSBuild build file, why could cmake support building with Windows SDK? I searched the internet, and only found a few posts talking about this, and there's a repo on Github which named FindWindowsSDK. Do we have any inside news from the core developers? Thanks, David -- Thanks, David S. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kristianonline28 at gmail.com Thu Jun 9 04:35:20 2016 From: kristianonline28 at gmail.com (Kristian) Date: Thu, 9 Jun 2016 10:35:20 +0200 Subject: [CMake] CPack and executable permissions on linux In-Reply-To: References: Message-ID: Thanks for all answers. I had to read the documentation before asking :-D I changed the line for the executable from > install(FILES ... into > install(PROGRAMS ... That worked and as far as i can see is sufficient for my requirements. 2016-06-08 20:09 GMT+02:00 Domen Vrankar : > > This could probably be supported by adding USE_SOURCE_PERMISSIONS for > > install(FILES ...) would you be willing to contribute a patch? > > Misses that this is not cmake-dev mailing list... Patch would still be > appreciated but you could also file a feature request (for extending > the documentation regarding default permissions and adding > USE_SOURCE_PERMISSIONS) here: > https://cmake.org/Bug/view_all_bug_page.php > Currently registration is disabled so if you don't have an account I > could do it for you. > > Regards, > Domen > -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.turner at kdab.com Thu Jun 9 04:39:35 2016 From: james.turner at kdab.com (James Turner) Date: Thu, 9 Jun 2016 09:39:35 +0100 Subject: [CMake] Build-system dependency (as opposed to target) Message-ID: <9455D676-B5CD-4D7D-A876-66F8F1E12569@kdab.com> Hi, Is there a way to make the entire build-system depend on a file? I have some data I?m reading into my CMakeList.txt via file(READ), and I want changes to that file to effectively act as if the CMakeList.txt itself was modified. The read values are used to populate some variables via string parsing, which is then used in generated headers and a few other places: > # read 'version' file into a variable (stripping any newlines or spaces) > file(READ version versionFile) > string(STRIP ${versionFile} FOO_VERSION) The file is part of the source distribution alongside the build-system, it?s not user-supplied or anything complex like that. Right now changes to the file contents don?t trigger the downstream variables being updated. Kind regards, James -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3868 bytes Desc: not available URL: From petr.kmoch at gmail.com Thu Jun 9 04:51:21 2016 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Thu, 9 Jun 2016 10:51:21 +0200 Subject: [CMake] Build-system dependency (as opposed to target) In-Reply-To: <9455D676-B5CD-4D7D-A876-66F8F1E12569@kdab.com> References: <9455D676-B5CD-4D7D-A876-66F8F1E12569@kdab.com> Message-ID: Hi James, I believe you're looking for the directory property CMAKE_CONFIGURE_DEPENDS ( https://cmake.org/cmake/help/latest/prop_dir/CMAKE_CONFIGURE_DEPENDS.html ). Adding a file path to that property causes any changes to that file to trigger a regeneration: set_property(DIRECTORY APPEND PROPERTY CMAKE_CONFIGURE_DEPENDS version) If you are using CMake old enough not to have this property, an alternative workaround is to run configure_file() on the file (even if you never use the configured result). This will introduce the exact same dependency. Petr ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.turner at kdab.com Thu Jun 9 05:06:16 2016 From: james.turner at kdab.com (James Turner) Date: Thu, 9 Jun 2016 10:06:16 +0100 Subject: [CMake] Build-system dependency (as opposed to target) In-Reply-To: References: <9455D676-B5CD-4D7D-A876-66F8F1E12569@kdab.com> Message-ID: <69BBF03F-F283-4669-9B7B-458B54D39C0B@kdab.com> > On 9 Jun 2016, at 09:51, Petr Kmoch wrote: > > I believe you're looking for the directory property CMAKE_CONFIGURE_DEPENDS ( https://cmake.org/cmake/help/latest/prop_dir/CMAKE_CONFIGURE_DEPENDS.html ). Adding a file path to that property causes any changes to that file to trigger a regeneration: > > set_property(DIRECTORY APPEND PROPERTY CMAKE_CONFIGURE_DEPENDS version) > > If you are using CMake old enough not to have this property, an alternative workaround is to run configure_file() on the file (even if you never use the configured result). This will introduce the exact same dependency. That is indeed exactly what I needed, I am trying to figure out if I would ever have got that from Googling. I never think of ?running Cmake again? as ?configure? but it makes sense now you pointed it out. Thank you again, James -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3868 bytes Desc: not available URL: From ninimota87 at gmail.com Thu Jun 9 08:27:53 2016 From: ninimota87 at gmail.com (Ana Margarida Mota) Date: Thu, 9 Jun 2016 13:27:53 +0100 Subject: [CMake] CCMake is not getting updated Message-ID: Hello! I had to update cmake version from 2.8.12 to 3.5.2. I followed the steps here: https://xinyustudio.wordpress.com/2014/06/18/how-to-install-cmake-3-0-on-centos-6-centos-7/ . Now I have the right version of cmake (3.5.2), but the ccmake version is still 2.8.12... How can I update ccmake too? My system is CentOS 6.5. Thank you in advance!! -------------- next part -------------- An HTML attachment was scrubbed... URL: From domen.vrankar at gmail.com Thu Jun 9 08:31:24 2016 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Thu, 9 Jun 2016 14:31:24 +0200 Subject: [CMake] CCMake is not getting updated In-Reply-To: References: Message-ID: > Now I have the right version of cmake (3.5.2), but the ccmake version is > still 2.8.12... How can I update ccmake too? Not 100% certain but my guess would be that you are missing ncurses-devel package and therefore ccmake was not built. sudo yum install ncurses-devel Regards, Domen From ninimota87 at gmail.com Thu Jun 9 08:35:31 2016 From: ninimota87 at gmail.com (Ana Margarida Mota) Date: Thu, 9 Jun 2016 13:35:31 +0100 Subject: [CMake] CCMake is not getting updated In-Reply-To: References: Message-ID: OK, thank you very much! And now? Do I have to uninstall cmake 3.5 and install it again? Regards 2016-06-09 13:31 GMT+01:00 Domen Vrankar : > > Now I have the right version of cmake (3.5.2), but the ccmake version is > > still 2.8.12... How can I update ccmake too? > > Not 100% certain but my guess would be that you are missing > ncurses-devel package and therefore ccmake was not built. > > sudo yum install ncurses-devel > > Regards, > Domen > -------------- next part -------------- An HTML attachment was scrubbed... URL: From domen.vrankar at gmail.com Thu Jun 9 09:08:45 2016 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Thu, 9 Jun 2016 15:08:45 +0200 Subject: [CMake] CCMake is not getting updated In-Reply-To: References: Message-ID: > And now? Do I have to uninstall cmake 3.5 and install it again? Rebuild (in such cases I usually remove previous build dir as in the past sometimes it did not detect if a new library was added to the environment) and install (install is a dumb command that only copies files so you don't need to uninstall first as it will just overwrite the old ones). Regards, Domen From ninimota87 at gmail.com Thu Jun 9 09:47:48 2016 From: ninimota87 at gmail.com (Ana Margarida Mota) Date: Thu, 9 Jun 2016 14:47:48 +0100 Subject: [CMake] CCMake is not getting updated In-Reply-To: References: Message-ID: Perfect!! Now everything is working correctly!! Thank you so much!! Regards, Ana 2016-06-09 14:08 GMT+01:00 Domen Vrankar : > > And now? Do I have to uninstall cmake 3.5 and install it again? > > Rebuild (in such cases I usually remove previous build dir as in the > past sometimes it did not detect if a new library was added to the > environment) and install (install is a dumb command that only copies > files so you don't need to uninstall first as it will just overwrite > the old ones). > > Regards, > Domen > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.hoffman at kitware.com Thu Jun 9 11:36:17 2016 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Thu, 9 Jun 2016 11:36:17 -0400 Subject: [CMake] CMake v3.6.0 rc1 In-Reply-To: <57589611.2020001@gmail.com> References: <57589611.2020001@gmail.com> Message-ID: On 6/8/2016 6:02 PM, Gonzalo Garramu?o wrote: > I tried v3.6.0 rc1 but it fails on linking with a message about unknown > symbols when doing cmake -E vs_link_dll on a windows library. It seems > not to recognize the symbols in, for example, tinyxml2. > > The same code works just fine under cmake v3.5.2. Can you post an example project that shows this problem and describe which version of VS you are using and the steps needed to reproduce the problem? Thanks. -Bill From brad.king at kitware.com Thu Jun 9 11:40:58 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 9 Jun 2016 11:40:58 -0400 Subject: [CMake] CMake v3.6.0 rc1 In-Reply-To: <57589611.2020001@gmail.com> References: <57589611.2020001@gmail.com> Message-ID: <57598E0A.2010908@kitware.com> On 06/08/2016 06:02 PM, Gonzalo Garramu?o wrote: > I tried v3.6.0 rc1 but it fails on linking with a message about unknown > symbols when doing cmake -E vs_link_dll on a windows library. It seems > not to recognize the symbols in, for example, tinyxml2. > > The same code works just fine under cmake v3.5.2. I just cloned https://github.com/leethomason/tinyxml2 and it built fine with CMake 3.6.0-rc1 using the Ninja generator at a VS 2015 x86_64 tools command prompt. As Bill requested, please provide more details about how to reproduce the problem. Thanks, -Brad From chrysalisx at gmail.com Thu Jun 9 16:58:48 2016 From: chrysalisx at gmail.com (Walter Gray) Date: Thu, 09 Jun 2016 20:58:48 +0000 Subject: [CMake] MSVC /M[TD] as a compatible interface property? Message-ID: Setting /MT or /MD is pretty important, and is a transitive requirement. See: https://msdn.microsoft.com/en-us/library/2kzt1wy3(VS.80).aspx The standard mechanism of using target_compile_options isn't quite appropriate because it will simply append the flags used by each library and use the last one with no complaint if there is a mismatch. Example: A uses /MT, B uses /MD, C Depends on both. This will result in errors when compiling, but will configure just fine. I would like to make it so that if there is a mismatch between linked targets, cmake will either fail or issue a warning. https://cmake.org/cmake/help/v3.5/manual/cmake-buildsystem.7.html#compatible-interface-properties This seems to be meant to be used for exactly this type of thing, but because there is no specific property for specifying MSVC_RUNTIME, that system cannot be used in this case. Any thoughts on how to address this? -------------- next part -------------- An HTML attachment was scrubbed... URL: From arankin at robarts.ca Thu Jun 9 16:41:13 2016 From: arankin at robarts.ca (Adam Rankin) Date: Thu, 9 Jun 2016 20:41:13 +0000 Subject: [CMake] execute_process, cmd /c and vcvarsall Message-ID: Hello all, I am trying to develop a execute_process command that will first load the env variables set by the appropriate vcvarsall, and then run a compile command. See here for my progress so far: set(cuda_generation_command cmd /c "\"call \"$ENV{VS${VS_IDE_VERSION}0COMNTOOLS}../../VC/vcvarsall.bat\" x86_amd64 && \"${CUDA_NVCC_EXECUTABLE}\" \"${OpenCV_SOURCE_DIR}/cmake/checks/OpenCVDetectCudaArch.cu\" \"--run\"\"") execute_process( COMMAND ${cuda_generation_command} WORKING_DIRECTORY "${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeTmp/" RESULT_VARIABLE _nvcc_res OUTPUT_VARIABLE _nvcc_out OUTPUT_STRIP_TRAILING_WHITESPACE) When run at a command prompt, the command works as expected. When called from CMake, the output is: The filename, directory name, or volume label syntax is incorrect. Has anyone ever succeeded with something like this? Cheers, Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From dschepler at scalable-networks.com Thu Jun 9 17:54:45 2016 From: dschepler at scalable-networks.com (Daniel Schepler) Date: Thu, 9 Jun 2016 21:54:45 +0000 Subject: [CMake] MSVC /M[TD] as a compatible interface property? In-Reply-To: References: Message-ID: A while ago I did an experiment along the same lines, using something like this in CMake/MTflags.cmake. (What we really needed was forcing /MT /D_HAS_ITERATOR_DEBUGGING=0 even on debug builds, because we were using an external library only available in /MT format. So I might have accidentally broken it while adapting it here.) add_library(MTflags INTERFACE) target_compile_options(MTflags INTERFACE "/MT$<$:d>") set_property(TARGET MTflags PROPERTY INTERFACE_MSVC_MT ON) set_property(TARGET MTflags APPEND PROPERTY COMPATIBLE_INTERFACE_BOOL MSVC_MT) # Example usage: # include(MTflags) # add_library(A STATIC src1.cpp src2.cpp...) # target_link_libraries(A PUBLIC MTflags) That almost did what we wanted. The biggest problem (and the one annoying enough to make me abandon the experiment for the time being) was: if you configured using the "NMake Makefiles" generator, then the compiler would give a warning on each source file because the build system was passing both the default /MD[d] and the additional /MT. -- Daniel Schepler ________________________________ From: CMake [cmake-bounces at cmake.org] on behalf of Walter Gray [chrysalisx at gmail.com] Sent: Thursday, June 09, 2016 1:58 PM To: Cmake Mailing List Subject: [CMake] MSVC /M[TD] as a compatible interface property? Setting /MT or /MD is pretty important, and is a transitive requirement. See: https://msdn.microsoft.com/en-us/library/2kzt1wy3(VS.80).aspx The standard mechanism of using target_compile_options isn't quite appropriate because it will simply append the flags used by each library and use the last one with no complaint if there is a mismatch. Example: A uses /MT, B uses /MD, C Depends on both. This will result in errors when compiling, but will configure just fine. I would like to make it so that if there is a mismatch between linked targets, cmake will either fail or issue a warning. https://cmake.org/cmake/help/v3.5/manual/cmake-buildsystem.7.html#compatible-interface-properties This seems to be meant to be used for exactly this type of thing, but because there is no specific property for specifying MSVC_RUNTIME, that system cannot be used in this case. Any thoughts on how to address this? -------------- next part -------------- An HTML attachment was scrubbed... URL: From chrysalisx at gmail.com Thu Jun 9 21:11:14 2016 From: chrysalisx at gmail.com (Walter Gray) Date: Fri, 10 Jun 2016 01:11:14 +0000 Subject: [CMake] MSVC /M[TD] as a compatible interface property? In-Reply-To: References: Message-ID: Yeah, that issue with /MD and /MT is the reason every project I've seen that deals with this problem uses something like this: # https://cmake.org/Wiki/CMake_FAQ#How_can_I_build_my_MSVC_application_with_a_static_runtime.3F foreach(flag_var CMAKE_CXX_FLAGS CMAKE_CXX_FLAGS_DEBUG CMAKE_CXX_FLAGS_RELEASE CMAKE_CXX_FLAGS_MINSIZEREL CMAKE_CXX_FLAGS_RELWITHDEBINFO) if(${flag_var} MATCHES "/MD") string(REGEX REPLACE "/MD" "/MT" ${flag_var} "${${flag_var}}") endif(${flag_var} MATCHES "/MD") endforeach(flag_var) Just appending also means that you cant just check if the compile flags contain one or the other using string(FIND...) /MD and /MT are by no means unique in being a compile flag that needs to be the same between linked packages. I'd forgotten about HAS_ITERATOR_DEBUGGING, but STL version also comes to mind (vs10 vs vs12, libstdc++ vs libc++, ect) On Thu, Jun 9, 2016 at 2:54 PM Daniel Schepler < dschepler at scalable-networks.com> wrote: > A while ago I did an experiment along the same lines, using something like > this in CMake/MTflags.cmake. (What we really needed was forcing /MT > /D_HAS_ITERATOR_DEBUGGING=0 even on debug builds, because we were using an > external library only available in /MT format. So I might have > accidentally broken it while adapting it here.) > > add_library(MTflags INTERFACE) > target_compile_options(MTflags INTERFACE "/MT$<$:d>") > set_property(TARGET MTflags > PROPERTY INTERFACE_MSVC_MT ON) > set_property(TARGET MTflags > APPEND PROPERTY COMPATIBLE_INTERFACE_BOOL MSVC_MT) > > # Example usage: > # include(MTflags) > # add_library(A STATIC src1.cpp src2.cpp...) > # target_link_libraries(A PUBLIC MTflags) > > That almost did what we wanted. The biggest problem (and the one annoying > enough to make me abandon the experiment for the time being) was: if you > configured using the "NMake Makefiles" generator, then the compiler would > give a warning on each source file because the build system was passing > both the default /MD[d] and the additional /MT. > -- > Daniel Schepler > ------------------------------ > *From:* CMake [cmake-bounces at cmake.org] on behalf of Walter Gray [ > chrysalisx at gmail.com] > *Sent:* Thursday, June 09, 2016 1:58 PM > *To:* Cmake Mailing List > *Subject:* [CMake] MSVC /M[TD] as a compatible interface property? > > Setting /MT or /MD is pretty important, and is a transitive requirement. > See: https://msdn.microsoft.com/en-us/library/2kzt1wy3(VS.80).aspx > > The standard mechanism of using target_compile_options isn't quite > appropriate because it will simply append the flags used by each library > and use the last one with no complaint if there is a mismatch. > > Example: > A uses /MT, B uses /MD, C Depends on both. > This will result in errors when compiling, but will configure just fine. I > would like to make it so that if there is a mismatch between linked > targets, cmake will either fail or issue a warning. > > > https://cmake.org/cmake/help/v3.5/manual/cmake-buildsystem.7.html#compatible-interface-properties > This seems to be meant to be used for exactly this type of thing, but > because there is no specific property for specifying MSVC_RUNTIME, that > system cannot be used in this case. > > Any thoughts on how to address this? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kristianonline28 at gmail.com Fri Jun 10 06:21:52 2016 From: kristianonline28 at gmail.com (Kristian) Date: Fri, 10 Jun 2016 12:21:52 +0200 Subject: [CMake] execute_process, cmd /c and vcvarsall In-Reply-To: References: Message-ID: After some tries I found maybe a solution for you. In my small example, I had these lines, which are working: > set(HELLO1 "C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/vcvarsall.bat") > execute_process(COMMAND ${HELLO1} && msbuild /help WORKING_DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}") So for you, it would look like this (I am not very sure about it): ========== execute_process( COMMAND $ENV{VS${VS_IDE_VERSION} 0COMNTOOLS}../../VC/vcvarsall.bat x86_amd64 && ${CUDA_NVCC_EXECUTABLE} ${OpenCV_SOURCE_DIR}/cmake/checks/OpenCVDetectCudaArch.cu --run WORKING_DIRECTORY "${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeTmp/" RESULT_VARIABLE _nvcc_res OUTPUT_VARIABLE _nvcc_out OUTPUT_STRIP_TRAILING_WHITESPACE) ========== Anyhow, when I tried several types of your presentation, I got always some errors. I do not know, if this is a bug or not, but I will write them down here. Maybe some of the others could write something about it. *** First try *** > set(HELLO1 "C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/vcvarsall.bat") > execute_process(COMMAND cmd /c "call ${HELLO1}" WORKING_DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}" RESULT_VARIABLE _nvcc_res OUTPUT_VARIABLE _nvcc_out) > message("${_nvcc_out}") When I call these lines on a windows machine, I am getting the error > 'C:/Program' is not recognized as an internal or external command, operable program or batch file. *** Second try *** When I change the execute_process to this > execute_process(COMMAND cmd /c "call \"${HELLO1}\"" WORKING_DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}" RESULT_VARIABLE _nvcc_res OUTPUT_VARIABLE _nvcc_out) then I am getting this error > '\"C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/vcvarsall.bat\"' is not recognized as an internal or external command, operable program or batch file. So now, CMake / Batch recognizes the right path, but somehow there are the characters \". *** Third try *** I changed the definition of the variable HELLO1 into (because of some hints here https://superuser.com/questions/279008/how-do-i-escape-spaces-in-command-line-in-windows-without-using-quotation-marks ) > set(HELLO1 "C:/Program^ Files^ (x86)/Microsoft^ Visual^ Studio^ 14.0/VC/vcvarsall.bat") But here, I am also getting the error > 'C:/Program' is not recognized as an internal or external command, operable program or batch file. Even, when I double the carets ^^, then the same error occurs 2016-06-09 22:41 GMT+02:00 Adam Rankin : > Hello all, > > > > I am trying to develop a execute_process command that will first load the > env variables set by the appropriate vcvarsall, and then run a compile > command. See here for my progress so far: > > > > set(cuda_generation_command cmd /c "\"call > \"$ENV{VS${VS_IDE_VERSION}0COMNTOOLS}../../VC/vcvarsall.bat\" x86_amd64 && > \"${CUDA_NVCC_EXECUTABLE}\" > \"${OpenCV_SOURCE_DIR}/cmake/checks/OpenCVDetectCudaArch.cu\" \"--run\"\"") > > > > execute_process( COMMAND ${cuda_generation_command} > > WORKING_DIRECTORY > "${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeTmp/" > > RESULT_VARIABLE _nvcc_res OUTPUT_VARIABLE _nvcc_out > > OUTPUT_STRIP_TRAILING_WHITESPACE) > > > > When run at a command prompt, the command works as expected. When called > from CMake, the output is: > > The filename, directory name, or volume label syntax is incorrect. > > > > Has anyone ever succeeded with something like this? > > > > Cheers, > > Adam > > -- > > 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 davidshen84 at gmail.com Fri Jun 10 07:09:23 2016 From: davidshen84 at gmail.com (Xi Shen) Date: Fri, 10 Jun 2016 11:09:23 +0000 Subject: [CMake] Boost directories are not added to solution file Message-ID: I created a simple command line tool on Windows, using the Boost library. I use the CMake tool to generate the build file for MSBuild. I set the BOOST_INCLUDEDIR environment variable and CMake generated the build file without any error. However the solution cannot be built by MSBuild. It complains not able to find "boost\regex.hpp" file, etc. I found if I open the solution file and edit the `additional include directory` and `additional library directory`, the solution can build without error. So I wonder why CMake did not add those directories to the solution. What did I miss? Thanks, Daivd -- Thanks, David S. -------------- next part -------------- An HTML attachment was scrubbed... URL: From petr.kmoch at gmail.com Fri Jun 10 07:13:14 2016 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Fri, 10 Jun 2016 13:13:14 +0200 Subject: [CMake] Boost directories are not added to solution file In-Reply-To: References: Message-ID: Hi David. Probably something in your CMakeList is set up incorrectly. If you share that CMakeList, someone might be able to tell what. Petr On 10 June 2016 at 13:09, Xi Shen wrote: > I created a simple command line tool on Windows, using the Boost library. > I use the CMake tool to generate the build file for MSBuild. > > I set the BOOST_INCLUDEDIR environment variable and CMake generated the > build file without any error. > > However the solution cannot be built by MSBuild. It complains not able to > find "boost\regex.hpp" file, etc. > > I found if I open the solution file and edit the `additional include > directory` and `additional library directory`, the solution can build > without error. > > So I wonder why CMake did not add those directories to the solution. What > did I miss? > > > Thanks, > Daivd > > -- > > Thanks, > David S. > > -- > > 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 s.baars at rug.nl Fri Jun 10 07:34:15 2016 From: s.baars at rug.nl (Sven Baars) Date: Fri, 10 Jun 2016 13:34:15 +0200 Subject: [CMake] How do you handle recursive dependencies in CMake In-Reply-To: References: <57583A66.1050709@rug.nl> Message-ID: <575AA5B7.7060408@rug.nl> Hey Chuck, In ATargets.cmake it says add_library(a SHARED IMPORTED) and in BTargets.cmake it says add_library(b SHARED IMPORTED) However, if I build C it will say /usr/bin/ld: cannot find -la when I do find_package(B) target_link_libraries(c b) add_executable(main main.cpp) target_link_libraries(main c) This, I think, because the 'b' target depends on 'a' but doesn't know where 'a' is located, because this is not described in BTargets.cmake. Sven On 06/08/2016 06:07 PM, Chuck Atkins wrote: > If the projects are each providing their own Config.cmake file then > you probably will want to use those instead of Find modules. Instead > of using the Foo_Bar_LIBRARIES variable though, try using the actual > imported targets from the config files. Those should have the > appropriate dependency information. If you're not sure what they are > you should be able to dig through the provided Config.cmake and > Targets.cmake files for FooBar and see which targets are created bu > "add_library(FooBar::Foo ... IMPORTED)". > > - Chuck > > On Wed, Jun 8, 2016 at 11:31 AM, Sven Baars > wrote: > > In my case all projects provide their own FooBarConfig.cmake, but > not a FindFooBar.cmake. For this reason I wanted to use those, > because I thought it saves me the effort of writing a lot of > FindFooBar.cmake files, and it also seemed like the right way to > do it, because it provides things like FooBar_LIBRARIES, which is > what I need. The reason I said that I create my own > FooBarConfig.cmake, is because I want to use CMake properly in my > own project, so I also want to provide a FoorBarConfig.cmake file > for my users. So even if the projects I use don't do everything > properly, I still want to do it properly myself. The problem in > this case is that I'm not sure what the proper way is. If the > FoorBarConfig.cmake file is not enough to handle the dependencies > I encounter, should I provide a FindFooBar.cmake file or > something, instead of just the FooBarConfig.cmake? And meanwhile > also write a FindFooBar.cmake file for all my dependencies? > > Another reason why this seems odd to me, is because if N different > projects use FooBar, then also possibly N different versions of > FindFooBar.cmake are created by all the different projects (I have > actually already seen this a lot). That is the case, because the > FindFooBar.cmake file is not provided by the FooBar project, > unlike the FooBarConfig.cmake. > > Cheers, > Sven > > > On 06/08/2016 03:11 PM, Chuck Atkins wrote: >> The FooBarConfig.cmake is something that should be generated by >> FooBar's build. The reason you don't get absolute paths for the >> "libraries" from a package config file is that they're not >> actually libraries but imported targets. The imported target >> let's you treat "foo" as though it were a library built by your >> project. It then has the appropriate target properties set on it >> ti define the full path to it's library, etc. That being said, >> if you're manually creating the FooBarConfig.cmake that's not >> really the right approach. If the FooBar buil;d doesn't actually >> generate it's own FooBarConfig.cmake file then you'll want to >> create you're own FindFooBar.cmake. A bare bones find module >> that creates an imported target would look something like this: >> >> if(NOT FooBar_FOUND AND NOT TARGET FooBar::FooBar) >> find_path(FooBar_INCLUDE_DIR FooBar.h) >> find_library(FooBar_LIBRARY FooBar) >> >> include(FindPackageHandleStandardArgs) >> find_package_handle_standard_args(FooBar >> FOUND_VAR FooBar_FOUND >> REQUIRED_VARS FooBar_INCLUDE_DIR FooBar_LIBRARY >> ) >> endif() >> >> if(FooBar_FOUND AND NOT TARGET FooBar::FooBar) >> add_library(FooBar::FooBar UNKNOWN IMPORTED) >> set_target_properties(FooBar::FooBar PROPERTIES >> IMPORTED_LOCATION ${FooBar_LIBRARY} >> INTERFACE_INCLUDE_DIRECTORIES ${FooBar_INCLUDE_DIR} >> ) >> endif() >> >> Then in your project you can use: >> >> find_package(FooBar) >> add_library(MyLib supercoolfiles.cxx) >> target_libkLibraries(MyLib FooBar::FooBar) >> >> Where this starts to get really helpful in your situation is if >> you have an imported target for A, B, and C, then you can create >> the appropriate dependencies. Say, for example, you have a >> FindA.cmake that follows the pattern above and generates an A::A >> target. Then in your FindB.cmake you can have: >> >> if(NOT B_FOUND AND NOT TARGET B::B) >> find_path(B_INCLUDE_DIR B.h) >> find_library(B_LIBRARY B) >> >> include(FindPackageHandleStandardArgs) >> find_package_handle_standard_args(B >> FOUND_VAR B_FOUND >> REQUIRED_VARS B_INCLUDE_DIR B_LIBRARY >> ) >> >> * find_package(A QUIET) >> if(A_FOUND) >> set(B_Extra_Deps A::A) >> endif()* >> endif() >> >> if(B_FOUND AND NOT TARGET B::B) >> add_library(B::B UNKNOWN IMPORTED) >> set_target_properties(B::B PROPERTIES >> IMPORTED_LOCATION ${B_LIBRARY} >> INTERFACE_INCLUDE_DIRECTORIES ${B_INCLUDE_DIR} >> ) >> * if(B_Extra_Deps) >> set_target_properties(B::B PROPERTIES >> INTERFACE_LINK_LIBRARIES ${B_Extra_Deps} >> ) >> endif()* >> endif() >> >> and similarly for FindC.cmake. Since A::A, B::B, and C::C are >> actual proper CMake targets and not just library files then they >> carry with them associated target dependency information. In >> CMake vernacular we refer this as "target usage requirements" >> since the target caries with it all the necessary information for >> something to actually use it, whether that's just extra link >> libraries or also extra include directories and compile >> definitions needed. The Package::Target naming convention is the >> idea that each package has it's own namespace where you may >> define multiple targets. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Fri Jun 10 07:48:10 2016 From: DLRdave at aol.com (David Cole) Date: Fri, 10 Jun 2016 07:48:10 -0400 Subject: [CMake] execute_process, cmd /c and vcvarsall In-Reply-To: References: Message-ID: The easiest way to do what you want here is to make a standalone script (*.bat / *.cmd) that runs the commands you want and get it to work without CMake involvement at all, and then simply use execute_process to invoke that script. You can pass arguments to it if you need to communicate information from CMake to the script, but if you **require** environment for your command to run, the easiest way to achieve it is to write a script that sets up the env, and then executes the command, and then restores the environment (if necessary). In Windows *.cmd files, it's easy to save/restore the environment by using "setlocal" and "endlocal". Why bother with all the escaping and special characters in an execute_process when you could just write a script and then call it? It will be much easier on the eyes for people having to read your code in the future if you make it simpler. HTH, David C. On Fri, Jun 10, 2016 at 6:21 AM, Kristian wrote: > After some tries I found maybe a solution for you. In my small example, I > had these lines, which are working: > > >> set(HELLO1 "C:/Program Files (x86)/Microsoft Visual Studio >> 14.0/VC/vcvarsall.bat") >> execute_process(COMMAND ${HELLO1} && msbuild /help WORKING_DIRECTORY >> "${CMAKE_CURRENT_SOURCE_DIR}") > > So for you, it would look like this (I am not very sure about it): > > ========== > > > execute_process( COMMAND > $ENV{VS${VS_IDE_VERSION}0COMNTOOLS}../../VC/vcvarsall.bat x86_amd64 && > ${CUDA_NVCC_EXECUTABLE} > ${OpenCV_SOURCE_DIR}/cmake/checks/OpenCVDetectCudaArch.cu --run > > WORKING_DIRECTORY > "${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeTmp/" > > RESULT_VARIABLE _nvcc_res OUTPUT_VARIABLE _nvcc_out > > OUTPUT_STRIP_TRAILING_WHITESPACE) > > > ========== > > Anyhow, when I tried several types of your presentation, I got always some > errors. I do not know, if this is a bug or not, but I will write them down > here. Maybe some of the others could write something about it. > > > *** First try *** > >> set(HELLO1 "C:/Program Files (x86)/Microsoft Visual Studio >> 14.0/VC/vcvarsall.bat") >> execute_process(COMMAND cmd /c "call ${HELLO1}" WORKING_DIRECTORY >> "${CMAKE_CURRENT_SOURCE_DIR}" RESULT_VARIABLE _nvcc_res OUTPUT_VARIABLE >> _nvcc_out) >> message("${_nvcc_out}") > > When I call these lines on a windows machine, I am getting the error > >> 'C:/Program' is not recognized as an internal or external command, >> operable program or batch file. > > *** Second try *** > > When I change the execute_process to this > >> execute_process(COMMAND cmd /c "call \"${HELLO1}\"" WORKING_DIRECTORY >> "${CMAKE_CURRENT_SOURCE_DIR}" RESULT_VARIABLE _nvcc_res OUTPUT_VARIABLE >> _nvcc_out) > > then I am getting this error > >> '\"C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/vcvarsall.bat\"' >> is not recognized as an internal or external command, operable program or >> batch file. > > So now, CMake / Batch recognizes the right path, but somehow there are the > characters \". > > *** Third try *** > > I changed the definition of the variable HELLO1 into (because of some hints > here > https://superuser.com/questions/279008/how-do-i-escape-spaces-in-command-line-in-windows-without-using-quotation-marks) > >> set(HELLO1 "C:/Program^ Files^ (x86)/Microsoft^ Visual^ Studio^ >> 14.0/VC/vcvarsall.bat") > > But here, I am also getting the error > >> 'C:/Program' is not recognized as an internal or external command, >> operable program or batch file. > > Even, when I double the carets ^^, then the same error occurs > > > 2016-06-09 22:41 GMT+02:00 Adam Rankin : >> >> Hello all, >> >> >> >> I am trying to develop a execute_process command that will first load the >> env variables set by the appropriate vcvarsall, and then run a compile >> command. See here for my progress so far: >> >> >> >> set(cuda_generation_command cmd /c "\"call >> \"$ENV{VS${VS_IDE_VERSION}0COMNTOOLS}../../VC/vcvarsall.bat\" x86_amd64 && >> \"${CUDA_NVCC_EXECUTABLE}\" >> \"${OpenCV_SOURCE_DIR}/cmake/checks/OpenCVDetectCudaArch.cu\" \"--run\"\"") >> >> >> >> execute_process( COMMAND ${cuda_generation_command} >> >> WORKING_DIRECTORY >> "${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeTmp/" >> >> RESULT_VARIABLE _nvcc_res OUTPUT_VARIABLE _nvcc_out >> >> OUTPUT_STRIP_TRAILING_WHITESPACE) >> >> >> >> When run at a command prompt, the command works as expected. When called >> from CMake, the output is: >> >> The filename, directory name, or volume label syntax is incorrect. >> >> >> >> Has anyone ever succeeded with something like this? >> >> >> >> Cheers, >> >> Adam >> >> >> -- >> >> 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 sena at hurd.homeunix.org Fri Jun 10 08:05:31 2016 From: sena at hurd.homeunix.org (Sergey Spiridonov) Date: Fri, 10 Jun 2016 14:05:31 +0200 Subject: [CMake] how to compile single source file with debug options? Message-ID: Hello all, We have big project with lots of libraries and applications. We want to switch to cmake. Currently we use our own build system, which is derived from tmake. To debug and fix our applications/libraries we often need to recompile single source file in a debug mode. With the our current build system it is as simple, as touching a file an starting make with debug option. It will then recompile that single file with -O0 -g and with -DDEBUG and relink target application/library. How it would be possible in cmake? We found out how to do that for the single directory (library or application). But recompiling whole library/application just for single file is too slow. This is really a show-stopper for us. -- Best regards, Sergey Spiridonov From davidshen84 at gmail.com Fri Jun 10 09:50:04 2016 From: davidshen84 at gmail.com (Xi Shen) Date: Fri, 10 Jun 2016 13:50:04 +0000 Subject: [CMake] CMake and FindBoost cannot set the library variables Message-ID: Hi, I have a simple CMakeList.txt file: cmake_minimum_required (VERSION 3.0) project (winotify) set(Boost_USE_STATIC_LIBS ON) set(Boost_USE_MULTITHREADED ON) find_package(Boost REQUIRED COMPONENTS regex program_options) add_executable(winotify winotify.cpp) message(STATUS "xxx ${Boost_program_options_LIBRARY_DEBUG}") message(STATUS "xxx ${Boost_INCLUDE_DIR}") message(STATUS "xxx ${Boost_LIBRARY_DIR}") target_link_libraries(winotify ${Boost_PROGRAMOPTIONS_LIBRARY_DEBUG}) I set up BOOST_ROOT on my Windows system. When I execute cmake, I got: ... -- Boost version: 1.59.0 -- Found the following Boost libraries: -- regex -- program_options -- xxx -- xxx C:/Boost/include/boost-1_59 -- xxx -- Configuring done ... So the "Boost_INCLUDE_DIR" variable is set, but the other are not...what did I miss? Thanks, David -- Thanks, David S. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Luke.Mauldin at l-3com.com Fri Jun 10 10:49:41 2016 From: Luke.Mauldin at l-3com.com (Luke.Mauldin at l-3com.com) Date: Fri, 10 Jun 2016 14:49:41 +0000 Subject: [CMake] v140_clang_3_7 generator and multi processor compilation Message-ID: I am using Cmake 3.6.0 RC1 with Visual Studio 2015 and the Clang May 2016 update. When I create a simple C++ project with Visual Studio 2015 and change the toolset to v140_clang_3_7, I have the option to set Multi Processor Compilation to "Yes". When I do this, this setting is added in the .vcxproj file: true However, if I use Cmake to generate my project files using: "cmake .. -G "Visual Studio 14 2015 Win64" -T v140_clang_3_7", I cannot find a way to have the generated project file contain the UseMutliToolTask as shown above. I have tried modifying CXX_FLAGS and other input variables but cannot figure it out. Can someone please help me? Luke -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggarra13 at gmail.com Fri Jun 10 12:52:35 2016 From: ggarra13 at gmail.com (Gonzalo) Date: Fri, 10 Jun 2016 13:52:35 -0300 Subject: [CMake] how to compile single source file with debug options? In-Reply-To: References: Message-ID: <575AF053.1040106@gmail.com> El 10/06/16 a las 09:05, Sergey Spiridonov escribi?: > Hello all, > > We have big project with lots of libraries and applications. We want to > switch to cmake. Currently we use our own build system, which is derived > from tmake. Cmake handles all dependencies if you keep the CMakeFiles directory around. If you do and have a debug build, you can then just do: touch file.c and only that file will be recompiled and relinked. -- Gonzalo Garramu?o ggarra13 at gmail.com From sena at hurd.homeunix.org Fri Jun 10 12:57:55 2016 From: sena at hurd.homeunix.org (Sergey Spiridonov) Date: Fri, 10 Jun 2016 18:57:55 +0200 Subject: [CMake] how to compile single source file with debug options? In-Reply-To: <575AF053.1040106@gmail.com> References: <575AF053.1040106@gmail.com> Message-ID: Hi Gonzalo On 10/06/16 18:52, Gonzalo wrote: >> We have big project with lots of libraries and applications. We want to >> switch to cmake. Currently we use our own build system, which is derived >> from tmake. > Cmake handles all dependencies if you keep the CMakeFiles directory around. > If you do and have a debug build, you can then just do: > > touch file.c > > and only that file will be recompiled and relinked. I do release build, but I want single source file to be compiled in debug mode, with "-O0 -DDEBUG" options instead of "-O3". Of course, without recompiling whole directory. -- Best regards, Sergey Spiridonov From arankin at robarts.ca Fri Jun 10 13:07:34 2016 From: arankin at robarts.ca (Adam Rankin) Date: Fri, 10 Jun 2016 17:07:34 +0000 Subject: [CMake] execute_process, cmd /c and vcvarsall In-Reply-To: References: Message-ID: Thank you Kristian, I will keep experimenting. David, I agree, and in my own project I have done it that way. However, I am attempting to fix the CUDA auto detection in OpenCV, and I am not sure if they would take kindly to adding .bat files for Windows only solutions (maybe they will, I haven't discussed it yet). I was hoping to solve the problem within a CMake one-liner to reduce the complexity of the change. Thanks for your suggestions, Adam -----Original Message----- From: David Cole [mailto:DLRdave at aol.com] Sent: Friday, June 10, 2016 7:48 AM To: Kristian Cc: Adam Rankin ; cmake at cmake.org Subject: Re: [CMake] execute_process, cmd /c and vcvarsall The easiest way to do what you want here is to make a standalone script (*.bat / *.cmd) that runs the commands you want and get it to work without CMake involvement at all, and then simply use execute_process to invoke that script. You can pass arguments to it if you need to communicate information from CMake to the script, but if you **require** environment for your command to run, the easiest way to achieve it is to write a script that sets up the env, and then executes the command, and then restores the environment (if necessary). In Windows *.cmd files, it's easy to save/restore the environment by using "setlocal" and "endlocal". Why bother with all the escaping and special characters in an execute_process when you could just write a script and then call it? It will be much easier on the eyes for people having to read your code in the future if you make it simpler. HTH, David C. On Fri, Jun 10, 2016 at 6:21 AM, Kristian wrote: > After some tries I found maybe a solution for you. In my small > example, I had these lines, which are working: > > >> set(HELLO1 "C:/Program Files (x86)/Microsoft Visual Studio >> 14.0/VC/vcvarsall.bat") >> execute_process(COMMAND ${HELLO1} && msbuild /help WORKING_DIRECTORY >> "${CMAKE_CURRENT_SOURCE_DIR}") > > So for you, it would look like this (I am not very sure about it): > > ========== > > > execute_process( COMMAND > $ENV{VS${VS_IDE_VERSION}0COMNTOOLS}../../VC/vcvarsall.bat x86_amd64 && > ${CUDA_NVCC_EXECUTABLE} > ${OpenCV_SOURCE_DIR}/cmake/checks/OpenCVDetectCudaArch.cu --run > > WORKING_DIRECTORY > "${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeTmp/" > > RESULT_VARIABLE _nvcc_res OUTPUT_VARIABLE _nvcc_out > > OUTPUT_STRIP_TRAILING_WHITESPACE) > > > ========== > > Anyhow, when I tried several types of your presentation, I got always > some errors. I do not know, if this is a bug or not, but I will write > them down here. Maybe some of the others could write something about it. > > > *** First try *** > >> set(HELLO1 "C:/Program Files (x86)/Microsoft Visual Studio >> 14.0/VC/vcvarsall.bat") >> execute_process(COMMAND cmd /c "call ${HELLO1}" WORKING_DIRECTORY >> "${CMAKE_CURRENT_SOURCE_DIR}" RESULT_VARIABLE _nvcc_res >> OUTPUT_VARIABLE >> _nvcc_out) >> message("${_nvcc_out}") > > When I call these lines on a windows machine, I am getting the error > >> 'C:/Program' is not recognized as an internal or external command, >> operable program or batch file. > > *** Second try *** > > When I change the execute_process to this > >> execute_process(COMMAND cmd /c "call \"${HELLO1}\"" WORKING_DIRECTORY >> "${CMAKE_CURRENT_SOURCE_DIR}" RESULT_VARIABLE _nvcc_res >> OUTPUT_VARIABLE >> _nvcc_out) > > then I am getting this error > >> '\"C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/vcvarsall.bat\"' >> is not recognized as an internal or external command, operable >> program or batch file. > > So now, CMake / Batch recognizes the right path, but somehow there are > the characters \". > > *** Third try *** > > I changed the definition of the variable HELLO1 into (because of some > hints here > https://superuser.com/questions/279008/how-do-i-escape-spaces-in-comma > nd-line-in-windows-without-using-quotation-marks) > >> set(HELLO1 "C:/Program^ Files^ (x86)/Microsoft^ Visual^ Studio^ >> 14.0/VC/vcvarsall.bat") > > But here, I am also getting the error > >> 'C:/Program' is not recognized as an internal or external command, >> operable program or batch file. > > Even, when I double the carets ^^, then the same error occurs > > > 2016-06-09 22:41 GMT+02:00 Adam Rankin : >> >> Hello all, >> >> >> >> I am trying to develop a execute_process command that will first load >> the env variables set by the appropriate vcvarsall, and then run a >> compile command. See here for my progress so far: >> >> >> >> set(cuda_generation_command cmd /c "\"call >> \"$ENV{VS${VS_IDE_VERSION}0COMNTOOLS}../../VC/vcvarsall.bat\" >> x86_amd64 && \"${CUDA_NVCC_EXECUTABLE}\" >> \"${OpenCV_SOURCE_DIR}/cmake/checks/OpenCVDetectCudaArch.cu\" >> \"--run\"\"") >> >> >> >> execute_process( COMMAND ${cuda_generation_command} >> >> WORKING_DIRECTORY >> "${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeTmp/" >> >> RESULT_VARIABLE _nvcc_res OUTPUT_VARIABLE _nvcc_out >> >> OUTPUT_STRIP_TRAILING_WHITESPACE) >> >> >> >> When run at a command prompt, the command works as expected. When >> called from CMake, the output is: >> >> The filename, directory name, or volume label syntax is incorrect. >> >> >> >> Has anyone ever succeeded with something like this? >> >> >> >> Cheers, >> >> Adam >> >> >> -- >> >> 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 ggarra13 at gmail.com Fri Jun 10 13:13:27 2016 From: ggarra13 at gmail.com (Gonzalo) Date: Fri, 10 Jun 2016 14:13:27 -0300 Subject: [CMake] how to compile single source file with debug options? In-Reply-To: References: <575AF053.1040106@gmail.com> Message-ID: <575AF537.1050605@gmail.com> El 10/06/16 a las 13:57, Sergey Spiridonov escribi?: > I do release build, but I want single source file to be compiled in > debug mode, with "-O0 -DDEBUG" options instead of "-O3". > > Of course, without recompiling whole directory. > Oh, I see. In perspective, Windows, for example, does not allow mixing debug and non debug builds. I am afraid cmake cannot do what you want. But you may be able to do it with a wrapper bash script. The idea would be to have two CMakeCache.txt files (one debug, one release) and a CMakeFiles directory. Once you want to compile a single file in a directory, you'd rename the debug CMakeCache.txt file and run cmake/make. I'll let others chime in with more elegant solutions. -- Gonzalo Garramu?o ggarra13 at gmail.com From rleigh at codelibre.net Fri Jun 10 15:03:43 2016 From: rleigh at codelibre.net (Roger Leigh) Date: Fri, 10 Jun 2016 19:03:43 +0000 Subject: [CMake] CMake and FindBoost cannot set the library variables In-Reply-To: References: Message-ID: <6327a7b7-4b36-7c6c-e0b2-27cb3a6b2b3e@codelibre.net> On 10/06/2016 13:50, Xi Shen wrote: > find_package(Boost REQUIRED COMPONENTS regex program_options) > > add_executable(winotify winotify.cpp) > > message(STATUS "xxx ${Boost_program_options_LIBRARY_DEBUG}") Try Boost_PROGRAM_OPTIONS_LIBRARY_DEBUG > message(STATUS "xxx ${Boost_INCLUDE_DIR}") > message(STATUS "xxx ${Boost_LIBRARY_DIR}") Try Boost_LIBRARY_DIRS Even easier: use the Boost::program_options interface target target_link_libraries(winotify Boost::program_options) and it will handle both the include dir and the library to link with transparently. It's the way forward! Regards, Roger From davidshen84 at gmail.com Fri Jun 10 22:24:38 2016 From: davidshen84 at gmail.com (Xi Shen) Date: Sat, 11 Jun 2016 02:24:38 +0000 Subject: [CMake] CMake and FindBoost cannot set the library variables In-Reply-To: <6327a7b7-4b36-7c6c-e0b2-27cb3a6b2b3e@codelibre.net> References: <6327a7b7-4b36-7c6c-e0b2-27cb3a6b2b3e@codelibre.net> Message-ID: Thanks a lot man~ On Sat, Jun 11, 2016 at 3:04 AM Roger Leigh wrote: > On 10/06/2016 13:50, Xi Shen wrote: > > find_package(Boost REQUIRED COMPONENTS regex program_options) > > > > add_executable(winotify winotify.cpp) > > > > message(STATUS "xxx ${Boost_program_options_LIBRARY_DEBUG}") > > Try Boost_PROGRAM_OPTIONS_LIBRARY_DEBUG > > > message(STATUS "xxx ${Boost_INCLUDE_DIR}") > > message(STATUS "xxx ${Boost_LIBRARY_DIR}") > > Try Boost_LIBRARY_DIRS > > Even easier: use the Boost::program_options interface target > > target_link_libraries(winotify Boost::program_options) > > and it will handle both the include dir and the library to link with > transparently. It's the way forward! > > > Regards, > Roger > -- > > 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 > -- Thanks, David S. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jphartmann at gmail.com Sat Jun 11 10:01:10 2016 From: jphartmann at gmail.com (John P. Hartmann) Date: Sat, 11 Jun 2016 16:01:10 +0200 Subject: [CMake] Testing commands that are intended to fail In-Reply-To: <575C184F.5@gmail.com> References: <575C184F.5@gmail.com> Message-ID: <575C19A6.9040102@gmail.com> Excuse me for asking a no doubt obvious question. The test case (objlink is the executable): add_test( null objlink ) The log: Output: ---------------------------------------------------------- Positional argument(s) missing. 0 specified, 1 required. Test time = 0.01 sec ---------------------------------------------------------- Test Failed. Test was actually successful. I'd like to verify that the return value is 8 and that the above message is issued to standard error. The test should fail for any other return value or if anything is written to stdout or if anything else is written to stderr. Howto, please? From magnus at therning.org Mon Jun 13 04:00:40 2016 From: magnus at therning.org (Magnus Therning) Date: Mon, 13 Jun 2016 10:00:40 +0200 Subject: [CMake] Testing commands that are intended to fail In-Reply-To: <575C19A6.9040102@gmail.com> References: <575C184F.5@gmail.com> <575C19A6.9040102@gmail.com> Message-ID: <8737ohv7pz.fsf@sobel.cipherstone.com> John P. Hartmann writes: > Excuse me for asking a no doubt obvious question. > > The test case (objlink is the executable): > > add_test( null objlink ) > > The log: > > Output: > ---------------------------------------------------------- > Positional argument(s) missing. 0 specified, 1 required. > > Test time = 0.01 sec > ---------------------------------------------------------- > Test Failed. > > Test was actually successful. I'd like to verify that the return value > is 8 and that the above message is issued to standard error. The test > should fail for any other return value or if anything is written to > stdout or if anything else is written to stderr. > > Howto, please? I'd wrap it in a shell script, or use something like shelltestrunner[1]. /M [1]: http://joyful.com/shelltestrunner/ -- Magnus Therning OpenPGP: 0x927912051716CE39 email: magnus at therning.org jabber: magnus at therning.org twitter: magthe http://therning.org/magnus Java is, in many ways, C++--. ? M Feldman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 800 bytes Desc: not available URL: From patrick.boettcher at posteo.de Mon Jun 13 05:36:20 2016 From: patrick.boettcher at posteo.de (Patrick Boettcher) Date: Mon, 13 Jun 2016 11:36:20 +0200 Subject: [CMake] GCC: -std=g++14 vs -std=c++14 Message-ID: <20160613113620.0eb4f713@posteo.de> Hi list, I'm using gcc for a c++14-based project. To have cmake add the corresponding -std=-flag I'm setting set_property(TARGET PROPERTY CXX_STANDARD 14) This makes that when gcc is used cmake adds -std=gnu++14 . How can I make it set -std=c++14 instead? Background: my problem is the complex literal 'i' . This literal existed in gcc as a C99 extension and the effect is kept when -std=gnu++14 is set and deactivated when -std=c++14 is set. The outcome is that '0.0i' is typed as '__complex__ double' and not 'std::complex' as the standard says. regards. -- Patrick. From brad.king at kitware.com Mon Jun 13 08:31:51 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 13 Jun 2016 08:31:51 -0400 Subject: [CMake] [ANNOUNCE] CMake Issue Tracker Moved Message-ID: <575EA7B7.8080305@kitware.com> Hi Folks, CMake issue tracking is now hosted on Kitware's GitLab instance: https://gitlab.kitware.com/cmake/cmake/issues The old mantis issue tracker will remain available as a read-only reference. All CMake issues from that tracker have been migrated to the new CMake Issues page with their original numbers intact and links back to the original mantis pages in their descriptions. Further discussion of any issue should take place on its new page. -Brad From sena at hurd.homeunix.org Mon Jun 13 11:37:11 2016 From: sena at hurd.homeunix.org (Sergey Spiridonov) Date: Mon, 13 Jun 2016 17:37:11 +0200 Subject: [CMake] how to compile single source file with debug options? In-Reply-To: References: Message-ID: <575ED327.4080802@hurd.homeunix.org> Hi all On 10/06/16 14:05, Sergey Spiridonov wrote: > To debug and fix our applications/libraries we often need to recompile > single source file in a debug mode. With the our current build system it > is as simple, as touching a file an starting make with debug option. It > will then recompile that single file with -O0 -g and with -DDEBUG and > relink target application/library. I implemented following solution (proposed by Elizabeth A. Fischer elizabeth.fischer at columbia.edu): 1. Create a wrapper script ggcc/gg++ around the gcc/g++. It checks if env variable PDL has "d" and if true, then removes release options and inserts debug options instead. 2. The very first time cmake must be started like "CC=ggcc CXX=gg++ cmake" (it is not enough just to rerun cmake, you must clean everything first) 3. To recompile some of the source files in debug mode, one has to touch them and run "make PDL=d" Here is the wrapper script (inspired by [1]) [1] https://github.com/gawen947/gcc-wrapper/ #!/bin/bash # This is a wrapper around gcc compiler to allow switching to debug mode "on the fly" # you can enable debugging by executing "make PDL=d" # # # (may be also trigger debug mode by creating empty sourcefile.cc.debug in the same directory?) # TODO: pass this from cmake(CMakeList.txt)->make GAM_DEBUG_FLAGS="-Og -g -DGAM_DEBUG -ggdb -fno-inline -fno-default-inline" GAM_REMOVE_DEBUG_FLAGS="-O3 -finline-functions -fexpensive-optimizations" # what is cheaper, call external program or use bash instead of sh? newcmd="" if [ ${0##*/} == "ggcc" ]; then TOOL="gcc" elif [ ${0##*/} == "gg++" ]; then TOOL="g++" else echo "wrapper for gcc or g++" exit 120 fi if [[ "$PDL" == *"d"* ]]; then # add GAM_DEBUG_FLAGS, remove GAM_REMOVE_DEBUG_FLAGS INSERTED=0 for arg in $*; do if [ "-O3" == "$arg" ]; then INSERTED=1 newcmd="$newcmd $GAM_DEBUG_FLAGS" continue fi # note spaces around env variables, they are essential if [[ " $GAM_DEBUG_FLAGS $GAM_REMOVE_FLAGS " == *" $arg "* ]]; then continue fi newcmd="$newcmd $arg" done if [ "$INSERTED" == 1 ]; then echo $TOOL $newcmd exec $TOOL $newcmd else exec $TOOL "$@" fi else exec $TOOL "$@" fi Hope this can be useful for somebody else... -- Best regards, Sergey Spiridonov From joubert.sy at gmail.com Mon Jun 13 12:40:59 2016 From: joubert.sy at gmail.com (Sylvain Joubert) Date: Mon, 13 Jun 2016 18:40:59 +0200 Subject: [CMake] GCC: -std=g++14 vs -std=c++14 In-Reply-To: <20160613113620.0eb4f713@posteo.de> References: <20160613113620.0eb4f713@posteo.de> Message-ID: <575EE21B.7030809@gmail.com> Le 13/06/2016 11:36, Patrick Boettcher a ?crit : > Hi list, > > I'm using gcc for a c++14-based project. > > To have cmake add the corresponding -std=-flag I'm setting > > set_property(TARGET PROPERTY CXX_STANDARD 14) > > This makes that when gcc is used cmake adds -std=gnu++14 . > > How can I make it set -std=c++14 instead? Hi, You also need to correctly set the CXX_EXTENSIONS properties to get a standard standard. You might also want to take a look at the CXX_STANDARD_REQUIRED property. Sylvain From patrick.boettcher at posteo.de Mon Jun 13 14:05:23 2016 From: patrick.boettcher at posteo.de (Patrick Boettcher) Date: Mon, 13 Jun 2016 20:05:23 +0200 Subject: [CMake] GCC: -std=g++14 vs -std=c++14 In-Reply-To: <575EE21B.7030809@gmail.com> References: <20160613113620.0eb4f713@posteo.de> <575EE21B.7030809@gmail.com> Message-ID: <20160613200523.1edc761c@vdr> On Mon, 13 Jun 2016 18:40:59 +0200 Sylvain Joubert wrote: > Le 13/06/2016 11:36, Patrick Boettcher a ?crit : > > Hi list, > > > > I'm using gcc for a c++14-based project. > > > > To have cmake add the corresponding -std=-flag I'm setting > > > > set_property(TARGET PROPERTY CXX_STANDARD 14) > > > > This makes that when gcc is used cmake adds -std=gnu++14 . > > > > How can I make it set -std=c++14 instead? > > Hi, > > You also need to correctly set the CXX_EXTENSIONS properties to get a > standard standard. Yep, set(CXX_EXTENSIONS OFF) seems to do the trick - thanks. regards, -- Patrick. From roman.wueger at gmx.at Mon Jun 13 14:58:14 2016 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Mon, 13 Jun 2016 20:58:14 +0200 Subject: [CMake] Problems when generating xcarchive from within Xcode Message-ID: <38A15792-E147-439A-AFDB-7580DEF05154@gmx.at> Hello, I have successfully configured a project with CMake 3.5.2 so it creates a valid Release and Debug *.app bundle which runs on iOS. However if I build an archive in Xcode with "Product->Archive" then the app bundle seems not complete under ~/Library/Developer/Xcode/Archives/YYY-MM-DD/*.xcarchive For example the Info.plist is not the same as in the Release folder, subfolders and some files are not copied/created. Did I need something special for this (the archive)? Thanks Roman From robert.maynard at kitware.com Mon Jun 13 15:08:06 2016 From: robert.maynard at kitware.com (Robert Maynard) Date: Mon, 13 Jun 2016 15:08:06 -0400 Subject: [CMake] [ANNOUNCE] CMake 3.6.0-rc2 now ready for testing! Message-ID: I am proud to announce the second CMake 3.6 release candidate. https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.6 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.6/release/3.6.html Some of the more significant features of CMake 3.6 are: * The "Visual Studio 14 2015" generator learned to support the Clang/C2 toolsets, e.g. with the "-T v140_clang_3_7" option. This feature is experimental. * The "list()" command gained a "FILTER" sub-command to filter list elements by regular expression. * A "CMAKE_TRY_COMPILE_TARGET_TYPE" variable was added to optionally tell the "try_compile()" command to build a static library instead of an executable. This is useful for cross-compiling toolchains that cannot link binaries without custom flags or scripts. * A "_CLANG_TIDY" target property and supporting "CMAKE__CLANG_TIDY" variable were introduced to tell the Makefile Generators and the "Ninja" generator to run "clang-tidy" along with the compiler for "C" and "CXX" languages. * The "ExternalProject" module leared the "GIT_SHALLOW 1" option to perform a shallow clone of a Git repository. * The "ExternalProject" module learned to initialize Git submodules recursively and also to initialize new submodules on updates. Use the "GIT_SUBMODULES" option to restrict which submodules are initalized and updated. * The "InstallRequiredSystemLibraries" module learned a new "CMAKE_INSTALL_UCRT_LIBRARIES" option to enable app-local deployment of the Windows Universal CRT libraries with Visual Studio 2015. * The "Compile Features" functionality is now aware of features supported by Intel C++ compilers versions 12.1 through 16.0 on UNIX platforms. Deprecated and Removed Features =============================== * The "CMakeForceCompiler" module and its macros are now deprecated. See module documentation for an explanation. * The "Visual Studio 7 .NET 2003" generator is now deprecated and will be removed in a future version of CMake. * The "Visual Studio 7" generator (for VS .NET 2002) has been removed. It had been deprecated since CMake 3.3. * The "Visual Studio 6" generator has been removed. It had been deprecated since CMake 3.3. CMake 3.6 Release Notes *********************** Changes made since CMake 3.5 include the following. New Features ============ Generators ---------- * The "Ninja" generator learned to produce phony targets of the form "sub/dir/all" to drive the build of a subdirectory. This is equivalent to "cd sub/dir; make all" with Makefile Generators. * The "Ninja" generator now includes system header files in build dependencies to ensure correct re-builds when system packages are updated. * The "Visual Studio 14 2015" generator learned to support the Clang/C2 toolsets, e.g. with the "-T v140_clang_3_7" option. This feature is experimental. Commands -------- * The "add_custom_command()" and "add_custom_target()" commands learned how to use the "CROSSCOMPILING_EMULATOR" executable target property. * The "install()" command learned a new "EXCLUDE_FROM_ALL" option to leave installation rules out of the default installation. * The "list()" command gained a "FILTER" sub-command to filter list elements by regular expression. * The "string(TIMESTAMP)" and "file(TIMESTAMP)" commands gained support for the "%s" placeholder. This is the number of seconds since the UNIX Epoch. * The "try_compile()" command source file signature now honors configuration-specific flags (e.g. "CMAKE__FLAGS_DEBUG") in the generated test project. Previously only the default such flags for the current toolchain were used. Variables --------- * A "CMAKE_DEPENDS_IN_PROJECT_ONLY" variable was introduced to tell Makefile Generators to limit dependency scanning only to files in the project source and build trees. * A new "CMAKE_HOST_SOLARIS" variable was introduced to indicate when CMake is running on an Oracle Solaris host. * A "CMAKE__STANDARD_INCLUDE_DIRECTORIES" variable was added for use by toolchain files to specify system include directories to be appended to all compiler command lines. * The "CMAKE__STANDARD_LIBRARIES" variable is now documented. It is intended for use by toolchain files to specify system libraries to be added to all linker command lines. * A "CMAKE_NINJA_OUTPUT_PATH_PREFIX" variable was introduced to tell the "Ninja" generator to configure the generated "build.ninja" file for use as a "subninja". * A "CMAKE_TRY_COMPILE_PLATFORM_VARIABLES" variable was added for use by toolchain files to specify platform-specific variables that must be propagated by the "try_compile()" command into test projects. * A "CMAKE_TRY_COMPILE_TARGET_TYPE" variable was added to optionally tell the "try_compile()" command to build a static library instead of an executable. This is useful for cross-compiling toolchains that cannot link binaries without custom flags or scripts. Properties ---------- * A "DEPLOYMENT_REMOTE_DIRECTORY" target property was introduced to tell the "Visual Studio 9 2008" and "Visual Studio 8 2005" generators to generate the "remote directory" for WinCE project deployment and debugger settings. * A "_CLANG_TIDY" target property and supporting "CMAKE__CLANG_TIDY" variable were introduced to tell the Makefile Generators and the "Ninja" generator to run "clang-tidy" along with the compiler for "C" and "CXX" languages. * A "TIMEOUT_AFTER_MATCH" test property was introduced to optionally tell CTest to enforce a secondary timeout after matching certain output from a test. * A "VS_CONFIGURATION_TYPE" target property was introduced to specify a custom project file type for Visual Studio Generators supporting VS 2010 and above. * A "VS_STARTUP_PROJECT" directory property was introduced to specify for Visual Studio Generators the default startup project for generated solutions (".sln" files). Modules ------- * The "CMakePushCheckState" module now pushes/pops/resets the variable "CMAKE_EXTRA_INCLUDE_FILE" used in "CheckTypeSize". * The "ExternalProject" module leared the "GIT_SHALLOW 1" option to perform a shallow clone of a Git repository. * The "ExternalProject" module learned to initialize Git submodules recursively and also to initialize new submodules on updates. Use the "GIT_SUBMODULES" option to restrict which submodules are initalized and updated. * The "ExternalProject" module leared the "DOWNLOAD_NO_EXTRACT 1" argument to skip extracting the file that is downloaded (e.g., for self-extracting shell installers or ".msi" files). * The "ExternalProject" module now uses "TLS_VERIFY" when fetching from git repositories. * The "FindBLAS" and "FindLAPACK" modules learned to support OpenBLAS. * The "FindCUDA" module learned to find the "cublas_device" library. * The "FindGTest" module "gtest_add_tests" function now causes CMake to automatically re-run when test sources change so that they can be re-scanned. * The "FindLTTngUST" module was introduced to find the LTTng-UST library. * The "FindPkgConfig" module learned to optionally create imported targets for the libraries it has found. * The "FindProtobuf" module learned to provide a "Protobuf_VERSION" variable and check the version number requested in a "find_package()" call. * The "InstallRequiredSystemLibraries" module learned a new "CMAKE_INSTALL_UCRT_LIBRARIES" option to enable app-local deployment of the Windows Universal CRT libraries with Visual Studio 2015. Platforms --------- * The Clang compiler is now supported on CYGWIN. * Support was added for the Bruce C Compiler with compiler id "Bruce". CTest ----- * The "ctest_update()" command now looks at the "CTEST_GIT_INIT_SUBMODULES" variable to determine whether submodules should be updated or not before updating. * The "ctest_update()" command will now synchronize submodules on an update. Updates which add submodules or change a submodule's URL will now be pulled properly. CPack ----- * The "CPackDeb" module learned how to handle "$ORIGIN" in "CMAKE_INSTALL_RPATH" when "CPACK_DEBIAN_PACKAGE_SHLIBDEPS" is used for dependency auto detection. * The "CPackDeb" module learned how to generate "DEBIAN/shlibs" contorl file when package contains shared libraries. * The "CPackDeb" module learned how to generate "DEBIAN/postinst" and "DEBIAN/postrm" files if the package installs libraries in ldconfig- controlled locations (e.g. "/lib/", "/usr/lib/"). * The "CPackDeb" module learned how to generate dependencies between Debian packages if multi-component setup is used and "CPACK_COMPONENT__DEPENDS" variables are set. For backward compatibility this feature is disabled by default. See "CPACK_DEBIAN_ENABLE_COMPONENT_DEPENDS". * The "CPackDeb" module learned how to set custom package file names including how to generate properly-named Debian packages: _-_.deb For backward compatibility this feature is disabled by default. See "CPACK_DEBIAN_FILE_NAME" and "CPACK_DEBIAN__FILE_NAME". * The "CPackDeb" module learned how to set the package release number ("DebianRevisionNumber" in package file name when used in combination with "DEB-DEFAULT" value set by "CPACK_DEBIAN_FILE_NAME"). See "CPACK_DEBIAN_PACKAGE_RELEASE". * The "CPackDeb" module learned how to set the package architecture per-component. See "CPACK_DEBIAN__PACKAGE_ARCHITECTURE". * The "CPackDMG" module learned a new option to tell the CPack "DragNDrop" generaor to skip the "/Applications" symlink. See the "CPACK_DMG_DISABLE_APPLICATIONS_SYMLINK" variable. * The "CPackIFW" module gained a new "cpack_ifw_update_repository()" command to update a QtIFW-specific repository from a remote repository. * The "CPackRPM" module learned how to set RPM "dist" tag as part of RPM "Release:" tag when enabled (mandatory on some Linux distributions for e.g. on Fedora). See "CPACK_RPM_PACKAGE_RELEASE_DIST". * The "CPackRPM" module learned how to set default values for owning user/group and file/directory permissions of package content. See "CPACK_RPM_DEFAULT_USER", "CPACK_RPM_DEFAULT_GROUP", "CPACK_RPM_DEFAULT_FILE_PERMISSIONS", "CPACK_RPM_DEFAULT_DIR_PERMISSIONS" and their per component counterparts. * The "CPackRPM" module learned how to set user defined package file names, how to specify that rpmbuild should decide on file name format as well as handling of multiple rpm packages generated by a single user defined spec file. See "CPACK_RPM_PACKAGE_NAME" and "CPACK_RPM__PACKAGE_NAME". * The "CPackRPM" module learned how to correctly handle symlinks that are pointing outside generated packages. Other ----- * The "Compile Features" functionality is now aware of features supported by Intel C++ compilers versions 12.1 through 16.0 on UNIX platforms. Deprecated and Removed Features =============================== * The "CMakeForceCompiler" module and its macros are now deprecated. See module documentation for an explanation. * The "find_library()", "find_path()", and "find_file()" commands no longer search in installation prefixes derived from the "PATH" environment variable on non-Windows platforms. This behavior was added in CMake 3.3 to support Windows hosts but has proven problematic on UNIX hosts. Users that keep some "/bin" directories in the "PATH" just for their tools do not necessarily want any supporting "/lib" directories searched. One may set the "CMAKE_PREFIX_PATH" environment variable with a ;-list of prefixes that are to be searched. * The "Visual Studio 7 .NET 2003" generator is now deprecated and will be removed in a future version of CMake. * The "Visual Studio 7" generator (for VS .NET 2002) has been removed. It had been deprecated since CMake 3.3. * The "Visual Studio 6" generator has been removed. It had been deprecated since CMake 3.3. Other Changes ============= * The precompiled OS X binary provided on "cmake.org" now requires OS X 10.7 or newer. * On Linux and FreeBSD platforms, when building CMake itself from source and not using a system-provided libcurl, OpenSSL is now used by default if it is found on the system. This enables SSL/TLS support for commands supporting network communication via "https", such as "file(DOWNLOAD)", "file(UPLOAD)", and "ctest_submit()". * The "cmake(1)" "--build" command-line tool now rejects multiple "-- target" options with an error instead of silently ignoring all but the last one. * "AUTOMOC" now diagnoses name collisions when multiple source files in different directories use "#include " with the same name (because the generated "moc_foo.cpp" files would collide). * The "FindBISON" module "BISON_TARGET" macro now supports special characters by passing the "VERBATIM" option to internal "add_custom_command()" calls. This may break clients that added escaping manually to work around the bug. * The "FindFLEX" module "FLEX_TARGET" macro now supports special characters by passing the "VERBATIM" option to internal "add_custom_command()" calls. This may break clients that added escaping manually to work around the bug. * The "FindProtobuf" module input and output variables were all renamed from "PROTOBUF_" to "Protobuf_" for consistency with other find modules. Input variables of the old case will be honored if provided, and output variables of the old case are always provided. * The "CPackRPM" module now supports upper cased component names in per component CPackRPM specific variables. E.g. component named "foo" now expects component specific variable to be "CPACK_RPM_FOO_PACKAGE_NAME" while before it expected "CPACK_RPM_foo_PACKAGE_NAME". Upper cased component name part in variables is compatible with convention used for other CPack variables. For back compatibility old format of variables is still valid and preferred if both versions of variable are set, but the preferred future use is upper cased component names in variables. New variables that will be added to CPackRPM in later versions will only support upper cased component variable format. ---------------------------------------------------------------------------- Changes made since CMake 3.6.0-rc1: Brad King (4): libarchive: Restore OpenSSL include directory from upstream Help: Document ctest_update branch following behavior Help: Document CTest Git fetch-and-reset behavior CMake 3.6.0-rc2 Eric NOULARD (4): bash-completion: Add cmake --help-manual bash-completion: Fix cmake --help-policy lookup bash-completion: Add ctest --help-{manual,module,policy,property,variable} bash-completion: Add cpack --help-{manual,module,policy,property} Expat Upstream (1): expat 2016-06-05 (2b9cb7f5) Micha? G?rny (1): Platform: add flag definitions for PathScale compiler on SunOS (#16135) Orion Poplawski (1): FindLibArchive: Support libarchive 3.2 version string format Robert Maynard (1): cmake-gui: Teach Qt5 where plugins are when launched through a symlink From brad.king at kitware.com Mon Jun 13 15:12:56 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 13 Jun 2016 15:12:56 -0400 Subject: [CMake] [cmake-developers] Problems when generating xcarchive from within Xcode In-Reply-To: <38A15792-E147-439A-AFDB-7580DEF05154@gmx.at> References: <38A15792-E147-439A-AFDB-7580DEF05154@gmx.at> Message-ID: <575F05B8.1070301@kitware.com> On 06/13/2016 02:58 PM, Roman W?ger wrote: > I have successfully configured a project with CMake 3.5.2 so it > creates a valid Release and Debug *.app bundle which runs on iOS. > However if I build an archive in Xcode with "Product->Archive" > then the app bundle seems not complete under > ~/Library/Developer/Xcode/Archives/YYY-MM-DD/*.xcarchive > > For example the Info.plist is not the same as in the Release > folder, subfolders and some files are not copied/created. > > Did I need something special for this (the archive)? Possibly related issues: https://gitlab.kitware.com/cmake/cmake/issues/12640 https://gitlab.kitware.com/cmake/cmake/issues/15183 -Brad From cedric.doucet at inria.fr Tue Jun 14 06:28:46 2016 From: cedric.doucet at inria.fr (Cedric Doucet) Date: Tue, 14 Jun 2016 12:28:46 +0200 (CEST) Subject: [CMake] Provide configuration settings for users In-Reply-To: <583065834.20027052.1465899641841.JavaMail.zimbra@inria.fr> Message-ID: <411701068.20030789.1465900126927.JavaMail.zimbra@inria.fr> Hello, is there a native way to provide configuration settings for the users of a software? For example, I develop a software which depends on several 3rd party libraries which are automatically downloaded and installed with the ExternalProject module. My CMake configuration scripts are written so as to handle these 3rd party libraries. During installation of the software, header files and libraries are copied to the destination directory but (of course) without their 3rd party dependencies. Therefore, if a user wants to use my software, he has to handle these 3rd party libraries during compilation and linking steps. Depending on the skills of the user, it may be difficult to achieve it. I would like to know if there exists a native way of providing sufficient configuration information so that users do not have to handle these libraries. For the moment, I provide a CMakeLists template but I wonder if it's the best possible solution. Best regards, C?dric Doucet -------------- next part -------------- An HTML attachment was scrubbed... URL: From chuck.atkins at kitware.com Tue Jun 14 09:51:45 2016 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Tue, 14 Jun 2016 09:51:45 -0400 Subject: [CMake] Provide configuration settings for users In-Reply-To: <411701068.20030789.1465900126927.JavaMail.zimbra@inria.fr> References: <583065834.20027052.1465899641841.JavaMail.zimbra@inria.fr> <411701068.20030789.1465900126927.JavaMail.zimbra@inria.fr> Message-ID: Hi Cedric, It sounds like creating a package config file is exactly what you need. When installed, a user will be able to consume your project with "find_package(Foo)". That will locate and read the package config file which will create an imported target Foo::Foo. This imported target will cary with it all of the necessary link dependency information. See https://cmake.org/cmake/help/v3.6/manual/cmake-packages.7.html for more details. - Chuck On Tue, Jun 14, 2016 at 6:28 AM, Cedric Doucet wrote: > > Hello, > > is there a native way to provide configuration settings for the users of a > software? > > For example, I develop a software which depends on several 3rd party > libraries which are automatically downloaded and installed with the > ExternalProject module. > My CMake configuration scripts are written so as to handle these 3rd party > libraries. > During installation of the software, header files and libraries are copied > to the destination directory but (of course) without their 3rd party > dependencies. > > Therefore, if a user wants to use my software, he has to handle these 3rd > party libraries during compilation and linking steps. > Depending on the skills of the user, it may be difficult to achieve it. > > I would like to know if there exists a native way of providing sufficient > configuration information so that users do not have to handle these > libraries. > For the moment, I provide a CMakeLists template but I wonder if it's the > best possible solution. > > Best regards, > > C?dric Doucet > > -- > > 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 elizabeth.fischer at columbia.edu Tue Jun 14 10:09:06 2016 From: elizabeth.fischer at columbia.edu (Elizabeth A. Fischer) Date: Tue, 14 Jun 2016 10:09:06 -0400 Subject: [CMake] Provide configuration settings for users In-Reply-To: <411701068.20030789.1465900126927.JavaMail.zimbra@inria.fr> References: <583065834.20027052.1465899641841.JavaMail.zimbra@inria.fr> <411701068.20030789.1465900126927.JavaMail.zimbra@inria.fr> Message-ID: Cedric, I would highly recommend an auto-builder such as Spack as a good way to have a system that automatically downloads and installs dependencies for your software. My software requires about 50 dependencies (once recursive dependencies are counted), and I've successfully used Spack to have others install it. See instructions for installing my software stack using Spack at: https://github.com/citibeth/icebin (Most of these instructions are for bootstrapping Spack on old machines, and not directly for my particular software). This approach is a lot easier for you and your users, and more flexible to boot: 1. You don't have to deal with advanced/esoteric features like ExternalProject, CMakeList templates, etc. 2. It doesn't matter what build system your dependencies were written with. (I've heard of people writing CMake builds for all their dependencies. As much as I like CMake, that seems like a painful way to proceed). 3. Consider what would happen if every project used ExternalProject for its dependencies: we'd be unable to link projects together as soon as they share a sub-dependency, since every project would be building its own. You really want to build a coherent software DAG (Directed Acyclic Graph) at a level ABOVE the single-project level, in order to avoid duplicate / conflicting packages in your build. For that reason, the project-building level (CMake) is fundamentally the wrong place to do this. It should be done by auto-builders on top of the project level (Spack, EasyBuild, MacPorts, Gentoo Portage, etc). -- Elizabeth On Tue, Jun 14, 2016 at 6:28 AM, Cedric Doucet wrote: > > Hello, > > is there a native way to provide configuration settings for the users of a > software? > > For example, I develop a software which depends on several 3rd party > libraries which are automatically downloaded and installed with the > ExternalProject module. > My CMake configuration scripts are written so as to handle these 3rd party > libraries. > During installation of the software, header files and libraries are copied > to the destination directory but (of course) without their 3rd party > dependencies. > > Therefore, if a user wants to use my software, he has to handle these 3rd > party libraries during compilation and linking steps. > Depending on the skills of the user, it may be difficult to achieve it. > > I would like to know if there exists a native way of providing sufficient > configuration information so that users do not have to handle these > libraries. > For the moment, I provide a CMakeLists template but I wonder if it's the > best possible solution. > > Best regards, > > C?dric Doucet > > -- > > 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 fifteenknots505 at gmail.com Tue Jun 14 14:21:40 2016 From: fifteenknots505 at gmail.com (Martin Weber) Date: Tue, 14 Jun 2016 20:21:40 +0200 Subject: [CMake] CMAKE - troubles finding executables/paths - Windows 7 / MinGW Message-ID: <2622639.aepvOh1Cc6@linux> Yes, I know this [1] thread is old, but it hurts me, too. This is what I found: The mingw32 installer (mingw32-get, IIRC) no longer places a key in the windows registry. So if anyone installed mingw32 in a directory other than c:/MinGW/, cmake will not find it. After adding the bin directory of the mingw install location to %PATH%, cmake will detect mingw32-make, but it will complain saying 'the compiler is not able to build a single program'. This happens because cc1.exe (which is *not* in the bin directory) cannot find the DLLs located in the bin directory. You have to manually copy the DLLs to the directory containing cc1.exe. Maybe someone finds this useful. Martin [1] https://cmake.org/pipermail/cmake/2011-May/044637.html -- Cd wrttn wtht vwls s mch trsr. From eldlistmailingz at tropicsoft.com Tue Jun 14 20:28:15 2016 From: eldlistmailingz at tropicsoft.com (Edward Diener) Date: Tue, 14 Jun 2016 20:28:15 -0400 Subject: [CMake] Finding libxml2 when building llvm/clang Message-ID: Building llvm/clang from source involves using CMake. I am building llvm/clang from source on Windows using CMake 3.5.2. I am not a clang developer, just a clang user. Similarly I just use CMake rather than understand or write CMakeLists.txt files. I reported a problem to clang where building a 32-bit version of clang succeeds but building a 64-bit version of clang fails with xml link errors. I have A 32-bit libxml2 binary in my path from gnuwin32, but not a 64-bit binary of libxml2 in my path. I was told by clang developers that one of the tools which clang builds uses xml and libxml2 if it is available, otherwise uses some other technology for the tool. The suggestion was that the problem I am encountering is that of CMake; that CMake does not recognize that the libxml2 which I have is the 32-bit version and instead thinks that it is the 64-bit version and therefore attempts erroneously to use it in the 64-bit build of clang. Does anybody know what might be happening here ? I do not create the CMakeLists.txt files used by llvm/clang so I do not know how the use of libxml2 can be optionally specified in them. From patrick.boettcher at posteo.de Wed Jun 15 01:50:58 2016 From: patrick.boettcher at posteo.de (Patrick Boettcher) Date: Wed, 15 Jun 2016 07:50:58 +0200 Subject: [CMake] GCC: -std=g++14 vs -std=c++14 In-Reply-To: <20160613200523.1edc761c@vdr> References: <20160613113620.0eb4f713@posteo.de> <575EE21B.7030809@gmail.com> <20160613200523.1edc761c@vdr> Message-ID: <20160615075058.3e20ce4a@posteo.de> On Mon, 13 Jun 2016 20:05:23 +0200 Patrick Boettcher wrote: > > You also need to correctly set the CXX_EXTENSIONS properties to get > > a standard standard. > > Yep, > > set(CXX_EXTENSIONS OFF) > > seems to do the trick - thanks. Well, it is set(CMAKE_CXX_EXTENSIONS OFF) actually. Before the target-definition (add_library or add_executable). -- Patrick. From chuck.atkins at kitware.com Wed Jun 15 09:15:45 2016 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Wed, 15 Jun 2016 09:15:45 -0400 Subject: [CMake] Finding libxml2 when building llvm/clang In-Reply-To: References: Message-ID: You could try to force libxml to be ignored by CMake so it will think it wasn't found and use the fallback configuration: cmake ... -DLIBXML2_LIBRARIES=IGNORE ... - Chuck On Tue, Jun 14, 2016 at 8:28 PM, Edward Diener < eldlistmailingz at tropicsoft.com> wrote: > Building llvm/clang from source involves using CMake. I am building > llvm/clang from source on Windows using CMake 3.5.2. I am not a clang > developer, just a clang user. Similarly I just use CMake rather than > understand or write CMakeLists.txt files. > > I reported a problem to clang where building a 32-bit version of clang > succeeds but building a 64-bit version of clang fails with xml link errors. > I have A 32-bit libxml2 binary in my path from gnuwin32, but not a 64-bit > binary of libxml2 in my path. > > I was told by clang developers that one of the tools which clang builds > uses xml and libxml2 if it is available, otherwise uses some other > technology for the tool. The suggestion was that the problem I am > encountering is that of CMake; that CMake does not recognize that the > libxml2 which I have is the 32-bit version and instead thinks that it is > the 64-bit version and therefore attempts erroneously to use it in the > 64-bit build of clang. > > Does anybody know what might be happening here ? I do not create the > CMakeLists.txt files used by llvm/clang so I do not know how the use of > libxml2 can be optionally specified in them. > > -- > > 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 eldlistmailingz at tropicsoft.com Wed Jun 15 09:40:07 2016 From: eldlistmailingz at tropicsoft.com (Edward Diener) Date: Wed, 15 Jun 2016 09:40:07 -0400 Subject: [CMake] Finding libxml2 when building llvm/clang In-Reply-To: References: Message-ID: On 6/15/2016 9:15 AM, Chuck Atkins wrote: > You could try to force libxml to be ignored by CMake so it will think it > wasn't found and use the fallback configuration: > > cmake ... -DLIBXML2_LIBRARIES=IGNORE ... I will try that, thanks ! But shouldn't CMake be able to distinguish between a 32-bit and a 64-bit version of a library when 'find_package(some_library)' is specified ? > > - Chuck > > On Tue, Jun 14, 2016 at 8:28 PM, Edward Diener > > wrote: > > Building llvm/clang from source involves using CMake. I am building > llvm/clang from source on Windows using CMake 3.5.2. I am not a > clang developer, just a clang user. Similarly I just use CMake > rather than understand or write CMakeLists.txt files. > > I reported a problem to clang where building a 32-bit version of > clang succeeds but building a 64-bit version of clang fails with xml > link errors. I have A 32-bit libxml2 binary in my path from > gnuwin32, but not a 64-bit binary of libxml2 in my path. > > I was told by clang developers that one of the tools which clang > builds uses xml and libxml2 if it is available, otherwise uses some > other technology for the tool. The suggestion was that the problem I > am encountering is that of CMake; that CMake does not recognize that > the libxml2 which I have is the 32-bit version and instead thinks > that it is the 64-bit version and therefore attempts erroneously to > use it in the 64-bit build of clang. > > Does anybody know what might be happening here ? I do not create the > CMakeLists.txt files used by llvm/clang so I do not know how the use > of libxml2 can be optionally specified in them. From elizabeth.fischer at columbia.edu Wed Jun 15 10:50:13 2016 From: elizabeth.fischer at columbia.edu (Elizabeth A. Fischer) Date: Wed, 15 Jun 2016 10:50:13 -0400 Subject: [CMake] GCC: -std=g++14 vs -std=c++14 In-Reply-To: <20160615075058.3e20ce4a@posteo.de> References: <20160613113620.0eb4f713@posteo.de> <575EE21B.7030809@gmail.com> <20160613200523.1edc761c@vdr> <20160615075058.3e20ce4a@posteo.de> Message-ID: Why are these extensions not turned off by default? Normally, things should conform to the standards out-of-the-box; and you should have to explicitly enable extensions. Following that principle would have avoided this entire thread. -- Elizabeth On Wed, Jun 15, 2016 at 1:50 AM, Patrick Boettcher < patrick.boettcher at posteo.de> wrote: > On Mon, 13 Jun 2016 20:05:23 +0200 > Patrick Boettcher wrote: > > > You also need to correctly set the CXX_EXTENSIONS properties to get > > > a standard standard. > > > > Yep, > > > > set(CXX_EXTENSIONS OFF) > > > > seems to do the trick - thanks. > > Well, it is > > set(CMAKE_CXX_EXTENSIONS OFF) > > actually. Before the target-definition (add_library or add_executable). > > > -- > Patrick. > -- > > 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 patrick.boettcher at posteo.de Wed Jun 15 11:00:00 2016 From: patrick.boettcher at posteo.de (Patrick Boettcher) Date: Wed, 15 Jun 2016 17:00:00 +0200 Subject: [CMake] GCC: -std=g++14 vs -std=c++14 In-Reply-To: References: <20160613113620.0eb4f713@posteo.de> <575EE21B.7030809@gmail.com> <20160613200523.1edc761c@vdr> <20160615075058.3e20ce4a@posteo.de> Message-ID: <20160615170000.1bf019f8@posteo.de> On Wed, 15 Jun 2016 10:50:13 -0400 "Elizabeth A. Fischer" wrote: > Why are these extensions not turned off by default? Normally, things > should conform to the standards out-of-the-box; and you should have to > explicitly enable extensions. Following that principle would have > avoided this entire thread. Well, I'd not be surprised if the expected standard for gcc users is --std=gnu++14 instead of --std=c++14 . That could be a good explanation. regards, -- Patrick. From robert.maynard at kitware.com Wed Jun 15 11:48:52 2016 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 15 Jun 2016 11:48:52 -0400 Subject: [CMake] GCC: -std=g++14 vs -std=c++14 In-Reply-To: <20160615170000.1bf019f8@posteo.de> References: <20160613113620.0eb4f713@posteo.de> <575EE21B.7030809@gmail.com> <20160613200523.1edc761c@vdr> <20160615075058.3e20ce4a@posteo.de> <20160615170000.1bf019f8@posteo.de> Message-ID: This is correct. The default for GCC has always been to enable gcc extensions, with GCC < 6 having a default of gnu++98, and GCC 6 having a default of gnu++14 On Wed, Jun 15, 2016 at 11:00 AM, Patrick Boettcher wrote: > On Wed, 15 Jun 2016 10:50:13 -0400 > "Elizabeth A. Fischer" wrote: > >> Why are these extensions not turned off by default? Normally, things >> should conform to the standards out-of-the-box; and you should have to >> explicitly enable extensions. Following that principle would have >> avoided this entire thread. > > Well, I'd not be surprised if the expected standard for gcc users is > --std=gnu++14 instead of --std=c++14 . That could be a good explanation. > > regards, > -- > Patrick. > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From elizabeth.fischer at columbia.edu Wed Jun 15 12:18:36 2016 From: elizabeth.fischer at columbia.edu (Elizabeth A. Fischer) Date: Wed, 15 Jun 2016 12:18:36 -0400 Subject: [CMake] GCC: -std=g++14 vs -std=c++14 In-Reply-To: References: <20160613113620.0eb4f713@posteo.de> <575EE21B.7030809@gmail.com> <20160613200523.1edc761c@vdr> <20160615075058.3e20ce4a@posteo.de> <20160615170000.1bf019f8@posteo.de> Message-ID: That seems wrong to me. Regardless of how proud the compiler makers are of their extensions, the language you're using should depend as little as possible (by default) on the compiler you choose. -- Elizabeth On Wed, Jun 15, 2016 at 11:48 AM, Robert Maynard wrote: > This is correct. The default for GCC has always been to enable gcc > extensions, with GCC < 6 having a default of gnu++98, and GCC 6 having > a default of gnu++14 > > On Wed, Jun 15, 2016 at 11:00 AM, Patrick Boettcher > wrote: > > On Wed, 15 Jun 2016 10:50:13 -0400 > > "Elizabeth A. Fischer" wrote: > > > >> Why are these extensions not turned off by default? Normally, things > >> should conform to the standards out-of-the-box; and you should have to > >> explicitly enable extensions. Following that principle would have > >> avoided this entire thread. > > > > Well, I'd not be surprised if the expected standard for gcc users is > > --std=gnu++14 instead of --std=c++14 . That could be a good explanation. > > > > regards, > > -- > > Patrick. > > -- > > > > 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 welson.sun at gmail.com Wed Jun 15 14:43:01 2016 From: welson.sun at gmail.com (Welson Sun) Date: Wed, 15 Jun 2016 11:43:01 -0700 Subject: [CMake] cmake targeting vs2015 error Message-ID: cmake 3.4.3 on windows 7 targeting vs2015 error out: cl : Command line error D8021: invalid numeric argument '/Wno-variadic-macros' Thanks, Welson -------------- next part -------------- An HTML attachment was scrubbed... URL: From kristianonline28 at gmail.com Wed Jun 15 16:36:56 2016 From: kristianonline28 at gmail.com (Kristian) Date: Wed, 15 Jun 2016 16:36:56 -0400 Subject: [CMake] cmake targeting vs2015 error In-Reply-To: References: Message-ID: Could you give us either the CMakeLists.txt or the whole cl command, which was called? Without of some more information, I could not give you a hint, where the problem is. 2016-06-15 14:43 GMT-04:00 Welson Sun : > cmake 3.4.3 on windows 7 targeting vs2015 error out: > > cl : Command line error D8021: invalid numeric argument > '/Wno-variadic-macros' > > > Thanks, > Welson > > -- > > 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 afe.young at gmail.com Wed Jun 15 22:11:40 2016 From: afe.young at gmail.com (Young Yang) Date: Thu, 16 Jun 2016 10:11:40 +0800 Subject: [CMake] cmake install target doesn't run ldconfig after installing library Message-ID: Hi, I've encountered some problem when writing install target with cmake. I use `install (TARGETS DESTINATION lib)` to install my shared_library. However, when I run `make install`. It just install the .so to /usr/local/lib and didn't run the ldconfig. I think it is strange and inconvenient to tell the user he should run ldconfig by himself or herself. What is the best way to make the ldconfig run automatically? Thanks in advance :) -- Best wishes, Young Yang -------------- next part -------------- An HTML attachment was scrubbed... URL: From Dvir.Yitzchaki at ceva-dsp.com Thu Jun 16 02:54:29 2016 From: Dvir.Yitzchaki at ceva-dsp.com (Dvir Yitzchaki) Date: Thu, 16 Jun 2016 06:54:29 +0000 Subject: [CMake] Target has dependency information when it shouldn't Message-ID: <71350F7ED6EBB54AA2D182B26086A1B60114AB4070@ILMAIL1.corp.local> Hi group. I use CMake 3.3.1 with Visual Studio 2013. I've changed a target from a static library to an INTERFACE library and now I get the following message from CMake: CUSTOMBUILD : CMake error : Target <...> has dependency information when it shouldn't. Your cache is probably stale. Please remove the entry <...>_LIB_DEPENDS If I remove this entry from CMakeCache.txt manually everything works. My question is why can't CMake do it for me as it obviously knows what to do. Thanks, Dvir -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkeeler at tenable.com Thu Jun 16 09:02:17 2016 From: mkeeler at tenable.com (Matthew Keeler) Date: Thu, 16 Jun 2016 16:02:17 +0300 Subject: [CMake] cmake install target doesn't run ldconfig after installing library In-Reply-To: References: Message-ID: CMake won?t and in my opinion shouldn?t implicitly invoke ldconfig for you. There are many scenarios and platforms where this is incorrect behavior and some such as running install to prepare for packaging that CMake wouldn?t reliably be able to detect. If you want to provide the functionality for your users you could add something like the following to your CMakeLists.txt: install(CODE ?execute_process(COMMAND ldconfig)?) This will need to run after your other installed targets. I can?t find any way in the CMake documentation to force install ordering but it seems like as long as CMake processes that install command last it will perform it last. So at the very end of your top level CMakeLists.txt file should do the trick. -- Matt Keeler On June 15, 2016 at 22:12:09, Young Yang (afe.young at gmail.com) wrote: Hi, I've encountered some problem when writing install target with cmake. I use `install (TARGETS DESTINATION lib)` to install my shared_library. However, when I run `make install`. It just install the .so to /usr/local/lib and didn't run the ldconfig. I think it is strange and inconvenient to tell the user he should run ldconfig by himself or herself. What is the best way to make the ldconfig run automatically? Thanks in advance :) -- Best wishes, Young Yang -- 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 zbeekman at gmail.com Thu Jun 16 11:14:20 2016 From: zbeekman at gmail.com (Zaak Beekman) Date: Thu, 16 Jun 2016 15:14:20 +0000 Subject: [CMake] oversubscribing OpenMPI in tests Message-ID: Does anyone know a good way to determine if `find_package(MPI REQUIRED)` is returning OpenMPI? I need to know, because OpenMPI does not handle oversubscribed (more ranks than cores) tests well without explicitly telling OpenMPI that you are oversubscribing. This can be done by creating a hosts file, and passing some flags to `mpirun` to tell it to use the hosts file, or can be accomplished by passing the `--oversubscribe` flag. The problem is that MPICH has different flags/host-file syntax. (I am oversubscribing some of the project's tests because this will often find correctness problems due to race conditions or other parallel programming errors that are not always exposed otherwise.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From howard.rubin at hl.konicaminolta.us Thu Jun 16 11:13:01 2016 From: howard.rubin at hl.konicaminolta.us (Howard Rubin) Date: Thu, 16 Jun 2016 09:13:01 -0600 Subject: [CMake] What do these CMake error messages mean? Message-ID: <008901d1c7e1$92c1f9d0$b845ed70$@hl.konicaminolta.us> CMake is giving many error messages like the below since we added OpenCV 3.1.0 to our project (and we need that new version). Can anyone help me understand what do about it and/or what the error messages are telling me? None of the 3 hits for this google search were helpful: opencv cmake "which is prefixed in the" - Howard Rubin ======== Error messages ============================================================== : : Configuring done CMake Error in 3rdparty/opencv-3.1.0/modules/core/CMakeLists.txt: Target "opencv_core" INTERFACE_INCLUDE_DIRECTORIES property contains path: "D:/shared/projects/magellan-build-windows" which is prefixed in the build directory. CMake Error in 3rdparty/opencv-3.1.0/modules/core/CMakeLists.txt: Target "opencv_core" INTERFACE_INCLUDE_DIRECTORIES property contains path: "D:/shared/projects/magellan/3rdparty/opencv-3.1.0/include" which is prefixed in the source directory. : : ======== The referenced 3rdparty/opencv-3.1.0/modules/core/CMakeLists.txt ================= set(the_description "The Core Functionality") ocv_add_module(core PRIVATE_REQUIRED ${ZLIB_LIBRARIES} "${OPENCL_LIBRARIES}" "${VA_LIBRARIES}" OPTIONAL opencv_cudev WRAP java python) set(extra_libs "") if(WINRT AND CMAKE_SYSTEM_NAME MATCHES WindowsStore AND CMAKE_SYSTEM_VERSION MATCHES "8.0") list(APPEND extra_libs ole32.lib) endif() if(DEFINED WINRT AND NOT DEFINED ENABLE_WINRT_MODE_NATIVE) set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /ZW") endif() if(HAVE_CUDA) ocv_warnings_disable(CMAKE_CXX_FLAGS -Wundef -Wenum-compare -Wunused-function -Wshadow) endif() file(GLOB lib_cuda_hdrs "include/opencv2/${name}/cuda/*.hpp" "include/opencv2/${name}/cuda/*.h") file(GLOB lib_cuda_hdrs_detail "include/opencv2/${name}/cuda/detail/*.hpp" "include/opencv2/${name}/cuda/detail/*.h") source_group("Cuda Headers" FILES ${lib_cuda_hdrs}) source_group("Cuda Headers\\Detail" FILES ${lib_cuda_hdrs_detail}) ocv_glob_module_sources(SOURCES "${OPENCV_MODULE_opencv_core_BINARY_DIR}/version_string.inc" HEADERS ${lib_cuda_hdrs} ${lib_cuda_hdrs_detail}) ocv_module_include_directories(${the_module} ${ZLIB_INCLUDE_DIRS}) ocv_create_module(${extra_libs}) ocv_add_accuracy_tests() ocv_add_perf_tests() -------------- next part -------------- An HTML attachment was scrubbed... URL: From welson.sun at gmail.com Thu Jun 16 12:57:40 2016 From: welson.sun at gmail.com (Welson Sun) Date: Thu, 16 Jun 2016 09:57:40 -0700 Subject: [CMake] cmake targeting vs2015 error In-Reply-To: References: Message-ID: Update: I tried cmake 3.5.2, and that worked fine. BTW, I am trying to compile llvm+clang 3.5 with VS2015. On Wed, Jun 15, 2016 at 1:36 PM, Kristian wrote: > Could you give us either the CMakeLists.txt or the whole cl command, which > was called? > > Without of some more information, I could not give you a hint, where the > problem is. > > 2016-06-15 14:43 GMT-04:00 Welson Sun : > >> cmake 3.4.3 on windows 7 targeting vs2015 error out: >> >> cl : Command line error D8021: invalid numeric argument >> '/Wno-variadic-macros' >> >> >> Thanks, >> Welson >> >> -- >> >> 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 >> > > -- - Welson -------------- next part -------------- An HTML attachment was scrubbed... URL: From kgt at lanl.gov Thu Jun 16 16:45:33 2016 From: kgt at lanl.gov (Thompson, KT) Date: Thu, 16 Jun 2016 20:45:33 +0000 Subject: [CMake] oversubscribing OpenMPI in tests In-Reply-To: References: Message-ID: Zaak, I use ?execute_process (${MPIEXEC} --version)? and match the output to a string (Open MPI, ALPS, MPICH). This isn?t the most elegant solution, but it seems fairly robust. -kt From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Zaak Beekman Sent: Thursday, June 16, 2016 9:14 AM To: cmake at cmake.org Subject: [CMake] oversubscribing OpenMPI in tests Does anyone know a good way to determine if `find_package(MPI REQUIRED)` is returning OpenMPI? I need to know, because OpenMPI does not handle oversubscribed (more ranks than cores) tests well without explicitly telling OpenMPI that you are oversubscribing. This can be done by creating a hosts file, and passing some flags to `mpirun` to tell it to use the hosts file, or can be accomplished by passing the `--oversubscribe` flag. The problem is that MPICH has different flags/host-file syntax. (I am oversubscribing some of the project's tests because this will often find correctness problems due to race conditions or other parallel programming errors that are not always exposed otherwise.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From zbeekman at gmail.com Thu Jun 16 20:31:55 2016 From: zbeekman at gmail.com (Zaak Beekman) Date: Fri, 17 Jun 2016 00:31:55 +0000 Subject: [CMake] oversubscribing OpenMPI in tests In-Reply-To: References: Message-ID: Excellent, this is far better than any of the approaches I had thought of... cheers! On Thu, Jun 16, 2016 at 4:45 PM Thompson, KT wrote: > Zaak, > > > > I use ?execute_process (${MPIEXEC} --version)? and match the output to a > string (Open MPI, ALPS, MPICH). This isn?t the most elegant solution, but > it seems fairly robust. > > > > -kt > > > > *From:* CMake [mailto:cmake-bounces at cmake.org] *On Behalf Of *Zaak Beekman > *Sent:* Thursday, June 16, 2016 9:14 AM > *To:* cmake at cmake.org > *Subject:* [CMake] oversubscribing OpenMPI in tests > > > > Does anyone know a good way to determine if `find_package(MPI REQUIRED)` > is returning OpenMPI? I need to know, because OpenMPI does not handle > oversubscribed (more ranks than cores) tests well without explicitly > telling OpenMPI that you are oversubscribing. This can be done by creating > a hosts file, and passing some flags to `mpirun` to tell it to use the > hosts file, or can be accomplished by passing the `--oversubscribe` flag. > The problem is that MPICH has different flags/host-file syntax. > > > > (I am oversubscribing some of the project's tests because this will often > find correctness problems due to race conditions or other parallel > programming errors that are not always exposed otherwise.) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From afe.young at gmail.com Thu Jun 16 21:01:26 2016 From: afe.young at gmail.com (Young Yang) Date: Fri, 17 Jun 2016 09:01:26 +0800 Subject: [CMake] cmake install target doesn't run ldconfig after installing library In-Reply-To: References: Message-ID: Thanks! This command really solve my problem. But I still get a problem about the command order now. I have some sub directories. For e.g. One of them is called "src" and there is also a CMakeLists.txt in it. And the shared library installation instructions are in it. So I have `ADD_SUBDIRECTORY(src)` in my main CMakeLists.txt. I put the command `install(CODE "execute_process(COMMAND ldconfig)")` after `ADD_SUBDIRECTORY(src)` . But It still run ldconfig before the installation of shared libraries in src sub folder. On Thu, Jun 16, 2016 at 9:02 PM, Matthew Keeler wrote: > CMake won?t and in my opinion shouldn?t implicitly invoke ldconfig for > you. There are many scenarios and platforms where this is incorrect > behavior and some such as running install to prepare for packaging that > CMake wouldn?t reliably be able to detect. > > If you want to provide the functionality for your users you could add > something like the following to your CMakeLists.txt: > > install(CODE ?execute_process(COMMAND ldconfig)?) > > This will need to run after your other installed targets. I can?t find any > way in the CMake documentation to force install ordering but it seems like > as long as CMake processes that install command last it will perform it > last. So at the very end of your top level CMakeLists.txt file should do > the trick. > > -- > Matt Keeler > > > On June 15, 2016 at 22:12:09, Young Yang (afe.young at gmail.com) wrote: > > Hi, > I've encountered some problem when writing install target with cmake. > > I use `install (TARGETS DESTINATION lib)` to install > my shared_library. > However, when I run `make install`. It just install the .so to > /usr/local/lib and didn't run the ldconfig. > > I think it is strange and inconvenient to tell the user he should run > ldconfig by himself or herself. > > What is the best way to make the ldconfig run automatically? > > > Thanks in advance :) > > -- > Best wishes, > Young Yang > -- > > 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 > > -- Best wishes, Young Yang -------------- next part -------------- An HTML attachment was scrubbed... URL: From tiagomacarios at gmail.com Thu Jun 16 23:56:39 2016 From: tiagomacarios at gmail.com (Tiago Macarios) Date: Thu, 16 Jun 2016 20:56:39 -0700 Subject: [CMake] QT + CMake + Visual Studio = ui files refresh Message-ID: Hi, I am currently using QT + CMake + Visual Studio and everything works great. Problem I am having is that if I change a .ui file Visual Studio does not seem to capture that during the build. If I just "touch" the header file, them everything works fine (moc gets triggered). Is there a way to set this up so that the ui file change also gets detected? I tried simply adding the ui file to the target, but this does not seem to work... Tiago -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkeeler at tenable.com Fri Jun 17 09:07:14 2016 From: mkeeler at tenable.com (Matthew Keeler) Date: Fri, 17 Jun 2016 09:07:14 -0400 Subject: [CMake] cmake install target doesn't run ldconfig after installing library In-Reply-To: References: Message-ID: So I did some experimenting. It would seem there are a few rules to the order installs are executed 1 - installs are processed in the order the containing CMakeLists.txt files are 2 - within a CMakeLists.txt they seem to be ordered based on which comes first in the file. So a not so elegant workaround would be to create a post-install directory in your source tree and have the last line of your main CMakeLists.txt be to add_subdirectory(post-install). Then all your post-install logic can live in there. -- Matt Keeler On June 16, 2016 at 21:01:46, Young Yang (afe.young at gmail.com) wrote: Thanks! This command really solve my problem. But I still get a problem about the command order now. I have some sub directories. For e.g. One of them is called "src" and there is also a CMakeLists.txt in it. And the shared library installation instructions are in it. So I have `ADD_SUBDIRECTORY(src)` in my main CMakeLists.txt. I put the command `install(CODE "execute_process(COMMAND ldconfig)")` after `ADD_SUBDIRECTORY(src)` . But It still run ldconfig before the installation of shared libraries in src sub folder. On Thu, Jun 16, 2016 at 9:02 PM, Matthew Keeler wrote: > CMake won?t and in my opinion shouldn?t implicitly invoke ldconfig for > you. There are many scenarios and platforms where this is incorrect > behavior and some such as running install to prepare for packaging that > CMake wouldn?t reliably be able to detect. > > If you want to provide the functionality for your users you could add > something like the following to your CMakeLists.txt: > > install(CODE ?execute_process(COMMAND ldconfig)?) > > This will need to run after your other installed targets. I can?t find any > way in the CMake documentation to force install ordering but it seems like > as long as CMake processes that install command last it will perform it > last. So at the very end of your top level CMakeLists.txt file should do > the trick. > > -- > Matt Keeler > > > On June 15, 2016 at 22:12:09, Young Yang (afe.young at gmail.com) wrote: > > Hi, > I've encountered some problem when writing install target with cmake. > > I use `install (TARGETS DESTINATION lib)` to install > my shared_library. > However, when I run `make install`. It just install the .so to > /usr/local/lib and didn't run the ldconfig. > > I think it is strange and inconvenient to tell the user he should run > ldconfig by himself or herself. > > What is the best way to make the ldconfig run automatically? > > > Thanks in advance :) > > -- > Best wishes, > Young Yang > -- > > 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 > > -- Best wishes, Young Yang -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergey.nikulov at gmail.com Fri Jun 17 10:39:01 2016 From: sergey.nikulov at gmail.com (Sergei Nikulov) Date: Fri, 17 Jun 2016 17:39:01 +0300 Subject: [CMake] Question about CHECK_C_COMPILER_FLAG Message-ID: Hi All, I have a question about CHECK_C_COMPILER_FLAG behaviour. Documentation will tell that "the compiler does not give an error message when it encounters the flag". Unfortunately, it not only compiles but try to link executable. If linker fails, due missed libraries it also does not produce positive result even if compilation was successful. Is it expected behaviour or issue? My example environment cmake v3.4.3/Linux/gcc v4.8.5 check_c_compiler_flag("-fsanitize=address" HAVE_C_FLAG_asan) Log in CMakeError.log ... erforming C SOURCE FILE Test HAVE_C_FLAG_asan failed with the following output: Change Dir: /home/snikulov/work/github/curl/build/CMakeFiles/CMakeTmp Run Build Command:"/usr/bin/gmake" "cmTC_846be/fast" /usr/bin/gmake -f CMakeFiles/cmTC_846be.dir/build.make CMakeFiles/cmTC_846be.dir/build gmake[1]: Entering directory `/home/snikulov/work/github/curl/build/CMakeFiles/CMakeTmp' Building C object CMakeFiles/cmTC_846be.dir/src.c.o /usr/bin/cc -DHAVE_C_FLAG_asan -fsanitize=address -o CMakeFiles/cmTC_846be.dir/src.c.o -c /home/snikulov/work/github/curl/build/CMakeFiles/CMakeTmp/src.c Linking C executable cmTC_846be /usr/local/bin/cmake -E cmake_link_script CMakeFiles/cmTC_846be.dir/link.txt --verbose=1 /usr/bin/cc -DHAVE_C_FLAG_asan CMakeFiles/cmTC_846be.dir/src.c.o -o cmTC_846be -rdynamic /usr/lib64/libssl.so /usr/lib64/libcrypto.so -lldap -llber CMakeFiles/cmTC_846be.dir/src.c.o: In function `_GLOBAL__sub_I_00099_0_main': src.c:(.text+0x10): undefined reference to `__asan_init_v1' collect2: error: ld returned 1 exit status gmake[1]: *** [cmTC_846be] Error 1 gmake[1]: Leaving directory `/home/snikulov/work/github/curl/build/CMakeFiles/CMakeTmp' gmake: *** [cmTC_846be/fast] Error 2 Source file was: int main(void) { return 0; } ... -- Best Regards, Sergei Nikulov From cmake at Alexander.Shukaev.name Sat Jun 18 03:34:12 2016 From: cmake at Alexander.Shukaev.name (Alexander Shukaev) Date: Sat, 18 Jun 2016 09:34:12 +0200 Subject: [CMake] Policy CMP0063 is not set: Honor visibility properties for all target Message-ID: <36fd43ca-4f6e-6a55-4128-8b8224328f3d@Alexander.Shukaev.name> Hello, CMake 3.5.2 here. Why explicitly setting the CMP0063 policy to NEW does not suppress the warning and actually use that new policy? That is if(POLICY CMP0063) cmake_policy(SET CMP0063 NEW) endif() and I still get Policy CMP0063 is not set: Honor visibility properties for all target types. Run "cmake --help-policy CMP0063" for policy details. Use the cmake_policy command to set the policy and suppress this warning. Target of type "EXECUTABLE" has the following visibility properties set for CXX: CXX_VISIBILITY_PRESET VISIBILITY_INLINES_HIDDEN For compatibility CMake is not honoring them for this target. Is this a bug? Thanks in advance. Regards, Alexander From nilsgladitz at gmail.com Sat Jun 18 05:02:21 2016 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Sat, 18 Jun 2016 11:02:21 +0200 Subject: [CMake] Policy CMP0063 is not set: Honor visibility properties for all target In-Reply-To: <36fd43ca-4f6e-6a55-4128-8b8224328f3d@Alexander.Shukaev.name> References: <36fd43ca-4f6e-6a55-4128-8b8224328f3d@Alexander.Shukaev.name> Message-ID: <57650E1D.80206@gmail.com> On 18.06.2016 09:34, Alexander Shukaev wrote: > Hello, > > CMake 3.5.2 here. Why explicitly setting the CMP0063 policy to NEW > does not suppress the warning and actually use that new policy? That is > > if(POLICY CMP0063) > cmake_policy(SET CMP0063 NEW) > endif() > > and I still get > > Policy CMP0063 is not set: Honor visibility properties for all target > types. Run "cmake --help-policy CMP0063" for policy details. Use the > cmake_policy command to set the policy and suppress this warning. Did you call cmake_minimum_required(VERSION) after setting that policy? That would reset all policies based on the requested version. Otherwise did you set the policy before creating your targets and in a scope that is parent to all targets involved? Nils From cmake at Alexander.Shukaev.name Sat Jun 18 05:38:27 2016 From: cmake at Alexander.Shukaev.name (Alexander Shukaev) Date: Sat, 18 Jun 2016 11:38:27 +0200 Subject: [CMake] Policy CMP0063 is not set: Honor visibility properties for all target In-Reply-To: <57650E1D.80206@gmail.com> References: <36fd43ca-4f6e-6a55-4128-8b8224328f3d@Alexander.Shukaev.name> <57650E1D.80206@gmail.com> Message-ID: <637cd7f1-9ea0-772b-3f18-ec98969425c1@Alexander.Shukaev.name> On 06/18/2016 11:02 AM, Nils Gladitz wrote: > On 18.06.2016 09:34, Alexander Shukaev wrote: >> Hello, >> >> CMake 3.5.2 here. Why explicitly setting the CMP0063 policy to NEW >> does not suppress the warning and actually use that new policy? That is >> >> if(POLICY CMP0063) >> cmake_policy(SET CMP0063 NEW) >> endif() >> >> and I still get >> >> Policy CMP0063 is not set: Honor visibility properties for all target >> types. Run "cmake --help-policy CMP0063" for policy details. Use the >> cmake_policy command to set the policy and suppress this warning. > > Did you call cmake_minimum_required(VERSION) after setting that policy? > That would reset all policies based on the requested version. > > Otherwise did you set the policy before creating your targets and in a > scope that is parent to all targets involved? > > Nils I did try both variants, after and before cmake_minimum_required(VERSION) but the result is the same. The scope is for sure parent to targets. Alexander From nilsgladitz at gmail.com Sat Jun 18 06:18:40 2016 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Sat, 18 Jun 2016 12:18:40 +0200 Subject: [CMake] Policy CMP0063 is not set: Honor visibility properties for all target In-Reply-To: <637cd7f1-9ea0-772b-3f18-ec98969425c1@Alexander.Shukaev.name> References: <36fd43ca-4f6e-6a55-4128-8b8224328f3d@Alexander.Shukaev.name> <57650E1D.80206@gmail.com> <637cd7f1-9ea0-772b-3f18-ec98969425c1@Alexander.Shukaev.name> Message-ID: <57652000.8050205@gmail.com> On 18.06.2016 11:38, Alexander Shukaev wrote: > > I did try both variants, after and before > > cmake_minimum_required(VERSION) > > but the result is the same. The scope is for sure parent to targets. I don't know what else it could be but this works fine for me: cmake_minimum_required(VERSION 2.8.12) if(POLICY CMP0063) cmake_policy(SET CMP0063 NEW) endif() file(WRITE foo.cpp "int main() {}") set(CMAKE_CXX_VISIBILITY_PRESET hidden) add_executable(foo foo.cpp) Is it possible that the scope where the policy warning comes from has its own cmake_minimum_required(VERSION) call? (e.g. is there more than one?) Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmake at Alexander.Shukaev.name Sat Jun 18 07:03:29 2016 From: cmake at Alexander.Shukaev.name (Alexander Shukaev) Date: Sat, 18 Jun 2016 13:03:29 +0200 Subject: [CMake] Policy CMP0063 is not set: Honor visibility properties for all target In-Reply-To: <57652000.8050205@gmail.com> References: <36fd43ca-4f6e-6a55-4128-8b8224328f3d@Alexander.Shukaev.name> <57650E1D.80206@gmail.com> <637cd7f1-9ea0-772b-3f18-ec98969425c1@Alexander.Shukaev.name> <57652000.8050205@gmail.com> Message-ID: <630b8bf5-6e42-118a-b654-ce9d59efe977@Alexander.Shukaev.name> On 06/18/2016 12:18 PM, Nils Gladitz wrote: > On 18.06.2016 11:38, Alexander Shukaev wrote: >> >> I did try both variants, after and before >> >> cmake_minimum_required(VERSION) >> >> but the result is the same. The scope is for sure parent to targets. > > I don't know what else it could be but this works fine for me: > > cmake_minimum_required(VERSION 2.8.12) > > if(POLICY CMP0063) > cmake_policy(SET CMP0063 NEW) > endif() > > file(WRITE foo.cpp "int main() {}") > > set(CMAKE_CXX_VISIBILITY_PRESET hidden) > > add_executable(foo foo.cpp) > > > Is it possible that the scope where the policy warning comes from has > its own cmake_minimum_required(VERSION) call? (e.g. is there more than > one?) > > Nils > You were right, Nils. I have a CMake library that is pretty huge. When one does `find_package' for it, then it will `include' all its modules into the client code. Back when I started it, I didn't know that `cmake_minimum_required' can reset policies. So there were a couple of modules that were still calling `cmake_minimum_required' which is clearly a bad practice. I cleaned it up and it works now. However, now the sequence is like this xxx.cmake: if(POLICY CMP0011) cmake_policy(SET CMP0011 NEW) endif() if(POLICY CMP0063) cmake_policy(SET CMP0063 NEW) endif() CMakeLists.txt: include(xxx) cmake_minimum_required(VERSION 3.1.0) and it still works. Is it because the version is high enough so it does not reset policies? Alexander From nicholas11braden at gmail.com Sat Jun 18 07:12:10 2016 From: nicholas11braden at gmail.com (Nicholas Braden) Date: Sat, 18 Jun 2016 06:12:10 -0500 Subject: [CMake] Policy CMP0063 is not set: Honor visibility properties for all target In-Reply-To: <630b8bf5-6e42-118a-b654-ce9d59efe977@Alexander.Shukaev.name> References: <36fd43ca-4f6e-6a55-4128-8b8224328f3d@Alexander.Shukaev.name> <57650E1D.80206@gmail.com> <637cd7f1-9ea0-772b-3f18-ec98969425c1@Alexander.Shukaev.name> <57652000.8050205@gmail.com> <630b8bf5-6e42-118a-b654-ce9d59efe977@Alexander.Shukaev.name> Message-ID: CMP0063 was not added until CMake 3.3, so requesting 3.1 as the minimum does not make sense. https://cmake.org/cmake/help/latest/policy/CMP0063.html On Sat, Jun 18, 2016 at 6:03 AM, Alexander Shukaev wrote: > On 06/18/2016 12:18 PM, Nils Gladitz wrote: >> >> On 18.06.2016 11:38, Alexander Shukaev wrote: >>> >>> >>> I did try both variants, after and before >>> >>> cmake_minimum_required(VERSION) >>> >>> but the result is the same. The scope is for sure parent to targets. >> >> >> I don't know what else it could be but this works fine for me: >> >> cmake_minimum_required(VERSION 2.8.12) >> >> if(POLICY CMP0063) >> cmake_policy(SET CMP0063 NEW) >> endif() >> >> file(WRITE foo.cpp "int main() {}") >> >> set(CMAKE_CXX_VISIBILITY_PRESET hidden) >> >> add_executable(foo foo.cpp) >> >> >> Is it possible that the scope where the policy warning comes from has >> its own cmake_minimum_required(VERSION) call? (e.g. is there more than >> one?) >> >> Nils >> > > You were right, Nils. I have a CMake library that is pretty huge. When one > does `find_package' for it, then it will `include' all its modules into the > client code. Back when I started it, I didn't know that > `cmake_minimum_required' can reset policies. So there were a couple of > modules that were still calling `cmake_minimum_required' which is clearly a > bad practice. I cleaned it up and it works now. > > However, now the sequence is like this > > xxx.cmake: > > if(POLICY CMP0011) > cmake_policy(SET CMP0011 NEW) > endif() > if(POLICY CMP0063) > cmake_policy(SET CMP0063 NEW) > endif() > > CMakeLists.txt: > > include(xxx) > cmake_minimum_required(VERSION 3.1.0) > > and it still works. Is it because the version is high enough so it does not > reset policies? > > Alexander > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From nilsgladitz at gmail.com Sat Jun 18 07:15:05 2016 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Sat, 18 Jun 2016 13:15:05 +0200 Subject: [CMake] Policy CMP0063 is not set: Honor visibility properties for all target In-Reply-To: <630b8bf5-6e42-118a-b654-ce9d59efe977@Alexander.Shukaev.name> References: <36fd43ca-4f6e-6a55-4128-8b8224328f3d@Alexander.Shukaev.name> <57650E1D.80206@gmail.com> <637cd7f1-9ea0-772b-3f18-ec98969425c1@Alexander.Shukaev.name> <57652000.8050205@gmail.com> <630b8bf5-6e42-118a-b654-ce9d59efe977@Alexander.Shukaev.name> Message-ID: <57652D39.3050300@gmail.com> On 18.06.2016 13:03, Alexander Shukaev wrote: > > if(POLICY CMP0011) > cmake_policy(SET CMP0011 NEW) > endif() > if(POLICY CMP0063) > cmake_policy(SET CMP0063 NEW) > endif() > > CMakeLists.txt: > > include(xxx) > cmake_minimum_required(VERSION 3.1.0) > > and it still works. Is it because the version is high enough so it > does not reset policies? The cmake_minimum_required() call will set CMP0011 to NEW and will unset CMP0063. This is because CMP0011 was introduced before CMake 3.1.0 (the version you require) and CMP0063 was introduced afterwards (in CMake 3.3). Given your sequence of calls none of the previous cmake_policy(SET) calls will have any effect. Nils From cmake at Alexander.Shukaev.name Sat Jun 18 07:28:30 2016 From: cmake at Alexander.Shukaev.name (Alexander Shukaev) Date: Sat, 18 Jun 2016 13:28:30 +0200 Subject: [CMake] Policy CMP0063 is not set: Honor visibility properties for all target In-Reply-To: <57652D39.3050300@gmail.com> References: <36fd43ca-4f6e-6a55-4128-8b8224328f3d@Alexander.Shukaev.name> <57650E1D.80206@gmail.com> <637cd7f1-9ea0-772b-3f18-ec98969425c1@Alexander.Shukaev.name> <57652000.8050205@gmail.com> <630b8bf5-6e42-118a-b654-ce9d59efe977@Alexander.Shukaev.name> <57652D39.3050300@gmail.com> Message-ID: <596bbc52-1c69-0346-d6de-9938654b1907@Alexander.Shukaev.name> On 06/18/2016 01:15 PM, Nils Gladitz wrote: > On 18.06.2016 13:03, Alexander Shukaev wrote: >> >> if(POLICY CMP0011) >> cmake_policy(SET CMP0011 NEW) >> endif() >> if(POLICY CMP0063) >> cmake_policy(SET CMP0063 NEW) >> endif() >> >> CMakeLists.txt: >> >> include(xxx) >> cmake_minimum_required(VERSION 3.1.0) >> >> and it still works. Is it because the version is high enough so it >> does not reset policies? > > The cmake_minimum_required() call will set CMP0011 to NEW and will unset > CMP0063. > This is because CMP0011 was introduced before CMake 3.1.0 (the version > you require) and CMP0063 was introduced afterwards (in CMake 3.3). > > Given your sequence of calls none of the previous cmake_policy(SET) > calls will have any effect. > > Nils But they in fact do. How come? From nilsgladitz at gmail.com Sat Jun 18 07:37:46 2016 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Sat, 18 Jun 2016 13:37:46 +0200 Subject: [CMake] Policy CMP0063 is not set: Honor visibility properties for all target In-Reply-To: <596bbc52-1c69-0346-d6de-9938654b1907@Alexander.Shukaev.name> References: <36fd43ca-4f6e-6a55-4128-8b8224328f3d@Alexander.Shukaev.name> <57650E1D.80206@gmail.com> <637cd7f1-9ea0-772b-3f18-ec98969425c1@Alexander.Shukaev.name> <57652000.8050205@gmail.com> <630b8bf5-6e42-118a-b654-ce9d59efe977@Alexander.Shukaev.name> <57652D39.3050300@gmail.com> <596bbc52-1c69-0346-d6de-9938654b1907@Alexander.Shukaev.name> Message-ID: <5765328A.6040008@gmail.com> On 18.06.2016 13:28, Alexander Shukaev wrote: > > But they in fact do. How come? I am not sure what facts you mean ... they don't: cmake_policy(SET CMP0063 NEW) cmake_policy(GET CMP0063 POLICY_VALUE_BEFORE) cmake_minimum_required(VERSION 3.1.0) cmake_policy(GET CMP0063 POLICY_VALUE_AFTER) message("[${POLICY_VALUE_BEFORE}] [${POLICY_VALUE_AFTER}]") file(WRITE foo.cpp "int main() {}") set(CMAKE_CXX_VISIBILITY_PRESET hidden) add_executable(foo foo.cpp) Expectedly outputs for me: [NEW] [] (plus the policy warning since CMP0063 is in fact not set) Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: From Miroslav.Ilias at umb.sk Sat Jun 18 08:31:19 2016 From: Miroslav.Ilias at umb.sk (Ilias Miroslav) Date: Sat, 18 Jun 2016 12:31:19 +0000 Subject: [CMake] first WARNING message swallows all previous STATUS messages in cmake configure Message-ID: <1466253079697.50439@umb.sk> Dear experts, we are employing CMake buildup system in our project http://www.diracprogram.org. We have a system of cmake files, many of them containing printouts in the form message(STATUS "...") . What happens, however, is when message (WARNING ...) appears during configure step all the previous message(STATUS "...")- output statutes are gone. On the screen there is only the WARNING message, but no previous STATUS messages. Any help, how to fix it ? I would be glad to have all STATUS, WARNING (even FATAL) messages on the screen as it helps the CMake development. Thanks, Miro -------------- next part -------------- An HTML attachment was scrubbed... URL: From kristianonline28 at gmail.com Sat Jun 18 13:46:31 2016 From: kristianonline28 at gmail.com (Kristian) Date: Sat, 18 Jun 2016 13:46:31 -0400 Subject: [CMake] first WARNING message swallows all previous STATUS messages in cmake configure In-Reply-To: <1466253079697.50439@umb.sk> References: <1466253079697.50439@umb.sk> Message-ID: I have some questions for clarification: Which CMake-Version do you use? Which OS do you use? And where is the output of CMake written to? 2016-06-18 8:31 GMT-04:00 Ilias Miroslav : > Dear experts, > > > we are employing CMake buildup system in our project > http://www.diracprogram.org. > > > We have a system of cmake files, many of them containing printouts in the > form message(STATUS "...") . > > > What happens, however, is when message (WARNING ...) appears during > configure step all the previous message(STATUS "...")- output > statutes are gone. On the screen there is only the WARNING message, but no > previous STATUS messages. > > > Any help, how to fix it ? I would be glad to have all STATUS, WARNING > (even FATAL) messages on the screen as it helps the CMake development. > > > Thanks, Miro > > > > > -- > > 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 Miroslav.Ilias at umb.sk Sat Jun 18 13:50:16 2016 From: Miroslav.Ilias at umb.sk (Ilias Miroslav) Date: Sat, 18 Jun 2016 17:50:16 +0000 Subject: [CMake] first WARNING message swallows all previous STATUS messages in cmake configure In-Reply-To: References: <1466253079697.50439@umb.sk>, Message-ID: <1466272215647.94208@umb.sk> Hi, thanks for response; after checking it more thoroughly I think it might be the issue of python related script, not of the CMake, for what I have open the issue: https://github.com/coderefinery/autocmake/issues/174 We can close this question for now. All the best, Miro From: Kristian Sent: Saturday, June 18, 2016 7:46 PM To: Ilias Miroslav Cc: cmake at cmake.org Subject: Re: [CMake] first WARNING message swallows all previous STATUS messages in cmake configure I have some questions for clarification: Which CMake-Version do you use? Which OS do you use? And where is the output of CMake written to? 2016-06-18 8:31 GMT-04:00 Ilias Miroslav >: Dear experts, we are employing CMake buildup system in our project http://www.diracprogram.org. We have a system of cmake files, many of them containing printouts in the form message(STATUS "...") . What happens, however, is when message (WARNING ...) appears during configure step all the previous message(STATUS "...")- output statutes are gone. On the screen there is only the WARNING message, but no previous STATUS messages. Any help, how to fix it ? I would be glad to have all STATUS, WARNING (even FATAL) messages on the screen as it helps the CMake development. Thanks, Miro -- 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 afe.young at gmail.com Sun Jun 19 21:16:11 2016 From: afe.young at gmail.com (Young Yang) Date: Mon, 20 Jun 2016 09:16:11 +0800 Subject: [CMake] cmake install target doesn't run ldconfig after installing library In-Reply-To: References: Message-ID: Thanks :) I think there should be better solutions. But It's the best solution I know so far. On Fri, Jun 17, 2016 at 9:07 PM, Matthew Keeler wrote: > So I did some experimenting. It would seem there are a few rules to the > order installs are executed > > 1 - installs are processed in the order the containing CMakeLists.txt > files are > 2 - within a CMakeLists.txt they seem to be ordered based on which comes > first in the file. > > So a not so elegant workaround would be to create a post-install directory > in your source tree and have the last line of your main CMakeLists.txt be > to add_subdirectory(post-install). Then all your post-install logic can > live in there. > > -- > Matt Keeler > > > On June 16, 2016 at 21:01:46, Young Yang (afe.young at gmail.com) wrote: > > Thanks! > This command really solve my problem. > > But I still get a problem about the command order now. > > I have some sub directories. > For e.g. One of them is called "src" and there is also a CMakeLists.txt in > it. And the shared library installation instructions are in it. > So I have `ADD_SUBDIRECTORY(src)` in my main CMakeLists.txt. > > I put the command `install(CODE "execute_process(COMMAND ldconfig)")` > after `ADD_SUBDIRECTORY(src)` . But It still run ldconfig before the > installation of shared libraries in src sub folder. > > > > On Thu, Jun 16, 2016 at 9:02 PM, Matthew Keeler > wrote: > >> CMake won?t and in my opinion shouldn?t implicitly invoke ldconfig for >> you. There are many scenarios and platforms where this is incorrect >> behavior and some such as running install to prepare for packaging that >> CMake wouldn?t reliably be able to detect. >> >> If you want to provide the functionality for your users you could add >> something like the following to your CMakeLists.txt: >> >> install(CODE ?execute_process(COMMAND ldconfig)?) >> >> This will need to run after your other installed targets. I can?t find >> any way in the CMake documentation to force install ordering but it seems >> like as long as CMake processes that install command last it will perform >> it last. So at the very end of your top level CMakeLists.txt file should do >> the trick. >> >> -- >> Matt Keeler >> >> >> On June 15, 2016 at 22:12:09, Young Yang (afe.young at gmail.com) wrote: >> >> Hi, >> I've encountered some problem when writing install target with cmake. >> >> I use `install (TARGETS DESTINATION lib)` to install >> my shared_library. >> However, when I run `make install`. It just install the .so to >> /usr/local/lib and didn't run the ldconfig. >> >> I think it is strange and inconvenient to tell the user he should run >> ldconfig by himself or herself. >> >> What is the best way to make the ldconfig run automatically? >> >> >> Thanks in advance :) >> >> -- >> Best wishes, >> Young Yang >> -- >> >> 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 >> >> > > > -- > Best wishes, > Young Yang > > -- Best wishes, Young Yang -------------- next part -------------- An HTML attachment was scrubbed... URL: From zcsd2012 at gmail.com Sun Jun 19 22:01:07 2016 From: zcsd2012 at gmail.com (Chaos Zhang) Date: Sun, 19 Jun 2016 19:01:07 -0700 (MST) Subject: [CMake] Why a foo.dll.a generated when i build shared lib foo.dll or foo.exe file? Message-ID: <1466388067296-7593769.post@n2.nabble.com> Hi,all, I am working on transferring an existed make project into cmake, and the platform is MinGW(32 bit) on windows. The make flow to build foo.dll or foo.exe would not generate foo.dll.a, but when i use CMake, this generated. I was wondering if this foo.dll.a is necessary, and if it is not necessary, what can i do to avoid generating this file. Thanks a lot, Chao -- View this message in context: http://cmake.3232098.n2.nabble.com/Why-a-foo-dll-a-generated-when-i-build-shared-lib-foo-dll-or-foo-exe-file-tp7593769.html Sent from the CMake mailing list archive at Nabble.com. From d3ck0r at gmail.com Sun Jun 19 22:12:50 2016 From: d3ck0r at gmail.com (J Decker) Date: Sun, 19 Jun 2016 19:12:50 -0700 Subject: [CMake] MinGW and sh.exe In-Reply-To: References: Message-ID: I was searching for 'cmake disable check sh.exe' which is not a problem (anymore?) If I do cmake -G "MinGW Makefiles" /some/path it complains; then the same command again succeeds; so it's not a problem... it only causes a stutter in startup; which is a problem; and the project builds and installs just fine. (it doesn't do find required system libraries to pull in the libgcc-sjlj-something-threads library and potentially others on 'findrequiredsystemlibraries?' but that's a side issue. sh.exe comes with git.exe there's just no two ways about it. and not in MSYS; just an installed mingw64 from sourceforge and cmake On Wed, Jun 17, 2015 at 1:25 AM, J?rg Kreuzberger wrote: > Hi! > > i get an error at cmake configure step on windows with -G "MinGW > Makefiles", if the OpenSSH bin folder is in the PATH environment cause > cmake detects sh.exe and then throws an error. This seems to be intended > due to this link > http://www.cmake.org/Wiki/CMake_MinGW_Compiler_Issues > But if i now configure a second time, everything is fine and the generated > MinGW Makefiles are generated properly and could be build normaly with > mingw32-make wihtout any msys or sh environment. > > So is the first cmake error an error? The link ist quite old (2006) > > Thanks for any help. > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From w.bekker at vdgsecurity.com Mon Jun 20 06:04:16 2016 From: w.bekker at vdgsecurity.com (Wim Bekker) Date: Mon, 20 Jun 2016 12:04:16 +0200 Subject: [CMake] AUTORCC recompiles rcc Message-ID: <25643541-4e6b-3fd5-be1f-fe485ea2e843@vdgsecurity.com> Hi, In cmake 3.5.0, 3.5.2 and 3.6.0 rc1 and 2 my resource file is compiled every time I build. I'm trying to create an issue in the new kitware issue tracker but I cannot find an "Add" button or so. How can I proceed? Thanks, Wim From cliffyapp at gmail.com Mon Jun 20 07:37:07 2016 From: cliffyapp at gmail.com (Clifford Yapp) Date: Mon, 20 Jun 2016 07:37:07 -0400 Subject: [CMake] Getting at the final compiler/linker string for a given library Message-ID: Does anyone know if there's a way, given the full path find_package result: /usr/lib/libfoo.so to have CMake report what the eventual "-lfoo" entry will be on the compiler/linker line? I need to report out that information into a file independent of CMake's logic, and so far I haven't been able to zero in on how to get at it. Thanks, CY From christian.convey at gmail.com Mon Jun 20 11:28:07 2016 From: christian.convey at gmail.com (Christian Convey) Date: Mon, 20 Jun 2016 11:28:07 -0400 Subject: [CMake] Best way to modify C++ build steps (clang / linux)? Message-ID: I've got an existing project with a CMake-based build system. The project: - Has both C and C++ files - Links some ".o" files into convenience .a files. - Links some ".o" and ".a" files into several different executables. - Can be built successfully with gcc or clang. When using clang, I'd like the build process to *not* directly compile a C/C++ source file into an object file. Instead, I'd like it to use two distinct steps: 1. Use "clang -emit-llvm ..." to produce a bitcode (".bc") file. 2. Use "llc" to compile the bitcode file to a native ".o" file. Does CMake have an idiomatic way to implement this change? (Worst-case scenario I can create a wrapper script for "clang" which performs those two steps separately. But I'd rather use the intended approach if possible.) - Christian -------------- next part -------------- An HTML attachment was scrubbed... URL: From iraytrace at gmail.com Mon Jun 20 14:47:32 2016 From: iraytrace at gmail.com (Lee Butler) Date: Mon, 20 Jun 2016 14:47:32 -0400 Subject: [CMake] gathering directory names in cmake Message-ID: <57683A44.4030608@gmail.com> I have a source tree which contains multiple directories each of which has a subdirectory called "xyz". I want to create a target that creates a zip file with each of the xyz directories. So if the source tree looks like src src/xyz src/application src/application/xyz src/plugins/one/xyz I want to end up with a zip file containing: src/xyz/* src/application/xyz/* src/plugins/one/xyz/* On unix I could just generate the list of these directories with: find src -type d -name test -print alas, I need a cross-platform way to do this. I tried: file(GLOB_RECURSE XYZFILES "${CMAKE_SOURCE_DIR}/src/*xyz) and got nothing. At the moment, it looks like I cannot wildcard any portion of the directory path. The following: file(GLOB_RECURSE XYZFILES "${CMAKE_SOURCE_DIR}/src/*xyz*") seems to only produce files which have xyz in their name. Lee From robert.maynard at kitware.com Tue Jun 21 08:19:15 2016 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 21 Jun 2016 08:19:15 -0400 Subject: [CMake] AUTORCC recompiles rcc In-Reply-To: <25643541-4e6b-3fd5-be1f-fe485ea2e843@vdgsecurity.com> References: <25643541-4e6b-3fd5-be1f-fe485ea2e843@vdgsecurity.com> Message-ID: We have switched over to gitlab for our issue tracking. You can report your issue at: https://gitlab.kitware.com/cmake/cmake/issues On Mon, Jun 20, 2016 at 6:04 AM, Wim Bekker wrote: > Hi, > > In cmake 3.5.0, 3.5.2 and 3.6.0 rc1 and 2 my resource file is compiled every > time I build. > > I'm trying to create an issue in the new kitware issue tracker but I cannot > find an "Add" button or so. > > How can I proceed? > > Thanks, Wim > -- > > 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 laasunde at hotmail.com Tue Jun 21 10:28:36 2016 From: laasunde at hotmail.com (Lars) Date: Tue, 21 Jun 2016 16:28:36 +0200 Subject: [CMake] VS2015 and toolset v110 Message-ID: Hello, Environment is Windows 7sp1, CMake 3.5.2 and Visual Studio 2015 Pro. Running below command in MSBuild Command prompt for VS2015 shell; cmake -DCMAKE_BUILD_TYPE=Release -G "Visual Studio 14 2015" -T v110 ../src output is; The c compiler identification is unknown The cxx compiler identification is unknown No CMAKE_C_COMPILER could be found No CMAKE_CXX_COMPILER could be found Updating command with different toolset (same shell) cmake -DCMAKE_BUILD_TYPE=Release -G "Visual Studio 14 2015" -T v140 ../src output is; The c compiler identification is MSVC 19.0.23.. The cxx compiler identification is MSVC 19.0.23.. check for working c compiler using Visual Studio 14 2015 check for working c compiler using Visual Studio 14 2015 -- works Using toolset v140 appears to find the compiler but using v100 or v110 or vs120 does not work. Why is this happening? The second example using v140 actually also fails but that is because it is trying to find boost_math_c99_v140 library which does not exists (we use v110 library). (and no, I cannot change toolset at the moment) Kind regards, Lars -------------- next part -------------- An HTML attachment was scrubbed... URL: From post at hendrik-sattler.de Tue Jun 21 11:57:22 2016 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Tue, 21 Jun 2016 17:57:22 +0200 Subject: [CMake] VS2015 and toolset v110 In-Reply-To: References: Message-ID: To generate for V110 toolset, you can just use visual studio 11 generator and open the result in VS14. HS Am 21. Juni 2016 16:28:36 MESZ, schrieb Lars : >Hello, > >Environment is Windows 7sp1, CMake 3.5.2 and Visual Studio 2015 Pro. > >Running below command in MSBuild Command prompt for VS2015 shell; >cmake -DCMAKE_BUILD_TYPE=Release -G "Visual Studio 14 2015" -T v110 >../src > >output is; >The c compiler identification is unknown >The cxx compiler identification is unknown >No CMAKE_C_COMPILER could be found >No CMAKE_CXX_COMPILER could be found > >Updating command with different toolset (same shell) >cmake -DCMAKE_BUILD_TYPE=Release -G "Visual Studio 14 2015" -T v140 >../src > >output is; >The c compiler identification is MSVC 19.0.23.. >The cxx compiler identification is MSVC 19.0.23.. >check for working c compiler using Visual Studio 14 2015 >check for working c compiler using Visual Studio 14 2015 -- works > >Using toolset v140 appears to find the compiler but using v100 or v110 >or vs120 does not work. Why is this happening? > >The second example using v140 actually also fails but that is because >it is trying to find boost_math_c99_v140 library which does not exists >(we use v110 library). > >(and no, I cannot change toolset at the moment) > >Kind regards, Lars > > >------------------------------------------------------------------------ -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. From mohammedrashadkm at gmail.com Tue Jun 21 14:51:37 2016 From: mohammedrashadkm at gmail.com (Rashad Kanavath) Date: Tue, 21 Jun 2016 20:51:37 +0200 Subject: [CMake] gathering directory names in cmake In-Reply-To: <57683A44.4030608@gmail.com> References: <57683A44.4030608@gmail.com> Message-ID: On Mon, Jun 20, 2016 at 8:47 PM, Lee Butler wrote: > I have a source tree which contains multiple directories each of which has > a subdirectory called "xyz". I want to create a target that creates a zip > file with each of the xyz directories. So if the source tree looks like > src > src/xyz > src/application > src/application/xyz > src/plugins/one/xyz > > I want to end up with a zip file containing: > src/xyz/* > src/application/xyz/* > src/plugins/one/xyz/* > > On unix I could just generate the list of these directories with: > find src -type d -name test -print > alas, I need a cross-platform way to do this. > > I tried: > file(GLOB_RECURSE XYZFILES "${CMAKE_SOURCE_DIR}/src/*xyz) > and got nothing. > > At the moment, it looks like I cannot wildcard any portion of the > directory path. The following: > file(GLOB_RECURSE XYZFILES "${CMAKE_SOURCE_DIR}/src/*xyz*") > what about adding a backslash at end of expression ? file(GLOB_RECURSE XYZFILES "${CMAKE_SOURCE_DIR}/src/*xyz/") seems to only produce files which have xyz in their name. > > Lee > -- > > 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, Rashad -------------- next part -------------- An HTML attachment was scrubbed... URL: From Miroslav.Ilias at umb.sk Wed Jun 22 06:47:15 2016 From: Miroslav.Ilias at umb.sk (Ilias Miroslav) Date: Wed, 22 Jun 2016 10:47:15 +0000 Subject: [CMake] help with OBJECT libraries hierarchy Message-ID: <1466592435290.20207@umb.sk> Dear experts, I am trying to introduce OBJECT libraries into our project, http://www.diracprogram.org. Into local src/functionality1/CMakeLists.txt I changed add_library(main ${local_sources}) to add_library(main OBJECT ${local_sources}) at higher level, in src/CMakeLists.txt I changed add_subdirectory(${PROJECT_SOURCE_DIR}/src/functionality1) set(EXTERNAL_LIBS main ${EXTERNAL_LIBS}) to add_subdirectory(${PROJECT_SOURCE_DIR}/src/functionality1) set(EXTERNAL_LIBS $ ${EXTERNAL_LIBS}) and at the highest level of our CMake infrastructure I have linking of all object libraries for given executable(s) : target_link_libraries( ${_executable} ${EXTERNAL_LIBS} ) However, during configuration I am getting repeating error messages of type "CMake Error at cmake/custom/core.cmake:75 (target_link_libraries): 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. Call Stack (most recent call first): CMakeLists.txt:77 (include)" Any help please how to best arrange OBJECT libraries ? I have cmake version 3.5.0 . Yours, Miro -------------- next part -------------- An HTML attachment was scrubbed... URL: From petr.kmoch at gmail.com Wed Jun 22 07:09:48 2016 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Wed, 22 Jun 2016 13:09:48 +0200 Subject: [CMake] help with OBJECT libraries hierarchy In-Reply-To: <1466592435290.20207@umb.sk> References: <1466592435290.20207@umb.sk> Message-ID: Ahoj Miro, object libraries are not intended for linking. The way it works is you expand the $ genex into the list of *sources* of the consuming target. In other words, the string '$' needs to go into the add_executable(foo) or add_library(foo) command, not into target_link_libraries(foo). Petr On 22 June 2016 at 12:47, Ilias Miroslav wrote: > Dear experts, > > > I am trying to introduce OBJECT libraries into our project, > http://www.diracprogram.org. > > > Into local src/functionality1/CMakeLists.txt I changed > > > add_library(main ${local_sources}) > > to > > add_library(main OBJECT ${local_sources}) > > > at higher level, in src/CMakeLists.txt I changed > > > add_subdirectory(${PROJECT_SOURCE_DIR}/src/functionality1) > set(EXTERNAL_LIBS main ${EXTERNAL_LIBS}) > > to > > add_subdirectory(${PROJECT_SOURCE_DIR}/src/functionality1) > set(EXTERNAL_LIBS $ ${EXTERNAL_LIBS}) > > > and at the highest level of our CMake infrastructure I have linking of all > object libraries for given executable(s) : > > > target_link_libraries( ${_executable} ${EXTERNAL_LIBS} ) > > > However, during configuration I am getting repeating error messages of > type > > > "CMake Error at cmake/custom/core.cmake:75 (target_link_libraries): > 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. > Call Stack (most recent call first): > CMakeLists.txt:77 (include)" > > Any help please how to best arrange OBJECT libraries ? I have cmake > version 3.5.0 . > > > Yours, Miro > > > > -- > > 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 patrick.boettcher at posteo.de Wed Jun 22 10:43:40 2016 From: patrick.boettcher at posteo.de (Patrick Boettcher) Date: Wed, 22 Jun 2016 16:43:40 +0200 Subject: [CMake] CMake generator executable variable Message-ID: <20160622164340.7b6cc897@posteo.de> Hi list, In my project some people use Ninja as a generator, some use GNU Make. In a part of my projects I have a add_custom_command() which runs, for convenience, the build of another cmake-generated project in another dir using a different set of compilers (which is the reason for not being a sub_directory). add_custom_target(build-app COMMAND make -C ${APP_BUILD_DIR}) This fails of course if the user decided to use ninja. We can assume that the caller's build is always using the same generator as the callee's one. I know there is CMAKE_GENERATOR - I could do it with 'IF()', but is there a variable carrying the generator-command which I can use to replace the bare 'make'? Thank you in advance. regards, -- Patrick. From petr.kmoch at gmail.com Wed Jun 22 10:52:17 2016 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Wed, 22 Jun 2016 16:52:17 +0200 Subject: [CMake] CMake generator executable variable In-Reply-To: <20160622164340.7b6cc897@posteo.de> References: <20160622164340.7b6cc897@posteo.de> Message-ID: Hi Patrick. If the "subproject" is also CMake-generated, as you say, the best way to build it would be: add_custom_target(build-app COMMAND ${CMAKE_COMMAND} --build #... other options as appropriate ) You might also have to set the WORKING_DIRECTORY. This should give you a generator-agnostic command to build a CMake-generated project. Petr On 22 June 2016 at 16:43, Patrick Boettcher wrote: > Hi list, > > In my project some people use Ninja as a generator, some use GNU Make. > > In a part of my projects I have a add_custom_command() which runs, for > convenience, the build of another cmake-generated project in another > dir using a different set of compilers (which is the reason for not > being a sub_directory). > > add_custom_target(build-app > COMMAND make -C ${APP_BUILD_DIR}) > > This fails of course if the user decided to use ninja. > > We can assume that the caller's build is always using the same generator > as the callee's one. > > I know there is CMAKE_GENERATOR - I could do it with 'IF()', but is > there a variable carrying the generator-command which I can use to > replace the bare 'make'? > > Thank you in advance. > > regards, > -- > Patrick. > > > > -- > > 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 patrick.boettcher at posteo.de Wed Jun 22 10:58:33 2016 From: patrick.boettcher at posteo.de (Patrick Boettcher) Date: Wed, 22 Jun 2016 16:58:33 +0200 Subject: [CMake] CMake generator executable variable In-Reply-To: References: <20160622164340.7b6cc897@posteo.de> Message-ID: <20160622165833.4b186425@posteo.de> Hi Petr, On Wed, 22 Jun 2016 16:52:17 +0200 Petr Kmoch wrote: > Hi Patrick. > > If the "subproject" is also CMake-generated, as you say, the best way > to build it would be: > > add_custom_target(build-app > COMMAND ${CMAKE_COMMAND} --build #... other options as > appropriate ) > > You might also have to set the WORKING_DIRECTORY. Thanks. Just when your Email arrived I just found the --build-option. It is even better than I thought it will be. regards, -- Patrick. From roman.wueger at gmx.at Wed Jun 22 11:22:02 2016 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Wed, 22 Jun 2016 17:22:02 +0200 Subject: [CMake] [iOS] What is the correct way to add resources to an XCode project Message-ID: <21D325C1-601B-4393-8BBB-7D82B36456E7@gmx.at> Hello, I read the mailing list but did find a way which works. At the moment I use Xcode 7.3.1 and CMake 3.5.2 which creates a project for iOS 9.3. All I want is to add the directory "Images.xcassets" and a second directory structure to be copied to the Resource folder listed in XCode. When I manually drag'n drop the directories into the Resource folder as reference or as group everything is working. How can I archive this with CMake? Thanks and regards Roman From patrick.boettcher at posteo.de Wed Jun 22 11:59:33 2016 From: patrick.boettcher at posteo.de (Patrick Boettcher) Date: Wed, 22 Jun 2016 17:59:33 +0200 Subject: [CMake] Dependency on imported target with ninja-generator Message-ID: <20160622175933.18907b01@posteo.de> Hi list, I'm finding myself in the following situation. - Project A generates libmain.a and export(TARGETS ... NAMESPACE ns) it to a file. The target is called ns::main - Project B includes this file and has some executables link with libmain.a (via target_link_libraries(exe ns::main). - Project B's CMakeLists.txt contains a add_custom_target(build ...) which runs cmake --build in project A's build-dir. - the target build is a add_dependency() of ns::main. Building it with gnu-make works like a charm - make is entering project A's build-dir before linking. Building it with ninja fails with not finding libmain.a - which is normal it has not yet been built. Ninja seems to evaluate the complete dependency-tree of files before doing anything. Is there a way to fix this? Thanks. best regards, -- Patrick. From robert.maynard at kitware.com Wed Jun 22 15:13:01 2016 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 22 Jun 2016 15:13:01 -0400 Subject: [CMake] [ANNOUNCE] CMake 3.6.0-rc3 now ready for testing! Message-ID: I am proud to announce the third CMake 3.6 release candidate. Sources and binaries are available at: https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.6 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.6/release/3.6.html Some of the more significant features of CMake 3.6 are: * The "Visual Studio 14 2015" generator learned to support the Clang/C2 toolsets, e.g. with the "-T v140_clang_3_7" option. This feature is experimental. * The "list()" command gained a "FILTER" sub-command to filter list elements by regular expression. * A "CMAKE_TRY_COMPILE_TARGET_TYPE" variable was added to optionally tell the "try_compile()" command to build a static library instead of an executable. This is useful for cross-compiling toolchains that cannot link binaries without custom flags or scripts. * A "_CLANG_TIDY" target property and supporting "CMAKE__CLANG_TIDY" variable were introduced to tell the Makefile Generators and the "Ninja" generator to run "clang-tidy" along with the compiler for "C" and "CXX" languages. * The "ExternalProject" module leared the "GIT_SHALLOW 1" option to perform a shallow clone of a Git repository. * The "ExternalProject" module learned to initialize Git submodules recursively and also to initialize new submodules on updates. Use the "GIT_SUBMODULES" option to restrict which submodules are initalized and updated. * The "InstallRequiredSystemLibraries" module learned a new "CMAKE_INSTALL_UCRT_LIBRARIES" option to enable app-local deployment of the Windows Universal CRT libraries with Visual Studio 2015. * The "Compile Features" functionality is now aware of features supported by Intel C++ compilers versions 12.1 through 16.0 on UNIX platforms. Deprecated and Removed Features =============================== * The "CMakeForceCompiler" module and its macros are now deprecated. See module documentation for an explanation. * The "Visual Studio 7 .NET 2003" generator is now deprecated and will be removed in a future version of CMake. * The "Visual Studio 7" generator (for VS .NET 2002) has been removed. It had been deprecated since CMake 3.3. * The "Visual Studio 6" generator has been removed. It had been deprecated since CMake 3.3. CMake 3.6 Release Notes *********************** Changes made since CMake 3.5 include the following. New Features ============ Generators ---------- * The "Ninja" generator learned to produce phony targets of the form "sub/dir/all" to drive the build of a subdirectory. This is equivalent to "cd sub/dir; make all" with Makefile Generators. * The "Ninja" generator now includes system header files in build dependencies to ensure correct re-builds when system packages are updated. * The "Visual Studio 14 2015" generator learned to support the Clang/C2 toolsets, e.g. with the "-T v140_clang_3_7" option. This feature is experimental. Commands -------- * The "add_custom_command()" and "add_custom_target()" commands learned how to use the "CROSSCOMPILING_EMULATOR" executable target property. * The "install()" command learned a new "EXCLUDE_FROM_ALL" option to leave installation rules out of the default installation. * The "list()" command gained a "FILTER" sub-command to filter list elements by regular expression. * The "string(TIMESTAMP)" and "file(TIMESTAMP)" commands gained support for the "%s" placeholder. This is the number of seconds since the UNIX Epoch. * The "try_compile()" command source file signature now honors configuration-specific flags (e.g. "CMAKE__FLAGS_DEBUG") in the generated test project. Previously only the default such flags for the current toolchain were used. Variables --------- * A "CMAKE_DEPENDS_IN_PROJECT_ONLY" variable was introduced to tell Makefile Generators to limit dependency scanning only to files in the project source and build trees. * A new "CMAKE_HOST_SOLARIS" variable was introduced to indicate when CMake is running on an Oracle Solaris host. * A "CMAKE__STANDARD_INCLUDE_DIRECTORIES" variable was added for use by toolchain files to specify system include directories to be appended to all compiler command lines. * The "CMAKE__STANDARD_LIBRARIES" variable is now documented. It is intended for use by toolchain files to specify system libraries to be added to all linker command lines. * A "CMAKE_NINJA_OUTPUT_PATH_PREFIX" variable was introduced to tell the "Ninja" generator to configure the generated "build.ninja" file for use as a "subninja". * A "CMAKE_TRY_COMPILE_PLATFORM_VARIABLES" variable was added for use by toolchain files to specify platform-specific variables that must be propagated by the "try_compile()" command into test projects. * A "CMAKE_TRY_COMPILE_TARGET_TYPE" variable was added to optionally tell the "try_compile()" command to build a static library instead of an executable. This is useful for cross-compiling toolchains that cannot link binaries without custom flags or scripts. Properties ---------- * A "DEPLOYMENT_REMOTE_DIRECTORY" target property was introduced to tell the "Visual Studio 9 2008" and "Visual Studio 8 2005" generators to generate the "remote directory" for WinCE project deployment and debugger settings. * A "_CLANG_TIDY" target property and supporting "CMAKE__CLANG_TIDY" variable were introduced to tell the Makefile Generators and the "Ninja" generator to run "clang-tidy" along with the compiler for "C" and "CXX" languages. * A "TIMEOUT_AFTER_MATCH" test property was introduced to optionally tell CTest to enforce a secondary timeout after matching certain output from a test. * A "VS_CONFIGURATION_TYPE" target property was introduced to specify a custom project file type for Visual Studio Generators supporting VS 2010 and above. * A "VS_STARTUP_PROJECT" directory property was introduced to specify for Visual Studio Generators the default startup project for generated solutions (".sln" files). Modules ------- * The "CMakePushCheckState" module now pushes/pops/resets the variable "CMAKE_EXTRA_INCLUDE_FILE" used in "CheckTypeSize". * The "ExternalProject" module leared the "GIT_SHALLOW 1" option to perform a shallow clone of a Git repository. * The "ExternalProject" module learned to initialize Git submodules recursively and also to initialize new submodules on updates. Use the "GIT_SUBMODULES" option to restrict which submodules are initalized and updated. * The "ExternalProject" module leared the "DOWNLOAD_NO_EXTRACT 1" argument to skip extracting the file that is downloaded (e.g., for self-extracting shell installers or ".msi" files). * The "ExternalProject" module now uses "TLS_VERIFY" when fetching from git repositories. * The "FindBLAS" and "FindLAPACK" modules learned to support OpenBLAS. * The "FindCUDA" module learned to find the "cublas_device" library. * The "FindGTest" module "gtest_add_tests" function now causes CMake to automatically re-run when test sources change so that they can be re-scanned. * The "FindLTTngUST" module was introduced to find the LTTng-UST library. * The "FindPkgConfig" module learned to optionally create imported targets for the libraries it has found. * The "FindProtobuf" module learned to provide a "Protobuf_VERSION" variable and check the version number requested in a "find_package()" call. * The "InstallRequiredSystemLibraries" module learned a new "CMAKE_INSTALL_UCRT_LIBRARIES" option to enable app-local deployment of the Windows Universal CRT libraries with Visual Studio 2015. Platforms --------- * The Clang compiler is now supported on CYGWIN. * Support was added for the Bruce C Compiler with compiler id "Bruce". CTest ----- * The "ctest_update()" command now looks at the "CTEST_GIT_INIT_SUBMODULES" variable to determine whether submodules should be updated or not before updating. * The "ctest_update()" command will now synchronize submodules on an update. Updates which add submodules or change a submodule's URL will now be pulled properly. CPack ----- * The "CPackDeb" module learned how to handle "$ORIGIN" in "CMAKE_INSTALL_RPATH" when "CPACK_DEBIAN_PACKAGE_SHLIBDEPS" is used for dependency auto detection. * The "CPackDeb" module learned how to generate "DEBIAN/shlibs" contorl file when package contains shared libraries. * The "CPackDeb" module learned how to generate "DEBIAN/postinst" and "DEBIAN/postrm" files if the package installs libraries in ldconfig- controlled locations (e.g. "/lib/", "/usr/lib/"). * The "CPackDeb" module learned how to generate dependencies between Debian packages if multi-component setup is used and "CPACK_COMPONENT__DEPENDS" variables are set. For backward compatibility this feature is disabled by default. See "CPACK_DEBIAN_ENABLE_COMPONENT_DEPENDS". * The "CPackDeb" module learned how to set custom package file names including how to generate properly-named Debian packages: _-_.deb For backward compatibility this feature is disabled by default. See "CPACK_DEBIAN_FILE_NAME" and "CPACK_DEBIAN__FILE_NAME". * The "CPackDeb" module learned how to set the package release number ("DebianRevisionNumber" in package file name when used in combination with "DEB-DEFAULT" value set by "CPACK_DEBIAN_FILE_NAME"). See "CPACK_DEBIAN_PACKAGE_RELEASE". * The "CPackDeb" module learned how to set the package architecture per-component. See "CPACK_DEBIAN__PACKAGE_ARCHITECTURE". * The "CPackDMG" module learned a new option to tell the CPack "DragNDrop" generaor to skip the "/Applications" symlink. See the "CPACK_DMG_DISABLE_APPLICATIONS_SYMLINK" variable. * The "CPackIFW" module gained a new "cpack_ifw_update_repository()" command to update a QtIFW-specific repository from a remote repository. * The "CPackRPM" module learned how to set RPM "dist" tag as part of RPM "Release:" tag when enabled (mandatory on some Linux distributions for e.g. on Fedora). See "CPACK_RPM_PACKAGE_RELEASE_DIST". * The "CPackRPM" module learned how to set default values for owning user/group and file/directory permissions of package content. See "CPACK_RPM_DEFAULT_USER", "CPACK_RPM_DEFAULT_GROUP", "CPACK_RPM_DEFAULT_FILE_PERMISSIONS", "CPACK_RPM_DEFAULT_DIR_PERMISSIONS" and their per component counterparts. * The "CPackRPM" module learned how to set user defined package file names, how to specify that rpmbuild should decide on file name format as well as handling of multiple rpm packages generated by a single user defined spec file. See "CPACK_RPM_PACKAGE_NAME" and "CPACK_RPM__PACKAGE_NAME". * The "CPackRPM" module learned how to correctly handle symlinks that are pointing outside generated packages. Other ----- * The "Compile Features" functionality is now aware of features supported by Intel C++ compilers versions 12.1 through 16.0 on UNIX platforms. Deprecated and Removed Features =============================== * The "CMakeForceCompiler" module and its macros are now deprecated. See module documentation for an explanation. * The "find_library()", "find_path()", and "find_file()" commands no longer search in installation prefixes derived from the "PATH" environment variable on non-Windows platforms. This behavior was added in CMake 3.3 to support Windows hosts but has proven problematic on UNIX hosts. Users that keep some "/bin" directories in the "PATH" just for their tools do not necessarily want any supporting "/lib" directories searched. One may set the "CMAKE_PREFIX_PATH" environment variable with a ;-list of prefixes that are to be searched. * The "Visual Studio 7 .NET 2003" generator is now deprecated and will be removed in a future version of CMake. * The "Visual Studio 7" generator (for VS .NET 2002) has been removed. It had been deprecated since CMake 3.3. * The "Visual Studio 6" generator has been removed. It had been deprecated since CMake 3.3. Other Changes ============= * The precompiled OS X binary provided on "cmake.org" now requires OS X 10.7 or newer. * On Linux and FreeBSD platforms, when building CMake itself from source and not using a system-provided libcurl, OpenSSL is now used by default if it is found on the system. This enables SSL/TLS support for commands supporting network communication via "https", such as "file(DOWNLOAD)", "file(UPLOAD)", and "ctest_submit()". * The "cmake(1)" "--build" command-line tool now rejects multiple "-- target" options with an error instead of silently ignoring all but the last one. * "AUTOMOC" now diagnoses name collisions when multiple source files in different directories use "#include " with the same name (because the generated "moc_foo.cpp" files would collide). * The "FindBISON" module "BISON_TARGET" macro now supports special characters by passing the "VERBATIM" option to internal "add_custom_command()" calls. This may break clients that added escaping manually to work around the bug. * The "FindFLEX" module "FLEX_TARGET" macro now supports special characters by passing the "VERBATIM" option to internal "add_custom_command()" calls. This may break clients that added escaping manually to work around the bug. * The "FindProtobuf" module input and output variables were all renamed from "PROTOBUF_" to "Protobuf_" for consistency with other find modules. Input variables of the old case will be honored if provided, and output variables of the old case are always provided. * The "CPackRPM" module now supports upper cased component names in per component CPackRPM specific variables. E.g. component named "foo" now expects component specific variable to be "CPACK_RPM_FOO_PACKAGE_NAME" while before it expected "CPACK_RPM_foo_PACKAGE_NAME". Upper cased component name part in variables is compatible with convention used for other CPack variables. For back compatibility old format of variables is still valid and preferred if both versions of variable are set, but the preferred future use is upper cased component names in variables. New variables that will be added to CPackRPM in later versions will only support upper cased component variable format. ---------------------------------------------------------------------------- Changes made since CMake 3.6.0-rc2: Brad King (5): VS: Fix regressed mapping for the cl `/Os` compiler flag README: Update Issue Tracker link to new location FindQt4: Document Qt4::QtDeclarative imported target (#16157) Help: Clarify VS_STARTUP_PROJECT documentation CMake 3.6.0-rc3 Domen Vrankar (2): CPack/Deb: Fix tests for SELinux-enabled systems CPack/Deb: Fix test to actually test the preinst script LibArchive Upstream (1): LibArchive 2016-06-19 (139d0576) Rolf Eike Beer (1): FindPkgConfig: define the imported targets also when the data comes from cache Tobias Hunger (1): cmExtraCodeBlocksGenerator: Do not shuffle include directories From crestchristopher at gmail.com Wed Jun 22 20:30:23 2016 From: crestchristopher at gmail.com (Crest Christopher) Date: Wed, 22 Jun 2016 20:30:23 -0400 Subject: [CMake] Compiling binaries with cmake -- help Message-ID: <576B2D9F.7090400@gmail.com> Hi, I'm hoping I can get some help on how to compile a repository from github which is local on my machine with a series of folders which contain CPP extension files. I have chosen the folders for which most likely contain the correct files to compile the binaries followed by the folder to which to build the binaries then I have chosen generate but I'm getting an error that the project files are invalid ? From nicholas11braden at gmail.com Wed Jun 22 20:44:14 2016 From: nicholas11braden at gmail.com (Nicholas Braden) Date: Wed, 22 Jun 2016 19:44:14 -0500 Subject: [CMake] Dependency on imported target with ninja-generator In-Reply-To: <20160622175933.18907b01@posteo.de> References: <20160622175933.18907b01@posteo.de> Message-ID: If Project B depends on Project A, you should probably be using the ExternalProject module with a superproject structure that builds both projects in the proper order. https://cmake.org/cmake/help/latest/module/ExternalProject.html Trying to manually call CMake is not really a good idea IMO - let ExternalProject handle it for you. On Wed, Jun 22, 2016 at 10:59 AM, Patrick Boettcher wrote: > Hi list, > > I'm finding myself in the following situation. > > - Project A generates libmain.a and export(TARGETS ... NAMESPACE ns) it > to a file. The target is called ns::main > > - Project B includes this file and has some executables link with > libmain.a (via target_link_libraries(exe ns::main). > > - Project B's CMakeLists.txt contains a add_custom_target(build ...) > which runs cmake --build in project A's build-dir. > > - the target build is a add_dependency() of ns::main. > > Building it with gnu-make works like a charm - make is entering project > A's build-dir before linking. > > Building it with ninja fails with not finding libmain.a - which is > normal it has not yet been built. Ninja seems to evaluate the complete > dependency-tree of files before doing anything. > > Is there a way to fix this? > > Thanks. > > best regards, > -- > Patrick. > > > > -- > > 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 nicholas11braden at gmail.com Wed Jun 22 20:50:40 2016 From: nicholas11braden at gmail.com (Nicholas Braden) Date: Wed, 22 Jun 2016 19:50:40 -0500 Subject: [CMake] Compiling binaries with cmake -- help In-Reply-To: <576B2D9F.7090400@gmail.com> References: <576B2D9F.7090400@gmail.com> Message-ID: Are you trying to use an existing CMakeLists.txt, or are you trying to create your own? CMake doesn't just work on source files alone. On Wed, Jun 22, 2016 at 7:30 PM, Crest Christopher wrote: > Hi, I'm hoping I can get some help on how to compile a repository from > github which is local on my machine with a series of folders which contain > CPP extension files. > > I have chosen the folders for which most likely contain the correct files to > compile the binaries followed by the folder to which to build the binaries > then I have chosen generate but I'm getting an error that the project files > are invalid ? > -- > > 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 crestchristopher at gmail.com Thu Jun 23 00:31:46 2016 From: crestchristopher at gmail.com (Crest Christopher) Date: Thu, 23 Jun 2016 00:31:46 -0400 Subject: [CMake] Compiling binaries with cmake -- help In-Reply-To: References: <576B2D9F.7090400@gmail.com> Message-ID: <576B6632.7010706@gmail.com> Hi, I'm trying to use an existing CMakeList.txt file. > Nicholas Braden > Wednesday, June 22, 2016 8:50 PM > Are you trying to use an existing CMakeLists.txt, or are you trying to > create your own? CMake doesn't just work on source files alone. > > On Wed, Jun 22, 2016 at 7:30 PM, Crest Christopher > Crest Christopher > Wednesday, June 22, 2016 8:30 PM > Hi, I'm hoping I can get some help on how to compile a repository from > github which is local on my machine with a series of folders which > contain CPP extension files. > > I have chosen the folders for which most likely contain the correct > files to compile the binaries followed by the folder to which to build > the binaries then I have chosen generate but I'm getting an error that > the project files are invalid ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From meinemailingliste2 at online.de Thu Jun 23 00:45:01 2016 From: meinemailingliste2 at online.de (Martin Maurer) Date: Thu, 23 Jun 2016 06:45:01 +0200 Subject: [CMake] Compiling binaries with cmake -- help In-Reply-To: <576B6632.7010706@gmail.com> References: <576B2D9F.7090400@gmail.com> <576B6632.7010706@gmail.com> Message-ID: <611F4C8C6DD445C6957D50BA73C22025@quad> Hello, how about to share the github URL, which file you have downloaded or project you want to compile? I think this would make it much easier for readers to help. Best regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From crestchristopher at gmail.com Thu Jun 23 00:56:20 2016 From: crestchristopher at gmail.com (Crest Christopher) Date: Thu, 23 Jun 2016 00:56:20 -0400 Subject: [CMake] Compiling binaries with cmake -- help In-Reply-To: <611F4C8C6DD445C6957D50BA73C22025@quad> References: <576B2D9F.7090400@gmail.com> <576B6632.7010706@gmail.com> <611F4C8C6DD445C6957D50BA73C22025@quad> Message-ID: <576B6BF4.6040806@gmail.com> Hi, here is the github URL; I hope it will help, to help me understand how to compile and use should I come across a cMaker compiler installation in the future. > Martin Maurer > Thursday, June 23, 2016 12:45 AM > Hello, > how about to share the github URL, > which file you have downloaded or project you want to compile? > I think this would make it much easier for readers to help. > Best regards, > Martin > Nicholas Braden > Wednesday, June 22, 2016 8:50 PM > Are you trying to use an existing CMakeLists.txt, or are you trying to > create your own? CMake doesn't just work on source files alone. > > On Wed, Jun 22, 2016 at 7:30 PM, Crest Christopher > Crest Christopher > Wednesday, June 22, 2016 8:30 PM > Hi, I'm hoping I can get some help on how to compile a repository from > github which is local on my machine with a series of folders which > contain CPP extension files. > > I have chosen the folders for which most likely contain the correct > files to compile the binaries followed by the folder to which to build > the binaries then I have chosen generate but I'm getting an error that > the project files are invalid ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicholas11braden at gmail.com Thu Jun 23 01:08:11 2016 From: nicholas11braden at gmail.com (Nicholas Braden) Date: Thu, 23 Jun 2016 00:08:11 -0500 Subject: [CMake] Compiling binaries with cmake -- help In-Reply-To: <576B6BF4.6040806@gmail.com> References: <576B2D9F.7090400@gmail.com> <576B6632.7010706@gmail.com> <611F4C8C6DD445C6957D50BA73C22025@quad> <576B6BF4.6040806@gmail.com> Message-ID: It looks like the instructions are there in the README. I tried building on my system but I'm missing some dependencies (e.g. at some point it finds my Python 3 installation and tries to run some code but fails due to a missing sipconfig module, which I am not familiar with). Generally, to build a project that uses CMake, create an empty directory for the build and open a terminal in it, then run CMake with the path to the directory containing CMakeLists.txt and optionally specify the generator to use if the default is not the one you want. Then, if it completes without errors, you can use "cmake --build ." to build it and "cmake --build . --target install" to install it, even if you used an IDE generator. As for the project dependencies, you are own your own to get those. On Wed, Jun 22, 2016 at 11:56 PM, Crest Christopher wrote: > Hi, here is the github URL; I hope it will help, to help me understand how > to compile and use should I come across a cMaker compiler installation in > the future. > > Martin Maurer > Thursday, June 23, 2016 12:45 AM > Hello, > > how about to share the github URL, > which file you have downloaded or project you want to compile? > > I think this would make it much easier for readers to help. > > Best regards, > > Martin > > Nicholas Braden > Wednesday, June 22, 2016 8:50 PM > Are you trying to use an existing CMakeLists.txt, or are you trying to > create your own? CMake doesn't just work on source files alone. > > On Wed, Jun 22, 2016 at 7:30 PM, Crest Christopher > Crest Christopher > Wednesday, June 22, 2016 8:30 PM > Hi, I'm hoping I can get some help on how to compile a repository from > github which is local on my machine with a series of folders which contain > CPP extension files. > > I have chosen the folders for which most likely contain the correct files to > compile the binaries followed by the folder to which to build the binaries > then I have chosen generate but I'm getting an error that the project files > are invalid ? > > > > -- > > 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 crestchristopher at gmail.com Thu Jun 23 01:10:40 2016 From: crestchristopher at gmail.com (Crest Christopher) Date: Thu, 23 Jun 2016 01:10:40 -0400 Subject: [CMake] Compiling binaries with cmake -- help In-Reply-To: References: <576B2D9F.7090400@gmail.com> <576B6632.7010706@gmail.com> <611F4C8C6DD445C6957D50BA73C22025@quad> <576B6BF4.6040806@gmail.com> Message-ID: <576B6F50.9030802@gmail.com> It can work, but it's missing dependencies ? > Nicholas Braden > Thursday, June 23, 2016 1:08 AM > It looks like the instructions are there in the README. I tried > building on my system but I'm missing some dependencies (e.g. at some > point it finds my Python 3 installation and tries to run some code but > fails due to a missing sipconfig module, which I am not familiar > with). > > Generally, to build a project that uses CMake, create an empty > directory for the build and open a terminal in it, then run CMake with > the path to the directory containing CMakeLists.txt and optionally > specify the generator to use if the default is not the one you want. > Then, if it completes without errors, you can use "cmake --build ." to > build it and "cmake --build . --target install" to install it, even if > you used an IDE generator. > > As for the project dependencies, you are own your own to get those. > > On Wed, Jun 22, 2016 at 11:56 PM, Crest Christopher > Martin Maurer > Thursday, June 23, 2016 12:45 AM > Hello, > how about to share the github URL, > which file you have downloaded or project you want to compile? > I think this would make it much easier for readers to help. > Best regards, > Martin > Nicholas Braden > Wednesday, June 22, 2016 8:50 PM > Are you trying to use an existing CMakeLists.txt, or are you trying to > create your own? CMake doesn't just work on source files alone. > > On Wed, Jun 22, 2016 at 7:30 PM, Crest Christopher > Crest Christopher > Wednesday, June 22, 2016 8:30 PM > Hi, I'm hoping I can get some help on how to compile a repository from > github which is local on my machine with a series of folders which > contain CPP extension files. > > I have chosen the folders for which most likely contain the correct > files to compile the binaries followed by the folder to which to build > the binaries then I have chosen generate but I'm getting an error that > the project files are invalid ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicholas11braden at gmail.com Thu Jun 23 01:15:21 2016 From: nicholas11braden at gmail.com (Nicholas Braden) Date: Thu, 23 Jun 2016 00:15:21 -0500 Subject: [CMake] Compiling binaries with cmake -- help In-Reply-To: <576B6F50.9030802@gmail.com> References: <576B2D9F.7090400@gmail.com> <576B6632.7010706@gmail.com> <611F4C8C6DD445C6957D50BA73C22025@quad> <576B6BF4.6040806@gmail.com> <576B6F50.9030802@gmail.com> Message-ID: Yes, many projects do not include their dependencies and require you to obtain them yourself. In this case it looks like you need the Python sipconfig module installed. On Thu, Jun 23, 2016 at 12:10 AM, Crest Christopher wrote: > It can work, but it's missing dependencies ? > > Nicholas Braden > Thursday, June 23, 2016 1:08 AM > It looks like the instructions are there in the README. I tried > building on my system but I'm missing some dependencies (e.g. at some > point it finds my Python 3 installation and tries to run some code but > fails due to a missing sipconfig module, which I am not familiar > with). > > Generally, to build a project that uses CMake, create an empty > directory for the build and open a terminal in it, then run CMake with > the path to the directory containing CMakeLists.txt and optionally > specify the generator to use if the default is not the one you want. > Then, if it completes without errors, you can use "cmake --build ." to > build it and "cmake --build . --target install" to install it, even if > you used an IDE generator. > > As for the project dependencies, you are own your own to get those. > > On Wed, Jun 22, 2016 at 11:56 PM, Crest Christopher > Martin Maurer > Thursday, June 23, 2016 12:45 AM > Hello, > > how about to share the github URL, > which file you have downloaded or project you want to compile? > > I think this would make it much easier for readers to help. > > Best regards, > > Martin > > Nicholas Braden > Wednesday, June 22, 2016 8:50 PM > Are you trying to use an existing CMakeLists.txt, or are you trying to > create your own? CMake doesn't just work on source files alone. > > On Wed, Jun 22, 2016 at 7:30 PM, Crest Christopher > Crest Christopher > Wednesday, June 22, 2016 8:30 PM > Hi, I'm hoping I can get some help on how to compile a repository from > github which is local on my machine with a series of folders which contain > CPP extension files. > > I have chosen the folders for which most likely contain the correct files to > compile the binaries followed by the folder to which to build the binaries > then I have chosen generate but I'm getting an error that the project files > are invalid ? > > From crestchristopher at gmail.com Thu Jun 23 01:20:58 2016 From: crestchristopher at gmail.com (Crest Christopher) Date: Thu, 23 Jun 2016 01:20:58 -0400 Subject: [CMake] Compiling binaries with cmake -- help In-Reply-To: References: <576B2D9F.7090400@gmail.com> <576B6632.7010706@gmail.com> <611F4C8C6DD445C6957D50BA73C22025@quad> <576B6BF4.6040806@gmail.com> <576B6F50.9030802@gmail.com> Message-ID: <576B71BA.1060804@gmail.com> I'll get the Python sipconfig module installed, then I hope we can continue with getting it compiled ? > Nicholas Braden > Thursday, June 23, 2016 1:15 AM > Yes, many projects do not include their dependencies and require you > to obtain them yourself. In this case it looks like you need the > Python sipconfig module installed. > > On Thu, Jun 23, 2016 at 12:10 AM, Crest Christopher > Nicholas Braden > Thursday, June 23, 2016 1:08 AM > It looks like the instructions are there in the README. I tried > building on my system but I'm missing some dependencies (e.g. at some > point it finds my Python 3 installation and tries to run some code but > fails due to a missing sipconfig module, which I am not familiar > with). > > Generally, to build a project that uses CMake, create an empty > directory for the build and open a terminal in it, then run CMake with > the path to the directory containing CMakeLists.txt and optionally > specify the generator to use if the default is not the one you want. > Then, if it completes without errors, you can use "cmake --build ." to > build it and "cmake --build . --target install" to install it, even if > you used an IDE generator. > > As for the project dependencies, you are own your own to get those. > > On Wed, Jun 22, 2016 at 11:56 PM, Crest Christopher > Martin Maurer > Thursday, June 23, 2016 12:45 AM > Hello, > how about to share the github URL, > which file you have downloaded or project you want to compile? > I think this would make it much easier for readers to help. > Best regards, > Martin > Nicholas Braden > Wednesday, June 22, 2016 8:50 PM > Are you trying to use an existing CMakeLists.txt, or are you trying to > create your own? CMake doesn't just work on source files alone. > > On Wed, Jun 22, 2016 at 7:30 PM, Crest Christopher > Crest Christopher > Wednesday, June 22, 2016 8:30 PM > Hi, I'm hoping I can get some help on how to compile a repository from > github which is local on my machine with a series of folders which > contain CPP extension files. > > I have chosen the folders for which most likely contain the correct > files to compile the binaries followed by the folder to which to build > the binaries then I have chosen generate but I'm getting an error that > the project files are invalid ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From Martin.Wagner at neuberger.net Thu Jun 23 04:19:49 2016 From: Martin.Wagner at neuberger.net (Wagner Martin) Date: Thu, 23 Jun 2016 08:19:49 +0000 Subject: [CMake] C header file cross dependency In-Reply-To: <20160606113628.6a729d17@posteo.de> References: <56E920142ED81D4FBE3260E4B9D1DB3E97208951@ROTSRV13.Neuberger.local> <20160525113902.0eb6f70d@posteo.de> <56E920142ED81D4FBE3260E4B9D1DB3E97208FAB@ROTSRV13.Neuberger.local> <20160606113628.6a729d17@posteo.de> Message-ID: <56E920142ED81D4FBE3260E4B9D1DB3E97283CDF@ROTSRV13.Neuberger.local> Hi Patrick, thank you for your answer and sorry that it took me a while to work on it. > > I forked your repo and played a little bit around. > > https://github.com/pboettch/test_cmake I pulled those changes and played aroud a bit myself. https://github.com/martinwag/test_cmake I'm now back at the point where I decided to use cmake's OBJECTS functionality. I didn't find any other way to pack all compiled products into an easy-to-include-and-link package for the application. I was unable to use target_link_libraries() because this actually wants to do linking instead of just packaging. The way you used it add_library(bsp INTERFACE) target_link_libraries(bsp INTERFACE drivers terminal) install(TARGETS bsp DESTINATION ${ARCHIVE_INSTALL_DIR}) the install command runs, but does not install anything, resulting in an archive with just the headers. I'm open to package the archive in a different way - install(EXPORT ...) seems promising. The important thing to me is that the consuming application doesn't need inside knowledge of the bsp package. > > Here are my conclusions: > > 1) Due to the use of add_libary(... OBJECTS ...) you cannot link > libraries with libraries or interfaces, this is a pity - especially for > a complex project with a lot of sub-dirs. > > There is a possibility to merge STATIC-libraries to generated one big > archive using external tools (libtool). If I were you I'd try to this > way to profit from the target_*-cmake-features. See above. > > 2) I created a log-dir with an interface-library - which only carries > the log.h and thus the printf-prototypes > > 3) Both, drivers and terminal link with this interface-library (to get > their hands on log.h) > This sounds good - I have to check if that works in the (more complex) production code. > 4) In addition I added two libraries to drivers/ uart-logging1 and uart- > logging2. This shows how you could compile-configure your printf- > function depending on the hardware used. In the main CMakeLists you just > need to select one of them - depending on the option's value. > > Basically I followed the idea of instantiating a print-function > 'somewhere' in the project (it could also be done outside) and then > select the one you want to use at the final link. > > Of course this way you could add other ways of printf'ing - logging1 and > logging2 are just stupid examples. This is -more or less- already in my production code. I want to do all this stuff in one configuration header file inside the application. However, I think it's a good idea to have the option to replace the printing function with "anything". I removed that part to keep the example as simple as possible. > > HTH and sorry for the delay, Obviously I'm not the fastest myself :-). Regards, Martin From james at pspdfkit.com Thu Jun 23 08:27:42 2016 From: james at pspdfkit.com (James Swift) Date: Thu, 23 Jun 2016 14:27:42 +0200 Subject: [CMake] CXX_STANDARD and -std=c++14 Message-ID: Hi, is there a way (or can it be added) to get set_property(TARGET target PROPERTY CXX_STANDARD 14) to output -std=c++14 and not -std=gnu++14 when needed? Thanks, James Swift -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicholas11braden at gmail.com Thu Jun 23 08:34:37 2016 From: nicholas11braden at gmail.com (Nicholas Braden) Date: Thu, 23 Jun 2016 07:34:37 -0500 Subject: [CMake] CXX_STANDARD and -std=c++14 In-Reply-To: References: Message-ID: This was asked recently - have a look at the CXX_EXTENSIONS property: https://cmake.org/cmake/help/latest/prop_tgt/CXX_EXTENSIONS.html Previous discussion: http://public.kitware.com/pipermail/cmake/2016-June/063691.html On Thu, Jun 23, 2016 at 7:27 AM, James Swift wrote: > Hi, > > is there a way (or can it be added) to get set_property(TARGET target > PROPERTY CXX_STANDARD 14) to output -std=c++14 and not -std=gnu++14 when > needed? > > Thanks, > James Swift > > > -- > > 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 nicholas11braden at gmail.com Thu Jun 23 08:37:01 2016 From: nicholas11braden at gmail.com (Nicholas Braden) Date: Thu, 23 Jun 2016 07:37:01 -0500 Subject: [CMake] Compiling binaries with cmake -- help In-Reply-To: <576B71BA.1060804@gmail.com> References: <576B2D9F.7090400@gmail.com> <576B6632.7010706@gmail.com> <611F4C8C6DD445C6957D50BA73C22025@quad> <576B6BF4.6040806@gmail.com> <576B6F50.9030802@gmail.com> <576B71BA.1060804@gmail.com> Message-ID: Yep, if you have all the dependencies it should just work as I described in a previous message. On Thu, Jun 23, 2016 at 12:20 AM, Crest Christopher wrote: > I'll get the Python sipconfig module installed, then I hope we can continue > with getting it compiled ? > > Nicholas Braden > Thursday, June 23, 2016 1:15 AM > Yes, many projects do not include their dependencies and require you > to obtain them yourself. In this case it looks like you need the > Python sipconfig module installed. > > On Thu, Jun 23, 2016 at 12:10 AM, Crest Christopher > Nicholas Braden > Thursday, June 23, 2016 1:08 AM > It looks like the instructions are there in the README. I tried > building on my system but I'm missing some dependencies (e.g. at some > point it finds my Python 3 installation and tries to run some code but > fails due to a missing sipconfig module, which I am not familiar > with). > > Generally, to build a project that uses CMake, create an empty > directory for the build and open a terminal in it, then run CMake with > the path to the directory containing CMakeLists.txt and optionally > specify the generator to use if the default is not the one you want. > Then, if it completes without errors, you can use "cmake --build ." to > build it and "cmake --build . --target install" to install it, even if > you used an IDE generator. > > As for the project dependencies, you are own your own to get those. > > On Wed, Jun 22, 2016 at 11:56 PM, Crest Christopher > Martin Maurer > Thursday, June 23, 2016 12:45 AM > Hello, > > how about to share the github URL, > which file you have downloaded or project you want to compile? > > I think this would make it much easier for readers to help. > > Best regards, > > Martin > > Nicholas Braden > Wednesday, June 22, 2016 8:50 PM > Are you trying to use an existing CMakeLists.txt, or are you trying to > create your own? CMake doesn't just work on source files alone. > > On Wed, Jun 22, 2016 at 7:30 PM, Crest Christopher > Crest Christopher > Wednesday, June 22, 2016 8:30 PM > Hi, I'm hoping I can get some help on how to compile a repository from > github which is local on my machine with a series of folders which contain > CPP extension files. > > I have chosen the folders for which most likely contain the correct files to > compile the binaries followed by the folder to which to build the binaries > then I have chosen generate but I'm getting an error that the project files > are invalid ? > > From james at pspdfkit.com Thu Jun 23 08:37:26 2016 From: james at pspdfkit.com (James Swift) Date: Thu, 23 Jun 2016 14:37:26 +0200 Subject: [CMake] CXX_STANDARD and -std=c++14 In-Reply-To: References: Message-ID: Thanks, Nicholas. Might be worth adding a link to that from this page. https://cmake.org/cmake/help/latest/prop_tgt/CXX_STANDARD.html?highlight=cxx_standard On 23 June 2016 at 14:34, Nicholas Braden wrote: > This was asked recently - have a look at the CXX_EXTENSIONS property: > https://cmake.org/cmake/help/latest/prop_tgt/CXX_EXTENSIONS.html > > Previous discussion: > http://public.kitware.com/pipermail/cmake/2016-June/063691.html > > On Thu, Jun 23, 2016 at 7:27 AM, James Swift wrote: > > Hi, > > > > is there a way (or can it be added) to get set_property(TARGET target > > PROPERTY CXX_STANDARD 14) to output -std=c++14 and not -std=gnu++14 when > > needed? > > > > Thanks, > > James Swift > > > > > > -- > > > > 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 elizabeth.fischer at columbia.edu Thu Jun 23 08:53:45 2016 From: elizabeth.fischer at columbia.edu (Elizabeth A. Fischer) Date: Thu, 23 Jun 2016 08:53:45 -0400 Subject: [CMake] CXX_STANDARD and -std=c++14 In-Reply-To: References: Message-ID: At the risk of repeating myself... it's a non-intuitive "gotcha" that set_property(TARGET target PROPERTY CXX_STANDARD 14) results in something OTHER than the C++14 standard. The issue is likely to continue tripping people up, resulting in continued posts to this email list. If you want C++14 with GNU extensions, you should have to do something like: set_property(TARGET target PROPERTY CXX_STANDARD GNU14) which would throw an error if you try it with any non-GNU compiler. -- Elizabeth On Thu, Jun 23, 2016 at 8:37 AM, James Swift wrote: > Thanks, Nicholas. > > Might be worth adding a link to that from this page. > > > https://cmake.org/cmake/help/latest/prop_tgt/CXX_STANDARD.html?highlight=cxx_standard > > On 23 June 2016 at 14:34, Nicholas Braden > wrote: > >> This was asked recently - have a look at the CXX_EXTENSIONS property: >> https://cmake.org/cmake/help/latest/prop_tgt/CXX_EXTENSIONS.html >> >> Previous discussion: >> http://public.kitware.com/pipermail/cmake/2016-June/063691.html >> >> On Thu, Jun 23, 2016 at 7:27 AM, James Swift wrote: >> > Hi, >> > >> > is there a way (or can it be added) to get set_property(TARGET target >> > PROPERTY CXX_STANDARD 14) to output -std=c++14 and not -std=gnu++14 when >> > needed? >> > >> > Thanks, >> > James Swift >> > >> > >> > -- >> > >> > 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 iraytrace at gmail.com Thu Jun 23 11:13:44 2016 From: iraytrace at gmail.com (Lee Butler) Date: Thu, 23 Jun 2016 11:13:44 -0400 Subject: [CMake] gathering directory names in cmake In-Reply-To: References: Message-ID: <576BFCA8.9070508@gmail.com> Alas, this has no effect. Consider the following shell script: ----------------------------------------------------------------- #!/bin/sh if [ -d attempt ] ; then rm -rf attempt ; fi mkdir attempt cd attempt for d in src src/app src/plugins/one ; do mkdir -p $d/xyz touch $d/xyz/one.txt touch $d/xyz/two.txt done PATTERN="\${CMAKE_SOURCE_DIR}/src/*xyz/" cat > CMakeLists.txt < On Mon, Jun 20, 2016 at 8:47 PM, Lee Butler wrote: > >> >I have a source tree which contains multiple directories each of which has >> >a subdirectory called "xyz". I want to create a target that creates a zip >> >file with each of the xyz directories. So if the source tree looks like >> > src >> > src/xyz >> >src/application >> >src/application/xyz >> >src/plugins/one/xyz >> > >> >I want to end up with a zip file containing: >> > src/xyz/* >> >src/application/xyz/* >> >src/plugins/one/xyz/* >> > >> >On unix I could just generate the list of these directories with: >> > find src -type d -name test -print >> >alas, I need a cross-platform way to do this. >> > >> >I tried: >> > file(GLOB_RECURSE XYZFILES "${CMAKE_SOURCE_DIR}/src/*xyz) >> >and got nothing. >> > >> >At the moment, it looks like I cannot wildcard any portion of the >> >directory path. The following: >> > file(GLOB_RECURSE XYZFILES "${CMAKE_SOURCE_DIR}/src/*xyz*") >> > > what about adding a backslash at end of expression ? > file(GLOB_RECURSE XYZFILES "${CMAKE_SOURCE_DIR}/src/*xyz/") > > > seems to only produce files which have xyz in their name. >> > >> >Lee >> >-- >> > >> -- Regards, Rashad -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfyzium at gmail.com Thu Jun 23 13:31:41 2016 From: cfyzium at gmail.com (Cfyz) Date: Thu, 23 Jun 2016 20:31:41 +0300 Subject: [CMake] What is the best way to *export* the transitive dependencies of a library? Message-ID: Say the executable Exe uses some static library Foo which uses other libraries, e. g. Bar: Exe --> Foo --> Bar As the developer of Foo and I want to make it easy to link against: find_package(Foo REQUIRED) target_link_libraries(Exe PRIVATE Foo) The problem lies with the various dependencies of Foo necessary to use it: definitions, include directories, libraries. The Foo is a complex multimedia-processing library with a wide range of configuration options, so there is a reason why a lot of information may be necessary to use it in another project. The official (and quite neat) way to prepare a configuration module (FooConfig.cmake) is to use install/export commands: install(TARGETS Foo EXPORT FooExport DESTINATION lib) install(EXPORT FooExport DESTINATION lib/cmake/Foo FILE FooConfig.cmake) That, however does not export transitive properties of the target. If, for example there was some Bar dependency: find_package(Bar REQUIRED) target_link_libraries(Foo PUBLIC Bar) Then it will indeed use INTERFACE_xxx properties of Bar while building Foo. But FooConfig.cmake will only list a lone Bar dependency in the INTERFACE_LINK_LIBRARIES property of an imported Foo target: add_library(Foo STATIC IMPORTED) set_target_properties(Foo PROPERTIES ... INTERFACE_LINK_LIBRARIES "...;Bar") Which, obviously, is not enough to link against the Foo target in another project. This behavior is mentioned a bit in CMake documentation: "Note that it is not advisable to populate the INTERFACE_LINK_LIBRARIES of a target with paths for dependencies. That would hard-code into installed packages the include directory paths for dependencies as found on the machine the package was made on." Which is probably the reason why CMake does not export interface part of dependencies itself. But I do not see any way around it. By not including transitive dependencies in configuration module, the responsibility to search for those dependencies is shifted to the Exe project. But Exe cannot know which dependencies were enabled during particular Foo's configuration or where to search for them. Is this a bug? I'd expect there to be at least an option to include transitive dependencies during the export. There is EXPORT_LINK_INTERFACE_LIBRARIES option but it uses deprecated properties and has no visible effect. Or am I missing something here? What is the proper way to go around this issue? It is not hard to come up with a workaround, in fact. It should be enough to populate the INTERFACE_xxx (COMPILE_DEFINITIONS, INCLUDE_DIRECTORIES, LINK_LIBRARIES, maybe SYSTEM_INCLUDE_DIRECTORIES as well) properties of Foo with contents of respective INTERFACE_xxx properties of all Foo's dependencies. That, however, will require to include a rather noticeable piece of homebrew (and somewhat obscure) code to every project trying to export imported dependencies. Not elegant, will probably break in some corner case and hard to sell while advertising CMake to collegues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michele.portolan at imag.fr Fri Jun 24 10:52:16 2016 From: michele.portolan at imag.fr (portolan) Date: Fri, 24 Jun 2016 16:52:16 +0200 Subject: [CMake] Configuring CxxTest Message-ID: Hello, I setup my first cmake projet, but I have some problems with generating my CxxTest suite. I can easily call up the CxxTest packgage and specify the generator using "CXXTEST_PYTHON_TESTGEN_EXECUTABLE" following the instruction of the documentation (https://cmake.org/cmake/help/v3.0/module/FindCxxTest.html) . But how can I specify parameters to the generator? Most notably I use a template so I would need to have something along the lines of "--template Runner.tpl". Thanks, Michele From Andreas-Naumann at gmx.net Fri Jun 24 13:48:07 2016 From: Andreas-Naumann at gmx.net (Andreas Naumann) Date: Fri, 24 Jun 2016 19:48:07 +0200 Subject: [CMake] subversion Message-ID: <576D7257.1050303@gmx.net> Dear cmake users, I have a question if, and how, you use the Subversion module of cmake. The module provides the macro Subversion_WC_INFO, which extracts information of a working copy. I use this information, to generate a sub minor revision number of my project. If I checkout my project using svn, it works. But if I export it, the modules failes with a fatal error. At the moment, I check, if my directory is a working copy and if it is not, the version variable is not defined. In my oppinion, it would be better, if the macro from the subversion module would simply define a variable "is_working_directory" instead of failing hard. What do you think about this idea? How do you use the subversion module? The patch would be easy, and I would send one to the developer mailing list, if desired. Regards, Andreas From cfyzium at gmail.com Fri Jun 24 14:04:21 2016 From: cfyzium at gmail.com (Cfyz) Date: Fri, 24 Jun 2016 21:04:21 +0300 Subject: [CMake] gathering directory names in cmake Message-ID: > I have a source tree which contains multiple directories each of > which has a subdirectory called "xyz". I want to create a target > that creates a zip file with each of the xyz directories. You can filter the file paths with a few CMake script lines: file(GLOB_RECURSE FILES "./*") foreach(FILE ${FILES}) if(FILE MATCHES ".*/xyz/.*") list(APPEND XYZ_FILES ${FILE}) endif() endforeach() Now XYZ_FILES contains a list of files with /xyz/ subdirectory somewhere in their path. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ruslan_baratov at yahoo.com Fri Jun 24 16:06:16 2016 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Fri, 24 Jun 2016 23:06:16 +0300 Subject: [CMake] CMake terminology Message-ID: <79a10531-b80d-dc01-e3e8-a85021c99099@yahoo.com> Hi, I have a question about CMake terminology. When we are using CMake GUI there are two buttons "Configure" and "Generate", hence we have two stages: 1. Configure step, when we do configuring project, effectively creating file with cache variables (which we can modify) without really generating native tools files like Makefile/*.sln/etc. 2. Generate step, when we do generating project using file with cache variables, i.e. create those Makefile/*.sln/etc. The question is about command line version of CMake. Since we do creating file with cache and generate native tools files in one step what is the right term? Is it a configure step because we read user's '-D' and create cache file? Is it a generate step because native tools files generated at the end? May be there is a third name to describe the fact that it's configure+generate step? Thanks, Ruslo From robert.maynard at kitware.com Fri Jun 24 16:25:04 2016 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 24 Jun 2016 16:25:04 -0400 Subject: [CMake] CMake terminology In-Reply-To: <79a10531-b80d-dc01-e3e8-a85021c99099@yahoo.com> References: <79a10531-b80d-dc01-e3e8-a85021c99099@yahoo.com> Message-ID: cmake from the command line is still running the two stages, it just doesn't allow for feedback/input from the user between the two stages. On Fri, Jun 24, 2016 at 4:06 PM, Ruslan Baratov via CMake wrote: > Hi, > > I have a question about CMake terminology. When we are using CMake GUI there > are two buttons "Configure" and "Generate", hence we have two stages: > > 1. Configure step, when we do configuring project, effectively creating file > with cache variables (which we can modify) without really generating native > tools files like Makefile/*.sln/etc. > > 2. Generate step, when we do generating project using file with cache > variables, i.e. create those Makefile/*.sln/etc. > > The question is about command line version of CMake. Since we do creating > file with cache and generate native tools files in one step what is the > right term? Is it a configure step because we read user's '-D' and create > cache file? Is it a generate step because native tools files generated at > the end? May be there is a third name to describe the fact that it's > configure+generate step? > > Thanks, Ruslo > -- > > 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 ruslan_baratov at yahoo.com Fri Jun 24 16:40:30 2016 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Fri, 24 Jun 2016 23:40:30 +0300 Subject: [CMake] CMake terminology In-Reply-To: References: <79a10531-b80d-dc01-e3e8-a85021c99099@yahoo.com> Message-ID: <3af3acbe-9c31-c5ab-ee3b-b92db84d24c1@yahoo.com> On 24-Jun-16 23:25, Robert Maynard wrote: > cmake from the command line is still running the two stages, it just > doesn't allow for feedback/input from the user between the two stages. Yes, I understand that. Question is about the name of the step. I.e. when I do write manual what should I choose Please run configure step by: cmake -H. -B_builds or Please run generate step by: cmake -H. -B_builds ? May be both versions are correct? Or both incorrect? Ruslo > > On Fri, Jun 24, 2016 at 4:06 PM, Ruslan Baratov via CMake > wrote: >> Hi, >> >> I have a question about CMake terminology. When we are using CMake GUI there >> are two buttons "Configure" and "Generate", hence we have two stages: >> >> 1. Configure step, when we do configuring project, effectively creating file >> with cache variables (which we can modify) without really generating native >> tools files like Makefile/*.sln/etc. >> >> 2. Generate step, when we do generating project using file with cache >> variables, i.e. create those Makefile/*.sln/etc. >> >> The question is about command line version of CMake. Since we do creating >> file with cache and generate native tools files in one step what is the >> right term? Is it a configure step because we read user's '-D' and create >> cache file? Is it a generate step because native tools files generated at >> the end? May be there is a third name to describe the fact that it's >> configure+generate step? >> >> Thanks, Ruslo >> -- >> >> 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 Fri Jun 24 16:49:16 2016 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 24 Jun 2016 16:49:16 -0400 Subject: [CMake] CMake terminology In-Reply-To: <3af3acbe-9c31-c5ab-ee3b-b92db84d24c1@yahoo.com> References: <79a10531-b80d-dc01-e3e8-a85021c99099@yahoo.com> <3af3acbe-9c31-c5ab-ee3b-b92db84d24c1@yahoo.com> Message-ID: Please run the configure and generate steps by On Fri, Jun 24, 2016 at 4:40 PM, Ruslan Baratov wrote: > > On 24-Jun-16 23:25, Robert Maynard wrote: >> >> cmake from the command line is still running the two stages, it just >> doesn't allow for feedback/input from the user between the two stages. > > Yes, I understand that. Question is about the name of the step. I.e. when I > do write manual what should I choose > Please run configure step by: cmake -H. -B_builds > or > Please run generate step by: cmake -H. -B_builds > ? > > May be both versions are correct? Or both incorrect? > > Ruslo > > >> >> On Fri, Jun 24, 2016 at 4:06 PM, Ruslan Baratov via CMake >> wrote: >>> >>> Hi, >>> >>> I have a question about CMake terminology. When we are using CMake GUI >>> there >>> are two buttons "Configure" and "Generate", hence we have two stages: >>> >>> 1. Configure step, when we do configuring project, effectively creating >>> file >>> with cache variables (which we can modify) without really generating >>> native >>> tools files like Makefile/*.sln/etc. >>> >>> 2. Generate step, when we do generating project using file with cache >>> variables, i.e. create those Makefile/*.sln/etc. >>> >>> The question is about command line version of CMake. Since we do creating >>> file with cache and generate native tools files in one step what is the >>> right term? Is it a configure step because we read user's '-D' and create >>> cache file? Is it a generate step because native tools files generated >>> at >>> the end? May be there is a third name to describe the fact that it's >>> configure+generate step? >>> >>> Thanks, Ruslo >>> -- >>> >>> 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 Fri Jun 24 17:03:57 2016 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Fri, 24 Jun 2016 17:03:57 -0400 Subject: [CMake] Qt 5.6.1 messes up Linux packaging using CPack? Message-ID: I have a project that uses CMake. I had been compiling against Qt 5.6.0 for a while but due to issues with QWebEngine I installed Qt 5.6.1 instead and compiled against that. I can run my application from the build directory but when I go to use cpack to package my application I am getting the following errors for every single one of my libraries that I build: CMake Error at SimpleITKExplicit/cmake_install.cmake:36 (file): file INSTALL cannot find "/home/mjackson/Workspace/DREAM3D-build/Release/SimpleITKExplicit/CMakeFiles/CMakeRelink.dir/libSimpleITKExplicit-0.9.so.1". Call Stack (most recent call first): cmake_install.cmake:435 (include) I recompiled in a completely separate directory against my Qt 5.6.0 installation and cpack will execute without any errors. Has anyone else seen this yet? Thanks _________________________________________________________ Mike Jackson mike.jackson at bluequartz.net BlueQuartz Software www.bluequartz.net Principal Software Engineer Dayton, Ohio -------------- next part -------------- An HTML attachment was scrubbed... URL: From ruslan_baratov at yahoo.com Fri Jun 24 17:28:41 2016 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Sat, 25 Jun 2016 00:28:41 +0300 Subject: [CMake] CMake terminology In-Reply-To: References: <79a10531-b80d-dc01-e3e8-a85021c99099@yahoo.com> <3af3acbe-9c31-c5ab-ee3b-b92db84d24c1@yahoo.com> Message-ID: <1194db79-2e13-9cad-35b0-1f58fdb171ac@yahoo.com> On 24-Jun-16 23:49, Robert Maynard wrote: > Please run the configure and generate steps by It's too long :) Also it doesn't express the fact that it's a single action, consider: "To add variables on configure and generate steps use '-D'" "Before running configure and generate steps note that old variables from cache can be used" etc. > > On Fri, Jun 24, 2016 at 4:40 PM, Ruslan Baratov > wrote: >> On 24-Jun-16 23:25, Robert Maynard wrote: >>> cmake from the command line is still running the two stages, it just >>> doesn't allow for feedback/input from the user between the two stages. >> Yes, I understand that. Question is about the name of the step. I.e. when I >> do write manual what should I choose >> Please run configure step by: cmake -H. -B_builds >> or >> Please run generate step by: cmake -H. -B_builds >> ? >> >> May be both versions are correct? Or both incorrect? >> >> Ruslo >> >> >>> On Fri, Jun 24, 2016 at 4:06 PM, Ruslan Baratov via CMake >>> wrote: >>>> Hi, >>>> >>>> I have a question about CMake terminology. When we are using CMake GUI >>>> there >>>> are two buttons "Configure" and "Generate", hence we have two stages: >>>> >>>> 1. Configure step, when we do configuring project, effectively creating >>>> file >>>> with cache variables (which we can modify) without really generating >>>> native >>>> tools files like Makefile/*.sln/etc. >>>> >>>> 2. Generate step, when we do generating project using file with cache >>>> variables, i.e. create those Makefile/*.sln/etc. >>>> >>>> The question is about command line version of CMake. Since we do creating >>>> file with cache and generate native tools files in one step what is the >>>> right term? Is it a configure step because we read user's '-D' and create >>>> cache file? Is it a generate step because native tools files generated >>>> at >>>> the end? May be there is a third name to describe the fact that it's >>>> configure+generate step? >>>> >>>> Thanks, Ruslo >>>> -- >>>> >>>> Powered by www.kitware.com >>>> >>>> Please keep messages on-topic and check the CMake FAQ at: >>>> http://www.cmake.org/Wiki/CMake_FAQ >>>> >>>> Kitware offers various services to support the CMake community. For more >>>> information on each offering, please visit: >>>> >>>> CMake Support: http://cmake.org/cmake/help/support.html >>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>>> >>>> Visit other Kitware open-source projects at >>>> http://www.kitware.com/opensource/opensource.html >>>> >>>> Follow this link to subscribe/unsubscribe: >>>> http://public.kitware.com/mailman/listinfo/cmake >> >> From craig.scott at crascit.com Fri Jun 24 19:13:18 2016 From: craig.scott at crascit.com (Craig Scott) Date: Sat, 25 Jun 2016 09:13:18 +1000 Subject: [CMake] CMake terminology In-Reply-To: <1194db79-2e13-9cad-35b0-1f58fdb171ac@yahoo.com> References: <79a10531-b80d-dc01-e3e8-a85021c99099@yahoo.com> <3af3acbe-9c31-c5ab-ee3b-b92db84d24c1@yahoo.com> <1194db79-2e13-9cad-35b0-1f58fdb171ac@yahoo.com> Message-ID: In documentation, blog articles, etc. I just call it the "cmake" step (or sometimes the "project setup" step if talking in a more project-wide sense). For many users, the separate configure and generate steps are somewhat of an implementation detail, so it makes more sense to give it a single term. I'm not aware of any generally accepted term, but the ones I use seem to be fairly easy to understand, especially for those new to CMake. YMMV. On Saturday, 25 June 2016, Ruslan Baratov via CMake wrote: > On 24-Jun-16 23:49, Robert Maynard wrote: > >> Please run the configure and generate steps by >> > It's too long :) > > Also it doesn't express the fact that it's a single action, consider: > "To add variables on configure and generate steps use '-D'" > "Before running configure and generate steps note that old variables > from cache can be used" > etc. > > > >> On Fri, Jun 24, 2016 at 4:40 PM, Ruslan Baratov >> wrote: >> >>> On 24-Jun-16 23:25, Robert Maynard wrote: >>> >>>> cmake from the command line is still running the two stages, it just >>>> doesn't allow for feedback/input from the user between the two stages. >>>> >>> Yes, I understand that. Question is about the name of the step. I.e. >>> when I >>> do write manual what should I choose >>> Please run configure step by: cmake -H. -B_builds >>> or >>> Please run generate step by: cmake -H. -B_builds >>> ? >>> >>> May be both versions are correct? Or both incorrect? >>> >>> Ruslo >>> >>> >>> On Fri, Jun 24, 2016 at 4:06 PM, Ruslan Baratov via CMake >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> I have a question about CMake terminology. When we are using CMake GUI >>>>> there >>>>> are two buttons "Configure" and "Generate", hence we have two stages: >>>>> >>>>> 1. Configure step, when we do configuring project, effectively creating >>>>> file >>>>> with cache variables (which we can modify) without really generating >>>>> native >>>>> tools files like Makefile/*.sln/etc. >>>>> >>>>> 2. Generate step, when we do generating project using file with cache >>>>> variables, i.e. create those Makefile/*.sln/etc. >>>>> >>>>> The question is about command line version of CMake. Since we do >>>>> creating >>>>> file with cache and generate native tools files in one step what is the >>>>> right term? Is it a configure step because we read user's '-D' and >>>>> create >>>>> cache file? Is it a generate step because native tools files generated >>>>> at >>>>> the end? May be there is a third name to describe the fact that it's >>>>> configure+generate step? >>>>> >>>>> Thanks, Ruslo >>>>> -- >>>>> >>>>> Powered by www.kitware.com >>>>> >>>>> Please keep messages on-topic and check the CMake FAQ at: >>>>> http://www.cmake.org/Wiki/CMake_FAQ >>>>> >>>>> Kitware offers various services to support the CMake community. For >>>>> more >>>>> information on each offering, please visit: >>>>> >>>>> CMake Support: http://cmake.org/cmake/help/support.html >>>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>>>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>>>> >>>>> Visit other Kitware open-source projects at >>>>> http://www.kitware.com/opensource/opensource.html >>>>> >>>>> Follow this link to subscribe/unsubscribe: >>>>> http://public.kitware.com/mailman/listinfo/cmake >>>>> >>>> >>> >>> > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -- Craig Scott Melbourne, Australia http://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ruslan_baratov at yahoo.com Fri Jun 24 20:33:03 2016 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Sat, 25 Jun 2016 03:33:03 +0300 Subject: [CMake] CMake terminology In-Reply-To: References: <79a10531-b80d-dc01-e3e8-a85021c99099@yahoo.com> <3af3acbe-9c31-c5ab-ee3b-b92db84d24c1@yahoo.com> <1194db79-2e13-9cad-35b0-1f58fdb171ac@yahoo.com> Message-ID: There is cmake **build** step: cmake --build _builds So in GUI it's: * cmake configure * cmake generate * IDE build (which you can do with cmake --build so it can be called "cmake build" step) in cmd: * cmake configure+generate * cmake build Also I can call it "cmake step" in docs about some C++ project, but if the docs about cmake itself I think this term is too wide On 25-Jun-16 02:13, Craig Scott wrote: > In documentation, blog articles, etc. I just call it the "cmake" step > (or sometimes the "project setup" step if talking in a more > project-wide sense). For many users, the separate configure and > generate steps are somewhat of an implementation detail, so it makes > more sense to give it a single term. I'm not aware of any generally > accepted term, but the ones I use seem to be fairly easy to > understand, especially for those new to CMake. YMMV. > > On Saturday, 25 June 2016, Ruslan Baratov via CMake > wrote: > > On 24-Jun-16 23:49, Robert Maynard wrote: > > Please run the configure and generate steps by > > It's too long :) > > Also it doesn't express the fact that it's a single action, consider: > "To add variables on configure and generate steps use '-D'" > "Before running configure and generate steps note that old > variables from cache can be used" > etc. > > > > On Fri, Jun 24, 2016 at 4:40 PM, Ruslan Baratov > wrote: > > On 24-Jun-16 23:25, Robert Maynard wrote: > > cmake from the command line is still running the two > stages, it just > doesn't allow for feedback/input from the user between > the two stages. > > Yes, I understand that. Question is about the name of the > step. I.e. when I > do write manual what should I choose > Please run configure step by: cmake -H. -B_builds > or > Please run generate step by: cmake -H. -B_builds > ? > > May be both versions are correct? Or both incorrect? > > Ruslo > > > On Fri, Jun 24, 2016 at 4:06 PM, Ruslan Baratov via CMake > wrote: > > Hi, > > I have a question about CMake terminology. When we > are using CMake GUI > there > are two buttons "Configure" and "Generate", hence > we have two stages: > > 1. Configure step, when we do configuring project, > effectively creating > file > with cache variables (which we can modify) without > really generating > native > tools files like Makefile/*.sln/etc. > > 2. Generate step, when we do generating project > using file with cache > variables, i.e. create those Makefile/*.sln/etc. > > The question is about command line version of > CMake. Since we do creating > file with cache and generate native tools files in > one step what is the > right term? Is it a configure step because we read > user's '-D' and create > cache file? Is it a generate step because native > tools files generated > at > the end? May be there is a third name to describe > the fact that it's > configure+generate step? > > Thanks, Ruslo > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake > FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the > CMake community. For more > information on each offering, please visit: > > CMake Support: > http://cmake.org/cmake/help/support.html > CMake Consulting: > http://cmake.org/cmake/help/consulting.html > CMake Training Courses: > http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > > > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. > For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > > > > -- > Craig Scott > Melbourne, Australia > http://crascit.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From umihhgm at gmail.com Sat Jun 25 02:09:04 2016 From: umihhgm at gmail.com (Hgfjj Hhjgf) Date: Sat, 25 Jun 2016 12:09:04 +0600 Subject: [CMake] Using CMake on CLion and adding geoip library Message-ID: I am trying to use an external library (GeoIP). CMake list contains: message(STATUS "Looking for MaxMind GeoIP header files") set(CMAKE_INCLUDE_PATH "${CMAKE_INCLUDE_PATH} ${GEOIP_INCLUDE_DIR}") check_include_file("GeoIP.h" HAVE_GEOIP_H) check_include_file("GeoIPCity.h" HAVE_GEOIPCITY_H) if (HAVE_GEOIP_H AND HAVE_GEOIPCITY_H) message(STATUS "Looking for MaxMind GeoIP header files - found") else(HAVE_GEOIP_H AND HAVE_GEOIPCITY_H) message(FATAL_ERROR "Could not find one or more MaxMind GeoIP header files. If the MaxMind GeoIP library is installed, you can run CMake again and specify its location with -DGEOIP_INCLUDE_DIR=") endif(HAVE_GEOIP_H AND HAVE_GEOIPCITY_H) message(STATUS "Looking for MaxMind GeoIP libraries") find_library(GEOIP_LIB NAMES GeoIP geoip PATHS ${GEOIP_LIBRARY_DIR} ) if (GEOIP_LIB) message(STATUS "Looking for MaxMind GeoIP libraries - found") set(GEOIP_LIBRARIES ${GEOIP_LIB}) else(GEOIP_LIB) message(FATAL_ERROR "Could not find MaxMind GeoIP library") endif(GEOIP_LIB) but getting error like "Unknown cmake command: check_include_file" what's the problem here then? -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.noulard at gmail.com Sat Jun 25 03:02:51 2016 From: eric.noulard at gmail.com (Eric Noulard) Date: Sat, 25 Jun 2016 09:02:51 +0200 Subject: [CMake] CMake terminology In-Reply-To: References: <79a10531-b80d-dc01-e3e8-a85021c99099@yahoo.com> <3af3acbe-9c31-c5ab-ee3b-b92db84d24c1@yahoo.com> <1194db79-2e13-9cad-35b0-1f58fdb171ac@yahoo.com> Message-ID: Hi there, I'd like to give my opinion here. I agree that the fact that the cmake ui (qt or curse) makes it possible to separate configure from generate is an implementation detail. In fact one could perfectly decide that the "configure" step should "generate " each time it is run. Making it two-step save some time for big project but I have already seen people forgetting to generate and asking themselves why they didn't get any makefiles... Nevertheless from a user point of view explaining that there are different "time" because CMake is a buid system **generator** and not a build tool seems very important to me. Some action may be run during CMake time some may be done during Build time. For me CMake run is configure+generate. I did gave a tutorial which is now a bit outdated where I tried to picture this. See attached file or: https://github.com/TheErk/CMake-tutorial my 2 cents. 2016-06-25 2:33 GMT+02:00 Ruslan Baratov via CMake : > There is cmake **build** step: cmake --build _builds > > So in GUI it's: > * cmake configure > * cmake generate > * IDE build (which you can do with cmake --build so it can be called > "cmake build" step) > > in cmd: > * cmake configure+generate > * cmake build > > Also I can call it "cmake step" in docs about some C++ project, but if the > docs about cmake itself I think this term is too wide > > > On 25-Jun-16 02:13, Craig Scott wrote: > > In documentation, blog articles, etc. I just call it the "cmake" step (or > sometimes the "project setup" step if talking in a more project-wide > sense). For many users, the separate configure and generate steps are > somewhat of an implementation detail, so it makes more sense to give it a > single term. I'm not aware of any generally accepted term, but the ones I > use seem to be fairly easy to understand, especially for those new to > CMake. YMMV. > > On Saturday, 25 June 2016, Ruslan Baratov via CMake < > cmake at cmake.org> wrote: > >> On 24-Jun-16 23:49, Robert Maynard wrote: >> >>> Please run the configure and generate steps by >>> >> It's too long :) >> >> Also it doesn't express the fact that it's a single action, consider: >> "To add variables on configure and generate steps use '-D'" >> "Before running configure and generate steps note that old variables >> from cache can be used" >> etc. >> >> >> >>> On Fri, Jun 24, 2016 at 4:40 PM, Ruslan Baratov >>> wrote: >>> >>>> On 24-Jun-16 23:25, Robert Maynard wrote: >>>> >>>>> cmake from the command line is still running the two stages, it just >>>>> doesn't allow for feedback/input from the user between the two stages. >>>>> >>>> Yes, I understand that. Question is about the name of the step. I.e. >>>> when I >>>> do write manual what should I choose >>>> Please run configure step by: cmake -H. -B_builds >>>> or >>>> Please run generate step by: cmake -H. -B_builds >>>> ? >>>> >>>> May be both versions are correct? Or both incorrect? >>>> >>>> Ruslo >>>> >>>> >>>> On Fri, Jun 24, 2016 at 4:06 PM, Ruslan Baratov via CMake >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I have a question about CMake terminology. When we are using CMake GUI >>>>>> there >>>>>> are two buttons "Configure" and "Generate", hence we have two stages: >>>>>> >>>>>> 1. Configure step, when we do configuring project, effectively >>>>>> creating >>>>>> file >>>>>> with cache variables (which we can modify) without really generating >>>>>> native >>>>>> tools files like Makefile/*.sln/etc. >>>>>> >>>>>> 2. Generate step, when we do generating project using file with cache >>>>>> variables, i.e. create those Makefile/*.sln/etc. >>>>>> >>>>>> The question is about command line version of CMake. Since we do >>>>>> creating >>>>>> file with cache and generate native tools files in one step what is >>>>>> the >>>>>> right term? Is it a configure step because we read user's '-D' and >>>>>> create >>>>>> cache file? Is it a generate step because native tools files >>>>>> generated >>>>>> at >>>>>> the end? May be there is a third name to describe the fact that it's >>>>>> configure+generate step? >>>>>> >>>>>> Thanks, Ruslo >>>>>> -- >>>>>> >>>>>> Powered by www.kitware.com >>>>>> >>>>>> Please keep messages on-topic and check the CMake FAQ at: >>>>>> http://www.cmake.org/Wiki/CMake_FAQ >>>>>> >>>>>> Kitware offers various services to support the CMake community. For >>>>>> more >>>>>> information on each offering, please visit: >>>>>> >>>>>> CMake Support: http://cmake.org/cmake/help/support.html >>>>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>>>>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>>>>> >>>>>> Visit other Kitware open-source projects at >>>>>> http://www.kitware.com/opensource/opensource.html >>>>>> >>>>>> Follow this link to subscribe/unsubscribe: >>>>>> http://public.kitware.com/mailman/listinfo/cmake >>>>>> >>>>> >>>> >>>> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake >> > > > -- > Craig Scott > Melbourne, Australia > http://crascit.com > > > > -- > > 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: CMake-workflow-sumarized.pdf Type: application/pdf Size: 200640 bytes Desc: not available URL: From craig.scott at crascit.com Sat Jun 25 03:44:13 2016 From: craig.scott at crascit.com (Craig Scott) Date: Sat, 25 Jun 2016 17:44:13 +1000 Subject: [CMake] CMake terminology In-Reply-To: References: <79a10531-b80d-dc01-e3e8-a85021c99099@yahoo.com> <3af3acbe-9c31-c5ab-ee3b-b92db84d24c1@yahoo.com> <1194db79-2e13-9cad-35b0-1f58fdb171ac@yahoo.com> Message-ID: One of the slight wrinkles here is that the distinction between configure and generation times is now a little stronger due to generator expressions. In order to really understand generator expressions, you cannot really avoid getting your head around configure and generate being distinct parts of the process. Personally, I tend to gloss over the distinction when explaining things so as not to distract the reader, but if I'm explaining something to do with generator expressions, then the distinction has to be made and I deliberately use the terms *configure* and *generation* stages. Also, as Ruslo points out, cmake can be used like a front end to the build step proper (i.e. cmake --build ...). I still see this as the *build* though, not a cmake-specific step per se. If you treated that as a cmake step, then one could argue the whole build is cmake because cmake can be used to invoke the test and package targets too. I doubt many people think this way, so personally I feel it is clearer to refer to the *build* stage as simply that without bringing cmake into the terminology. So in summary, here's the set of terminology I use (hopefully similar to what others intuitively expect): Workflow stages in general: cmake (or project setup) --> build --> test --> package If talking about generator expressions: configure --> generate --> build --> test --> package On Sat, Jun 25, 2016 at 5:02 PM, Eric Noulard wrote: > Hi there, > > I'd like to give my opinion here. > I agree that the fact that the cmake ui (qt or curse) makes it possible to > separate configure from generate > is an implementation detail. In fact one could perfectly decide that the > "configure" step should "generate " > each time it is run. Making it two-step save some time for big project but > I have already seen people forgetting > to generate and asking themselves why they didn't get any makefiles... > > Nevertheless from a user point of view explaining that there are different > "time" because CMake is a buid system **generator** and not a build tool > seems very important to me. > > Some action may be run during CMake time some may be done during Build > time. > For me CMake run is configure+generate. > > I did gave a tutorial which is now a bit outdated where I tried to picture > this. > See attached file or: > https://github.com/TheErk/CMake-tutorial > > my 2 cents. > > 2016-06-25 2:33 GMT+02:00 Ruslan Baratov via CMake : > >> There is cmake **build** step: cmake --build _builds >> >> So in GUI it's: >> * cmake configure >> * cmake generate >> * IDE build (which you can do with cmake --build so it can be called >> "cmake build" step) >> >> in cmd: >> * cmake configure+generate >> * cmake build >> >> Also I can call it "cmake step" in docs about some C++ project, but if >> the docs about cmake itself I think this term is too wide >> >> >> On 25-Jun-16 02:13, Craig Scott wrote: >> >> In documentation, blog articles, etc. I just call it the "cmake" step (or >> sometimes the "project setup" step if talking in a more project-wide >> sense). For many users, the separate configure and generate steps are >> somewhat of an implementation detail, so it makes more sense to give it a >> single term. I'm not aware of any generally accepted term, but the ones I >> use seem to be fairly easy to understand, especially for those new to >> CMake. YMMV. >> >> On Saturday, 25 June 2016, Ruslan Baratov via CMake < >> cmake at cmake.org> wrote: >> >>> On 24-Jun-16 23:49, Robert Maynard wrote: >>> >>>> Please run the configure and generate steps by >>>> >>> It's too long :) >>> >>> Also it doesn't express the fact that it's a single action, consider: >>> "To add variables on configure and generate steps use '-D'" >>> "Before running configure and generate steps note that old variables >>> from cache can be used" >>> etc. >>> >>> >>> >>>> On Fri, Jun 24, 2016 at 4:40 PM, Ruslan Baratov >>>> wrote: >>>> >>>>> On 24-Jun-16 23:25, Robert Maynard wrote: >>>>> >>>>>> cmake from the command line is still running the two stages, it just >>>>>> doesn't allow for feedback/input from the user between the two stages. >>>>>> >>>>> Yes, I understand that. Question is about the name of the step. I.e. >>>>> when I >>>>> do write manual what should I choose >>>>> Please run configure step by: cmake -H. -B_builds >>>>> or >>>>> Please run generate step by: cmake -H. -B_builds >>>>> ? >>>>> >>>>> May be both versions are correct? Or both incorrect? >>>>> >>>>> Ruslo >>>>> >>>>> >>>>> On Fri, Jun 24, 2016 at 4:06 PM, Ruslan Baratov via CMake >>>>>> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I have a question about CMake terminology. When we are using CMake >>>>>>> GUI >>>>>>> there >>>>>>> are two buttons "Configure" and "Generate", hence we have two stages: >>>>>>> >>>>>>> 1. Configure step, when we do configuring project, effectively >>>>>>> creating >>>>>>> file >>>>>>> with cache variables (which we can modify) without really generating >>>>>>> native >>>>>>> tools files like Makefile/*.sln/etc. >>>>>>> >>>>>>> 2. Generate step, when we do generating project using file with cache >>>>>>> variables, i.e. create those Makefile/*.sln/etc. >>>>>>> >>>>>>> The question is about command line version of CMake. Since we do >>>>>>> creating >>>>>>> file with cache and generate native tools files in one step what is >>>>>>> the >>>>>>> right term? Is it a configure step because we read user's '-D' and >>>>>>> create >>>>>>> cache file? Is it a generate step because native tools files >>>>>>> generated >>>>>>> at >>>>>>> the end? May be there is a third name to describe the fact that it's >>>>>>> configure+generate step? >>>>>>> >>>>>>> Thanks, Ruslo >>>>>>> -- >>>>>>> >>>>>>> Powered by www.kitware.com >>>>>>> >>>>>>> Please keep messages on-topic and check the CMake FAQ at: >>>>>>> http://www.cmake.org/Wiki/CMake_FAQ >>>>>>> >>>>>>> Kitware offers various services to support the CMake community. For >>>>>>> more >>>>>>> information on each offering, please visit: >>>>>>> >>>>>>> CMake Support: http://cmake.org/cmake/help/support.html >>>>>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>>>>>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>>>>>> >>>>>>> Visit other Kitware open-source projects at >>>>>>> http://www.kitware.com/opensource/opensource.html >>>>>>> >>>>>>> Follow this link to subscribe/unsubscribe: >>>>>>> http://public.kitware.com/mailman/listinfo/cmake >>>>>>> >>>>>> >>>>> >>>>> >>> -- >>> >>> Powered by www.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: >>> http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For more >>> information on each offering, please visit: >>> >>> CMake Support: http://cmake.org/cmake/help/support.html >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware open-source projects at >>> >>> http://www.kitware.com/opensource/opensource.html >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/cmake >>> >> >> >> -- >> Craig Scott >> Melbourne, Australia >> http://crascit.com >> >> >> >> -- >> >> 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 > -- Craig Scott Melbourne, Australia http://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsvanbethlehem at gmail.com Sat Jun 25 07:50:43 2016 From: jsvanbethlehem at gmail.com (Jakob van Bethlehem) Date: Sat, 25 Jun 2016 13:50:43 +0200 Subject: [CMake] Using CMake on CLion and adding geoip library In-Reply-To: References: Message-ID: Hej, According to https://cmake.org/cmake/help/v3.4/module/CheckIncludeFile.html the ?check_include_file? is a function provided by a module. So you?ll need to include(CheckIncludeFile) at the beginning of your lists-file Sincerely, Jakob > On 25 Jun 2016, at 08:09, Hgfjj Hhjgf wrote: > > I am trying to use an external library (GeoIP). CMake list contains: > message(STATUS "Looking for MaxMind GeoIP header files") > > set(CMAKE_INCLUDE_PATH "${CMAKE_INCLUDE_PATH} ${GEOIP_INCLUDE_DIR}") > check_include_file("GeoIP.h" HAVE_GEOIP_H) > check_include_file("GeoIPCity.h" HAVE_GEOIPCITY_H) > if (HAVE_GEOIP_H AND HAVE_GEOIPCITY_H) > message(STATUS "Looking for MaxMind GeoIP header files - found") > else(HAVE_GEOIP_H AND HAVE_GEOIPCITY_H) > message(FATAL_ERROR "Could not find one or more MaxMind GeoIP header files. If the MaxMind GeoIP library is installed, you can run CMake again and specify its location with -DGEOIP_INCLUDE_DIR=") > endif(HAVE_GEOIP_H AND HAVE_GEOIPCITY_H) > > message(STATUS "Looking for MaxMind GeoIP libraries") > find_library(GEOIP_LIB > NAMES GeoIP geoip > PATHS ${GEOIP_LIBRARY_DIR} > ) > if (GEOIP_LIB) > message(STATUS "Looking for MaxMind GeoIP libraries - found") > set(GEOIP_LIBRARIES ${GEOIP_LIB}) > else(GEOIP_LIB) > message(FATAL_ERROR "Could not find MaxMind GeoIP library") > endif(GEOIP_LIB) > > but getting error like "Unknown cmake command: check_include_file" > what's the problem here then? > -- > > 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 ruslan_baratov at yahoo.com Sat Jun 25 11:22:30 2016 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Sat, 25 Jun 2016 18:22:30 +0300 Subject: [CMake] CMake terminology In-Reply-To: References: <79a10531-b80d-dc01-e3e8-a85021c99099@yahoo.com> <3af3acbe-9c31-c5ab-ee3b-b92db84d24c1@yahoo.com> <1194db79-2e13-9cad-35b0-1f58fdb171ac@yahoo.com> Message-ID: <0d87dc04-7f54-36a5-9a8f-8a2d0faa3325@yahoo.com> On 25-Jun-16 10:02, Eric Noulard wrote: > Hi there, > > I'd like to give my opinion here. > I agree that the fact that the cmake ui (qt or curse) makes it > possible to separate configure from generate > is an implementation detail. In fact one could perfectly decide that > the "configure" step should "generate " > each time it is run. Making it two-step save some time for big project > but I have already seen people forgetting > to generate and asking themselves why they didn't get any makefiles... > > Nevertheless from a user point of view explaining that there are > different "time" because CMake is a buid system **generator** and not > a build tool seems very important to me. > > Some action may be run during CMake time some may be done during Build > time. > For me CMake run is configure+generate. > > I did gave a tutorial which is now a bit outdated where I tried to > picture this. > See attached file or: > https://github.com/TheErk/CMake-tutorial > > my 2 cents. Actually it doesn't conflicts with steps notions. "cmake time" for GUI = "cmake configure" step + "cmake generate" step, "cmake time" for command-line = "cmake configure+generate" step. Also by one step you can trigger events from different "times", i.e. "cmake --build _builds --target install" will run "Install time" which can trigger commands from "Build time", which even can trigger commands from "CMake time" (if CMakeLists.txt changed for example). > > 2016-06-25 2:33 GMT+02:00 Ruslan Baratov via CMake >: > > There is cmake **build** step: cmake --build _builds > > So in GUI it's: > * cmake configure > * cmake generate > * IDE build (which you can do with cmake --build so it can be > called "cmake build" step) > > in cmd: > * cmake configure+generate > * cmake build > > Also I can call it "cmake step" in docs about some C++ project, > but if the docs about cmake itself I think this term is too wide > > > On 25-Jun-16 02:13, Craig Scott wrote: >> In documentation, blog articles, etc. I just call it the "cmake" >> step (or sometimes the "project setup" step if talking in a more >> project-wide sense). For many users, the separate configure and >> generate steps are somewhat of an implementation detail, so it >> makes more sense to give it a single term. I'm not aware of any >> generally accepted term, but the ones I use seem to be fairly >> easy to understand, especially for those new to CMake. YMMV. >> >> On Saturday, 25 June 2016, Ruslan Baratov via CMake >> > wrote: >> >> On 24-Jun-16 23:49, Robert Maynard wrote: >> >> Please run the configure and generate steps by >> >> It's too long :) >> >> Also it doesn't express the fact that it's a single action, >> consider: >> "To add variables on configure and generate steps use '-D'" >> "Before running configure and generate steps note that old >> variables from cache can be used" >> etc. >> >> >> >> On Fri, Jun 24, 2016 at 4:40 PM, Ruslan Baratov >> wrote: >> >> On 24-Jun-16 23:25, Robert Maynard wrote: >> >> cmake from the command line is still running the >> two stages, it just >> doesn't allow for feedback/input from the user >> between the two stages. >> >> Yes, I understand that. Question is about the name of >> the step. I.e. when I >> do write manual what should I choose >> Please run configure step by: cmake -H. -B_builds >> or >> Please run generate step by: cmake -H. -B_builds >> ? >> >> May be both versions are correct? Or both incorrect? >> >> Ruslo >> >> >> On Fri, Jun 24, 2016 at 4:06 PM, Ruslan Baratov >> via CMake >> wrote: >> >> Hi, >> >> I have a question about CMake terminology. >> When we are using CMake GUI >> there >> are two buttons "Configure" and "Generate", >> hence we have two stages: >> >> 1. Configure step, when we do configuring >> project, effectively creating >> file >> with cache variables (which we can modify) >> without really generating >> native >> tools files like Makefile/*.sln/etc. >> >> 2. Generate step, when we do generating >> project using file with cache >> variables, i.e. create those Makefile/*.sln/etc. >> >> The question is about command line version of >> CMake. Since we do creating >> file with cache and generate native tools >> files in one step what is the >> right term? Is it a configure step because we >> read user's '-D' and create >> cache file? Is it a generate step because >> native tools files generated >> at >> the end? May be there is a third name to >> describe the fact that it's >> configure+generate step? >> >> Thanks, Ruslo >> -- >> >> Powered by www.kitware.com >> >> >> Please keep messages on-topic and check the >> CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support >> the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: >> http://cmake.org/cmake/help/support.html >> CMake Consulting: >> http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: >> http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake >> >> >> >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake >> community. For more information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake >> >> >> >> -- >> Craig Scott >> Melbourne, Australia >> http://crascit.com >> > > > -- > > 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 ruslan_baratov at yahoo.com Sat Jun 25 11:42:29 2016 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Sat, 25 Jun 2016 18:42:29 +0300 Subject: [CMake] CMake terminology In-Reply-To: References: <79a10531-b80d-dc01-e3e8-a85021c99099@yahoo.com> <3af3acbe-9c31-c5ab-ee3b-b92db84d24c1@yahoo.com> <1194db79-2e13-9cad-35b0-1f58fdb171ac@yahoo.com> Message-ID: <93eec468-a861-a5b7-fa8c-a73dfeaadcb1@yahoo.com> On 25-Jun-16 10:44, Craig Scott wrote: > One of the slight wrinkles here is that the distinction between > configure and generation times is now a little stronger due to > generator expressions. In order to really understand generator > expressions, you cannot really avoid getting your head around > configure and generate being distinct parts of the process. > Personally, I tend to gloss over the distinction when explaining > things so as not to distract the reader, but if I'm explaining > something to do with generator expressions, then the distinction has > to be made and I deliberately use the terms /configure/ and > /generation/ stages. I'm not sure I understand the link between "generator expressions" and "confusing configure+generate stage". Do you mean "generator expressions" on "configure+generate stage" vs "build stage"? > > Also, as Ruslo points out, cmake can be used like a front end to the > build step proper (i.e. cmake --build ...). I still see this as the > /build/ though, not a cmake-specific step per se. If you treated that > as a cmake step, then one could argue the whole build is cmake because > cmake can be used to invoke the test and package targets too. I doubt > many people think this way, so personally I feel it is clearer to > refer to the /build/ stage as simply that without bringing cmake into > the terminology. Okay, I agree. "cmake build step" sounds weird, it should be just "build step" which can be triggered by "cmake --build" command. Also to be pedantic: it's CTest for testing stage and CPack for packing stage, not CMake (or you mean CMake tools?). > > So in summary, here's the set of terminology I use (hopefully similar > to what others intuitively expect): > > Workflow stages in general: cmake (or project setup) --> build --> > test --> package > > If talking about generator expressions: configure --> generate --> > build --> test --> package This one reminds me about ExternalProject_Add command. It has "Configure step" with "CONFIGURE_COMMAND". This is where "cmake -H. -B_builds" happens :) So for now I see two choices: * invent new name for configure+generate :) well, this seems like a huge overkill... * use words "configure" and "generate" interchangeably for command line cmake, depending on context, e.g.: * "you can add `-D` on __configure step__ to modify cache..." * "you can add `-G Xcode` on __generate step__ to create Xcode project instead of Makefile..." Ruslo > > > > On Sat, Jun 25, 2016 at 5:02 PM, Eric Noulard > wrote: > > Hi there, > > I'd like to give my opinion here. > I agree that the fact that the cmake ui (qt or curse) makes it > possible to separate configure from generate > is an implementation detail. In fact one could perfectly decide > that the "configure" step should "generate " > each time it is run. Making it two-step save some time for big > project but I have already seen people forgetting > to generate and asking themselves why they didn't get any makefiles... > > Nevertheless from a user point of view explaining that there are > different "time" because CMake is a buid system **generator** and > not a build tool seems very important to me. > > Some action may be run during CMake time some may be done during > Build time. > For me CMake run is configure+generate. > > I did gave a tutorial which is now a bit outdated where I tried to > picture this. > See attached file or: > https://github.com/TheErk/CMake-tutorial > > my 2 cents. > > 2016-06-25 2:33 GMT+02:00 Ruslan Baratov via CMake > >: > > There is cmake **build** step: cmake --build _builds > > So in GUI it's: > * cmake configure > * cmake generate > * IDE build (which you can do with cmake --build so it can be > called "cmake build" step) > > in cmd: > * cmake configure+generate > * cmake build > > Also I can call it "cmake step" in docs about some C++ > project, but if the docs about cmake itself I think this term > is too wide > > > On 25-Jun-16 02:13, Craig Scott wrote: >> In documentation, blog articles, etc. I just call it the >> "cmake" step (or sometimes the "project setup" step if >> talking in a more project-wide sense). For many users, the >> separate configure and generate steps are somewhat of an >> implementation detail, so it makes more sense to give it a >> single term. I'm not aware of any generally accepted term, >> but the ones I use seem to be fairly easy to understand, >> especially for those new to CMake. YMMV. >> >> On Saturday, 25 June 2016, Ruslan Baratov via CMake >> > wrote: >> >> On 24-Jun-16 23:49, Robert Maynard wrote: >> >> Please run the configure and generate steps by >> >> It's too long :) >> >> Also it doesn't express the fact that it's a single >> action, consider: >> "To add variables on configure and generate steps use '-D'" >> "Before running configure and generate steps note that >> old variables from cache can be used" >> etc. >> >> >> >> On Fri, Jun 24, 2016 at 4:40 PM, Ruslan Baratov >> wrote: >> >> On 24-Jun-16 23:25, Robert Maynard wrote: >> >> cmake from the command line is still running >> the two stages, it just >> doesn't allow for feedback/input from the >> user between the two stages. >> >> Yes, I understand that. Question is about the >> name of the step. I.e. when I >> do write manual what should I choose >> Please run configure step by: cmake -H. -B_builds >> or >> Please run generate step by: cmake -H. -B_builds >> ? >> >> May be both versions are correct? Or both incorrect? >> >> Ruslo >> >> >> On Fri, Jun 24, 2016 at 4:06 PM, Ruslan >> Baratov via CMake >> wrote: >> >> Hi, >> >> I have a question about CMake >> terminology. When we are using CMake GUI >> there >> are two buttons "Configure" and >> "Generate", hence we have two stages: >> >> 1. Configure step, when we do configuring >> project, effectively creating >> file >> with cache variables (which we can >> modify) without really generating >> native >> tools files like Makefile/*.sln/etc. >> >> 2. Generate step, when we do generating >> project using file with cache >> variables, i.e. create those >> Makefile/*.sln/etc. >> >> The question is about command line >> version of CMake. Since we do creating >> file with cache and generate native tools >> files in one step what is the >> right term? Is it a configure step >> because we read user's '-D' and create >> cache file? Is it a generate step >> because native tools files generated >> at >> the end? May be there is a third name to >> describe the fact that it's >> configure+generate step? >> >> Thanks, Ruslo >> -- >> >> Powered by www.kitware.com >> >> >> Please keep messages on-topic and check >> the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to >> support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: >> http://cmake.org/cmake/help/support.html >> CMake Consulting: >> http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: >> http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake >> >> >> >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake >> community. For more information on each offering, please >> visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: >> http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake >> >> >> >> -- >> Craig Scott >> Melbourne, Australia >> http://crascit.com >> > > > -- > > 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 > > > > > -- > Craig Scott > Melbourne, Australia > http://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcel.loose at zonnet.nl Sun Jun 26 11:20:22 2016 From: marcel.loose at zonnet.nl (Marcel Loose) Date: Sun, 26 Jun 2016 17:20:22 +0200 Subject: [CMake] subversion In-Reply-To: <576D7257.1050303@gmx.net> References: <576D7257.1050303@gmx.net> Message-ID: Hi Andreas, I think the FindSubversion module predates CMake 2.8, which introduced "message(WARNING ...)". I think a warning would be better than an error in this case; and I think the same argument holds for Subversion_WC_LOG, which also generates an error if invoked from a non-working copy. Cheers, Marcel Loose. Op 24-06-16 om 19:48 schreef Andreas Naumann: > Dear cmake users, > > I have a question if, and how, you use the Subversion module of cmake. > The module provides the macro Subversion_WC_INFO, which extracts > information of a working copy. I use this information, to generate a sub > minor revision number of my project. > If I checkout my project using svn, it works. But if I export it, the > modules failes with a fatal error. > At the moment, I check, if my directory is a working copy and if it is > not, the version variable is not defined. In my oppinion, it would be > better, if the macro from the subversion module would simply define a > variable "is_working_directory" instead of failing hard. > What do you think about this idea? How do you use the subversion module? > The patch would be easy, and I would send one to the developer mailing > list, if desired. > > Regards, > Andreas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: OpenPGP digital signature URL: From nagger at gmx.de Sun Jun 26 21:11:57 2016 From: nagger at gmx.de (Nagger) Date: Mon, 27 Jun 2016 03:11:57 +0200 Subject: [CMake] subversion In-Reply-To: <576D7257.1050303@gmx.net> References: <576D7257.1050303@gmx.net> Message-ID: <9ed1f4fd-1dc8-5b38-7966-9e70b4cf7dff@gmx.de> Am 24.06.2016 um 19:48 schrieb Andreas Naumann: > At the moment, I check, if my directory is a working copy and if it is > not, the version variable is not defined. In my oppinion, it would be > better, if the macro from the subversion module would simply define a > variable "is_working_directory" instead of failing hard. See https://cmake.org/pipermail/cmake/2010-January/034862.html From crestchristopher at gmail.com Mon Jun 27 00:31:55 2016 From: crestchristopher at gmail.com (Crest Christopher) Date: Mon, 27 Jun 2016 00:31:55 -0400 Subject: [CMake] Compiling binaries with cmake -- help In-Reply-To: References: <576B2D9F.7090400@gmail.com> <576B6632.7010706@gmail.com> <611F4C8C6DD445C6957D50BA73C22025@quad> <576B6BF4.6040806@gmail.com> <576B6F50.9030802@gmail.com> <576B71BA.1060804@gmail.com> Message-ID: <5770AC3B.8040304@gmail.com> I assume I must simply download this , install and I will then be able to compile ? > Nicholas Braden > Thursday, June 23, 2016 8:37 AM > Yep, if you have all the dependencies it should just work as I > described in a previous message. > > On Thu, Jun 23, 2016 at 12:20 AM, Crest Christopher > Crest Christopher > Thursday, June 23, 2016 1:20 AM > I'll get the Python sipconfig module installed, then I hope we can > continue with getting it compiled ? > > > Nicholas Braden > Thursday, June 23, 2016 1:15 AM > Yes, many projects do not include their dependencies and require you > to obtain them yourself. In this case it looks like you need the > Python sipconfig module installed. > > On Thu, Jun 23, 2016 at 12:10 AM, Crest Christopher > Crest Christopher > Thursday, June 23, 2016 1:10 AM > It can work, but it's missing dependencies ? > > > Nicholas Braden > Thursday, June 23, 2016 1:08 AM > It looks like the instructions are there in the README. I tried > building on my system but I'm missing some dependencies (e.g. at some > point it finds my Python 3 installation and tries to run some code but > fails due to a missing sipconfig module, which I am not familiar > with). > > Generally, to build a project that uses CMake, create an empty > directory for the build and open a terminal in it, then run CMake with > the path to the directory containing CMakeLists.txt and optionally > specify the generator to use if the default is not the one you want. > Then, if it completes without errors, you can use "cmake --build ." to > build it and "cmake --build . --target install" to install it, even if > you used an IDE generator. > > As for the project dependencies, you are own your own to get those. > > On Wed, Jun 22, 2016 at 11:56 PM, Crest Christopher -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andreas-Naumann at gmx.net Mon Jun 27 03:23:32 2016 From: Andreas-Naumann at gmx.net (Andreas Naumann) Date: Mon, 27 Jun 2016 09:23:32 +0200 Subject: [CMake] subversion In-Reply-To: <9ed1f4fd-1dc8-5b38-7966-9e70b4cf7dff@gmx.de> References: <576D7257.1050303@gmx.net>, <9ed1f4fd-1dc8-5b38-7966-9e70b4cf7dff@gmx.de> Message-ID: An HTML attachment was scrubbed... URL: From ycollette.nospam at free.fr Mon Jun 27 05:56:14 2016 From: ycollette.nospam at free.fr (ycollette.nospam at free.fr) Date: Mon, 27 Jun 2016 11:56:14 +0200 (CEST) Subject: [CMake] CTest periodic freeze under MacOS In-Reply-To: <1284156920.340465735.1467021255996.JavaMail.root@zimbra35-e6.priv.proxad.net> Message-ID: <667748726.340471023.1467021374299.JavaMail.root@zimbra35-e6.priv.proxad.net> Hello, I don't really know if it's a cmake / ctest bug but when I launch tests. I added a timeout limit for each tests. This timeout is set to 120 sec. Some tests fail after a timeout. And in the log file, the timemout has a different value. For example, it can be 280 seconds. This occurs for one tests out of 20. Maybe this is a MacOS bug (some kernel freeze) but I don't know how to track this down to cmake or MacOS. Best regards, YC From ycollette.nospam at free.fr Mon Jun 27 05:57:59 2016 From: ycollette.nospam at free.fr (ycollette.nospam at free.fr) Date: Mon, 27 Jun 2016 11:57:59 +0200 (CEST) Subject: [CMake] CTest periodic freeze under MacOS In-Reply-To: <667748726.340471023.1467021374299.JavaMail.root@zimbra35-e6.priv.proxad.net> Message-ID: <1366073057.340476421.1467021479003.JavaMail.root@zimbra35-e6.priv.proxad.net> I forgot to say that the cmake version installed on macos is 3.4.3. ----- Mail original ----- De: "ycollette nospam" ?: "cmake" Envoy?: Lundi 27 Juin 2016 11:56:14 Objet: [CMake] CTest periodic freeze under MacOS Hello, I don't really know if it's a cmake / ctest bug but when I launch tests. I added a timeout limit for each tests. This timeout is set to 120 sec. Some tests fail after a timeout. And in the log file, the timemout has a different value. For example, it can be 280 seconds. This occurs for one tests out of 20. Maybe this is a MacOS bug (some kernel freeze) but I don't know how to track this down to cmake or MacOS. Best regards, YC -- 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 loose at astron.nl Mon Jun 27 06:57:37 2016 From: loose at astron.nl (Marcel Loose) Date: Mon, 27 Jun 2016 12:57:37 +0200 Subject: [CMake] subversion In-Reply-To: References: <576D7257.1050303@gmx.net> <9ed1f4fd-1dc8-5b38-7966-9e70b4cf7dff@gmx.de> Message-ID: See also https://cmake.org/Bug/view.php?id=10200 Cheers, Marcel Loose. On 27/06/16 09:23, Andreas Naumann wrote: > Thanks for the 6 year old hint. But obviously, the patch is not in any > recent cmake version. > Therefore, I could use it in my own project and ship my own > FindSubversion.cmake.. which is quite ugly. > > *Gesendet:* Montag, 27. Juni 2016 um 03:11 Uhr > *Von:* Nagger > *An:* cmake at cmake.org > *Betreff:* Re: [CMake] subversion > Am 24.06.2016 um 19:48 schrieb Andreas Naumann: > > > At the moment, I check, if my directory is a working copy and if it is > > not, the version variable is not defined. In my oppinion, it would be > > better, if the macro from the subversion module would simply define a > > variable "is_working_directory" instead of failing hard. > > See https://cmake.org/pipermail/cmake/2010-January/034862.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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: loose.vcf Type: text/x-vcard Size: 292 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: OpenPGP digital signature URL: From eric.noulard at gmail.com Mon Jun 27 10:04:36 2016 From: eric.noulard at gmail.com (Eric Noulard) Date: Mon, 27 Jun 2016 16:04:36 +0200 Subject: [CMake] CMake terminology In-Reply-To: <93eec468-a861-a5b7-fa8c-a73dfeaadcb1@yahoo.com> References: <79a10531-b80d-dc01-e3e8-a85021c99099@yahoo.com> <3af3acbe-9c31-c5ab-ee3b-b92db84d24c1@yahoo.com> <1194db79-2e13-9cad-35b0-1f58fdb171ac@yahoo.com> <93eec468-a861-a5b7-fa8c-a73dfeaadcb1@yahoo.com> Message-ID: 2016-06-25 17:42 GMT+02:00 Ruslan Baratov : > On 25-Jun-16 10:44, Craig Scott wrote: > > One of the slight wrinkles here is that the distinction between configure > and generation times is now a little stronger due to generator expressions. > In order to really understand generator expressions, you cannot really > avoid getting your head around configure and generate being distinct parts > of the process. Personally, I tend to gloss over the distinction when > explaining things so as not to distract the reader, but if I'm explaining > something to do with generator expressions, then the distinction has to be > made and I deliberately use the terms *configure* and *generation* stages. > > I'm not sure I understand the link between "generator expressions" and > "confusing configure+generate stage". Do you mean "generator expressions" > on "configure+generate stage" vs "build stage"? > Generator expression came up because one needs to evaluate some variable value [apparently]at "build time" like knowing the exact name (with path) of a target (using TARGET_FILE generator expression in custom command). Knowing that "generator expression" are in fact evaluated during "generation step" and not really at build time is an implementation detail. (Which is a big one for implementors) but not really important to user. -- Craig Scott Melbourne, Australia http://crascit.com -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andreas-Naumann at gmx.net Mon Jun 27 12:55:45 2016 From: Andreas-Naumann at gmx.net (Andreas Naumann) Date: Mon, 27 Jun 2016 18:55:45 +0200 Subject: [CMake] subversion In-Reply-To: References: <576D7257.1050303@gmx.net> <9ed1f4fd-1dc8-5b38-7966-9e70b4cf7dff@gmx.de> Message-ID: <57715A91.8040701@gmx.net> The discussion is interesting and ends with the question, whether the macro "Subversion_IS_WC" is usable. As I understand the other arguments are *leave the FATAL_ERROR as default for backwards compatibility *the suggested patch hides the error message if error_quite is set . *calling svn info twice is felt to be a waste, if the result is desired anyway. So, I would suggest to extend Erik Johanssons patch from http://www.mail-archive.com/cmake at cmake.org/msg26817.html by storingto the error message and svn error code in an extra variable. Than, we have the ability to ignore errors due to "wrong" working directories and to analyze the error, if the user is interested in the error. In my opinion, a hard fail is annoying, because the user is not able to recover from the error. Regards, Andreas Am 27.06.2016 um 12:57 schrieb Marcel Loose: > > See also https://cmake.org/Bug/view.php?id=10200 > > Cheers, > Marcel Loose. > > > On 27/06/16 09:23, Andreas Naumann wrote: >> Thanks for the 6 year old hint. But obviously, the patch is not in >> any recent cmake version. >> Therefore, I could use it in my own project and ship my own >> FindSubversion.cmake.. which is quite ugly. >> *Gesendet:* Montag, 27. Juni 2016 um 03:11 Uhr >> *Von:* Nagger >> *An:* cmake at cmake.org >> *Betreff:* Re: [CMake] subversion >> Am 24.06.2016 um 19:48 schrieb Andreas Naumann: >> >> > At the moment, I check, if my directory is a working copy and if it is >> > not, the version variable is not defined. In my oppinion, it would be >> > better, if the macro from the subversion module would simply define a >> > variable "is_working_directory" instead of failing hard. >> >> See https://cmake.org/pipermail/cmake/2010-January/034862.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 bill.hoffman at kitware.com Mon Jun 27 15:53:04 2016 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Mon, 27 Jun 2016 15:53:04 -0400 Subject: [CMake] CTest periodic freeze under MacOS In-Reply-To: <1366073057.340476421.1467021479003.JavaMail.root@zimbra35-e6.priv.proxad.net> References: <1366073057.340476421.1467021479003.JavaMail.root@zimbra35-e6.priv.proxad.net> Message-ID: <67c4c19e-3ec9-0757-319b-9f05d3587eca@kitware.com> On 6/27/2016 5:57 AM, ycollette.nospam at free.fr wrote: > I forgot to say that the cmake version installed on macos is 3.4.3. Can you try a more recent version of cmake? -Bill From craig.scott at crascit.com Mon Jun 27 17:23:39 2016 From: craig.scott at crascit.com (Craig Scott) Date: Tue, 28 Jun 2016 07:23:39 +1000 Subject: [CMake] CMake terminology In-Reply-To: References: <79a10531-b80d-dc01-e3e8-a85021c99099@yahoo.com> <3af3acbe-9c31-c5ab-ee3b-b92db84d24c1@yahoo.com> <1194db79-2e13-9cad-35b0-1f58fdb171ac@yahoo.com> <93eec468-a861-a5b7-fa8c-a73dfeaadcb1@yahoo.com> Message-ID: On Tue, Jun 28, 2016 at 12:04 AM, Eric Noulard wrote: > > > 2016-06-25 17:42 GMT+02:00 Ruslan Baratov : > >> On 25-Jun-16 10:44, Craig Scott wrote: >> >> One of the slight wrinkles here is that the distinction between configure >> and generation times is now a little stronger due to generator expressions. >> In order to really understand generator expressions, you cannot really >> avoid getting your head around configure and generate being distinct parts >> of the process. Personally, I tend to gloss over the distinction when >> explaining things so as not to distract the reader, but if I'm explaining >> something to do with generator expressions, then the distinction has to be >> made and I deliberately use the terms *configure* and *generation* >> stages. >> >> I'm not sure I understand the link between "generator expressions" and >> "confusing configure+generate stage". Do you mean "generator expressions" >> on "configure+generate stage" vs "build stage"? >> > > Generator expression came up because one needs to evaluate some variable > value [apparently]at "build time" > like knowing the exact name (with path) of a target (using TARGET_FILE > generator expression in custom command). > > Knowing that "generator expression" are in fact evaluated during > "generation step" and not really at build time > is an implementation detail. (Which is a big one for implementors) but not > really important to user. > My original comment was more about the fact that users have to understand that the *result* of a generator expression is not available at configure time. This is what makes them unique compared to things like ordinary CMake variables. A classic case of this is where the developer may want to know the binary directory of a particular target. In the past, they might try using the LOCATION target property, but this would have been wrong for multi-config generators like Xcode or Visual Studio. The right way to do it is to use a generator expression like $, but you cannot use that in contexts where the value is needed immediately, such as in a call to configure_file(). This example is contrived (there are other ways to achieve the developer's goal), but it illustrates a common thought process and if the developer doesn't understand when a generator expression result is computed/available, they won't understand why using one in such contexts doesn't work. Not my best explanation, but hopefully that made sense. ;) -- Craig Scott Melbourne, Australia http://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From sambeet161616 at gmail.com Mon Jun 27 19:21:45 2016 From: sambeet161616 at gmail.com (Sambeet Panigrahi) Date: Tue, 28 Jun 2016 04:51:45 +0530 Subject: [CMake] Modifying the FindBoost.cmake module Message-ID: Hi, I am using Cmake to build Orocos RTT. There is a FindBoost.cmake module available in the config directory which the project uses.Now I have got two boost installations one in 1)/usr/include/boost 2)~/NewRockPort/x86/Install/boost The second installation is the one I want to use .However The find_package command always goes on to find the first installation. There is a section in the file SET(_boost_INCLUDE_SEARCH_DIRS "$ENV{INSTALL_PREFIX}/boost/include/" C:/boost/include C:/boost "$ENV{ProgramFiles}/boost/include" "$ENV{ProgramFiles}/boost" /sw/local/include in which I have tried to set the second installation's address, but it always points to the first.I have also tried to set the second installation from environment but somehow it always detects the first installation. What can I do to include the second installation in my project? Regards Sambeet -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andreas-Naumann at gmx.net Tue Jun 28 01:49:52 2016 From: Andreas-Naumann at gmx.net (Andreas Naumann) Date: Tue, 28 Jun 2016 07:49:52 +0200 Subject: [CMake] Modifying the FindBoost.cmake module In-Reply-To: References: Message-ID: <57721000.3040502@gmx.net> Hey, if you would use the FindBoost.cmake module from cmake itself, you could set the environment variable BOOST_ROOT to the second path. Regards, Andreas Am 28.06.2016 um 01:21 schrieb Sambeet Panigrahi: > Hi, > I am using Cmake to build Orocos RTT. There is a FindBoost.cmake > module available in the config directory which the project uses.Now I > have got two boost installations one in > 1)/usr/include/boost > 2)~/NewRockPort/x86/Install/boost > > The second installation is the one I want to use .However The > find_package command always goes on to find the first installation. > There is a section in the file > > SET(_boost_INCLUDE_SEARCH_DIRS > "$ENV{INSTALL_PREFIX}/boost/include/" > C:/boost/include > C:/boost > "$ENV{ProgramFiles}/boost/include" > "$ENV{ProgramFiles}/boost" > /sw/local/include > in which I have tried to set the second installation's address, but it > always points to the first.I have also tried to set the second > installation from environment but somehow it always detects the first > installation. > > What can I do to include the second installation in my project? > > Regards > Sambeet > > From s.baars at rug.nl Tue Jun 28 05:26:47 2016 From: s.baars at rug.nl (Sven Baars) Date: Tue, 28 Jun 2016 11:26:47 +0200 Subject: [CMake] How do you handle recursive dependencies in CMake In-Reply-To: <575AA5B7.7060408@rug.nl> References: <57583A66.1050709@rug.nl> <575AA5B7.7060408@rug.nl> Message-ID: <577242D7.70308@rug.nl> Hey all, Since I did not receive a reply to my previous mail, I decided to write a minimal example explaining my problem, where I kept al the names as I used in my previous mails. I hope that after seeing my example, someone can explain me what I am doing wrong here. I included a script that reproduces the problem. Cheers, Sven On 06/10/2016 01:34 PM, Sven Baars wrote: > Hey Chuck, > > In ATargets.cmake it says > > add_library(a SHARED IMPORTED) > > and in BTargets.cmake it says > > add_library(b SHARED IMPORTED) > > However, if I build C it will say > > /usr/bin/ld: cannot find -la > > when I do > > find_package(B) > target_link_libraries(c b) > add_executable(main main.cpp) > target_link_libraries(main c) > > This, I think, because the 'b' target depends on 'a' but doesn't know > where 'a' is located, because this is not described in BTargets.cmake. > > Sven > > On 06/08/2016 06:07 PM, Chuck Atkins wrote: >> If the projects are each providing their own Config.cmake file then >> you probably will want to use those instead of Find modules. Instead >> of using the Foo_Bar_LIBRARIES variable though, try using the actual >> imported targets from the config files. Those should have the >> appropriate dependency information. If you're not sure what they are >> you should be able to dig through the provided Config.cmake and >> Targets.cmake files for FooBar and see which targets are created bu >> "add_library(FooBar::Foo ... IMPORTED)". >> >> - Chuck >> >> On Wed, Jun 8, 2016 at 11:31 AM, Sven Baars > > wrote: >> >> In my case all projects provide their own FooBarConfig.cmake, but >> not a FindFooBar.cmake. For this reason I wanted to use those, >> because I thought it saves me the effort of writing a lot of >> FindFooBar.cmake files, and it also seemed like the right way to >> do it, because it provides things like FooBar_LIBRARIES, which is >> what I need. The reason I said that I create my own >> FooBarConfig.cmake, is because I want to use CMake properly in my >> own project, so I also want to provide a FoorBarConfig.cmake file >> for my users. So even if the projects I use don't do everything >> properly, I still want to do it properly myself. The problem in >> this case is that I'm not sure what the proper way is. If the >> FoorBarConfig.cmake file is not enough to handle the dependencies >> I encounter, should I provide a FindFooBar.cmake file or >> something, instead of just the FooBarConfig.cmake? And meanwhile >> also write a FindFooBar.cmake file for all my dependencies? >> >> Another reason why this seems odd to me, is because if N >> different projects use FooBar, then also possibly N different >> versions of FindFooBar.cmake are created by all the different >> projects (I have actually already seen this a lot). That is the >> case, because the FindFooBar.cmake file is not provided by the >> FooBar project, unlike the FooBarConfig.cmake. >> >> Cheers, >> Sven >> >> >> On 06/08/2016 03:11 PM, Chuck Atkins wrote: >>> The FooBarConfig.cmake is something that should be generated by >>> FooBar's build. The reason you don't get absolute paths for >>> the "libraries" from a package config file is that they're not >>> actually libraries but imported targets. The imported target >>> let's you treat "foo" as though it were a library built by your >>> project. It then has the appropriate target properties set on >>> it ti define the full path to it's library, etc. That being >>> said, if you're manually creating the FooBarConfig.cmake that's >>> not really the right approach. If the FooBar buil;d doesn't >>> actually generate it's own FooBarConfig.cmake file then you'll >>> want to create you're own FindFooBar.cmake. A bare bones find >>> module that creates an imported target would look something like >>> this: >>> >>> if(NOT FooBar_FOUND AND NOT TARGET FooBar::FooBar) >>> find_path(FooBar_INCLUDE_DIR FooBar.h) >>> find_library(FooBar_LIBRARY FooBar) >>> >>> include(FindPackageHandleStandardArgs) >>> find_package_handle_standard_args(FooBar >>> FOUND_VAR FooBar_FOUND >>> REQUIRED_VARS FooBar_INCLUDE_DIR FooBar_LIBRARY >>> ) >>> endif() >>> >>> if(FooBar_FOUND AND NOT TARGET FooBar::FooBar) >>> add_library(FooBar::FooBar UNKNOWN IMPORTED) >>> set_target_properties(FooBar::FooBar PROPERTIES >>> IMPORTED_LOCATION ${FooBar_LIBRARY} >>> INTERFACE_INCLUDE_DIRECTORIES ${FooBar_INCLUDE_DIR} >>> ) >>> endif() >>> >>> Then in your project you can use: >>> >>> find_package(FooBar) >>> add_library(MyLib supercoolfiles.cxx) >>> target_libkLibraries(MyLib FooBar::FooBar) >>> >>> Where this starts to get really helpful in your situation is if >>> you have an imported target for A, B, and C, then you can create >>> the appropriate dependencies. Say, for example, you have a >>> FindA.cmake that follows the pattern above and generates an A::A >>> target. Then in your FindB.cmake you can have: >>> >>> if(NOT B_FOUND AND NOT TARGET B::B) >>> find_path(B_INCLUDE_DIR B.h) >>> find_library(B_LIBRARY B) >>> >>> include(FindPackageHandleStandardArgs) >>> find_package_handle_standard_args(B >>> FOUND_VAR B_FOUND >>> REQUIRED_VARS B_INCLUDE_DIR B_LIBRARY >>> ) >>> >>> * find_package(A QUIET) >>> if(A_FOUND) >>> set(B_Extra_Deps A::A) >>> endif()* >>> endif() >>> >>> if(B_FOUND AND NOT TARGET B::B) >>> add_library(B::B UNKNOWN IMPORTED) >>> set_target_properties(B::B PROPERTIES >>> IMPORTED_LOCATION ${B_LIBRARY} >>> INTERFACE_INCLUDE_DIRECTORIES ${B_INCLUDE_DIR} >>> ) >>> * if(B_Extra_Deps) >>> set_target_properties(B::B PROPERTIES >>> INTERFACE_LINK_LIBRARIES ${B_Extra_Deps} >>> ) >>> endif()* >>> endif() >>> >>> and similarly for FindC.cmake. Since A::A, B::B, and C::C are >>> actual proper CMake targets and not just library files then they >>> carry with them associated target dependency information. In >>> CMake vernacular we refer this as "target usage requirements" >>> since the target caries with it all the necessary information >>> for something to actually use it, whether that's just extra link >>> libraries or also extra include directories and compile >>> definitions needed. The Package::Target naming convention is >>> the idea that each package has it's own namespace where you may >>> define multiple targets. >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cmake-example.tar.gz Type: application/gzip Size: 2096 bytes Desc: not available URL: From rwan.work at gmail.com Tue Jun 28 05:52:09 2016 From: rwan.work at gmail.com (Raymond Wan) Date: Tue, 28 Jun 2016 17:52:09 +0800 Subject: [CMake] How do you handle recursive dependencies in CMake In-Reply-To: <577242D7.70308@rug.nl> References: <57583A66.1050709@rug.nl> <575AA5B7.7060408@rug.nl> <577242D7.70308@rug.nl> Message-ID: Hi Sven, On Tue, Jun 28, 2016 at 5:26 PM, Sven Baars wrote: > Hey all, > > Since I did not receive a reply to my previous mail, I decided to write a > minimal example explaining my problem, where I kept al the names as I used > in my previous mails. I hope that after seeing my example, someone can > explain me what I am doing wrong here. I included a script that reproduces > the problem. > > Cheers, > Sven I'm not much of an expert with CMake, but I can explain to you what I've done, at least. If I understand correctly, package X makes use of package Y, but during compilation, it cannot find it? I think what you can do depends on whether X and Y are in two separate source trees. If they are, then it is almost like Y is the zlib library. Then what you can do is, like the zlib library, install it into a system directory (i.e., via INSTALL ()) and then X will use a FIND_PACKAGE to look for it. But, suppose Y isn't like zlib. For example, it is a library that is within the same source tree and will only ever be used by X (both of which are written by you). I think this is the scenario that you're talking about? In my case, I have done this in my CMakeLists.txt: SET (CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}) I guess you can set it [https://cmake.org/cmake/help/v3.3/variable/CMAKE_LIBRARY_OUTPUT_DIRECTORY.html] to anything so that all of the libraries will be installed into one place without doing an INSTALL. Of course, this directory is or somewhere within the build/ directory. (I suppose doing an install into ${CMAKE_BINARY_DIR} would achieve the same thing?) I had previously installed Y's archive into a system directory, but besides the need to run FIND_PACKAGE, I thought it was "silly" to install an archive into a system directory that is only used by my own program. Seems a bit messy and intrusive to the end-user -- my libraries are quite unlike zlib; few chance someone else will use it :-) . At the very least, this approach keeps it in one place within build/ . I'm not sure if it is the "right" way to do it, but this is what I do at the moment... I hope it helps! Ray From s.baars at rug.nl Tue Jun 28 06:03:14 2016 From: s.baars at rug.nl (Sven Baars) Date: Tue, 28 Jun 2016 12:03:14 +0200 Subject: [CMake] How do you handle recursive dependencies in CMake In-Reply-To: References: <57583A66.1050709@rug.nl> <575AA5B7.7060408@rug.nl> <577242D7.70308@rug.nl> Message-ID: <57724B62.2010001@rug.nl> Hi Ray, The packages I use are installed in a non-standard path, because I don't have access to the system directories on most systems I work on, but are used by many other libraries. They are also all separate packages, not packages in the same source tree. I did not see my attachment on the mailing list archive, so instead I just put it on Github. It can be found here: https://github.com/Sbte/cmake-example I hope the example shows my workflow, and also what doesn't work for me. Sven On 06/28/2016 11:52 AM, Raymond Wan wrote: > Hi Sven, > > > On Tue, Jun 28, 2016 at 5:26 PM, Sven Baars wrote: >> Hey all, >> >> Since I did not receive a reply to my previous mail, I decided to write a >> minimal example explaining my problem, where I kept al the names as I used >> in my previous mails. I hope that after seeing my example, someone can >> explain me what I am doing wrong here. I included a script that reproduces >> the problem. >> >> Cheers, >> Sven > > I'm not much of an expert with CMake, but I can explain to you what > I've done, at least. > > If I understand correctly, package X makes use of package Y, but > during compilation, it cannot find it? I think what you can do > depends on whether X and Y are in two separate source trees. > > If they are, then it is almost like Y is the zlib library. Then what > you can do is, like the zlib library, install it into a system > directory (i.e., via INSTALL ()) and then X will use a FIND_PACKAGE to > look for it. > > But, suppose Y isn't like zlib. For example, it is a library that is > within the same source tree and will only ever be used by X (both of > which are written by you). I think this is the scenario that you're > talking about? In my case, I have done this in my CMakeLists.txt: > > SET (CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}) > > I guess you can set it > [https://cmake.org/cmake/help/v3.3/variable/CMAKE_LIBRARY_OUTPUT_DIRECTORY.html] > to anything so that all of the libraries will be installed into one > place without doing an INSTALL. Of course, this directory is or > somewhere within the build/ directory. (I suppose doing an install > into ${CMAKE_BINARY_DIR} would achieve the same thing?) > > I had previously installed Y's archive into a system directory, but > besides the need to run FIND_PACKAGE, I thought it was "silly" to > install an archive into a system directory that is only used by my own > program. Seems a bit messy and intrusive to the end-user -- my > libraries are quite unlike zlib; few chance someone else will use it > :-) . At the very least, this approach keeps it in one place within > build/ . > > I'm not sure if it is the "right" way to do it, but this is what I do > at the moment... I hope it helps! > > Ray From rwan.work at gmail.com Tue Jun 28 06:25:01 2016 From: rwan.work at gmail.com (Raymond Wan) Date: Tue, 28 Jun 2016 18:25:01 +0800 Subject: [CMake] How do you handle recursive dependencies in CMake In-Reply-To: <57724B62.2010001@rug.nl> References: <57583A66.1050709@rug.nl> <575AA5B7.7060408@rug.nl> <577242D7.70308@rug.nl> <57724B62.2010001@rug.nl> Message-ID: Hi Sven, On Tue, Jun 28, 2016 at 6:03 PM, Sven Baars wrote: > The packages I use are installed in a non-standard path, because I don't > have access to the system directories on most systems I work on, but are > used by many other libraries. They are also all separate packages, not > packages in the same source tree. I did not see my attachment on the > mailing list archive, so instead I just put it on Github. It can be > found here: > > https://github.com/Sbte/cmake-example > > I hope the example shows my workflow, and also what doesn't work for me. Hmmmm, in that case, I should probably remain quiet as this is not quite something I've had to do. Maybe the only advice I can give is, if you plan to distribute your work to others, what are your expectations in terms of where do you think users should install these dependencies. For example, if it's a system-level directory, then maybe you can consider a FIND_PACKAGE solution which has a list of default paths to search. When you're developing on your own computer, you just change the default path to include paths in your home directory. There is also the ExternalProject () directive which you could consider [https://cmake.org/cmake/help/v3.3/module/ExternalProject.html] . This would retrieve the dependencies from outside sources (i.e., repositories) and build them. This would keep everything within the same build/ path and I haven't done that (and didn't mention it before) because all of my packages are within the same source tree. So, still not quite your situation, though. I hope this helps! Perhaps others can chime in and help you with exactly what you're stuck with... Ray From s.baars at rug.nl Tue Jun 28 06:35:45 2016 From: s.baars at rug.nl (Sven Baars) Date: Tue, 28 Jun 2016 12:35:45 +0200 Subject: [CMake] How do you handle recursive dependencies in CMake In-Reply-To: References: <57583A66.1050709@rug.nl> <575AA5B7.7060408@rug.nl> <577242D7.70308@rug.nl> <57724B62.2010001@rug.nl> Message-ID: <57725301.9050801@rug.nl> Hey Ray, Project A is used by many projects, and so is project B. So ExternalProject is not the right solution. I just want to be able to fix project B in such a way that people, including myself, can easily use it without knowledge of where project A is located. The packages will all be used mostly on supercomputers, where users never have rights to install anything, and even if they install them as a module, it is still in a non-standard path. As you can see from the example, this works fine for project B which depends on A, but not for project C which depends on B. Even if you set the PATH correctly. Sven On 06/28/2016 12:25 PM, Raymond Wan wrote: > Hi Sven, > > > On Tue, Jun 28, 2016 at 6:03 PM, Sven Baars wrote: >> The packages I use are installed in a non-standard path, because I don't >> have access to the system directories on most systems I work on, but are >> used by many other libraries. They are also all separate packages, not >> packages in the same source tree. I did not see my attachment on the >> mailing list archive, so instead I just put it on Github. It can be >> found here: >> >> https://github.com/Sbte/cmake-example >> >> I hope the example shows my workflow, and also what doesn't work for me. > > Hmmmm, in that case, I should probably remain quiet as this is not > quite something I've had to do. > > Maybe the only advice I can give is, if you plan to distribute your > work to others, what are your expectations in terms of where do you > think users should install these dependencies. > > For example, if it's a system-level directory, then maybe you can > consider a FIND_PACKAGE solution which has a list of default paths to > search. When you're developing on your own computer, you just change > the default path to include paths in your home directory. > > There is also the ExternalProject () directive which you could > consider [https://cmake.org/cmake/help/v3.3/module/ExternalProject.html] > . This would retrieve the dependencies from outside sources (i.e., > repositories) and build them. This would keep everything within the > same build/ path and I haven't done that (and didn't mention it > before) because all of my packages are within the same source tree. > > So, still not quite your situation, though. > > I hope this helps! Perhaps others can chime in and help you with > exactly what you're stuck with... > > Ray From simon.ricaldone at circabs.com Tue Jun 28 05:00:36 2016 From: simon.ricaldone at circabs.com (Simon Ricaldone) Date: Tue, 28 Jun 2016 09:00:36 +0000 Subject: [CMake] CMake Windows Visual Studio 14 problems Message-ID: Hello Firstly I am very new to CMake, C and Visual Studio so please excuse my ignorance! My problem is I am trying to convert an old Visual Studio 6 project into a Visual Studio 14 2015 solution using CMake, however I am having difficulties settings compiler flags. I have been unable to find relevant documentation or advice on web on how to achieve the necessary builds steps I need to achieve. The build I am trying to achieve is as following; 1. Use cl.exe to compile source but not link code 2. Use rc.exe to embed resource file into object code 3. Use link.exe to link objects into a DLL The problem I am having is the link stage probably due to an issue with the compiler flags I am setting via CMAKE_C_FLAGS, CMAKE_RC_FLAGS and CMAKE_LINKER_FLAGS, they appear not to override the default CMAKE settings. I have attached a copy of my CMakeLists.txt file to see if I am missing the obvious! Thanks in advance Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: CMakeLists.txt URL: From cfyzium at gmail.com Tue Jun 28 08:41:08 2016 From: cfyzium at gmail.com (Cfyz) Date: Tue, 28 Jun 2016 15:41:08 +0300 Subject: [CMake] How do you handle recursive dependencies in CMake In-Reply-To: <57725301.9050801@rug.nl> References: <57583A66.1050709@rug.nl> <575AA5B7.7060408@rug.nl> <577242D7.70308@rug.nl> <57724B62.2010001@rug.nl> <57725301.9050801@rug.nl> Message-ID: Hello. I've posted a message a few days ago on a very similar subject. Didn't know there was a discussion already. The main problem in my opinion is that CMake target exporting system does not handle transitive dependencies at all. CMake handles them correctly at the build step, but not at the export. As I've noted in my message there is a small hint on that being a conscious decision: documentation about target_link_libraries and relevant target properties advises not to include paths to dependencies into the target interface as it would hard-code dependencies' locations. Personally I do not agree with that as I see neither any way around specifying paths to dependencies not any substantial harm in that. Maybe I am missing something but as far as I've found there was not discussion about this matter before. With that there are some ways to make transitive dependencies work. Though you'll have to forsake most of CMake's export machinery. Probably the easiest way is to make each library export it's full interface in the Foo_INCLUDE_DIRS / Foo_LIBRARIES variables. By writing the AConfig.cmake by hand you can figure out and export the full path to the A. Therefore AConfig.cmake will essentially be: get_filename_component(A_CONFIG_DIR "${CMAKE_CURRENT_LIST_FILE}" PATH) find_library(A_LIB "A" HINTS ${A_CONFIG_DIR}/../../../lib) set(A_INCLUDE_DIRS ${A_CONFIG_DIR}/../../../include) set(A_LIBRARIES ${A_LIB}) set(A_FOUND TRUE) >From here on, every other library which care about its dependencies will have to export its interface in a similar way. However, since BConfig.cmake cannot find A by itself, it will need some help from the project configuration step. B project will need to gather its interface and do a configure_file() fixing B's interface dependencies in it: find_package(A) list(APPEND B_INTERFACE_INCLUDE_DIRS ${A_INCLUDE_DIRS}) list(APPEND B_INTERFACE_LIBRARIES ${A_LIBRARIES}) # here comes the full path to A library ... configure_file(BConfig.cmake.in ${CMAKE_CURRENT_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/BConfig.cmake @ONLY) Where BConfig.cmake.in may look like: get_filename_component(B_CONFIG_DIR "${CMAKE_CURRENT_LIST_FILE}" PATH) find_library(B_LIB "B" HINTS ${B_CONFIG_DIR}/../../../lib) set(B_INCLUDE_DIRS ${B_CONFIG_DIR}/../../../include @B_INTERFACE_INCLUDE_DIRS@) set(B_LIBRARIES ${B_LIB} @B_INTERFACE_LIBRARIES@) set(B_FOUND TRUE) Now find_package(B) will export B_INCLUDE_DIRS / B_LIBRARIES which will list full paths to everything necessary to build against it. At my company we usually use static libraries so that it's rarely a problem but with dynamic libraries (.so) this approach will not be enough to run the app. Searching for dynamic libraries is not exactly the build system responsibility, though and greatly depends on the platform and the way you distribute the resulting application. If anything it always possible to make another transitive Foo_RPATHS property. This 'simple' approach does not work with libraries that export 'imported targets' only (if I recall correctly, the Qt find module exports Qt::XYZ targets but not Qt_LIBRARIES) so that there is no interface variables to merge. In this case one would need to iterate over imported targets and merge their INTERFACE_xxx properties in a similar way. I believe this to be an oversight. Everything should be fine if there was an option to resolve and export transitive dependencies along the targets in CMake export() command. Probably this may be fixed by an external helper script (similar to CMakePackageConfigHelpers module) providing some function that takes a list of targets, analyzes them and writes a config file complete with targets and their dependencies. On 28 June 2016 at 13:35, Sven Baars wrote: > Hey Ray, > > Project A is used by many projects, and so is project B. So > ExternalProject is not the right solution. I just want to be able to fix > project B in such a way that people, including myself, can easily use it > without knowledge of where project A is located. The packages will all > be used mostly on supercomputers, where users never have rights to > install anything, and even if they install them as a module, it is still > in a non-standard path. As you can see from the example, this works fine > for project B which depends on A, but not for project C which depends on > B. Even if you set the PATH correctly. > > Sven > > On 06/28/2016 12:25 PM, Raymond Wan wrote: > > Hi Sven, > > > > > > On Tue, Jun 28, 2016 at 6:03 PM, Sven Baars wrote: > >> The packages I use are installed in a non-standard path, because I don't > >> have access to the system directories on most systems I work on, but are > >> used by many other libraries. They are also all separate packages, not > >> packages in the same source tree. I did not see my attachment on the > >> mailing list archive, so instead I just put it on Github. It can be > >> found here: > >> > >> https://github.com/Sbte/cmake-example > >> > >> I hope the example shows my workflow, and also what doesn't work for me. > > > > Hmmmm, in that case, I should probably remain quiet as this is not > > quite something I've had to do. > > > > Maybe the only advice I can give is, if you plan to distribute your > > work to others, what are your expectations in terms of where do you > > think users should install these dependencies. > > > > For example, if it's a system-level directory, then maybe you can > > consider a FIND_PACKAGE solution which has a list of default paths to > > search. When you're developing on your own computer, you just change > > the default path to include paths in your home directory. > > > > There is also the ExternalProject () directive which you could > > consider [https://cmake.org/cmake/help/v3.3/module/ExternalProject.html] > > . This would retrieve the dependencies from outside sources (i.e., > > repositories) and build them. This would keep everything within the > > same build/ path and I haven't done that (and didn't mention it > > before) because all of my packages are within the same source tree. > > > > So, still not quite your situation, though. > > > > I hope this helps! Perhaps others can chime in and help you with > > exactly what you're stuck with... > > > > Ray > > -- > > 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 s.baars at rug.nl Tue Jun 28 09:07:19 2016 From: s.baars at rug.nl (Sven Baars) Date: Tue, 28 Jun 2016 15:07:19 +0200 Subject: [CMake] How do you handle recursive dependencies in CMake In-Reply-To: References: <57583A66.1050709@rug.nl> <575AA5B7.7060408@rug.nl> <577242D7.70308@rug.nl> <57724B62.2010001@rug.nl> <57725301.9050801@rug.nl> Message-ID: <57727687.9080202@rug.nl> Hey Cfyz, After reading your post to the list, it does indeed seem like we have the same problem. I also wrote a lot of homebrew code you mentioned at the end of the post, but it indeed always seems to always break something for some user of the code, even though it seems to work for everyone else. Hence my question if there is some "right" way of doing this with CMake, without all of the code I wrote to work around the problem. In the mean time I'll have a look at the code you wrote, but it seems very similar to something I already had, which broke for some users. Sven On 06/28/2016 02:35 PM, Cfyz wrote: > Hello. > > I've posted a message a few days ago on a very similar subject. Didn't > know there was a discussion already. > > The main problem in my opinion is that CMake target exporting system > does not handle transitive dependencies at all. CMake handles them > correctly at the build step, but not at the export. As I've noted in > my message there is a small hint on that being a conscious decision: > documentation about target_link_libraries and relevant target > properties advises not to include paths to dependencies into the > target interface as it would hard-code dependencies' locations. > Personally I do not agree with that as I see neither any way around > specifying paths to dependencies not any substantial harm in that. > Maybe I am missing something but as far as I've found there was not > discussion about this matter before. > > With that there are some ways to make transitive dependencies work. > Though you'll have to forsake most of CMake's export machinery. > Probably the easiest way is to make each library export it's full > interface in the Foo_INCLUDE_DIRS / Foo_LIBRARIES variables. By > writing the AConfig.cmake by hand you can figure out and export the > full path to the A. Therefore AConfig.cmake will essentially be: > > get_filename_component(A_CONFIG_DIR "${CMAKE_CURRENT_LIST_FILE}" PATH) > find_library(A_LIB "A" HINTS ${A_CONFIG_DIR}/../../../lib) > set(A_INCLUDE_DIRS ${A_CONFIG_DIR}/../../../include) > set(A_LIBRARIES ${A_LIB}) > set(A_FOUND TRUE) > > From here on, every other library which care about its dependencies > will have to export its interface in a similar way. However, since > BConfig.cmake cannot find A by itself, it will need some help from the > project configuration step. B project will need to gather its > interface and do a configure_file() fixing B's interface dependencies > in it: > > find_package(A) > list(APPEND B_INTERFACE_INCLUDE_DIRS ${A_INCLUDE_DIRS}) > list(APPEND B_INTERFACE_LIBRARIES ${A_LIBRARIES}) # here comes the > full path to A library > ... > configure_file(BConfig.cmake.in > ${CMAKE_CURRENT_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/BConfig.cmake @ONLY) > > Where BConfig.cmake.in may look like: > > get_filename_component(B_CONFIG_DIR "${CMAKE_CURRENT_LIST_FILE}" PATH) > find_library(B_LIB "B" HINTS ${B_CONFIG_DIR}/../../../lib) > set(B_INCLUDE_DIRS ${B_CONFIG_DIR}/../../../include > @B_INTERFACE_INCLUDE_DIRS@) > set(B_LIBRARIES ${B_LIB} @B_INTERFACE_LIBRARIES@) > set(B_FOUND TRUE) > > Now find_package(B) will export B_INCLUDE_DIRS / B_LIBRARIES which > will list full paths to everything necessary to build against it. > > At my company we usually use static libraries so that it's rarely a > problem but with dynamic libraries (.so) this approach will not be > enough to run the app. Searching for dynamic libraries is not exactly > the build system responsibility, though and greatly depends on the > platform and the way you distribute the resulting application. If > anything it always possible to make another transitive Foo_RPATHS > property. > > This 'simple' approach does not work with libraries that export > 'imported targets' only (if I recall correctly, the Qt find module > exports Qt::XYZ targets but not Qt_LIBRARIES) so that there is no > interface variables to merge. In this case one would need to iterate > over imported targets and merge their INTERFACE_xxx properties in a > similar way. > > I believe this to be an oversight. Everything should be fine if there > was an option to resolve and export transitive dependencies along the > targets in CMake export() command. Probably this may be fixed by an > external helper script (similar to CMakePackageConfigHelpers module) > providing some function that takes a list of targets, analyzes them > and writes a config file complete with targets and their dependencies. > > On 28 June 2016 at 13:35, Sven Baars > wrote: > > Hey Ray, > > Project A is used by many projects, and so is project B. So > ExternalProject is not the right solution. I just want to be able > to fix > project B in such a way that people, including myself, can easily > use it > without knowledge of where project A is located. The packages will all > be used mostly on supercomputers, where users never have rights to > install anything, and even if they install them as a module, it is > still > in a non-standard path. As you can see from the example, this > works fine > for project B which depends on A, but not for project C which > depends on > B. Even if you set the PATH correctly. > > Sven > > On 06/28/2016 12:25 PM, Raymond Wan wrote: > > Hi Sven, > > > > > > On Tue, Jun 28, 2016 at 6:03 PM, Sven Baars > wrote: > >> The packages I use are installed in a non-standard path, > because I don't > >> have access to the system directories on most systems I work > on, but are > >> used by many other libraries. They are also all separate > packages, not > >> packages in the same source tree. I did not see my attachment > on the > >> mailing list archive, so instead I just put it on Github. It can be > >> found here: > >> > >> https://github.com/Sbte/cmake-example > >> > >> I hope the example shows my workflow, and also what doesn't > work for me. > > > > Hmmmm, in that case, I should probably remain quiet as this is not > > quite something I've had to do. > > > > Maybe the only advice I can give is, if you plan to distribute your > > work to others, what are your expectations in terms of where do you > > think users should install these dependencies. > > > > For example, if it's a system-level directory, then maybe you can > > consider a FIND_PACKAGE solution which has a list of default > paths to > > search. When you're developing on your own computer, you just > change > > the default path to include paths in your home directory. > > > > There is also the ExternalProject () directive which you could > > consider > [https://cmake.org/cmake/help/v3.3/module/ExternalProject.html] > > . This would retrieve the dependencies from outside sources (i.e., > > repositories) and build them. This would keep everything within the > > same build/ path and I haven't done that (and didn't mention it > > before) because all of my packages are within the same source tree. > > > > So, still not quite your situation, though. > > > > I hope this helps! Perhaps others can chime in and help you with > > exactly what you're stuck with... > > > > Ray > > -- > > 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 arankin at robarts.ca Tue Jun 28 09:51:47 2016 From: arankin at robarts.ca (Adam Rankin) Date: Tue, 28 Jun 2016 13:51:47 +0000 Subject: [CMake] [Visual Studio] Is it possible to specify a different target architecture? Message-ID: Hello all, I am wondering if there exist CMake commands/variables to specify for Visual Studio to have the project file(s) generated target a different architecture than the one associated with that version of Visual Studio. For example, I develop in VS2015, but would like to target the VS2012 redistributable (v110). Is this possible? Kind regards, Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From bballet at ivsweb.com Tue Jun 28 09:58:45 2016 From: bballet at ivsweb.com (Benjamin Ballet) Date: Tue, 28 Jun 2016 15:58:45 +0200 Subject: [CMake] [Visual Studio] Is it possible to specify a different target architecture? In-Reply-To: References: Message-ID: Hi Look at the CMAKE_VS_PLATFORM_TOOLSET variable 2016-06-28 15:51 GMT+02:00 Adam Rankin : > Hello all, > > > > I am wondering if there exist CMake commands/variables to specify for > Visual Studio to have the project file(s) generated target a different > architecture than the one associated with that version of Visual Studio. > > > > For example, I develop in VS2015, but would like to target the VS2012 > redistributable (v110). > > > > Is this possible? > > > > Kind regards, > > Adam > > -- > > 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 *ACTIVISU* 19, rue Klock - 92110 Clichy *> Standard T?l* : 01 44 69 37 37 *>* www.activisu.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From arankin at robarts.ca Tue Jun 28 09:59:45 2016 From: arankin at robarts.ca (Adam Rankin) Date: Tue, 28 Jun 2016 13:59:45 +0000 Subject: [CMake] [Visual Studio] Is it possible to specify a different target architecture? In-Reply-To: References: Message-ID: <2a8bc3c9d43b4f958b2540c101bbfd2b@dag2.robarts.ca> Well now don?t I feel silly? Thanks! Adam From: Benjamin Ballet [mailto:bballet at ivsweb.com] Sent: Tuesday, June 28, 2016 9:59 AM To: Adam Rankin Cc: cmake at cmake.org Subject: Re: [CMake] [Visual Studio] Is it possible to specify a different target architecture? Hi Look at the CMAKE_VS_PLATFORM_TOOLSET variable 2016-06-28 15:51 GMT+02:00 Adam Rankin >: Hello all, I am wondering if there exist CMake commands/variables to specify for Visual Studio to have the project file(s) generated target a different architecture than the one associated with that version of Visual Studio. For example, I develop in VS2015, but would like to target the VS2012 redistributable (v110). Is this possible? Kind regards, Adam -- 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 ACTIVISU 19, rue Klock - 92110 Clichy > Standard T?l : 01 44 69 37 37 > www.activisu.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From rwan.work at gmail.com Tue Jun 28 10:19:18 2016 From: rwan.work at gmail.com (Raymond Wan) Date: Tue, 28 Jun 2016 22:19:18 +0800 Subject: [CMake] How do you handle recursive dependencies in CMake In-Reply-To: References: <57583A66.1050709@rug.nl> <575AA5B7.7060408@rug.nl> <577242D7.70308@rug.nl> <57724B62.2010001@rug.nl> <57725301.9050801@rug.nl> Message-ID: Hi, On Tue, Jun 28, 2016 at 8:41 PM, Cfyz wrote: > dependencies' locations. Personally I do not agree with that as I see > neither any way around specifying paths to dependencies not any substantial > harm in that. Maybe I am missing something but as far as I've found there > was not discussion about this matter before. Actually, there has been discussions about transitive dependencies before. In fact, such discussions crop up once a month or two. See for example, http://public.kitware.com/pipermail/cmake/2016-January/062590.html (which I did reply, also with a link to my GitHub repository with a minimal example). Perhaps many others before me have also done the same. [Again, just because I reply doesn't mean I think I'm right...I'm learning through discussions, as well!] In my humble opinion, Sven's problem is two-fold. They are inter-related, but they could be separated. The first is the transitive dependency and for this, if it's all within the same source code tree then something like what I did could work. The second is that the dependencies are not installed in system-level directories, even though multiple users on a super-computer need to share them. Because of this second factor, I don't have an idea what Sven should do. Indeed, what you suggest could work -- as I don't have a need, I haven't given that much thought. I think if I were presented with the same problem as Sven, I'd ask the system administrator to install it. Or, if that wasn't possible, use ExternalProject. Yes, if there are 100 users, then there would be 100 copies of the dependency. But, running CMake will grab the most recent copy from the source repository. It's inefficient in terms of disk space, but at least A (assuming A depends on B) will be built correctly. I don't know if CMake's aim is to build software correctly *and* save disk space... :-) Ray From greg.marr at autodesk.com Tue Jun 28 10:00:00 2016 From: greg.marr at autodesk.com (Greg Marr) Date: Tue, 28 Jun 2016 14:00:00 +0000 Subject: [CMake] [Visual Studio] Is it possible to specify a different target architecture? Message-ID: <6748874E-E31D-4666-852A-2C19826F11CB@autodesk.com> From: CMake > on behalf of Adam Rankin > Date: Tuesday, June 28, 2016 at 9:51 AM To: "cmake at cmake.org" > Subject: [CMake] [Visual Studio] Is it possible to specify a different target architecture? Hello all, I am wondering if there exist CMake commands/variables to specify for Visual Studio to have the project file(s) generated target a different architecture than the one associated with that version of Visual Studio. For example, I develop in VS2015, but would like to target the VS2012 redistributable (v110). Add the command line parameter `-T v110` https://cmake.org/cmake/help/v3.0/manual/cmake.1.html -T Specify toolset name if supported by generator. Some CMake generators support a toolset name to be given to the native build system to choose a compiler. This is supported only on specific generators: Visual Studio >= 10 Xcode >= 3.0 See native build system documentation for allowed toolset names. -------------- next part -------------- An HTML attachment was scrubbed... URL: From post at hendrik-sattler.de Tue Jun 28 10:54:38 2016 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Tue, 28 Jun 2016 16:54:38 +0200 Subject: [CMake] [Visual Studio] Is it possible to specify a different target architecture? In-Reply-To: References: Message-ID: <65AAEFB1-7B1D-475F-AF55-1B0BFA82AF1A@hendrik-sattler.de> Hi, Yes, it is possible. Generate the solution for Visual Studio 11 2012 and open it in VS2015. VS will ask you once if to convert the project and you say no. Done. HS Am 28. Juni 2016 15:51:47 MESZ, schrieb Adam Rankin : >Hello all, > >I am wondering if there exist CMake commands/variables to specify for >Visual Studio to have the project file(s) generated target a different >architecture than the one associated with that version of Visual >Studio. > >For example, I develop in VS2015, but would like to target the VS2012 >redistributable (v110). > >Is this possible? > >Kind regards, >Adam > > >------------------------------------------------------------------------ -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. From cfyzium at gmail.com Tue Jun 28 15:23:32 2016 From: cfyzium at gmail.com (Cfyz) Date: Tue, 28 Jun 2016 22:23:32 +0300 Subject: [CMake] How do you handle recursive dependencies in CMake In-Reply-To: <57727687.9080202@rug.nl> References: <57583A66.1050709@rug.nl> <575AA5B7.7060408@rug.nl> <577242D7.70308@rug.nl> <57724B62.2010001@rug.nl> <57725301.9050801@rug.nl> <57727687.9080202@rug.nl> Message-ID: Hello Sven, Raymond. On 28 June 2016 at 16:07, Sven Baars wrote: > Hence my question if there is some "right" way of doing this with CMake, without all of the code I wrote to work around the problem. I am under impression there is an important bit missing from CMake export system. If some library has an unspecified set of dependencies (decided during its configuration) then it will not be able to generate a config file for find_package with CMake default tools alone. I think I will raise it as an issue at the main CMake issue tracker after some more investigation. On 28 June 2016 at 16:07, Sven Baars wrote: > I also wrote a lot of homebrew code you mentioned at the end of the post, but it indeed always seems to always break something for some user of the code > In the mean time I'll have a look at the code you wrote, but it seems very similar to something I already had, which broke for some users. The code examples and what I've mentioned earlier are just pieces of the possible solution. A complete export has a lot of nuances (e. g. versioning, build configurations, etc.) and is unlikely to work flawlessly right from the start. But think it might be worthwhile to try and make such helper module somewhere on github. On 28 June 2016 at 17:19, Raymond Wan wrote: > I think if I were presented with the same problem as Sven, I'd <...> Or, if that wasn't possible, use ExternalProject. > It's inefficient in terms of disk space, but at least A (assuming A depends on B) will be built correctly. What I'm trying to solve (and what Sven's problem looks very similar to) is more about keeping the information about dependencies. You've mentioned that yourself in the linked discussion: the real problem are projects with complex tree-like dependencies, more than one edge deep. And once those dependencies become optional and configurable, things break completely. It is impossible to search for the dependency you don't even know about =(. ExternalProject has a somewhat similar flaw. I've tried once to use it for FFmpeg and found out that ExternalProject does its work at the build step. On the configure step there is nothing yet and consequently there is no way to figure out what will be needed to link against the library. Even though FFmpeg does report its dependencies (via pkg-config) later after being installed, it is too late. There was a workaround with two-step build but that looked ugly, scaled even worse and I've settled on separate builds and custom find modules. -------------- next part -------------- An HTML attachment was scrubbed... URL: From roman.wueger at gmx.at Tue Jun 28 17:01:56 2016 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Tue, 28 Jun 2016 23:01:56 +0200 Subject: [CMake] [iOS] What is the correct way to add resources to an XCode project In-Reply-To: <21D325C1-601B-4393-8BBB-7D82B36456E7@gmx.at> References: <21D325C1-601B-4393-8BBB-7D82B36456E7@gmx.at> Message-ID: No one? The target property RESOURCE does only allow files but no directories. Regards Roman > Am 22.06.2016 um 17:22 schrieb Roman W?ger : > > Hello, > > I read the mailing list but did find a way which works. > > At the moment I use Xcode 7.3.1 and CMake 3.5.2 which creates a project for iOS 9.3. > > All I want is to add the directory "Images.xcassets" and a second directory structure to be copied to the Resource folder listed in XCode. > > When I manually drag'n drop the directories into the Resource folder as reference or as group everything is working. How can I archive this with CMake? > > Thanks and 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 patrick.boettcher at posteo.de Tue Jun 28 18:04:38 2016 From: patrick.boettcher at posteo.de (Patrick Boettcher) Date: Wed, 29 Jun 2016 00:04:38 +0200 Subject: [CMake] Dependency on imported target with ninja-generator In-Reply-To: References: <20160622175933.18907b01@posteo.de> Message-ID: <20160629000438.1d037a0d@vdr> On Wed, 22 Jun 2016 19:44:14 -0500 Nicholas Braden wrote: > If Project B depends on Project A, you should probably be using the > ExternalProject module with a superproject structure that builds both > projects in the proper order. > > https://cmake.org/cmake/help/latest/module/ExternalProject.html > > Trying to manually call CMake is not really a good idea IMO - let > ExternalProject handle it for you. That was it: superproject - based on CMake + ExternalProject. Thanks a lot. Regards, -- Patrick. From cristall at eleveneng.com Tue Jun 28 19:19:15 2016 From: cristall at eleveneng.com (Sam Cristall) Date: Tue, 28 Jun 2016 17:19:15 -0600 Subject: [CMake] CMAKE_C_COMPILE_OBJECT vs Message-ID: I'm trying to implement a cross compilation wrapper and hit a snag with CMAKE_C_COMPILE_OBJECT. I've found that on OSX / Linux (Makefile Generator), and work as expected, however on Windows (MinGW Makefile Generator), has both the flags and includes, whereas is undefined. Is this expected? Sam Cristall, BSc. EE Director, R&D skype: sam.cristall phone: +1-780-292-0423 <> Eleven Engineering Inc. 10150 100 st, Suite 800 Edmonton, Alberta Canada, T5J 0P6 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ruslan_baratov at yahoo.com Tue Jun 28 19:48:29 2016 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Wed, 29 Jun 2016 02:48:29 +0300 Subject: [CMake] [iOS] What is the correct way to add resources to an XCode project In-Reply-To: References: <21D325C1-601B-4393-8BBB-7D82B36456E7@gmx.at> Message-ID: <4a615877-e0b1-2ba4-7a67-fa6626acf459@yahoo.com> Hi, I have used two approaches which is not based on assets directories. First is to save icons to resources with special names. In this case Xcode will add them automatically, see: * https://github.com/forexample/testapp/blob/9202304134862f043af740af27dc7efb3b3f565d/CMakeLists.txt#L28 Second is to save icons to resources too, but you can control names of pictures. You have to update *.plist file in this case. * custom names: https://github.com/ruslo/weather/blob/56eee62eaac327e1a048165aaa868c2f3a71972f/Source/weather/ui/ios/icons/app/sugar.cmake#L15 * plist file: https://github.com/ruslo/weather/blob/56eee62eaac327e1a048165aaa868c2f3a71972f/Source/weather/ui/ios/views/plist.in#L35 * adding to resources: https://github.com/ruslo/weather/blob/56eee62eaac327e1a048165aaa868c2f3a71972f/Source/weather/ui/ios/CMakeLists.txt#L49 Also according to my reverse engineering skills next xcode variables used to define assets directories for icons and launch images: * ASSETCATALOG_COMPILER_APPICON_NAME * ASSETCATALOG_COMPILER_LAUNCHIMAGE_NAME This means you can experiment with target properties: * XCODE_ATTRIBUTE_ASSETCATALOG_COMPILER_APPICON_NAME * XCODE_ATTRIBUTE_ASSETCATALOG_COMPILER_LAUNCHIMAGE_NAME I have never used them before, so have no idea about it's working or not. Ruslo On 29-Jun-16 00:01, Roman W?ger wrote: > No one? > > The target property RESOURCE does only allow files but no directories. > > Regards > Roman > > >> Am 22.06.2016 um 17:22 schrieb Roman W?ger : >> >> Hello, >> >> I read the mailing list but did find a way which works. >> >> At the moment I use Xcode 7.3.1 and CMake 3.5.2 which creates a project for iOS 9.3. >> >> All I want is to add the directory "Images.xcassets" and a second directory structure to be copied to the Resource folder listed in XCode. >> >> When I manually drag'n drop the directories into the Resource folder as reference or as group everything is working. How can I archive this with CMake? >> >> Thanks and 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 rwan.work at gmail.com Tue Jun 28 22:08:40 2016 From: rwan.work at gmail.com (Raymond Wan) Date: Wed, 29 Jun 2016 10:08:40 +0800 Subject: [CMake] How do you handle recursive dependencies in CMake In-Reply-To: References: <57583A66.1050709@rug.nl> <575AA5B7.7060408@rug.nl> <577242D7.70308@rug.nl> <57724B62.2010001@rug.nl> <57725301.9050801@rug.nl> <57727687.9080202@rug.nl> Message-ID: On Wed, Jun 29, 2016 at 3:23 AM, Cfyz wrote: > On 28 June 2016 at 17:19, Raymond Wan wrote: >> I think if I were presented with the same problem as Sven, I'd <...> Or, >> if that wasn't possible, use ExternalProject. >> It's inefficient in terms of disk space, but at least A (assuming A >> depends on B) will be built correctly. > What I'm trying to solve (and what Sven's problem looks very similar to) is > more about keeping the information about dependencies. You've mentioned that > yourself in the linked discussion: the real problem are projects with > complex tree-like dependencies, more than one edge deep. And once those > dependencies become optional and configurable, things break completely. It > is impossible to search for the dependency you don't even know about =(. I agree that what we're observing is a problem, but I don't think it is that big. There are at least 3 solutions discussed so far: 1) The "ad-hoc" method I first mentioned by setting CMAKE_LIBRARY_OUTPUT_DIRECTORY. 2) ExternalProject which will grab a repository and build it. 3) Some Find_Package () mechanism that will do a search for it. 4) Your option of including *.cmake files that provide the paths [sorry, I might have misunderstood it]. If we have some kind of transitive dependency: A depends on B; B depends on C. Then when we build A, we don't really need to know [in detail] that this transitive dependency exists (*). All the compiler needs to know is where is B and where is C. And if B and C are in the same directory (i.e., a system-level directory), that's fine. Suppose B and C are in two different directories. I don't know if it's common, but often, I see install scripts provide a symbolic link from the system-level directory to where B and C are In Sven's case (sorry to put you on the spot, Sven! :-) ), the 3 options don't work because: 1) Modules are in different source trees. 2) Duplication between users on a super-computer. 3) Too many combinations of Find_Package (). 4) Seems ad-hoc? Though not perfect, either (2) or (3) could solve Sven's problem. For (2), ignore duplication. For (3), how about something like what Find_Boost does? It searches for system-level directories, but you can nudge it by setting an environment variable (i.e., BOOST_ROOT) where it will search first. This means each user will have to set an environment variable (or set it on the command-line of CMake with -D). Hmmmmm, I *think* any of this is fine (for Sven's problem), but if it isn't then perhaps I'm misunderstanding the problem... Ray (*) At least, the order to the archives in target_link_libraries have to be correct. But that is done once by the CMakeLists.txt writer and not something the end user needs to worry about. From roman.wueger at gmx.at Wed Jun 29 01:15:18 2016 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Wed, 29 Jun 2016 07:15:18 +0200 Subject: [CMake] Patch for CM_OVERRIDE Message-ID: Hello, I've attached a patch for the CM_OVERRIDE commit Best Regards Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-fixup-CM_OVERRIDE-Visual-Studio-2010-and-below-do-no.patch Type: application/octet-stream Size: 825 bytes Desc: not available URL: -------------- next part -------------- From ben.boeckel at kitware.com Wed Jun 29 08:52:48 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 29 Jun 2016 08:52:48 -0400 Subject: [CMake] [cmake-developers] [iOS] What is the correct way to add resources to an XCode project In-Reply-To: References: <21D325C1-601B-4393-8BBB-7D82B36456E7@gmx.at> Message-ID: <20160629125248.GA17842@megas.kitware.com> On Tue, Jun 28, 2016 at 23:01:56 +0200, Roman W?ger wrote: > The target property RESOURCE does only allow files but no directories. There's an open issue for this: https://gitlab.kitware.com/cmake/cmake/issues/14743 --Ben From roman.wueger at gmx.at Wed Jun 29 10:48:10 2016 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Wed, 29 Jun 2016 16:48:10 +0200 Subject: [CMake] [cmake-developers] [iOS] What is the correct way to add resources to an XCode project In-Reply-To: <20160629125248.GA17842@megas.kitware.com> References: <21D325C1-601B-4393-8BBB-7D82B36456E7@gmx.at> <20160629125248.GA17842@megas.kitware.com> Message-ID: <2CE602FB-9C41-4D77-856F-ED148765CC08@gmx.at> Thanks Ben, I know because I wrote this ticket. I thought this was "closed/want fixed" because of the implementation for RESOURCE a few days ago. Regards Roman > Am 29.06.2016 um 14:52 schrieb Ben Boeckel : > >> On Tue, Jun 28, 2016 at 23:01:56 +0200, Roman W?ger wrote: >> The target property RESOURCE does only allow files but no directories. > > There's an open issue for this: > > https://gitlab.kitware.com/cmake/cmake/issues/14743 > > --Ben From ben.boeckel at kitware.com Wed Jun 29 11:27:31 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 29 Jun 2016 11:27:31 -0400 Subject: [CMake] [cmake-developers] [iOS] What is the correct way to add resources to an XCode project In-Reply-To: <2CE602FB-9C41-4D77-856F-ED148765CC08@gmx.at> References: <21D325C1-601B-4393-8BBB-7D82B36456E7@gmx.at> <20160629125248.GA17842@megas.kitware.com> <2CE602FB-9C41-4D77-856F-ED148765CC08@gmx.at> Message-ID: <20160629152731.GB4279@megas.kitware.com> On Wed, Jun 29, 2016 at 16:48:10 +0200, Roman W?ger wrote: > I know because I wrote this ticket. Ah. I didn't check the Mantis side. > I thought this was "closed/want fixed" because of the implementation > for RESOURCE a few days ago. Hmm. I don't see that. Do you have a link? --Ben From cristall at eleveneng.com Wed Jun 29 13:41:40 2016 From: cristall at eleveneng.com (Sam Cristall) Date: Wed, 29 Jun 2016 11:41:40 -0600 Subject: [CMake] CMAKE_C_COMPILE_OBJECT vs In-Reply-To: References: Message-ID: <14455837-B56D-48FE-AB20-82EEB82C4C69@eleveneng.com> Looks like this was just a change in CMake 3.4. Updated to latest, and everything is working. > On Jun 28, 2016, at 5:19 PM, Sam Cristall wrote: > > I'm trying to implement a cross compilation wrapper and hit a snag with CMAKE_C_COMPILE_OBJECT. I've found that on OSX / Linux (Makefile Generator), and work as expected, however on Windows (MinGW Makefile Generator), has both the flags and includes, whereas is undefined. Is this expected? > From cfyzium at gmail.com Wed Jun 29 14:24:48 2016 From: cfyzium at gmail.com (Cfyz) Date: Wed, 29 Jun 2016 21:24:48 +0300 Subject: [CMake] How do you handle recursive dependencies in CMake In-Reply-To: References: <57583A66.1050709@rug.nl> <575AA5B7.7060408@rug.nl> <577242D7.70308@rug.nl> <57724B62.2010001@rug.nl> <57725301.9050801@rug.nl> <57727687.9080202@rug.nl> Message-ID: On 29 June 2016 at 05:08, Raymond Wan wrote: > I agree that what we're observing is a problem, but I don't think it is that big. I must admit I am mixing a bit of my own situation here and trying to think about the most general case. It's just there is a missing bit in the dependency search system and how far will it bleed into a project depends on the situation. In my case it breaks on static libraries. Neither installing in same stage directory nor ExternalProject go around the fact that such targets just does not provide enough to link against them. In case of dynamic libraries, it breaks if components are not located in (or installed to during build) the same path. Library B may find its dependency with some help (e. g. LIB_A_PATH during configure) and list libA.so in the dynamic section. But the next steps will still need to know libA.so location to link. On 29 June 2016 at 05:08, Raymond Wan wrote: > ExternalProject which will grab a repository and build it. Still, what about the fact that ExternalProject provides dependency information on the main project build step, after the configuration? I've found it quite disappointing and severely limiting ExternalProject usefulness. Especially with CMake-based projects where you cannot use usual find_package to search for that external project because its configuration file would not be installed until much later. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tzsariysk at gmail.com Wed Jun 29 15:20:57 2016 From: tzsariysk at gmail.com (TS) Date: Wed, 29 Jun 2016 15:20:57 -0400 Subject: [CMake] how to ctest with pre- and -post processing Message-ID: <005901d1d23b$5d3ae7e0$17b0b7a0$@gmail.com> Hi, Is it possible to have a ctest which involves preprocessing as well as postprocessing. The code I want to test is myCode.exe, which writes an output file OUTPUT. Measure for success is a comparison of OUTPUT against REFERENCE data file. Currently, I use two add_tests: ADD_TEST(code_for_test mpiexec --np 8 myCode.exe input OUTPUT) ADD_TEST(measure_for_success compare.exe OUTPUT REFERENCE 1.e-6) It works, but I believe there are better ways to achieve this. Also, I would like to have a preprocessing step, which removes OUTPUT before running myCode.exe, just to make sure that the comparison is always against the current OUTPUT and not against OUTPUT left from previous runs. What I have in mind is: Remove OUTPUT ? preprocessing step Run myCode.exe ? the code being tested Compare OUTPUT against REFERENCE data. ? measure for PASS/FAIL Thanks in advance, Ted -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Wed Jun 29 15:30:40 2016 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 29 Jun 2016 15:30:40 -0400 Subject: [CMake] [ANNOUNCE] CMake 3.6.0-rc4 now ready for testing! Message-ID: I am proud to announce the fourth CMake 3.6 release candidate. Sources and binaries are available at: https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.6 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.6/release/3.6.html Some of the more significant features of CMake 3.6 are: * The "Visual Studio 14 2015" generator learned to support the Clang/C2 toolsets, e.g. with the "-T v140_clang_3_7" option. This feature is experimental. * The "list()" command gained a "FILTER" sub-command to filter list elements by regular expression. * A "CMAKE_TRY_COMPILE_TARGET_TYPE" variable was added to optionally tell the "try_compile()" command to build a static library instead of an executable. This is useful for cross-compiling toolchains that cannot link binaries without custom flags or scripts. * A "_CLANG_TIDY" target property and supporting "CMAKE__CLANG_TIDY" variable were introduced to tell the Makefile Generators and the "Ninja" generator to run "clang-tidy" along with the compiler for "C" and "CXX" languages. * The "ExternalProject" module leared the "GIT_SHALLOW 1" option to perform a shallow clone of a Git repository. * The "ExternalProject" module learned to initialize Git submodules recursively and also to initialize new submodules on updates. Use the "GIT_SUBMODULES" option to restrict which submodules are initalized and updated. * The "InstallRequiredSystemLibraries" module learned a new "CMAKE_INSTALL_UCRT_LIBRARIES" option to enable app-local deployment of the Windows Universal CRT libraries with Visual Studio 2015. * The "Compile Features" functionality is now aware of features supported by Intel C++ compilers versions 12.1 through 16.0 on UNIX platforms. Deprecated and Removed Features =============================== * The "CMakeForceCompiler" module and its macros are now deprecated. See module documentation for an explanation. * The "Visual Studio 7 .NET 2003" generator is now deprecated and will be removed in a future version of CMake. * The "Visual Studio 7" generator (for VS .NET 2002) has been removed. It had been deprecated since CMake 3.3. * The "Visual Studio 6" generator has been removed. It had been deprecated since CMake 3.3. CMake 3.6 Release Notes *********************** Changes made since CMake 3.5 include the following. New Features ============ Generators ---------- * The "Ninja" generator learned to produce phony targets of the form "sub/dir/all" to drive the build of a subdirectory. This is equivalent to "cd sub/dir; make all" with Makefile Generators. * The "Ninja" generator now includes system header files in build dependencies to ensure correct re-builds when system packages are updated. * The "Visual Studio 14 2015" generator learned to support the Clang/C2 toolsets, e.g. with the "-T v140_clang_3_7" option. This feature is experimental. Commands -------- * The "add_custom_command()" and "add_custom_target()" commands learned how to use the "CROSSCOMPILING_EMULATOR" executable target property. * The "install()" command learned a new "EXCLUDE_FROM_ALL" option to leave installation rules out of the default installation. * The "list()" command gained a "FILTER" sub-command to filter list elements by regular expression. * The "string(TIMESTAMP)" and "file(TIMESTAMP)" commands gained support for the "%s" placeholder. This is the number of seconds since the UNIX Epoch. Variables --------- * A "CMAKE_DEPENDS_IN_PROJECT_ONLY" variable was introduced to tell Makefile Generators to limit dependency scanning only to files in the project source and build trees. * A new "CMAKE_HOST_SOLARIS" variable was introduced to indicate when CMake is running on an Oracle Solaris host. * A "CMAKE__STANDARD_INCLUDE_DIRECTORIES" variable was added for use by toolchain files to specify system include directories to be appended to all compiler command lines. * The "CMAKE__STANDARD_LIBRARIES" variable is now documented. It is intended for use by toolchain files to specify system libraries to be added to all linker command lines. * A "CMAKE_NINJA_OUTPUT_PATH_PREFIX" variable was introduced to tell the "Ninja" generator to configure the generated "build.ninja" file for use as a "subninja". * A "CMAKE_TRY_COMPILE_PLATFORM_VARIABLES" variable was added for use by toolchain files to specify platform-specific variables that must be propagated by the "try_compile()" command into test projects. * A "CMAKE_TRY_COMPILE_TARGET_TYPE" variable was added to optionally tell the "try_compile()" command to build a static library instead of an executable. This is useful for cross-compiling toolchains that cannot link binaries without custom flags or scripts. Properties ---------- * A "DEPLOYMENT_REMOTE_DIRECTORY" target property was introduced to tell the "Visual Studio 9 2008" and "Visual Studio 8 2005" generators to generate the "remote directory" for WinCE project deployment and debugger settings. * A "_CLANG_TIDY" target property and supporting "CMAKE__CLANG_TIDY" variable were introduced to tell the Makefile Generators and the "Ninja" generator to run "clang-tidy" along with the compiler for "C" and "CXX" languages. * A "TIMEOUT_AFTER_MATCH" test property was introduced to optionally tell CTest to enforce a secondary timeout after matching certain output from a test. * A "VS_CONFIGURATION_TYPE" target property was introduced to specify a custom project file type for Visual Studio Generators supporting VS 2010 and above. * A "VS_STARTUP_PROJECT" directory property was introduced to specify for Visual Studio Generators the default startup project for generated solutions (".sln" files). Modules ------- * The "CMakePushCheckState" module now pushes/pops/resets the variable "CMAKE_EXTRA_INCLUDE_FILE" used in "CheckTypeSize". * The "ExternalProject" module leared the "GIT_SHALLOW 1" option to perform a shallow clone of a Git repository. * The "ExternalProject" module learned to initialize Git submodules recursively and also to initialize new submodules on updates. Use the "GIT_SUBMODULES" option to restrict which submodules are initalized and updated. * The "ExternalProject" module leared the "DOWNLOAD_NO_EXTRACT 1" argument to skip extracting the file that is downloaded (e.g., for self-extracting shell installers or ".msi" files). * The "ExternalProject" module now uses "TLS_VERIFY" when fetching from git repositories. * The "FindBLAS" and "FindLAPACK" modules learned to support OpenBLAS. * The "FindCUDA" module learned to find the "cublas_device" library. * The "FindGTest" module "gtest_add_tests" function now causes CMake to automatically re-run when test sources change so that they can be re-scanned. * The "FindLTTngUST" module was introduced to find the LTTng-UST library. * The "FindPkgConfig" module learned to optionally create imported targets for the libraries it has found. * The "FindProtobuf" module learned to provide a "Protobuf_VERSION" variable and check the version number requested in a "find_package()" call. * The "InstallRequiredSystemLibraries" module learned a new "CMAKE_INSTALL_UCRT_LIBRARIES" option to enable app-local deployment of the Windows Universal CRT libraries with Visual Studio 2015. Platforms --------- * The Clang compiler is now supported on CYGWIN. * Support was added for the Bruce C Compiler with compiler id "Bruce". CTest ----- * The "ctest_update()" command now looks at the "CTEST_GIT_INIT_SUBMODULES" variable to determine whether submodules should be updated or not before updating. * The "ctest_update()" command will now synchronize submodules on an update. Updates which add submodules or change a submodule's URL will now be pulled properly. CPack ----- * The "CPackDeb" module learned how to handle "$ORIGIN" in "CMAKE_INSTALL_RPATH" when "CPACK_DEBIAN_PACKAGE_SHLIBDEPS" is used for dependency auto detection. * The "CPackDeb" module learned how to generate "DEBIAN/shlibs" contorl file when package contains shared libraries. * The "CPackDeb" module learned how to generate "DEBIAN/postinst" and "DEBIAN/postrm" files if the package installs libraries in ldconfig- controlled locations (e.g. "/lib/", "/usr/lib/"). * The "CPackDeb" module learned how to generate dependencies between Debian packages if multi-component setup is used and "CPACK_COMPONENT__DEPENDS" variables are set. For backward compatibility this feature is disabled by default. See "CPACK_DEBIAN_ENABLE_COMPONENT_DEPENDS". * The "CPackDeb" module learned how to set custom package file names including how to generate properly-named Debian packages: _-_.deb For backward compatibility this feature is disabled by default. See "CPACK_DEBIAN_FILE_NAME" and "CPACK_DEBIAN__FILE_NAME". * The "CPackDeb" module learned how to set the package release number ("DebianRevisionNumber" in package file name when used in combination with "DEB-DEFAULT" value set by "CPACK_DEBIAN_FILE_NAME"). See "CPACK_DEBIAN_PACKAGE_RELEASE". * The "CPackDeb" module learned how to set the package architecture per-component. See "CPACK_DEBIAN__PACKAGE_ARCHITECTURE". * The "CPackDMG" module learned a new option to tell the CPack "DragNDrop" generaor to skip the "/Applications" symlink. See the "CPACK_DMG_DISABLE_APPLICATIONS_SYMLINK" variable. * The "CPackIFW" module gained a new "cpack_ifw_update_repository()" command to update a QtIFW-specific repository from a remote repository. * The "CPackRPM" module learned how to set RPM "dist" tag as part of RPM "Release:" tag when enabled (mandatory on some Linux distributions for e.g. on Fedora). See "CPACK_RPM_PACKAGE_RELEASE_DIST". * The "CPackRPM" module learned how to set default values for owning user/group and file/directory permissions of package content. See "CPACK_RPM_DEFAULT_USER", "CPACK_RPM_DEFAULT_GROUP", "CPACK_RPM_DEFAULT_FILE_PERMISSIONS", "CPACK_RPM_DEFAULT_DIR_PERMISSIONS" and their per component counterparts. * The "CPackRPM" module learned how to set user defined package file names, how to specify that rpmbuild should decide on file name format as well as handling of multiple rpm packages generated by a single user defined spec file. See "CPACK_RPM_PACKAGE_NAME" and "CPACK_RPM__PACKAGE_NAME". * The "CPackRPM" module learned how to correctly handle symlinks that are pointing outside generated packages. Other ----- * The "Compile Features" functionality is now aware of features supported by Intel C++ compilers versions 12.1 through 16.0 on UNIX platforms. Deprecated and Removed Features =============================== * The "CMakeForceCompiler" module and its macros are now deprecated. See module documentation for an explanation. * The "find_library()", "find_path()", and "find_file()" commands no longer search in installation prefixes derived from the "PATH" environment variable on non-Windows platforms. This behavior was added in CMake 3.3 to support Windows hosts but has proven problematic on UNIX hosts. Users that keep some "/bin" directories in the "PATH" just for their tools do not necessarily want any supporting "/lib" directories searched. One may set the "CMAKE_PREFIX_PATH" environment variable with a ;-list of prefixes that are to be searched. * The "Visual Studio 7 .NET 2003" generator is now deprecated and will be removed in a future version of CMake. * The "Visual Studio 7" generator (for VS .NET 2002) has been removed. It had been deprecated since CMake 3.3. * The "Visual Studio 6" generator has been removed. It had been deprecated since CMake 3.3. Other Changes ============= * The precompiled OS X binary provided on "cmake.org" now requires OS X 10.7 or newer. * On Linux and FreeBSD platforms, when building CMake itself from source and not using a system-provided libcurl, OpenSSL is now used by default if it is found on the system. This enables SSL/TLS support for commands supporting network communication via "https", such as "file(DOWNLOAD)", "file(UPLOAD)", and "ctest_submit()". * The "cmake(1)" "--build" command-line tool now rejects multiple "-- target" options with an error instead of silently ignoring all but the last one. * "AUTOMOC" now diagnoses name collisions when multiple source files in different directories use "#include " with the same name (because the generated "moc_foo.cpp" files would collide). * The "FindBISON" module "BISON_TARGET" macro now supports special characters by passing the "VERBATIM" option to internal "add_custom_command()" calls. This may break clients that added escaping manually to work around the bug. * The "FindFLEX" module "FLEX_TARGET" macro now supports special characters by passing the "VERBATIM" option to internal "add_custom_command()" calls. This may break clients that added escaping manually to work around the bug. * The "FindProtobuf" module input and output variables were all renamed from "PROTOBUF_" to "Protobuf_" for consistency with other find modules. Input variables of the old case will be honored if provided, and output variables of the old case are always provided. * The "CPackRPM" module now supports upper cased component names in per component CPackRPM specific variables. E.g. component named "foo" now expects component specific variable to be "CPACK_RPM_FOO_PACKAGE_NAME" while before it expected "CPACK_RPM_foo_PACKAGE_NAME". Upper cased component name part in variables is compatible with convention used for other CPack variables. For back compatibility old format of variables is still valid and preferred if both versions of variable are set, but the preferred future use is upper cased component names in variables. New variables that will be added to CPackRPM in later versions will only support upper cased component variable format. ---------------------------------------------------------------------------- Changes made since CMake 3.6.0-rc3: Bartosz Kosiorek (1): Help: Describe VERSION and SOVERSION meanings for Mach-O binaries Ben Boeckel (1): ninja, rc: ignore CMAKE_NINJA_FORCE_RESPONSE_FILE for RC files Brad King (2): Revert "try_compile: Honor CMAKE__FLAGS_ changes" CMake 3.6.0-rc4 Gregor Jasny (1): Help: Cross reference CXX_STANDARD and CXX_EXTENSIONS (#16162) Robert Maynard (5): FindHDF5: correctly add lang to each component target name. FindHDF5: Handle HDF5 builds with non-suffixed components FindHDF5: When component targets not found fallback to compiler wrappers FindHDF5: cache the correct path to the high level libraries FindHDF5: create all the *_LIBRARIES when using hdf5-config.cmake Rolf Eike Beer (1): GetPrerequisites: fix typo in comment From post at hendrik-sattler.de Wed Jun 29 17:05:38 2016 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Wed, 29 Jun 2016 23:05:38 +0200 Subject: [CMake] [ANNOUNCE] CMake 3.6.0-rc4 now ready for testing! In-Reply-To: References: Message-ID: <1548229B-0D2D-4F7D-8AE9-BFE9E993D54A@hendrik-sattler.de> Am 29. Juni 2016 21:30:40 MESZ, schrieb Robert Maynard : >I am proud to announce the fourth CMake 3.6 release candidate. > >Sources and binaries are available at: > https://cmake.org/download/ > >Documentation is available at: > https://cmake.org/cmake/help/v3.6 > >Release notes appear below and are also published at > https://cmake.org/cmake/help/v3.6/release/3.6.html > >Some of the more significant features of CMake 3.6 are: > >* The "Visual Studio 14 2015" generator learned to support the > Clang/C2 toolsets, e.g. with the "-T v140_clang_3_7" option. This > feature is experimental. > >* The "list()" command gained a "FILTER" sub-command to filter list > elements by regular expression. This would also be very handy for generator expressions, similar to JOIN. >* A "CMAKE_TRY_COMPILE_TARGET_TYPE" variable was added to optionally > tell the "try_compile()" command to build a static library instead > of an executable. This is useful for cross-compiling toolchains > that cannot link binaries without custom flags or scripts. > >* A "_CLANG_TIDY" target property and supporting > "CMAKE__CLANG_TIDY" variable were introduced to tell the > Makefile Generators and the "Ninja" generator to run "clang-tidy" > along with the compiler for "C" and "CXX" languages. > >* The "ExternalProject" module leared the "GIT_SHALLOW 1" option to > perform a shallow clone of a Git repository. > >* The "ExternalProject" module learned to initialize Git submodules > recursively and also to initialize new submodules on updates. Use > the "GIT_SUBMODULES" option to restrict which submodules are > initalized and updated. > >* The "InstallRequiredSystemLibraries" module learned a new > "CMAKE_INSTALL_UCRT_LIBRARIES" option to enable app-local deployment > of the Windows Universal CRT libraries with Visual Studio 2015. Maybe the help should note that this is only needed when targeting WindowsXP. >* The "Compile Features" functionality is now aware of features > supported by Intel C++ compilers versions 12.1 through 16.0 on UNIX > platforms. > >Deprecated and Removed Features >=============================== > >* The "CMakeForceCompiler" module and its macros are now deprecated. > See module documentation for an explanation. > >* The "Visual Studio 7 .NET 2003" generator is now deprecated and > will be removed in a future version of CMake. > >* The "Visual Studio 7" generator (for VS .NET 2002) has been > removed. It had been deprecated since CMake 3.3. > >* The "Visual Studio 6" generator has been removed. It had been > deprecated since CMake 3.3. > > > >CMake 3.6 Release Notes >*********************** > >Changes made since CMake 3.5 include the following. > > >New Features >============ > > >Generators >---------- > >* The "Ninja" generator learned to produce phony targets of the form > "sub/dir/all" to drive the build of a subdirectory. This is > equivalent to "cd sub/dir; make all" with Makefile Generators. > >* The "Ninja" generator now includes system header files in build > dependencies to ensure correct re-builds when system packages are > updated. > >* The "Visual Studio 14 2015" generator learned to support the > Clang/C2 toolsets, e.g. with the "-T v140_clang_3_7" option. This > feature is experimental. > > >Commands >-------- > >* The "add_custom_command()" and "add_custom_target()" commands > learned how to use the "CROSSCOMPILING_EMULATOR" executable target > property. > >* The "install()" command learned a new "EXCLUDE_FROM_ALL" option to > leave installation rules out of the default installation. > >* The "list()" command gained a "FILTER" sub-command to filter list > elements by regular expression. > >* The "string(TIMESTAMP)" and "file(TIMESTAMP)" commands gained > support for the "%s" placeholder. This is the number of seconds > since the UNIX Epoch. > > >Variables >--------- > >* A "CMAKE_DEPENDS_IN_PROJECT_ONLY" variable was introduced to tell > Makefile Generators to limit dependency scanning only to files in > the project source and build trees. > >* A new "CMAKE_HOST_SOLARIS" variable was introduced to indicate > when CMake is running on an Oracle Solaris host. > >* A "CMAKE__STANDARD_INCLUDE_DIRECTORIES" variable was added > for use by toolchain files to specify system include directories to > be appended to all compiler command lines. > >* The "CMAKE__STANDARD_LIBRARIES" variable is now documented. > It is intended for use by toolchain files to specify system > libraries to be added to all linker command lines. > >* A "CMAKE_NINJA_OUTPUT_PATH_PREFIX" variable was introduced to tell > the "Ninja" generator to configure the generated "build.ninja" file > for use as a "subninja". > >* A "CMAKE_TRY_COMPILE_PLATFORM_VARIABLES" variable was added for > use by toolchain files to specify platform-specific variables that > must be propagated by the "try_compile()" command into test > projects. Can someone please add an example to the help. The use case for adding this variable is completely left in the dark. E.g. I tried to make the initial try_compile() to respect my CMAKE_CXX_FLAGS_INIT variable that gets defined in my toolchain file... does nothing. So I really have to use CXXFLAGS environment variable which feels clumsy. It's that really the only reliable way to define compiler arguments like -mcpu= for all compiler invocations? >* A "CMAKE_TRY_COMPILE_TARGET_TYPE" variable was added to optionally > tell the "try_compile()" command to build a static library instead > of an executable. This is useful for cross-compiling toolchains > that cannot link binaries without custom flags or scripts. > > >Properties >---------- > >* A "DEPLOYMENT_REMOTE_DIRECTORY" target property was introduced to > tell the "Visual Studio 9 2008" and "Visual Studio 8 2005" > generators to generate the "remote directory" for WinCE project > deployment and debugger settings. > >* A "_CLANG_TIDY" target property and supporting > "CMAKE__CLANG_TIDY" variable were introduced to tell the > Makefile Generators and the "Ninja" generator to run "clang-tidy" > along with the compiler for "C" and "CXX" languages. > >* A "TIMEOUT_AFTER_MATCH" test property was introduced to optionally > tell CTest to enforce a secondary timeout after matching certain > output from a test. > >* A "VS_CONFIGURATION_TYPE" target property was introduced to > specify a custom project file type for Visual Studio Generators > supporting VS 2010 and above. > >* A "VS_STARTUP_PROJECT" directory property was introduced to > specify for Visual Studio Generators the default startup project for > generated solutions (".sln" files). > > >Modules >------- > >* The "CMakePushCheckState" module now pushes/pops/resets the > variable "CMAKE_EXTRA_INCLUDE_FILE" used in "CheckTypeSize". > >* The "ExternalProject" module leared the "GIT_SHALLOW 1" option to > perform a shallow clone of a Git repository. > >* The "ExternalProject" module learned to initialize Git submodules > recursively and also to initialize new submodules on updates. Use > the "GIT_SUBMODULES" option to restrict which submodules are > initalized and updated. > >* The "ExternalProject" module leared the "DOWNLOAD_NO_EXTRACT 1" > argument to skip extracting the file that is downloaded (e.g., for > self-extracting shell installers or ".msi" files). > >* The "ExternalProject" module now uses "TLS_VERIFY" when fetching > from git repositories. > >* The "FindBLAS" and "FindLAPACK" modules learned to support > OpenBLAS. > >* The "FindCUDA" module learned to find the "cublas_device" library. > >* The "FindGTest" module "gtest_add_tests" function now causes CMake > to automatically re-run when test sources change so that they can be > re-scanned. > >* The "FindLTTngUST" module was introduced to find the LTTng-UST > library. > >* The "FindPkgConfig" module learned to optionally create imported > targets for the libraries it has found. > >* The "FindProtobuf" module learned to provide a "Protobuf_VERSION" > variable and check the version number requested in a > "find_package()" call. > >* The "InstallRequiredSystemLibraries" module learned a new > "CMAKE_INSTALL_UCRT_LIBRARIES" option to enable app-local deployment > of the Windows Universal CRT libraries with Visual Studio 2015. > > >Platforms >--------- > >* The Clang compiler is now supported on CYGWIN. > >* Support was added for the Bruce C Compiler with compiler id > "Bruce". > > >CTest >----- > >* The "ctest_update()" command now looks at the > "CTEST_GIT_INIT_SUBMODULES" variable to determine whether submodules > should be updated or not before updating. > >* The "ctest_update()" command will now synchronize submodules on an > update. Updates which add submodules or change a submodule's URL > will now be pulled properly. > > >CPack >----- > >* The "CPackDeb" module learned how to handle "$ORIGIN" in > "CMAKE_INSTALL_RPATH" when "CPACK_DEBIAN_PACKAGE_SHLIBDEPS" is used > for dependency auto detection. > >* The "CPackDeb" module learned how to generate "DEBIAN/shlibs" > contorl file when package contains shared libraries. > >* The "CPackDeb" module learned how to generate "DEBIAN/postinst" > and "DEBIAN/postrm" files if the package installs libraries in > ldconfig- controlled locations (e.g. "/lib/", "/usr/lib/"). > >* The "CPackDeb" module learned how to generate dependencies between > Debian packages if multi-component setup is used and > "CPACK_COMPONENT__DEPENDS" variables are set. For backward > compatibility this feature is disabled by default. See > "CPACK_DEBIAN_ENABLE_COMPONENT_DEPENDS". > >* The "CPackDeb" module learned how to set custom package file names > including how to generate properly-named Debian packages: > >_-_.deb > > For backward compatibility this feature is disabled by default. See > "CPACK_DEBIAN_FILE_NAME" and "CPACK_DEBIAN__FILE_NAME". > >* The "CPackDeb" module learned how to set the package release > number ("DebianRevisionNumber" in package file name when used in > combination with "DEB-DEFAULT" value set by > "CPACK_DEBIAN_FILE_NAME"). See "CPACK_DEBIAN_PACKAGE_RELEASE". > >* The "CPackDeb" module learned how to set the package architecture > per-component. See "CPACK_DEBIAN__PACKAGE_ARCHITECTURE". > >* The "CPackDMG" module learned a new option to tell the CPack > "DragNDrop" generaor to skip the "/Applications" symlink. See the > "CPACK_DMG_DISABLE_APPLICATIONS_SYMLINK" variable. > >* The "CPackIFW" module gained a new "cpack_ifw_update_repository()" > command to update a QtIFW-specific repository from a remote > repository. > >* The "CPackRPM" module learned how to set RPM "dist" tag as part of > RPM "Release:" tag when enabled (mandatory on some Linux > distributions for e.g. on Fedora). See > "CPACK_RPM_PACKAGE_RELEASE_DIST". > >* The "CPackRPM" module learned how to set default values for owning > user/group and file/directory permissions of package content. See > "CPACK_RPM_DEFAULT_USER", "CPACK_RPM_DEFAULT_GROUP", > "CPACK_RPM_DEFAULT_FILE_PERMISSIONS", > "CPACK_RPM_DEFAULT_DIR_PERMISSIONS" and their per component > counterparts. > >* The "CPackRPM" module learned how to set user defined package file > names, how to specify that rpmbuild should decide on file name > format as well as handling of multiple rpm packages generated by a > single user defined spec file. See "CPACK_RPM_PACKAGE_NAME" and > "CPACK_RPM__PACKAGE_NAME". > >* The "CPackRPM" module learned how to correctly handle symlinks > that are pointing outside generated packages. > > >Other >----- > >* The "Compile Features" functionality is now aware of features > supported by Intel C++ compilers versions 12.1 through 16.0 on UNIX > platforms. > > >Deprecated and Removed Features >=============================== > >* The "CMakeForceCompiler" module and its macros are now deprecated. > See module documentation for an explanation. > >* The "find_library()", "find_path()", and "find_file()" commands no > longer search in installation prefixes derived from the "PATH" > environment variable on non-Windows platforms. This behavior was > added in CMake 3.3 to support Windows hosts but has proven > problematic on UNIX hosts. Users that keep some "/bin" > directories in the "PATH" just for their tools do not necessarily > want any supporting "/lib" directories searched. One may > set the "CMAKE_PREFIX_PATH" environment variable with a ;-list of > prefixes that are to be searched. > >* The "Visual Studio 7 .NET 2003" generator is now deprecated and > will be removed in a future version of CMake. > >* The "Visual Studio 7" generator (for VS .NET 2002) has been > removed. It had been deprecated since CMake 3.3. > >* The "Visual Studio 6" generator has been removed. It had been > deprecated since CMake 3.3. > > >Other Changes >============= > >* The precompiled OS X binary provided on "cmake.org" now requires > OS X 10.7 or newer. > >* On Linux and FreeBSD platforms, when building CMake itself from > source and not using a system-provided libcurl, OpenSSL is now used > by default if it is found on the system. This enables SSL/TLS > support for commands supporting network communication via "https", > such as "file(DOWNLOAD)", "file(UPLOAD)", and "ctest_submit()". > >* The "cmake(1)" "--build" command-line tool now rejects multiple > "-- target" options with an error instead of silently ignoring all > but the last one. > >* "AUTOMOC" now diagnoses name collisions when multiple source files > in different directories use "#include " with the same > name (because the generated "moc_foo.cpp" files would collide). > >* The "FindBISON" module "BISON_TARGET" macro now supports special > characters by passing the "VERBATIM" option to internal > "add_custom_command()" calls. This may break clients that added > escaping manually to work around the bug. > >* The "FindFLEX" module "FLEX_TARGET" macro now supports special > characters by passing the "VERBATIM" option to internal > "add_custom_command()" calls. This may break clients that added > escaping manually to work around the bug. > >* The "FindProtobuf" module input and output variables were all > renamed from "PROTOBUF_" to "Protobuf_" for consistency with other > find modules. Input variables of the old case will be honored if > provided, and output variables of the old case are always provided. > >* The "CPackRPM" module now supports upper cased component names in > per component CPackRPM specific variables. E.g. component named > "foo" now expects component specific variable to be > "CPACK_RPM_FOO_PACKAGE_NAME" while before it expected > "CPACK_RPM_foo_PACKAGE_NAME". Upper cased component name part in > variables is compatible with convention used for other CPack > variables. For back compatibility old format of variables is still > valid and preferred if both versions of variable are set, but the > preferred future use is upper cased component names in variables. > New variables that will be added to CPackRPM in later versions will > only support upper cased component variable format. > >---------------------------------------------------------------------------- >Changes made since CMake 3.6.0-rc3: > >Bartosz Kosiorek (1): > Help: Describe VERSION and SOVERSION meanings for Mach-O binaries > >Ben Boeckel (1): > ninja, rc: ignore CMAKE_NINJA_FORCE_RESPONSE_FILE for RC files > >Brad King (2): > Revert "try_compile: Honor CMAKE__FLAGS_ changes" > CMake 3.6.0-rc4 > >Gregor Jasny (1): > Help: Cross reference CXX_STANDARD and CXX_EXTENSIONS (#16162) > >Robert Maynard (5): > FindHDF5: correctly add lang to each component target name. > FindHDF5: Handle HDF5 builds with non-suffixed components >FindHDF5: When component targets not found fallback to compiler >wrappers > FindHDF5: cache the correct path to the high level libraries > FindHDF5: create all the *_LIBRARIES when using hdf5-config.cmake > >Rolf Eike Beer (1): > GetPrerequisites: fix typo in comment -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. From s.baars at rug.nl Thu Jun 30 04:59:54 2016 From: s.baars at rug.nl (Sven Baars) Date: Thu, 30 Jun 2016 10:59:54 +0200 Subject: [CMake] How do you handle recursive dependencies in CMake In-Reply-To: References: Message-ID: <5774DF8A.3070107@rug.nl> This is a reply to the options that Ray gave. Here I will use the package dependencies C -> B -> A{1,2}: 1) The "ad-hoc" method I first mentioned by setting CMAKE_LIBRARY_OUTPUT_DIRECTORY. As far as I understand, this would mean that every user of all of the different projects would have to be forced to use this, and would not be allowed to "install" anything anywhere else, which doesn't seem nice. 2) ExternalProject which will grab a repository and build it. This will not work. One of the projects I use is Trilinos, which has build of around 1GB. I don't want to pull and build that for every project I have. Also the build flags that are used sometimes differ per machine, not per project, so it would be nice if I could build it only once per machine. Also, in a more generalized sense, this would also mean that every project I pull with ExtenalProject should also pull its own dependencies with ExternalProject. So then if every project on my system used CMake, this would mean that I would recursively rebuild my entire system for every project I have. This doesn't seem right. 3) Some Find_Package () mechanism that will do a search for it. The point I had is that we actually try to use this. However, the find_package does not find all dependencies. And we don't know in package C whether it depends on A1 or A2, because of build flags/CMake checks that were used for project B. So we can't just do a find_package for either A1 or A2, because we don't know which one was used unless we perform all the CMake checks that were done in project B (in some cases 10k+ lines of CMake code). 4) Your option of including *.cmake files that provide the paths [sorry, I might have misunderstood it]. This, so far, is the only option, because then B can tell us that it used A2, not A1. This can just be done by providing absolute paths to the libraries that were used in the compilation of B. But we are looking for a standardized way to do this. I'd prefer to not have a lot of custom code in all of my libraries. Now some more information: On supercomputers it is very common that every library on the system is installed in a different directory. This is so every user can load their own version of the library without breaking the system for others. Therefore, you will never find libraries that are installed in the standard system directories where CMake looks for the libraries. By using PATH you can make it able to find the place where to look for the FoobarConfig.cmake files, which is great when you want to build project B, and this is also done automatically on all supercomputers I work on, but those config files do not contain information on where the actual libraries of project A are when you build project C. I guess Cfyz and me think they should in some standardized way. Sven From rwan.work at gmail.com Thu Jun 30 06:10:21 2016 From: rwan.work at gmail.com (Raymond Wan) Date: Thu, 30 Jun 2016 18:10:21 +0800 Subject: [CMake] How do you handle recursive dependencies in CMake In-Reply-To: <5774DF8A.3070107@rug.nl> References: <5774DF8A.3070107@rug.nl> Message-ID: Hi Sven, On Thu, Jun 30, 2016 at 4:59 PM, Sven Baars wrote: > This is a reply to the options that Ray gave. Here I will use the > package dependencies C -> B -> A{1,2}: Well, I presented some options to you. Perhaps there are others, but if none of them are right for you then there's nothing more I can add, I think. > On supercomputers it is very common that every library on the system is > installed in a different directory. This is so every user can load their > own version of the library without breaking the system for others. Sure. So, during the CMake run, you can set CMAKE_INSTALL_PREFIX to be something like ~/lib/ or ~/mylib/ or whatever. > Therefore, you will never find libraries that are installed in the > standard system directories where CMake looks for the libraries. By Well, I wasn't suggesting that you use Find_Package as-is. I mean the phrase "CMake looks for the libraries" isn't quite correct here since its behaviour is affected by the Find_Package's implementation. Presumably, you will need to write your own for the modules you're working with. One person would write it and this file would be shared. How it would work is "something like" (i.e., you need to look at how it works yourself) the Boost library. With that, you can set BOOST_ROOT to override the system-installed version. (Take a look at: https://cmake.org/cmake/help/v3.3/module/FindBoost.html) I think I said this early on, but perhaps I didn't explain it very well. Thus, each user would set an environment variable that would affect the search path of this Find_Package that you wrote. If this is troublesome, then you can add some favourite paths like ~/lib/ and ~/mylib/ as default paths to the search first. I think it is a bit unreasonable for CMake to "automatically" know where libraries are stored for each user other than performing a recursive search down ~/ . (I suppose that's possible.) To reduce the search space for binary programs that we've installed in ~/, we would set the PATH variable. I don't think it's that much different from setting something like BOOST_ROOT and then getting a Find_Package that you've written to use this as the starting point for a search. I mean, it seems strange to expect CMake to be able to find archive files by itself but, by default, we do not expect the same for executable files... Ray From s.baars at rug.nl Thu Jun 30 06:40:49 2016 From: s.baars at rug.nl (Sven Baars) Date: Thu, 30 Jun 2016 12:40:49 +0200 Subject: [CMake] How do you handle recursive dependencies in CMake In-Reply-To: References: <5774DF8A.3070107@rug.nl> Message-ID: <5774F731.3070401@rug.nl> Hi Ray, This still has the same problem. If I use FindBoost in project B, I can use BOOST_ROOT to be able to find it. This works fine. Now, if I try to compile project C, I can set B_ROOT for FindB, but then Boost will not be found, because it is not in B_ROOT, so project C will not compile. That is, unless Boost sets absolute paths for all its libraries. Which is something we have would have to do manually with custom CMake code as per option 4. I don't find it weird that CMake should be able to find Boost in project C, since Boost was already found and used in project B. And we only link to project B explicitly in project C, not to Boost. Actually in C we don't use any Boost functionality other than what is used inside of B. So why should C then explicitly look for Boost, require BOOST_ROOT to do so, then do a lot of checks to see if B actually uses Boost, and in that case link to it, when we don't use Boost in C? So let's take Trilinos as an example, which is quite a big library, which depends on a lot of libraries as well. In every project that builds upon it (but does not even use functionality of any libraries), we would have to set: SCALAPACK_ROOT, LAPACK_ROOT, BLAS_ROOT, BOOST_ROOT, GTEST_ROOT, BLACS_ROOT, UMFPACK_ROOT, MKL_ROOT, etc... and then inside the CMakeFiles.txt do a find_package(Trilinos), find_package(Scalapack), find_package(LAPACK), etc... just to compile int main() {} with one call to a Trilinos function inside of it. I'd say that it should be enough to just do a find_package(Trilinos). Note that by finding a library, I mean that it should know where it is, by for instance using absolute paths at linking time, which I think is sufficient. I don't mean doing all the things that are done in Find*, or going through directories to find the library. Sven On 06/30/2016 12:10 PM, Raymond Wan wrote: > Hi Sven, > > > On Thu, Jun 30, 2016 at 4:59 PM, Sven Baars wrote: >> This is a reply to the options that Ray gave. Here I will use the >> package dependencies C -> B -> A{1,2}: > > Well, I presented some options to you. Perhaps there are others, but > if none of them are right for you then there's nothing more I can add, > I think. > > >> On supercomputers it is very common that every library on the system is >> installed in a different directory. This is so every user can load their >> own version of the library without breaking the system for others. > > Sure. So, during the CMake run, you can set CMAKE_INSTALL_PREFIX to > be something like ~/lib/ or ~/mylib/ or whatever. > > >> Therefore, you will never find libraries that are installed in the >> standard system directories where CMake looks for the libraries. By > > Well, I wasn't suggesting that you use Find_Package as-is. I mean the > phrase "CMake looks for the libraries" isn't quite correct here since > its behaviour is affected by the Find_Package's implementation. > > Presumably, you will need to write your own for the modules you're > working with. One person would write it and this file would be > shared. > > How it would work is "something like" (i.e., you need to look at how > it works yourself) the Boost library. With that, you can set > BOOST_ROOT to override the system-installed version. (Take a look at: > https://cmake.org/cmake/help/v3.3/module/FindBoost.html) > > I think I said this early on, but perhaps I didn't explain it very well. > > Thus, each user would set an environment variable that would affect > the search path of this Find_Package that you wrote. If this is > troublesome, then you can add some favourite paths like ~/lib/ and > ~/mylib/ as default paths to the search first. > > I think it is a bit unreasonable for CMake to "automatically" know > where libraries are stored for each user other than performing a > recursive search down ~/ . (I suppose that's possible.) To reduce > the search space for binary programs that we've installed in ~/, we > would set the PATH variable. I don't think it's that much different > from setting something like BOOST_ROOT and then getting a Find_Package > that you've written to use this as the starting point for a search. > > I mean, it seems strange to expect CMake to be able to find archive > files by itself but, by default, we do not expect the same for > executable files... > > Ray From rwan.work at gmail.com Thu Jun 30 07:05:47 2016 From: rwan.work at gmail.com (Raymond Wan) Date: Thu, 30 Jun 2016 19:05:47 +0800 Subject: [CMake] How do you handle recursive dependencies in CMake In-Reply-To: <5774F731.3070401@rug.nl> References: <5774DF8A.3070107@rug.nl> <5774F731.3070401@rug.nl> Message-ID: Hi Sven, On Thu, Jun 30, 2016 at 6:40 PM, Sven Baars wrote: > So let's take Trilinos as an example, which is quite a big library, > which depends on a lot of libraries as well. In every project that > builds upon it (but does not even use functionality of any libraries), > we would have to set: SCALAPACK_ROOT, LAPACK_ROOT, BLAS_ROOT, > BOOST_ROOT, GTEST_ROOT, BLACS_ROOT, UMFPACK_ROOT, MKL_ROOT, etc... and > then inside the CMakeFiles.txt do a find_package(Trilinos), > find_package(Scalapack), find_package(LAPACK), etc... just to compile > int main() {} with one call to a Trilinos function inside of it. I'd say > that it should be enough to just do a find_package(Trilinos). Perhaps I'm alone here, but I actually don't see this as being a "big" problem. For the environment variables, you can place them all in a bash script and source it during log in. For all of the Find_Package calls, they only matter whenever you have to re-run cmake. I don't know what Trilinos is, but for something that big, I presume it takes more time to compile it (during active development) than to run cmake to look through all those paths... Ray From s.baars at rug.nl Thu Jun 30 07:42:53 2016 From: s.baars at rug.nl (Sven Baars) Date: Thu, 30 Jun 2016 13:42:53 +0200 Subject: [CMake] How do you handle recursive dependencies in CMake In-Reply-To: References: <5774DF8A.3070107@rug.nl> <5774F731.3070401@rug.nl> Message-ID: <577505BD.9090804@rug.nl> Hey Ray, For myself it is not a big problem either, but I don't want to tell users of my libraries that they have to look up how the administrators at their supercomputing facility compiled 20 other libraries so they can set their environment variables in the right way, while at the same time making my own CMakeLists.txt files much longer (because I would need many more find_package calls for dependencies of dependencies that I don't use). Whereas if CMake would just provide some means of using absolute paths instead of targets for libraries, or attach the information about those paths to the targets or something like that, this would never be a problem, since in that case everything would be found automatically. Also, it still doesn't make sense to me that instead of one find_package call for a package I actually use, I also need 20 find_package calls for dependencies of that other package. Also it doesn't make sense that I would actually need these find_package calls, whereas if the packages were just installed in /usr/lib or something it would work without any knowledge of this package even being used. Something that causes problems is the case where you use either A1 or A2. Then in B you would do something like option(B_USE_A2 OFF "Use package A2 instead of A1") if (NOT B_USE_A2) find_package(A1) if (A1_FOUND) ... target_link_libraries(B ${A1_LIBRARIES}) ... else() set(B_USE_A2 ON) endif() if (B_USE_A2) find_package(A2) if (A2_FOUND) ... target_link_libraries(B ${A2_LIBRARIES}) ... endif() endif() which makes sense, but then also in C instead of doing find_package(B) if (B_FOUND) target_link_libraries(C ${B_LIBRARIES}) endif() you would also have to do if (B_FOUND) option(C_USE_A2 OFF "Use package A2 instead of A1, which is used in package B. Make sure C_USE_A2 is equal to what you used in package B as B_USE_A2") if (NOT C_USE_A2) find_package(A1) if (A1_FOUND) ... target_link_libraries(C ${A1_LIBRARIES}) ... else() set(C_USE_A2 ON) endif() if (C_USE_A2) find_package(A2) if (A2_FOUND) ... target_link_libraries(C ${A2_LIBRARIES}) ... endif() endif() target_link_libraries(C ${B_LIBRARIES}) endif() or something like that, which is quite silly. Especially the part where compilation fails if B_USE_A2 is unequal to C_USE_A2. In general, my CMakeLists.txt is a lot more complicated, so I'd prefer the option where I only look for B. Sven On 06/30/2016 01:05 PM, Raymond Wan wrote: > Hi Sven, > > > On Thu, Jun 30, 2016 at 6:40 PM, Sven Baars wrote: >> So let's take Trilinos as an example, which is quite a big library, >> which depends on a lot of libraries as well. In every project that >> builds upon it (but does not even use functionality of any libraries), >> we would have to set: SCALAPACK_ROOT, LAPACK_ROOT, BLAS_ROOT, >> BOOST_ROOT, GTEST_ROOT, BLACS_ROOT, UMFPACK_ROOT, MKL_ROOT, etc... and >> then inside the CMakeFiles.txt do a find_package(Trilinos), >> find_package(Scalapack), find_package(LAPACK), etc... just to compile >> int main() {} with one call to a Trilinos function inside of it. I'd say >> that it should be enough to just do a find_package(Trilinos). > > Perhaps I'm alone here, but I actually don't see this as being a "big" problem. > > For the environment variables, you can place them all in a bash script > and source it during log in. > > For all of the Find_Package calls, they only matter whenever you have > to re-run cmake. I don't know what Trilinos is, but for something > that big, I presume it takes more time to compile it (during active > development) than to run cmake to look through all those paths... > > Ray From tzsariysk at gmail.com Thu Jun 30 08:37:07 2016 From: tzsariysk at gmail.com (TS) Date: Thu, 30 Jun 2016 08:37:07 -0400 Subject: [CMake] ctest: how to include pre- and post- processing commands Message-ID: <00ea01d1d2cc$1d68bde0$583a39a0$@gmail.com> Hi, Apologize if I sent this twice. Is it possible to have a ctest which involves preprocessing as well as postprocessing. The code to test is myCode.exe, which writes an output file. PASS or FAIL is the result of comparison of output against reference data. Currently I use two add_tests: ADD_TEST(NAME test COMMAND mpiexec --np 8 myCode.exe input output) ADD_TEST(NAME comp COMMAND compare.exe output refdata 1.e-6) It works, but reports two tests, 'test' and 'comp', while in essence these are two steps of a single test. Is there a better way to achieve this? I would like to add a preprocessing step, which removes output (if any) from previous tests. I tried ADD_TEST(NAME rm COMMAND /bin/rm output) but because rm is not build by cmake, it complains that cannot find it. Any help is highly appreciated, Thanks, Ted -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicholas11braden at gmail.com Thu Jun 30 08:41:36 2016 From: nicholas11braden at gmail.com (Nicholas Braden) Date: Thu, 30 Jun 2016 07:41:36 -0500 Subject: [CMake] How do you handle recursive dependencies in CMake In-Reply-To: <5774DF8A.3070107@rug.nl> References: <5774DF8A.3070107@rug.nl> Message-ID: If find_project is not enough, and ExternalProject's only problem is build duplication, then I think it makes sense to consider a CMake-based dependency manager such as hunter: https://github.com/ruslo/hunter On Thu, Jun 30, 2016 at 3:59 AM, Sven Baars wrote: > This is a reply to the options that Ray gave. Here I will use the > package dependencies C -> B -> A{1,2}: > > 1) The "ad-hoc" method I first mentioned by setting > CMAKE_LIBRARY_OUTPUT_DIRECTORY. > > As far as I understand, this would mean that every user of all of the > different projects would have to be forced to use this, and would not be > allowed to "install" anything anywhere else, which doesn't seem nice. > > 2) ExternalProject which will grab a repository and build it. > > This will not work. One of the projects I use is Trilinos, which has > build of around 1GB. I don't want to pull and build that for every > project I have. Also the build flags that are used sometimes differ per > machine, not per project, so it would be nice if I could build it only > once per machine. > > Also, in a more generalized sense, this would also mean that every > project I pull with ExtenalProject should also pull its own dependencies > with ExternalProject. So then if every project on my system used CMake, > this would mean that I would recursively rebuild my entire system for > every project I have. This doesn't seem right. > > 3) Some Find_Package () mechanism that will do a search for it. > > The point I had is that we actually try to use this. However, the > find_package does not find all dependencies. And we don't know in > package C whether it depends on A1 or A2, because of build flags/CMake > checks that were used for project B. So we can't just do a find_package > for either A1 or A2, because we don't know which one was used unless we > perform all the CMake checks that were done in project B (in some cases > 10k+ lines of CMake code). > > 4) Your option of including *.cmake files that provide the paths > [sorry, I might have misunderstood it]. > > This, so far, is the only option, because then B can tell us that it > used A2, not A1. This can just be done by providing absolute paths to > the libraries that were used in the compilation of B. But we are looking > for a standardized way to do this. I'd prefer to not have a lot of > custom code in all of my libraries. > > Now some more information: > > On supercomputers it is very common that every library on the system is > installed in a different directory. This is so every user can load their > own version of the library without breaking the system for others. > Therefore, you will never find libraries that are installed in the > standard system directories where CMake looks for the libraries. By > using PATH you can make it able to find the place where to look for the > FoobarConfig.cmake files, which is great when you want to build project > B, and this is also done automatically on all supercomputers I work on, > but those config files do not contain information on where the actual > libraries of project A are when you build project C. I guess Cfyz and me > think they should in some standardized way. > > Sven > -- > > 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 s.baars at rug.nl Thu Jun 30 09:01:08 2016 From: s.baars at rug.nl (Sven Baars) Date: Thu, 30 Jun 2016 15:01:08 +0200 Subject: [CMake] How do you handle recursive dependencies in CMake In-Reply-To: References: <5774DF8A.3070107@rug.nl> Message-ID: <57751814.2080501@rug.nl> I don't think this is a solution to the problem, since then it seems like the build will still fail for all our users unless they also build all their packages from inside hunter. If I wanted it to work just for myself I could just use hardcoded paths. The problem is that I want a portable way such that users can build my projects without losing dependency information. In the current situation they are forced to copy-paste all of my CMakeLists.txt files and add their own stuff to that. At least if I follow the guides on the wiki/the advice that I got so far. That is, unless I misunderstand something, which I hope I do, but no one pointed that out yet. Sven On 06/30/2016 02:41 PM, Nicholas Braden wrote: > If find_project is not enough, and ExternalProject's only problem is > build duplication, then I think it makes sense to consider a > CMake-based dependency manager such as hunter: > https://github.com/ruslo/hunter > > > On Thu, Jun 30, 2016 at 3:59 AM, Sven Baars wrote: >> This is a reply to the options that Ray gave. Here I will use the >> package dependencies C -> B -> A{1,2}: >> >> 1) The "ad-hoc" method I first mentioned by setting >> CMAKE_LIBRARY_OUTPUT_DIRECTORY. >> >> As far as I understand, this would mean that every user of all of the >> different projects would have to be forced to use this, and would not be >> allowed to "install" anything anywhere else, which doesn't seem nice. >> >> 2) ExternalProject which will grab a repository and build it. >> >> This will not work. One of the projects I use is Trilinos, which has >> build of around 1GB. I don't want to pull and build that for every >> project I have. Also the build flags that are used sometimes differ per >> machine, not per project, so it would be nice if I could build it only >> once per machine. >> >> Also, in a more generalized sense, this would also mean that every >> project I pull with ExtenalProject should also pull its own dependencies >> with ExternalProject. So then if every project on my system used CMake, >> this would mean that I would recursively rebuild my entire system for >> every project I have. This doesn't seem right. >> >> 3) Some Find_Package () mechanism that will do a search for it. >> >> The point I had is that we actually try to use this. However, the >> find_package does not find all dependencies. And we don't know in >> package C whether it depends on A1 or A2, because of build flags/CMake >> checks that were used for project B. So we can't just do a find_package >> for either A1 or A2, because we don't know which one was used unless we >> perform all the CMake checks that were done in project B (in some cases >> 10k+ lines of CMake code). >> >> 4) Your option of including *.cmake files that provide the paths >> [sorry, I might have misunderstood it]. >> >> This, so far, is the only option, because then B can tell us that it >> used A2, not A1. This can just be done by providing absolute paths to >> the libraries that were used in the compilation of B. But we are looking >> for a standardized way to do this. I'd prefer to not have a lot of >> custom code in all of my libraries. >> >> Now some more information: >> >> On supercomputers it is very common that every library on the system is >> installed in a different directory. This is so every user can load their >> own version of the library without breaking the system for others. >> Therefore, you will never find libraries that are installed in the >> standard system directories where CMake looks for the libraries. By >> using PATH you can make it able to find the place where to look for the >> FoobarConfig.cmake files, which is great when you want to build project >> B, and this is also done automatically on all supercomputers I work on, >> but those config files do not contain information on where the actual >> libraries of project A are when you build project C. I guess Cfyz and me >> think they should in some standardized way. >> >> Sven >> -- >> >> 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 loose at astron.nl Thu Jun 30 09:06:53 2016 From: loose at astron.nl (Marcel Loose) Date: Thu, 30 Jun 2016 15:06:53 +0200 Subject: [CMake] How do you handle recursive dependencies in CMake In-Reply-To: <577505BD.9090804@rug.nl> References: <5774DF8A.3070107@rug.nl> <5774F731.3070401@rug.nl> <577505BD.9090804@rug.nl> Message-ID: Hi Sven, Sorry to chime in so late. I was wondering, since you're mentioning large computer clusters, don't you use the "module" system to select which versions of which packages you want to use? If so, then (I assume) your PATH and LD_LIBRARY_PATH environment variables will have been set such that the correct binaries and libraries can be found, right? CMake also searches for libraries in the paths specified in the environment variables PATH and LIB (unfortunately not LD_LIBRARY_PATH). Isn't that the way to tackle this problem? Cheers, Marcel Loose. On 30/06/16 13:42, Sven Baars wrote: > Hey Ray, > > For myself it is not a big problem either, but I don't want to tell > users of my libraries that they have to look up how the administrators > at their supercomputing facility compiled 20 other libraries so they can > set their environment variables in the right way, while at the same > time making my own CMakeLists.txt files much longer (because I would > need many more find_package calls for dependencies of dependencies that > I don't use). Whereas if CMake would just provide some means of using > absolute paths instead of targets for libraries, or attach the > information about those paths to the targets or something like that, > this would never be a problem, since in that case everything would be > found automatically. > > Also, it still doesn't make sense to me that instead of one find_package > call for a package I actually use, I also need 20 find_package calls for > dependencies of that other package. Also it doesn't make sense that I > would actually need these find_package calls, whereas if the packages > were just installed in /usr/lib or something it would work without any > knowledge of this package even being used. > > Something that causes problems is the case where you use either A1 or > A2. Then in B you would do something like > > option(B_USE_A2 OFF "Use package A2 instead of A1") > > if (NOT B_USE_A2) > find_package(A1) > if (A1_FOUND) > ... > target_link_libraries(B ${A1_LIBRARIES}) > ... > else() > set(B_USE_A2 ON) > endif() > > if (B_USE_A2) > find_package(A2) > if (A2_FOUND) > ... > target_link_libraries(B ${A2_LIBRARIES}) > ... > endif() > endif() > > which makes sense, but then also in C instead of doing > > find_package(B) > if (B_FOUND) > target_link_libraries(C ${B_LIBRARIES}) > endif() > > you would also have to do > > if (B_FOUND) > option(C_USE_A2 OFF "Use package A2 instead of A1, which is used in > package B. Make sure C_USE_A2 is equal to what you used in package B as > B_USE_A2") > > if (NOT C_USE_A2) > find_package(A1) > if (A1_FOUND) > ... > target_link_libraries(C ${A1_LIBRARIES}) > ... > else() > set(C_USE_A2 ON) > endif() > > if (C_USE_A2) > find_package(A2) > if (A2_FOUND) > ... > target_link_libraries(C ${A2_LIBRARIES}) > ... > endif() > endif() > target_link_libraries(C ${B_LIBRARIES}) > endif() > > or something like that, which is quite silly. Especially the part where > compilation fails if B_USE_A2 is unequal to C_USE_A2. In general, my > CMakeLists.txt is a lot more complicated, so I'd prefer the option where > I only look for B. > > Sven > > On 06/30/2016 01:05 PM, Raymond Wan wrote: >> Hi Sven, >> >> >> On Thu, Jun 30, 2016 at 6:40 PM, Sven Baars wrote: >>> So let's take Trilinos as an example, which is quite a big library, >>> which depends on a lot of libraries as well. In every project that >>> builds upon it (but does not even use functionality of any libraries), >>> we would have to set: SCALAPACK_ROOT, LAPACK_ROOT, BLAS_ROOT, >>> BOOST_ROOT, GTEST_ROOT, BLACS_ROOT, UMFPACK_ROOT, MKL_ROOT, etc... and >>> then inside the CMakeFiles.txt do a find_package(Trilinos), >>> find_package(Scalapack), find_package(LAPACK), etc... just to compile >>> int main() {} with one call to a Trilinos function inside of it. I'd say >>> that it should be enough to just do a find_package(Trilinos). >> Perhaps I'm alone here, but I actually don't see this as being a "big" problem. >> >> For the environment variables, you can place them all in a bash script >> and source it during log in. >> >> For all of the Find_Package calls, they only matter whenever you have >> to re-run cmake. I don't know what Trilinos is, but for something >> that big, I presume it takes more time to compile it (during active >> development) than to run cmake to look through all those paths... >> >> Ray -------------- next part -------------- A non-text attachment was scrubbed... Name: loose.vcf Type: text/x-vcard Size: 292 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: OpenPGP digital signature URL: From s.baars at rug.nl Thu Jun 30 09:19:09 2016 From: s.baars at rug.nl (Sven Baars) Date: Thu, 30 Jun 2016 15:19:09 +0200 Subject: [CMake] How do you handle recursive dependencies in CMake In-Reply-To: References: Message-ID: <57751C4D.2050906@rug.nl> Hey Marcel, They are indeed always set correctly, and for this reason, find_package is also always able to find these packages, which is great, and this is why I love using CMake, but then it still happens that when you don't explicitly use find_package, so in this case I don't use find_package(A) in package C because C only depends on B, it will give an error, as can be seen in my example on Github: https://github.com/Sbte/cmake-example The error is: Linking CXX shared library libC.so /usr/bin/ld: cannot find -lA It might be that I am just doing something wrong here, so in that case please let me know. Cheers, Sven From brad.king at kitware.com Thu Jun 30 09:20:15 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 30 Jun 2016 09:20:15 -0400 Subject: [CMake] CMake 3.6.0-rc4 now ready for testing! In-Reply-To: <1548229B-0D2D-4F7D-8AE9-BFE9E993D54A@hendrik-sattler.de> References: <1548229B-0D2D-4F7D-8AE9-BFE9E993D54A@hendrik-sattler.de> Message-ID: <57751C8F.6030602@kitware.com> On 06/29/2016 05:05 PM, Hendrik Sattler wrote: >> * The "InstallRequiredSystemLibraries" module learned a new >> "CMAKE_INSTALL_UCRT_LIBRARIES" option to enable app-local deployment >> of the Windows Universal CRT libraries with Visual Studio 2015. > > Maybe the help should note that this is only needed when targeting > WindowsXP. It is also useful for deploying to Windows 7 machines that have not had updates installed to provide the UCRT libraries. I've updated the documentation to show Windows XP as an example: InstallRequiredSystemLibraries: Document UCRT option use case https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=dab3ccf2 >> * A "CMAKE_TRY_COMPILE_PLATFORM_VARIABLES" variable was added for >> use by toolchain files to specify platform-specific variables that >> must be propagated by the "try_compile()" command into test >> projects. > > Can someone please add an example to the help. Done: Help: Document CMAKE_TRY_COMPILE_PLATFORM_VARIABLES example https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c05d240e > E.g. I tried to make the initial try_compile() to respect my > CMAKE_CXX_FLAGS_INIT variable that gets defined in my toolchain file... CMAKE_CXX_FLAGS_INIT is not documented for use in a toolchain file. It is used internally by platform modules. > I really have to use CXXFLAGS environment variable which feels clumsy. > It's that really the only reliable way to define compiler arguments > like -mcpu= for all compiler invocations? It is one way. Another way is to set the cache entry directly: set(CMAKE_CXX_FLAGS "-mcpu=..." CACHE STRING "C++ flags") Note that CMAKE_CXX_FLAGS is propagated by try_compile automatically. The above two approaches are actually just trying to get a toolchain file to have a say in the initial CMAKE_CXX_FLAGS cache entry value of the main project. -Brad From s.baars at rug.nl Thu Jun 30 09:33:34 2016 From: s.baars at rug.nl (Sven Baars) Date: Thu, 30 Jun 2016 15:33:34 +0200 Subject: [CMake] How do you handle recursive dependencies in CMake In-Reply-To: References: Message-ID: <57751FAE.2020205@rug.nl> Hey again Marcel, Your reply got me thinking. I just checked again, and found that I just have to set the LIBRARY_PATH correctly as well. After that everything seems to work. Apparently this was not done in the right way. Since I have to use PATH anyway to find the FoobarConfig.cmake files, it is just as easy to also set LIBRARY_PATH to find the dependencies of the already compiled libraries. The problem was that PATH was already set in the right way, so I didn't notice that LIBRARY_PATH was not set correctly. Anyhow, the thing that ultimately confused me in such a way that I thought the problem was somewhere else was that https://cmake.org/cmake/help/v3.0/command/link_directories.html says that find_package should return *absolute* paths, which it does not, since it just returns the targets. Maybe that can be cleared up a bit to prevent further confusion. Thanks a lot for pointing me in the right direction! Cheers, Sven From imbacen at gmail.com Thu Jun 30 11:56:59 2016 From: imbacen at gmail.com (cen) Date: Thu, 30 Jun 2016 17:56:59 +0200 Subject: [CMake] CPack source package install location Message-ID: <9c149daf-35b8-f984-5a9a-e4e5790f6b7c@gmail.com> Hi I have a very standard CPack configuration for deb package. I have two questions: 1. I generate the deb with: cpack --config CPackConfig.cmake -G "DEB" This is supposedly a binary package but when I install it on the machine I see header files being installed in /usr/include. Is this normal? 2. Header files are installed into /usr/include but there is one problem: other projects using the library are including header files with #include as a standard practice. So I actually want them installed in /usr/include/libname instead. After scouring the CPack variables in documentation I didn't really find anything suitable to do this. Is it possible to achieve?|| || -------------- next part -------------- An HTML attachment was scrubbed... URL: From irwin at beluga.phys.uvic.ca Thu Jun 30 14:36:17 2016 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Thu, 30 Jun 2016 11:36:17 -0700 (PDT) Subject: [CMake] How do you handle recursive dependencies in CMake In-Reply-To: <5774DF8A.3070107@rug.nl> References: <5774DF8A.3070107@rug.nl> Message-ID: On 2016-06-30 10:59+0200 Sven Baars wrote: > 2) ExternalProject which will grab a repository and build it. > > This will not work. One of the projects I use is Trilinos, which has > build of around 1GB. I don't want to pull and build that for every > project I have. Also the build flags that are used sometimes differ per > machine, not per project, so it would be nice if I could build it only > once per machine. > > Also, in a more generalized sense, this would also mean that every > project I pull with ExtenalProject should also pull its own dependencies > with ExternalProject. So then if every project on my system used CMake, > this would mean that I would recursively rebuild my entire system for > every project I have. This doesn't seem right. Hi Sven: I am chiming in late on this thread because I became aware of it only recently. My advice is to look again at ExternalProject because there are some misconceptions above. For example, in my epa_build superproject I use ExternalProject to build a whole set of different projects (some with CMake-based build systems some with autotools-based build system) that interdepend on each other in a large tree of dependencies and which also have external dependencies that must be installed on the machine that are not controlled by my epa_build superproject. ExternalProject allows you to set up dependencies between those epa_built projects so they are built and installed only once and only if needed directly or transitively by the particular epa_built "starter" project the user specifies. I have implemented a useful CMake function so that each project that I make part of epa_build typically only needs to know what other epa_built projects it depends on and the location of the source code to be downloaded for the project. So the epa_build CMakeList.txt files that are required to describe each project tend to be quite short. For epa_build I do simplify my life by using two common install locations (one for the build tools that are epa_built, one for the libraries that are epa_built) for every project that I build and install with epa_build. So that vastly simplifies the find issues for the dependencies which are epa_built projects themselves. The external dependencies (not under epa_build control) for each project are a different story, but in my case those are largely system dependencies found in the expected location. So the result is I have virtually no find issues at all with epa_build. To learn more about epa_build see or the latest release of PLplot. (I originally set up epa_build so that I could straightforwardly build the latest versions of PLplot dependencies to test PLplot against those rather than being limited to testing PLplot against dated system versions of its dependencies. But I now use it for any software that I like to build for myself.) Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From robert.maynard at kitware.com Thu Jun 30 16:23:05 2016 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 30 Jun 2016 16:23:05 -0400 Subject: [CMake] CMAKE_C_COMPILE_OBJECT vs In-Reply-To: <14455837-B56D-48FE-AB20-82EEB82C4C69@eleveneng.com> References: <14455837-B56D-48FE-AB20-82EEB82C4C69@eleveneng.com> Message-ID: Hi, Can you explain what the goal of your compilation wrappers are? Are you trying to add a new compiler? On Wed, Jun 29, 2016 at 1:41 PM, Sam Cristall wrote: > Looks like this was just a change in CMake 3.4. Updated to latest, and everything is working. >> On Jun 28, 2016, at 5:19 PM, Sam Cristall wrote: >> >> I'm trying to implement a cross compilation wrapper and hit a snag with CMAKE_C_COMPILE_OBJECT. I've found that on OSX / Linux (Makefile Generator), and work as expected, however on Windows (MinGW Makefile Generator), has both the flags and includes, whereas is undefined. Is this expected? >> > -- > > 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 cristall at eleveneng.com Thu Jun 30 16:41:22 2016 From: cristall at eleveneng.com (Sam Cristall) Date: Thu, 30 Jun 2016 14:41:22 -0600 Subject: [CMake] CMAKE_C_COMPILE_OBJECT vs In-Reply-To: References: <14455837-B56D-48FE-AB20-82EEB82C4C69@eleveneng.com> Message-ID: <976A9B9D-21FD-48BE-9FEA-123FFD626D22@eleveneng.com> Hi Robert, Yes, we are adding the Keil C8051 compiler, which is very old and uses a very unique command line syntax compared to the others supported by CMake. Also, it's Windows only but Wine works -- so we optionally add Wine on non-Windows platforms. An example would be: wine C51.exe INCDIR(/path/to/dir/1/, /path/to/dir/2/) DEBUG DEFINE(FOO_FLAG) OBJECT(/path/to/output.obj) /path/to/source.c To achieve this, we use a wrapper cmake script with the following: set(CMAKE_C_COMPILE_OBJECT "cmake\ -DWINE=${WINE}\ -DCOMPILER=\ -DSOURCE=\ -DINCLUDES=\"\"\ -DFLAGS=\" \"\ -DOBJECT=\ -P \"${CMAKE_CURRENT_LIST_DIR}/C8051Compile.cmake\"" ) It was important that be separate, as its form is significantly different than most compilers. Prior to cmake 3.4, it would be very difficult to handle this, since would append the includes as a list of directories, and there is no CMAKE_INCLUDE_FLAG suffix variable (need a closing bracket for INCDIR). > On Jun 30, 2016, at 2:23 PM, Robert Maynard wrote: > > Hi, > > Can you explain what the goal of your compilation wrappers are? Are > you trying to add a new compiler? > > > > On Wed, Jun 29, 2016 at 1:41 PM, Sam Cristall wrote: >> Looks like this was just a change in CMake 3.4. Updated to latest, and everything is working. >>> On Jun 28, 2016, at 5:19 PM, Sam Cristall wrote: >>> >>> I'm trying to implement a cross compilation wrapper and hit a snag with CMAKE_C_COMPILE_OBJECT. I've found that on OSX / Linux (Makefile Generator), and work as expected, however on Windows (MinGW Makefile Generator), has both the flags and includes, whereas is undefined. Is this expected? >>> >> -- >> >> 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