From daniel.wirtz at simtech.uni-stuttgart.de Mon Jun 1 05:03:53 2015 From: daniel.wirtz at simtech.uni-stuttgart.de (Daniel Wirtz) Date: Mon, 01 Jun 2015 11:03:53 +0200 Subject: [CMake] Conditional transitive link libraries Message-ID: <556C1FF9.6040609@simtech.uni-stuttgart.de> Hello all, I'm struggling with the CMake "Config"-based package description when using two depending packages where the upstream package has optional link libraries. Suppose you have libA that optionally uses zip functionality (say by some option USE_ZLIB in libA's CMakeLists.txt). This means libA will optionally have -lz in its INTERFACE_LINK_LIBRARIES (exported into liba-config.cmake). Now, if you have a libB using libA via find_package(libA), how do you know if libA has been built with or without zlib support when both libraries are installed and exported with CMake's package config system? I know that the link library information is treated transitively and will be propagated to the link libraries of libB, hence -lz will appear whenever linking against libB. However, the PATH to libz is nowhere included; consequently, the link fails with "could not find library z" unless you magically knew that libz is a dependent link library of libA and where to include it from. Including the absolute path to libz in libA's config is also not the way to go, as it ruins the portability over different systems. Is there a "native" CMake way? Thanks! -- Dr. Daniel Wirtz Dipl. Math. Dipl. Inf. SRC SimTech Pfaffenwaldring 5a +49 711 685 60044 From cedric.doucet at inria.fr Mon Jun 1 06:38:12 2015 From: cedric.doucet at inria.fr (Cedric Doucet) Date: Mon, 1 Jun 2015 12:38:12 +0200 (CEST) Subject: [CMake] Can't cd to DOWNLOAD_DIR In-Reply-To: <1161011688.9494700.1433154742066.JavaMail.zimbra@inria.fr> Message-ID: <704529771.9496164.1433155092455.JavaMail.zimbra@inria.fr> Hello, in the ExternalProject_add function, I would like to access to DOWNLOAD_DIR to download a patch (for ARPACK). So, I define my patch command like this: ================================================== PATCH_COMMAND cd && wget /myurl/mypatch.tar.gz && cd && tar xvzf /mypatch.tar.gz ================================================== However, I get the following error: [ 5%] Performing patch step for 'arpack' /bin/sh: 1: cd: can't cd to make[2]: *** [third-party/arpack/stamp/arpack-patch] Erreur 2 make[1]: *** [CMakeFiles/arpack.dir/all] Erreur 2 make: *** [all] Erreur 2 Do you see where I make a mistake? Thank you! C?dric -------------- next part -------------- An HTML attachment was scrubbed... URL: From t.err.a at yandex.ru Mon Jun 1 08:03:57 2015 From: t.err.a at yandex.ru (c roman) Date: Mon, 01 Jun 2015 15:03:57 +0300 Subject: [CMake] CMake 3.2.2 generates too many virtual folders for Codeblocks project Message-ID: <63811433160237@web4j.yandex.ru> Hi, i have a project in the path D:\folder1\folder2\prj1, all sources and CMakeLists.txt are in this folder 'prj1'. CMake generates for the Codeblocks project file in which the source files are located in a virtual folders with the path not corresponding to the root folder of the project 'prj1'. For Codelite CMake generates normal path corresponding to the root folder of the project. So generated project tree in Codeblocks: ___CMakeFiles | |__[..] | | |__[..] | | |__[programms] | | |__[cmake] | | |__[share] | | |__cmake-3.2 | | |__[Modules] | | |__[Compiler] | | | |__GNU-C.cmake | | | |__GNU-CXX.cmake | | | |__GNU.cmake | | | |__GNU.cmake | | | | | |__[Platform] | | | |__Windows-GNU-C-ABI.cmake | | | |__ ..... cmake files | | | | | |__ ..... cmake files | |__CMakeList.txt | |__[Sources] | |__[folder1] | |__[folder2] | |__[prj1] | |__ .... '.cpp' files | |__[Headers] | |__[folder1] | |__[folder2] | |__[prj1] | |__ .... '.h' files | |__[Resources] |__[folder1] |__[folder2] |__[prj1] |__ resource.rc Generated project tree in Codelite: |__[include] | |_ .... '.h' files |__[src] |__ .... '.cpp' files Why such a difference? Is it possible to get CMake does not create extra virtual folders for Codeblocks project? CMakeLists.txt: # ????????? ???? ??? ????????? my_program # ??????????? ?????? CMake, ?????? ??????. cmake_minimum_required( VERSION 2.8.4 ) # ????????????? ???????? ?????????? BIN set( BIN hisview_dev ) # ??? ??????? ? ??? ????????????? ????? ?????????. project( ${BIN} ) # ????????? ???? ????? ?????????? set ( CMAKE_CXX_FLAGS "-m32 -std=gnu++11" ) set(CMAKE_INSTALL_PREFIX $ENV{mybin}) message (STATUS "CMAKE_INSTALL_PREFIX:" ${CMAKE_INSTALL_PREFIX}) # ????????? ???? ???????????? ????????? ?????????? set (EXECUTABLE_OUTPUT_PATH $ENV{mybin}) # ???? ?? ?????????? ??? ???? ??? ??? #set(CMAKE_RUNTIME_OUTPUT_DIRECTORY $ENV{PROJECTS_OUTPUT}) # ????????????? ???????? ???? ? ????? ? ??????????? ?????????. set( SOURCE_ROOT ${PROJECT_SOURCE_DIR} ) message (STATUS "PROJECT_SOURCE_DIR:" ${PROJECT_SOURCE_DIR}) set(DEBEA_ROOT $ENV{DEBEA}) file(TO_CMAKE_PATH ${DEBEA_ROOT} DEBEA_ROOT) message (STATUS "DEBEA_ROOT" ${DEBEA_ROOT}) #STRING(REGEX REPLACE '\\' '/' TEST_VAR ${DEBEA_ROOT} ) set(DEBEA_INCLUDE ${DEBEA_ROOT}/dba) message (STATUS "DEBEA_INCLUDE:" ${DEBEA_INCLUDE}) set(DEBEA_LIB ${DEBEA_ROOT}/lib/gcc_static_mingw-w64-32) # ?? ????????? ????? ?????? ? ??????????? ????? ??????????? ????. # ??????? aux_source_directory (??????????) ????????????? ????????? #(??????? ?? ????????? ????, ?????????? ????) ? ???????? ????? ???? # ??????, ??????? ???????????? ??????????, ????? ??? .cpp, .cxx ? ?.?. # ? ????? ??????????? ?????? ???? ????????? ?????? ? ??????????? ? ?????????? # SOURCES aux_source_directory( ${SOURCE_ROOT} SOURCES ) message (STATUS "SOURCES:" ${SOURCES}) # ??? Windows ?? ???????? ????? ???????? #message (STATUS "SRC:" ${SRC}) if(WIN32) set(SRC ${SRC} ${SOURCE_ROOT}/resource.rc) endif(WIN32) # ???????? ?????????????? ????? ? ?????? # MainFrameBase.fbp - ?????? wxFormBlocks #set(SRC ${SRC} ${SOURCE_ROOT}/MainFrameBase.fbp ${SOURCE_ROOT}/wxsmith/MainFrameBase.wxs ${SOURCE_ROOT}/wx_pch.h) # ???????? ?????? ?????? ??? #source_group ("Headers" FILES ${HEADERS}) #source_group ("Source Files" FILES ${SOURCES}) #?????????? wxWidgets find_package(wxWidgets COMPONENTS aui adv core base REQUIRED) if(wxWidgets_FOUND) INCLUDE_DIRECTORIES(${wxWidgets_INCLUDE_DIRS}) include(${wxWidgets_USE_FILE}) endif () include_directories(${DEBEA_ROOT}) link_directories(${DEBEA_LIB}) set (REQUIRED_LIBRARIES ${REQUIRED_LIBRARIES} ${wxWidgets_LIBRARIES}) message (STATUS lib: ${wxWidgets_LIBRARIES}) # ???????? ??????????? ???? ? ?????? my_program. #add_executable( ${BIN} WIN32 ${SOURCES}) add_library(dba STATIC IMPORTED) set_property(TARGET dba PROPERTY IMPORTED_LOCATION ${DEBEA_LIB}/libdba.a) add_executable( ${BIN} WIN32 ${SOURCES} ${SRC}) # ????????? ????????? ????????? ? ???????????? ????????????? ????????????. #target_link_libraries(${BIN} ${wxWidgets_LIBRARIES}) target_link_libraries( ${BIN} ${REQUIRED_LIBRARIES} dba) From brad.king at kitware.com Mon Jun 1 15:09:08 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 01 Jun 2015 15:09:08 -0400 Subject: [CMake] Visual Studio 2013, increamental builds, intermediate directories and long target names In-Reply-To: References: Message-ID: <556CADD4.1020701@kitware.com> On 05/31/2015 12:43 PM, Dan Kegel wrote: > Did you try the workaround suggested in the first link you gave, i.e. > > set( RatherLongLibraryName_GUID_CMAKE CACHE INTERNAL > "remove this and Visual Studio will mess up incremental builds") > > On Sun, May 31, 2015 at 9:04 AM, david_bjornbak at keysight.com wrote: >> VS 2013 with cmake working with long target names. For reference, the length of the target name changes the behavior of VS but not of CMake. >> http://stackoverflow.com/questions/28959488/how-to-enable-incremental-builds-for-vs-2013-with-cmake-and-long-target-names >From that link: "solution is regenerated each build after the CMake cache has been cleared" Clearing the cache causes CMake's storage of the GUID used for each target to be reset, so it generates a new one the next time around. The above-mentioned workaround tells CMake to use a fixed GUID so it stays the same every time. Note that this workaround sets an internal/undocumented variable so it is not guaranteed to work in the future. Currently CMake was not designed to guarantee any behavior for an incremental build when CMakeCache.txt and/or CMakeFiles/ is removed without also removing other build outputs. Still, we may be able to address this particular case. If I get a chance I'll look at whether CMake can deterministically generate a GUID from a hash of the build tree and target names or something like that. -Brad From david_bjornbak at keysight.com Mon Jun 1 16:38:37 2015 From: david_bjornbak at keysight.com (david_bjornbak at keysight.com) Date: Mon, 1 Jun 2015 20:38:37 +0000 Subject: [CMake] Visual Studio 2013, increamental builds, intermediate directories and long target names In-Reply-To: <556CADD4.1020701@kitware.com> References: <556CADD4.1020701@kitware.com> Message-ID: I appreciate the feedback on this issue. Deterministically generating a GUID sounds like a real solution. ++David->Bjornbak; -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Monday, June 01, 2015 12:09 PM To: BJORNBAK,DAVID (K-Sonoma,ex1) Cc: Dan Kegel; cmake; Bill Hoffman Subject: Re: [CMake] Visual Studio 2013, increamental builds, intermediate directories and long target names On 05/31/2015 12:43 PM, Dan Kegel wrote: > Did you try the workaround suggested in the first link you gave, i.e. > > set( RatherLongLibraryName_GUID_CMAKE CACHE INTERNAL > "remove this and Visual Studio will mess up incremental builds") > > On Sun, May 31, 2015 at 9:04 AM, david_bjornbak at keysight.com wrote: >> VS 2013 with cmake working with long target names. For reference, the length of the target name changes the behavior of VS but not of CMake. >> http://stackoverflow.com/questions/28959488/how-to-enable-incremental >> -builds-for-vs-2013-with-cmake-and-long-target-names >From that link: "solution is regenerated each build after the CMake cache has been cleared" Clearing the cache causes CMake's storage of the GUID used for each target to be reset, so it generates a new one the next time around. The above-mentioned workaround tells CMake to use a fixed GUID so it stays the same every time. Note that this workaround sets an internal/undocumented variable so it is not guaranteed to work in the future. Currently CMake was not designed to guarantee any behavior for an incremental build when CMakeCache.txt and/or CMakeFiles/ is removed without also removing other build outputs. Still, we may be able to address this particular case. If I get a chance I'll look at whether CMake can deterministically generate a GUID from a hash of the build tree and target names or something like that. -Brad From robert.maynard at kitware.com Mon Jun 1 17:13:35 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Mon, 1 Jun 2015 17:13:35 -0400 Subject: [CMake] [ANNOUNCE] CMake 3.2.3 Released Message-ID: We are pleased to announce that CMake 3.2.3 is now available for download. Please use the latest release from our download page: http://www.cmake.org/download/ Thanks for your support! ------------------------------------------------------------------------- Changes in 3.2.3 since 3.2.2: Brad King (5): Makefile: Workaround mingw32-make trailing backslash trouble (#15546) Makefile: Fix compilation after parent commit was backported InstallRequiredSystemLibraries: Update for VS 2015 (#15552) Fix assertion failure on unmatched foreach in function (#15572) CMake 3.2.3 Zack Galbreath (1): ctest_build: Fix regression in GNU make error message matching From Dave at Yost.com Mon Jun 1 17:28:51 2015 From: Dave at Yost.com (Dave Yost) Date: Mon, 1 Jun 2015 14:28:51 -0700 Subject: [CMake] Not finding boost Message-ID: The boost I want is not in a normal location, but: Boost's include dir is first in my CPATH. Boost's lib dir is first in my LD_LIBRARY_PATH. Why doesn't cmake 3.2.2 find it? I'm not being picky about the version. From akapulka.2015 at yandex.ru Mon Jun 1 18:26:14 2015 From: akapulka.2015 at yandex.ru (1 1) Date: Tue, 02 Jun 2015 01:26:14 +0300 Subject: [CMake] XAML files fo Visual Studio (WP8.1) is not working? Message-ID: <3468911433197574@web27m.yandex.ru> I try add to my project *.xaml files, but xaml files adds to solutionincorrect. For example, i have App.xaml, App.xaml.cpp and App.xaml.h. In solution these files must be gropped and App.xaml must be have "XAML Page" or "XAML Application Definition" item type. But these files is not grupped, and App.xaml have item type "Does not participate in build". And generated files (App.g.h, App.g.hpp) is not creating when build. I tried CMake 3.2.2 or 3.2.3, VS2013, VS2015RC. This feature is not working? So, i try build VSXaml test from github (CMake/Test/VSXaml) with settings from Tests/CMakeLists.txt and give same problems. From roman.wueger at gmx.at Mon Jun 1 19:00:21 2015 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Tue, 2 Jun 2015 01:00:21 +0200 Subject: [CMake] Virtual folders in Visual studio get expanded on reload Message-ID: Hi, I noticed that sometimes when a target is reloaded, that the virtual folders and targets for the complete visual studio solution get expanded. For a small project this isn't a problem, but in a large project (~ 100 targets) this is a really big problem to close all targets every time. Did anybody noticed this behavior and has a solution for it? Thanks Best Regards Roman From Dave at Yost.com Mon Jun 1 22:18:18 2015 From: Dave at Yost.com (Dave Yost) Date: Mon, 1 Jun 2015 19:18:18 -0700 Subject: [CMake] Not finding boost In-Reply-To: References: Message-ID: <249F1622-1E78-4846-8227-3D1BC299AF8E@yost.com> > On 2015-06-01, at 2:28 PM, Dave Yost wrote: > > The boost I want is not in a normal location, but: > Boost's include dir is first in my CPATH. > Boost's lib dir is first in my LD_LIBRARY_PATH. > > Why doesn't cmake 3.2.2 find it? > > I'm not being picky about the version. In other words, why should I have to set BOOST_ROOT? It should be obvious where a boost is, even obvious where the one I want is. What am I missing? 0 Mon 19:13:25 yost DaveBook ~/p/c++/cmake/findboost/build 243 Z% cat ../CMakeLists.txt cmake_minimum_required (VERSION 3.2.2 FATAL_ERROR) project(findBoost CXX) find_package (Boost COMPONENTS program_options REQUIRED) if (NOT Boost_FOUND) message (FATAL_ERROR "Could not find boost! ${BOOST_VERSION}") endif () message (" Boost_LIBRARY_DIR_DEBUG is ${Boost_LIBRARY_DIR_DEBUG}") 0 Mon 19:13:34 yost DaveBook ~/p/c++/cmake/findboost/build 244 Z% cmake --version cmake version 3.2.20150504-ga4a12 CMake suite maintained and supported by Kitware (kitware.com/cmake). 0 Mon 19:13:45 yost DaveBook ~/p/c++/cmake/findboost/build 245 Z% ls -l /usr/local/boost/1.55.0..llvm/include total 0 drwxrwxr-x 221 yost admin 7514 Mar 8 22:19 boost 0 Mon 19:13:51 yost DaveBook ~/p/c++/cmake/findboost/build 246 Z% CPATH=/usr/local/boost/1.55.0..llvm/include 0 Mon 19:13:53 yost DaveBook ~/p/c++/cmake/findboost/build 247 Z% ls -l /usr/local/boost/1.55.0..llvm/lib/libboost_program_options.* -rw-rw-r-- 1 yost admin 938312 Mar 8 22:19 /usr/local/boost/1.55.0..llvm/lib/libboost_program_options.a -rwxrwxr-x 1 yost admin 444236 Mar 8 22:18 /usr/local/boost/1.55.0..llvm/lib/libboost_program_options.dylib 0 Mon 19:14:18 yost DaveBook ~/p/c++/cmake/findboost/build 248 Z% LD_LIBRARY_PATH=/usr/local/boost/1.55.0..llvm/lib 0 Mon 19:14:22 yost DaveBook ~/p/c++/cmake/findboost/build 249 Z% DYLD_LIBRARY_PATH=/usr/local/boost/1.55.0..llvm/lib 0 Mon 19:14:25 yost DaveBook ~/p/c++/cmake/findboost/build 250 Z% cmake .. CMake Error at /Applications/CMake.app/Contents/share/cmake-3.2/Modules/FindBoost.cmake:1243 (message): Unable to find the requested Boost libraries. Unable to find the Boost header files. Please set BOOST_ROOT to the root directory containing Boost or BOOST_INCLUDEDIR to the directory containing Boost's headers. Call Stack (most recent call first): CMakeLists.txt:5 (find_package) CMake Error at CMakeLists.txt:10 (message): Could not find boost! -- Configuring incomplete, errors occurred! See also "/Users/yost/p/c++/cmake/findboost/build/CMakeFiles/CMakeOutput.log". 1 Mon 19:14:46 yost DaveBook ~/p/c++/cmake/findboost/build 251 Z% -------------- next part -------------- An HTML attachment was scrubbed... URL: From Dave at Yost.com Mon Jun 1 22:43:04 2015 From: Dave at Yost.com (Dave Yost) Date: Mon, 1 Jun 2015 19:43:04 -0700 Subject: [CMake] Not finding boost In-Reply-To: <249F1622-1E78-4846-8227-3D1BC299AF8E@yost.com> References: <249F1622-1E78-4846-8227-3D1BC299AF8E@yost.com> Message-ID: <20868DFF-3CFF-4729-A03D-038D7DAD8543@yost.com> Also, from what I can make of CMake.app/Contents/share/cmake-3.2/Modules/FindBoost.cmake findBoost looks in /sw/local/ which is a path from the old, old Fink package system for OS X. findBoost should also look in /usr/local (Homebrew and long unix tradition) /opt/local (MacPorts) /opt/ (linux and others) > On 2015-06-01, at 7:18 PM, Dave Yost wrote: > > >> On 2015-06-01, at 2:28 PM, Dave Yost > wrote: >> >> The boost I want is not in a normal location, but: >> Boost's include dir is first in my CPATH. >> Boost's lib dir is first in my LD_LIBRARY_PATH. >> >> Why doesn't cmake 3.2.2 find it? >> >> I'm not being picky about the version. > > In other words, why should I have to set BOOST_ROOT? It should be obvious where a boost is, even obvious where the one I want is. What am I missing? > > 0 Mon 19:13:25 yost DaveBook ~/p/c++/cmake/findboost/build > 243 Z% cat ../CMakeLists.txt > cmake_minimum_required (VERSION 3.2.2 FATAL_ERROR) > > project(findBoost CXX) > > find_package (Boost > COMPONENTS program_options > REQUIRED) > > if (NOT Boost_FOUND) > message (FATAL_ERROR "Could not find boost! ${BOOST_VERSION}") > endif () > > message (" Boost_LIBRARY_DIR_DEBUG is ${Boost_LIBRARY_DIR_DEBUG}") > 0 Mon 19:13:34 yost DaveBook ~/p/c++/cmake/findboost/build > 244 Z% cmake --version > cmake version 3.2.20150504-ga4a12 > > CMake suite maintained and supported by Kitware (kitware.com/cmake ). > 0 Mon 19:13:45 yost DaveBook ~/p/c++/cmake/findboost/build > 245 Z% ls -l /usr/local/boost/1.55.0..llvm/include > total 0 > drwxrwxr-x 221 yost admin 7514 Mar 8 22:19 boost > 0 Mon 19:13:51 yost DaveBook ~/p/c++/cmake/findboost/build > 246 Z% CPATH=/usr/local/boost/1.55.0..llvm/include > 0 Mon 19:13:53 yost DaveBook ~/p/c++/cmake/findboost/build > 247 Z% ls -l /usr/local/boost/1.55.0..llvm/lib/libboost_program_options.* > -rw-rw-r-- 1 yost admin 938312 Mar 8 22:19 /usr/local/boost/1.55.0..llvm/lib/libboost_program_options.a > -rwxrwxr-x 1 yost admin 444236 Mar 8 22:18 /usr/local/boost/1.55.0..llvm/lib/libboost_program_options.dylib > 0 Mon 19:14:18 yost DaveBook ~/p/c++/cmake/findboost/build > 248 Z% LD_LIBRARY_PATH=/usr/local/boost/1.55.0..llvm/lib > 0 Mon 19:14:22 yost DaveBook ~/p/c++/cmake/findboost/build > 249 Z% DYLD_LIBRARY_PATH=/usr/local/boost/1.55.0..llvm/lib > 0 Mon 19:14:25 yost DaveBook ~/p/c++/cmake/findboost/build > 250 Z% cmake .. > CMake Error at /Applications/CMake.app/Contents/share/cmake-3.2/Modules/FindBoost.cmake:1243 (message): > Unable to find the requested Boost libraries. > > Unable to find the Boost header files. Please set BOOST_ROOT to the root > directory containing Boost or BOOST_INCLUDEDIR to the directory containing > Boost's headers. > Call Stack (most recent call first): > CMakeLists.txt:5 (find_package) > > > CMake Error at CMakeLists.txt:10 (message): > Could not find boost! > > > -- Configuring incomplete, errors occurred! > See also "/Users/yost/p/c++/cmake/findboost/build/CMakeFiles/CMakeOutput.log". > 1 Mon 19:14:46 yost DaveBook ~/p/c++/cmake/findboost/build > 251 Z% > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Dave at Yost.com Mon Jun 1 22:45:23 2015 From: Dave at Yost.com (Dave Yost) Date: Mon, 1 Jun 2015 19:45:23 -0700 Subject: [CMake] no convenience target for generated files? In-Reply-To: References: <041437DD-A473-4C32-A97F-28D3C9B74636@yost.com> Message-ID: <9B9B8B70-FC5E-4DD3-BF6F-C6704D999179@yost.com> 0 Mon 19:44:33 yost DaveBook ~/p/c++/cmake/target-for-generate/build 261 Z% make help The following are some of the valid targets for this Makefile: ... all (the default if no target is provided) ... clean ... depend ... edit_cache ... rebuild_cache ... foo ... genBar ... bar ... foo.o ... foo.i ... foo.s 0 Mon 19:44:35 yost DaveBook ~/p/c++/cmake/target-for-generate/build 262 Z% > On 2015-04-08, at 8:05 PM, David Cole wrote: > > Does > > cd bar > make help > > Tell you anything? > > > On Wednesday, April 8, 2015, Dave Yost > wrote: > I?m using add_custom_command to generate a file, ?bar.cc ?. > > It would be convenient if I could say > make bar.cc > or > make bar/bar.cc > but neither of these work, and I can?t see a target in the Makefiles that I can use. > > There is a way to make bar.cc.o, but not bar.cc > > 0 Wed 14:15:54 yost DaveBook ~/p/c++/cmake/target-for-generate > 241 Z% bundle `findf *` > [ find CMakeLists.txt bar foo.cc -type f ] > #!/usr/bin/env unbundle > # See http://yost.com/computers/bundle/ > ======== CMakeLists.txt > cmake_minimum_required(VERSION 3.2.1) > > project(yost-cmake-example) > > add_subdirectory(bar) > > add_executable (foo foo.cc ) > target_link_libraries(foo bar) > > ======== bar/bar.hh > extern char* str1; > > ======== bar/CMakeLists.txt > > add_executable(genBar genBar.cc ) > > add_custom_command( > OUTPUT bar.cc > COMMAND genBar > bar.cc > DEPENDS genBar) > > add_library (bar SHARED bar.cc ) > target_include_directories(bar PUBLIC .) > > ======== bar/genBar.cc > #include > > int main(int argc, char** argv) { > std::cout > << "#include \"bar.hh\"\n\n" > "char str1array[] = \"Hello!\";\n" > "char* str1 = str1array;\n"; > return 0; > } > > ======== foo.cc > #include > #include > > int main(int argc, char** argv) { > std::cout << str1 << std::endl; > return 0; > } > > ======== > 0 Wed 14:15:57 yost DaveBook ~/p/c++/cmake/target-for-generate > 242 Z% mkdir build > 0 Wed 14:16:02 yost DaveBook ~/p/c++/cmake/target-for-generate > 243 Z% cd build > 0 Wed 14:16:03 yost DaveBook ~/p/c++/cmake/target-for-generate/build > 244 Z% cmake .. > -- The C compiler identification is AppleClang 6.0.0.6000057 > -- The CXX compiler identification is AppleClang 6.0.0.6000057 > -- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc > -- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -- works > -- Detecting C compiler ABI info > -- Detecting C compiler ABI info - done > -- Detecting C compile features > -- Detecting C compile features - done > -- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ > -- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -- works > -- Detecting CXX compiler ABI info > -- Detecting CXX compiler ABI info - done > -- Detecting CXX compile features > -- Detecting CXX compile features - done > -- Configuring done > -- Generating done > -- Build files have been written to: /Users/yost/p/c++/cmake/target-for-generate/build > 0 Wed 14:16:07 yost DaveBook ~/p/c++/cmake/target-for-generate/build > 245 Z% make > Scanning dependencies of target genBar > [ 14%] Building CXX object bar/CMakeFiles/genBar.dir/genBar.cc.o > [ 28%] Linking CXX executable genBar > [ 28%] Built target genBar > [ 42%] Generating bar.cc > Scanning dependencies of target bar > [ 57%] Building CXX object bar/CMakeFiles/bar.dir/bar.cc.o > [ 71%] Linking CXX shared library libbar.dylib > [ 71%] Built target bar > Scanning dependencies of target foo > [ 85%] Building CXX object CMakeFiles/foo.dir/foo.cc.o > [100%] Linking CXX executable foo > [100%] Built target foo > 0 Wed 14:16:09 yost DaveBook ~/p/c++/cmake/target-for-generate/build > 246 Z% rm bar/bar.cc > 0 Wed 14:16:15 yost DaveBook ~/p/c++/cmake/target-for-generate/build > 247 Z% make bar/bar.cc > make: *** No rule to make target `bar/bar.cc '. Stop. > 2 Wed 14:16:24 yost DaveBook ~/p/c++/cmake/target-for-generate/build > 248 Z% make bar.cc > make: *** No rule to make target `bar.cc '. Stop. > 2 Wed 14:16:27 yost DaveBook ~/p/c++/cmake/target-for-generate/build > 249 Z% cd bar > 0 Wed 14:19:20 yost DaveBook ~/p/c++/cmake/target-for-generate/build/bar > 253 Z% make bar.cc > make: *** No rule to make target `bar.cc '. Stop. > 2 Wed 14:19:22 yost DaveBook ~/p/c++/cmake/target-for-generate/build/bar > 254 Z% make bar.cc.o > Generating bar.cc > Building CXX object bar/CMakeFiles/bar.dir/bar.cc.o > 0 Wed 14:19:25 yost DaveBook ~/p/c++/cmake/target-for-generate/build/bar > 255 Z% > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mjklaim at gmail.com Tue Jun 2 04:54:18 2015 From: mjklaim at gmail.com (=?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?=) Date: Tue, 2 Jun 2015 10:54:18 +0200 Subject: [CMake] [cmake-developers] Virtual folders in Visual studio get expanded on reload In-Reply-To: References: Message-ID: I did notice it quite a lot but I don't think CMake can do anything about it. I might be wrong though. On Tue, Jun 2, 2015 at 1:00 AM, Roman W?ger wrote: > Hi, > > I noticed that sometimes when a target is reloaded, that the virtual > folders and targets for the complete visual studio solution get expanded. > For a small project this isn't a problem, but in a large project (~ 100 > targets) this is a really big problem to close all targets every time. > > Did anybody noticed this behavior and has a solution for it? > > Thanks > > Best Regards > Roman > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake-developers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kgt at lanl.gov Tue Jun 2 09:52:04 2015 From: kgt at lanl.gov (Thompson, KT) Date: Tue, 2 Jun 2015 13:52:04 +0000 Subject: [CMake] [cmake-developers] Virtual folders in Visual studio get expanded on reload In-Reply-To: References: Message-ID: <0458DF31F610EF42BFC78C497E806C7B458AB8FF@ECS-EXG-P-MB03.win.lanl.gov> Roman, I have the same complaint. My project has about 300 targets arranged in two dozen folders. I use the "collapse all" button in Visual Studio's Solution Explorer window (looks like a stack of 3 squares in VS2013). kt -----Original Message----- From: cmake-developers [mailto:cmake-developers-bounces at cmake.org] On Behalf Of Roman W?ger Sent: Monday, June 01, 2015 5:00 PM To: CMake Developer MailingList; CMake MailingList Subject: [cmake-developers] Virtual folders in Visual studio get expanded on reload Hi, I noticed that sometimes when a target is reloaded, that the virtual folders and targets for the complete visual studio solution get expanded. For a small project this isn't a problem, but in a large project (~ 100 targets) this is a really big problem to close all targets every time. Did anybody noticed this behavior and has a solution for it? Thanks Best Regards Roman -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers From raffael.casagrande at sam.math.ethz.ch Tue Jun 2 09:54:56 2015 From: raffael.casagrande at sam.math.ethz.ch (Casagrande Raffael) Date: Tue, 2 Jun 2015 13:54:56 +0000 Subject: [CMake] Visual Studio support for Header Only Libraries Message-ID: Hello, How should I properly setup a header-only library in cmake such that: 1. The headers appear in the Visual Studio solution. 2. In an executable i can use target_link_libraries( ) to specify that I want to use (the headers of) this library. So far I have considered two options: a) create a INTERFACE library using add_library( INTERFACE), this fulfills property 2. from above but not 1. b) create a usual library and set LINKER_LANGUAGE to CXX. In this way 1. works but 2. doesn't work unfortunately because the executable will try to link to a library that does not exist. Notes: - A not so nice workaround is to go with b) and add an empty source file to it. - Another option would be to not link the executable with the HEADER_ONLY_LIBRARY. However one thing that I like about target_link_libraries is that all the "usage requirements" from the HEADER_ONLY_LIBRARY (such as include directories and compile options) are applied to the executable automatic. So if I don't use target_link_libraries I would have to set these options manually (unless there is another alternative?). I would be very happy for some suggestions :) Raffael P.S.: See also the (a bit outdated) discussion http://stackoverflow.com/a/11583676/2796908.http://stackoverflow.com/a/11583676/2796908. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Federico.Carminati at cern.ch Tue Jun 2 14:02:33 2015 From: Federico.Carminati at cern.ch (Federico Carminati) Date: Tue, 2 Jun 2015 18:02:33 +0000 Subject: [CMake] Newbye question (?) Message-ID: <61E7EC63-559A-4CCB-AA8C-EA91E0C4692F@cern.ch> Dear All, sorry if this is a stupid question. I have a directory where there are fortran and C++ files mixed and I want to specify different compilation flags for the two languages. Is this possible? And if yes, how? Thanks a lot for your help and best regards, Federico Carminati CERN-PH 1211 Geneva 23 Switzerland Tel: +41 22 76 74959 Fax: +41 22 76 68505 Mobile: +41 76 487 4843 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kent.Knox at amd.com Tue Jun 2 12:26:39 2015 From: Kent.Knox at amd.com (Knox, Kent) Date: Tue, 2 Jun 2015 16:26:39 +0000 Subject: [CMake] CMake Digest, Vol 134, Issue 1 In-Reply-To: References: Message-ID: <19F649914E0E4A4C82F9972E886B16CA44C860C5@satlexdag04.amd.com> Hi Daniel~ " Suppose you have libA that optionally uses zip functionality (say by some option USE_ZLIB in libA's CMakeLists.txt). This means libA will optionally have -lz in its INTERFACE_LINK_LIBRARIES (exported into liba-config.cmake)." I think the best way to handle this is to turn 'transitive library linking' off. It seems to me that the use of zip functionality is an implementation detail of libA, that no clients should be aware of. I do this in my projects with a special form of the target_link_libraries( ) command: `target_link_libraries( libA PRIVATE ${ZLIB_LIBRARIES} )` I believe PRIVATE, PUBLIC, INTERFACE keywards were added in cmake 2.8.12 Kent ------------------------------ Message: 4 Date: Mon, 01 Jun 2015 11:03:53 +0200 From: Daniel Wirtz To: cmake at cmake.org Subject: [CMake] Conditional transitive link libraries Message-ID: <556C1FF9.6040609 at simtech.uni-stuttgart.de> Content-Type: text/plain; charset=utf-8; format=flowed Hello all, I'm struggling with the CMake "Config"-based package description when using two depending packages where the upstream package has optional link libraries. Suppose you have libA that optionally uses zip functionality (say by some option USE_ZLIB in libA's CMakeLists.txt). This means libA will optionally have -lz in its INTERFACE_LINK_LIBRARIES (exported into liba-config.cmake). Now, if you have a libB using libA via find_package(libA), how do you know if libA has been built with or without zlib support when both libraries are installed and exported with CMake's package config system? I know that the link library information is treated transitively and will be propagated to the link libraries of libB, hence -lz will appear whenever linking against libB. However, the PATH to libz is nowhere included; consequently, the link fails with "could not find library z" unless you magically knew that libz is a dependent link library of libA and where to include it from. Including the absolute path to libz in libA's config is also not the way to go, as it ruins the portability over different systems. Is there a "native" CMake way? Thanks! -- Dr. Daniel Wirtz Dipl. Math. Dipl. Inf. SRC SimTech Pfaffenwaldring 5a +49 711 685 60044 From Dave at Yost.com Tue Jun 2 17:46:39 2015 From: Dave at Yost.com (Dave Yost) Date: Tue, 2 Jun 2015 14:46:39 -0700 Subject: [CMake] Not finding boost In-Reply-To: <20868DFF-3CFF-4729-A03D-038D7DAD8543@yost.com> References: <249F1622-1E78-4846-8227-3D1BC299AF8E@yost.com> <20868DFF-3CFF-4729-A03D-038D7DAD8543@yost.com> Message-ID: <50D958A5-7CB9-4D63-988F-3E4FA7027C82@yost.com> Here is my solution. if (DEFINED BOOST_ROOT) message (" Using argument BOOST_ROOT ${BOOST_ROOT}") elseif (DEFINED ENV{BOOST_ROOT}) message (" Using env var BOOST_ROOT $ENV{BOOST_ROOT}") set (BOOST_ROOT $ENV{BOOST_ROOT}) else () message (" Looking in CPATH for include/boost/") if (DEFINED ENV{CPATH}) string (REPLACE ":" ";" cpathList $ENV{CPATH}) foreach (dir ${cpathList}) if (EXISTS ${dir}/boost) message (" BOOST_ROOT found in CPATH ${dir}/..") set (BOOST_ROOT ${dir}/..) break () endif () endforeach () endif () endif () > On 2015-06-01, at 7:43 PM, Dave Yost wrote: > > Also, from what I can make of > CMake.app/Contents/share/cmake-3.2/Modules/FindBoost.cmake > findBoost looks in > /sw/local/ > which is a path from the old, old Fink package system for OS X. findBoost should also look in > /usr/local (Homebrew and long unix tradition) > /opt/local (MacPorts) > /opt/ (linux and others) > >> On 2015-06-01, at 7:18 PM, Dave Yost > wrote: >> >> >>> On 2015-06-01, at 2:28 PM, Dave Yost > wrote: >>> >>> The boost I want is not in a normal location, but: >>> Boost's include dir is first in my CPATH. >>> Boost's lib dir is first in my LD_LIBRARY_PATH. >>> >>> Why doesn't cmake 3.2.2 find it? >>> >>> I'm not being picky about the version. >> >> In other words, why should I have to set BOOST_ROOT? It should be obvious where a boost is, even obvious where the one I want is. What am I missing? >> >> 0 Mon 19:13:25 yost DaveBook ~/p/c++/cmake/findboost/build >> 243 Z% cat ../CMakeLists.txt >> cmake_minimum_required (VERSION 3.2.2 FATAL_ERROR) >> >> project(findBoost CXX) >> >> find_package (Boost >> COMPONENTS program_options >> REQUIRED) >> >> if (NOT Boost_FOUND) >> message (FATAL_ERROR "Could not find boost! ${BOOST_VERSION}") >> endif () >> >> message (" Boost_LIBRARY_DIR_DEBUG is ${Boost_LIBRARY_DIR_DEBUG}") >> 0 Mon 19:13:34 yost DaveBook ~/p/c++/cmake/findboost/build >> 244 Z% cmake --version >> cmake version 3.2.20150504-ga4a12 >> >> CMake suite maintained and supported by Kitware (kitware.com/cmake ). >> 0 Mon 19:13:45 yost DaveBook ~/p/c++/cmake/findboost/build >> 245 Z% ls -l /usr/local/boost/1.55.0..llvm/include >> total 0 >> drwxrwxr-x 221 yost admin 7514 Mar 8 22:19 boost >> 0 Mon 19:13:51 yost DaveBook ~/p/c++/cmake/findboost/build >> 246 Z% CPATH=/usr/local/boost/1.55.0..llvm/include >> 0 Mon 19:13:53 yost DaveBook ~/p/c++/cmake/findboost/build >> 247 Z% ls -l /usr/local/boost/1.55.0..llvm/lib/libboost_program_options.* >> -rw-rw-r-- 1 yost admin 938312 Mar 8 22:19 /usr/local/boost/1.55.0..llvm/lib/libboost_program_options.a >> -rwxrwxr-x 1 yost admin 444236 Mar 8 22:18 /usr/local/boost/1.55.0..llvm/lib/libboost_program_options.dylib >> 0 Mon 19:14:18 yost DaveBook ~/p/c++/cmake/findboost/build >> 248 Z% LD_LIBRARY_PATH=/usr/local/boost/1.55.0..llvm/lib >> 0 Mon 19:14:22 yost DaveBook ~/p/c++/cmake/findboost/build >> 249 Z% DYLD_LIBRARY_PATH=/usr/local/boost/1.55.0..llvm/lib >> 0 Mon 19:14:25 yost DaveBook ~/p/c++/cmake/findboost/build >> 250 Z% cmake .. >> CMake Error at /Applications/CMake.app/Contents/share/cmake-3.2/Modules/FindBoost.cmake:1243 (message): >> Unable to find the requested Boost libraries. >> >> Unable to find the Boost header files. Please set BOOST_ROOT to the root >> directory containing Boost or BOOST_INCLUDEDIR to the directory containing >> Boost's headers. >> Call Stack (most recent call first): >> CMakeLists.txt:5 (find_package) >> >> >> CMake Error at CMakeLists.txt:10 (message): >> Could not find boost! >> >> >> -- Configuring incomplete, errors occurred! >> See also "/Users/yost/p/c++/cmake/findboost/build/CMakeFiles/CMakeOutput.log". >> 1 Mon 19:14:46 yost DaveBook ~/p/c++/cmake/findboost/build >> 251 Z% >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjvbertin at gmail.com Tue Jun 2 20:44:29 2015 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Wed, 03 Jun 2015 02:44:29 +0200 Subject: [CMake] linking a C application with a C++ library Message-ID: <1564499.PJSPuDrUbk@portia.local> Hello, I'm trying to write a cmake file for an older project of mine, which consists of a library (mostly C++) and a few test cases one of which is a C programme to test the library's functionality exported to C. I'd like to use a single cmake file, but am getting link error on the C app, most likely because it should be linked by the C++ linker (or at least with -X c++). How do I instruct cmake to do this? Thanks, R. From rjvbertin at gmail.com Tue Jun 2 20:52:27 2015 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Wed, 03 Jun 2015 02:52:27 +0200 Subject: [CMake] linking a C application with a C++ library In-Reply-To: <1564499.PJSPuDrUbk@portia.local> References: <1564499.PJSPuDrUbk@portia.local> Message-ID: <9940548.aDH149NIbs@portia.local> On Wednesday June 03 2015 02:44:29 Ren? J.V. Bertin wrote: > How do I instruct cmake to do this? never mind: set_target_properties(cseTest PROPERTIES LINKER_LANGUAGE CXX) Sorry for the noise! R. From andlind at gmail.com Wed Jun 3 05:46:10 2015 From: andlind at gmail.com (Anders Lindgren) Date: Wed, 3 Jun 2015 11:46:10 +0200 Subject: [CMake] add_custom_command taints main dependency file? Message-ID: Hi! I just noticed that add_custom_command() "taints" the main dependency file, a behavior that in counter-intuitive and does not correspond to the description in the CMake manual. The following files demonstrates the problem: ---- CMakeLists.txt cmake_minimum_required(VERSION 3.1) add_custom_command( MAIN_DEPENDENCY input.c COMMENT "Generating ${CMAKE_CURRENT_BINARY_DIR}/output.c" COMMAND ${CMAKE_COMMAND} -E copy ${CMAKE_CURRENT_SOURCE_DIR}/input.c ${CMAKE_CURRENT_BINARY_DIR}/output.c OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/output.c VERBATIM) add_executable(foo ${CMAKE_CURRENT_BINARY_DIR}/output.c) add_executable(bar input.c) ---- input.c: int main() { return 0; } ---- In this case, I expect "bar" to simply include a plain "input.c" Instead, it gets an "input.c" with a custom rule. This doesn't work since 1: "bar" generates "output.c" (which is shouldn't) and 2: "input.c" isn't compiled and included in the project. I've tested this using CMake 3.1 using Visual Studio 2008 and using CMake 3.2.1 on UNIX using Makefile:s. My specific use case is that I create two targets and after each target is created I create a custom command and add the output files to the target. (The path of the output file contains the ARCHIVE_OUTPUT_DIRECTORY target property.) In my case, what happens is that second target includes rules for building the output file of the first target, as well as rules for building it's own. Sincerely, Anders Lindgren -------------- next part -------------- An HTML attachment was scrubbed... URL: From Micha.Renner at t-online.de Wed Jun 3 09:50:16 2015 From: Micha.Renner at t-online.de (Micha Renner) Date: Wed, 03 Jun 2015 15:50:16 +0200 Subject: [CMake] Find a 64-bit library Message-ID: <1433339416.2746.5.camel@t-online.de> Hallo, I want to find the library MSImg32 on a Windos 8.1 system 64-bit. The library is located here: "C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Lib\x64 \MSImg32.Lib" "C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Lib\MSImg32.Lib" "C:\Program Files (x86)\Windows Kits\8.0\Lib\win8\um\x64\MSImg32.Lib" "C:\Program Files (x86)\Windows Kits\8.0\Lib\win8\um\x86\MSImg32.Lib" The script uses these commands to locate the library SET_PROPERTY(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS TRUE) FIND_LIBRARY(MS_IMG_32_LIBRARY MSImg32) The result is: C:/Program Files (x86)/Windows Kits/8.0/Lib/win8/um/x86/MSImg32.Lib So what can I do to find the 64-bit version of MSImg32. Greetings Micha From steveire at gmail.com Wed Jun 3 14:04:19 2015 From: steveire at gmail.com (Stephen Kelly) Date: Wed, 03 Jun 2015 20:04:19 +0200 Subject: [CMake] Conditional transitive link libraries References: <556C1FF9.6040609@simtech.uni-stuttgart.de> Message-ID: Daniel Wirtz wrote: > Hello all, > > I'm struggling with the CMake "Config"-based package description when > using two depending packages where the upstream package has optional > link libraries. For reference, you have the right answer and the link to the right documentation on SO http://stackoverflow.com/questions/30568733 Thanks, Steve. From daniel.wirtz at simtech.uni-stuttgart.de Wed Jun 3 15:17:50 2015 From: daniel.wirtz at simtech.uni-stuttgart.de (Daniel Wirtz) Date: Wed, 03 Jun 2015 21:17:50 +0200 Subject: [CMake] Conditional transitive link libraries In-Reply-To: References: <556C1FF9.6040609@simtech.uni-stuttgart.de> Message-ID: <556F52DE.6070805@simtech.uni-stuttgart.de> Hey, so while this is a suitable solution for 3-level transitive packages, it will break as soon as you have more than that.. i realized there is no "native" solution to the problem, and the solution in the below link indeed helps for many cases. however, facing a ever-more cmake'ified software environment (which is good!), we will sooner or later encounter "downstream" package constellations that have transitive linking into cmake packages over more than 3 levels.. so i think it is worth while discussing/thinking about a suitable design to include. best, Daniel > Daniel Wirtz wrote: > >> Hello all, >> >> I'm struggling with the CMake "Config"-based package description when >> using two depending packages where the upstream package has optional >> link libraries. > For reference, you have the right answer and the link to the right > documentation on SO > > http://stackoverflow.com/questions/30568733 > > Thanks, > > Steve. > From steveire at gmail.com Wed Jun 3 15:34:37 2015 From: steveire at gmail.com (Stephen Kelly) Date: Wed, 03 Jun 2015 21:34:37 +0200 Subject: [CMake] Conditional transitive link libraries References: <556C1FF9.6040609@simtech.uni-stuttgart.de> <556F52DE.6070805@simtech.uni-stuttgart.de> Message-ID: Daniel Wirtz wrote: > Hey, > > so while this is a suitable solution for 3-level transitive packages, it > will break as soon as you have I don't understand. Please provide an http://sscce.org/ if you can. > more than that.. > i realized there is no "native" solution to the problem, and the The native solution is documented here: http://www.cmake.org/cmake/help/v3.2/manual/cmake-packages.7.html#creating-packages If there is a 3-level or further problem, then I am not aware of it. Thanks, Steve. From jackie at sdiwc.info Thu Jun 4 02:19:14 2015 From: jackie at sdiwc.info (Jackie Blanco) Date: Thu, 04 Jun 2015 00:19:14 -0600 Subject: [CMake] Deadline Approaching: The Global Technology Management Conference 2015 - USA Message-ID: The Global Technology Management Conference (GTMC2015) Bemidji State University, Minnesota, USA July 15 - 17, 2015 http://sdiwc.net/conferences/gtmc2015/ You are invited to participate in The Global Technology Management Conference (GTMC2015) that will be held at Bemidji State University, Minnesota, USA on July 15 - 17, 2015. The event will be held over three days, with presentations delivered by researchers from the international community, including presentations from keynote speakers and state-of-the-art lectures. The proceedings will be published in SDIWC Digital Library. The conference welcome papers on the following (but not limited to) research topics: *Information Technology -Information and Data Management -Information Content Security -The Management of IT Investments -Computational Intelligence -Data Management in Mobile Peer-to-Peer Networks -Information Management -Enterprise Architecture Management -The Management of "Green" IT -Ubiquitous Computing, Services and Applications -Web Services Security -Information Ethics -Quality of Service, Scalability and Performance -Information Security and Cryptography -Data Stream Processing in Mobile/Sensor Networks *Computer Science -Biometrics Technologies -Computer Forensics -Computer Security -Data Mining -Distributed and Parallel Applications -Wireless Communications -Cloud Computing -Access Control -Network Security -Digital Signal and Image Processing -Multimedia Computing -Computer Animation -Computer Architecture -Artificial Intelligence -Information Retrieval -Natural Language Processing *Business, and Technology In Education -Educational Technology -Computer-aided Systems -Mobile Computing -Education In Computational Science -Mobile Learning -Business Intelligence and Web Services -E-commerce Business Models -Future Development of E-Business -E- Learning -E-Government -Debugging Tools and Learning -E-Business Applications and Software *Manufacturing Systems -Design and Manufacturing -Intelligent Processing of Materials -Human-Machine Interface -Computer-Aided Design, Manufacturing, and Engineering -Modeling and Design -Design and Green Manufacturing -Automation -Networks Design, Protocols and Management *Engineering Technology -Bioinformatics & Biomedical Imaging -Robotics and Atomization Engineering -Globalization of Engineering -Applications of AI Techniques in Design and Manufacturing -Industrial Engineering -Biomedical Signal Processing -Robotics and Mobile Machines -Computer Architecture for Intelligent Machines All submitted papers will be reviewed by a minimum of two reviewers. The published proceedings will be indexed in ResearchBib, ProQuest, and Google Scholar Databases, in addition they will be submitted for POSSIBLE inclusion within the INSPEC, EI, DBLP, Microsoft Academic Research, and ResearchGate. IMPORTANT DATES =============== Submission Deadline: Open from now until June 15, 2015 Notification of Acceptance: 4 weeks from the submission date Camera Ready Submission: Open from now until July 05, 2015 Registration Deadline: Open from now until July 05, 2015 Conference Dates: July 15 - 17, 2015 Drop us an email at gtmc15 at sdiwc.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From ycollette.nospam at free.fr Thu Jun 4 02:48:00 2015 From: ycollette.nospam at free.fr (ycollette.nospam at free.fr) Date: Thu, 4 Jun 2015 08:48:00 +0200 (CEST) Subject: [CMake] Ctest and setting variables via command line In-Reply-To: <712096223.120919067.1433400336676.JavaMail.root@zimbra35-e6.priv.proxad.net> Message-ID: <1856246521.120928569.1433400480532.JavaMail.root@zimbra35-e6.priv.proxad.net> Hello, With the current version of CTest.cmake, it's not possible to set the CTEST_DROP_SITE and some others variables via a cmake command line. The only solution is to add a CTestConfig.cmake file is the source directory. What about changing this part of CTest.cmake: if(EXISTS "${PROJECT_SOURCE_DIR}/CTestConfig.cmake") include("${PROJECT_SOURCE_DIR}/CTestConfig.cmake") SET_IF_SET_AND_NOT_SET(NIGHTLY_START_TIME "${CTEST_NIGHTLY_START_TIME}") SET_IF_SET_AND_NOT_SET(DROP_METHOD "${CTEST_DROP_METHOD}") SET_IF_SET_AND_NOT_SET(DROP_SITE "${CTEST_DROP_SITE}") SET_IF_SET_AND_NOT_SET(DROP_SITE_USER "${CTEST_DROP_SITE_USER}") SET_IF_SET_AND_NOT_SET(DROP_SITE_PASSWORD "${CTEST_DROP_SITE_PASWORD}") SET_IF_SET_AND_NOT_SET(DROP_SITE_MODE "${CTEST_DROP_SITE_MODE}") SET_IF_SET_AND_NOT_SET(DROP_LOCATION "${CTEST_DROP_LOCATION}") SET_IF_SET_AND_NOT_SET(TRIGGER_SITE "${CTEST_TRIGGER_SITE}") SET_IF_SET_AND_NOT_SET(UPDATE_TYPE "${CTEST_UPDATE_TYPE}") endif() into: if(EXISTS "${PROJECT_SOURCE_DIR}/CTestConfig.cmake") include("${PROJECT_SOURCE_DIR}/CTestConfig.cmake") endif() SET_IF_SET_AND_NOT_SET(NIGHTLY_START_TIME "${CTEST_NIGHTLY_START_TIME}") SET_IF_SET_AND_NOT_SET(DROP_METHOD "${CTEST_DROP_METHOD}") SET_IF_SET_AND_NOT_SET(DROP_SITE "${CTEST_DROP_SITE}") SET_IF_SET_AND_NOT_SET(DROP_SITE_USER "${CTEST_DROP_SITE_USER}") SET_IF_SET_AND_NOT_SET(DROP_SITE_PASSWORD "${CTEST_DROP_SITE_PASWORD}") SET_IF_SET_AND_NOT_SET(DROP_SITE_MODE "${CTEST_DROP_SITE_MODE}") SET_IF_SET_AND_NOT_SET(DROP_LOCATION "${CTEST_DROP_LOCATION}") SET_IF_SET_AND_NOT_SET(TRIGGER_SITE "${CTEST_TRIGGER_SITE}") SET_IF_SET_AND_NOT_SET(UPDATE_TYPE "${CTEST_UPDATE_TYPE}") With such a change we should be able to fine tune some ctest variables via the cmake command line. Best regards, YC From brad.king at kitware.com Thu Jun 4 08:44:31 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 04 Jun 2015 08:44:31 -0400 Subject: [CMake] Visual Studio 2013, increamental builds, intermediate directories and long target names In-Reply-To: References: <556CADD4.1020701@kitware.com> Message-ID: <5570482F.8050803@kitware.com> On 06/01/2015 04:38 PM, david_bjornbak at keysight.com wrote: > Deterministically generating a GUID sounds like a real solution. > >> If I get a chance I'll look at whether CMake can deterministically >> generate a GUID from a hash of the build tree and target names I've done this here: VS: Compute project GUIDs deterministically http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c85367f4 We're past the freeze for CMake 3.3 but this will be in 3.4. Meanwhile you can try using a nightly binary to drive your incremental builds: http://www.cmake.org/files/dev/?C=M;O=D It should be part of cmake-3.3.20150602 or later. -Brad From elfring at users.sourceforge.net Thu Jun 4 09:30:16 2015 From: elfring at users.sourceforge.net (SF Markus Elfring) Date: Thu, 04 Jun 2015 15:30:16 +0200 Subject: [CMake] Management of source file lists Message-ID: <557052E8.7080407@users.sourceforge.net> Hello, CMake provides an interface for sub-projects by the command "add_subdirectory". http://www.cmake.org/cmake/help/v3.2/command/add_subdirectory.html The input and output directories will match by default and will be automatically created by the build system. Each directory will usually handle only the source files from its own area. I see software development challenges there if the corresponding source file lists will also be needed for other build options like documentation generation from source code. Now I am looking again for possibilities to forward information from such subdirectories to companion CMake projects. I can construct also a source file list in a single CMake script. Do I need to care for creation of output directories myself then if I combine some components in this way? Regards, Markus From gahanse at sandia.gov Thu Jun 4 10:45:56 2015 From: gahanse at sandia.gov (Hansen, Glen A) Date: Thu, 4 Jun 2015 14:45:56 +0000 Subject: [CMake] CTEST_TEST INCLUDE_LABEL does not include labeled tests Message-ID: All, I am running cmake version 3.0.1 In my dashboard CTest script, I'd like to only run the tests marked with the label "CUDA_TEST". When I set up the tests, I set their labels with the following command: set_tests_properties(${testName} PROPERTIES LABELS CUDA_TEST) When I run the tests manually using ctest: ctest -L CUDA_TEST only the tests with the CUDA_TEST label are executed, which is exactly what I want. However, when I script this in my dashboard script, as follows: CTEST_TEST( BUILD "${CTEST_BINARY_DIRECTORY}/Albany" INCLUDE_LABEL "CUDA_TEST" ) I get the following: SetCTestConfiguration:BuildDirectory:/home/gahanse/nightly/buildAlbany/Albany SetCTestConfiguration:SourceDirectory:/home/gahanse/nightly/repos Test project /home/gahanse/nightly/buildAlbany/Albany Constructing a list of tests Done constructing a list of tests Checking test dependency graph... Checking test dependency graph end No tests were found!!! Does anyone see what I might have done wrong or have ideas about what is happening? Thanks! Glen -- ******************************************* Glen Hansen Manager, Computational Multiphysics Dept. (1443) Sandia National Laboratories P.O. Box 5800, MS 1321 Albuquerque, NM 87185-1321 Email: gahanse at sandia.gov Sandia Location: CSRI Room 168 Phone: (505) 252-9514 ******************************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: From scott at towel42.com Thu Jun 4 12:54:52 2015 From: scott at towel42.com (Scott Aron Bloom) Date: Thu, 4 Jun 2015 16:54:52 +0000 Subject: [CMake] RPATH issues... Message-ID: Recently, during our install phase, we get the following error message CMake Error at CoreApp/CLI/cmake_install.cmake:45 (file): file RPATH_CHANGE could not write new RPATH: $ORIGIN/lib to the file: /home/marc_local/views/.branch/bin/dbg/Install/./.BluePearlCLI No valid ELF RPATH or RUNPATH entry exists in the file; File does not have a valid ELF identification. Call Stack (most recent call first): cmake_install.cmake:768 (include) The only solution seems to be a make clean. However that seems a bit drastic.. Any ideas on what could cause this? Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From smjert at gmail.com Thu Jun 4 14:06:30 2015 From: smjert at gmail.com (Stefano Bonicatti) Date: Thu, 4 Jun 2015 20:06:30 +0200 Subject: [CMake] Force appending flags to external projects Message-ID: Hello, i'm on Windows, i have a CMake script which uses ExternalProject_Add to download and compile some libraries my project needs. The majority of the libraries use CMake themselves. Now what i'm interested in is having these libraries compile with the Visual Studio /MP flag appended to their C++/C flags. Is there any way to do this from my CMake script? -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Fri Jun 5 09:03:00 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 5 Jun 2015 09:03:00 -0400 Subject: [CMake] [ANNOUNCE] CMake 3.3.0-rc1 is now ready! Message-ID: I am proud to announce the first CMake 3.3 release candidate. Sources and binaries are available at: http://www.cmake.org/download/ Documentation is available at: http://www.cmake.org/cmake/help/v3.3 Release notes appear below and are also published at http://www.cmake.org/cmake/help/v3.3/release/3.3.html Some of the more significant features of CMake 3.3 are: * The "if()" command learned a new "IN_LIST" operator that evaluates to true if a given element is contained in a named list. * The "add_dependencies()" command learned to allow dependencies to be added to *interface libraries*. Dependencies added to an interface library are followed transitively in its place since the target itself does not build. * The "find_library()", "find_path()", and "find_file()" commands now search in installation prefixes derived from the "PATH" environment variable. * The "_VISIBILITY_PRESET" and "VISIBILITY_INLINES_HIDDEN" target properties now affect compilation in sources of all target types. See policy "CMP0063". * A "_INCLUDE_WHAT_YOU_USE" target property and supporting "CMAKE__INCLUDE_WHAT_YOU_USE" variable were introduced to tell the *Makefile Generators* and the "Ninja" generator to run "include- what-you-use" along with the compiler for "C" and "CXX" languages. Deprecated and Removed Features: * The "ctest_build()" and "build_command()" commands no longer tell "make" tools to ignore errors with the "-i" option. Previously this was done for *Makefile Generators* but not others. See policy "CMP0061". * The "Visual Studio 7" generator (.NET 2002) is now deprecated and will be removed in a future version of CMake. * The "Visual Studio 6" generator is now deprecated and will be removed in a future version of CMake. * The "add_definitions()" command no longer causes a "DEFINITIONS" directory property to be populated. See policy "CMP0059". CMake 3.3 Release Notes *********************** Changes made since CMake 3.2 include the following. New Features ============ Generators ---------- * The *Makefile Generators* now add ".DELETE_ON_ERROR" to the makefiles that contain the actual build rules for files on disk. This tells GNU make to remove rule outputs when their recipe modifies an output but fails. * The *Visual Studio Generators* learned to support ".xaml" source files and automatically associate them with corresponding ".h" and ".cpp" sources. * A new experimental "Green Hills MULTI" generator was added on Windows. Green Hills MULTI is an IDE for embedded real-time systems. Commands -------- * The "add_dependencies()" command learned to allow dependencies to be added to *interface libraries*. Dependencies added to an interface library are followed transitively in its place since the target itself does not build. * The "execute_process()" command learned to support specifying the same file for "OUTPUT_FILE" and "ERROR_FILE". * The "file(GLOB)" and "file(GLOB_RECURSE)" commands learned a new "LIST_DIRECTORIES " option to specify whether the glob result should include directories. * The "find_library()", "find_path()", and "find_file()" commands now search in installation prefixes derived from the "PATH" environment variable. * The "if()" command learned a new "IN_LIST" operator that evaluates to true if a given element is contained in a named list. * The "install(EXPORT)" and "export()" commands learned to export targets that populate the "INTERFACE_SOURCES" target property. * The "install(TARGETS)" command learned to support generator expressions in the "DESTINATION" value. Variables --------- * The version of some Fortran compilers is now detected and stored in the "CMAKE_Fortran_COMPILER_VERSION" variable. * The *Visual Studio Generators* learned a new "CMAKE_VS_INCLUDE_INSTALL_TO_DEFAULT_BUILD" option to put the "INSTALL" target in the default build of a solution (".sln") file. Properties ---------- * A "CROSSCOMPILING_EMULATOR" target property and supporting "CMAKE_CROSSCOMPILING_EMULATOR" variable were introduced to allow target platform binaries to run on the host during cross compiling. * A "_INCLUDE_WHAT_YOU_USE" target property and supporting "CMAKE__INCLUDE_WHAT_YOU_USE" variable were introduced to tell the *Makefile Generators* and the "Ninja" generator to run "include- what-you-use" along with the compiler for "C" and "CXX" languages. * The "_VISIBILITY_PRESET" and "VISIBILITY_INLINES_HIDDEN" target properties now affect compilation in sources of all target types. See policy "CMP0063". * The "XCODE_ATTRIBUTE_" target property learned to support generator expressions. Modules ------- * The "CheckFortranCompilerFlag" module was introduced to check "Fortran" compiler flags, much like the "CheckCCompilerFlag" module already does for "C". * The "ExternalData" module learned a new "ExternalData_NO_SYMLINKS" option to disable use of symbolic links to populate the real data files and use copies instead. * The "ExternalData" module learned a new "RECURSE:" option in "DATA{}" references specifying directories. This allows an entire directory tree of associated files to be matched. * The "ExternalData" module learned a new URL template placeholder "%(algo:)" to allow custom mapping from algorithm name to URL component through configuration of new "ExternalData_URL_ALGO__" variables. This allows more flexibility in remote URLs. * The "ExternalProject" module learned to replace tokens like "" in the "BYPRODUCTS" of each step. * The "ExternalProject" module APIs learned to support "generator expressions" when using "LOG_*" options and in CMake initial cache options. * The "FindBoost" module now tracks the directories containing libraries separately for RELEASE and DEBUG configurations. * The "FindCUDA" module now defaults to using the static CUDA runtime library if it is available. A new "CUDA_USE_STATIC_CUDA_RUNTIME" option is offered to control this behavior. * The "FindMatlab" module was completely rewritten. It learned about versions and components and to find Matlab in a more precise and multiplatform way. The module now offers APIs to create mex extensions, documentation, and unit tests. * The "FindPackageHandleStandardArgs" module "FIND_PACKAGE_HANDLE_STANDARD_ARGS" function now always populates both the "_FOUND" and "_FOUND" variables (the latter for backwards compatibility). The "FOUND_VAR" option is now ignored except to enforce its allowed values. * The "InstallRequiredSystemLibraries" module learned a new "CMAKE_INSTALL_SYSTEM_RUNTIME_COMPONENT" option to specify the installation component. Generator Expressions --------------------- * A new "COMPILE_LANGUAGE" generator expression was introduced to allow specification of compile options for target files based on the "LANGUAGE" of each source file. Due to limitations of the underlying native build tools, this feature has varying support across generators. See the "cmake-generator-expressions(7)" manual for details. CTest ----- * The "ctest(1)" tool learned a new "--repeat-until-fail " option to help find sporadic test failures. * The "CTestCoverageCollectGCOV" module learned to support the same "CTEST_CUSTOM_COVERAGE_EXCLUDE" option as the "ctest_coverage()" command. CPack ----- * The "cpack(1)" "IFW" generator and the "CPackIFW" module learned to support Qt Framework Installer 2.0 tools. * The "CPackDeb" module learned a new "CPACK_DEBIAN__PACKAGE_SHLIBDEPS" variable to specify per-component use of "dpkg-shlibdeps". * The "CPackDeb" module learned a new "CPACK_DEBIAN__PACKAGE_DEPENDS" option to specify per- component dependencies. * The "CPackRPM" module learned to package symbolic links more cleanly and now supports directory symlinks with recent "rpmbuild" versions. * The "CPackRPM" module learned a new "CPACK_RPM_ADDITIONAL_MAN_DIRS" variable to specify directories containing man pages for the brp- compress RPM macro. * The "CPackRPM" module learned a new "CPACK_RPM__PACKAGE_ARCHITECTURE" variable to specify a component-specific package architecture. * The CPack WIX generator learned the new "CPACK_START_MENU_SHORTCUTS", "CPACK_DESKTOP_SHORTCUTS" and "CPACK_STARTUP_SHORTCUTS" installed file properties which can be used to install shorcuts in the Start Menu, on the Desktop and in the Startup Folder respectively. Other ----- * The "Compile Features" functionality is now aware of features supported by GNU compilers on Windows, versions 4.4 through 5.0. * The "cmake(1)" "-E tar" command learned a new "--format" option to specify the archive format to be written. * On OS X, CMake learned to create XCTest bundles to test Frameworks and App Bundles within Xcode. The "FindXCTest" module provides convenience functions to handle "XCTEST" bundles. Deprecated and Removed Features =============================== * On OS X the "cmake-gui(1)" no longer has the "Install For Command Line Use" menu item. Instead there is a "How to Install For Command Line Use" menu item that shows an informational dialog box explaining how to make the command line tools available. For example: /Applications/CMake.app/Contents/bin/cmake-gui --install * The "ctest_build()" and "build_command()" commands no longer tell "make" tools to ignore errors with the "-i" option. Previously this was done for *Makefile Generators* but not others. See policy "CMP0061". * The "Visual Studio 10 2010" generator no longer checks for running VS IDEs with the project open or asks them to reload. This was originally done for VS 10 because it had been done for VS 7 through 9 to avoid prompting for every project in a solution. Since VS >= 10 allow the whole solution to reload at once they do not need CMake to help them. * The "Visual Studio 7" generator (.NET 2002) is now deprecated and will be removed in a future version of CMake. * The "Visual Studio 6" generator is now deprecated and will be removed in a future version of CMake. * The "find_package()" command no longer considers project build trees recently configured in a "cmake-gui(1)". This was previously done only on Windows and is now never done. The "NO_CMAKE_BUILDS_PATH" option is now ignored if given and effectively always on. Projects may populate the *User Package Registry* to aid users building multiple dependent projects one after another. * When building with GNU tools on Windows (MinGW tools), the "find_library()" command will no longer consider ".dll" files to be linkable libraries. All dynamic link libraries are expected to provide separate ".dll.a" or ".lib" import libraries. * The "add_definitions()" command no longer causes a "DEFINITIONS" directory property to be populated. See policy "CMP0059". * With Visual Studio 7, 8, and 9 generators the value of the "$(OutDir)" placeholder no longer evaluates to the configuration name. Projects should use "$(ConfigurationName)" for that instead. * Using the output of "export()" with the "install(FILES)" command is no longer allowed. See policy "CMP0062" for details. Other Changes ============= * The "Ninja" generator now requires that calls to the "add_custom_command()" and "add_custom_target()" commands use the "BYPRODUCTS" option to explicitly specify any files generated by the custom commands that are not listed as outputs (perhaps because their timestamps are allowed to be older than the inputs). See policy "CMP0058". * Build-time progress output of *Makefile Generators* has been improved. It no longer mixes progress and build rule messages during parallel builds. The link rule messages now have progress and are displayed as bold green instead of bold red (since red is often associated with an error message). * The "CMAKE_CFG_INTDIR" variable value for Visual Studio 7, 8, and 9 is now "$(ConfigurationName)" instead of "$(OutDir)". This should have no effect on the intended use cases of the variable. * Linking to library files by a full path in an implicit linker search directory (e.g. "/usr/lib/libfoo.a") no longer asks the linker to search for the library (e.g. "-lfoo") and now links by full path. See policy "CMP0060". From DLRdave at aol.com Fri Jun 5 10:18:33 2015 From: DLRdave at aol.com (David Cole) Date: Fri, 5 Jun 2015 10:18:33 -0400 Subject: [CMake] [ANNOUNCE] CMake 3.3.0-rc1 is now ready! In-Reply-To: References: Message-ID: On Fri, Jun 5, 2015 at 9:03 AM, Robert Maynard wrote: ... > > * The "Visual Studio 7" generator (.NET 2002) is now deprecated and > will be removed in a future version of CMake. > > * The "Visual Studio 6" generator is now deprecated and will be > removed in a future version of CMake. > ... Awesome. Congratulations on jettisoning the old dead weight. No need to carry albatross around our necks like that... By "future version" might you mean v3.3.0-rc2 ...? ;-) D From dank at kegel.com Fri Jun 5 14:32:26 2015 From: dank at kegel.com (Dan Kegel) Date: Fri, 5 Jun 2015 11:32:26 -0700 Subject: [CMake] add_custom_command and visual c++ only running first command? Message-ID: I was using add_custom_command to execute three commands, triggering that rule with add_custom_target, and it worked great with make and ninja on linux and mac. Over on Windows, though, with visual c++ 2013 and cmake 3.0.1, only the first of the three commands was executed. After much head-scratching, I junked the add_custom_targets, and just used add_custom_target, since the commands were supposed to be unconditional anyway. (Why'd I use add_custom_command in the first place?) That seemed to work better. (I also moved the three commands out into a script, which may also have helped.) Has anyone else had problems with add_custom_command being squirrely with visual c++? From dlahouss at mtu.edu Fri Jun 5 15:34:39 2015 From: dlahouss at mtu.edu (Derek LaHousse) Date: Fri, 5 Jun 2015 15:34:39 -0400 Subject: [CMake] Errors trying to cross-compile Icinga2, which uses CMake Message-ID: Hello, CMake users. I'm running into an error trying to cross-compile Icinga2 for OpenWRT. The root of this issue is that there are helper programs compiled to help complete the compilation (I believe these are called generators). I have understood that I can compile on my native system, then somehow use imports/exports to get the programs able to be used on the cross-compile. However, I'm getting an error message: make[5]: *** No rule to make target 'lib/base/mkunity', needed by 'lib/base/base_unity.cpp'. Stop. mkunity is one of these compiled programs, and in a native compile, ends up in Bin/Release/mkunity . I have pasted the CMakeLists.txt, ImportExecutables.txt to pastebin. http://pastebin.com/ybnrDP9M The reference I found for this course of action was http://www.vtk.org/Wiki/CMake_Cross_Compiling Thank you for any help you can render. Derek From fifteenknots505 at gmail.com Fri Jun 5 15:47:50 2015 From: fifteenknots505 at gmail.com (Martin Weber) Date: Fri, 05 Jun 2015 21:47:50 +0200 Subject: [CMake] Eclipse .cproject Preprocessor Macro Definitions In-Reply-To: <2A375B5C08C24643A8A3F8CC2B98C1084BAD4AB3@USINDPR-MBX003.Rolls-Royce.Local> References: <2A375B5C08C24643A8A3F8CC2B98C1084BAC0C53@USINDPR-MBX003.Rolls-Royce.Local> <5152066.l9u29SKOmL@linux> <2A375B5C08C24643A8A3F8CC2B98C1084BAD4AB3@USINDPR-MBX003.Rolls-Royce.Local> Message-ID: <2085223.PAk1FZaBeM@linux> Am Donnerstag, 4. Juni 2015, 15:53:11 schrieb Ette, Anthony: > Ok I've got this installed but can't get it to work. I've selected the Please discuss this on the appropriate mailing list. https://groups.google.com/forum/#!forum/cmake4eclipse-users Martin -- Cd wrttn wtht vwls s mch trsr. From helios.corona at gmail.com Fri Jun 5 21:37:02 2015 From: helios.corona at gmail.com (Sunrise) Date: Fri, 05 Jun 2015 18:37:02 -0700 Subject: [CMake] undefined reference to error when use "c" extension Message-ID: <55724EBE.1030209@gmail.com> Hello, I am linking my code to a library. My code is in C++ but the library is in C. The problem is that whenever the extension of library implementations are "c" (not cpp), they are not linked and I get "undefined reference to" error. Here is an example: Suppose I have ./src/main.cpp // as main file ./include/lib.h ./include/lib.c // as a library And the cmake file is cmake_minimum_required(VERSION 2.8) project(myproj) set(INCLUDE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/include) include_directories(${INCLUDE_DIR}) add_library(MY_LIB ${INCLUDE_DIR}/Lib.c) set(EXECUTABLE_NAME "myproj") set(SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/src) add_executable(myproj ${SOURCE_DIR}/main.cpp) target_link_libraries(myproj MY_LIB) This returns undefined reference to error, but if I rename lib.c to lib.cpp, everything works fine. How can I resolve this? I do not want to rename the file to cpp, because there are a lot of library files and I prefer to keep the library implementations untouched. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Fri Jun 5 22:33:45 2015 From: d3ck0r at gmail.com (J Decker) Date: Fri, 5 Jun 2015 19:33:45 -0700 Subject: [CMake] undefined reference to error when use "c" extension In-Reply-To: <55724EBE.1030209@gmail.com> References: <55724EBE.1030209@gmail.com> Message-ID: c++ does name mangling on functions... so functions like 'f' become a much more complex name (as shown in the xxx not found in your error messages). In order for C++ to not produce a mangled name C functions have to be defined as extern "c" void f( void ); but 'extern "c"' is not liked by C... so you really need to define in the shared header something like... #ifdef __cplusplus #define CEXTERN extern "C" #ese #define CEXTERN #endif CEXTERN void f( void ); But of course since you don't know about name mangling I guess you don't know proper header usage either. This is not a cmake issue, but a general C++ issue... and you'd do better asking stack exchange or something. On Fri, Jun 5, 2015 at 6:37 PM, Sunrise wrote: > Hello, > > I am linking my code to a library. My code is in C++ but the library is in > C. > > The problem is that whenever the extension of library implementations are " > c" (not cpp), they are not linked and I get "undefined reference to" > error. > > Here is an example: > > Suppose I have > ./src/main.cpp // as main file > ./include/lib.h > ./include/lib.c // as a library > > And the cmake file is > > cmake_minimum_required(VERSION 2.8) > project(myproj) > > set(INCLUDE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/include) > include_directories(${INCLUDE_DIR}) > add_library(MY_LIB ${INCLUDE_DIR}/Lib.c) > > set(EXECUTABLE_NAME "myproj") > set(SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/src) > add_executable(myproj ${SOURCE_DIR}/main.cpp) > > target_link_libraries(myproj MY_LIB) > > This returns undefined reference to error, but if I rename lib.c to > lib.cpp, everything works fine. > > How can I resolve this? I do not want to rename the file to cpp, because > there are a lot of library files and I prefer to keep the library > implementations untouched. > > Thanks. > > -- > > 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 helios.corona at gmail.com Fri Jun 5 22:42:34 2015 From: helios.corona at gmail.com (Sunrise) Date: Fri, 05 Jun 2015 19:42:34 -0700 Subject: [CMake] undefined reference to error when use "c" extension In-Reply-To: References: <55724EBE.1030209@gmail.com> Message-ID: <55725E1A.4020606@gmail.com> Thanks for your reply. I am aware of extern "C" {} but this is not an option for me. As I mentioned, there are a lot of lib files (which were not written by me) and I was wondering if lib itself could be untouched. On 06/05/2015 07:33 PM, J Decker wrote: > c++ does name mangling on functions... so functions like 'f' become a > much more complex name (as shown in the xxx not found in your error > messages). > In order for C++ to not produce a mangled name C functions have to be > defined as > > extern "c" void f( void ); > but 'extern "c"' is not liked by C... so you really need to define in > the shared header something like... > > #ifdef __cplusplus > #define CEXTERN extern "C" > #ese > #define CEXTERN > #endif > > CEXTERN void f( void ); > > But of course since you don't know about name mangling I guess you > don't know proper header usage either. This is not a cmake issue, but > a general C++ issue... and you'd do better asking stack exchange or > something. > > On Fri, Jun 5, 2015 at 6:37 PM, Sunrise > wrote: > > Hello, > > I am linking my code to a library. My code is in C++ but the > library is in C. > > The problem is that whenever the extension of library > implementations are "c" (not cpp), they are not linked and I get > "undefined reference to" error. > > Here is an example: > > Suppose I have > ./src/main.cpp // as main file > ./include/lib.h > ./include/lib.c // as a library > > And the cmake file is > > cmake_minimum_required(VERSION 2.8) > project(myproj) > > set(INCLUDE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/include) > include_directories(${INCLUDE_DIR}) > add_library(MY_LIB ${INCLUDE_DIR}/Lib.c) > > set(EXECUTABLE_NAME "myproj") > set(SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/src) > add_executable(myproj ${SOURCE_DIR}/main.cpp) > > target_link_libraries(myproj MY_LIB) > > This returns undefined reference to error, but if I rename lib.c > to lib.cpp, everything works fine. > > How can I resolve this? I do not want to rename the file to cpp, > because there are a lot of library files and I prefer to keep the > library implementations untouched. > > Thanks. > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. > For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Fri Jun 5 22:44:57 2015 From: d3ck0r at gmail.com (J Decker) Date: Fri, 5 Jun 2015 19:44:57 -0700 Subject: [CMake] undefined reference to error when use "c" extension In-Reply-To: <55725E1A.4020606@gmail.com> References: <55724EBE.1030209@gmail.com> <55725E1A.4020606@gmail.com> Message-ID: it's not the lib, it's the header interface to the lib. On Fri, Jun 5, 2015 at 7:42 PM, Sunrise wrote: > Thanks for your reply. I am aware of extern "C" {} but this is not an > option for me. As I mentioned, there are a lot of lib files (which were not > written by me) and I was wondering if lib itself could be untouched. > > > On 06/05/2015 07:33 PM, J Decker wrote: > > c++ does name mangling on functions... so functions like 'f' become a much > more complex name (as shown in the xxx not found in your error messages). > In order for C++ to not produce a mangled name C functions have to be > defined as > > extern "c" void f( void ); > but 'extern "c"' is not liked by C... so you really need to define in the > shared header something like... > > #ifdef __cplusplus > #define CEXTERN extern "C" > #ese > #define CEXTERN > #endif > > CEXTERN void f( void ); > > But of course since you don't know about name mangling I guess you don't > know proper header usage either. This is not a cmake issue, but a general > C++ issue... and you'd do better asking stack exchange or something. > > On Fri, Jun 5, 2015 at 6:37 PM, Sunrise wrote: > >> Hello, >> >> I am linking my code to a library. My code is in C++ but the library is >> in C. >> >> The problem is that whenever the extension of library implementations are >> "c" (not cpp), they are not linked and I get "undefined reference to" >> error. >> >> Here is an example: >> >> Suppose I have >> ./src/main.cpp // as main file >> ./include/lib.h >> ./include/lib.c // as a library >> >> And the cmake file is >> >> cmake_minimum_required(VERSION 2.8) >> project(myproj) >> >> set(INCLUDE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/include) >> include_directories(${INCLUDE_DIR}) >> add_library(MY_LIB ${INCLUDE_DIR}/Lib.c) >> >> set(EXECUTABLE_NAME "myproj") >> set(SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/src) >> add_executable(myproj ${SOURCE_DIR}/main.cpp) >> >> target_link_libraries(myproj MY_LIB) >> >> This returns undefined reference to error, but if I rename lib.c to >> lib.cpp, everything works fine. >> >> How can I resolve this? I do not want to rename the file to cpp, because >> there are a lot of library files and I prefer to keep the library >> implementations untouched. >> >> Thanks. >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Fri Jun 5 22:47:39 2015 From: d3ck0r at gmail.com (J Decker) Date: Fri, 5 Jun 2015 19:47:39 -0700 Subject: [CMake] undefined reference to error when use "c" extension In-Reply-To: References: <55724EBE.1030209@gmail.com> <55725E1A.4020606@gmail.com> Message-ID: Or make c++ wrappers that use dlopen/dlsym or loadlibrary/getprocaddress as appropriate and reference the libs through an interface class. On Fri, Jun 5, 2015 at 7:44 PM, J Decker wrote: > it's not the lib, it's the header interface to the lib. > > On Fri, Jun 5, 2015 at 7:42 PM, Sunrise wrote: > >> Thanks for your reply. I am aware of extern "C" {} but this is not an >> option for me. As I mentioned, there are a lot of lib files (which were not >> written by me) and I was wondering if lib itself could be untouched. >> >> >> On 06/05/2015 07:33 PM, J Decker wrote: >> >> c++ does name mangling on functions... so functions like 'f' become a >> much more complex name (as shown in the xxx not found in your error >> messages). >> In order for C++ to not produce a mangled name C functions have to be >> defined as >> >> extern "c" void f( void ); >> but 'extern "c"' is not liked by C... so you really need to define in the >> shared header something like... >> >> #ifdef __cplusplus >> #define CEXTERN extern "C" >> #ese >> #define CEXTERN >> #endif >> >> CEXTERN void f( void ); >> >> But of course since you don't know about name mangling I guess you >> don't know proper header usage either. This is not a cmake issue, but a >> general C++ issue... and you'd do better asking stack exchange or something. >> >> On Fri, Jun 5, 2015 at 6:37 PM, Sunrise wrote: >> >>> Hello, >>> >>> I am linking my code to a library. My code is in C++ but the library is >>> in C. >>> >>> The problem is that whenever the extension of library implementations >>> are "c" (not cpp), they are not linked and I get "undefined reference to" >>> error. >>> >>> Here is an example: >>> >>> Suppose I have >>> ./src/main.cpp // as main file >>> ./include/lib.h >>> ./include/lib.c // as a library >>> >>> And the cmake file is >>> >>> cmake_minimum_required(VERSION 2.8) >>> project(myproj) >>> >>> set(INCLUDE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/include) >>> include_directories(${INCLUDE_DIR}) >>> add_library(MY_LIB ${INCLUDE_DIR}/Lib.c) >>> >>> set(EXECUTABLE_NAME "myproj") >>> set(SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/src) >>> add_executable(myproj ${SOURCE_DIR}/main.cpp) >>> >>> target_link_libraries(myproj MY_LIB) >>> >>> This returns undefined reference to error, but if I rename lib.c to >>> lib.cpp, everything works fine. >>> >>> How can I resolve this? I do not want to rename the file to cpp, >>> because there are a lot of library files and I prefer to keep the library >>> implementations untouched. >>> >>> Thanks. >>> >>> -- >>> >>> 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 greg.marr at autodesk.com Fri Jun 5 23:55:49 2015 From: greg.marr at autodesk.com (Greg Marr) Date: Sat, 6 Jun 2015 03:55:49 +0000 Subject: [CMake] undefined reference to error when use "c" extension In-Reply-To: References: <55724EBE.1030209@gmail.com>, Message-ID: If you are including the .h file for the .c file in your .cpp file and it doesn't already have extern "C" in it, wrapping it like this when including it in your cpp should help: extern "C" { #include "header.h" } Sent from my Verizon Wireless 4G LTE smartphone -------- Original message -------- From: J Decker Date: 06/05/2015 10:33 PM (GMT-05:00) To: Sunrise Cc: cmake at cmake.org Subject: Re: [CMake] undefined reference to error when use "c" extension c++ does name mangling on functions... so functions like 'f' become a much more complex name (as shown in the xxx not found in your error messages). In order for C++ to not produce a mangled name C functions have to be defined as extern "c" void f( void ); but 'extern "c"' is not liked by C... so you really need to define in the shared header something like... #ifdef __cplusplus #define CEXTERN extern "C" #ese #define CEXTERN #endif CEXTERN void f( void ); But of course since you don't know about name mangling I guess you don't know proper header usage either. This is not a cmake issue, but a general C++ issue... and you'd do better asking stack exchange or something. On Fri, Jun 5, 2015 at 6:37 PM, Sunrise > wrote: Hello, I am linking my code to a library. My code is in C++ but the library is in C. The problem is that whenever the extension of library implementations are "c" (not cpp), they are not linked and I get "undefined reference to" error. Here is an example: Suppose I have ./src/main.cpp // as main file ./include/lib.h ./include/lib.c // as a library And the cmake file is cmake_minimum_required(VERSION 2.8) project(myproj) set(INCLUDE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/include) include_directories(${INCLUDE_DIR}) add_library(MY_LIB ${INCLUDE_DIR}/Lib.c) set(EXECUTABLE_NAME "myproj") set(SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/src) add_executable(myproj ${SOURCE_DIR}/main.cpp) target_link_libraries(myproj MY_LIB) This returns undefined reference to error, but if I rename lib.c to lib.cpp, everything works fine. How can I resolve this? I do not want to rename the file to cpp, because there are a lot of library files and I prefer to keep the library implementations untouched. Thanks. -- 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 alexey.petruchik at gmail.com Sun Jun 7 13:44:38 2015 From: alexey.petruchik at gmail.com (Alexey Petruchik) Date: Sun, 7 Jun 2015 20:44:38 +0300 Subject: [CMake] Visual Studio Project System Extensibilty Message-ID: Microsoft recently announced Project System Extensibility in Visual Studio 2015. http://blogs.msdn.com/b/visualstudio/archive/2015/06/02/introducing-the-project-system-extensibility-sdk-preview.aspx Just curious if this can be used to let Visual Studio directly open CMake projects? -------------- next part -------------- An HTML attachment was scrubbed... URL: From golubdr at gmail.com Sun Jun 7 18:27:52 2015 From: golubdr at gmail.com (David Golub) Date: Sun, 7 Jun 2015 18:27:52 -0400 Subject: [CMake] Visual Studio Project System Extensibilty In-Reply-To: References: Message-ID: <008701d0a171$31e741c0$95b5c540$@gmail.com> Probably doable but still a lot of work. It took me about a year over my nights and weekends to implement CMake Tools for Visual Studio, which provides syntax highlighting and IntelliSense for CMake but no project system (yet). From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Alexey Petruchik Sent: Sunday, June 07, 2015 1:45 PM To: cmake at cmake.org Subject: [CMake] Visual Studio Project System Extensibilty Microsoft recently announced Project System Extensibility in Visual Studio 2015. http://blogs.msdn.com/b/visualstudio/archive/2015/06/02/introducing-the-project-system-extensibility-sdk-preview.aspx Just curious if this can be used to let Visual Studio directly open CMake projects? -------------- next part -------------- An HTML attachment was scrubbed... URL: From pengyu.ut at gmail.com Sun Jun 7 18:39:39 2015 From: pengyu.ut at gmail.com (Peng Yu) Date: Sun, 7 Jun 2015 17:39:39 -0500 Subject: [CMake] How to choose a compiler different from default? Message-ID: Hi, I following the following steps to compile gtest. https://code.google.com/p/tonatiuh/wiki/GoogleTest But the following output shows that it uses the default compiler on Mac OS X. I want to use some other compiler. Does anybody know how to instruct cmake to do so? Thanks. /tmp/gtest-1.7.0/mybuild$ cmake -G"Unix Makefiles" .. -- The CXX compiler identification is AppleClang 6.0.0.6000057 -- The C compiler identification is AppleClang 6.0.0.6000057 -- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Found PythonInterp: /Library/Frameworks/Python.framework/Versions/2.7/bin/python (found version "2.7.8") -- Looking for include file pthread.h -- Looking for include file pthread.h - found -- Looking for pthread_create -- Looking for pthread_create - found -- Found Threads: TRUE -- Configuring done -- Generating done -- Build files have been written to: /tmp/gtest-1.7.0/mybuild /tmp/gtest-1.7.0/mybuild$ make VERBOSE=1 /usr/local/Cellar/cmake/3.2.2/bin/cmake -H/tmp/gtest-1.7.0 -B/tmp/gtest-1.7.0/mybuild --check-build-system CMakeFiles/Makefile.cmake 0 /usr/local/Cellar/cmake/3.2.2/bin/cmake -E cmake_progress_start /tmp/gtest-1.7.0/mybuild/CMakeFiles /tmp/gtest-1.7.0/mybuild/CMakeFiles/progress.marks /Applications/Xcode.app/Contents/Developer/usr/bin/make -f CMakeFiles/Makefile2 all /Applications/Xcode.app/Contents/Developer/usr/bin/make -f CMakeFiles/gtest.dir/build.make CMakeFiles/gtest.dir/depend cd /tmp/gtest-1.7.0/mybuild && /usr/local/Cellar/cmake/3.2.2/bin/cmake -E cmake_depends "Unix Makefiles" /tmp/gtest-1.7.0 /tmp/gtest-1.7.0 /tmp/gtest-1.7.0/mybuild /tmp/gtest-1.7.0/mybuild /tmp/gtest-1.7.0/mybuild/CMakeFiles/gtest.dir/DependInfo.cmake --color= Dependee "/tmp/gtest-1.7.0/mybuild/CMakeFiles/gtest.dir/DependInfo.cmake" is newer than depender "/tmp/gtest-1.7.0/mybuild/CMakeFiles/gtest.dir/depend.internal". Dependee "/tmp/gtest-1.7.0/mybuild/CMakeFiles/CMakeDirectoryInformation.cmake" is newer than depender "/tmp/gtest-1.7.0/mybuild/CMakeFiles/gtest.dir/depend.internal". Scanning dependencies of target gtest /Applications/Xcode.app/Contents/Developer/usr/bin/make -f CMakeFiles/gtest.dir/build.make CMakeFiles/gtest.dir/build /usr/local/Cellar/cmake/3.2.2/bin/cmake -E cmake_progress_report /tmp/gtest-1.7.0/mybuild/CMakeFiles 1 [ 50%] Building CXX object CMakeFiles/gtest.dir/src/gtest-all.cc.o /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -I/tmp/gtest-1.7.0/include -I/tmp/gtest-1.7.0 -DGTEST_HAS_PTHREAD=1 -o CMakeFiles/gtest.dir/src/gtest-all.cc.o -c /tmp/gtest-1.7.0/src/gtest-all.cc Linking CXX static library libgtest.a /usr/local/Cellar/cmake/3.2.2/bin/cmake -P CMakeFiles/gtest.dir/cmake_clean_target.cmake /usr/local/Cellar/cmake/3.2.2/bin/cmake -E cmake_link_script CMakeFiles/gtest.dir/link.txt --verbose=1 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ar cq libgtest.a CMakeFiles/gtest.dir/src/gtest-all.cc.o /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib libgtest.a /usr/local/Cellar/cmake/3.2.2/bin/cmake -E cmake_progress_report /tmp/gtest-1.7.0/mybuild/CMakeFiles 1 [ 50%] Built target gtest /Applications/Xcode.app/Contents/Developer/usr/bin/make -f CMakeFiles/gtest_main.dir/build.make CMakeFiles/gtest_main.dir/depend cd /tmp/gtest-1.7.0/mybuild && /usr/local/Cellar/cmake/3.2.2/bin/cmake -E cmake_depends "Unix Makefiles" /tmp/gtest-1.7.0 /tmp/gtest-1.7.0 /tmp/gtest-1.7.0/mybuild /tmp/gtest-1.7.0/mybuild /tmp/gtest-1.7.0/mybuild/CMakeFiles/gtest_main.dir/DependInfo.cmake --color= Dependee "/tmp/gtest-1.7.0/mybuild/CMakeFiles/gtest_main.dir/DependInfo.cmake" is newer than depender "/tmp/gtest-1.7.0/mybuild/CMakeFiles/gtest_main.dir/depend.internal". Dependee "/tmp/gtest-1.7.0/mybuild/CMakeFiles/CMakeDirectoryInformation.cmake" is newer than depender "/tmp/gtest-1.7.0/mybuild/CMakeFiles/gtest_main.dir/depend.internal". Scanning dependencies of target gtest_main /Applications/Xcode.app/Contents/Developer/usr/bin/make -f CMakeFiles/gtest_main.dir/build.make CMakeFiles/gtest_main.dir/build /usr/local/Cellar/cmake/3.2.2/bin/cmake -E cmake_progress_report /tmp/gtest-1.7.0/mybuild/CMakeFiles 2 [100%] Building CXX object CMakeFiles/gtest_main.dir/src/gtest_main.cc.o /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -I/tmp/gtest-1.7.0/include -I/tmp/gtest-1.7.0 -DGTEST_HAS_PTHREAD=1 -o CMakeFiles/gtest_main.dir/src/gtest_main.cc.o -c /tmp/gtest-1.7.0/src/gtest_main.cc Linking CXX static library libgtest_main.a /usr/local/Cellar/cmake/3.2.2/bin/cmake -P CMakeFiles/gtest_main.dir/cmake_clean_target.cmake /usr/local/Cellar/cmake/3.2.2/bin/cmake -E cmake_link_script CMakeFiles/gtest_main.dir/link.txt --verbose=1 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ar cq libgtest_main.a CMakeFiles/gtest_main.dir/src/gtest_main.cc.o /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib libgtest_main.a /usr/local/Cellar/cmake/3.2.2/bin/cmake -E cmake_progress_report /tmp/gtest-1.7.0/mybuild/CMakeFiles 2 [100%] Built target gtest_main /usr/local/Cellar/cmake/3.2.2/bin/cmake -E cmake_progress_start /tmp/gtest-1.7.0/mybuild/CMakeFiles 0 -- Regards, Peng From vini.ipsmaker at gmail.com Sun Jun 7 23:37:30 2015 From: vini.ipsmaker at gmail.com (=?UTF-8?Q?Vin=C3=ADcius_dos_Santos_Oliveira?=) Date: Mon, 8 Jun 2015 00:37:30 -0300 Subject: [CMake] ctest --output-on-failure doesn't work Message-ID: According to the documentation[1], the --output-on-failure argument will instruct ctest to show the tests output when they fail. A second approach is to set the env var CTEST_OUTPUT_ON_FAILURE. Neither option work for me. As you can see on appveyor[2], some tests fail, but no output is given. On GNU/Linux, setting the CTEST_OUTPUT_ON_FAILURE does work for me. The CMake configuration files I used are publicly available and there is no magic in their contents: https://github.com/vinipsmaker/asiohttpserver/tree/travis [1] http://www.cmake.org/cmake/help/v3.3/manual/ctest.1.html [2] https://ci.appveyor.com/project/vinipsmaker/boost-http/build/1.0.63/job/71vy3hxrx9clstju#L1028 -- Vin?cius dos Santos Oliveira https://about.me/vinipsmaker -------------- next part -------------- An HTML attachment was scrubbed... URL: From sina_11235 at yahoo.com Mon Jun 8 02:48:05 2015 From: sina_11235 at yahoo.com (sina Tavakoli) Date: Mon, 8 Jun 2015 06:48:05 +0000 (UTC) Subject: [CMake] CMake to find path to a file which its name contains a certain string Message-ID: <822136776.8312837.1433746085143.JavaMail.yahoo@mail.yahoo.com> So I am writing a CMake module to find some libraries which is being used a lot in our company. These libraries all have different versions and are such a mess here. In a certain library, even the name of header files and binary files don't match. So I am writing a CMake script to handle all the problems of finding each library once and for all. What I have in my mind is to write something like how we find boost packages but include the version of each component as well. Something like this:find_package(OrgName COMPONENTS librarya-1.4.3 libraryb-2.3.1 libraryc-3.6.0)So I created a FindOrgName.cmake file and iterated on the requested components, then I processed the string which is passed and gained the library name along with its version information something like this (never mind the difference between include and binary files):IF(OrgName_FIND_COMPONENTS) FOREACH(comp ${OrgName_FIND_COMPONENTS}) SET(OrgName_${comp}_FOUND 0) STRING(FIND ${comp} "-" dashind REVERSE) STRING(LENGTH ${comp} length) STRING(SUBSTRING ${comp} 0 ${dashind} name) MATH(EXPR s "${dashind}+1") MATH(EXPR l "${length}-${dashind}-1") STRING(SUBSTRING ${comp} ${s} ${l} version) SET(OrgName_${name}_INCLUDE_DIR "/usr/local/include/OrgName/${comp}/") find_library(OrgName_${comp}_LIBRARIES NAMES "${comp}" HINTS "/usr/lib") IF(OrgName_${comp}_INCLUDE_DIR AND OrgName_${comp}_LIBRARIES) SET(OrgName_${comp}_FOUND 1) ENDIF() IF(NOT OrgName_${comp}_FOUND AND OrgName_FIND_REQUIRED_${comp}) MESSAGE(FATAL_ERROR "OrgName ${comp} not available.") ENDIF() SET (OrgName_INCLUDE_DIR ${OrgName_INCLUDE_DIR} ${OrgName_${comp}_INCLUDE_DIR}) SET (OrgName_LIBRARIES ${OrgName_LIBRARIES} ${OrgName_${comp}_LIBRARIES}) ENDFOREACH() ENDIF() Now here is the problem, imagine someone didn't enter the version part in components names. I want to search for the versions which he has installed (assume the path to library is always the same) and use the last version it can find, so I have to search for the files which their name contains the library name (${name}). First of all how can I do this? Second, Am I doing things right? I mean is there an easier way to do this task? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.jackson at bluequartz.net Mon Jun 8 10:52:26 2015 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Mon, 8 Jun 2015 10:52:26 -0400 Subject: [CMake] [ANNOUNCE] CMake 3.3.0-rc1 is now ready! In-Reply-To: References: Message-ID: <0fa601d0a1fa$bd3f42c0$37bdc840$@bluequartz.net> We are very interested in using the "include-what-you-use" functionality. Is there a wiki page or something that can help us get all the dependencies setup, compiled and working. Thanks Mike Jackson -----Original Message----- From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Robert Maynard Sent: Friday, June 5, 2015 9:03 AM To: CMake MailingList Subject: [CMake] [ANNOUNCE] CMake 3.3.0-rc1 is now ready! I am proud to announce the first CMake 3.3 release candidate. Sources and binaries are available at: http://www.cmake.org/download/ Documentation is available at: http://www.cmake.org/cmake/help/v3.3 Release notes appear below and are also published at http://www.cmake.org/cmake/help/v3.3/release/3.3.html Some of the more significant features of CMake 3.3 are: * The "if()" command learned a new "IN_LIST" operator that evaluates to true if a given element is contained in a named list. * The "add_dependencies()" command learned to allow dependencies to be added to *interface libraries*. Dependencies added to an interface library are followed transitively in its place since the target itself does not build. * The "find_library()", "find_path()", and "find_file()" commands now search in installation prefixes derived from the "PATH" environment variable. * The "_VISIBILITY_PRESET" and "VISIBILITY_INLINES_HIDDEN" target properties now affect compilation in sources of all target types. See policy "CMP0063". * A "_INCLUDE_WHAT_YOU_USE" target property and supporting "CMAKE__INCLUDE_WHAT_YOU_USE" variable were introduced to tell the *Makefile Generators* and the "Ninja" generator to run "include- what-you-use" along with the compiler for "C" and "CXX" languages. Deprecated and Removed Features: * The "ctest_build()" and "build_command()" commands no longer tell "make" tools to ignore errors with the "-i" option. Previously this was done for *Makefile Generators* but not others. See policy "CMP0061". * The "Visual Studio 7" generator (.NET 2002) is now deprecated and will be removed in a future version of CMake. * The "Visual Studio 6" generator is now deprecated and will be removed in a future version of CMake. * The "add_definitions()" command no longer causes a "DEFINITIONS" directory property to be populated. See policy "CMP0059". CMake 3.3 Release Notes *********************** Changes made since CMake 3.2 include the following. New Features ============ Generators ---------- * The *Makefile Generators* now add ".DELETE_ON_ERROR" to the makefiles that contain the actual build rules for files on disk. This tells GNU make to remove rule outputs when their recipe modifies an output but fails. * The *Visual Studio Generators* learned to support ".xaml" source files and automatically associate them with corresponding ".h" and ".cpp" sources. * A new experimental "Green Hills MULTI" generator was added on Windows. Green Hills MULTI is an IDE for embedded real-time systems. Commands -------- * The "add_dependencies()" command learned to allow dependencies to be added to *interface libraries*. Dependencies added to an interface library are followed transitively in its place since the target itself does not build. * The "execute_process()" command learned to support specifying the same file for "OUTPUT_FILE" and "ERROR_FILE". * The "file(GLOB)" and "file(GLOB_RECURSE)" commands learned a new "LIST_DIRECTORIES " option to specify whether the glob result should include directories. * The "find_library()", "find_path()", and "find_file()" commands now search in installation prefixes derived from the "PATH" environment variable. * The "if()" command learned a new "IN_LIST" operator that evaluates to true if a given element is contained in a named list. * The "install(EXPORT)" and "export()" commands learned to export targets that populate the "INTERFACE_SOURCES" target property. * The "install(TARGETS)" command learned to support generator expressions in the "DESTINATION" value. Variables --------- * The version of some Fortran compilers is now detected and stored in the "CMAKE_Fortran_COMPILER_VERSION" variable. * The *Visual Studio Generators* learned a new "CMAKE_VS_INCLUDE_INSTALL_TO_DEFAULT_BUILD" option to put the "INSTALL" target in the default build of a solution (".sln") file. Properties ---------- * A "CROSSCOMPILING_EMULATOR" target property and supporting "CMAKE_CROSSCOMPILING_EMULATOR" variable were introduced to allow target platform binaries to run on the host during cross compiling. * A "_INCLUDE_WHAT_YOU_USE" target property and supporting "CMAKE__INCLUDE_WHAT_YOU_USE" variable were introduced to tell the *Makefile Generators* and the "Ninja" generator to run "include- what-you-use" along with the compiler for "C" and "CXX" languages. * The "_VISIBILITY_PRESET" and "VISIBILITY_INLINES_HIDDEN" target properties now affect compilation in sources of all target types. See policy "CMP0063". * The "XCODE_ATTRIBUTE_" target property learned to support generator expressions. Modules ------- * The "CheckFortranCompilerFlag" module was introduced to check "Fortran" compiler flags, much like the "CheckCCompilerFlag" module already does for "C". * The "ExternalData" module learned a new "ExternalData_NO_SYMLINKS" option to disable use of symbolic links to populate the real data files and use copies instead. * The "ExternalData" module learned a new "RECURSE:" option in "DATA{}" references specifying directories. This allows an entire directory tree of associated files to be matched. * The "ExternalData" module learned a new URL template placeholder "%(algo:)" to allow custom mapping from algorithm name to URL component through configuration of new "ExternalData_URL_ALGO__" variables. This allows more flexibility in remote URLs. * The "ExternalProject" module learned to replace tokens like "" in the "BYPRODUCTS" of each step. * The "ExternalProject" module APIs learned to support "generator expressions" when using "LOG_*" options and in CMake initial cache options. * The "FindBoost" module now tracks the directories containing libraries separately for RELEASE and DEBUG configurations. * The "FindCUDA" module now defaults to using the static CUDA runtime library if it is available. A new "CUDA_USE_STATIC_CUDA_RUNTIME" option is offered to control this behavior. * The "FindMatlab" module was completely rewritten. It learned about versions and components and to find Matlab in a more precise and multiplatform way. The module now offers APIs to create mex extensions, documentation, and unit tests. * The "FindPackageHandleStandardArgs" module "FIND_PACKAGE_HANDLE_STANDARD_ARGS" function now always populates both the "_FOUND" and "_FOUND" variables (the latter for backwards compatibility). The "FOUND_VAR" option is now ignored except to enforce its allowed values. * The "InstallRequiredSystemLibraries" module learned a new "CMAKE_INSTALL_SYSTEM_RUNTIME_COMPONENT" option to specify the installation component. Generator Expressions --------------------- * A new "COMPILE_LANGUAGE" generator expression was introduced to allow specification of compile options for target files based on the "LANGUAGE" of each source file. Due to limitations of the underlying native build tools, this feature has varying support across generators. See the "cmake-generator-expressions(7)" manual for details. CTest ----- * The "ctest(1)" tool learned a new "--repeat-until-fail " option to help find sporadic test failures. * The "CTestCoverageCollectGCOV" module learned to support the same "CTEST_CUSTOM_COVERAGE_EXCLUDE" option as the "ctest_coverage()" command. CPack ----- * The "cpack(1)" "IFW" generator and the "CPackIFW" module learned to support Qt Framework Installer 2.0 tools. * The "CPackDeb" module learned a new "CPACK_DEBIAN__PACKAGE_SHLIBDEPS" variable to specify per-component use of "dpkg-shlibdeps". * The "CPackDeb" module learned a new "CPACK_DEBIAN__PACKAGE_DEPENDS" option to specify per- component dependencies. * The "CPackRPM" module learned to package symbolic links more cleanly and now supports directory symlinks with recent "rpmbuild" versions. * The "CPackRPM" module learned a new "CPACK_RPM_ADDITIONAL_MAN_DIRS" variable to specify directories containing man pages for the brp- compress RPM macro. * The "CPackRPM" module learned a new "CPACK_RPM__PACKAGE_ARCHITECTURE" variable to specify a component-specific package architecture. * The CPack WIX generator learned the new "CPACK_START_MENU_SHORTCUTS", "CPACK_DESKTOP_SHORTCUTS" and "CPACK_STARTUP_SHORTCUTS" installed file properties which can be used to install shorcuts in the Start Menu, on the Desktop and in the Startup Folder respectively. Other ----- * The "Compile Features" functionality is now aware of features supported by GNU compilers on Windows, versions 4.4 through 5.0. * The "cmake(1)" "-E tar" command learned a new "--format" option to specify the archive format to be written. * On OS X, CMake learned to create XCTest bundles to test Frameworks and App Bundles within Xcode. The "FindXCTest" module provides convenience functions to handle "XCTEST" bundles. Deprecated and Removed Features =============================== * On OS X the "cmake-gui(1)" no longer has the "Install For Command Line Use" menu item. Instead there is a "How to Install For Command Line Use" menu item that shows an informational dialog box explaining how to make the command line tools available. For example: /Applications/CMake.app/Contents/bin/cmake-gui --install * The "ctest_build()" and "build_command()" commands no longer tell "make" tools to ignore errors with the "-i" option. Previously this was done for *Makefile Generators* but not others. See policy "CMP0061". * The "Visual Studio 10 2010" generator no longer checks for running VS IDEs with the project open or asks them to reload. This was originally done for VS 10 because it had been done for VS 7 through 9 to avoid prompting for every project in a solution. Since VS >= 10 allow the whole solution to reload at once they do not need CMake to help them. * The "Visual Studio 7" generator (.NET 2002) is now deprecated and will be removed in a future version of CMake. * The "Visual Studio 6" generator is now deprecated and will be removed in a future version of CMake. * The "find_package()" command no longer considers project build trees recently configured in a "cmake-gui(1)". This was previously done only on Windows and is now never done. The "NO_CMAKE_BUILDS_PATH" option is now ignored if given and effectively always on. Projects may populate the *User Package Registry* to aid users building multiple dependent projects one after another. * When building with GNU tools on Windows (MinGW tools), the "find_library()" command will no longer consider ".dll" files to be linkable libraries. All dynamic link libraries are expected to provide separate ".dll.a" or ".lib" import libraries. * The "add_definitions()" command no longer causes a "DEFINITIONS" directory property to be populated. See policy "CMP0059". * With Visual Studio 7, 8, and 9 generators the value of the "$(OutDir)" placeholder no longer evaluates to the configuration name. Projects should use "$(ConfigurationName)" for that instead. * Using the output of "export()" with the "install(FILES)" command is no longer allowed. See policy "CMP0062" for details. Other Changes ============= * The "Ninja" generator now requires that calls to the "add_custom_command()" and "add_custom_target()" commands use the "BYPRODUCTS" option to explicitly specify any files generated by the custom commands that are not listed as outputs (perhaps because their timestamps are allowed to be older than the inputs). See policy "CMP0058". * Build-time progress output of *Makefile Generators* has been improved. It no longer mixes progress and build rule messages during parallel builds. The link rule messages now have progress and are displayed as bold green instead of bold red (since red is often associated with an error message). * The "CMAKE_CFG_INTDIR" variable value for Visual Studio 7, 8, and 9 is now "$(ConfigurationName)" instead of "$(OutDir)". This should have no effect on the intended use cases of the variable. * Linking to library files by a full path in an implicit linker search directory (e.g. "/usr/lib/libfoo.a") no longer asks the linker to search for the library (e.g. "-lfoo") and now links by full path. See policy "CMP0060". -- 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 masariello+cmake.org at gmail.com Mon Jun 8 13:32:43 2015 From: masariello+cmake.org at gmail.com (Alessio) Date: Mon, 8 Jun 2015 18:32:43 +0100 Subject: [CMake] install(TARGETS) does not work with configuration-specific destinations Message-ID: Hi The below CMake code is causing my targets to get installed twice in the same tarball when I invoke cpack with the following command line "${CPACK_COMMAND}" -G ${cpack_gen} --config "${CMAKE_CURRENT_BINARY_DIR}/${package_cfg_file}" -C "$" The generated cmake_install.cmake in fact contains two fiel(INSTALL) sections for every target like the one at the bottom. Using \${CMAKE_INSTALL_CONFIG_NAME} as suggested in reference (1) does not quite work for me. I would like the installed directory to have a name of my choosing, rather than relying on the name of the configuration. Can this be done at all? Is there a single-call install(TARGETS) signature that gives me what I want? Thank you very much for any light you can shed on this. -alessio THE CMAKE INSTALL CODE WITH THE PROBLEM --------------------------------------- set(${PROJECT_NAME}_INSTALL_RUNTIME_RELEASE "release") set(${PROJECT_NAME}_INSTALL_RUNTIME_DEBUG "debug") install(TARGETS ${target} COMPONENT ${component} RUNTIME DESTINATION "${${PROJECT_NAME}_INSTALL_RUNTIME_RELEASE}" LIBRARY DESTINATION "${${PROJECT_NAME}_INSTALL_RUNTIME_RELEASE}" CONFIGURATIONS Release MinSizeRel RelWithDebInfo) install(TARGETS ${target} COMPONENT ${component} RUNTIME DESTINATION "${${PROJECT_NAME}_INSTALL_RUNTIME_DEBUG}" LIBRARY DESTINATION "${${PROJECT_NAME}_INSTALL_RUNTIME_DEBUG}" CONFIGURATIONS Debug PDebug) SAMPLE cmake_install.cmake SECTION ---------------------------------- if(NOT CMAKE_INSTALL_COMPONENT OR "${CMAKE_INSTALL_COMPONENT}" STREQUAL "platform") if("${CMAKE_INSTALL_CONFIG_NAME}" MATCHES "^([Dd][Ee][Bb][Uu][Gg])$") file(INSTALL DESTINATION "${CMAKE_INSTALL_PREFIX}/release" TYPE SHARED_LIBRARY FILES "E:/Views/build/testapp/Debug/testapp-d.dll") elseif("${CMAKE_INSTALL_CONFIG_NAME}" MATCHES "^([Rr][Ee][Ll][Ee][Aa][Ss][Ee])$") file(INSTALL DESTINATION "${CMAKE_INSTALL_PREFIX}/release" TYPE SHARED_LIBRARY FILES "E:/Views/build/testapp/Release/testapp.dll") elseif("${CMAKE_INSTALL_CONFIG_NAME}" MATCHES "^([Mm][Ii][Nn][Ss][Ii][Zz][Ee][Rr][Ee][Ll])$") file(INSTALL DESTINATION "${CMAKE_INSTALL_PREFIX}/release" TYPE SHARED_LIBRARY FILES "E:/Views/build/testapp/MinSizeRel/testapp-ms.dll") elseif("${CMAKE_INSTALL_CONFIG_NAME}" MATCHES "^([Rr][Ee][Ll][Ww][Ii][Tt][Hh][Dd][Ee][Bb][Ii][Nn][Ff][Oo])$") file(INSTALL DESTINATION "${CMAKE_INSTALL_PREFIX}/release" TYPE SHARED_LIBRARY FILES "E:/Views/build/testapp/RelWithDebInfo/testapp-rd.dll") elseif("${CMAKE_INSTALL_CONFIG_NAME}" MATCHES "^([Pp][Dd][Ee][Bb][Uu][Gg])$") file(INSTALL DESTINATION "${CMAKE_INSTALL_PREFIX}/release" TYPE SHARED_LIBRARY FILES "E:/Views/build/testapp/PDebug/testapp-pd.dll") endif() endif() REFERENCES ---------- (1) http://www.cmake.org/pipermail/cmake/2010-May/036979.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From masariello+cmake.org at gmail.com Mon Jun 8 13:40:29 2015 From: masariello+cmake.org at gmail.com (Alessio) Date: Mon, 8 Jun 2015 18:40:29 +0100 Subject: [CMake] install(TARGETS) does not work with configuration-specific destinations In-Reply-To: References: Message-ID: I forgot to mention that, by contrast, elsewhere I have the following working code. So install(FILES) seems to work fine with multiple calls for different configurations. install( FILES "$/some_file.txt" COMPONENT platform DESTINATION "${${PROJECT_NAME}_INSTALL_RUNTIME_RELEASE}" CONFIGURATIONS Release RelWithDebInfo MinSizeRel) install( FILES "$/some_file.txt" COMPONENT platform DESTINATION "${${PROJECT_NAME}_INSTALL_RUNTIME_DEBUG}" CONFIGURATIONS Debug PDebug) On 8 June 2015 at 18:32, Alessio wrote: > Hi > > The below CMake code is causing my targets to get installed twice in the > same tarball when I invoke cpack with the following command line > > "${CPACK_COMMAND}" -G ${cpack_gen} --config > "${CMAKE_CURRENT_BINARY_DIR}/${package_cfg_file}" -C "$" > > The generated cmake_install.cmake in fact contains two fiel(INSTALL) > sections for every target like the one at the bottom. > > Using \${CMAKE_INSTALL_CONFIG_NAME} as suggested in reference (1) does not > quite work for me. I would like the installed directory to have a name of > my choosing, rather than relying on the name of the configuration. > > Can this be done at all? Is there a single-call install(TARGETS) signature > that gives me what I want? > > Thank you very much for any light you can shed on this. > -alessio > > > THE CMAKE INSTALL CODE WITH THE PROBLEM > --------------------------------------- > set(${PROJECT_NAME}_INSTALL_RUNTIME_RELEASE "release") > set(${PROJECT_NAME}_INSTALL_RUNTIME_DEBUG "debug") > > install(TARGETS ${target} > COMPONENT ${component} > RUNTIME DESTINATION "${${PROJECT_NAME}_INSTALL_RUNTIME_RELEASE}" > LIBRARY DESTINATION "${${PROJECT_NAME}_INSTALL_RUNTIME_RELEASE}" > CONFIGURATIONS Release MinSizeRel RelWithDebInfo) > install(TARGETS ${target} > COMPONENT ${component} > RUNTIME DESTINATION "${${PROJECT_NAME}_INSTALL_RUNTIME_DEBUG}" > LIBRARY DESTINATION "${${PROJECT_NAME}_INSTALL_RUNTIME_DEBUG}" > CONFIGURATIONS Debug PDebug) > > > > SAMPLE cmake_install.cmake SECTION > ---------------------------------- > if(NOT CMAKE_INSTALL_COMPONENT OR "${CMAKE_INSTALL_COMPONENT}" STREQUAL > "platform") > if("${CMAKE_INSTALL_CONFIG_NAME}" MATCHES "^([Dd][Ee][Bb][Uu][Gg])$") > file(INSTALL DESTINATION "${CMAKE_INSTALL_PREFIX}/release" TYPE > SHARED_LIBRARY FILES "E:/Views/build/testapp/Debug/testapp-d.dll") > elseif("${CMAKE_INSTALL_CONFIG_NAME}" MATCHES > "^([Rr][Ee][Ll][Ee][Aa][Ss][Ee])$") > file(INSTALL DESTINATION "${CMAKE_INSTALL_PREFIX}/release" TYPE > SHARED_LIBRARY FILES "E:/Views/build/testapp/Release/testapp.dll") > elseif("${CMAKE_INSTALL_CONFIG_NAME}" MATCHES > "^([Mm][Ii][Nn][Ss][Ii][Zz][Ee][Rr][Ee][Ll])$") > file(INSTALL DESTINATION "${CMAKE_INSTALL_PREFIX}/release" TYPE > SHARED_LIBRARY FILES "E:/Views/build/testapp/MinSizeRel/testapp-ms.dll") > elseif("${CMAKE_INSTALL_CONFIG_NAME}" MATCHES > "^([Rr][Ee][Ll][Ww][Ii][Tt][Hh][Dd][Ee][Bb][Ii][Nn][Ff][Oo])$") > file(INSTALL DESTINATION "${CMAKE_INSTALL_PREFIX}/release" TYPE > SHARED_LIBRARY FILES "E:/Views/build/testapp/RelWithDebInfo/testapp-rd.dll") > elseif("${CMAKE_INSTALL_CONFIG_NAME}" MATCHES > "^([Pp][Dd][Ee][Bb][Uu][Gg])$") > file(INSTALL DESTINATION "${CMAKE_INSTALL_PREFIX}/release" TYPE > SHARED_LIBRARY FILES "E:/Views/build/testapp/PDebug/testapp-pd.dll") > endif() > endif() > > > REFERENCES > ---------- > (1) http://www.cmake.org/pipermail/cmake/2010-May/036979.html > -------------- next part -------------- An HTML attachment was scrubbed... URL: From post at hendrik-sattler.de Mon Jun 8 15:29:51 2015 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Mon, 08 Jun 2015 21:29:51 +0200 Subject: [CMake] cmake automoc fails when enabling autorcc Message-ID: <5575ED2F.2080304@hendrik-sattler.de> Hi, can someone explain to me what goes wrong? I am using Visual Studio 2010. CMake is 3.2.2 but also I tried 3.3-rc1. I created a small example that shows the problem. I created it from scratch and it instantly fails for me. You need to create a foo.png to get the qrc to actually create the source file (actually 2nd bug that CMake doesn't warn here). First run, comment out the onTst2 slot function (both h and cpp file), it should build. Then comment it before 2nd run. I get: error C3861: 'onTst2': identifier not found (moc_main.cpp) This file is auto-generated and thus was not updated. -> Should not happen. I also tried to manually run cmake, it won't help. However, commenting mainx.qrc helps! Or using qt4_add_resources() and disabling CMAKE_AUTORCC! Suddenly, the bugtest_automoc target is gone in VS and it compiles again, even after adding/removing Qt slot functions. BTW, why is this target called bugtest_automoc and not bugtest_autogen? The whole thing looks strange as bugtest target still has a qrc_mainx.cpp.rule but bugtest_automoc also has such a rule. The bugtest.automoc.rule file properties show no real command: ----------------- setlocal cd D:\bugtest\cmake-autogen\build if %errorlevel% neq 0 goto :cmEnd D: if %errorlevel% neq 0 goto :cmEnd :cmEnd endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone :cmErrorLevel exit /b %1 :cmDone if %errorlevel% neq 0 goto :VCEnd ----------------- Is that supposed to actually do something? Can someone point me to a possible solution? I'm back to qt4_add_resources() for now. Regards, HS CMakeLists.txt: ---------------------------------------------- cmake_minimum_required ( VERSION 3.0.2 ) cmake_policy ( VERSION 3.0.2 ) project ( bugtest CXX ) find_package ( Qt4 ) set ( CMAKE_INCLUDE_CURRENT_DIR ON ) set ( CMAKE_AUTOMOC ON ) set ( CMAKE_AUTORCC ON ) add_executable ( bugtest main.cpp mainx.qrc ) target_link_libraries ( bugtest Qt4::QtCore ) ---------------------------------------------- main.h: ---------------------------------------------- #include class tst1 : public QObject { Q_OBJECT public slots: void onTst1(); //void onTst2(); }; ---------------------------------------------- main.cpp: ---------------------------------------------- #include "main.h" void tst1::onTst1() { } // void tst1::onTst2() // { // } int main( int argc, char **argv) { return 0; } ---------------------------------------------- mainx.qrc: ---------------------------------------------- foo.png ---------------------------------------------- From austin.wood at gmail.com Mon Jun 8 19:49:07 2015 From: austin.wood at gmail.com (Austin Wood) Date: Mon, 8 Jun 2015 19:49:07 -0400 Subject: [CMake] install_manifest.txt Message-ID: Hi, The install_manifest.txt includes all the files installed by the entire project. Is it possible to get this list per subproject, ie per CMakeLists.txt? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From Dave at Yost.com Tue Jun 9 01:05:53 2015 From: Dave at Yost.com (Dave Yost) Date: Mon, 8 Jun 2015 22:05:53 -0700 Subject: [CMake] getting a build parameter from a file Message-ID: <9879BB0A-D3A6-455B-BA50-00D04D6D8A5F@yost.com> First, my cmake code does this: sets ${metals} from a cmake command-line argument compares the contents of ${metals} against the contents of a file to note whether the variable is being changed since the last run of cmake writes the new value to that file for next time call an add_timestamp_file_target function. which touches the file metalsTimestamp if the variable is being changed or if the file doesn?t exist. Then comes this: set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -DMETALS=\"\\\"${metals}\\\"\"") add_executable (metals metals.cc ) add_dependencies (metals metalsTimestamp) My add_timestamp_file_target function has to use one of add_custom_target add_custom_command to make metalsTimestamp visible to the add_dependencies function. Problem is, it seems that those commands have to touch the file every time cmake runs, but I want to touch it only when necessary. Is there a way to make this work? -------------- next part -------------- An HTML attachment was scrubbed... URL: From masariello+cmake.org at gmail.com Tue Jun 9 04:31:29 2015 From: masariello+cmake.org at gmail.com (Alessio) Date: Tue, 9 Jun 2015 09:31:29 +0100 Subject: [CMake] install(TARGETS) does not work with configuration-specific destinations In-Reply-To: References: Message-ID: Ah! Specifying the CONFIGURATIONS argument *before* the DESTINATION ones works as intended. It would really help if the documentation was changed to reflect the importance of parameter ordering here. install(TARGETS ${target} COMPONENT ${component} CONFIGURATIONS Release MinSizeRel RelWithDebInfo RUNTIME DESTINATION "${${PROJECT_NAME}_INSTALL_RUNTIME_RELEASE}" LIBRARY DESTINATION "${${PROJECT_NAME}_INSTALL_RUNTIME_RELEASE}") install(TARGETS ${target} COMPONENT ${component} CONFIGURATIONS Debug PDebug RUNTIME DESTINATION "${${PROJECT_NAME}_INSTALL_RUNTIME_DEBUG}" LIBRARY DESTINATION "${${PROJECT_NAME}_INSTALL_RUNTIME_DEBUG}") On 8 June 2015 at 18:40, Alessio wrote: > I forgot to mention that, by contrast, elsewhere I have the following > working code. So install(FILES) seems to work fine with multiple calls for > different configurations. > > install( > FILES "$/some_file.txt" > COMPONENT platform > DESTINATION "${${PROJECT_NAME}_INSTALL_RUNTIME_RELEASE}" > CONFIGURATIONS Release RelWithDebInfo MinSizeRel) > install( > FILES "$/some_file.txt" > COMPONENT platform > DESTINATION "${${PROJECT_NAME}_INSTALL_RUNTIME_DEBUG}" > CONFIGURATIONS Debug PDebug) > > On 8 June 2015 at 18:32, Alessio wrote: > >> Hi >> >> The below CMake code is causing my targets to get installed twice in the >> same tarball when I invoke cpack with the following command line >> >> "${CPACK_COMMAND}" -G ${cpack_gen} --config >> "${CMAKE_CURRENT_BINARY_DIR}/${package_cfg_file}" -C "$" >> >> The generated cmake_install.cmake in fact contains two fiel(INSTALL) >> sections for every target like the one at the bottom. >> >> Using \${CMAKE_INSTALL_CONFIG_NAME} as suggested in reference (1) does >> not quite work for me. I would like the installed directory to have a name >> of my choosing, rather than relying on the name of the configuration. >> >> Can this be done at all? Is there a single-call install(TARGETS) >> signature that gives me what I want? >> >> Thank you very much for any light you can shed on this. >> -alessio >> >> >> THE CMAKE INSTALL CODE WITH THE PROBLEM >> --------------------------------------- >> set(${PROJECT_NAME}_INSTALL_RUNTIME_RELEASE "release") >> set(${PROJECT_NAME}_INSTALL_RUNTIME_DEBUG "debug") >> >> install(TARGETS ${target} >> COMPONENT ${component} >> RUNTIME DESTINATION "${${PROJECT_NAME}_INSTALL_RUNTIME_RELEASE}" >> LIBRARY DESTINATION "${${PROJECT_NAME}_INSTALL_RUNTIME_RELEASE}" >> CONFIGURATIONS Release MinSizeRel RelWithDebInfo) >> install(TARGETS ${target} >> COMPONENT ${component} >> RUNTIME DESTINATION "${${PROJECT_NAME}_INSTALL_RUNTIME_DEBUG}" >> LIBRARY DESTINATION "${${PROJECT_NAME}_INSTALL_RUNTIME_DEBUG}" >> CONFIGURATIONS Debug PDebug) >> >> >> >> SAMPLE cmake_install.cmake SECTION >> ---------------------------------- >> if(NOT CMAKE_INSTALL_COMPONENT OR "${CMAKE_INSTALL_COMPONENT}" STREQUAL >> "platform") >> if("${CMAKE_INSTALL_CONFIG_NAME}" MATCHES "^([Dd][Ee][Bb][Uu][Gg])$") >> file(INSTALL DESTINATION "${CMAKE_INSTALL_PREFIX}/release" TYPE >> SHARED_LIBRARY FILES "E:/Views/build/testapp/Debug/testapp-d.dll") >> elseif("${CMAKE_INSTALL_CONFIG_NAME}" MATCHES >> "^([Rr][Ee][Ll][Ee][Aa][Ss][Ee])$") >> file(INSTALL DESTINATION "${CMAKE_INSTALL_PREFIX}/release" TYPE >> SHARED_LIBRARY FILES "E:/Views/build/testapp/Release/testapp.dll") >> elseif("${CMAKE_INSTALL_CONFIG_NAME}" MATCHES >> "^([Mm][Ii][Nn][Ss][Ii][Zz][Ee][Rr][Ee][Ll])$") >> file(INSTALL DESTINATION "${CMAKE_INSTALL_PREFIX}/release" TYPE >> SHARED_LIBRARY FILES "E:/Views/build/testapp/MinSizeRel/testapp-ms.dll") >> elseif("${CMAKE_INSTALL_CONFIG_NAME}" MATCHES >> "^([Rr][Ee][Ll][Ww][Ii][Tt][Hh][Dd][Ee][Bb][Ii][Nn][Ff][Oo])$") >> file(INSTALL DESTINATION "${CMAKE_INSTALL_PREFIX}/release" TYPE >> SHARED_LIBRARY FILES "E:/Views/build/testapp/RelWithDebInfo/testapp-rd.dll") >> elseif("${CMAKE_INSTALL_CONFIG_NAME}" MATCHES >> "^([Pp][Dd][Ee][Bb][Uu][Gg])$") >> file(INSTALL DESTINATION "${CMAKE_INSTALL_PREFIX}/release" TYPE >> SHARED_LIBRARY FILES "E:/Views/build/testapp/PDebug/testapp-pd.dll") >> endif() >> endif() >> >> >> REFERENCES >> ---------- >> (1) http://www.cmake.org/pipermail/cmake/2010-May/036979.html >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmstima at gmail.com Tue Jun 9 05:48:45 2015 From: gmstima at gmail.com (Roman Savchenko) Date: Tue, 9 Jun 2015 12:48:45 +0300 Subject: [CMake] CTest and grouped test with custom_target Message-ID: Hi all, I whant create goups of test and add them to custom targets, e.g. //unit test add_custom_target(check-unit "COMMAND ${CMAKE_CTEST_COMMAND} --output-on-failure") add_test_to_target(check-unit ${TEST1}) //integration tests add_custom_target(check-integration "COMMAND ${CMAKE_CTEST_COMMAND} --output-on-failure") add_test_to_target((check-integration ${TEST1}) How can I implement such logic? Many tanks, R. Savchenko. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Tue Jun 9 06:09:22 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 09 Jun 2015 12:09:22 +0200 Subject: [CMake] CTest and grouped test with custom_target In-Reply-To: References: Message-ID: <5576BB52.8090003@gmail.com> On 06/09/2015 11:48 AM, Roman Savchenko wrote: > I whant create goups of test and add them to custom targets, e.g. > > //unit test > add_custom_target(check-unit "COMMAND ${CMAKE_CTEST_COMMAND} > --output-on-failure") > add_test_to_target(check-unit ${TEST1}) > > //integration tests > add_custom_target(check-integration "COMMAND ${CMAKE_CTEST_COMMAND} > --output-on-failure") > add_test_to_target((check-integration ${TEST1}) > > How can I implement such logic? Untested but something like ... function(add_test_to_target label) set_property(TARGET ${ARGN} APPEND PROPERTY LABELS ${label}) endfunction() add_custom_target(check-integration "COMMAND ${CMAKE_CTEST_COMMAND} -L check-integration --output-on-failure") add_test_to_target(check-integration ${TEST1}) Nils From nilsgladitz at gmail.com Tue Jun 9 06:11:43 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 09 Jun 2015 12:11:43 +0200 Subject: [CMake] CTest and grouped test with custom_target In-Reply-To: <5576BB52.8090003@gmail.com> References: <5576BB52.8090003@gmail.com> Message-ID: <5576BBDF.9090709@gmail.com> On 06/09/2015 12:09 PM, Nils Gladitz wrote: Addendum ... don't quote the entire commandline; quote individual arguments (or omit quotes): add_custom_target(check-integration COMMAND ${CMAKE_CTEST_COMMAND} -L check-integration --output-on-failure) Nils From gmstima at gmail.com Tue Jun 9 07:40:01 2015 From: gmstima at gmail.com (Roman Savchenko) Date: Tue, 9 Jun 2015 14:40:01 +0300 Subject: [CMake] add_custom_command and variable arguments Message-ID: HI All, I whant to add custom command in such way: add_custom_target(my_target) add_custom_command(TARGET my_target POST_BUILD COMMAND script ${LIST}) set(LIST "") function(add_to_target source) add_executable(source ${source}) add_dependency(my_target ${source}) list(APPEND LIST ${source}) endfunction() add_to_target(s1.c) add_to_target(s2.c) But list is empty. How can I do it poperly? Many thanks, R. Savchenko. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Tue Jun 9 08:07:27 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 09 Jun 2015 14:07:27 +0200 Subject: [CMake] add_custom_command and variable arguments In-Reply-To: References: Message-ID: <5576D6FF.50808@gmail.com> On 06/09/2015 01:40 PM, Roman Savchenko wrote: > I whant to add custom command in such way: > > add_custom_target(my_target) > add_custom_command(TARGET my_target POST_BUILD COMMAND script ${LIST}) > > set(LIST "") > > function(add_to_target source) > add_executable(source ${source}) > add_dependency(my_target ${source}) > list(APPEND LIST ${source}) > endfunction() > > add_to_target(s1.c) > add_to_target(s2.c) > > But list is empty. How can I do it poperly? CMake functions have their own variable scope. To set a variable in the parent (calling) scope use set() with the PARENT_SCOPE flag. Alternatively use a macro instead of a function. Macros don't have their own variable scope. Nils From DLRdave at aol.com Tue Jun 9 11:05:04 2015 From: DLRdave at aol.com (David Cole) Date: Tue, 9 Jun 2015 11:05:04 -0400 Subject: [CMake] getting a build parameter from a file In-Reply-To: <9879BB0A-D3A6-455B-BA50-00D04D6D8A5F@yost.com> References: <9879BB0A-D3A6-455B-BA50-00D04D6D8A5F@yost.com> Message-ID: Why not just use configure_file to write ${metals} into the file... configure_file only actually touches/writes-to/updates the file if the contents are different... Then you can just depend on that file and you don't need a separate timestamp file. HTH, David C. On Tue, Jun 9, 2015 at 1:05 AM, Dave Yost wrote: > > > First, my cmake code does this: > > sets ${metals} from a cmake command-line argument > compares the contents of ${metals} against the contents of a file to note > whether the variable is being changed since the last run of cmake > writes the new value to that file for next time > call an add_timestamp_file_target function. which touches the file > metalsTimestamp if the variable is being changed or if the file doesn?t > exist. > > Then comes this: > > set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -DMETALS=\"\\\"${metals}\\\"\"") > add_executable (metals metals.cc) > add_dependencies (metals metalsTimestamp) > > > My add_timestamp_file_target function has to use one of > add_custom_target > add_custom_command > to make metalsTimestamp visible to the add_dependencies function. > > Problem is, it seems that those commands have to touch the file every time > cmake runs, but I want to touch it only when necessary. > > Is there a way to make this work? > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From DLRdave at aol.com Tue Jun 9 11:08:15 2015 From: DLRdave at aol.com (David Cole) Date: Tue, 9 Jun 2015 11:08:15 -0400 Subject: [CMake] install(TARGETS) does not work with configuration-specific destinations In-Reply-To: References: Message-ID: Updating the documentation for this would help... Do you have time to propose a patch which updates the wording of the documentation to stress the importance of parameter ordering? On Tue, Jun 9, 2015 at 4:31 AM, Alessio wrote: > Ah! Specifying the CONFIGURATIONS argument *before* the DESTINATION ones > works as intended. It would really help if the documentation was changed to > reflect the importance of parameter ordering here. > > install(TARGETS ${target} > COMPONENT ${component} > CONFIGURATIONS Release MinSizeRel RelWithDebInfo > RUNTIME DESTINATION > "${${PROJECT_NAME}_INSTALL_RUNTIME_RELEASE}" > LIBRARY DESTINATION > "${${PROJECT_NAME}_INSTALL_RUNTIME_RELEASE}") > install(TARGETS ${target} > COMPONENT ${component} > CONFIGURATIONS Debug PDebug > RUNTIME DESTINATION > "${${PROJECT_NAME}_INSTALL_RUNTIME_DEBUG}" > LIBRARY DESTINATION > "${${PROJECT_NAME}_INSTALL_RUNTIME_DEBUG}") > > On 8 June 2015 at 18:40, Alessio wrote: >> >> I forgot to mention that, by contrast, elsewhere I have the following >> working code. So install(FILES) seems to work fine with multiple calls for >> different configurations. >> >> install( >> FILES "$/some_file.txt" >> COMPONENT platform >> DESTINATION "${${PROJECT_NAME}_INSTALL_RUNTIME_RELEASE}" >> CONFIGURATIONS Release RelWithDebInfo MinSizeRel) >> install( >> FILES "$/some_file.txt" >> COMPONENT platform >> DESTINATION "${${PROJECT_NAME}_INSTALL_RUNTIME_DEBUG}" >> CONFIGURATIONS Debug PDebug) >> >> On 8 June 2015 at 18:32, Alessio wrote: >>> >>> Hi >>> >>> The below CMake code is causing my targets to get installed twice in the >>> same tarball when I invoke cpack with the following command line >>> >>> "${CPACK_COMMAND}" -G ${cpack_gen} --config >>> "${CMAKE_CURRENT_BINARY_DIR}/${package_cfg_file}" -C "$" >>> >>> The generated cmake_install.cmake in fact contains two fiel(INSTALL) >>> sections for every target like the one at the bottom. >>> >>> Using \${CMAKE_INSTALL_CONFIG_NAME} as suggested in reference (1) does >>> not quite work for me. I would like the installed directory to have a name >>> of my choosing, rather than relying on the name of the configuration. >>> >>> Can this be done at all? Is there a single-call install(TARGETS) >>> signature that gives me what I want? >>> >>> Thank you very much for any light you can shed on this. >>> -alessio >>> >>> >>> THE CMAKE INSTALL CODE WITH THE PROBLEM >>> --------------------------------------- >>> set(${PROJECT_NAME}_INSTALL_RUNTIME_RELEASE "release") >>> set(${PROJECT_NAME}_INSTALL_RUNTIME_DEBUG "debug") >>> >>> install(TARGETS ${target} >>> COMPONENT ${component} >>> RUNTIME DESTINATION "${${PROJECT_NAME}_INSTALL_RUNTIME_RELEASE}" >>> LIBRARY DESTINATION "${${PROJECT_NAME}_INSTALL_RUNTIME_RELEASE}" >>> CONFIGURATIONS Release MinSizeRel RelWithDebInfo) >>> install(TARGETS ${target} >>> COMPONENT ${component} >>> RUNTIME DESTINATION "${${PROJECT_NAME}_INSTALL_RUNTIME_DEBUG}" >>> LIBRARY DESTINATION "${${PROJECT_NAME}_INSTALL_RUNTIME_DEBUG}" >>> CONFIGURATIONS Debug PDebug) >>> >>> >>> >>> SAMPLE cmake_install.cmake SECTION >>> ---------------------------------- >>> if(NOT CMAKE_INSTALL_COMPONENT OR "${CMAKE_INSTALL_COMPONENT}" STREQUAL >>> "platform") >>> if("${CMAKE_INSTALL_CONFIG_NAME}" MATCHES "^([Dd][Ee][Bb][Uu][Gg])$") >>> file(INSTALL DESTINATION "${CMAKE_INSTALL_PREFIX}/release" TYPE >>> SHARED_LIBRARY FILES "E:/Views/build/testapp/Debug/testapp-d.dll") >>> elseif("${CMAKE_INSTALL_CONFIG_NAME}" MATCHES >>> "^([Rr][Ee][Ll][Ee][Aa][Ss][Ee])$") >>> file(INSTALL DESTINATION "${CMAKE_INSTALL_PREFIX}/release" TYPE >>> SHARED_LIBRARY FILES "E:/Views/build/testapp/Release/testapp.dll") >>> elseif("${CMAKE_INSTALL_CONFIG_NAME}" MATCHES >>> "^([Mm][Ii][Nn][Ss][Ii][Zz][Ee][Rr][Ee][Ll])$") >>> file(INSTALL DESTINATION "${CMAKE_INSTALL_PREFIX}/release" TYPE >>> SHARED_LIBRARY FILES "E:/Views/build/testapp/MinSizeRel/testapp-ms.dll") >>> elseif("${CMAKE_INSTALL_CONFIG_NAME}" MATCHES >>> "^([Rr][Ee][Ll][Ww][Ii][Tt][Hh][Dd][Ee][Bb][Ii][Nn][Ff][Oo])$") >>> file(INSTALL DESTINATION "${CMAKE_INSTALL_PREFIX}/release" TYPE >>> SHARED_LIBRARY FILES "E:/Views/build/testapp/RelWithDebInfo/testapp-rd.dll") >>> elseif("${CMAKE_INSTALL_CONFIG_NAME}" MATCHES >>> "^([Pp][Dd][Ee][Bb][Uu][Gg])$") >>> file(INSTALL DESTINATION "${CMAKE_INSTALL_PREFIX}/release" TYPE >>> SHARED_LIBRARY FILES "E:/Views/build/testapp/PDebug/testapp-pd.dll") >>> endif() >>> endif() >>> >>> >>> REFERENCES >>> ---------- >>> (1) http://www.cmake.org/pipermail/cmake/2010-May/036979.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 csiga.biga at aol.com Tue Jun 9 13:32:48 2015 From: csiga.biga at aol.com (=?utf-8?Q?Nagy-Egri_M=C3=A1t=C3=A9_Ferenc?=) Date: Tue, 9 Jun 2015 17:32:48 +0000 Subject: [CMake] =?utf-8?q?Visual_Studio_Project_System_Extensibilty?= In-Reply-To: <008701d0a171$31e741c0$95b5c540$@gmail.com> References: , <008701d0a171$31e741c0$95b5c540$@gmail.com> Message-ID: I?m curious too, but I think that it would be easier to use a fixed format for project representation, such as the suggested CPS, and have it generate a CMake file if an update is needed. CMake generally lacks any kind of structure, users are generally free to roam about the script language. Qt Creator is doing a similar thing. You have a .pro file that is maintained by the IDE, and this .pro file is translated to a QMake script, which then translates to a native build system. Such a project could start off impementing the translation from CPS to a strictly formatted, auto-generated CMake script that only covers the features of the IDE. Once that is done, the next few steps can be taken to extend it?s capabilities by adding new switches, levers and buttons to the Properties section of the Solution/Project entities. While it does not strictly relate, I would suggest people take a visit here: http://visualstudio.uservoice.com/forums/293070-visual-studio-code/suggestions/7752684-add-cmake-support Visual Studio Code is a promising new IDE that is completely cross-platform and already has pilot support for brand new stuff, such as Rust language support. It is a new IDE (that currently looks more like a code editor, as far as C++ is concerned), and user input greatly influences the course of action from the developers POV. The last patch issued took 2 months and adds ~300 bug fixes and feature requests, most originating from uservoice.com. Please take a moment and up-vote CMake support. Most likely on all platform it would rely on the newly open-sourced MSBuild system. Nontheless, it would be a great win for CMake, if an IDE picked up GUI editing of projects that translate to CMake automatically. Either by Visual Studio Code picking up support, or if someone took the time and implemented CMake project for old-school VS through CPS. Cheers, M?t? ps.: David, great job on the VS Add-In for CMake. We love it! Felad?: David Golub Elk?ldve: ?h?tf??, ?2015?. ?j?nius? ?8?. ?0?:?27 C?mzett: 'Alexey Petruchik', cmake at cmake.org Probably doable but still a lot of work. It took me about a year over my nights and weekends to implement CMake Tools for Visual Studio, which provides syntax highlighting and IntelliSense for CMake but no project system (yet). From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Alexey Petruchik Sent: Sunday, June 07, 2015 1:45 PM To: cmake at cmake.org Subject: [CMake] Visual Studio Project System Extensibilty Microsoft recently announced Project System Extensibility in Visual Studio 2015. http://blogs.msdn.com/b/visualstudio/archive/2015/06/02/introducing-the-project-system-extensibility-sdk-preview.aspx Just curious if this can be used to let Visual Studio directly open CMake projects? -------------- next part -------------- An HTML attachment was scrubbed... URL: From parag at ionicsecurity.com Tue Jun 9 13:52:26 2015 From: parag at ionicsecurity.com (Parag Chandra) Date: Tue, 9 Jun 2015 17:52:26 +0000 Subject: [CMake] Visual Studio Project System Extensibilty In-Reply-To: <20150609174517.7E46AAE9BF@public.kitware.com> References: <008701d0a171$31e741c0$95b5c540$@gmail.com> <20150609174517.7E46AAE9BF@public.kitware.com> Message-ID: Somewhat related: CLion, the new C/C++ IDE from JetBrains, uses CMake directly as its project system: https://www.jetbrains.com/clion/ Not free, but also cross-platform. Parag Chandra Senior Software Engineer, Mobile Team Mobile: +1.919.824.1410 [https://www.ionicsecurity.com/IonicSigHz.png] Ionic Security Inc. 1170 Peachtree St. NE STE 400, Atlanta, GA 30309 From: Nagy-Egri M?t? Ferenc via CMake > Reply-To: Nagy-Egri M?t? Ferenc > Date: Tuesday, June 9, 2015 at 1:32 PM To: David Golub >, 'Alexey Petruchik' >, "cmake at cmake.org" > Subject: Re: [CMake] Visual Studio Project System Extensibilty I?m curious too, but I think that it would be easier to use a fixed format for project representation, such as the suggested CPS, and have it generate a CMake file if an update is needed. CMake generally lacks any kind of structure, users are generally free to roam about the script language. Qt Creator is doing a similar thing. You have a .pro file that is maintained by the IDE, and this .pro file is translated to a QMake script, which then translates to a native build system. Such a project could start off impementing the translation from CPS to a strictly formatted, auto-generated CMake script that only covers the features of the IDE. Once that is done, the next few steps can be taken to extend it?s capabilities by adding new switches, levers and buttons to the Properties section of the Solution/Project entities. While it does not strictly relate, I would suggest people take a visit here: http://visualstudio.uservoice.com/forums/293070-visual-studio-code/suggestions/7752684-add-cmake-support Visual Studio Code is a promising new IDE that is completely cross-platform and already has pilot support for brand new stuff, such as Rust language support. It is a new IDE (that currently looks more like a code editor, as far as C++ is concerned), and user input greatly influences the course of action from the developers POV. The last patch issued took 2 months and adds ~300 bug fixes and feature requests, most originating from uservoice.com. Please take a moment and up-vote CMake support. Most likely on all platform it would rely on the newly open-sourced MSBuild system. Nontheless, it would be a great win for CMake, if an IDE picked up GUI editing of projects that translate to CMake automatically. Either by Visual Studio Code picking up support, or if someone took the time and implemented CMake project for old-school VS through CPS. Cheers, M?t? ps.: David, great job on the VS Add-In for CMake. We love it! Felad?: David Golub Elk?ldve: ?h?tf??, ?2015?. ?j?nius? ?8?. ?0?:?27 C?mzett: 'Alexey Petruchik', cmake at cmake.org Probably doable but still a lot of work. It took me about a year over my nights and weekends to implement CMake Tools for Visual Studio, which provides syntax highlighting and IntelliSense for CMake but no project system (yet). From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Alexey Petruchik Sent: Sunday, June 07, 2015 1:45 PM To: cmake at cmake.org Subject: [CMake] Visual Studio Project System Extensibilty Microsoft recently announced Project System Extensibility in Visual Studio 2015. http://blogs.msdn.com/b/visualstudio/archive/2015/06/02/introducing-the-project-system-extensibility-sdk-preview.aspx Just curious if this can be used to let Visual Studio directly open CMake projects? -------------- next part -------------- An HTML attachment was scrubbed... URL: From cxjohnson at gmail.com Tue Jun 9 13:56:02 2015 From: cxjohnson at gmail.com (Chris Johnson) Date: Tue, 9 Jun 2015 12:56:02 -0500 Subject: [CMake] Backup copy on install? Message-ID: About a year ago we converted our build system, which used a huge pile of custom Makefile code, to use CMake. It has been working well for us. But now, the boss (who dabbles at the command line) and a couple of the developers are asking for a "feature" which went away with that conversion. Namely, the old Makefiles used the "install -b" command, which results in every installed binary first making a backup copy of the old file before replacing it. That is: Before install: % ls ~/bin ~/bin/myprog After install: % ls ~/bin ~/bin/myprog.old ~/bin/myprog Is there a quick and easy way to globally add such an automatic copy of the install target in CMake? I've searched high and low for some setting or method, but have come up empty handed. We do use a globally included set of CMake rules in all of our CMakeLists.txt files, so if there's a bit of code that could be added there, that would be sufficient. All suggestions welcome! Thanks, ..chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjvbertin at gmail.com Tue Jun 9 14:34:22 2015 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Tue, 09 Jun 2015 20:34:22 +0200 Subject: [CMake] determining which system headerfile provides a given function Message-ID: <2365905.UvL37pODeQ@patux> Hello, I need to determine the availability of a certain function (reallocf) and which headerfile provides its prototype. If there is a function that handles this case I must have overlooked it (including on google), so I tried repeating a check_symbol_exist() call repeatedly with the various known header file paths. But that also doesn't work, either because of caching or because I'm doing something else wrong. So, how does one handle this kind of situation? Thanks, Ren? From bill.hoffman at kitware.com Tue Jun 9 15:00:23 2015 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Tue, 09 Jun 2015 15:00:23 -0400 Subject: [CMake] Backup copy on install? In-Reply-To: References: Message-ID: <557737C7.900@kitware.com> On 6/9/2015 1:56 PM, Chris Johnson wrote: > > We do use a globally included set of CMake rules in all of our > CMakeLists.txt files, so if there's a bit of code that could be added > there, that would be sufficient. > > All suggestions welcome! > You might be able to do something with install(CODE ...) At the end of the day the install step is just running generated cmake code. If you look in your build tree there are files like this: cmake_install.cmake. With install(CODE), you can inject your own code into those files. -Bill From steveire at gmail.com Tue Jun 9 16:16:55 2015 From: steveire at gmail.com (Stephen Kelly) Date: Tue, 09 Jun 2015 22:16:55 +0200 Subject: [CMake] determining which system headerfile provides a given function References: <2365905.UvL37pODeQ@patux> Message-ID: Ren? J.V. Bertin wrote: > Hello, > > I need to determine the availability of a certain function (reallocf) and > which headerfile provides its prototype. If there is a function that > handles this case I must have overlooked it (including on google), so I > tried repeating a check_symbol_exist() call repeatedly with the various > known header file paths. But that also doesn't work, either because of > caching or because I'm doing something else wrong. > > So, how does one handle this kind of situation? http://www.macieira.org/blog/2012/05/doesnt-work-doesnt-work/ http://sscce.org/ From rjvbertin at gmail.com Tue Jun 9 19:32:21 2015 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Wed, 10 Jun 2015 01:32:21 +0200 Subject: [CMake] determining which system headerfile provides a given function References: <2365905.UvL37pODeQ@patux> Message-ID: <2677252.MfnChCZEH7@portia.local> Ok, let me rephrase the question to see what other kind of constructive answers that'll lead to: how does one check which header file provides the prototype for a function from the system libraries? Function in question: reallocf; can apparently be in either stdlib.h or bsd/stdlib.h . From khouli at gmail.com Tue Jun 9 21:12:57 2015 From: khouli at gmail.com (Kevin Houlihan) Date: Tue, 9 Jun 2015 21:12:57 -0400 Subject: [CMake] Migrating from another build system that maintains its own source file lists In-Reply-To: References: Message-ID: >From Alan's suggestions and some fiddling here's the solution I came up with to the problem I posted a while back. Seems to work. (I have no idea what the etiquette is on a mailing list like this for posting chunks of code so just tell me if I'm doing anything wrong.) The problem is that there's some existing build system that maintains authoritative lists of files and we want to create a CMake build system that updates appropriately according to this list of files. Here's the directory structure for a simple example: ex/ prj/ f1.h f1.cpp lib1_files.txt new_cmake_system/ CMakeLists.txt make_cmakelists.sh 'lib1_files.txt' is part of some existing build system and so for the time being it must remain the authoritative list of source files. We want a CMake build system that can coexist with the current build system and perhaps supplant it later. The example shown is intended to read from lib1_files.txt and create a CMakeLists.txt as appropriate and "do the right thing" when rebuilding. *prj/lib1_files.txt*: f1.cpp *new_cmake_system/CMakeLists.txt*: cmake_minimum_required(VERSION 2.8.11) project(prj) set(REL_PRJ_DIR ../prj) get_filename_component(PRJ_DIR ${REL_PRJ_DIR} ABSOLUTE) # command that generates the CMakeLists.txt file for a library set(GEN_LIB1_CMAKELIST_CMD ${CMAKE_CURRENT_LIST_DIR}/make_cmakelists.sh) # initial bootstrapping of the CMakeLists.txt file execute_process( COMMAND ${GEN_LIB1_CMAKELIST_CMD} WORKING_DIRECTORY ${CMAKE_CURRENT_LIST_DIR} ) add_custom_command( OUTPUT ${CMAKE_CURRENT_LIST_DIR}/lib1/CMakeLists.txt COMMAND execute_process(COMMAND ${GEN_LIB1_CMAKELIST_CMD}) WORKING_DIRECTORY ${CMAKE_CURRENT_LIST_DIR} ) add_custom_target( lib1_cmakelists DEPENDS ${CMAKE_CURRENT_LIST_DIR}/lib1/CMakeLists.txt ) add_subdirectory(lib1) add_dependencies(lib1 lib1_cmakelists) And even though it's just a crude example, for completeness here's *make_cmakelists.sh*: #!/usr/bin/env bash cmakelistsfile=lib1/CMakeLists.txt mkdir lib1 2> /dev/null echo 'set(SRCS' > $cmakelistsfile while read line; do echo ' ${PRJ_DIR}/'$line done < ../prj/lib1_files.txt >> $cmakelistsfile echo ' )' >> $cmakelistsfile echo 'add_library(lib1 SHARED ${SRCS})' >> $cmakelistsfile The whole boot strapping thing via execute_process() feels a little funny but the whole thing seems to update appropriately when files are added or removed from the example project. On Thu, May 28, 2015 at 1:11 PM, Alan W. Irwin wrote: > Hi Kevin: > > I believe this discussion continues to belong on the cmake list so I have > CC'd > there. > > > On Wed, May 27, 2015 at 2:17 PM, Alan W. Irwin > > >> wrote: >> >> On 2015-05-27 13:48-0400 Kevin Houlihan wrote: >>> >>> Hello, >>> >>>> >>>> I want to migrate from a build system that has its own lists of source >>>> files that must be maintained for the time being. I have scripts to >>>> translate those list files into CMakeLists.txt files but I don't know >>>> of a >>>> good way to integrate those into a CMake generated build system and keep >>>> the generated CMakeLists.txt files up to date with the files they were >>>> generated from. >>>> >>>> My current solution is to use a Makefile to check to see if the >>>> CMakeLists.txt files need to be updated as part of the build. This is a >>>> bit >>>> clumsy. >>>> >>>> The issue seems similar to the problem of using file globbing in >>>> CMakeLIsts.txt files and as far as I know, the answer there is "don't do >>>> that". Still I thought I'd try my luck. >>>> >>>> Any suggestions? >>>> >>>> >>> Use a CMake list of files, and maintain that, e.g., >>> >>> set(lib_SRC_FILE_LIST >>> a.c >>> b.c >>> c.c >>> [...] >>> ) >>> >>> add_library(lib ${lib_SRC_FILE_LIST}) >>> >>> or if there are thousands of files in the list and you don't want >>> to disrupt the logic of your principal CMakeLists.txt files with >>> lists scattered all over within the file, then look at >>> the include(...) command which will include CMake source code >>> from a file (say completely devoted to the above list creation command). >>> >>> > On 2015-05-28 08:31-0400 Kevin Houlihan wrote: > > Sorry, I wasn't clear. The list of source files from the existing >> non-CMake >> build system is the authoritative list and whenever it changes >> (potentially >> by people who aren't me) I want the CMakeLists.txt files to automatically >> update. Generating the CMakeLists.txt files isn't the issue, it's >> automating that process. >> > > Just for reference the actual quote you were referring to is likely > from which > says: > > "Note We do not recommend using GLOB to collect a list of source files > from your source tree. If no CMakeLists.txt file changes when a source > is added or removed then the generated build system cannot know when > to ask CMake to regenerate." > > Does this mean that a summary of your need is that you want an > automated method such that if a source file was added or deleted for > an already configured build of a library, then the next attempt to > build that library would regenerate the list of source files for that > library? > > If so, that is an intriguing problem. I have never tried anything > like that, but to replace your current Makefile approach it seems to > me the following approach would work: > > 1. Implement a custom command that file depended on the authorative > list of source files for a particular library and whose OUTPUT was the > generated CMakeLists.txt file that built that library. > > 2. Implement a custom target which file depended on that OUTPUT file. > > 3. Use add_dependencies to make the library target depend on the > custom target (so the custom target will always be built first). > > Of course, 1. through 3. could all be implemented as part of the generated > CMakeLists.txt 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 > __________________________ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Dave at Yost.com Tue Jun 9 22:17:53 2015 From: Dave at Yost.com (Dave Yost) Date: Tue, 9 Jun 2015 19:17:53 -0700 Subject: [CMake] CMAKE_COLOR_MAKEFILE Message-ID: <2FA7BB67-7CA7-4355-B9B1-2BD7C6AF8D8A@yost.com> Hey, I love colors. But one of my users doesn?t. Why doesn?t this work? CMAKE_COLOR_MAKEFILE=OFF cmake .. If that worked, he could set it and forget it. Instead, he has to do this: cmake -DCMAKE_COLOR_MAKEFILE=OFF .. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Dave at Yost.com Tue Jun 9 22:19:48 2015 From: Dave at Yost.com (Dave Yost) Date: Tue, 9 Jun 2015 19:19:48 -0700 Subject: [CMake] getting a build parameter from a file In-Reply-To: References: <9879BB0A-D3A6-455B-BA50-00D04D6D8A5F@yost.com> Message-ID: <0F1E1140-E5C6-4007-8F14-2D34A8A3FD73@yost.com> > On 2015-06-09, at 8:05 AM, David Cole wrote: > > Why not just use configure_file because I didn?t know about it. Thanks! > to write ${metals} into the file... > configure_file only actually touches/writes-to/updates the file if the > contents are different... > > Then you can just depend on that file and you don't need a separate > timestamp file. > > > HTH, > David C. > > > On Tue, Jun 9, 2015 at 1:05 AM, Dave Yost wrote: >> >> >> First, my cmake code does this: >> >> sets ${metals} from a cmake command-line argument >> compares the contents of ${metals} against the contents of a file to note >> whether the variable is being changed since the last run of cmake >> writes the new value to that file for next time >> call an add_timestamp_file_target function. which touches the file >> metalsTimestamp if the variable is being changed or if the file doesn?t >> exist. >> >> Then comes this: >> >> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -DMETALS=\"\\\"${metals}\\\"\"") >> add_executable (metals metals.cc) >> add_dependencies (metals metalsTimestamp) >> >> >> My add_timestamp_file_target function has to use one of >> add_custom_target >> add_custom_command >> to make metalsTimestamp visible to the add_dependencies function. >> >> Problem is, it seems that those commands have to touch the file every time >> cmake runs, but I want to touch it only when necessary. >> >> Is there a way to make this work? >> >> >> -- >> >> 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 iosif.neitzke+cmake at gmail.com Tue Jun 9 22:45:58 2015 From: iosif.neitzke+cmake at gmail.com (Iosif Neitzke) Date: Tue, 9 Jun 2015 21:45:58 -0500 Subject: [CMake] CMAKE_COLOR_MAKEFILE In-Reply-To: <2FA7BB67-7CA7-4355-B9B1-2BD7C6AF8D8A@yost.com> References: <2FA7BB67-7CA7-4355-B9B1-2BD7C6AF8D8A@yost.com> Message-ID: The CMake variable CMAKE_COLOR_MAKEFILE sets the preference to generate a colored Makefile at Configure time. At Build time, regardless if CMAKE_COLOR_MAKEFILE=ON, you can use 'make COLOR=0' to turn off Makefile color dynamically. Running through cmake with 'cmake --build -- COLOR=0' does the same thing. You could also set COLOR=0 as an environment variable. I don't believe a Makefile generated with CMAKE_COLOR_MAKEFILE=OFF can have color turned back on dynamically, however. On Tue, Jun 9, 2015 at 9:17 PM, Dave Yost wrote: > Hey, I love colors. But one of my users doesn?t. > > Why doesn?t this work? > > CMAKE_COLOR_MAKEFILE=OFF cmake .. > > If that worked, he could set it and forget it. > > Instead, he has to do this: > > cmake -DCMAKE_COLOR_MAKEFILE=OFF .. > > > > -- > > 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 d3ck0r at gmail.com Wed Jun 10 03:48:06 2015 From: d3ck0r at gmail.com (J Decker) Date: Wed, 10 Jun 2015 00:48:06 -0700 Subject: [CMake] Check_include_file is supposed make a definition? Message-ID: CHECK_INCLUDE_FILE(stdint.h HAVE_STDINT_H) is this supposed to create some sort of ADD_DEFINITION( -DHAVE_STDINT_H) ? if not what else do I have to do to make that work? -------------- next part -------------- An HTML attachment was scrubbed... URL: From johannes.zarl-zierl at jku.at Wed Jun 10 04:21:51 2015 From: johannes.zarl-zierl at jku.at (Johannes Zarl-Zierl) Date: Wed, 10 Jun 2015 10:21:51 +0200 Subject: [CMake] Check_include_file is supposed make a definition? In-Reply-To: References: Message-ID: <8195803.lYKNLFppmz@ersa> On Wednesday 10 June 2015 00:48:06 J Decker wrote: > CHECK_INCLUDE_FILE(stdint.h HAVE_STDINT_H) > > is this supposed to create some sort of ADD_DEFINITION( -DHAVE_STDINT_H) ? No. > if not what else do I have to do to make that work? IF(HAVE_STDINT_H) ADD_DEFINITION(HAVE_STDINT_H) ENDIF() If you want to do this always, you can write a wrapper function, of course... Cheers, Johannes From cxjohnson at gmail.com Wed Jun 10 12:57:32 2015 From: cxjohnson at gmail.com (Chris Johnson) Date: Wed, 10 Jun 2015 11:57:32 -0500 Subject: [CMake] Backup copy on install? In-Reply-To: <557737C7.900@kitware.com> References: <557737C7.900@kitware.com> Message-ID: Hmm. It's a possibility. But those files are generate when I run cmake, aren't they? So re-running that would tend to overwrite any custom modifications I made. And I have about 350 of them. I note that cmake_install.cmake simply uses the file(INSTALL ...) command. How could I find the implementation of the file() command? Could I possibly customize that implementation? Thanks much! ..chris On Tue, Jun 9, 2015 at 2:00 PM, Bill Hoffman wrote: > On 6/9/2015 1:56 PM, Chris Johnson wrote: > >> >> We do use a globally included set of CMake rules in all of our >> CMakeLists.txt files, so if there's a bit of code that could be added >> there, that would be sufficient. >> >> All suggestions welcome! >> >> You might be able to do something with install(CODE ...) > > At the end of the day the install step is just running generated cmake > code. If you look in your build tree there are files like this: > cmake_install.cmake. With install(CODE), you can inject your own code into > those files. > > -Bill > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.hoffman at kitware.com Wed Jun 10 15:15:52 2015 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Wed, 10 Jun 2015 15:15:52 -0400 Subject: [CMake] Backup copy on install? In-Reply-To: References: <557737C7.900@kitware.com> Message-ID: <55788CE8.4060601@kitware.com> On 6/10/2015 12:57 PM, Chris Johnson wrote: > Hmm. It's a possibility. > > But those files are generate when I run cmake, aren't they? So > re-running that would tend to overwrite any custom modifications I > made. And I have about 350 of them. > That is what install(CODE ...) will do for you. It will inject your code into those files and the code will stay there. I was not suggesting you edit those files directly, just that you could use install(CODE, and look at those files to make sure it is doing what you want. > I note that cmake_install.cmake simply uses the file(INSTALL ...) > command. How could I find the implementation of the file() command? > Could I possibly customize that implementation? To change the file command you would have to change the C++ of CMake. If you get install(CODE to work then it will work with any version of CMake. If you can get your code to run just before the file(INSTALL then you should be good. > > Thanks much! -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 bill.hoffman at kitware.com http://www.kitware.com 518 881-4905 (Direct) 518 371-3971 x105 Fax (518) 371-4573 From MillerHenry at JohnDeere.com Wed Jun 10 18:12:20 2015 From: MillerHenry at JohnDeere.com (Miller Henry) Date: Wed, 10 Jun 2015 22:12:20 +0000 Subject: [CMake] 3.3.0-rc1 feedback - CMP0046 doens't obey policy push Message-ID: <35F6921410093E4CA40D524BD5C18D4C268A6A82@EDXMB57.jdnet.deere.com> I'm trying out my project on 3.3.0-rc1, but currently I'm using 2.8.11 and 2.8.12. I got a couple errors from CMP0046. Most of them are correct: I've fixed a couple places where a non-existent dependency was used, and I want to set this policy to NEW so that more do not sneak in. However there is a problem. I have a test that dynamically loads a bunch of .so's, as configured by a .xml file to ensure they are compatible. Some of the .so's are in the same project and some are from a different project and installed into the system at build time. We are running tests as part of the make all target, (easy to do with a few add_custom_command/add_custom_target). The obvious problem is this test needs to have all the .so's built before the test runs, but it doesn't link them. This was easy enough - I just parsed the .xml for the name of the .so and place that name into an add_dependencies. That works great in cmake 2.8.11. In cmake 3.3.0-rc1 it doesn't work. Some of the .so's are installed on the system and not built in the project. Obviously no target exists for them. What I want to do to solve this is: cmake_policy(PUSH) if(POLICY CMP0046) CMAKE_POLICY(SET CMP0046 OLD) endif() add_dependencies(${MyTestRunTarget} ${XML_PARSED_DEPENDENCIES}) cmake_policy(POP) This does not work. It appears that the policy is not actually checked until long after the add_dependencies line is done processing, and the fact that I want to suppress the policy for just these is not carried along. Is there some way to achieve changing this policy for just a few select targets? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mjklaim at gmail.com Wed Jun 10 18:55:19 2015 From: mjklaim at gmail.com (=?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?=) Date: Thu, 11 Jun 2015 00:55:19 +0200 Subject: [CMake] How does :: actually works? Message-ID: Hi, I tried several times now to find documentation about how to define and use target names which seem to have namespaces, like Qt ones. For example: add_executable( MyProject::some_target ... ) I can't find any documentation or even name for this. Is it considered a "namespace"? In any way I found nothing specific to this syntax in the wiki. Help? -------------- next part -------------- An HTML attachment was scrubbed... URL: From johannes.zarl-zierl at jku.at Thu Jun 11 09:22:16 2015 From: johannes.zarl-zierl at jku.at (Johannes Zarl-Zierl) Date: Thu, 11 Jun 2015 15:22:16 +0200 Subject: [CMake] How does :: actually works? In-Reply-To: References: Message-ID: <1966303.10G05DjLjn@ersa> Hi, > I tried several times now to find documentation about how to define > and use target names which seem to have namespaces, like Qt ones. > > For example: add_executable( MyProject::some_target ... ) AFAIK target namespaces are intended for imported targets, not "regular" targets: "A NAMESPACE with double-colons is specified when exporting the targets for installation. This convention of double-colons gives CMake a hint that the name is an IMPORTED target when it is used by downstreams with the target_link_libraries() command. This way, CMake can issue a diagnostic if the package providing it has not yet been found." [1] [1] http://www.cmake.org/cmake/help/v3.3/manual/cmake-packages.7.html?highlight=namespace > I can't find any documentation or even name for this. > Is it considered a "namespace"? > In any way I found nothing specific to this syntax in the wiki. The concept is called "namespace" in cmake, just as you assumed. I don't know if there's anything about it in the wiki, but the official documentation has a (very) short description in the cmake_packages[1] page, as well as in the documentation for the export command. Cheers, Johannes From robert.maynard at kitware.com Thu Jun 11 09:37:28 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 11 Jun 2015 09:37:28 -0400 Subject: [CMake] [ANNOUNCE] CMake 3.3.0-rc2 is now ready! Message-ID: I am proud to announce the second CMake 3.3 release candidate. Sources and binaries are available at: http://www.cmake.org/download/ Documentation is available at: http://www.cmake.org/cmake/help/v3.3 Release notes appear below and are also published at http://www.cmake.org/cmake/help/v3.3/release/3.3.html Some of the more significant features of CMake 3.3 are: * The "if()" command learned a new "IN_LIST" operator that evaluates to true if a given element is contained in a named list. * The "add_dependencies()" command learned to allow dependencies to be added to *interface libraries*. Dependencies added to an interface library are followed transitively in its place since the target itself does not build. * The "find_library()", "find_path()", and "find_file()" commands now search in installation prefixes derived from the "PATH" environment variable. * The "_VISIBILITY_PRESET" and "VISIBILITY_INLINES_HIDDEN" target properties now affect compilation in sources of all target types. See policy "CMP0063". * A "_INCLUDE_WHAT_YOU_USE" target property and supporting "CMAKE__INCLUDE_WHAT_YOU_USE" variable were introduced to tell the *Makefile Generators* and the "Ninja" generator to run "include- what-you-use" along with the compiler for "C" and "CXX" languages. Deprecated and Removed Features: * The "ctest_build()" and "build_command()" commands no longer tell "make" tools to ignore errors with the "-i" option. Previously this was done for *Makefile Generators* but not others. See policy "CMP0061". * The "Visual Studio 7" generator (.NET 2002) is now deprecated and will be removed in a future version of CMake. * The "Visual Studio 6" generator is now deprecated and will be removed in a future version of CMake. * The "add_definitions()" command no longer causes a "DEFINITIONS" directory property to be populated. See policy "CMP0059". CMake 3.3 Release Notes *********************** Changes made since CMake 3.2 include the following. New Features ============ Generators ---------- * The *Makefile Generators* now add ".DELETE_ON_ERROR" to the makefiles that contain the actual build rules for files on disk. This tells GNU make to remove rule outputs when their recipe modifies an output but fails. * The *Visual Studio Generators* learned to support ".xaml" source files and automatically associate them with corresponding ".h" and ".cpp" sources. * A new experimental "Green Hills MULTI" generator was added on Windows. Green Hills MULTI is an IDE for embedded real-time systems. Commands -------- * The "add_dependencies()" command learned to allow dependencies to be added to *interface libraries*. Dependencies added to an interface library are followed transitively in its place since the target itself does not build. * The "execute_process()" command learned to support specifying the same file for "OUTPUT_FILE" and "ERROR_FILE". * The "file(GLOB)" and "file(GLOB_RECURSE)" commands learned a new "LIST_DIRECTORIES " option to specify whether the glob result should include directories. * The "find_library()", "find_path()", and "find_file()" commands now search in installation prefixes derived from the "PATH" environment variable. * The "if()" command learned a new "IN_LIST" operator that evaluates to true if a given element is contained in a named list. * The "install(EXPORT)" and "export()" commands learned to export targets that populate the "INTERFACE_SOURCES" target property. * The "install(TARGETS)" command learned to support generator expressions in the "DESTINATION" value. Variables --------- * The version of some Fortran compilers is now detected and stored in the "CMAKE_Fortran_COMPILER_VERSION" variable. * The *Visual Studio Generators* learned a new "CMAKE_VS_INCLUDE_INSTALL_TO_DEFAULT_BUILD" option to put the "INSTALL" target in the default build of a solution (".sln") file. Properties ---------- * A "CROSSCOMPILING_EMULATOR" target property and supporting "CMAKE_CROSSCOMPILING_EMULATOR" variable were introduced to allow target platform binaries to run on the host during cross compiling. * A "_INCLUDE_WHAT_YOU_USE" target property and supporting "CMAKE__INCLUDE_WHAT_YOU_USE" variable were introduced to tell the *Makefile Generators* and the "Ninja" generator to run "include- what-you-use" along with the compiler for "C" and "CXX" languages. * The "_VISIBILITY_PRESET" and "VISIBILITY_INLINES_HIDDEN" target properties now affect compilation in sources of all target types. See policy "CMP0063". * The "XCODE_ATTRIBUTE_" target property learned to support generator expressions. Modules ------- * The "CheckFortranCompilerFlag" module was introduced to check "Fortran" compiler flags, much like the "CheckCCompilerFlag" module already does for "C". * The "ExternalData" module learned a new "ExternalData_NO_SYMLINKS" option to disable use of symbolic links to populate the real data files and use copies instead. * The "ExternalData" module learned a new "RECURSE:" option in "DATA{}" references specifying directories. This allows an entire directory tree of associated files to be matched. * The "ExternalData" module learned a new URL template placeholder "%(algo:)" to allow custom mapping from algorithm name to URL component through configuration of new "ExternalData_URL_ALGO__" variables. This allows more flexibility in remote URLs. * The "ExternalProject" module learned to replace tokens like "" in the "BYPRODUCTS" of each step. * The "ExternalProject" module APIs learned to support "generator expressions" when using "LOG_*" options and in CMake initial cache options. * The "FindBoost" module now tracks the directories containing libraries separately for RELEASE and DEBUG configurations. * The "FindCUDA" module now defaults to using the static CUDA runtime library if it is available. A new "CUDA_USE_STATIC_CUDA_RUNTIME" option is offered to control this behavior. * The "FindMatlab" module was completely rewritten. It learned about versions and components and to find Matlab in a more precise and multiplatform way. The module now offers APIs to create mex extensions, documentation, and unit tests. * The "FindPackageHandleStandardArgs" module "FIND_PACKAGE_HANDLE_STANDARD_ARGS" function now always populates both the "_FOUND" and "_FOUND" variables (the latter for backwards compatibility). The "FOUND_VAR" option is now ignored except to enforce its allowed values. * The "InstallRequiredSystemLibraries" module learned a new "CMAKE_INSTALL_SYSTEM_RUNTIME_COMPONENT" option to specify the installation component. Generator Expressions --------------------- * A new "COMPILE_LANGUAGE" generator expression was introduced to allow specification of compile options for target files based on the "LANGUAGE" of each source file. Due to limitations of the underlying native build tools, this feature has varying support across generators. See the "cmake-generator-expressions(7)" manual for details. CTest ----- * The "ctest(1)" tool learned a new "--repeat-until-fail " option to help find sporadic test failures. * The "CTestCoverageCollectGCOV" module learned to support the same "CTEST_CUSTOM_COVERAGE_EXCLUDE" option as the "ctest_coverage()" command. CPack ----- * The "cpack(1)" "IFW" generator and the "CPackIFW" module learned to support Qt Framework Installer 2.0 tools. * The "CPackDeb" module learned a new "CPACK_DEBIAN__PACKAGE_SHLIBDEPS" variable to specify per-component use of "dpkg-shlibdeps". * The "CPackDeb" module learned a new "CPACK_DEBIAN__PACKAGE_DEPENDS" option to specify per- component dependencies. * The "CPackRPM" module learned to package symbolic links more cleanly and now supports directory symlinks with recent "rpmbuild" versions. * The "CPackRPM" module learned a new "CPACK_RPM_ADDITIONAL_MAN_DIRS" variable to specify directories containing man pages for the brp- compress RPM macro. * The "CPackRPM" module learned a new "CPACK_RPM__PACKAGE_ARCHITECTURE" variable to specify a component-specific package architecture. * The CPack WIX generator learned the new "CPACK_START_MENU_SHORTCUTS", "CPACK_DESKTOP_SHORTCUTS" and "CPACK_STARTUP_SHORTCUTS" installed file properties which can be used to install shorcuts in the Start Menu, on the Desktop and in the Startup Folder respectively. Other ----- * The "Compile Features" functionality is now aware of features supported by GNU compilers on Windows, versions 4.4 through 5.0. * The "cmake(1)" "-E tar" command learned a new "--format" option to specify the archive format to be written. * On OS X, CMake learned to create XCTest bundles to test Frameworks and App Bundles within Xcode. The "FindXCTest" module provides convenience functions to handle "XCTEST" bundles. Deprecated and Removed Features =============================== * On OS X the "cmake-gui(1)" no longer has the "Install For Command Line Use" menu item. Instead there is a "How to Install For Command Line Use" menu item that shows an informational dialog box explaining how to make the command line tools available. For example: /Applications/CMake.app/Contents/bin/cmake-gui --install * The "ctest_build()" and "build_command()" commands no longer tell "make" tools to ignore errors with the "-i" option. Previously this was done for *Makefile Generators* but not others. See policy "CMP0061". * The "Visual Studio 10 2010" generator no longer checks for running VS IDEs with the project open or asks them to reload. This was originally done for VS 10 because it had been done for VS 7 through 9 to avoid prompting for every project in a solution. Since VS >= 10 allow the whole solution to reload at once they do not need CMake to help them. * The "Visual Studio 7" generator (.NET 2002) is now deprecated and will be removed in a future version of CMake. * The "Visual Studio 6" generator is now deprecated and will be removed in a future version of CMake. * The "find_package()" command no longer considers project build trees recently configured in a "cmake-gui(1)". This was previously done only on Windows and is now never done. The "NO_CMAKE_BUILDS_PATH" option is now ignored if given and effectively always on. Projects may populate the *User Package Registry* to aid users building multiple dependent projects one after another. * The "add_definitions()" command no longer causes a "DEFINITIONS" directory property to be populated. See policy "CMP0059". * With Visual Studio 7, 8, and 9 generators the value of the "$(OutDir)" placeholder no longer evaluates to the configuration name. Projects should use "$(ConfigurationName)" for that instead. * Using the output of "export()" with the "install(FILES)" command is no longer allowed. See policy "CMP0062" for details. Other Changes ============= * The "Ninja" generator now requires that calls to the "add_custom_command()" and "add_custom_target()" commands use the "BYPRODUCTS" option to explicitly specify any files generated by the custom commands that are not listed as outputs (perhaps because their timestamps are allowed to be older than the inputs). See policy "CMP0058". * Build-time progress output of *Makefile Generators* has been improved. It no longer mixes progress and build rule messages during parallel builds. The link rule messages now have progress and are displayed as bold green instead of bold red (since red is often associated with an error message). * The "CMAKE_CFG_INTDIR" variable value for Visual Studio 7, 8, and 9 is now "$(ConfigurationName)" instead of "$(OutDir)". This should have no effect on the intended use cases of the variable. * Linking to library files by a full path in an implicit linker search directory (e.g. "/usr/lib/libfoo.a") no longer asks the linker to search for the library (e.g. "-lfoo") and now links by full path. See policy "CMP0060". ------------------------------------------------------------------- Changes made since CMake 3.3.0-rc1: Brad King (7): Help: Reference TARGET_FILE genex in add_custom_command docs (#15605) FindwxWidgets: Fix find_program call for versioned names Windows-GNU: Restore find_library treatment of '.dll' as linkable (#15409) ctest: Disable CMake Cygwin legacy warning in dashboard client script Help: Drop incorrect advice from cmake-developer.7 manual Help: Document explicitly that policy OLD behavior is deprecated CMake 3.3.0-rc2 Clinton Stimpson (1): cmake-gui: Make command-line install help text selectable ------------------------------------------------------------------- From mjklaim at gmail.com Thu Jun 11 13:18:55 2015 From: mjklaim at gmail.com (=?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?=) Date: Thu, 11 Jun 2015 19:18:55 +0200 Subject: [CMake] How does :: actually works? In-Reply-To: <1966303.10G05DjLjn@ersa> References: <1966303.10G05DjLjn@ersa> Message-ID: On 11 June 2015 at 15:22, Johannes Zarl-Zierl wrote: > Hi, > > > I tried several times now to find documentation about how to define > > and use target names which seem to have namespaces, like Qt ones. > > > > For example: add_executable( MyProject::some_target ... ) > > AFAIK target namespaces are intended for imported targets, not "regular" > targets: > > "A NAMESPACE with double-colons is specified when exporting the targets for > installation. This convention of double-colons gives CMake a hint that the > name is an IMPORTED target when it is used by downstreams with the > target_link_libraries() command. This way, CMake can issue a diagnostic if > the > package providing it has not yet been found." > [1] > > > [1] > http://www.cmake.org/cmake/help/v3.3/manual/cmake-packages.7.html?highlight=namespace > > > I can't find any documentation or even name for this. > > Is it considered a "namespace"? > > In any way I found nothing specific to this syntax in the wiki. > > The concept is called "namespace" in cmake, just as you assumed. I don't > know > if there's anything about it in the wiki, but the official documentation > has a > (very) short description in the cmake_packages[1] page, as well as in the > documentation for the export command. > (sorry I was actually thinking about the documentation and typed "wiki") Thanks, it was not totally clear that the definition of the namespace is done in another operation, so I assumed that it was just a local option, not ana actual language feature, and simply dismissed it. Maybe the concept should have it's own section? There is no mention of this in the language page. Or is it really useful only if you are writing exports? Anyway thanks, it's clearer now. > > Cheers, > Johannes > -- > > 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 ondrej.certik at gmail.com Thu Jun 11 16:39:07 2015 From: ondrej.certik at gmail.com (=?UTF-8?B?T25kxZllaiDEjGVydMOtaw==?=) Date: Thu, 11 Jun 2015 14:39:07 -0600 Subject: [CMake] What is the recommended ways to find libraries Message-ID: Hi, What is the official recommended way to make your project depend on other libraries using cmake? Let's say my project wants to depend on a library PKG1 (here PKG1 can be MPFR, MPC, PTHREAD, GMP, BZIP2, you name it). Let's say the library is installed in $PKG1/include, $PKG1/lib, alternatively, all my dependencies are installed in $HASHSTACK/include and $HASHSTACK/lib, or perhaps they are installed system wide. As a user, I would like at least the following ways to specify the library: 1. cmake -DPKG1_INCLUDE_DIRS=$PKG1/include -DPKG1_LIBRARIES=$PKG1/lib 2. cmake -DPKG1_DIR=$PKG1 3. cmake -DCOMMON_DIR=$HASHSTACK 4. cmake For more than 1 package, I want to chain it on the command line, i.e. cmake -DPKG1_DIR=$PKG1 -DPKG2_DIR=$PKG2 ... In the above, 1. specifies the include and library paths separately, 2. specifies the root installation directory, 3. specifies the root installation directory for all dependencies (but if you specify let's say PKG3 using 1. or 2., it will take precedence) and 4. just uses systemwide. We can find a better name for COMMON_DIR (perhaps TPL_ROOT_DIR, or TPL_COMMON_DIR, ...). The only official documentation that I was able to find is this: http://www.cmake.org/Wiki/CMake:How_To_Find_Libraries Notice that they recommend to do per project programming, so in particular, each project must implement the above rules, and so each project does, and implements it slightly differently, some projects for example skip the -DPKG1_DIR option. The wiki also recommends to use Using_LibFindMacros, which again, requires per project programming. Perhaps I am missing the official recommendation regarding the above, so that's why I am asking here. But if there is none, then I think the current state is unsatisfactory. Such functionality should be in cmake itself, and projects should just use it. For projects that I am involved in, we implemented the following: https://github.com/sympy/symengine/blob/a4b2c773f2286c6efb06e70894b672032e345faf/cmake/LibFindMacros.cmake https://github.com/sympy/symengine/blob/a4b2c773f2286c6efb06e70894b672032e345faf/cmake/FindGMP.cmake https://github.com/sympy/symengine/blob/a4b2c773f2286c6efb06e70894b672032e345faf/CMakeLists.txt#L41 You can see the libfind_include(), libfind_library() definitions, how they are used in FindGMP and finally how FindGMP is used in the main CMakeLists.txt. These macros implement the above. It is unsatisfactory, that now I need to copy this to all other projects, that would like to use this and projects that already programmed a similar, but incompatible solution cannot use it at all. Here is a list of all our (mostly optional) dependencies: https://github.com/sympy/symengine/tree/a4b2c773f2286c6efb06e70894b672032e345faf/cmake Some packages like Cython and Python require special code, but for most libraries that have couple include files and couple installed libraries, this works excellent. We would be happy to contribute something like that into cmake itself, so that any project can use it. But it's weird to me, that nobody has done it yet, so perhaps we are fundamentally misunderstanding how to depend on external libraries with a cmake project. Thanks, Ondrej Certik From Dave at Yost.com Thu Jun 11 20:00:23 2015 From: Dave at Yost.com (Dave Yost) Date: Thu, 11 Jun 2015 17:00:23 -0700 Subject: [CMake] output of add_custom_command as target in Makefile Message-ID: <67A81FD0-E6A3-418D-BBE3-135003FE8F85@yost.com> In this example, how do I get make foo.cc to work? 0 Thu 16:56:19 yost DaveBook ~/p/c++/cmake/custom-command-target 369 Z% bundle CMakeLists.txt genFoo #!/usr/bin/env unbundle # See http://yost.com/computers/bundle/ ======== CMakeLists.txt cmake_minimum_required(VERSION 3.3.0) project(custom-command-target) add_custom_command ( OUTPUT foo.cc COMMAND ${CMAKE_CURRENT_SOURCE_DIR}/genFoo > foo.cc ) add_executable (foo foo.cc) ======== genFoo #!/bin/bash echo " int main() { return 0; }" ======== 0 Thu 16:56:23 yost DaveBook ~/p/c++/cmake/custom-command-target 370 Z% cd build 0 Thu 16:56:36 yost DaveBook ~/p/c++/cmake/custom-command-target/build 371 Z% cmake .. -- Configuring done -- Generating done -- Build files have been written to: /Users/yost/p/c++/cmake/custom-command-target/build 0 Thu 16:56:41 yost DaveBook ~/p/c++/cmake/custom-command-target/build 372 Z% make clean 0 Thu 16:56:45 yost DaveBook ~/p/c++/cmake/custom-command-target/build 373 Z% make foo.cc make: *** No rule to make target 'foo.cc'. Stop. 2 Thu 16:56:49 yost DaveBook ~/p/c++/cmake/custom-command-target/build 374 Z% -------------- next part -------------- An HTML attachment was scrubbed... URL: From csiga.biga at aol.com Fri Jun 12 03:24:42 2015 From: csiga.biga at aol.com (=?utf-8?Q?Nagy-Egri_M=C3=A1t=C3=A9_Ferenc?=) Date: Fri, 12 Jun 2015 07:24:42 +0000 Subject: [CMake] =?utf-8?q?output_of_add=5Fcustom=5Fcommand_as_target_in_M?= =?utf-8?q?akefile?= In-Reply-To: <67A81FD0-E6A3-418D-BBE3-135003FE8F85@yost.com> References: <67A81FD0-E6A3-418D-BBE3-135003FE8F85@yost.com> Message-ID: You?re doing it all wrong. You do not name source files as make targets, but the target name (or project name, I have no idea, because it rarely makes sense to name them differently). Try simply ?foo? or ?custom-command-target?. You would never say ?make foo.cpp?, not even in an ordinary GNU Make script. Felad?: Dave Yost Elk?ldve: ?p?ntek?, ?2015?. ?j?nius? ?12?. ?2?:?00 C?mzett: cmake at cmake.org In this example, how do I get make foo.cc to work? 0 Thu 16:56:19 yost DaveBook ~/p/c++/cmake/custom-command-target 369 Z% bundle CMakeLists.txt genFoo #!/usr/bin/env unbundle # See http://yost.com/computers/bundle/ ======== CMakeLists.txt cmake_minimum_required(VERSION 3.3.0) project(custom-command-target) add_custom_command ( OUTPUT foo.cc COMMAND ${CMAKE_CURRENT_SOURCE_DIR}/genFoo > foo.cc ) add_executable (foo foo.cc) ======== genFoo #!/bin/bash echo " int main() { return 0; }" ======== 0 Thu 16:56:23 yost DaveBook ~/p/c++/cmake/custom-command-target 370 Z% cd build 0 Thu 16:56:36 yost DaveBook ~/p/c++/cmake/custom-command-target/build 371 Z% cmake .. -- Configuring done -- Generating done -- Build files have been written to: /Users/yost/p/c++/cmake/custom-command-target/build 0 Thu 16:56:41 yost DaveBook ~/p/c++/cmake/custom-command-target/build 372 Z% make clean 0 Thu 16:56:45 yost DaveBook ~/p/c++/cmake/custom-command-target/build 373 Z% make foo.cc make: *** No rule to make target 'foo.cc'. Stop. 2 Thu 16:56:49 yost DaveBook ~/p/c++/cmake/custom-command-target/build 374 Z% -------------- next part -------------- An HTML attachment was scrubbed... URL: From roman.wueger at gmx.at Fri Jun 12 07:19:48 2015 From: roman.wueger at gmx.at (=?iso-8859-1?Q?Roman_W=FCger?=) Date: Fri, 12 Jun 2015 13:19:48 +0200 Subject: [CMake] Problems when creating config files and add_dependencies Message-ID: <07e401d0a501$b1e77230$15b65690$@gmx.at> Hello, short description: I want to have a configuration header file per unit test. For this purpose I wrote the following function, which creates a header file in ?${CURRENT_BINARY_DIR}? and copy all test files into the binary directory. Howewer, I got it to work when I use add_custom_target as pre_build target, but this doesn?t work on *nix systems. So here is the current function: function(CopyUnitTestFiles projectName) set(UnitTestConfigName "${projectName}UnitTestConfig") set(UNITTESTCONFIGNAME "${projectName}UnitTestConfig") set(PROJECT_NAME ${projectName}) set(OUTPUT_FILENAME "${CMAKE_CURRENT_BINARY_DIR}/${UnitTestConfigName}.cmake") set(HEADER_INPUT_FILENAME "${CMAKE_SOURCE_DIR}/cmake/UnitTestConfig.h.in") set(HEADER_OUTPUT_FILENAME "${CMAKE_CURRENT_BINARY_DIR}/${UnitTestConfigName}.h") set(CURRENT_FILENAME "${OUTPUT_FILENAME}") set(RELATIVE_FILEPATH "testfiles/${projectName}") set(INCLUDE_GUARD "${projectName}_UNITTESTCONFIG_H") string(TOUPPER ${INCLUDE_GUARD} INCLUDE_GUARD) set(TARGET_FILE_DIR $) set(CopyUnitTestFilesProjectName CopyUnitTestFiles_${projectName}) configure_file(${CMAKE_SOURCE_DIR}/cmake/UnitTestConfig.cmake.in ${OUTPUT_FILENAME} @ONLY) add_custom_target(${CopyUnitTestFilesProjectName} COMMAND ${CMAKE_COMMAND} -DABSFILEPATH=${TARGET_FILE_DIR} -P ${OUTPUT_FILENAME} COMMAND ${CMAKE_COMMAND} -E remove_directory ${TARGET_FILE_DIR}/testfiles/${projectName} COMMAND ${CMAKE_COMMAND} -E copy_directory ${CMAKE_CURRENT_SOURCE_DIR}/data/testfiles ${TARGET_FILE_DIR}/testfiles/${projectName} ) set_property(TARGET ${CopyUnitTestFilesProjectName} PROPERTY FOLDER "Custom Targets/CopyUnitTestFiles") add_dependencies(${projectName} ${CopyUnitTestFilesProjectName}) endfunction(CopyUnitTestFiles) The function should be called like: project(UnitTest1) add_executable(${PROJECT_NAME} ${HEADERS} ${SOURCES}) target_link_libraries(${PROJECT_NAME} gtest gtest_main) CopyUnitTestFiles(${PROJECT_NAME}) The error message which I get: -- Configuring done CMake Error: The inter-target dependency graph contains the following strongly connected component (cycle): "CopyUnitTestFiles_UnitTest1" of type UTILITY depends on "UnitTest1" (strong) "UnitTest1" of type EXECUTABLE depends on "CopyUnitTestFiles_UnitTest1" (strong) At least one of these targets is not a STATIC_LIBRARY. Cyclic dependencies are allowed only among static libraries. UnitTestConfig.cmake.in: set(ProjectName "@PROJECT_NAME@") set(UnitTestConfigName "@UNITTESTCONFIGNAME@") set(NAMESPACE "${UnitTestConfigName}") set(UNITTESTNAME "${ProjectName}") set(RELATIVE_FILEPATH "testfiles/${ProjectName}") set(ABSOLUTE_FILEPATH "${ABSFILEPATH}/testfiles/${ProjectName}") set(INCLUDE_GUARD "${ProjectName}_UNITTESTCONFIG_H") string(TOUPPER ${INCLUDE_GUARD} INCLUDE_GUARD) configure_file("@HEADER_INPUT_FILENAME@" "@HEADER_OUTPUT_FILENAME@") UnitTestConfig.h.in: #ifndef @INCLUDE_GUARD@ #define @INCLUDE_GUARD@ namespace @NAMESPACE@ { const char *const UnitTestName = "@UNITTESTNAME@"; const char *const RelativeTestFilesPath = "@RELATIVE_FILEPATH@"; const char *const AbsoluteTestFilesPath = "@ABSOLUTE_FILEPATH@"; const wchar_t *const UnitTestNameW= L"@UNITTESTNAME@"; const wchar_t *const RelativeTestFilesPathW = L"@RELATIVE_FILEPATH@"; const wchar_t *const AbsoluteTestFilesPathW = L"@ABSOLUTE_FILEPATH@"; } #endif // @INCLUDE_GUARD@ It would be great if generator expressions can be used with configure_file to avoid such overhead. Does anyone have an idea on how to solve that? Best Regards Roman -------------- next part -------------- An HTML attachment was scrubbed... URL: From roman.wueger at gmx.at Fri Jun 12 07:55:17 2015 From: roman.wueger at gmx.at (=?UTF-8?Q?Roman_W=C3=BCger?=) Date: Fri, 12 Jun 2015 13:55:17 +0200 Subject: [CMake] [cmake-developers] Virtual folders in Visual studio get expanded on reload In-Reply-To: <0458DF31F610EF42BFC78C497E806C7B458AB8FF@ECS-EXG-P-MB03.win.lanl.gov> References: <0458DF31F610EF42BFC78C497E806C7B458AB8FF@ECS-EXG-P-MB03.win.lanl.gov> Message-ID: <081801d0a506$a801c720$f8055560$@gmx.at> @kgt: Thank you for this great hint. :-) I had overlooked this button in Visual Studio @mjklaim: I didn't see this behavior in older CMake versions. Roman > -----Urspr?ngliche Nachricht----- > Von: Thompson, KT [mailto:kgt at lanl.gov] > Gesendet: Dienstag, 02. Juni 2015 15:52 > An: Roman W?ger; CMake MailingList > Betreff: RE: [cmake-developers] Virtual folders in Visual studio get expanded > on reload > > Roman, > > I have the same complaint. My project has about 300 targets arranged in two > dozen folders. I use the "collapse all" button in Visual Studio's Solution > Explorer window (looks like a stack of 3 squares in VS2013). > > kt > > -----Original Message----- > From: cmake-developers [mailto:cmake-developers-bounces at cmake.org] > On Behalf Of Roman W?ger > Sent: Monday, June 01, 2015 5:00 PM > To: CMake Developer MailingList; CMake MailingList > Subject: [cmake-developers] Virtual folders in Visual studio get expanded on > reload > > Hi, > > I noticed that sometimes when a target is reloaded, that the virtual folders > and targets for the complete visual studio solution get expanded. > For a small project this isn't a problem, but in a large project (~ 100 targets) > this is a really big problem to close all targets every time. > > Did anybody noticed this behavior and has a solution for it? > > Thanks > > Best Regards > Roman > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake-developers From Dave at Yost.com Fri Jun 12 09:20:23 2015 From: Dave at Yost.com (Dave Yost) Date: Fri, 12 Jun 2015 06:20:23 -0700 Subject: [CMake] output of add_custom_command as target in Makefile In-Reply-To: <20150612072751.A3B86714082@homiemail-mx4.g.dreamhost.com> References: <67A81FD0-E6A3-418D-BBE3-135003FE8F85@yost.com> <20150612072751.A3B86714082@homiemail-mx4.g.dreamhost.com> Message-ID: <94ECE0F3-00DF-4E95-8A70-75CD19F548DE@yost.com> I?m not doing it wrong. Remember, this is a simplified example. We want to be able to make foo.cc so we can look at it and compare it. Yes, we could make foo and then look at foo.cc, but until foo.cc is right, we will suffer a lot of compiler error clutter. When foo.cc looks right, then we will make foo. BTW, changing add_custom_command to add_custom_target has no apparent effect and doesn?t help. > On 2015-06-12, at 12:24 AM, Nagy-Egri M?t? Ferenc wrote: > > You?re doing it all wrong. You do not name source files as make targets, but the target name (or project name, I have no idea, because it rarely makes sense to name them differently). Try simply ?foo? or ?custom-command-target?. You would never say ?make foo.cpp?, not even in an ordinary GNU Make script. > > Felad?: Dave Yost > Elk?ldve: ?p?ntek?, ?2015?. ?j?nius? ?12?. ?2?:?00 > C?mzett: cmake at cmake.org > > In this example, how do I get > make foo.cc > to work? > > 0 Thu 16:56:19 yost DaveBook ~/p/c++/cmake/custom-command-target > 369 Z% bundle CMakeLists.txt genFoo > #!/usr/bin/env unbundle > # See http://yost.com/computers/bundle/ > ======== CMakeLists.txt > cmake_minimum_required(VERSION 3.3.0) > > project(custom-command-target) > > > add_custom_command ( > OUTPUT foo.cc > COMMAND ${CMAKE_CURRENT_SOURCE_DIR}/genFoo > foo.cc > ) > > add_executable (foo foo.cc ) > > ======== genFoo > #!/bin/bash > > echo " > int main() { > return 0; > }" > ======== > 0 Thu 16:56:23 yost DaveBook ~/p/c++/cmake/custom-command-target > 370 Z% cd build > 0 Thu 16:56:36 yost DaveBook ~/p/c++/cmake/custom-command-target/build > 371 Z% cmake .. > -- Configuring done > -- Generating done > -- Build files have been written to: /Users/yost/p/c++/cmake/custom-command-target/build > 0 Thu 16:56:41 yost DaveBook ~/p/c++/cmake/custom-command-target/build > 372 Z% make clean > 0 Thu 16:56:45 yost DaveBook ~/p/c++/cmake/custom-command-target/build > 373 Z% make foo.cc > make: *** No rule to make target 'foo.cc '. Stop. > 2 Thu 16:56:49 yost DaveBook ~/p/c++/cmake/custom-command-target/build > 374 Z% -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkarascybi at gmail.com Fri Jun 12 10:46:47 2015 From: mkarascybi at gmail.com (Matthew Karas) Date: Fri, 12 Jun 2015 10:46:47 -0400 Subject: [CMake] Installing systemd service files that point to my installed location Message-ID: This is probably and XY problem but... I'm trying to install a systemd file in my cmake. The service file needs to point at the installed destination of my build after I "make install". I was trying to use "CONFIGURE_FILE" When I tried to do this - the variable is blank because the configure file occurs during the cmake setup part - not the make install DESTDIR=~/blah part. Is there any way to configure files while I'm installing them, or to configure a file as part of a post install script? Thanks, Matt From glenn.coombs at gmail.com Fri Jun 12 11:40:43 2015 From: glenn.coombs at gmail.com (Glenn Coombs) Date: Fri, 12 Jun 2015 16:40:43 +0100 Subject: [CMake] output of add_custom_command as target in Makefile In-Reply-To: <94ECE0F3-00DF-4E95-8A70-75CD19F548DE@yost.com> References: <67A81FD0-E6A3-418D-BBE3-135003FE8F85@yost.com> <20150612072751.A3B86714082@homiemail-mx4.g.dreamhost.com> <94ECE0F3-00DF-4E95-8A70-75CD19F548DE@yost.com> Message-ID: If you run "make help" it will list targets it understands. And as you pointed out there is no target for foo.cc. You can "make foo" but if you really want a target for foo.cc you can add one yourself: cmake_minimum_required(VERSION 3.0.0) project(custom-command-target) add_custom_command ( OUTPUT foo.cc COMMAND ${CMAKE_CURRENT_SOURCE_DIR}/genFoo > foo.cc ) add_custom_target(foo.cc DEPENDS ${CMAKE_BINARY_DIR}/foo.cc) add_executable (foo foo.cc) That should create a foo.cc target that you can run that will do the right thing. -- Glenn On 12 June 2015 at 14:20, Dave Yost wrote: > I?m not doing it wrong. Remember, this is a simplified example. > > We want to be able to make foo.cc so we can look at it and compare it. > Yes, we could make foo and then look at foo.cc, but until foo.cc is > right, we will suffer a lot of compiler error clutter. When foo.cc looks > right, then we will make foo. > > BTW, changing add_custom_command to add_custom_target has no apparent > effect and doesn?t help. > > On 2015-06-12, at 12:24 AM, Nagy-Egri M?t? Ferenc > wrote: > > You?re doing it all wrong. You do not name source files as make targets, > but the target name (or project name, I have no idea, because it rarely > makes sense to name them differently). Try simply ?foo? > or ?custom-command-target?. You would never say ?make foo.cpp?, not even in > an ordinary GNU Make script. > > *Felad?:* Dave Yost > *Elk?ldve:* ?p?ntek?, ?2015?. ?j?nius? ?12?. ?2?:?00 > *C?mzett:* cmake at cmake.org > > In this example, how do I get > make foo.cc > to work? > > 0 Thu 16:56:19 yost DaveBook ~/p/c++/cmake/custom-command-target > 369 Z% bundle CMakeLists.txt genFoo > #!/usr/bin/env unbundle > # See http://yost.com/computers/bundle/ > ======== CMakeLists.txt > cmake_minimum_required(VERSION 3.3.0) > > project(custom-command-target) > > > add_custom_command ( > OUTPUT foo.cc > COMMAND ${CMAKE_CURRENT_SOURCE_DIR}/genFoo > foo.cc > ) > > add_executable (foo foo.cc) > > ======== genFoo > #!/bin/bash > > echo " > int main() { > return 0; > }" > ======== > 0 Thu 16:56:23 yost DaveBook ~/p/c++/cmake/custom-command-target > 370 Z% cd build > 0 Thu 16:56:36 yost DaveBook ~/p/c++/cmake/custom-command-target/build > 371 Z% cmake .. > -- Configuring done > -- Generating done > -- Build files have been written to: > /Users/yost/p/c++/cmake/custom-command-target/build > 0 Thu 16:56:41 yost DaveBook ~/p/c++/cmake/custom-command-target/build > 372 Z% make clean > 0 Thu 16:56:45 yost DaveBook ~/p/c++/cmake/custom-command-target/build > 373 Z% make foo.cc > make: *** No rule to make target 'foo.cc'. Stop. > 2 Thu 16:56:49 yost DaveBook ~/p/c++/cmake/custom-command-target/build > 374 Z% > > > > -- > > 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 Fri Jun 12 12:20:57 2015 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Fri, 12 Jun 2015 18:20:57 +0200 Subject: [CMake] Installing systemd service files that point to my installed location In-Reply-To: References: Message-ID: Am 12. Juni 2015 16:46:47 MESZ, schrieb Matthew Karas : >This is probably and XY problem but... > >I'm trying to install a systemd file in my cmake. > >The service file needs to point at the installed destination of my >build after I "make install". > >I was trying to use "CONFIGURE_FILE" > >When I tried to do this - the variable is blank because the configure >file occurs during the cmake setup part - not the make install >DESTDIR=~/blah part. > >Is there any way to configure files while I'm installing them, or to >configure a file as part of a post install script? You should not base generated file content on DESTDIR as this should be used e.g. for packaging to an intermediate directory. Use only CMAKE_INSTALL_PREFIX. You can use configure_file() for this. HS From zbeekman at gmail.com Fri Jun 12 13:46:04 2015 From: zbeekman at gmail.com (Zaak Beekman) Date: Fri, 12 Jun 2015 17:46:04 +0000 Subject: [CMake] option for gcov coverage and overriding optimization flag Message-ID: I?m having trouble determining the right way to enforce `-O0` optimization level when the user selects a boolean cache entry to enable code coverage with gcov. I tried something like: if ( ENABLE_CODE_COVERAGE ) set ( CMAKE_Fortran_FLAGS ?${CMAKE_Fortran_FLAGS} -fprofile-arcs -ftest-coverage -O0? ) but the issue is that the CMAKE_Fortran_FLAGS_ flags get appended to the compiler flags so gfortran gets passed something like: `gfortran -fprofile-arcs -ftest-coverage -O0 ? -O3 ?` and since the `-O3` the right-most optimization option it takes precedent over `-O0`. What is the correct way to either ensure that `-O0` comes after `-O3` when the user selects ENABLE_CODE_COVERAGE=TRUE or remove `-O3` entirely? Note that CMAKE_Fortran_FLAGS_ are all (advanced) cache variables, and I would like to let advanced users have the option to re-enable optimization here should they so choose? -------------- next part -------------- An HTML attachment was scrubbed... URL: From Dave at Yost.com Fri Jun 12 15:35:19 2015 From: Dave at Yost.com (Dave Yost) Date: Fri, 12 Jun 2015 12:35:19 -0700 Subject: [CMake] output of add_custom_command as target in Makefile In-Reply-To: References: <67A81FD0-E6A3-418D-BBE3-135003FE8F85@yost.com> <20150612072751.A3B86714082@homiemail-mx4.g.dreamhost.com> <94ECE0F3-00DF-4E95-8A70-75CD19F548DE@yost.com> Message-ID: Hooray! Thanks! Could a future version of cmake provide a nicer way to do this, without these error messages? 0 Fri 12:29:25 yost DaveBook ~/p/c++/cmake/custom-command-target/build 391 Z% make foo.cc Scanning dependencies of target foo.cc make[3]: Circular CMakeFiles/foo.cc <- foo.cc dependency dropped. make[3]: Circular foo.cc <- foo.cc dependency dropped. [100%] Generating foo.cc [100%] Built target foo.cc 0 Fri 12:29:27 yost DaveBook ~/p/c++/cmake/custom-command-target/build 392 Z% > On 2015-06-12, at 8:40 AM, Glenn Coombs wrote: > > If you run "make help" it will list targets it understands. And as you pointed out there is no target for foo.cc. You can "make foo" but if you really want a target for foo.cc you can add one yourself: > > cmake_minimum_required(VERSION 3.0.0) > > project(custom-command-target) > > add_custom_command ( > OUTPUT foo.cc > COMMAND ${CMAKE_CURRENT_SOURCE_DIR}/genFoo > foo.cc > ) > > add_custom_target(foo.cc DEPENDS ${CMAKE_BINARY_DIR}/foo.cc) > > add_executable (foo foo.cc) > > That should create a foo.cc target that you can run that will do the right thing. > > -- > Glenn > > On 12 June 2015 at 14:20, Dave Yost > wrote: > I?m not doing it wrong. Remember, this is a simplified example. > > We want to be able to make foo.cc so we can look at it and compare it. Yes, we could make foo and then look at foo.cc , but until foo.cc is right, we will suffer a lot of compiler error clutter. When foo.cc looks right, then we will make foo. > > BTW, changing add_custom_command to add_custom_target has no apparent effect and doesn?t help. > >> On 2015-06-12, at 12:24 AM, Nagy-Egri M?t? Ferenc > wrote: >> >> You?re doing it all wrong. You do not name source files as make targets, but the target name (or project name, I have no idea, because it rarely makes sense to name them differently). Try simply ?foo? or ?custom-command-target?. You would never say ?make foo.cpp?, not even in an ordinary GNU Make script. >> >> Felad?: Dave Yost >> Elk?ldve: ?p?ntek?, ?2015?. ?j?nius? ?12?. ?2?:?00 >> C?mzett: cmake at cmake.org >> >> In this example, how do I get >> make foo.cc >> to work? >> >> 0 Thu 16:56:19 yost DaveBook ~/p/c++/cmake/custom-command-target >> 369 Z% bundle CMakeLists.txt genFoo >> #!/usr/bin/env unbundle >> # See http://yost.com/computers/bundle/ >> ======== CMakeLists.txt >> cmake_minimum_required(VERSION 3.3.0) >> >> project(custom-command-target) >> >> >> add_custom_command ( >> OUTPUT foo.cc >> COMMAND ${CMAKE_CURRENT_SOURCE_DIR}/genFoo > foo.cc >> ) >> >> add_executable (foo foo.cc ) >> >> ======== genFoo >> #!/bin/bash >> >> echo " >> int main() { >> return 0; >> }" >> ======== >> 0 Thu 16:56:23 yost DaveBook ~/p/c++/cmake/custom-command-target >> 370 Z% cd build >> 0 Thu 16:56:36 yost DaveBook ~/p/c++/cmake/custom-command-target/build >> 371 Z% cmake .. >> -- Configuring done >> -- Generating done >> -- Build files have been written to: /Users/yost/p/c++/cmake/custom-command-target/build >> 0 Thu 16:56:41 yost DaveBook ~/p/c++/cmake/custom-command-target/build >> 372 Z% make clean >> 0 Thu 16:56:45 yost DaveBook ~/p/c++/cmake/custom-command-target/build >> 373 Z% make foo.cc >> make: *** No rule to make target 'foo.cc '. Stop. >> 2 Thu 16:56:49 yost DaveBook ~/p/c++/cmake/custom-command-target/build >> 374 Z% > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcdailey.lists at gmail.com Fri Jun 12 17:16:26 2015 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Fri, 12 Jun 2015 16:16:26 -0500 Subject: [CMake] Accessing source directory of a target Message-ID: Hello, Is there a SOURCE_DIR property for targets? I wasn't able to find anything in the documentation on this, however I thought I saw something similar to this a few years ago. I'm using CMake 3.2. Basically I want the equivalent of CMAKE_CURRENT_SOURCE_DIR, but for a specific project. Documentation states you can do _SOURCE_DIR, but this value is empty for me. Unless this is for projects, not targets (i.e. the value passed to the project() command). Thanks in advance. From rjvbertin at gmail.com Sat Jun 13 10:51:26 2015 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Sat, 13 Jun 2015 16:51:26 +0200 Subject: [CMake] wrapping a macro Message-ID: <9100183.s9QHbh9Ivd@patux.local> Hello, Is it possible to wrap an existing macro that returns a result via one of its arguments? I think it will be clear what I would like to do from the following example: if(${INTRINSICS_TEST_TYPE} MATCHES "compiles") macro(check_intrinsics_availability source var) check_c_source_compiles(source var) endmacro() elseif(${INTRINSICS_TEST_TYPE} MATCHES "runs") include(CheckCSourceRuns) macro(check_intrinsics_availability source var) check_c_source_runs(source var) endmacro() elseif(${INTRINSICS_TEST_TYPE} MATCHES "none") macro(check_intrinsics_availability source var) set(${var} 1) set(${var}_EXITCODE 0) endmacro() else() macro(check_intrinsics_availability source var) set(${var} 0) set(${var}_EXITCODE 1) endmacro() endif() This does not have the intended effect: when INTRINSICS_TEST_TYPE == "compiles", cmake prints "Performing test var - Failed". Evidently I'd like it to perform test ${var}, in other words, the check_intrinsics_availability macro should behave exactly as either check_c_source_compiles or check_c_source_runs. Additionally, the "none" and fallback cases are supposed to behave if check_c_source_?? succeeded or failed, respectively. Are they implemented correctly? Thanks, R. From a.neundorf-work at gmx.net Sat Jun 13 16:18:48 2015 From: a.neundorf-work at gmx.net (Alexander Neundorf) Date: Sat, 13 Jun 2015 22:18:48 +0200 Subject: [CMake] cross compiling with sdcc In-Reply-To: <0C30A697-C3DB-4400-8269-A69EA79DC6E5@Robitzki.de> References: <0C30A697-C3DB-4400-8269-A69EA79DC6E5@Robitzki.de> Message-ID: <1865149.1O4BFgnYP3@tuxedo.neundorf.net> On Friday, May 29, 2015 11:14:06 Torsten at Robitzki.de wrote: > Hello, > I was looking for some resources on how to configure cmake to use the small > device c compiler (sdcc). I tried a little bit and found that cmake assumed > that the object file extension would be .obj. But sdcc uses .rel for object > files. I?ve searched a lot in the web and the cmake sources, tried to > figure out, how the compiler detection mechanism works. > > I saw that there is a file Platform/Generic-SDCC-C.cmake, while searching > for a way to force cmake to use this file, I found a makro > CMAKE_FORCE_C_COMPILER that let me override the compiler detection. > > So now I have a working solution and wonder if that solution is one > ?correct? solution. ?correct? in terms of supported and intended by the > developers. > > cmake_minimum_required(VERSION 3.2) > include (CMakeForceCompiler) > set(CMAKE_SYSTEM_NAME Generic) > CMAKE_FORCE_C_COMPILER(sdcc SDCC) > > project(test C) > > Does this looks reasonable? Thank you very much for your time! you shouldn't have to use cmake_force_c_compiler(). You did try setting up a toolchain file which points to sdcc ? Alex From a.neundorf-work at gmx.net Sat Jun 13 16:22:16 2015 From: a.neundorf-work at gmx.net (Alexander Neundorf) Date: Sat, 13 Jun 2015 22:22:16 +0200 Subject: [CMake] How to choose a compiler different from default? In-Reply-To: References: Message-ID: <2411354.vhbkLVpHHr@tuxedo.neundorf.net> On Sunday, June 07, 2015 17:39:39 Peng Yu wrote: > Hi, I following the following steps to compile gtest. > > https://code.google.com/p/tonatiuh/wiki/GoogleTest > > But the following output shows that it uses the default compiler on > Mac OS X. I want to use some other compiler. Does anybody know how to > instruct cmake to do so? Thanks. did you try setting the CC/CXX environment variables to point to the compiler you want before running cmake initially ? Alex From a.neundorf-work at gmx.net Sat Jun 13 16:26:12 2015 From: a.neundorf-work at gmx.net (Alexander Neundorf) Date: Sat, 13 Jun 2015 22:26:12 +0200 Subject: [CMake] determining which system headerfile provides a given function In-Reply-To: <2677252.MfnChCZEH7@portia.local> References: <2365905.UvL37pODeQ@patux> <2677252.MfnChCZEH7@portia.local> Message-ID: <2151979.WFpR57yxEj@tuxedo.neundorf.net> On Wednesday, June 10, 2015 01:32:21 Ren? J. V. Bertin wrote: > Ok, let me rephrase the question to see what other kind of constructive > answers that'll lead to: > > how does one check which header file provides the prototype for a function > from the system libraries? Function in question: reallocf; can apparently > be in either stdlib.h or bsd/stdlib.h . did you try check_symbol_exists() and the other similar functions ? Alex From a.neundorf-work at gmx.net Sat Jun 13 16:29:51 2015 From: a.neundorf-work at gmx.net (Alexander Neundorf) Date: Sat, 13 Jun 2015 22:29:51 +0200 Subject: [CMake] How does :: actually works? In-Reply-To: References: <1966303.10G05DjLjn@ersa> Message-ID: <2047991.UhN35aOpPK@tuxedo.neundorf.net> On Thursday, June 11, 2015 19:18:55 Klaim - Jo?l Lamotte wrote: > On 11 June 2015 at 15:22, Johannes Zarl-Zierl > > wrote: > > Hi, > > > > > I tried several times now to find documentation about how to define > > > and use target names which seem to have namespaces, like Qt ones. > > > > > > For example: add_executable( MyProject::some_target ... ) > > > > AFAIK target namespaces are intended for imported targets, not "regular" > > targets: > > > > "A NAMESPACE with double-colons is specified when exporting the targets > > for > > installation. This convention of double-colons gives CMake a hint that the > > name is an IMPORTED target when it is used by downstreams with the > > target_link_libraries() command. This way, CMake can issue a diagnostic if > > the > > package providing it has not yet been found." > > [1] > > > > > > [1] > > http://www.cmake.org/cmake/help/v3.3/manual/cmake-packages.7.html?highligh > > t=namespace > > > > > > I can't find any documentation or even name for this. > > > > > Is it considered a "namespace"? > > > In any way I found nothing specific to this syntax in the wiki. > > > > The concept is called "namespace" in cmake, just as you assumed. I don't > > know > > if there's anything about it in the wiki, but the official documentation > > has a > > (very) short description in the cmake_packages[1] page, as well as in the > > documentation for the export command. > > (sorry I was actually thinking about the documentation and typed "wiki") > > Thanks, it was not totally clear that the definition of the namespace is > done > in another operation, so I assumed that it was just a local option, not ana > actual language feature, > and simply dismissed it. > Maybe the concept should have it's own section? > There is no mention of this in the language page. Or is it really useful > only if you are writing exports? > > Anyway thanks, it's clearer now. What do you actually want to do with the "namespace" ? cmake does not really have namespaces, what the documentation talks about is only used as a hint when using imported targets. Alex From rjvbertin at gmail.com Sat Jun 13 17:17:37 2015 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Sat, 13 Jun 2015 23:17:37 +0200 Subject: [CMake] determining which system headerfile provides a given function In-Reply-To: <2151979.WFpR57yxEj@tuxedo.neundorf.net> References: <2365905.UvL37pODeQ@patux> <2677252.MfnChCZEH7@portia.local> <2151979.WFpR57yxEj@tuxedo.neundorf.net> Message-ID: <4940927.LaEBni3ykD@portia.local> On Saturday June 13 2015 22:26:12 Alexander Neundorf wrote: > did you try check_symbol_exists() and the other similar functions ? Yes, but none that I could find give any information beyond whether the symbol exists. It may be possible (or necessary) to repeat such tests trying each of the possible candidate header files in succession until a hit is found, but as I said in my initial email, that doesn't work. That's about all there's to say about it: I presume this approach doesn't work because of caching intended to avoid testing the same thing twice. Ren? From Torsten at Robitzki.de Sat Jun 13 17:26:59 2015 From: Torsten at Robitzki.de (Torsten at Robitzki.de) Date: Sat, 13 Jun 2015 23:26:59 +0200 Subject: [CMake] cross compiling with sdcc In-Reply-To: <1865149.1O4BFgnYP3@tuxedo.neundorf.net> References: <0C30A697-C3DB-4400-8269-A69EA79DC6E5@Robitzki.de> <1865149.1O4BFgnYP3@tuxedo.neundorf.net> Message-ID: <99BCC5F8-783D-4756-8A63-79821FD3F3A5@Robitzki.de> Hi Alex, Am 13.06.2015 um 22:18 schrieb Alexander Neundorf : > On Friday, May 29, 2015 11:14:06 Torsten at Robitzki.de wrote: ? >> I saw that there is a file Platform/Generic-SDCC-C.cmake, while searching >> for a way to force cmake to use this file, I found a makro >> CMAKE_FORCE_C_COMPILER that let me override the compiler detection. > ? > you shouldn't have to use cmake_force_c_compiler(). > You did try setting up a toolchain file which points to sdcc ? could you elaborate on this solution? Would the Platform/Generic-SDCC-C.cmake file that is shipped with a normal cmake installation such a toolchain file? kind regards, Torsten From ewmailing at gmail.com Sun Jun 14 08:38:08 2015 From: ewmailing at gmail.com (Eric Wing) Date: Sun, 14 Jun 2015 05:38:08 -0700 Subject: [CMake] How do I set an Xcode property on the global/root project? Message-ID: I have been successful at setting Xcode properties on specific targets with CMake via: set_property (TARGET ${TARGET} PROPERTY XCODE_ATTRIBUTE_${XCODE_PROPERTY} ${XCODE_VALUE}) But I have been unable to set properties on the global/root project. Is there a way to do this? Much of the time, I want to set a property on all my targets. I can manually set each target, but visually inspecting the Xcode project is more confusing this way because you have to understand how overrides work. It's nice to just look at the root. (And I haven't figured out how to set the built-in aggregate targets.) But more annoyingly, sometimes I'm in places in the build system where it is too early for a target or I don't have easy access to the target name. It would be much easier to just set the global project and not worry about needing a target to pass. Thanks, Eric From gjasny at googlemail.com Sun Jun 14 13:31:32 2015 From: gjasny at googlemail.com (Gregor Jasny) Date: Sun, 14 Jun 2015 19:31:32 +0200 Subject: [CMake] How do I set an Xcode property on the global/root project? In-Reply-To: References: Message-ID: <557DBA74.1080105@googlemail.com> Hi Eric, On 14/06/15 14:38, Eric Wing wrote: > I have been successful at setting Xcode properties on specific targets > with CMake via: > > set_property (TARGET ${TARGET} PROPERTY > XCODE_ATTRIBUTE_${XCODE_PROPERTY} ${XCODE_VALUE}) > > But I have been unable to set properties on the global/root project. > Is there a way to do this? The excellent CMake documentation has the answer. The XCODE_ATTRIBUTE help page here: http://www.cmake.org/cmake/help/v3.2/prop_tgt/XCODE_ATTRIBUTE_an-attribute.html Would have pointed you to CMAKE_XCODE_ATTRIBUTE > http://www.cmake.org/cmake/help/v3.2/variable/CMAKE_XCODE_ATTRIBUTE_an-attribute.html Hope that helps, Gregor From gjasny at googlemail.com Sun Jun 14 13:35:27 2015 From: gjasny at googlemail.com (Gregor Jasny) Date: Sun, 14 Jun 2015 19:35:27 +0200 Subject: [CMake] CMAKE_COLOR_MAKEFILE In-Reply-To: <2FA7BB67-7CA7-4355-B9B1-2BD7C6AF8D8A@yost.com> References: <2FA7BB67-7CA7-4355-B9B1-2BD7C6AF8D8A@yost.com> Message-ID: <557DBB5F.40203@googlemail.com> On 10/06/15 04:17, Dave Yost wrote: > Hey, I love colors. But one of my users doesn?t. You could try the Ninja generator instead of Makefile. It much often faster, as verbose as necessary, and black'n'white. Thanks, Gregor From ewmailing at gmail.com Sun Jun 14 16:21:36 2015 From: ewmailing at gmail.com (Eric Wing) Date: Sun, 14 Jun 2015 13:21:36 -0700 Subject: [CMake] How do I set an Xcode property on the global/root project? In-Reply-To: <557DBA74.1080105@googlemail.com> References: <557DBA74.1080105@googlemail.com> Message-ID: On 6/14/15, Gregor Jasny wrote: > Hi Eric, > > On 14/06/15 14:38, Eric Wing wrote: >> I have been successful at setting Xcode properties on specific targets >> with CMake via: >> >> set_property (TARGET ${TARGET} PROPERTY >> XCODE_ATTRIBUTE_${XCODE_PROPERTY} ${XCODE_VALUE}) >> >> But I have been unable to set properties on the global/root project. >> Is there a way to do this? > > The excellent CMake documentation has the answer. The XCODE_ATTRIBUTE > help page here: > http://www.cmake.org/cmake/help/v3.2/prop_tgt/XCODE_ATTRIBUTE_an-attribute.html > > Would have pointed you to CMAKE_XCODE_ATTRIBUTE >> http://www.cmake.org/cmake/help/v3.2/variable/CMAKE_XCODE_ATTRIBUTE_an-attribute.html > > Hope that helps, > Gregor > Can you elaborate on this? I can't make this work. (I remember that I tried this before and failed.) Here's an example of how I'm trying to invoke it: set_property(GLOBAL PROPERTY CMAKE_XCODE_ATTRIBUTE_SWIFT_OBJC_INTERFACE_HEADER_NAME "BlurrrSwiftInterfaceHeader.h") This seems to get ignored. (But if I use a per-target setting, then it works.) Thanks, Eric From petr.kmoch at gmail.com Mon Jun 15 05:43:12 2015 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Mon, 15 Jun 2015 11:43:12 +0200 Subject: [CMake] How do I set an Xcode property on the global/root project? In-Reply-To: References: <557DBA74.1080105@googlemail.com> Message-ID: On Sun, Jun 14, 2015 at 10:21 PM, Eric Wing wrote: > On 6/14/15, Gregor Jasny wrote: > > Hi Eric, > > > > On 14/06/15 14:38, Eric Wing wrote: > >> I have been successful at setting Xcode properties on specific targets > >> with CMake via: > >> > >> set_property (TARGET ${TARGET} PROPERTY > >> XCODE_ATTRIBUTE_${XCODE_PROPERTY} ${XCODE_VALUE}) > >> > >> But I have been unable to set properties on the global/root project. > >> Is there a way to do this? > > > > The excellent CMake documentation has the answer. The XCODE_ATTRIBUTE > > help page here: > > > http://www.cmake.org/cmake/help/v3.2/prop_tgt/XCODE_ATTRIBUTE_an-attribute.html > > > > Would have pointed you to CMAKE_XCODE_ATTRIBUTE > >> > http://www.cmake.org/cmake/help/v3.2/variable/CMAKE_XCODE_ATTRIBUTE_an-attribute.html > > > > Hope that helps, > > Gregor > > > > Can you elaborate on this? I can't make this work. (I remember that I > tried this before and failed.) > > Here's an example of how I'm trying to invoke it: > > set_property(GLOBAL PROPERTY > CMAKE_XCODE_ATTRIBUTE_SWIFT_OBJC_INTERFACE_HEADER_NAME > "BlurrrSwiftInterfaceHeader.h") > > This seems to get ignored. (But if I use a per-target setting, then it > works.) > The global setting is a variable, not a property. So you'd set it like this: set(CMAKE_XCODE_ATTRIBUTE_SWIFT_OBJC_INTERFACE_HEADER_NAME "BlurrrSwiftInterfaceHeader.h") Hope it helps. Petr -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Mon Jun 15 09:10:38 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 15 Jun 2015 09:10:38 -0400 Subject: [CMake] [cmake-developers] Problems when creating config files and add_dependencies In-Reply-To: <07e401d0a501$b1e77230$15b65690$@gmx.at> References: <07e401d0a501$b1e77230$15b65690$@gmx.at> Message-ID: <557ECECE.8030905@kitware.com> On 06/12/2015 07:19 AM, Roman W?ger wrote: > It would be great if generator expressions can be used with > configure_file to avoid such overhead. > > Does anyone have an idea on how to solve that? See file(GENERATE). -Brad From mjklaim at gmail.com Mon Jun 15 10:40:10 2015 From: mjklaim at gmail.com (=?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?=) Date: Mon, 15 Jun 2015 16:40:10 +0200 Subject: [CMake] How does :: actually works? In-Reply-To: <2047991.UhN35aOpPK@tuxedo.neundorf.net> References: <1966303.10G05DjLjn@ersa> <2047991.UhN35aOpPK@tuxedo.neundorf.net> Message-ID: On 13 June 2015 at 22:29, Alexander Neundorf wrote: > On Thursday, June 11, 2015 19:18:55 Klaim - Jo?l Lamotte wrote: > > On 11 June 2015 at 15:22, Johannes Zarl-Zierl < > johannes.zarl-zierl at jku.at> > > > > wrote: > > > Hi, > > > > > > > I tried several times now to find documentation about how to define > > > > and use target names which seem to have namespaces, like Qt ones. > > > > > > > > For example: add_executable( MyProject::some_target ... ) > > > > > > AFAIK target namespaces are intended for imported targets, not > "regular" > > > targets: > > > > > > "A NAMESPACE with double-colons is specified when exporting the targets > > > for > > > installation. This convention of double-colons gives CMake a hint that > the > > > name is an IMPORTED target when it is used by downstreams with the > > > target_link_libraries() command. This way, CMake can issue a > diagnostic if > > > the > > > package providing it has not yet been found." > > > [1] > > > > > > > > > [1] > > > > http://www.cmake.org/cmake/help/v3.3/manual/cmake-packages.7.html?highligh > > > t=namespace > > > > > > > > > I can't find any documentation or even name for this. > > > > > > > Is it considered a "namespace"? > > > > In any way I found nothing specific to this syntax in the wiki. > > > > > > The concept is called "namespace" in cmake, just as you assumed. I > don't > > > know > > > if there's anything about it in the wiki, but the official > documentation > > > has a > > > (very) short description in the cmake_packages[1] page, as well as in > the > > > documentation for the export command. > > > > (sorry I was actually thinking about the documentation and typed "wiki") > > > > Thanks, it was not totally clear that the definition of the namespace is > > done > > in another operation, so I assumed that it was just a local option, not > ana > > actual language feature, > > and simply dismissed it. > > Maybe the concept should have it's own section? > > There is no mention of this in the language page. Or is it really useful > > only if you are writing exports? > > > > Anyway thanks, it's clearer now. > > > What do you actually want to do with the "namespace" ? > cmake does not really have namespaces, what the documentation talks about > is > only used as a hint when using imported targets. > Alex > I'm trying to figure out better ways to organize my projects which have the following properties: 1. cross-platform (that part is covered by cmake) 2. are composed of a lot of different executables and libraries 3. have a lot of different dependencies. I also study the recent wave of dependency managements solutions, but that's another topic. One of my projects is open source and is a big set of tools (mostly libraries uses by one big gui tool) and I was wondering about the syntax that you can see in some projects like Qt, which have lot of tools too, so maybe it could be useful to me. So far I didn't get what imported targets helps with, so I'm a bit lost on the usefulness of "namespaces" but I am sure that I am missing something. -------------- next part -------------- An HTML attachment was scrubbed... URL: From schroeter at epsitec.ch Mon Jun 15 11:13:19 2015 From: schroeter at epsitec.ch (Mathieu Schroeter) Date: Mon, 15 Jun 2015 17:13:19 +0200 Subject: [CMake] CPack and mswindows MAX_PATH for temporary work Message-ID: <557EEB8F.7070106@epsitec.ch> Hello, Is MAX_PATH a problem with CPack? I received the following error when the destination is longer than MAX_PATH (here, 264 chars): CPack Error: Problem copying file: S:/devel/bootstrap-windev/sysroot/toolchain/var/tmp/wpkg/source/epsitec+lydia/usr/share/epsitec/lydia/cache/data/Lydia.Arc.Components/lydia/electrum-arc/components/forms/options/CheckboxField/CheckboxField.styles.js -> S:/devel/bootstrap-windev/sysroot/toolchain/var/tmp/wpkg-8424/build/_CPack_Packages/win64-Source/TGZ/epsitec+lydia_0.1.0.0////usr/share/epsitec/lydia/cache/data/Lydia.Arc.Components/lydia/electrum-arc/components/forms/options/CheckboxField/CheckboxField.styles.js set(CPACK_SOURCE_GENERATOR "TGZ") set(CPACK_SOURCE_PACKAGE_FILE_NAME "epsitec+lydia_0.1.0.0") include(CPack) If I reduce the longer, it works fine. I've just looked a bit in the sources. It seems that it uses UNC paths then I don't understand. I'm using CMake 3.2.3. Thanks Regards, Mathieu Schroeter From Anthony.R.Ette at controlsdata.com Mon Jun 15 11:31:39 2015 From: Anthony.R.Ette at controlsdata.com (Ette, Anthony (CDS)) Date: Mon, 15 Jun 2015 15:31:39 +0000 Subject: [CMake] fortran compiler failed to compile simple test program Message-ID: <2A375B5C08C24643A8A3F8CC2B98C1084BAD8011@USINDPR-MBX003.Rolls-Royce.Local> Any ideas? Our FORTRAN compiler (Concurrent Computer Corporation port of f77) is failing to compile simple test program because the linker can't find -lrt (highlighted below). Have you ever seen anything like this? How can I remedy? -- Check for working CXX compiler: /usr/bin/g++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- No build type selected, default to Debug -- The Fortran compiler identification is GNU -- Check for working Fortran compiler: /usr/ccs/bin/cf77 -- Check for working Fortran compiler: /usr/ccs/bin/cf77 -- broken CMake Error at /usr/local/cmake/share/cmake-3.2/Modules/CMakeTestFortranCompiler.cmake:54 (message): The Fortran compiler "/usr/ccs/bin/cf77" is not able to compile a simple test program. It fails with the following output: Change Dir: /home/bzpl46/sandbox/AE3007/C2/build/redhawk/CMakeFiles/CMakeTmp Run Build Command:"/usr/bin/gmake" "cmTryCompileExec3634533531/fast" /usr/bin/gmake -f CMakeFiles/cmTryCompileExec3634533531.dir/build.make CMakeFiles/cmTryCompileExec3634533531.dir/build gmake[1]: Entering directory `/home/bzpl46/sandbox/AE3007/C2/build/redhawk/CMakeFiles/CMakeTmp' /usr/local/cmake/bin/cmake -E cmake_progress_report /home/bzpl46/sandbox/AE3007/C2/build/redhawk/CMakeFiles/CMakeTmp/CMakeFiles 1 Building Fortran object CMakeFiles/cmTryCompileExec3634533531.dir/testFortranCompiler.f.o /usr/ccs/bin/cf77 -c /home/bzpl46/sandbox/AE3007/C2/build/redhawk/CMakeFiles/CMakeTmp/testFortranCompiler.f -o CMakeFiles/cmTryCompileExec3634533531.dir/testFortranCompiler.f.o /home/bzpl46/sandbox/AE3007/C2/build/redhawk/CMakeFiles/CMakeTmp/testFortranCompiler.f: Linking Fortran executable cmTryCompileExec3634533531 /usr/local/cmake/bin/cmake -E cmake_link_script CMakeFiles/cmTryCompileExec3634533531.dir/link.txt --verbose=1 /usr/ccs/bin/cf77 CMakeFiles/cmTryCompileExec3634533531.dir/testFortranCompiler.f.o -o cmTryCompileExec3634533531 -rdynamic /usr/ccs/release/7.3/lib_ia32/ld: cannot find -lrt gmake[1]: *** [cmTryCompileExec3634533531] Error 1 gmake[1]: Leaving directory `/home/bzpl46/sandbox/AE3007/C2/build/redhawk/CMakeFiles/CMakeTmp' gmake: *** [cmTryCompileExec3634533531/fast] Error 2 CMake will not be able to correctly generate this project. Call Stack (most recent call first): src/namelist/CMakeLists.txt:3 (PROJECT) -- Configuring incomplete, errors occurred! Anthony Ette Systems Engineer Simulation and Modeling Controls and Data Services Inc. Part of the Rolls-Royce Group 7661 N Perimeter Rd Indianapolis, IN 46241 tel: +1 (317) 230-6943 mob: +1 (317) 864-7975 email: Anthony.R.Ette at controlsdata.com www.controlsdata.com This e-mail (including attachments) contains contents owned by Rolls-Royce plc and its subsidiaries, affiliated companies or customers and covered by the laws of England and Wales, Brazil, US, or Canada (federal, state or provincial). The information contained in this email is intended to be confidential, may be legally privileged and subject to export controls which may restrict the access to and transfer of the information. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, interception or copying of this communication is strictly prohibited and may subject you to further legal action. Reply to the sender if you received this email by accident, and then delete the email and any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From johannes.zarl-zierl at jku.at Mon Jun 15 12:20:39 2015 From: johannes.zarl-zierl at jku.at (Johannes Zarl-Zierl) Date: Mon, 15 Jun 2015 18:20:39 +0200 Subject: [CMake] How does :: actually works? In-Reply-To: References: <2047991.UhN35aOpPK@tuxedo.neundorf.net> Message-ID: <6642590.gJq68crCL0@ersa> On Monday 15 June 2015 16:40:10 Klaim - Jo?l Lamotte wrote: > So far I didn't get what imported targets helps with, so I'm a bit lost on > the usefulness of "namespaces" > but I am sure that I am missing something. Imported targets improve the handling of find_package stuff. In the "old days", the common pattern for using another library as dependency was as follows: find_package(XXX) include_directories( ${XXX_INCLUDE_DIR} ) add_definitions( ${XXX_DEFINITIONS} ) target_link_library(YourTarget ${XXX_LIBRARIES} ) Sometimes you don't need the add_definitions part, and sometimes the variable names are a little bit different. Most of the time you inadvertedly add definitions and include directories for other targets, too. With imported targets, you can combine everything that's needed to use a library into an imported target, making the above pattern simpler and less error-prone: find_package(XXX) target_link_library(YourTarget XXX) With more complex libraries, you often have different components, and that's when namespaces come in handy: find_package(XXX COMPONENTS Base Advanced) target_link_library(YourTarget XXX::Base) Find_package(YYY COMPONENTS Base) target_link_library(YourOtherTarget XXX::Advanced YYY::Base) Does this answer your question? Cheers, Johannes From brad.king at kitware.com Mon Jun 15 12:59:11 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 15 Jun 2015 12:59:11 -0400 Subject: [CMake] fortran compiler failed to compile simple test program In-Reply-To: <2A375B5C08C24643A8A3F8CC2B98C1084BAD8011@USINDPR-MBX003.Rolls-Royce.Local> References: <2A375B5C08C24643A8A3F8CC2B98C1084BAD8011@USINDPR-MBX003.Rolls-Royce.Local> Message-ID: <557F045F.30804@kitware.com> On 06/15/2015 11:31 AM, Ette, Anthony (CDS) wrote: > Any ideas? Our FORTRAN compiler (Concurrent Computer Corporation > port of f77) is failing to compile simple test program because the > linker can't find -lrt >From the log: > /usr/ccs/bin/cf77 -c /home/bzpl46/sandbox/AE3007/C2/build/redhawk/CMakeFiles/CMakeTmp/testFortranCompiler.f -o CMakeFiles/cmTryCompileExec3634533531.dir/testFortranCompiler.f.o > /usr/ccs/bin/cf77 CMakeFiles/cmTryCompileExec3634533531.dir/testFortranCompiler.f.o -o cmTryCompileExec3634533531 -rdynamic > /usr/ccs/release/7.3/lib_ia32/ld: cannot find -lrt This is pretty typical usage of a compiler to compile and link a program. Perhaps cf77 is responding to -rdynamic and adding -lrt. The -rdynamic flag is known to work with GNU compilers on Linux: http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/Platform/Linux-GNU.cmake;hb=v3.3.0-rc2#l21 That setting may be getting re-used because we don't distinguish cf77 from GNU f77 currently. For the Intel Fortran compiler we turn off use of -rdynamic here: http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/Platform/Linux-Intel-Fortran.cmake;hb=v3.3.0-rc2#l4 Something similar may be needed for this compiler. Does it define a preprocessor macro to identify itself? Thanks, -Brad From Anthony.R.Ette at controlsdata.com Mon Jun 15 13:53:06 2015 From: Anthony.R.Ette at controlsdata.com (Ette, Anthony (CDS)) Date: Mon, 15 Jun 2015 17:53:06 +0000 Subject: [CMake] fortran compiler failed to compile simple test program In-Reply-To: <557F045F.30804@kitware.com> References: <2A375B5C08C24643A8A3F8CC2B98C1084BAD8011@USINDPR-MBX003.Rolls-Royce.Local> <557F045F.30804@kitware.com> Message-ID: <2A375B5C08C24643A8A3F8CC2B98C1084BAD809E@USINDPR-MBX003.Rolls-Royce.Local> Brad, Thank you for the response. I suppose I should've provided more information about the platform up front. Our system is a RHEL5 variant named "RedHawk Linux". The kernel is a custom real-time kernel developed by Concurrent Computer Corporation and cf77 is a real-time port of the GNU f77 compiler so it doesn't surprise me this compiler is not covered inherently by CMake (I have asked the developers if a preprocessor macro is defined for future version of Cmake to latch onto). The -lrt is the option to link to the concurrent real-time libraries which is the default for the compiler (regardless of rdynamic). So my problem is that, given Cmake doesn't support natively, I need a way to "beat" it into submission. Correct me if I'm wrong, but I think I need to create a toolchain file to overcome this which is the path I've started down but Cmake is still identifying the compiler as GNU and attempting the same test program. I've attached the toolchain file in its current state and the current output from the cmake command: rts1-4:/home/bzpl46/sandbox/AE3007/C2/build> rm -rf redhawk;mkdir redhawk/;cd redhawk;cmake ../../ -DCMAKETOOLCHAIN_FILE=../../redhawk.cmake -G "Unix Makefiles" -- The C compiler identification is GNU 4.1.2 -- The CXX compiler identification is GNU 4.1.2 -- 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 -- Detecting C compile features -- Detecting C compile features - done -- Check for working CXX compiler: /usr/bin/g++ -- Check for working CXX compiler: /usr/bin/g++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- No build type selected, default to Debug -- UNIX: 1 -- WIN32: -- PYCMD: -- PYSHMDIR: -- UNIX: 1 -- WIN32: -- PYCMD: python2.7 -- PYSHMDIR: -- The Fortran compiler identification is GNU -- Check for working Fortran compiler: /usr/ccs/bin/cf77 -- Check for working Fortran compiler: /usr/ccs/bin/cf77 -- broken CMake Error at /usr/local/cmake/share/cmake-3.2/Modules/CMakeTestFortranCompiler.cmake:54 (message): The Fortran compiler "/usr/ccs/bin/cf77" is not able to compile a simple test program. It fails with the following output: Change Dir: /home/bzpl46/sandbox/AE3007/C2/build/redhawk/CMakeFiles/CMakeTmp Run Build Command:"/usr/bin/gmake" "cmTryCompileExec1559089261/fast" /usr/bin/gmake -f CMakeFiles/cmTryCompileExec1559089261.dir/build.make CMakeFiles/cmTryCompileExec1559089261.dir/build gmake[1]: Entering directory `/home/bzpl46/sandbox/AE3007/C2/build/redhawk/CMakeFiles/CMakeTmp' /usr/local/cmake/bin/cmake -E cmake_progress_report /home/bzpl46/sandbox/AE3007/C2/build/redhawk/CMakeFiles/CMakeTmp/CMakeFiles 1 Building Fortran object CMakeFiles/cmTryCompileExec1559089261.dir/testFortranCompiler.f.o /usr/ccs/bin/cf77 -c /home/bzpl46/sandbox/AE3007/C2/build/redhawk/CMakeFiles/CMakeTmp/testFortranCompiler.f -o CMakeFiles/cmTryCompileExec1559089261.dir/testFortranCompiler.f.o /home/bzpl46/sandbox/AE3007/C2/build/redhawk/CMakeFiles/CMakeTmp/testFortranCompiler.f: Linking Fortran executable cmTryCompileExec1559089261 /usr/local/cmake/bin/cmake -E cmake_link_script CMakeFiles/cmTryCompileExec1559089261.dir/link.txt --verbose=1 /usr/ccs/bin/cf77 CMakeFiles/cmTryCompileExec1559089261.dir/testFortranCompiler.f.o -o cmTryCompileExec1559089261 -rdynamic /usr/ccs/release/7.3/lib_ia32/ld: cannot find -lrt gmake[1]: *** [cmTryCompileExec1559089261] Error 1 gmake[1]: Leaving directory `/home/bzpl46/sandbox/AE3007/C2/build/redhawk/CMakeFiles/CMakeTmp' gmake: *** [cmTryCompileExec1559089261/fast] Error 2 CMake will not be able to correctly generate this project. Call Stack (most recent call first): src/namelist/CMakeLists.txt:3 (PROJECT) -- Configuring incomplete, errors occurred! This e-mail (including attachments) contains contents owned by Rolls-Royce plc and its subsidiaries, affiliated companies or customers and covered by the laws of England and Wales, Brazil, US, or Canada (federal, state or provincial). The information contained in this email is intended to be confidential, may be legally privileged and subject to export controls which may restrict the access to and transfer of the information. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, interception or copying of this communication is strictly prohibited and may subject you to further legal action. Reply to the sender if you received this email by accident, and then delete the email and any attachments. -------------- next part -------------- A non-text attachment was scrubbed... Name: redhawk.cmake Type: application/octet-stream Size: 577 bytes Desc: redhawk.cmake URL: From brad.king at kitware.com Mon Jun 15 14:04:58 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 15 Jun 2015 14:04:58 -0400 Subject: [CMake] fortran compiler failed to compile simple test program In-Reply-To: <2A375B5C08C24643A8A3F8CC2B98C1084BAD809E@USINDPR-MBX003.Rolls-Royce.Local> References: <2A375B5C08C24643A8A3F8CC2B98C1084BAD8011@USINDPR-MBX003.Rolls-Royce.Local> <557F045F.30804@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD809E@USINDPR-MBX003.Rolls-Royce.Local> Message-ID: <557F13CA.50903@kitware.com> On 06/15/2015 01:53 PM, Ette, Anthony (CDS) wrote: > Thank you for the response. I suppose I should've provided > more information about the platform up front. Our system is a > RHEL5 variant named "RedHawk Linux". The kernel is a custom > real-time kernel developed by Concurrent Computer Corporation > and cf77 is a real-time port of the GNU f77 compiler so it Is the compiler hosted natively on that platform or are you cross-compiling to it? > I have asked the developers if a preprocessor macro is > defined for future version of Cmake to latch onto. That would be useful, thanks. Version information should also be made available via preprocessor macros. > The -lrt is the option to link to the concurrent real-time libraries > which is the default for the compiler (regardless of rdynamic). Okay. If -lrt is the default for the compiler why might "rt" not be found? > So my problem is that, given Cmake doesn't support natively, I > need a way to "beat" it into submission. Correct me if I'm > wrong, but I think I need to create a toolchain file to A toolchain file is normally used for true cross-compiling. You may be able to use one here too, but if you want to skip the compiler checks then you need to use the CMakeForceCompiler module's helpers within the toolchain file. First I think we should identify why the compiler doesn't work for the simple test case though. Maybe some other fix is needed. Does building a simple test program by hand work? $ cat test.f PROGRAM TESTFortran PRINT *, 'Hello' END $ cf77 test.f If the compiler requires some special environment to be loaded then it is your responsibility to do that before running CMake. Thanks, -Brad From JamesJ at motionview3d.com Mon Jun 15 14:56:06 2015 From: JamesJ at motionview3d.com (James Johnston) Date: Mon, 15 Jun 2015 18:56:06 -0000 Subject: [CMake] Ninja race condition compiling VTK with Borland bcc32 compiler Message-ID: <0e5101d0a79c$eff482a0$cfdd87e0$@motionview3d.com> Hi, While newer VTK versions seem to have forgone support for the C++ Builder compiler, we still have code that extensively uses both VTK 5.4.2 and proprietary C++ Builder features (including its runtime library, the VCL). I am seeking to improve build performance of VTK in this situation by using Ninja. Using the Borland Makefiles generator in CMake works fine, except that Borland Make itself has no parallelism and thus the build takes a lengthy time period. So I want to find another generator and Ninja looks promising. Unfortunately, it appears that the Borland linker utilizes temporary files with a hard-coded name (e.g. turboc.$ln); these temporary files are written to the current directory. (Determined via Process Monitor). If two or more concurrent linkers are run with the same current directory, some of them may fail as shown below because they will both be trying to use the same temporary filename. While this constitutes eye-bleeding sadness on bcc32's part, I'd still like to get this working by having the linkers run in target-specific directories. And so my question: is there a way to make the Ninja generator use target-specific current directories when calling the linker to work around this? The NMake JOM generator seems to work around this by changing directory to target-specific directories; however, the ninja generator does not. And so, Ninja with only one thread (i.e. "ninja -j 1") works fine, but the default configuration ("ninja" == "ninja -j10" on my system) gives me errors. For example: ================================================= [214/2008] Linking CXX shared library bin\vtkDICOMParser.dll Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland Turbo Incremental Link 5.66 Copyright (c) 1997-2002 Borland Fatal: No object file or .EXE name was given Borland Implib Version 3.0.22 Copyright (c) 1991, 2000 Inprise Corporation Error bin\: unable to open file [215/2008] Linking C shared library bin\vtkzlib.dll FAILED: cmd.exe /C "cd . && C:\PROGRA~2\Borland\CBUILD~1\Bin\bcc32.exe -tWR -tW- -tWD -ebin\vtkzlib.dll -tWM -lS:104857 6 -lSc:4098 -lH:1048576 -lHc:8192 -v import32.lib Utilities\vtkzlib\CMakeFiles\vtkzlib.dir\adler32.obj && implib -c -w bin\vtkzlib.lib bin\vtkzlib.dll && cd ." Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland Turbo Incremental Link 5.66 Copyright (c) 1997-2002 Borland Fatal: Unable to open file 'turboc.$ln' ================================================= My configuration: * Windows 7 64-bit on a quad-core hyperthreaded CPU * VTK 5.4.2, checked out from the appropriately tagged Git commit * CMake 3.3.0-rc1, Kitware-provided Windows binary * Ninja v1.5.3, built from source using Visual C++ 2008 Express. * C++ Builder 5 Update 1 * I configure VTK in CMake GUI as follows: CMAKE_BUILD_TYPE=RelWithDebInfo, VTK_REMOVE_LEGACY=ON, BUILD_TESTING=OFF, BUILD_SHARED_LIBS=ON Here is the offending snippet from one of the generated ninja files - build.ninja: ================================================= build bin\vtkzlib.dll bin\vtkzlib.lib: C_SHARED_LIBRARY_LINKER__vtkzlib Utilities\vtkzlib\CMakeFiles\vtkzlib.dir\adler32.obj LANGUAGE_COMPILE_FLAGS = -tWM -Od LINK_FLAGS = -tWM -lS:1048576 -lSc:4098 -lH:1048576 -lHc:8192 -v LINK_LIBRARIES = import32.lib POST_BUILD = cd . PRE_LINK = cd . TARGET_FILE = bin\vtkzlib.dll TARGET_IMPLIB = bin\vtkzlib.lib TARGET_PDB = vtkzlib.dll.dbg ================================================= And the corresponding ninja rule: ================================================= rule C_SHARED_LIBRARY_LINKER__vtkzlib command = cmd.exe /C "$PRE_LINK && C:\PROGRA~2\Borland\CBUILD~1\Bin\bcc32.exe -tWR -tW- -tWD -e$TARGET_FILE $LINK_FLAGS $LINK_PATH $LINK_LIBRARIES $in && implib -c -w $TARGET_IMPLIB $TARGET_FILE && $POST_BUILD" description = Linking C shared library $TARGET_FILE restat = $RESTAT ================================================= Notice POST_BUILD and PRE_LINK variables don't change directory to something else. What I think will work around this bcc32 design flaw is if it can do something like: POST_BUILD = cd ..\.. PRE_LINK = cd Utilities\vtkzlib (Or alternatively, cd to absolute paths like the NMake JOM example below). And of course, adjust the relative paths in other parameters to the build rule To contrast, NMake JOM generator has it right in order to work around this bcc32 issue - notice we change directory to a target-specific directory before linking, and then go back when done: ================================================= Utilities\vtkzlib\CMakeFiles\vtkzlib.dir\build.make: bin\vtkzlib.dll: Utilities\vtkzlib\CMakeFiles\vtkzlib.dir\adler32.obj bin\vtkzlib.dll: Utilities\vtkzlib\CMakeFiles\vtkzlib.dir\build.make cd C:\Users\JamesJ\Documents\Repositories\SuperRepo\VTK-JOM\Utilities\vtkzlib C:\PROGRA~2\Borland\CBUILD~1\Bin\bcc32.exe -tWR -tW- -tWD @<< -e..\..\bin\vtkzlib.dll -tWM -lS:1048576 -lSc:4098 -lH:1048576 -lHc:8192 -v import32.lib $(vtkzlib_OBJECTS) $(vtkzlib_EXTERNAL_OBJECTS) << implib -c -w ..\..\bin\vtkzlib.lib ..\..\bin\vtkzlib.dll cd C:\Users\JamesJ\Documents\Repositories\SuperRepo\VTK-JOM ================================================= For what it's worth, at this time, I think this issue is limited to the linker and not to the single-unit compilation of a CPP file to OBJ file. I ran Process Monitor for a few seconds while VTK was compiling, and it seems that the only file writes to the build tree were either legitimate writes to named intermediate/output files, or else to these problematic files from the linker. Best regards, James Johnston From Anthony.R.Ette at controlsdata.com Mon Jun 15 15:08:21 2015 From: Anthony.R.Ette at controlsdata.com (Ette, Anthony (CDS)) Date: Mon, 15 Jun 2015 19:08:21 +0000 Subject: [CMake] fortran compiler failed to compile simple test program In-Reply-To: <557F13CA.50903@kitware.com> References: <2A375B5C08C24643A8A3F8CC2B98C1084BAD8011@USINDPR-MBX003.Rolls-Royce.Local> <557F045F.30804@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD809E@USINDPR-MBX003.Rolls-Royce.Local> <557F13CA.50903@kitware.com> Message-ID: <2A375B5C08C24643A8A3F8CC2B98C1084BAD80FC@USINDPR-MBX003.Rolls-Royce.Local> > Is the compiler hosted natively on that platform or are you cross-compiling to it? Hosted natively. I wouldn't normally try to use a toolchain file to overcome this because I'm not really cross-compiling here, but it one of the mechanisms that I though *may* work. I don't want to go against the grain though and have something break in future release (see below). > That would be useful, thanks. Version information should also be made available via preprocessor macros. I will report back with what I find from the developers. > Okay. If -lrt is the default for the compiler why might "rt" not be found? This is the million dollar question. I'm assuming some system lib is not in the path, or ldpath, or something? Actually, I'm not even convinced that cf77 is responsible for throwing the flag...any chance I could be forcing that flag (say if one of my CMakeFiles.txt had "SET(CMAKE_CXX_LINK_FLAGS "-lrt")") or are my CMakeFiles.txt not considered as part of building a simple test program? > A toolchain file is normally used for true cross-compiling. > You may be able to use one here too, but if you want to skip the compiler checks then you need to use the CMakeForceCompiler module's helpers within the toolchain file. First I think we should > identify why the compiler doesn't work for the simple test case though. Maybe some other fix is needed. So, in order of appropriateness, is it: 1) fix simple test case 2) use toolchain file, then 3) force compiler using CMakeForceCompiler? Assuming we can't get the test program to compile, what is the officially recommended way forward for compilers not currently supported by Cmake? > Does building a simple test program by hand work? Yes this works no problem. I need to figure out how to turn on verbose to see if -lrt is being thrown or not (I suspect not)... > If the compiler requires some special environment to be loaded then it is your responsibility to do that before running CMake. Yes. I expect to have to do some of this just not exactly sure how much/what/where. So far I've the FORTRAN bin & lib directories to the PATH. This e-mail (including attachments) contains contents owned by Rolls-Royce plc and its subsidiaries, affiliated companies or customers and covered by the laws of England and Wales, Brazil, US, or Canada (federal, state or provincial). The information contained in this email is intended to be confidential, may be legally privileged and subject to export controls which may restrict the access to and transfer of the information. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, interception or copying of this communication is strictly prohibited and may subject you to further legal action. Reply to the sender if you received this email by accident, and then delete the email and any attachments. From brad.king at kitware.com Mon Jun 15 15:19:14 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 15 Jun 2015 15:19:14 -0400 Subject: [CMake] fortran compiler failed to compile simple test program In-Reply-To: <2A375B5C08C24643A8A3F8CC2B98C1084BAD80FC@USINDPR-MBX003.Rolls-Royce.Local> References: <2A375B5C08C24643A8A3F8CC2B98C1084BAD8011@USINDPR-MBX003.Rolls-Royce.Local> <557F045F.30804@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD809E@USINDPR-MBX003.Rolls-Royce.Local> <557F13CA.50903@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD80FC@USINDPR-MBX003.Rolls-Royce.Local> Message-ID: <557F2532.5000403@kitware.com> On 06/15/2015 03:08 PM, Ette, Anthony (CDS) wrote: >> Okay. If -lrt is the default for the compiler why might "rt" not be found? > say if one of my CMakeFiles.txt had "SET(CMAKE_CXX_LINK_FLAGS "-lrt")") > or are my CMakeFiles.txt not considered as part of building a simple > test program? Some information is considered but not all. Try a minimal CMakeLists.txt: cmake_minimum_required(VERSION ...) project(TestProject Fortran) Does this enable Fortran correctly with cf77? If so then you can start stripping down your project to debug this. > So, in order of appropriateness, is it: > 1) fix simple test case Yes. > 2) use toolchain file, then > 3) force compiler using CMakeForceCompiler? Those go together. CMakeForceCompiler must be used in a toolchain file. >> Does building a simple test program by hand work? > Yes this works no problem. > I need to figure out how to turn on verbose to see if -lrt is being > thrown or not (I suspect not)... Okay. One can see from the build log in the error message that CMake is not adding -lrt itself so the compiler front-end must be choosing to do it somehow. What did you mean by "default for the compiler" if it is not adding -lrt by default? Thanks, -Brad From Anthony.R.Ette at controlsdata.com Mon Jun 15 15:42:25 2015 From: Anthony.R.Ette at controlsdata.com (Ette, Anthony (CDS)) Date: Mon, 15 Jun 2015 19:42:25 +0000 Subject: [CMake] fortran compiler failed to compile simple test program In-Reply-To: <557F2532.5000403@kitware.com> References: <2A375B5C08C24643A8A3F8CC2B98C1084BAD8011@USINDPR-MBX003.Rolls-Royce.Local> <557F045F.30804@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD809E@USINDPR-MBX003.Rolls-Royce.Local> <557F13CA.50903@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD80FC@USINDPR-MBX003.Rolls-Royce.Local> <557F2532.5000403@kitware.com> Message-ID: <2A375B5C08C24643A8A3F8CC2B98C1084BAD8142@USINDPR-MBX003.Rolls-Royce.Local> >Some information is considered but not all. Try a minimal CMakeLists.txt: > cmake_minimum_required(VERSION ...) > project(TestProject Fortran) >Does this enable Fortran correctly with cf77? If so then you can start stripping down your project to debug this. No joy. Same error. Must mean that the -lrt is not being added by Cmake or by myself so it must be the compiler. In either case, you mention that it is my responsibility to setup the environment before invoking Cmake and while I agree, it's just not clear to me what speficially Cmake requires to be setup. I.e. PATH, LD_LIBRARY_PATH, etc. Can you please elaborate on precisely how Cmake finds everything it needs to compile the simple test and what hooks/env vars the user has at his disposal to control this behavior? I apologize if this is well documented somewhere and I just haven't been able to find it. I'm pretty sure the lib that contains the -lrt is in /usr/lib/libccur_rt.a, but adding /usr/lib to the PATH and LD_LIBRARY_PATH aren't helping Cmake find it... > So, in order of appropriateness, is it: > 1) fix simple test case Yes. > 2) use toolchain file, then > 3) force compiler using CMakeForceCompiler? >>Those go together. CMakeForceCompiler must be used in a toolchain file. Ok, I didn't realize that. If you look at my current toolchain file that I was playing around with, I'm not currently using the CMakeForceCompiler command. I will keep in mind in case I have to go down this path. >Okay. One can see from the build log in the error message that CMake is not adding -lrt itself so the compiler front-end must be choosing to do it somehow. What did you mean by "default for the >compiler" >if it is not adding -lrt by default? I'm not sure what I mean. :) I'm working with concurrent to better understand where the -lrt is coming from and why it's needed. I think it's more like certain "features" require this linkage. E.g. when we link an executable that contains shared memory, we have to throw this flag. Also note that we've architected such that FORTRAN is only ever used as a subroutine. In other words, we no longer support FORTRAN main programs, and as such, we always use C/CXX to perform the link and thus have to manually point C/CXX to the fortran instrinsic libs. Thanks, -Brad ______________________________________________________________________ This email has been scanned. This e-mail (including attachments) contains contents owned by Rolls-Royce plc and its subsidiaries, affiliated companies or customers and covered by the laws of England and Wales, Brazil, US, or Canada (federal, state or provincial). The information contained in this email is intended to be confidential, may be legally privileged and subject to export controls which may restrict the access to and transfer of the information. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, interception or copying of this communication is strictly prohibited and may subject you to further legal action. Reply to the sender if you received this email by accident, and then delete the email and any attachments. From brad.king at kitware.com Mon Jun 15 16:02:53 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 15 Jun 2015 16:02:53 -0400 Subject: [CMake] fortran compiler failed to compile simple test program In-Reply-To: <2A375B5C08C24643A8A3F8CC2B98C1084BAD8142@USINDPR-MBX003.Rolls-Royce.Local> References: <2A375B5C08C24643A8A3F8CC2B98C1084BAD8011@USINDPR-MBX003.Rolls-Royce.Local> <557F045F.30804@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD809E@USINDPR-MBX003.Rolls-Royce.Local> <557F13CA.50903@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD80FC@USINDPR-MBX003.Rolls-Royce.Local> <557F2532.5000403@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD8142@USINDPR-MBX003.Rolls-Royce.Local> Message-ID: <557F2F6D.6040804@kitware.com> On 06/15/2015 03:42 PM, Ette, Anthony (CDS) wrote: > you mention that it is my responsibility to setup the environment > before invoking Cmake and while I agree, it's just not clear to me > what speficially Cmake requires to be setup. The environment is not for CMake but for the compiler itself. I was just saying that CMake is not going to know what environment variables the toolchain needs to have set in order for the compiler to work. If you invoke CMake from the same environment as that by-hand test that worked earlier then that is the required environment. You can run CMake on that minimal project with --debug-trycompile to leave behind the test project directory. That may help dig into how the test project is invoking the compiler. -Brad From mjklaim at gmail.com Mon Jun 15 16:43:41 2015 From: mjklaim at gmail.com (=?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?=) Date: Mon, 15 Jun 2015 22:43:41 +0200 Subject: [CMake] How does :: actually works? In-Reply-To: <6642590.gJq68crCL0@ersa> References: <2047991.UhN35aOpPK@tuxedo.neundorf.net> <6642590.gJq68crCL0@ersa> Message-ID: On 15 June 2015 at 18:20, Johannes Zarl-Zierl wrote: > On Monday 15 June 2015 16:40:10 Klaim - Jo?l Lamotte wrote: > > So far I didn't get what imported targets helps with, so I'm a bit lost > on > > the usefulness of "namespaces" > > but I am sure that I am missing something. > > Imported targets improve the handling of find_package stuff. In the "old > days", > the common pattern for using another library as dependency was as follows: > > find_package(XXX) > include_directories( ${XXX_INCLUDE_DIR} ) > add_definitions( ${XXX_DEFINITIONS} ) > target_link_library(YourTarget ${XXX_LIBRARIES} ) > > Sometimes you don't need the add_definitions part, and sometimes the > variable > names are a little bit different. Most of the time you inadvertedly add > definitions and include directories for other targets, too. > > > With imported targets, you can combine everything that's needed to use a > library into an imported target, making the above pattern simpler and less > error-prone: > > find_package(XXX) > target_link_library(YourTarget XXX) > > With more complex libraries, you often have different components, and > that's > when namespaces come in handy: > > find_package(XXX COMPONENTS Base Advanced) > target_link_library(YourTarget XXX::Base) > Find_package(YYY COMPONENTS Base) > target_link_library(YourOtherTarget XXX::Advanced YYY::Base) > > Does this answer your question? > > Cheers, > Johannes > > Yes! Thanks a lot! I was only getting half of the usage but now it's clear. It's pretty close to how I was working before but I was hacking stuffs in a hard to update way. I'll try this way of doing in one project, it seems to fix at least one issue I have with my dependencies: help with uprading them. Thanks again! Just a last question: I assume that most find module scripts distributed with cmake are not using this feature at the moment, right? After reading your explaination I looked at documentation for FindBoost and FindGTest which are both used in all my projects and they dont seem to provide import targets. Are there plans to update the cmake scripts distributed with CMake or is it just assumed that projects willing to use importing targets will write them somewhere before using 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 a.neundorf-work at gmx.net Mon Jun 15 17:05:07 2015 From: a.neundorf-work at gmx.net (Alexander Neundorf) Date: Mon, 15 Jun 2015 23:05:07 +0200 Subject: [CMake] determining which system headerfile provides a given function In-Reply-To: <4940927.LaEBni3ykD@portia.local> References: <2365905.UvL37pODeQ@patux> <2151979.WFpR57yxEj@tuxedo.neundorf.net> <4940927.LaEBni3ykD@portia.local> Message-ID: <8859268.qRelmB3V3V@tuxedo.neundorf.net> On Saturday, June 13, 2015 23:17:37 Ren? J.V. Bertin wrote: > On Saturday June 13 2015 22:26:12 Alexander Neundorf wrote: > > did you try check_symbol_exists() and the other similar functions ? > > Yes, but none that I could find give any information beyond whether the > symbol exists. It may be possible (or necessary) to repeat such tests > trying each of the possible candidate header files in succession until a > hit is found, but as I said in my initial email, that doesn't work. That's > about all there's to say about it: I presume this approach doesn't work > because of caching intended to avoid testing the same thing twice. if you have multiple candidate headers, try them all, and use separate result variables for every one. Is that the problem you have ? Alex From a.neundorf-work at gmx.net Mon Jun 15 17:08:29 2015 From: a.neundorf-work at gmx.net (Alexander Neundorf) Date: Mon, 15 Jun 2015 23:08:29 +0200 Subject: [CMake] cross compiling with sdcc In-Reply-To: <99BCC5F8-783D-4756-8A63-79821FD3F3A5@Robitzki.de> References: <0C30A697-C3DB-4400-8269-A69EA79DC6E5@Robitzki.de> <1865149.1O4BFgnYP3@tuxedo.neundorf.net> <99BCC5F8-783D-4756-8A63-79821FD3F3A5@Robitzki.de> Message-ID: <4867314.WDoUB72XYS@tuxedo.neundorf.net> On Saturday, June 13, 2015 23:26:59 Torsten at Robitzki.de wrote: > Hi Alex, > > Am 13.06.2015 um 22:18 schrieb Alexander Neundorf : > > On Friday, May 29, 2015 11:14:06 Torsten at Robitzki.de wrote: > ? > > >> I saw that there is a file Platform/Generic-SDCC-C.cmake, while searching > >> for a way to force cmake to use this file, I found a makro > >> CMAKE_FORCE_C_COMPILER that let me override the compiler detection. > > > > ? > > you shouldn't have to use cmake_force_c_compiler(). > > You did try setting up a toolchain file which points to sdcc ? > > could you elaborate on this solution? Would the > Platform/Generic-SDCC-C.cmake file that is shipped with a normal cmake > installation such a toolchain file? here is some documentation on this: http://www.cmake.org/cmake/help/v3.2/manual/cmake-toolchains.7.html Alex From DLRdave at aol.com Mon Jun 15 19:05:32 2015 From: DLRdave at aol.com (David Cole) Date: Mon, 15 Jun 2015 19:05:32 -0400 Subject: [CMake] [cmake-developers] Virtual folders in Visual studio get expanded on reload In-Reply-To: <081801d0a506$a801c720$f8055560$@gmx.at> References: <0458DF31F610EF42BFC78C497E806C7B458AB8FF@ECS-EXG-P-MB03.win.lanl.gov> <081801d0a506$a801c720$f8055560$@gmx.at> Message-ID: I think I have seen this behavior in pure (non-CMake-generated) VS projects... Perhaps it's simply a Visual Studio issue, and has nothing to do with CMake. D On Fri, Jun 12, 2015 at 7:55 AM, Roman W?ger wrote: > @kgt: Thank you for this great hint. :-) > I had overlooked this button in Visual Studio > > @mjklaim: I didn't see this behavior in older CMake versions. > > Roman > >> -----Urspr?ngliche Nachricht----- >> Von: Thompson, KT [mailto:kgt at lanl.gov] >> Gesendet: Dienstag, 02. Juni 2015 15:52 >> An: Roman W?ger; CMake MailingList >> Betreff: RE: [cmake-developers] Virtual folders in Visual studio get expanded >> on reload >> >> Roman, >> >> I have the same complaint. My project has about 300 targets arranged in two >> dozen folders. I use the "collapse all" button in Visual Studio's Solution >> Explorer window (looks like a stack of 3 squares in VS2013). >> >> kt >> >> -----Original Message----- >> From: cmake-developers [mailto:cmake-developers-bounces at cmake.org] >> On Behalf Of Roman W?ger >> Sent: Monday, June 01, 2015 5:00 PM >> To: CMake Developer MailingList; CMake MailingList >> Subject: [cmake-developers] Virtual folders in Visual studio get expanded on >> reload >> >> Hi, >> >> I noticed that sometimes when a target is reloaded, that the virtual folders >> and targets for the complete visual studio solution get expanded. >> For a small project this isn't a problem, but in a large project (~ 100 targets) >> this is a really big problem to close all targets every time. >> >> Did anybody noticed this behavior and has a solution for it? >> >> Thanks >> >> Best Regards >> Roman >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake-developers > > -- > > 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 Anthony.R.Ette at controlsdata.com Tue Jun 16 01:21:40 2015 From: Anthony.R.Ette at controlsdata.com (Ette, Anthony (CDS)) Date: Tue, 16 Jun 2015 05:21:40 +0000 Subject: [CMake] fortran compiler failed to compile simple test program In-Reply-To: <557F2F6D.6040804@kitware.com> References: <2A375B5C08C24643A8A3F8CC2B98C1084BAD8011@USINDPR-MBX003.Rolls-Royce.Local> <557F045F.30804@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD809E@USINDPR-MBX003.Rolls-Royce.Local> <557F13CA.50903@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD80FC@USINDPR-MBX003.Rolls-Royce.Local> <557F2532.5000403@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD8142@USINDPR-MBX003.Rolls-Royce.Local> <557F2F6D.6040804@kitware.com> Message-ID: <2A375B5C08C24643A8A3F8CC2B98C1084BAD82C0@USINDPR-MBX003.Rolls-Royce.Local> >The environment is not for CMake but for the compiler itself. I was just saying that CMake is not going to know what environment variables the toolchain needs to have set in order for the compiler >to work. >If you invoke CMake from the same environment as that by-hand test that worked earlier then that is the required environment. Ok Yep - so the environment is good. You mentioned that cmake doesn't take "much if anything" from my CmakeFiles.txt contents into consideration when compiling the test program, but what control does the user have over the compilation of the test program? I.e. can I tell cmake to add -L (where to look for libraries) or -v (cf77 compiler verbose flag) when compiling the test program to avoid having to go to a full toolchain file and forcing the compiler? Note that working with developers from Concurrent, I have found the -lrt is coming from /usr/lib/librt.so (for dynamic linking) and /usr/lib/librt.a (for static linking). If /usr/lib is in my path, and cmake is being invoked from the same environment where I can compile hello world.f, then wouldn't this indicate a problem unique to cmake? Why can't cmake find -lrt? For reference, here's detailed output below when I compile the hello world.f; does this provide any clues as to where cmake is tripping up with this compiler? rts1-4:/home/bzpl46/test2> cf77 -v -g test.f environment: PDE_RELEASE = 7.3 environment: PDE_LINUX_RELEASE = i386-redhat-linux environment: PDE_GCC_VERSION = 4.1.2 environment: PDE_CPU = pentium4 Compiling: /usr/ccs/release/7.3/lib_ia32/cxf77 -v -g3 --rel=7.3 -W/tmp/F77dw1YhNSx test.f /tmp/F77r.s1SNtdW Concurrent Fortran 77 Compiler - Version 7.3 Tue Jun 16 00:57:59 2015 Input=test.f Assembly=/tmp/F77r.s1SNtdW Error Summary: 0 Cautions, 0 Warnings, 0 Fatals Elapsed wall time = 0.0 seconds CPU time used = 0.0 seconds Reordering code: /usr/ccs/release/7.3/lib_ia32/reorder64 -Zno_optimize -dw/tmp/F77dw1YhNSx < /tmp/F77r.s1SNtdW > /tmp/F77s1cqwy9 Assembling /tmp/F77s1cqwy9: /usr/bin/as --32 -o test.o /tmp/F77s1cqwy9 Linking executable: /usr/ccs/release/7.3/lib_ia32/ld -t -melf_i386 -u MAIN__ -dynamic-linker /lib/ld-linux.so.2 --allow-multiple-definition /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/gcc/i386-redhat-linux/4.1.2/crtbeginT.o -v test.o -L/usr/ccs/release/7.3/lib_ia32 -L/usr/lib/gcc/i386-redhat-linux/4.1.2 -lhU77 -lhF77 -lhI77 -lrt -lm -lgcc -lgcc_eh -lc -lgcc -lgcc_eh -o a.out /usr/lib/gcc/i386-redhat-linux/4.1.2/crtend.o /usr/lib/crtn.o GNU ld version 2.17.50.0.6-5.el5 20061020 /usr/ccs/release/7.3/lib_ia32/ld: mode elf_i386 /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/gcc/i386-redhat-linux/4.1.2/crtbeginT.o test.o -lhU77 (/usr/ccs/release/7.3/lib_ia32/libhU77.so) (/usr/ccs/release/7.3/lib_ia32/libhF77.so)ioinit.o (/usr/ccs/release/7.3/lib_ia32/libhF77.so)main.o (/usr/ccs/release/7.3/lib_ia32/libhF77.so)xarg.o (/usr/ccs/release/7.3/lib_ia32/libhF77.so)libhF77.so.1 -lhI77 (/usr/ccs/release/7.3/lib_ia32/libhI77.so) -lrt (/usr/lib/librt.so) -lm (/usr/lib/libm.so) /lib/libc.so.6 (/usr/lib/libc_nonshared.a)elf-init.oS /lib/ld-linux.so.2 /usr/lib/gcc/i386-redhat-linux/4.1.2/crtend.o /usr/lib/crtn.o >You can run CMake on that minimal project with --debug-trycompile to leave behind the test project directory. That may help dig into how the test project is invoking the compiler. Ok thank you for that, I do remember seeing that somewhere before. This e-mail (including attachments) contains contents owned by Rolls-Royce plc and its subsidiaries, affiliated companies or customers and covered by the laws of England and Wales, Brazil, US, or Canada (federal, state or provincial). The information contained in this email is intended to be confidential, may be legally privileged and subject to export controls which may restrict the access to and transfer of the information. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, interception or copying of this communication is strictly prohibited and may subject you to further legal action. Reply to the sender if you received this email by accident, and then delete the email and any attachments. From Anthony.R.Ette at controlsdata.com Tue Jun 16 01:51:27 2015 From: Anthony.R.Ette at controlsdata.com (Ette, Anthony (CDS)) Date: Tue, 16 Jun 2015 05:51:27 +0000 Subject: [CMake] fortran compiler failed to compile simple test program References: <2A375B5C08C24643A8A3F8CC2B98C1084BAD8011@USINDPR-MBX003.Rolls-Royce.Local> <557F045F.30804@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD809E@USINDPR-MBX003.Rolls-Royce.Local> <557F13CA.50903@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD80FC@USINDPR-MBX003.Rolls-Royce.Local> <557F2532.5000403@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD8142@USINDPR-MBX003.Rolls-Royce.Local> <557F2F6D.6040804@kitware.com> Message-ID: <2A375B5C08C24643A8A3F8CC2B98C1084BAD8314@USINDPR-MBX003.Rolls-Royce.Local> > For reference, here's detailed output below when I compile the hello world.f; does this provide any clues as to where cmake is tripping up with this compiler? Please also find attached zip file which includes the simple cmake example and the --debug-trycompile output to compare with the cf77 -v output I provided. This e-mail (including attachments) contains contents owned by Rolls-Royce plc and its subsidiaries, affiliated companies or customers and covered by the laws of England and Wales, Brazil, US, or Canada (federal, state or provincial). The information contained in this email is intended to be confidential, may be legally privileged and subject to export controls which may restrict the access to and transfer of the information. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, interception or copying of this communication is strictly prohibited and may subject you to further legal action. Reply to the sender if you received this email by accident, and then delete the email and any attachments. -------------- next part -------------- A non-text attachment was scrubbed... Name: cf77_cmake.zip Type: application/x-zip-compressed Size: 32421 bytes Desc: cf77_cmake.zip URL: From johannes.zarl-zierl at jku.at Tue Jun 16 05:49:22 2015 From: johannes.zarl-zierl at jku.at (Johannes Zarl-Zierl) Date: Tue, 16 Jun 2015 11:49:22 +0200 Subject: [CMake] How does :: actually works? In-Reply-To: References: <6642590.gJq68crCL0@ersa> Message-ID: <10549345.795GcQO5j7@ersa> On Monday 15 June 2015 22:43:41 you wrote: > Just a last question: I assume that most find module scripts distributed > with cmake are > not using this feature at the moment, right? Sadly, no. > After reading your explaination I looked at documentation for FindBoost and > FindGTest > which are both used in all my projects and they dont seem to provide import > targets. > Are there plans to update the cmake scripts distributed with CMake On the one hand, FindPackage modules are, as far as I'm aware, slowly being updated to use imported targets. On the other hand, quite a few packages are missing a maintainer[1]. If you are using a package and want it to provide imported targets, I think your best bet is to propose a patch for the module and get it into cmake. That said, its worth mentioning that FindPackage modules are only intended for "legacy" projects which do not provide a PackageConfig.cmake file. If you are writing a new project, especially if it's based on cmake, you should write a PackageConfig.cmake file instead [2]. > or is it just assumed that projects willing to use importing targets will > write them somewhere before using them? Creating imported targets on your own is not the way to go. Better file a bug report or write a patch to add the functionality and get that into cmake. IMO, until the official module provides imported targets, you're better off using the old way. Cheers, Johannes [1] http://www.cmake.org/Wiki/CMake:Module_Maintainers#List [2] http://www.cmake.org/Wiki/CMake/Tutorials#CMake_Packages From rjvbertin at gmail.com Tue Jun 16 06:50:43 2015 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Tue, 16 Jun 2015 12:50:43 +0200 Subject: [CMake] determining which system headerfile provides a given function In-Reply-To: <8859268.qRelmB3V3V@tuxedo.neundorf.net> References: <2365905.UvL37pODeQ@patux> <4940927.LaEBni3ykD@portia.local> <8859268.qRelmB3V3V@tuxedo.neundorf.net> Message-ID: <1960902.0MWmq7f9EG@portia.local> On Monday June 15 2015 23:05:07 Alexander Neundorf wrote: > if you have multiple candidate headers, try them all, and use separate result > variables for every one. > Is that the problem you have ? Yes. That's probably the thing I missed and why it didn't work; I used a single variable. Still, it seems surprising there's no predefined macro that would help make things easier in this kind of scenario that cannot be that uncommon (at least it used to be quite common, like for instance with string.h vs. strings.h). A macro that takes a list of candidates and returns the name of the appropriate file would seem useful, no? R. From brad.king at kitware.com Tue Jun 16 08:46:14 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 16 Jun 2015 08:46:14 -0400 Subject: [CMake] fortran compiler failed to compile simple test program In-Reply-To: <2A375B5C08C24643A8A3F8CC2B98C1084BAD82C0@USINDPR-MBX003.Rolls-Royce.Local> References: <2A375B5C08C24643A8A3F8CC2B98C1084BAD8011@USINDPR-MBX003.Rolls-Royce.Local> <557F045F.30804@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD809E@USINDPR-MBX003.Rolls-Royce.Local> <557F13CA.50903@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD80FC@USINDPR-MBX003.Rolls-Royce.Local> <557F2532.5000403@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD8142@USINDPR-MBX003.Rolls-Royce.Local> <557F2F6D.6040804@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD82C0@USINDPR-MBX003.Rolls-Royce.Local> Message-ID: <55801A96.7080600@kitware.com> On 06/16/2015 01:21 AM, Ette, Anthony (CDS) wrote: > what control does the user have over the compilation of the test program? Very little. The whole point is to test that the compiler works the way CMake will invoke it in the generated build system. > I.e. can I tell cmake to add -L (where to look for libraries) > or -v (cf77 compiler verbose flag) when compiling the test program to > avoid having to go to a full toolchain file and forcing the compiler? If you use CMake 3.2 or higher then you can try a test project like this: cmake_minimum_required(VERSION 3.2) project(cf77test Fortran) and run CMake as cmake . -DCMAKE_EXE_LINKER_FLAGS="-v" to get more verbose output from the link step. > I have found the -lrt is coming from /usr/lib/librt.so [snip] > If /usr/lib is in my path It shouldn't matter if /usr/lib is in your PATH. The linker does not pay attention to PATH. Linkers normally look in /usr/lib by default. > rts1-4:/home/bzpl46/test2> cf77 -v -g test.f > Linking executable: /usr/ccs/release/7.3/lib_ia32/ld ... -lrt ... One can see that cf77 indeed adds -lrt to the link line itself. So the question is: why does this work when invoked by hand but not when CMake invokes it? In the test project you sent in a sibling message, try this: $ cd CMakeFiles/CMakeTmp $ cat CMakeFiles/cmTryCompileExec4035725976.dir/link.txt /usr/ccs/bin/cf77 CMakeFiles/cmTryCompileExec4035725976.dir/testFortranCompiler.f.o -o cmTryCompileExec4035725976 -rdynamic Then run that command line by hand. You can add -v to it too. Note that the "4035725976" number will be different each time so adapt to your local build tree accordingly. -Brad From Anthony.R.Ette at controlsdata.com Tue Jun 16 09:31:42 2015 From: Anthony.R.Ette at controlsdata.com (Ette, Anthony (CDS)) Date: Tue, 16 Jun 2015 13:31:42 +0000 Subject: [CMake] fortran compiler failed to compile simple test program In-Reply-To: <55801A96.7080600@kitware.com> References: <2A375B5C08C24643A8A3F8CC2B98C1084BAD8011@USINDPR-MBX003.Rolls-Royce.Local> <557F045F.30804@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD809E@USINDPR-MBX003.Rolls-Royce.Local> <557F13CA.50903@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD80FC@USINDPR-MBX003.Rolls-Royce.Local> <557F2532.5000403@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD8142@USINDPR-MBX003.Rolls-Royce.Local> <557F2F6D.6040804@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD82C0@USINDPR-MBX003.Rolls-Royce.Local> <55801A96.7080600@kitware.com> Message-ID: <2A375B5C08C24643A8A3F8CC2B98C1084BAD83FB@USINDPR-MBX003.Rolls-Royce.Local> > Very little. The whole point is to test that the compiler works the way CMake will invoke it in the generated build system. But the user does have tons of control over the generated build system so why can't he have same control have test program compilation? I think in this case someone forcing cmake/ld to link in /usr/lib would solve the issue. Or is it the case that user has pretty much same hooks for test program but only via command line since CMakeFiles.txt are not used (e.g. -DCMAKE_EXE_LINKER_FLAGS like you suggest below)? >cmake . -DCMAKE_EXE_LINKER_FLAGS="-v" >to get more verbose output from the link step. The command below does not turn cf77 verbose on during test program compilation...any other suggestions for this? cmake . -DCMAKE_EXE_LINKER_FLAGS="-v" -G "Unix Makefiles" > It shouldn't matter if /usr/lib is in your PATH. The linker does not pay attention to PATH. Linkers normally look in /usr/lib by default. So the linker determines where to look for libs for test program and cmake plays no part in this? Seems surprising given that it works outside of cmake. > So the question is: why does this work when invoked by hand but not when CMake invokes it? IDK this is bizarre. > Then run that command line by hand. You can add -v to it too. Results are shown below. Looks identical to the hello world.f outside of cmake so it's a mystery why -lrt can't be found. Presumably the linker is not looking in /usr/lib when invoked by cmake, no? rts1-4:/home/bzpl46/test2/CMakeFiles/CMakeTmp> /usr/ccs/bin/cf77 CMakeFiles/cmTryCompileExec3453195864.dir/testFortranCompiler.f.o -o cmTryCompileExec3453195864 -rdynamic /usr/ccs/release/7.3/lib_ia32/ld: cannot find -lrt rts1-4:/home/bzpl46/test2/CMakeFiles/CMakeTmp> /usr/ccs/bin/cf77 -v CMakeFiles/cmTryCompileExec3453195864.dir/testFortranCompiler.f.o -o cmTryCompileExec3453195864 -rdynamic environment: PDE_RELEASE = 7.3 environment: PDE_LINUX_RELEASE = i386-redhat-linux environment: PDE_GCC_VERSION = 4.1.2 environment: PDE_CPU = pentium4 Linking executable: /usr/ccs/release/7.3/lib_ia32/ld -t -melf_i386 -u MAIN__ -dynamic-linker /lib/ld-linux.so.2 --allow-multiple-definition /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/gcc/i386-redhat-linux/4.1.2/crtbeginT.o -v CMakeFiles/cmTryCompileExec3453195864.dir/testFortranCompiler.f.o -r -L/usr/ccs/release/7.3/lib_ia32 -L/usr/lib/gcc/i386-redhat-linux/4.1.2 -lhU77 -lhF77 -lhI77 -lrt -lm -lgcc -lgcc_eh -lc -lgcc -lgcc_eh -o cmTryCompileExec3453195864 /usr/lib/gcc/i386-redhat-linux/4.1.2/crtend.o /usr/lib/crtn.o GNU ld version 2.17.50.0.6-5.el5 20061020 /usr/ccs/release/7.3/lib_ia32/ld: mode elf_i386 /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/gcc/i386-redhat-linux/4.1.2/crtbeginT.o CMakeFiles/cmTryCompileExec3453195864.dir/testFortranCompiler.f.o (/usr/ccs/release/7.3/lib_ia32/libhF77.a)main.o (/usr/ccs/release/7.3/lib_ia32/libhF77.a)main2.o (/usr/ccs/release/7.3/lib_ia32/libhF77.a)no_lg.o (/usr/ccs/release/7.3/lib_ia32/libhF77.a)xarg.o (/usr/ccs/release/7.3/lib_ia32/libhF77.a)fperoundset.o (/usr/ccs/release/7.3/lib_ia32/libhF77.a)fpetrapset.o (/usr/ccs/release/7.3/lib_ia32/libhI77.a)close.o (/usr/ccs/release/7.3/lib_ia32/libhI77.a)err.o (/usr/ccs/release/7.3/lib_ia32/libhI77.a)f_errlist.o (/usr/ccs/release/7.3/lib_ia32/libhI77.a)hf77_io.o (/usr/ccs/release/7.3/lib_ia32/libhI77.a)lwrite.o (/usr/ccs/release/7.3/lib_ia32/libhI77.a)open.o (/usr/ccs/release/7.3/lib_ia32/libhI77.a)util.o (/usr/ccs/release/7.3/lib_ia32/libhI77.a)wrtfmt.o (/usr/ccs/release/7.3/lib_ia32/libhI77.a)dofio.o (/usr/ccs/release/7.3/lib_ia32/libhI77.a)dolio.o (/usr/ccs/release/7.3/lib_ia32/libhI77.a)douio.o (/usr/ccs/release/7.3/lib_ia32/libhI77.a)fmt.o (/usr/ccs/release/7.3/lib_ia32/libhI77.a)fmtlib.o (/usr/ccs/release/7.3/lib_ia32/libhI77.a)sue.o /usr/ccs/release/7.3/lib_ia32/ld: cannot find -lrt This e-mail (including attachments) contains contents owned by Rolls-Royce plc and its subsidiaries, affiliated companies or customers and covered by the laws of England and Wales, Brazil, US, or Canada (federal, state or provincial). The information contained in this email is intended to be confidential, may be legally privileged and subject to export controls which may restrict the access to and transfer of the information. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, interception or copying of this communication is strictly prohibited and may subject you to further legal action. Reply to the sender if you received this email by accident, and then delete the email and any attachments. From brad.king at kitware.com Tue Jun 16 09:51:27 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 16 Jun 2015 09:51:27 -0400 Subject: [CMake] fortran compiler failed to compile simple test program In-Reply-To: <2A375B5C08C24643A8A3F8CC2B98C1084BAD83FB@USINDPR-MBX003.Rolls-Royce.Local> References: <2A375B5C08C24643A8A3F8CC2B98C1084BAD8011@USINDPR-MBX003.Rolls-Royce.Local> <557F045F.30804@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD809E@USINDPR-MBX003.Rolls-Royce.Local> <557F13CA.50903@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD80FC@USINDPR-MBX003.Rolls-Royce.Local> <557F2532.5000403@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD8142@USINDPR-MBX003.Rolls-Royce.Local> <557F2F6D.6040804@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD82C0@USINDPR-MBX003.Rolls-Royce.Local> <55801A96.7080600@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD83FB@USINDPR-MBX003.Rolls-Royce.Local> Message-ID: <558029DF.9090403@kitware.com> On 06/16/2015 09:31 AM, Ette, Anthony (CDS) wrote: > rts1-4:/home/bzpl46/test2/CMakeFiles/CMakeTmp> /usr/ccs/bin/cf77 CMakeFiles/cmTryCompileExec3453195864.dir/testFortranCompiler.f.o -o cmTryCompileExec3453195864 -rdynamic > /usr/ccs/release/7.3/lib_ia32/ld: cannot find -lrt That shows it can be reproduced locally outside of CMake. Please try dropping -rdynamic from that command line. -Brad From Anthony.R.Ette at controlsdata.com Tue Jun 16 10:00:46 2015 From: Anthony.R.Ette at controlsdata.com (Ette, Anthony (CDS)) Date: Tue, 16 Jun 2015 14:00:46 +0000 Subject: [CMake] fortran compiler failed to compile simple test program In-Reply-To: <558029DF.9090403@kitware.com> References: <2A375B5C08C24643A8A3F8CC2B98C1084BAD8011@USINDPR-MBX003.Rolls-Royce.Local> <557F045F.30804@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD809E@USINDPR-MBX003.Rolls-Royce.Local> <557F13CA.50903@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD80FC@USINDPR-MBX003.Rolls-Royce.Local> <557F2532.5000403@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD8142@USINDPR-MBX003.Rolls-Royce.Local> <557F2F6D.6040804@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD82C0@USINDPR-MBX003.Rolls-Royce.Local> <55801A96.7080600@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD83FB@USINDPR-MBX003.Rolls-Royce.Local> <558029DF.9090403@kitware.com> Message-ID: <2A375B5C08C24643A8A3F8CC2B98C1084BAD84B8@USINDPR-MBX003.Rolls-Royce.Local> >> rts1-4:/home/bzpl46/test2/CMakeFiles/CMakeTmp> /usr/ccs/bin/cf77 CMakeFiles/cmTryCompileExec3453195864.dir/testFortranCompiler.f.o -o cmTryCompileExec3453195864 -rdynamic >> /usr/ccs/release/7.3/lib_ia32/ld: cannot find -lrt >That shows it can be reproduced locally outside of CMake. >Please try dropping -rdynamic from that command line. Ahh, you are correct. Success! What does this mean? This e-mail (including attachments) contains contents owned by Rolls-Royce plc and its subsidiaries, affiliated companies or customers and covered by the laws of England and Wales, Brazil, US, or Canada (federal, state or provincial). The information contained in this email is intended to be confidential, may be legally privileged and subject to export controls which may restrict the access to and transfer of the information. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, interception or copying of this communication is strictly prohibited and may subject you to further legal action. Reply to the sender if you received this email by accident, and then delete the email and any attachments. From brad.king at kitware.com Tue Jun 16 10:08:02 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 16 Jun 2015 10:08:02 -0400 Subject: [CMake] fortran compiler failed to compile simple test program In-Reply-To: <2A375B5C08C24643A8A3F8CC2B98C1084BAD84B8@USINDPR-MBX003.Rolls-Royce.Local> References: <2A375B5C08C24643A8A3F8CC2B98C1084BAD8011@USINDPR-MBX003.Rolls-Royce.Local> <557F045F.30804@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD809E@USINDPR-MBX003.Rolls-Royce.Local> <557F13CA.50903@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD80FC@USINDPR-MBX003.Rolls-Royce.Local> <557F2532.5000403@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD8142@USINDPR-MBX003.Rolls-Royce.Local> <557F2F6D.6040804@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD82C0@USINDPR-MBX003.Rolls-Royce.Local> <55801A96.7080600@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD83FB@USINDPR-MBX003.Rolls-Royce.Local> <558029DF.9090403@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD84B8@USINDPR-MBX003.Rolls-Royce.Local> Message-ID: <55802DC2.4040205@kitware.com> On 06/16/2015 10:00 AM, Ette, Anthony (CDS) wrote: >> That shows it can be reproduced locally outside of CMake. >> Please try dropping -rdynamic from that command line. > > Ahh, you are correct. Success! What does this mean? This means CMake needs to be able to define and detect an id for this compiler so that it can know that -rdynamic is not supported. Currently the compiler looks like a GNU compiler which does support the flags. Even if a preprocessor symbol is not available CMake does have other ways to detect the compiler id. We need to be able to run the compiler with just one flag that causes it to print out some kind of identifying information but not compile anything. See here for some examples: http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/CMakeDetermineFortranCompiler.cmake;hb=v3.3.0-rc2#l114 -Brad From Anthony.R.Ette at controlsdata.com Tue Jun 16 10:08:19 2015 From: Anthony.R.Ette at controlsdata.com (Ette, Anthony (CDS)) Date: Tue, 16 Jun 2015 14:08:19 +0000 Subject: [CMake] fortran compiler failed to compile simple test program References: <2A375B5C08C24643A8A3F8CC2B98C1084BAD8011@USINDPR-MBX003.Rolls-Royce.Local> <557F045F.30804@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD809E@USINDPR-MBX003.Rolls-Royce.Local> <557F13CA.50903@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD80FC@USINDPR-MBX003.Rolls-Royce.Local> <557F2532.5000403@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD8142@USINDPR-MBX003.Rolls-Royce.Local> <557F2F6D.6040804@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD82C0@USINDPR-MBX003.Rolls-Royce.Local> <55801A96.7080600@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD83FB@USINDPR-MBX003.Rolls-Royce.Local> <558029DF.9090403@kitware.com> Message-ID: <2A375B5C08C24643A8A3F8CC2B98C1084BAD84DF@USINDPR-MBX003.Rolls-Royce.Local> > Ahh, you are correct. Success! What does this mean? I found this in the cf77 release notes, not sure if it means anything to us at this point. Linking with gcc, g++ or g77: This release ships with its own updated linker (ld) that can interpret DWARF 3. If you link cf77generated code using the gcc, g++, or g77 commands, they should be directed to use this alternativeld. This may be done by setting the COMPILER_PATH environment variable to one of the followingvalues:COMPILER_PATH=/usr/ccs/release/7.2/lib_ia32COMPILER_PATH=/usr/ccs/release/7.2/lib_amd64for 32-bit Pentium code or 64-bit AMD64 code, respectively. It important that the correct path bechosen.To make the COMPILER_PATH effective for the duration of a shell invocation, it can be exported:export COMPILER_PATH=...Or the variable may be set for a single invocation:COMPILER_PATH=... gcc ...If the COMPILER_PATH environment variable is omitted, the default system linker will be used; it willwork on correct programs, but error diagnostics may be inaccurate.The cf77 command will use the alternative ld without requiring the user to set the COMPILER_PATHenvironment variable. This e-mail (including attachments) contains contents owned by Rolls-Royce plc and its subsidiaries, affiliated companies or customers and covered by the laws of England and Wales, Brazil, US, or Canada (federal, state or provincial). The information contained in this email is intended to be confidential, may be legally privileged and subject to export controls which may restrict the access to and transfer of the information. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, interception or copying of this communication is strictly prohibited and may subject you to further legal action. Reply to the sender if you received this email by accident, and then delete the email and any attachments. From mike.jackson at bluequartz.net Tue Jun 16 10:27:09 2015 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Tue, 16 Jun 2015 10:27:09 -0400 Subject: [CMake] Xcode project generation failed Message-ID: Running OS X 10.8.5 with Xcode 5.1.1 and Cmake 3.2.x and 3.3.RC and neither generate a Xcode project file that can be opened by Xcode. We get valid Ninja and Makefile projects for our project. I was wondering if anyone else has seen this issue. Not sure if there is something in our project that is hanging up CMake. Thanks for any insights. Mike Jackson BlueQuartz Software. From rjvbertin at gmail.com Tue Jun 16 10:59:19 2015 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Tue, 16 Jun 2015 16:59:19 +0200 Subject: [CMake] --sphinx-qthelp leads to build error with CMake 3.2.3 Message-ID: <4909201.GkMUmDLSMn@portia.local> Hi, I'm trying to build the latest CMake release, with the Qt4 gui and including the docs in Qt help format. I'm using the same "recipe" as for the 3.2.2 release, but now I see this: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [ 95%] sphinx-build qthelp: see Utilities/Sphinx/build-qthelp.log cd /build//cmake-3.2.3/Utilities/Sphinx && /opt/local/bin/sphinx-build-3.4 -c /build//cmake-3.2.3/Utilities/Sphinx -d /build//cmake-3.2.3/Utilities/Sphinx/doctrees -b qthelp /build//cmake-3.2.3/Help /build//cmake-3.2.3/Utilities/Sphinx/qthelp > build-qthelp.log WARNING: 'default' html theme has been renamed to 'classic'. Please change your html_theme setting either to the new 'alabaster' default theme, or to 'classic' to keep using the old default. cd /build//cmake-3.2.3/Utilities/Sphinx && ../../Bootstrap.cmk/cmake -DCSS_DIR=/build//cmake-3.2.3/Utilities/Sphinx/qthelp/_static -P /build//cmake-3.2.3/Utilities/Sphinx/apply_qthelp_css_workaround.cmake CMake Error at apply_qthelp_css_workaround.cmake:4 (file): file failed to open for reading (No such file or directory): /build//cmake-3.2.3/Utilities/Sphinx/qthelp/_static/default.css Utilities/Sphinx/CMakeFiles/documentation.dir/build.make:63: recipe for target 'Utilities/Sphinx/doc_format_qthelp' failed make[2]: *** [Utilities/Sphinx/doc_format_qthelp] Error 1 ><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< I cannot vouch that the WARNING wasn't already there last time, but the fact that a file called default.css is missing while there is a classic.css might be significant. I've google the error a bit, but so far haven't found anything relevant AND recent. Thanks, Ren? From Anthony.R.Ette at controlsdata.com Tue Jun 16 13:44:42 2015 From: Anthony.R.Ette at controlsdata.com (Ette, Anthony (CDS)) Date: Tue, 16 Jun 2015 17:44:42 +0000 Subject: [CMake] fortran compiler failed to compile simple test program In-Reply-To: <55802DC2.4040205@kitware.com> References: <2A375B5C08C24643A8A3F8CC2B98C1084BAD8011@USINDPR-MBX003.Rolls-Royce.Local> <557F045F.30804@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD809E@USINDPR-MBX003.Rolls-Royce.Local> <557F13CA.50903@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD80FC@USINDPR-MBX003.Rolls-Royce.Local> <557F2532.5000403@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD8142@USINDPR-MBX003.Rolls-Royce.Local> <557F2F6D.6040804@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD82C0@USINDPR-MBX003.Rolls-Royce.Local> <55801A96.7080600@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD83FB@USINDPR-MBX003.Rolls-Royce.Local> <558029DF.9090403@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD84B8@USINDPR-MBX003.Rolls-Royce.Local> <55802DC2.4040205@kitware.com> Message-ID: <2A375B5C08C24643A8A3F8CC2B98C1084BAD86E8@USINDPR-MBX003.Rolls-Royce.Local> > http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/CMakeDetermineFortranCompiler.cmake;hb=v3.3.0-rc2#l114 Ok. I'm still struggling getting anything unique from the cf77 command line. They have plenty of custom functions that can be invoked outside of cf77 but that wouldn't be suitable for cmake. Also, I got a response from Concurrent on the issue with the -rdynamic option. Please see his resonse below and let me know what you think. I need to get Cmake to work and, ideally, I'd like it to work with -rdynamic. I'm wondering if there is something they can change (other than the ugly kludge he references) to get -rdynamic to work. Hi Anthony: Okay, the -rdynamic option to cf77 instructs it to build a shared object (shared library), not an executable program. I doubt this is what you intended, rather CMake just wanted to link the program with the system dynamic libraries -- it's unclear. By default, cf77 links in all system libraries dynamically anyway, which is a standard default way most compilers operate in the Linux world. I'm not sure why CMake would be passing -rdynamic along, unless you really are trying to build a dynamic fortran shared library. (It is possible it is trying to force a transitive closure of symbol references for debugging purposes -- that's what gcc describes its -rdynamic option as doing). I don't use CMake, and I can imagine it may be difficult to use if it isn't flexible wrt compilation and linking options. If you could abandon CMake for standard GNU make, that would be good, but of course that may not be acceptable to you in terms of man power, style, etc. If CMake is indeed forcing this option on every command that links a program, the best I can recommend is to replace the /usr/css/bin/cf77 with a wrapper that strips out the option and then continues to invoke the real cf77. That is of course a horrible kludge. If you would like me to supply you with that (albeit disgusting) workaround, just let me know. I'd recommend fighting with CMake first. Alternative, I can supply you with some simple example gmake Makefiles that you might use with cf77. Please let me know what you think about this. Also, I'm concerned that your man pages are not installed properly (the CF77 man pages). I recommend doing the following to rectify that: rpm -q ccurf77-manpages-7.3 --nodeps rpm -Uvh cf77-manpages-7.3*.rpm # File attached man cf77 If that does not work, please try the following: man -M /opt/ccur/compilers-7.3/man cf77 If that works, then you can put that path in your MANPATH environment variable, or edit /etc/man.config and put the path in that file so everyone will benefit from it. Alternatively, we can chase this down to the final bit depending on how much time you want to spend on it. -- Jeff This e-mail (including attachments) contains contents owned by Rolls-Royce plc and its subsidiaries, affiliated companies or customers and covered by the laws of England and Wales, Brazil, US, or Canada (federal, state or provincial). The information contained in this email is intended to be confidential, may be legally privileged and subject to export controls which may restrict the access to and transfer of the information. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, interception or copying of this communication is strictly prohibited and may subject you to further legal action. Reply to the sender if you received this email by accident, and then delete the email and any attachments. From brad.king at kitware.com Tue Jun 16 13:51:31 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 16 Jun 2015 13:51:31 -0400 Subject: [CMake] fortran compiler failed to compile simple test program In-Reply-To: <2A375B5C08C24643A8A3F8CC2B98C1084BAD86E8@USINDPR-MBX003.Rolls-Royce.Local> References: <2A375B5C08C24643A8A3F8CC2B98C1084BAD8011@USINDPR-MBX003.Rolls-Royce.Local> <557F045F.30804@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD809E@USINDPR-MBX003.Rolls-Royce.Local> <557F13CA.50903@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD80FC@USINDPR-MBX003.Rolls-Royce.Local> <557F2532.5000403@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD8142@USINDPR-MBX003.Rolls-Royce.Local> <557F2F6D.6040804@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD82C0@USINDPR-MBX003.Rolls-Royce.Local> <55801A96.7080600@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD83FB@USINDPR-MBX003.Rolls-Royce.Local> <558029DF.9090403@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD84B8@USINDPR-MBX003.Rolls-Royce.Local> <55802DC2.4040205@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD86E8@USINDPR-MBX003.Rolls-Royce.Local> Message-ID: <55806223.5080305@kitware.com> On 06/16/2015 01:44 PM, Ette, Anthony (CDS) wrote: > I'm still struggling getting anything unique from the cf77 command line. What is the output of "cf77 --version"? > Okay, the -rdynamic option to cf77 instructs it to build > a shared object (shared library), not an executable program. That may be what it tells cf77 but that is not what it tells gcc. From "man gcc": -rdynamic Pass the flag -export-dynamic to the ELF linker, on targets that support it. This instructs the linker to add all symbols, not only used ones, to the dynamic symbol table. This option is needed for some uses of "dlopen" or to allow obtaining backtraces from within a program. Anyway we should drop it for cf77 once we can identify that compiler as distinct from a GNU compiler. -Brad From Anthony.R.Ette at controlsdata.com Tue Jun 16 14:01:21 2015 From: Anthony.R.Ette at controlsdata.com (Ette, Anthony (CDS)) Date: Tue, 16 Jun 2015 18:01:21 +0000 Subject: [CMake] fortran compiler failed to compile simple test program In-Reply-To: <55806223.5080305@kitware.com> References: <2A375B5C08C24643A8A3F8CC2B98C1084BAD8011@USINDPR-MBX003.Rolls-Royce.Local> <557F045F.30804@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD809E@USINDPR-MBX003.Rolls-Royce.Local> <557F13CA.50903@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD80FC@USINDPR-MBX003.Rolls-Royce.Local> <557F2532.5000403@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD8142@USINDPR-MBX003.Rolls-Royce.Local> <557F2F6D.6040804@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD82C0@USINDPR-MBX003.Rolls-Royce.Local> <55801A96.7080600@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD83FB@USINDPR-MBX003.Rolls-Royce.Local> <558029DF.9090403@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD84B8@USINDPR-MBX003.Rolls-Royce.Local> <55802DC2.4040205@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD86E8@USINDPR-MBX003.Rolls-Royce.Local> <55806223.5080305@kitware.com> Message-ID: <2A375B5C08C24643A8A3F8CC2B98C1084BAD8725@USINDPR-MBX003.Rolls-Royce.Local> > What is the output of "cf77 --version"? Garbage (see below): rts1-4:/home/bzpl46> cf77 --version cf77 Fatal Error: invalid flag -io I've scoured the cf77 docs and found nothing native so I've responded to concurrent and again asked how I can find unique identifying information for cmake to latch onto. Will report back. > That may be what it tells cf77 but that is not what it tells gcc. From "man gcc": > Anyway we should drop it for cf77 once we can identify that compiler as distinct from a GNU compiler. Agreed on both counts although I've challenged concurrent to justify their decision to treat -rdynamic different than standard GNU. I think ideally cf77 would handle -rdynamic same as standard GNU. If that's really not an option, we should continue down the path of having cmake identify cf77 and strip the option. Thank you again for all your help - you rock! This e-mail (including attachments) contains contents owned by Rolls-Royce plc and its subsidiaries, affiliated companies or customers and covered by the laws of England and Wales, Brazil, US, or Canada (federal, state or provincial). The information contained in this email is intended to be confidential, may be legally privileged and subject to export controls which may restrict the access to and transfer of the information. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, interception or copying of this communication is strictly prohibited and may subject you to further legal action. Reply to the sender if you received this email by accident, and then delete the email and any attachments. From gjasny at googlemail.com Tue Jun 16 15:27:52 2015 From: gjasny at googlemail.com (Gregor Jasny) Date: Tue, 16 Jun 2015 21:27:52 +0200 Subject: [CMake] Xcode project generation failed In-Reply-To: References: Message-ID: <558078B8.8040006@googlemail.com> Hello, I applied some fixes to what becomes CMake 3.3. could you please test the release candidate? On 16/06/15 16:27, Michael Jackson wrote: > Running OS X 10.8.5 with Xcode 5.1.1 and Cmake 3.2.x and 3.3.RC and neither generate a Xcode project file that can be opened by Xcode. We get valid Ninja and Makefile projects for our project. I was wondering if anyone else has seen this issue. Not sure if there is something in our project that is hanging up CMake. Could you share your project.pbxproj file (if don't want to share it here you could also mail it to me directly). Thanks, Gregor From gjasny at googlemail.com Tue Jun 16 15:34:25 2015 From: gjasny at googlemail.com (Gregor Jasny) Date: Tue, 16 Jun 2015 21:34:25 +0200 Subject: [CMake] Xcode project generation failed In-Reply-To: <558078B8.8040006@googlemail.com> References: <558078B8.8040006@googlemail.com> Message-ID: <55807A41.1090609@googlemail.com> On 16/06/15 21:27, Gregor Jasny wrote: > Hello, > > I applied some fixes to what becomes CMake 3.3. could you please test > the release candidate? Sorry, somehow overlooked the statement about RC in your mail. > On 16/06/15 16:27, Michael Jackson wrote: >> Running OS X 10.8.5 with Xcode 5.1.1 and Cmake 3.2.x and 3.3.RC and neither generate a Xcode project file that can be opened by Xcode. We get valid Ninja and Makefile projects for our project. I was wondering if anyone else has seen this issue. Not sure if there is something in our project that is hanging up CMake. > > Could you share your project.pbxproj file (if don't want to share it > here you could also mail it to me directly). From j.kreuzberger at procitec.de Wed Jun 17 04:25:40 2015 From: j.kreuzberger at procitec.de (=?utf-8?Q?J=C3=B6rg_Kreuzberger?=) Date: Wed, 17 Jun 2015 10:25:40 +0200 Subject: [CMake] =?utf-8?q?MinGW_and_sh=2Eexe?= Message-ID: 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 From mjklaim at gmail.com Wed Jun 17 08:09:39 2015 From: mjklaim at gmail.com (=?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?=) Date: Wed, 17 Jun 2015 14:09:39 +0200 Subject: [CMake] How does :: actually works? In-Reply-To: <10549345.795GcQO5j7@ersa> References: <6642590.gJq68crCL0@ersa> <10549345.795GcQO5j7@ersa> Message-ID: On 16 June 2015 at 11:49, Johannes Zarl-Zierl wrote: > On Monday 15 June 2015 22:43:41 you wrote: > > Just a last question: I assume that most find module scripts distributed > > with cmake are > > not using this feature at the moment, right? > > Sadly, no. > > > After reading your explaination I looked at documentation for FindBoost > and > > FindGTest > > which are both used in all my projects and they dont seem to provide > import > > targets. > > Are there plans to update the cmake scripts distributed with CMake > > On the one hand, FindPackage modules are, as far as I'm aware, slowly being > updated to use imported targets. On the other hand, quite a few packages > are > missing a maintainer[1]. If you are using a package and want it to provide > imported targets, I think your best bet is to propose a patch for the > module > and get it into cmake. > > That said, its worth mentioning that FindPackage modules are only intended > for > "legacy" projects which do not provide a PackageConfig.cmake file. If you > are > writing a new project, especially if it's based on cmake, you should write > a > PackageConfig.cmake file instead [2]. > > I didn't realize at all that the FindPackage way is supposed to be obsolete now. I'm quite surprised actually. Ok I'll check PackageConfig.cmake for my new and even current projects if it can help with managing the tons of libraries I work on. > > or is it just assumed that projects willing to use importing targets will > > write them somewhere before using them? > > Creating imported targets on your own is not the way to go. Better file a > bug > report or write a patch to add the functionality and get that into cmake. > IMO, until the official module provides imported targets, you're better > off using > the old way. > > I will consider providing patches, if I can spend time on this once and not bother later it would help a lot. Thanks again for these explainations. > Cheers, > Johannes > > [1] http://www.cmake.org/Wiki/CMake:Module_Maintainers#List > [2] http://www.cmake.org/Wiki/CMake/Tutorials#CMake_Packages > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.jackson at bluequartz.net Wed Jun 17 10:29:25 2015 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Wed, 17 Jun 2015 10:29:25 -0400 Subject: [CMake] Xcode project generation failed In-Reply-To: <558078B8.8040006@googlemail.com> References: <558078B8.8040006@googlemail.com> Message-ID: <3F799085-A695-42C9-9058-4A150463580C@bluequartz.net> On Jun 16, 2015, at 3:27 PM, Gregor Jasny wrote: > Hello, > > I applied some fixes to what becomes CMake 3.3. could you please test > the release candidate? > > On 16/06/15 16:27, Michael Jackson wrote: >> Running OS X 10.8.5 with Xcode 5.1.1 and Cmake 3.2.x and 3.3.RC and neither generate a Xcode project file that can be opened by Xcode. We get valid Ninja and Makefile projects for our project. I was wondering if anyone else has seen this issue. Not sure if there is something in our project that is hanging up CMake. > > Could you share your project.pbxproj file (if don't want to share it > here you could also mail it to me directly). > > Thanks, > Gregor Just to follow up with this issue in case anyone else has issues with Xcode here is what happened. Thanks to Gregor for taking a look at the generated project file he was able to identify an issue where there were file paths in the form of "//" inside the project file. They specifically showed in the form of: /* // */. This was enough to throw the Xcode parser and send Xcode into the spin-of-death. The root cause of the issue is that I had a cmake variable that held all my source files. In that list was a file path, where the path was completely created through cmake variables, set(FOO_FILE "${SomethingLib_path}/${SOME_HEADER_PATH}) but neither of those variables had been defined for this project. (Copy paste mistake). This resulted in the cmake variable (FOO_FILE from above) being empty but still included as a source in the add_library() call. Fixing the cmake variables fixed the Xcode generation issue. I also want to recognize "git" for being helpful in all of this which allowed to quickly figure out which commit broke the Xcode functionality. Hope this helps someone in the future. Mike Jackson From Anthony.R.Ette at controlsdata.com Wed Jun 17 11:07:52 2015 From: Anthony.R.Ette at controlsdata.com (Ette, Anthony (CDS)) Date: Wed, 17 Jun 2015 15:07:52 +0000 Subject: [CMake] fortran compiler failed to compile simple test program References: <2A375B5C08C24643A8A3F8CC2B98C1084BAD8011@USINDPR-MBX003.Rolls-Royce.Local> <557F045F.30804@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD809E@USINDPR-MBX003.Rolls-Royce.Local> <557F13CA.50903@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD80FC@USINDPR-MBX003.Rolls-Royce.Local> <557F2532.5000403@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD8142@USINDPR-MBX003.Rolls-Royce.Local> <557F2F6D.6040804@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD82C0@USINDPR-MBX003.Rolls-Royce.Local> <55801A96.7080600@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD83FB@USINDPR-MBX003.Rolls-Royce.Local> <558029DF.9090403@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD84B8@USINDPR-MBX003.Rolls-Royce.Local> <55802DC2.4040205@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD86E8@USINDPR-MBX003.Rolls-Royce.Local> <55806223.5080305@kitware.com> Message-ID: <2A375B5C08C24643A8A3F8CC2B98C1084BAD8AA3@USINDPR-MBX003.Rolls-Royce.Local> >I've scoured the cf77 docs and found nothing native so I've responded to concurrent and again asked how I can find unique identifying information for cmake to latch onto. Will report back. Please see the response below about uniquely identifying cf77. Does this seem doable? How do we proceed with rolling into CMakeDetermineFortranCompiler and do I have a workaround that I can use for now until this gets rolled into cmake? Anthony, Some commands and answers to your last email... >Can you elaborate as to why cf77 must treat -rdynamic different from GNU standard? In many ways, cf77 pre-dates GNU. When porting cf77 to the Linux/GNU environment, option processing was made GNU-like when appropriate, but without allowing legacy options to change (would breaking exiting customer build schemes). In reality, cf77 treats -rdynamic as a string of individual options, which in this case is being parsed as: * -r -- Pass to ld; generate a shared object * -d -- A cf77 debug option. The remainder of the option string (namic) is considered as additional -d flags. Now gcc interprets -rdynamic as an individual option, and ends up not passing the -r to ld, but -export-dynamic, as you indicated in your email. >The cmake developers have agreed to roll this in, I just need a way of uniquely identifying cf77 from any other compiler. Unfortunately, I don't have a nice clean solution for you. I guess it depends on how much trouble the cmake developers want to go to to detect cf77. In order to identify the compiler as cf77, do something akin to the following: $ echo ' PROGRAM V' > /tmp/nil.f $ echo ' END' >> /tmp/nil.f $ cf77 -v -o /dev/null -c /tmp/nil.f 2>&1 | fgrep "Concurrent Fortran" 2>&1 | fgrep Concurrent Concurrent Fortran 77 Compiler - Version 7.3 Wed Jun 17 06:52:27 2015 Alternatively, one could examine the resultant object file's DWARF information and extract the DW_AT_producer attribute from the DW_TAG_compilation unit DIE for the object file. $ cf77 -c -g /tmp/nil.f -o /tmp/nil.o $ readelf --debug-dump=info /tmp/nil.o | fgrep DW_AT_producer DW_AT_producer : Concurrent Fortran 77 In terms of identifying the major and minor versions, the information isn't as readily available as one would like. The major version number is included in the -v output of the compiler (see above). However, the minor version number is only available from the RPM: $ rpm -qa --qf="%{NAME}-%{VERSION}\n" 'ccur-f77-[0-9]*' ccur-f77-32-7.3-006 $ rpm -qa --qf="%{NAME}-%{VERSION}\n" 'ccur-f77-[0-9]*' | sed "s/^ccur-f77-..-//" 7.3-006 Note that the major version number is actually part of the RPM's "name" and the minor version number is the RPM's "version" (cf77 supports having multiple major versions of the compiler installed on one system -- hence the major version number being embedded in the name). Did you receive my email regarding the cf77 man page issue? Regards, Jeff This e-mail (including attachments) contains contents owned by Rolls-Royce plc and its subsidiaries, affiliated companies or customers and covered by the laws of England and Wales, Brazil, US, or Canada (federal, state or provincial). The information contained in this email is intended to be confidential, may be legally privileged and subject to export controls which may restrict the access to and transfer of the information. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, interception or copying of this communication is strictly prohibited and may subject you to further legal action. Reply to the sender if you received this email by accident, and then delete the email and any attachments. From cary at txcorp.com Wed Jun 17 11:01:21 2015 From: cary at txcorp.com (JR Cary) Date: Wed, 17 Jun 2015 09:01:21 -0600 Subject: [CMake] CUDA OBJECT libraries? Message-ID: <55818BC1.2020503@txcorp.com> I would like to use OBJECT libraries with CUDA. If I try cuda_add_library(foo OBJECT ) I get CMake Error at /opt/contrib-clangcxx11/cmake-3.2.2-ser/share/cmake-3.2/Modules/FindCUDA.cmake:1518 (add_library): OBJECT library "txsbaseobj" contains: txsbaseobj_generated_TxsGpuInterpolator.cu.o txsbaseobj_generated_TxsBaseTestKernels.cu.o txsbaseobj_intermediate_link.o Is there a standard way of dealing with this? Thx....... -------------- next part -------------- An HTML attachment was scrubbed... URL: From oto.petrik at gmail.com Wed Jun 17 13:18:34 2015 From: oto.petrik at gmail.com (=?UTF-8?B?T3RvIFBldMWZw61r?=) Date: Wed, 17 Jun 2015 19:18:34 +0200 Subject: [CMake] What is the recommended ways to find libraries Message-ID: Hi, > Let's say my project wants to depend on a library PKG1 (here PKG1 can > be MPFR, MPC, PTHREAD, GMP, BZIP2, you name it). Let's say the library > is installed in $PKG1/include, $PKG1/lib, alternatively, all my > dependencies are installed in $HASHSTACK/include and $HASHSTACK/lib, > or perhaps they are installed system wide. > Perhaps I am missing the official recommendation regarding the above, > so that's why I am asking here. But if there is none, then I think the > current state is unsatisfactory. you may be looking for CMAKE_PREFIX_PATH (http://www.cmake.org/cmake/help/v3.2/variable/CMAKE_PREFIX_PATH.html) cmake -DCMAKE_PREFIX_PATH=$HOME/built-libs/gmp;$HOME/built-libs/arb;$HOME/built-libs/otherdependencies (or have a script that sets CMAKE_PREFIX_PATH environment variable) works with find_module, find_file, find_library,... expects directories to have standard structure (include,lib,...), see documentation of find_* commands for details. it is usually enough to set CMAKE_PREFIX_PATH to DESTDIRs used in dependencies' "make install DESTDIR=/foo" you may want to remove NO_DEFAULT_PATH as used in linked LibFindMacros.cmake, it disables this functionality. Regards, Oto Petrik From roland at utk.edu Wed Jun 17 14:39:46 2015 From: roland at utk.edu (Roland Schulz) Date: Wed, 17 Jun 2015 14:39:46 -0400 Subject: [CMake] check_library_exists, built-in, and -Werror Message-ID: Hi, When using CFLAGS=-Werror $ check_library_exists(m sqrt "" HAVE_LIBM) fails to give the correct result. A very similar issue has been reported before for CHECK_FUNCTION_EXISTS http://www.cmake.org/Bug/view.php?id=8246 There the recommendation was to use CHECK_SYMBOL_EXISTS instead. My questions: 1) Is there an replacement for check_library_exists which gives the correct results for built-ins even with -Werror? 2) Should check_library_exists correctly work in this case and should I open a bug for it? Roland -- ORNL/UT Center for Molecular Biophysics cmb.ornl.gov 865-241-1537, ORNL PO BOX 2008 MS6309 -------------- next part -------------- An HTML attachment was scrubbed... URL: From steveire at gmail.com Wed Jun 17 14:50:22 2015 From: steveire at gmail.com (Stephen Kelly) Date: Wed, 17 Jun 2015 20:50:22 +0200 Subject: [CMake] How does :: actually works? References: <6642590.gJq68crCL0@ersa> <10549345.795GcQO5j7@ersa> Message-ID: Klaim - Jo?l Lamotte wrote: > I didn't realize at all that the FindPackage way is supposed to be > obsolete now. It is not obsolete, but it is not a good approach (since CMake 2.6.0 already) if the upstream uses cmake, because config file packages provide a better experience for downstreams http://www.cmake.org/cmake/help/v3.2/manual/cmake-packages.7.html Even for upstreams that do not use cmake, it is preferable to generate config file packages for a good downstream experience for cmake users. That is what Qt qmake and LLVM Makefile buildsystems do. Boost b2 could do it too: http://thread.gmane.org/gmane.comp.lib.boost.devel/259011/focus=259445 > I'm quite surprised actually. We prefer not to accept new Find modules into the cmake tree because that puts the maintenance burden on us, and because it is an inferior user experience. Some new Find modules still get in, but they need to have a reason to get in. > Ok I'll check PackageConfig.cmake for my new and even current projects > if it can help with managing the tons of libraries I work on. Do please let us know how that goes. > I will consider providing patches, if I can spend time on this once and > not bother > later it would help a lot. Documentation here explains how to do that for Find modules: http://www.cmake.org/cmake/help/v3.2/manual/cmake-developer.7.html#a-sample-find-module Thanks, Steve. From gjasny at googlemail.com Wed Jun 17 14:51:39 2015 From: gjasny at googlemail.com (Gregor Jasny) Date: Wed, 17 Jun 2015 20:51:39 +0200 Subject: [CMake] Xcode project generation failed In-Reply-To: <3F799085-A695-42C9-9058-4A150463580C@bluequartz.net> References: <558078B8.8040006@googlemail.com> <3F799085-A695-42C9-9058-4A150463580C@bluequartz.net> Message-ID: <5581C1BB.6040408@googlemail.com> On 17/06/15 16:29, Michael Jackson wrote: > Just to follow up with this issue in case anyone else has issues with Xcode here is what happened. Thanks to Gregor for taking a look at the generated project file he was able to identify an issue where there were file paths in the form of "//" inside the project file. They specifically showed in the form of: /* // */. This was enough to throw the Xcode parser and send Xcode into the spin-of-death. The root cause of the issue is that I had a cmake variable that held all my source files. In that list was a file path, where the path was completely created through cmake variables, > > set(FOO_FILE "${SomethingLib_path}/${SOME_HEADER_PATH}) > > but neither of those variables had been defined for this project. (Copy paste mistake). This resulted in the cmake variable (FOO_FILE from above) being empty but still included as a source in the add_library() call. Fixing the cmake variables fixed the Xcode generation issue. I will create a topic branch with a fixed Xcode generator. Thanks, Gregor From ondrej.certik at gmail.com Wed Jun 17 15:00:08 2015 From: ondrej.certik at gmail.com (=?UTF-8?B?T25kxZllaiDEjGVydMOtaw==?=) Date: Wed, 17 Jun 2015 13:00:08 -0600 Subject: [CMake] What is the recommended ways to find libraries In-Reply-To: References: Message-ID: Hi Oto, On Wed, Jun 17, 2015 at 11:18 AM, Oto Pet??k wrote: > Hi, > >> Let's say my project wants to depend on a library PKG1 (here PKG1 can >> be MPFR, MPC, PTHREAD, GMP, BZIP2, you name it). Let's say the library >> is installed in $PKG1/include, $PKG1/lib, alternatively, all my >> dependencies are installed in $HASHSTACK/include and $HASHSTACK/lib, >> or perhaps they are installed system wide. > >> Perhaps I am missing the official recommendation regarding the above, >> so that's why I am asking here. But if there is none, then I think the >> current state is unsatisfactory. > > you may be looking for CMAKE_PREFIX_PATH > (http://www.cmake.org/cmake/help/v3.2/variable/CMAKE_PREFIX_PATH.html) > > cmake -DCMAKE_PREFIX_PATH=$HOME/built-libs/gmp;$HOME/built-libs/arb;$HOME/built-libs/otherdependencies > (or have a script that sets CMAKE_PREFIX_PATH environment variable) > > works with find_module, find_file, find_library,... expects > directories to have standard structure (include,lib,...), see > documentation of find_* commands for details. > it is usually enough to set CMAKE_PREFIX_PATH to DESTDIRs used in > dependencies' "make install DESTDIR=/foo" > > you may want to remove NO_DEFAULT_PATH as used in linked > LibFindMacros.cmake, it disables this functionality. Yes, indeed CMAKE_PREFIX_PATH is a replacement for our COMMON_DIR, i.e. the case 3. above. So one can apply the following patch to our macros: --- a/cmake/LibFindMacros.cmake +++ b/cmake/LibFindMacros.cmake @@ -42,7 +42,6 @@ macro (libfind_library libname pkg) ${libname} PATHS ${${PKG}_DIR} - ${COMMON_DIR} PATH_SUFFIXES lib lib64 @@ -73,7 +72,6 @@ macro (libfind_include HEADER pkg) ${HEADER} PATHS ${${PKG}_DIR} - ${COMMON_DIR} PATH_SUFFIXES include NO_DEFAULT_PATH and just use CMAKE_PREFIX_PATH instead of COMMON_DIR. I tried it in our code and it works. However, for 1. and 2. there is no solution in CMake. There is CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH, but Isuru just tested it and CMAKE_PREFIX_PATH takes precedence over CMAKE_INCLUDE_PATH, which means that if you have a stack of packages installed in CMAKE_PREFIX_PATH, you cannot specify PKG1 using CMAKE_INCLUDE_PATH. And even if cmake changes the order, then if CMAKE_INCLUDE_PATH besides PKG1 also contains PKG2, but you want PKG2 from CMAKE_PREFIX_PATH, it won't work. The true solution is per package include/lib paths, just like we implemented in our macros. We tried many things, but we haven't figured out a solution other than our macros. So it looks like CMake itself should have our macros (or an equivalent functionality). Ondrej From rcdailey.lists at gmail.com Wed Jun 17 15:28:37 2015 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Wed, 17 Jun 2015 14:28:37 -0500 Subject: [CMake] Recursively include target include directories only Message-ID: Is there a way to only take (recursively) the include directories from a target or set of targets? I know that include directories propagate when passing targets to target_link_libraries(), but I do not want to link the libs; I only want the include directories. How can I do this? Thanks. From mjklaim at gmail.com Wed Jun 17 16:40:20 2015 From: mjklaim at gmail.com (=?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?=) Date: Wed, 17 Jun 2015 22:40:20 +0200 Subject: [CMake] How does :: actually works? In-Reply-To: References: <6642590.gJq68crCL0@ersa> <10549345.795GcQO5j7@ersa> Message-ID: On 17 June 2015 at 20:50, Stephen Kelly wrote: > Klaim - Jo?l Lamotte wrote: > > > I didn't realize at all that the FindPackage way is supposed to be > > obsolete now. > > It is not obsolete, but it is not a good approach (since CMake 2.6.0 > already) if the upstream uses cmake, because config file packages provide a > better experience for downstreams > > http://www.cmake.org/cmake/help/v3.2/manual/cmake-packages.7.html > > Even for upstreams that do not use cmake, it is preferable to generate > config file packages for a good downstream experience for cmake users. That > is what Qt qmake and LLVM Makefile buildsystems do. Boost b2 could do it > too: > > http://thread.gmane.org/gmane.comp.lib.boost.devel/259011/focus=259445 I remember the discussion but did not realize that it was a tool supposed to be useful for any project. Thinking about boost, if package files works well with header-only libraries (which I suppose it should as long as the boost define header-only targets) then it would be very useful indeed. By the way, in one of my project I end up using one FindBoost call with all the components needed by all the libraries of the project. I do this to avoid having to call FindBoost separately for every library with different components (still using the COMPONENTS option listing what the whole project needs). Then I have to have all my libraries to link with all the boost libraries listed in the boost library variable generated by FindBoost. If I understand correctly, if FindBoost was supporting imported targets and using "Boost" as a namespace (like Qt does), then I could link my libraries to boost libraries in a more precise way as I would link each library separately instead of everything FindBoost put in the boost libraries variable. Is my understanding correct? > > > > I'm quite surprised actually. > > We prefer not to accept new Find modules into the cmake tree because that > puts the maintenance burden on us, and because it is an inferior user > experience. Some new Find modules still get in, but they need to have a > reason to get in. > > > Ok I'll check PackageConfig.cmake for my new and even current projects > > if it can help with managing the tons of libraries I work on. > > Do please let us know how that goes. > I will. > > > I will consider providing patches, if I can spend time on this once and > > not bother > > later it would help a lot. > > Documentation here explains how to do that for Find modules: > > > http://www.cmake.org/cmake/help/v3.2/manual/cmake-developer.7.html#a-sample-find-module > > Thanks, > Thanks for the pointer. > > Steve. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steveire at gmail.com Wed Jun 17 16:58:37 2015 From: steveire at gmail.com (Stephen Kelly) Date: Wed, 17 Jun 2015 22:58:37 +0200 Subject: [CMake] How does :: actually works? References: <6642590.gJq68crCL0@ersa> <10549345.795GcQO5j7@ersa> Message-ID: Klaim - Jo?l Lamotte wrote: > Thinking about boost, if package files works well with header-only > libraries (which I > suppose it should as long as the boost define header-only targets) > then it would be very useful indeed. Yes, I wrote some cmake 3.0 features specifically for the Boost use cases (header only and lots of cyclic dependencies). > Then I have to have all my libraries to link with all the boost libraries > listed in the boost > library variable generated by FindBoost. I don't have working knowledge of FindBoost, so I can't give a good answer. The documentation at the top of the file says it creates a variable per library though. > If I understand correctly, if FindBoost was supporting imported targets > and using "Boost" as a > namespace (like Qt does), then I could link my libraries to boost > libraries in a more > precise way as I would link each library separately instead of everything > FindBoost > put in the boost libraries variable. This still has other advantages anyway, such as transitivity, conciseness, consistency, better error messages etc. Thanks, Steve. From dan at su-root.co.uk Wed Jun 17 17:31:26 2015 From: dan at su-root.co.uk (Dan Liew) Date: Wed, 17 Jun 2015 14:31:26 -0700 Subject: [CMake] Recursively include target include directories only In-Reply-To: References: Message-ID: On 17 June 2015 at 12:28, Robert Dailey wrote: > Is there a way to only take (recursively) the include directiories from > a target or set of targets? I know that include directories propagate > when passing targets to target_link_libraries(), but I do not want to > link the libs; I only want the include directories. > > How can I do this? Thanks. I presume recursively you mean propagating the required include directories between targets rather anything to do recursively handling directories. As you mentioned include directories do propagate but this only happens under certain conditions (when using PUBLIC or INTERFACE scopes). I don't know of a way of doing it without target_link_libraries but if it is necessary for you to do this it sounds like you have bigger problems relating to the way you have your project header files organised. The approach I use for include directories is to have all includes for the project rooted in a single include directory in the source tree and have all includes relative to that directory. Then if I you ``` include_directories(${CMAKE_SOURCE_DIR}/include) include_directories(${CMAKE_BINARY_DIR}/include) # for generated header files ``` in the root of the project you never need to set include paths anywhere else for sources that are in your project tree. E.g. if there is header file in ${CMAKE_SOURCE_DIR}/include/project/moduleA/interface.h then in the sources this is included as #include "project/moduleA/interface.h" (note there are never relative header file includes). This is the approach that the LLVM project uses which is very simple and very clean (take a look at the sources). This also works very well for installing your header files, the contents of ${CMAKE_SOURCE_DIR} just need to be copied into /usr/include . From oto.petrik at gmail.com Wed Jun 17 17:57:24 2015 From: oto.petrik at gmail.com (=?UTF-8?B?T3RvIFBldMWZw61r?=) Date: Wed, 17 Jun 2015 23:57:24 +0200 Subject: [CMake] What is the recommended ways to find libraries In-Reply-To: References: Message-ID: 2015-06-17 21:00 GMT+02:00 Ond?ej ?ert?k : > and just use CMAKE_PREFIX_PATH instead of COMMON_DIR. I tried it in > our code and it works. the idea is, that there is no need for PKG1_INCLUDE_DIRS, no PKG1_LIBRARIES and no PKG1_DIR just one path per dependency in CMAKE_PREFIX_PATH (or per group of dependencies in common directory) if dependency 'MyDependency' is installed in /opt/mydependency then after adding /opt/mydependency to CMAKE_PREFIX_PATH, following happens: find_library searches in: /opt/mydependency/lib /opt/mydependency and find_path,find_file searches in: /opt/mydependency/include /opt/mydependency (and if CMAKE_LIBRARY_ARCHITECTURE is set, then it is used as additional subdirectory under 'lib' and 'include') it looks like cmake documentation implies that only 'lib' and 'include' subdirectories are searched, and not the actual directory. at least cmake 3.2.1 on windows searches even the directory itself, looks like the behavior is not platform dependent: Source/cmSearchPath.cxx: method cmSearchPath::AddPrefixPaths lines 241-254 (http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmSearchPath.cxx;h=c9cc81737ac9ae65593ddea30f98233844274112;hb=HEAD#l241) when writing cmake/FindMyDependency.cmake, instead of libfind_* macros use plain find_* commands: find_library(MYDEPENDENCY_LIBRARY NAMES mydependency) find_path(MYDEPENDENCY_INCLUDE_DIR NAMES mydependency.h) if the header is in one of the following two locations, the work is done. /opt/mydependency/include/mydependency.h /opt/mydependency/mydependency.h two users installing/building same dependency end up with more or less the same directory structure, if you get path to that directory as part of CMAKE_PREFIX_PATH, you should be able to find headers/libraries. for unusual directory structure or platform/compiler differences use PATH_SUFFIXES. in exceptional cases find headers, then assemble path to libraries based on the header path - use it as a HINTS to find_library (probably called with NO_DEFAULT_PATH) > However, for 1. and 2. there is no solution in CMake. There is > CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH, but Isuru just tested it > and CMAKE_PREFIX_PATH takes precedence over CMAKE_INCLUDE_PATH, which > means that if you have a stack of packages installed in > CMAKE_PREFIX_PATH, you cannot specify PKG1 using CMAKE_INCLUDE_PATH. > And even if cmake changes the order, then if CMAKE_INCLUDE_PATH > besides PKG1 also contains PKG2, but you want PKG2 from > CMAKE_PREFIX_PATH, it won't work. The true solution is per package > include/lib paths, just like we implemented in our macros. when using only CMAKE_PREFIX_PATH, it should be possible to solve this by reordering paths within CMAKE_PREFIX_PATH (PKG1 first, stack of packages last). it should work for cases of new version of PKG1 in separate directory "overriding" (old) PKG1 in another directory containing e.g. oldPKG1, PKG2, ... it will break for two directories e.g. 'stable' and 'testing', each with both PKG1 and PKG2 - you cannot get stable PKG1 and testing PKG2, but in that case it is a problem to even construct the list of include directories for the compiler. > We tried many things, but we haven't figured out a solution other than > our macros. So it looks like CMake itself should have our macros (or > an equivalent functionality). is there a case where "dependencies are in following directories, search them in order" behavior of CMAKE_PREFIX_PATH is not enough ? Oto From rcdailey.lists at gmail.com Wed Jun 17 19:43:06 2015 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Wed, 17 Jun 2015 18:43:06 -0500 Subject: [CMake] Recursively include target include directories only In-Reply-To: References: Message-ID: On Wed, Jun 17, 2015 at 4:31 PM, Dan Liew wrote: > On 17 June 2015 at 12:28, Robert Dailey wrote: >> Is there a way to only take (recursively) the include directiories from >> a target or set of targets? I know that include directories propagate >> when passing targets to target_link_libraries(), but I do not want to >> link the libs; I only want the include directories. >> >> How can I do this? Thanks. > > I presume recursively you mean propagating the required include > directories between targets rather anything to do recursively handling > directories. > > As you mentioned include directories do propagate but this only > happens under certain conditions (when using PUBLIC or INTERFACE > scopes). > > I don't know of a way of doing it without target_link_libraries but if > it is necessary for you to do this it sounds like you have bigger > problems relating to the way you have your project header files > organised. > > The approach I use for include directories is to have all includes for > the project rooted in a single include directory in the source tree > and have all includes relative to that directory. Then if I you > > ``` > include_directories(${CMAKE_SOURCE_DIR}/include) > include_directories(${CMAKE_BINARY_DIR}/include) # for generated header files > ``` > > in the root of the project you never need to set include paths > anywhere else for sources that are in your project tree. E.g. if there > is header file in > > ${CMAKE_SOURCE_DIR}/include/project/moduleA/interface.h > > then in the sources this is included as > > #include "project/moduleA/interface.h" > > (note there are never relative header file includes). > > This is the approach that the LLVM project uses which is very simple > and very clean (take a look at the sources). This also works very well > for installing your header files, the contents of ${CMAKE_SOURCE_DIR} > just need to be copied into /usr/include . Thanks, I will go through this and see if it helps. The reason I'm asking this question is because of how I handle unit tests in CMake right now. Instead of just defining an executable target for the test and then adding a link dependency on the library containing the class or set of classes to be tested, I am manually pulling in the CPP and H file into the test target and building them inline with the test code. This is to support mocking (I can't mock objects already compiled into a static library). As such, I need the transitive includes and defines, but I do not want the transitive link libraries. If there is a better structure or overall approach I'm happy to listen! This has been a nightmare so far. From petr.kmoch at gmail.com Thu Jun 18 02:27:42 2015 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Thu, 18 Jun 2015 08:27:42 +0200 Subject: [CMake] Recursively include target include directories only In-Reply-To: References: Message-ID: On Thu, Jun 18, 2015 at 1:43 AM, Robert Dailey wrote: > On Wed, Jun 17, 2015 at 4:31 PM, Dan Liew wrote: > > On 17 June 2015 at 12:28, Robert Dailey > wrote: > >> Is there a way to only take (recursively) the include directiories from > >> a target or set of targets? I know that include directories propagate > >> when passing targets to target_link_libraries(), but I do not want to > >> link the libs; I only want the include directories. > >> > >> How can I do this? Thanks. > I haven't tested this, but it should be possible to drag in the interface properties explicitly with generator expressions. Something like this: add_executable(Depender ...) target_include_directories(Depender PRIVATE $ $ ) dtto for other INTERFACE_... properties you might need. Petr > > > > I presume recursively you mean propagating the required include > > directories between targets rather anything to do recursively handling > > directories. > > > > As you mentioned include directories do propagate but this only > > happens under certain conditions (when using PUBLIC or INTERFACE > > scopes). > > > > I don't know of a way of doing it without target_link_libraries but if > > it is necessary for you to do this it sounds like you have bigger > > problems relating to the way you have your project header files > > organised. > > > > The approach I use for include directories is to have all includes for > > the project rooted in a single include directory in the source tree > > and have all includes relative to that directory. Then if I you > > > > ``` > > include_directories(${CMAKE_SOURCE_DIR}/include) > > include_directories(${CMAKE_BINARY_DIR}/include) # for generated header > files > > ``` > > > > in the root of the project you never need to set include paths > > anywhere else for sources that are in your project tree. E.g. if there > > is header file in > > > > ${CMAKE_SOURCE_DIR}/include/project/moduleA/interface.h > > > > then in the sources this is included as > > > > #include "project/moduleA/interface.h" > > > > (note there are never relative header file includes). > > > > This is the approach that the LLVM project uses which is very simple > > and very clean (take a look at the sources). This also works very well > > for installing your header files, the contents of ${CMAKE_SOURCE_DIR} > > just need to be copied into /usr/include . > > Thanks, I will go through this and see if it helps. > > The reason I'm asking this question is because of how I handle unit > tests in CMake right now. Instead of just defining an executable > target for the test and then adding a link dependency on the library > containing the class or set of classes to be tested, I am manually > pulling in the CPP and H file into the test target and building them > inline with the test code. This is to support mocking (I can't mock > objects already compiled into a static library). As such, I need the > transitive includes and defines, but I do not want the transitive link > libraries. > > If there is a better structure or overall approach I'm happy to > listen! This has been a nightmare so far. > -- > > 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 18 02:50:00 2015 From: dan at su-root.co.uk (Dan Liew) Date: Wed, 17 Jun 2015 23:50:00 -0700 Subject: [CMake] Recursively include target include directories only In-Reply-To: References: Message-ID: > This is the approach that the LLVM project uses which is very simple > and very clean (take a look at the sources). This also works very well > for installing your header files, the contents of ${CMAKE_SOURCE_DIR} > just need to be copied into /usr/include . Oops I meant to say the contents of ${CMAKE_SOURCE_DIR}/include and ${CMAKE_BINARY_DIR}/include can be copied into /usr/include. From dan at su-root.co.uk Thu Jun 18 02:57:49 2015 From: dan at su-root.co.uk (Dan Liew) Date: Wed, 17 Jun 2015 23:57:49 -0700 Subject: [CMake] Recursively include target include directories only In-Reply-To: References: Message-ID: > The reason I'm asking this question is because of how I handle unit > tests in CMake right now. Instead of just defining an executable > target for the test and then adding a link dependency on the library > containing the class or set of classes to be tested, I am manually > pulling in the CPP and H file into the test target and building them > inline with the test code. This is to support mocking (I can't mock > objects already compiled into a static library). As such, I need the > transitive includes and defines, but I do not want the transitive link > libraries. Okay with that context what I suggested isn't going to completely solve the problem. It is actually possible to link with your static library and a mock implementation by making the symbols that you want mock in the library weak. Then when you link the linker will choose the strong (the mock) implementation in preference to the weak implementation. It probably isn't desirable to have weak symbols in a shipping library just to make unit testing easier so you could build two versions of the library (one with weak symbols and one without). This would allow to use target_link_libraries() but not get link conflicts between your mock implementation and the real implementation. However Petr's suggestion also sounds good (although I haven't tested it). From jcook at cray.com Thu Jun 18 03:34:55 2015 From: jcook at cray.com (Justin Cook) Date: Thu, 18 Jun 2015 07:34:55 +0000 Subject: [CMake] alternative method for setting CMAKE_TOOLCHAIN_FILE? Message-ID: Hello, Is there an alternative method for setting the CMAKE_TOOLCHAIN_FILE variable other than, for example: cmake -D CMAKE_TOOLCHAIN_FILE=... Perhaps an environment variable or something similar? Thanks, Justin From domen.vrankar at gmail.com Thu Jun 18 04:25:14 2015 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Thu, 18 Jun 2015 10:25:14 +0200 Subject: [CMake] alternative method for setting CMAKE_TOOLCHAIN_FILE? In-Reply-To: References: Message-ID: > Is there an alternative method for setting the CMAKE_TOOLCHAIN_FILE variable other than, for example: > > cmake -D CMAKE_TOOLCHAIN_FILE=... > > Perhaps an environment variable or something similar? You always have the option to set an environment variable and then read it at the top of your root CMake list (not tested): if($ENV{environment_variable_name}) set(CMAKE_TOOLCHAIN_FILE $ENV{environment_variable_name} CACHE String "some description" FORCE) endif() But I'm not certain why you'd want to do that as IMHO environment variables only make things messier and less transparent. Regards, Domen From brad.king at kitware.com Thu Jun 18 08:44:33 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 18 Jun 2015 08:44:33 -0400 Subject: [CMake] fortran compiler failed to compile simple test program In-Reply-To: <2A375B5C08C24643A8A3F8CC2B98C1084BAD8AA3@USINDPR-MBX003.Rolls-Royce.Local> References: <2A375B5C08C24643A8A3F8CC2B98C1084BAD8011@USINDPR-MBX003.Rolls-Royce.Local> <557F045F.30804@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD809E@USINDPR-MBX003.Rolls-Royce.Local> <557F13CA.50903@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD80FC@USINDPR-MBX003.Rolls-Royce.Local> <557F2532.5000403@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD8142@USINDPR-MBX003.Rolls-Royce.Local> <557F2F6D.6040804@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD82C0@USINDPR-MBX003.Rolls-Royce.Local> <55801A96.7080600@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD83FB@USINDPR-MBX003.Rolls-Royce.Local> <558029DF.9090403@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD84B8@USINDPR-MBX003.Rolls-Royce.Local> <55802DC2.4040205@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD86E8@USINDPR-MBX003.Rolls-Royce.Local> <55806223.5080305@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD8AA3@USINDPR-MBX003.Rolls-Royce.Local> Message-ID: <5582BD31.5080002@kitware.com> On 06/17/2015 11:07 AM, Ette, Anthony (CDS) wrote: > Please see the response below about uniquely identifying cf77. > > In order to identify the compiler as cf77, do something akin to the following: > $ echo ' PROGRAM V' > /tmp/nil.f > $ echo ' END' >> /tmp/nil.f > $ cf77 -v -o /dev/null -c /tmp/nil.f 2>&1 | fgrep "Concurrent Fortran" 2>&1 | fgrep Concurrent > Concurrent Fortran 77 Compiler - Version 7.3 Wed Jun 17 06:52:27 2015 We may be able to extract that while compiling the compiler identification source file. Try modifying Modules/CMakeDetermineFortranCompiler.cmake and extending the list in CMAKE_Fortran_COMPILER_ID_TEST_FLAGS with "-v". Then run CMake on the tiny CMakeLists.txt file we used for testing before. Then send me (off list) a tarball of the build tree. > In terms of identifying the major and minor versions, the information > isn't as readily available as one would like. Please encourage them to add identification and version macros to their preprocessor invocations. Nearly all compilers do this. It is how program sources are supposed to be able to adapt to idiosyncrasies of specific compilers. Thanks, -Brad From mike.jackson at bluequartz.net Thu Jun 18 08:51:40 2015 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Thu, 18 Jun 2015 08:51:40 -0400 Subject: [CMake] Running CTest with Xcode build results in Error Message-ID: <910D7217-A955-4487-94DD-2880A55224BB@bluequartz.net> We have a nightly build for our project as reported here http://my.cdash.org/viewBuildError.php?buildid=781789 which is producing an error. The short of it is that CTest is using xcodebuild (which is correct) but is trying to pass the ?-j16? style that normal ?MakeFiles? would use. I have looked through our CTest scripts (Which were adapted from VTK?s nightly builds) but I am not seeing anything about that flag being explicitly called out. Could anyone with nightly build experience help us out? Thanks Mike Jackson BlueQuartz Software From DLRdave at aol.com Thu Jun 18 09:56:49 2015 From: DLRdave at aol.com (David Cole) Date: Thu, 18 Jun 2015 09:56:49 -0400 Subject: [CMake] Running CTest with Xcode build results in Error In-Reply-To: <910D7217-A955-4487-94DD-2880A55224BB@bluequartz.net> References: <910D7217-A955-4487-94DD-2880A55224BB@bluequartz.net> Message-ID: Is there a MAKEFLAGS or CTEST_BUILD_FLAGS in your environment? Where does the -j16 come from? (CTest should not be injecting that unless you are telling it to somehow, so it either comes from one of your scripts, or your environment...) grep for just "\-j" -- the value 16 may come from a variable evaluation. HTH, David C. On Thu, Jun 18, 2015 at 8:51 AM, Michael Jackson wrote: > We have a nightly build for our project as reported here http://my.cdash.org/viewBuildError.php?buildid=781789 which is producing an error. The short of it is that CTest is using xcodebuild (which is correct) but is trying to pass the ?-j16? style that normal ?MakeFiles? would use. I have looked through our CTest scripts (Which were adapted from VTK?s nightly builds) but I am not seeing anything about that flag being explicitly called out. > > Could anyone with nightly build experience help us out? > > Thanks > Mike Jackson > BlueQuartz Software > -- > > 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 rcdailey.lists at gmail.com Thu Jun 18 11:50:40 2015 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Thu, 18 Jun 2015 10:50:40 -0500 Subject: [CMake] Recursively include target include directories only In-Reply-To: References: Message-ID: On Thu, Jun 18, 2015 at 1:57 AM, Dan Liew wrote: >> The reason I'm asking this question is because of how I handle unit >> tests in CMake right now. Instead of just defining an executable >> target for the test and then adding a link dependency on the library >> containing the class or set of classes to be tested, I am manually >> pulling in the CPP and H file into the test target and building them >> inline with the test code. This is to support mocking (I can't mock >> objects already compiled into a static library). As such, I need the >> transitive includes and defines, but I do not want the transitive link >> libraries. > > Okay with that context what I suggested isn't going to completely > solve the problem. > > It is actually possible to link with your static library and a mock > implementation by making the symbols that you want mock in the library > weak. Then when you link the linker will choose the strong (the mock) > implementation in preference to the weak implementation. It probably > isn't desirable to have weak symbols in a shipping library just to > make unit testing easier so you could build two versions of the > library (one with weak symbols and one without). > This would allow to use target_link_libraries() but not get link > conflicts between your mock implementation and the real > implementation. > > However Petr's suggestion also sounds good (although I haven't tested it). Can you explain what you mean by "strong" and "weak" symbols? From mike.jackson at bluequartz.net Thu Jun 18 12:23:59 2015 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Thu, 18 Jun 2015 12:23:59 -0400 Subject: [CMake] Running CTest with Xcode build results in Error In-Reply-To: References: <910D7217-A955-4487-94DD-2880A55224BB@bluequartz.net> Message-ID: <1DDCD453-3A9A-492F-B6DA-26A6BFA71D4C@bluequartz.net> Nope. Neither one of those are on my environment. I am also running at Root for this build and I have a clean .bashrc for both accounts. There must be something in my chest.cmake file that makes CTest think it is running with a makefile generator. Should I post my various files? Mike Jackson > On Jun 18, 2015, at 9:56 AM, David Cole wrote: > > Is there a MAKEFLAGS or CTEST_BUILD_FLAGS in your environment? > > Where does the -j16 come from? (CTest should not be injecting that > unless you are telling it to somehow, so it either comes from one of > your scripts, or your environment...) > > grep for just "\-j" -- the value 16 may come from a variable evaluation. > > > HTH, > David C. > > > On Thu, Jun 18, 2015 at 8:51 AM, Michael Jackson > wrote: >> We have a nightly build for our project as reported here http://my.cdash.org/viewBuildError.php?buildid=781789 which is producing an error. The short of it is that CTest is using xcodebuild (which is correct) but is trying to pass the ?-j16? style that normal ?MakeFiles? would use. I have looked through our CTest scripts (Which were adapted from VTK?s nightly builds) but I am not seeing anything about that flag being explicitly called out. >> >> Could anyone with nightly build experience help us out? >> >> Thanks >> Mike Jackson >> BlueQuartz Software >> -- >> >> 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 brad.king at kitware.com Thu Jun 18 12:51:44 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 18 Jun 2015 12:51:44 -0400 Subject: [CMake] Support for Concurrent Fortran 77 Compiler (was: fortran compiler failed to compile simple test program) In-Reply-To: <5582BD31.5080002@kitware.com> References: <2A375B5C08C24643A8A3F8CC2B98C1084BAD8011@USINDPR-MBX003.Rolls-Royce.Local> <557F045F.30804@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD809E@USINDPR-MBX003.Rolls-Royce.Local> <557F13CA.50903@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD80FC@USINDPR-MBX003.Rolls-Royce.Local> <557F2532.5000403@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD8142@USINDPR-MBX003.Rolls-Royce.Local> <557F2F6D.6040804@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD82C0@USINDPR-MBX003.Rolls-Royce.Local> <55801A96.7080600@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD83FB@USINDPR-MBX003.Rolls-Royce.Local> <558029DF.9090403@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD84B8@USINDPR-MBX003.Rolls-Royce.Local> <55802DC2.4040205@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD86E8@USINDPR-MBX003.Rolls-Royce.Local> <55806223.5080305@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD8AA3@USINDPR-MBX003.Rolls-Royce.Local> <5582BD31.5080002@kitware.com> Message-ID: <5582F720.50701@kitware.com> On 06/18/2015 08:44 AM, Brad King wrote: > We may be able to extract that while compiling the compiler identification > source file. Try modifying Modules/CMakeDetermineFortranCompiler.cmake > and extending the list in CMAKE_Fortran_COMPILER_ID_TEST_FLAGS with "-v". > Then run CMake on the tiny CMakeLists.txt file we used for testing before. > Then send me (off list) a tarball of the build tree. Okay, I've drafted some changes to use the compilation output to identify a compiler: CMakeDetermineCompilerId: Optionally try some flags before no flags http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c65a060e CMakeDetermineCompilerId: Refactor id build/check loop logic http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5f0dad75 CMakeDetermineCompilerId: Try matching compiler output to detect id http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0d204c1c and another change to actually use it for this compiler: Add support for Concurrent Fortran 77 Compiler http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7cd539b1 Please try building CMake from commit 7cd539b1 to see if it detects the compiler id as "CCur". Once that works we can look at updating the flags used for the compiler. Thanks, -Brad From dan at su-root.co.uk Thu Jun 18 13:02:14 2015 From: dan at su-root.co.uk (Dan Liew) Date: Thu, 18 Jun 2015 10:02:14 -0700 Subject: [CMake] Recursively include target include directories only In-Reply-To: References: Message-ID: > Can you explain what you mean by "strong" and "weak" symbols? Google is your friend https://en.wikipedia.org/wiki/Weak_symbol http://stackoverflow.com/questions/2290587/gcc-style-weak-linking-in-visual-studio From piroxiljin at gmail.com Thu Jun 18 14:19:31 2015 From: piroxiljin at gmail.com (Alex Iljin) Date: Fri, 19 Jun 2015 01:19:31 +0700 Subject: [CMake] Unable to set configuration name with a hyphen char Message-ID: Hi. I try to set a custom configurations like "Debug-Demo" and "Release-Demo". I had used a snippet from wiki: http://www.cmake.org/Wiki/CMake_FAQ#How_can_I_specify_my_own_configurations_.28for_generators_that_allow_it.29_.3F with additional modifying DEBUG_CONFIGURATIONS, because the "Debug-Demo" configuration should be linked with debug version of libraries. if(CMAKE_CONFIGURATION_TYPES) set(CMAKE_CONFIGURATION_TYPES Debug Release Debug-Demo Release-Demo) set(CMAKE_CONFIGURATION_TYPES "${CMAKE_CONFIGURATION_TYPES}" CACHE STRING "Reset the configurations to what we need" FORCE) set_property(GLOBAL PROPERTY DEBUG_CONFIGURATIONS "Debug;Debug-Demo") endif() But what I got is bunch of errors at generation time. CMake Error: Error evaluating generator expression: $ If I delete the "set_property" line, I get Debug-Demo configuration which is kind of optimized configuration (as default). So, does I have missed some notes about using a hyphen chars in configuration names, or is it a bug in the cmake? Alexander Iljin -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Thu Jun 18 15:08:31 2015 From: DLRdave at aol.com (David Cole) Date: Thu, 18 Jun 2015 15:08:31 -0400 Subject: [CMake] Running CTest with Xcode build results in Error In-Reply-To: <1DDCD453-3A9A-492F-B6DA-26A6BFA71D4C@bluequartz.net> References: <910D7217-A955-4487-94DD-2880A55224BB@bluequartz.net> <1DDCD453-3A9A-492F-B6DA-26A6BFA71D4C@bluequartz.net> Message-ID: Are you using Eclipse or Kate? Did you do a grep -E "\-j" on all of the files included by the script that drives the build? (And in your source tree?) The only -j possibilities that look likely in CMake itself are shown in the git grep results from a CMake checkout: $ git grep -E "\-j" Modules/CMakeFindEclipseCDT4.cmake:# Try to find out how many CPUs we have and set the -j Modules/CMakeFindEclipseCDT4.cmake:# Only set -j if we are under UNIX and if the make-tool Modules/CMakeFindEclipseCDT4.cmake: set(_CMAKE_ECLIPSE_INITIAL_MAKE_ARGS "-j${_CMAKE_ECLI Modules/CMakeFindEclipseCDT4.cmake:set(CMAKE_ECLIPSE_MAKE_ARGUMENTS "${_CMAKE_ECLIPSE_INIT Modules/CMakeFindKate.cmake:# Try to find out how many CPUs we have and set the -j argumen Modules/CMakeFindKate.cmake:# Only set -j if we are under UNIX and if the make-tool used a Modules/CMakeFindKate.cmake: set(_CMAKE_KATE_INITIAL_MAKE_ARGS "-j${_CMAKE_KATE_PROCESSOR Modules/CMakeFindKate.cmake:set(CMAKE_KATE_MAKE_ARGUMENTS "${_CMAKE_KATE_INITIAL_MAKE_ARGS And it looks like those try to restrict it to a "make" tool, so they shouldn't be using it in the case of xcodebuild... Mystery. We're missing something. On Thu, Jun 18, 2015 at 12:23 PM, Michael Jackson wrote: > Nope. Neither one of those are on my environment. I am also running at Root for this build and I have a clean .bashrc for both accounts. There must be something in my chest.cmake file that makes CTest think it is running with a makefile generator. > > Should I post my various files? > > Mike Jackson > >> On Jun 18, 2015, at 9:56 AM, David Cole wrote: >> >> Is there a MAKEFLAGS or CTEST_BUILD_FLAGS in your environment? >> >> Where does the -j16 come from? (CTest should not be injecting that >> unless you are telling it to somehow, so it either comes from one of >> your scripts, or your environment...) >> >> grep for just "\-j" -- the value 16 may come from a variable evaluation. >> >> >> HTH, >> David C. >> >> >> On Thu, Jun 18, 2015 at 8:51 AM, Michael Jackson >> wrote: >>> We have a nightly build for our project as reported here http://my.cdash.org/viewBuildError.php?buildid=781789 which is producing an error. The short of it is that CTest is using xcodebuild (which is correct) but is trying to pass the ?-j16? style that normal ?MakeFiles? would use. I have looked through our CTest scripts (Which were adapted from VTK?s nightly builds) but I am not seeing anything about that flag being explicitly called out. >>> >>> Could anyone with nightly build experience help us out? >>> >>> Thanks >>> Mike Jackson >>> BlueQuartz Software >>> -- >>> >>> 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 rcdailey.lists at gmail.com Thu Jun 18 15:16:31 2015 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Thu, 18 Jun 2015 14:16:31 -0500 Subject: [CMake] Recursively include target include directories only In-Reply-To: References: Message-ID: On Thu, Jun 18, 2015 at 12:02 PM, Dan Liew wrote: >> Can you explain what you mean by "strong" and "weak" symbols? > > > Google is your friend > > https://en.wikipedia.org/wiki/Weak_symbol > > http://stackoverflow.com/questions/2290587/gcc-style-weak-linking-in-visual-studio Normally Google is my friend, but today it hates me. Because no such feature exists for MSVC that I saw. From mike.jackson at bluequartz.net Thu Jun 18 15:17:22 2015 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Thu, 18 Jun 2015 15:17:22 -0400 Subject: [CMake] Running CTest with Xcode build results in Error In-Reply-To: References: <910D7217-A955-4487-94DD-2880A55224BB@bluequartz.net> <1DDCD453-3A9A-492F-B6DA-26A6BFA71D4C@bluequartz.net> Message-ID: <9AD1449F-D3FC-464B-A094-21FD48FE0F12@bluequartz.net> I will have to admit that I don't pretend to completely understand the CMake file that I am using as I started with something from VTK and changed things to work with our project and setup. I will attach the files to the email. Maybe you can see something that I am missing: -------------- next part -------------- A non-text attachment was scrubbed... Name: BuildDREAM3D.sh Type: application/octet-stream Size: 3418 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Xcode-DREAM3D_Dashboard.cmake Type: application/octet-stream Size: 16132 bytes Desc: not available URL: -------------- next part -------------- Thanks Mike Jackson On Jun 18, 2015, at 3:08 PM, David Cole via CMake wrote: > Are you using Eclipse or Kate? > > Did you do a grep -E "\-j" on all of the files included by the script > that drives the build? (And in your source tree?) > > The only -j possibilities that look likely in CMake itself are shown > in the git grep results from a CMake checkout: > > $ git grep -E "\-j" > > Modules/CMakeFindEclipseCDT4.cmake:# Try to find out how many CPUs we > have and set the -j > Modules/CMakeFindEclipseCDT4.cmake:# Only set -j if we are under UNIX > and if the make-tool > Modules/CMakeFindEclipseCDT4.cmake: > set(_CMAKE_ECLIPSE_INITIAL_MAKE_ARGS "-j${_CMAKE_ECLI > Modules/CMakeFindEclipseCDT4.cmake:set(CMAKE_ECLIPSE_MAKE_ARGUMENTS > "${_CMAKE_ECLIPSE_INIT > Modules/CMakeFindKate.cmake:# Try to find out how many CPUs we have > and set the -j argumen > Modules/CMakeFindKate.cmake:# Only set -j if we are under UNIX and if > the make-tool used a > Modules/CMakeFindKate.cmake: set(_CMAKE_KATE_INITIAL_MAKE_ARGS > "-j${_CMAKE_KATE_PROCESSOR > Modules/CMakeFindKate.cmake:set(CMAKE_KATE_MAKE_ARGUMENTS > "${_CMAKE_KATE_INITIAL_MAKE_ARGS > > And it looks like those try to restrict it to a "make" tool, so they > shouldn't be using it in the case of xcodebuild... > > Mystery. We're missing something. > > > > On Thu, Jun 18, 2015 at 12:23 PM, Michael Jackson > wrote: >> Nope. Neither one of those are on my environment. I am also running at Root for this build and I have a clean .bashrc for both accounts. There must be something in my chest.cmake file that makes CTest think it is running with a makefile generator. >> >> Should I post my various files? >> >> Mike Jackson >> >>> On Jun 18, 2015, at 9:56 AM, David Cole wrote: >>> >>> Is there a MAKEFLAGS or CTEST_BUILD_FLAGS in your environment? >>> >>> Where does the -j16 come from? (CTest should not be injecting that >>> unless you are telling it to somehow, so it either comes from one of >>> your scripts, or your environment...) >>> >>> grep for just "\-j" -- the value 16 may come from a variable evaluation. >>> >>> >>> HTH, >>> David C. >>> >>> >>> On Thu, Jun 18, 2015 at 8:51 AM, Michael Jackson >>> wrote: >>>> We have a nightly build for our project as reported here http://my.cdash.org/viewBuildError.php?buildid=781789 which is producing an error. The short of it is that CTest is using xcodebuild (which is correct) but is trying to pass the ?-j16? style that normal ?MakeFiles? would use. I have looked through our CTest scripts (Which were adapted from VTK?s nightly builds) but I am not seeing anything about that flag being explicitly called out. >>>> >>>> Could anyone with nightly build experience help us out? >>>> >>>> Thanks >>>> Mike Jackson >>>> BlueQuartz Software >>>> -- >>>> >>>> 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 DLRdave at aol.com Thu Jun 18 15:29:03 2015 From: DLRdave at aol.com (David Cole) Date: Thu, 18 Jun 2015 15:29:03 -0400 Subject: [CMake] Recursively include target include directories only In-Reply-To: References: Message-ID: Did you read through the pointed to stack overflow question and answers....? Is the information there misleading or incorrect?, ... because it seems to say there is a way to do it with MSVC... On Thu, Jun 18, 2015 at 3:16 PM, Robert Dailey wrote: > On Thu, Jun 18, 2015 at 12:02 PM, Dan Liew wrote: >>> Can you explain what you mean by "strong" and "weak" symbols? >> >> >> Google is your friend >> >> https://en.wikipedia.org/wiki/Weak_symbol >> >> http://stackoverflow.com/questions/2290587/gcc-style-weak-linking-in-visual-studio > > Normally Google is my friend, but today it hates me. Because no such > feature exists for MSVC that I saw. > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From DLRdave at aol.com Thu Jun 18 15:40:40 2015 From: DLRdave at aol.com (David Cole) Date: Thu, 18 Jun 2015 15:40:40 -0400 Subject: [CMake] Running CTest with Xcode build results in Error In-Reply-To: <9AD1449F-D3FC-464B-A094-21FD48FE0F12@bluequartz.net> References: <910D7217-A955-4487-94DD-2880A55224BB@bluequartz.net> <1DDCD453-3A9A-492F-B6DA-26A6BFA71D4C@bluequartz.net> <9AD1449F-D3FC-464B-A094-21FD48FE0F12@bluequartz.net> Message-ID: The error shown in your CDash build error output page could be coming from something that is built within your project as an ExternalProject. Do you have any of those? Have you grepped your source tree for -j yet? On Thu, Jun 18, 2015 at 3:17 PM, Michael Jackson wrote: > I will have to admit that I don't pretend to completely understand the CMake file that I am using as I started with something from VTK and changed things to work with our project and setup. I will attach the files to the email. Maybe you can see something that I am missing: > > > > > > Thanks > Mike Jackson > > On Jun 18, 2015, at 3:08 PM, David Cole via CMake wrote: > >> Are you using Eclipse or Kate? >> >> Did you do a grep -E "\-j" on all of the files included by the script >> that drives the build? (And in your source tree?) >> >> The only -j possibilities that look likely in CMake itself are shown >> in the git grep results from a CMake checkout: >> >> $ git grep -E "\-j" >> >> Modules/CMakeFindEclipseCDT4.cmake:# Try to find out how many CPUs we >> have and set the -j >> Modules/CMakeFindEclipseCDT4.cmake:# Only set -j if we are under UNIX >> and if the make-tool >> Modules/CMakeFindEclipseCDT4.cmake: >> set(_CMAKE_ECLIPSE_INITIAL_MAKE_ARGS "-j${_CMAKE_ECLI >> Modules/CMakeFindEclipseCDT4.cmake:set(CMAKE_ECLIPSE_MAKE_ARGUMENTS >> "${_CMAKE_ECLIPSE_INIT >> Modules/CMakeFindKate.cmake:# Try to find out how many CPUs we have >> and set the -j argumen >> Modules/CMakeFindKate.cmake:# Only set -j if we are under UNIX and if >> the make-tool used a >> Modules/CMakeFindKate.cmake: set(_CMAKE_KATE_INITIAL_MAKE_ARGS >> "-j${_CMAKE_KATE_PROCESSOR >> Modules/CMakeFindKate.cmake:set(CMAKE_KATE_MAKE_ARGUMENTS >> "${_CMAKE_KATE_INITIAL_MAKE_ARGS >> >> And it looks like those try to restrict it to a "make" tool, so they >> shouldn't be using it in the case of xcodebuild... >> >> Mystery. We're missing something. >> >> >> >> On Thu, Jun 18, 2015 at 12:23 PM, Michael Jackson >> wrote: >>> Nope. Neither one of those are on my environment. I am also running at Root for this build and I have a clean .bashrc for both accounts. There must be something in my chest.cmake file that makes CTest think it is running with a makefile generator. >>> >>> Should I post my various files? >>> >>> Mike Jackson >>> >>>> On Jun 18, 2015, at 9:56 AM, David Cole wrote: >>>> >>>> Is there a MAKEFLAGS or CTEST_BUILD_FLAGS in your environment? >>>> >>>> Where does the -j16 come from? (CTest should not be injecting that >>>> unless you are telling it to somehow, so it either comes from one of >>>> your scripts, or your environment...) >>>> >>>> grep for just "\-j" -- the value 16 may come from a variable evaluation. >>>> >>>> >>>> HTH, >>>> David C. >>>> >>>> >>>> On Thu, Jun 18, 2015 at 8:51 AM, Michael Jackson >>>> wrote: >>>>> We have a nightly build for our project as reported here http://my.cdash.org/viewBuildError.php?buildid=781789 which is producing an error. The short of it is that CTest is using xcodebuild (which is correct) but is trying to pass the ?-j16? style that normal ?MakeFiles? would use. I have looked through our CTest scripts (Which were adapted from VTK?s nightly builds) but I am not seeing anything about that flag being explicitly called out. >>>>> >>>>> Could anyone with nightly build experience help us out? >>>>> >>>>> Thanks >>>>> Mike Jackson >>>>> BlueQuartz Software >>>>> -- >>>>> >>>>> 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 mike.jackson at bluequartz.net Thu Jun 18 15:45:36 2015 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Thu, 18 Jun 2015 15:45:36 -0400 Subject: [CMake] Running CTest with Xcode build results in Error In-Reply-To: References: <910D7217-A955-4487-94DD-2880A55224BB@bluequartz.net> <1DDCD453-3A9A-492F-B6DA-26A6BFA71D4C@bluequartz.net> <9AD1449F-D3FC-464B-A094-21FD48FE0F12@bluequartz.net> Message-ID: <2500203E-3BC7-4257-83E7-B11B3CD7E2F9@bluequartz.net> Found the source. the generated CTestConfig.cmake is the following: ## This file should be placed in the root directory of your project. ## Then modify the CMakeLists.txt file in the root directory of your ## project to incorporate the testing dashboard. ## # The following are required to uses Dart and the Cdash dashboard ## ENABLE_TESTING() ## INCLUDE(CTest) set(CTEST_PROJECT_NAME "DREAM3D") set(CTEST_NIGHTLY_START_TIME "01:00:00 UTC") set(CTEST_DROP_METHOD "http") set(CTEST_DROP_SITE "my.cdash.org") set(CTEST_DROP_LOCATION "/submit.php?project=DREAM3D") set(CTEST_DROP_SITE_CDASH TRUE) # Use multiple CPU cores to build include(ProcessorCount) ProcessorCount(N) if(NOT N EQUAL 0) if(NOT WIN32) set(CTEST_BUILD_FLAGS "-j${N}") endif(NOT WIN32) set(ctest_test_args ${ctest_test_args} PARALLEL_LEVEL ${N}) endif() So that explains where it is coming from. Does CMake generate this or does my project generate this? Mike J On Jun 18, 2015, at 3:40 PM, David Cole wrote: > The error shown in your CDash build error output page could be coming > from something that is built within your project as an > ExternalProject. > > Do you have any of those? > > Have you grepped your source tree for -j yet? > > > On Thu, Jun 18, 2015 at 3:17 PM, Michael Jackson > wrote: >> I will have to admit that I don't pretend to completely understand the CMake file that I am using as I started with something from VTK and changed things to work with our project and setup. I will attach the files to the email. Maybe you can see something that I am missing: >> >> >> >> >> >> Thanks >> Mike Jackson >> >> On Jun 18, 2015, at 3:08 PM, David Cole via CMake wrote: >> >>> Are you using Eclipse or Kate? >>> >>> Did you do a grep -E "\-j" on all of the files included by the script >>> that drives the build? (And in your source tree?) >>> >>> The only -j possibilities that look likely in CMake itself are shown >>> in the git grep results from a CMake checkout: >>> >>> $ git grep -E "\-j" >>> >>> Modules/CMakeFindEclipseCDT4.cmake:# Try to find out how many CPUs we >>> have and set the -j >>> Modules/CMakeFindEclipseCDT4.cmake:# Only set -j if we are under UNIX >>> and if the make-tool >>> Modules/CMakeFindEclipseCDT4.cmake: >>> set(_CMAKE_ECLIPSE_INITIAL_MAKE_ARGS "-j${_CMAKE_ECLI >>> Modules/CMakeFindEclipseCDT4.cmake:set(CMAKE_ECLIPSE_MAKE_ARGUMENTS >>> "${_CMAKE_ECLIPSE_INIT >>> Modules/CMakeFindKate.cmake:# Try to find out how many CPUs we have >>> and set the -j argumen >>> Modules/CMakeFindKate.cmake:# Only set -j if we are under UNIX and if >>> the make-tool used a >>> Modules/CMakeFindKate.cmake: set(_CMAKE_KATE_INITIAL_MAKE_ARGS >>> "-j${_CMAKE_KATE_PROCESSOR >>> Modules/CMakeFindKate.cmake:set(CMAKE_KATE_MAKE_ARGUMENTS >>> "${_CMAKE_KATE_INITIAL_MAKE_ARGS >>> >>> And it looks like those try to restrict it to a "make" tool, so they >>> shouldn't be using it in the case of xcodebuild... >>> >>> Mystery. We're missing something. >>> >>> >>> >>> On Thu, Jun 18, 2015 at 12:23 PM, Michael Jackson >>> wrote: >>>> Nope. Neither one of those are on my environment. I am also running at Root for this build and I have a clean .bashrc for both accounts. There must be something in my chest.cmake file that makes CTest think it is running with a makefile generator. >>>> >>>> Should I post my various files? >>>> >>>> Mike Jackson >>>> >>>>> On Jun 18, 2015, at 9:56 AM, David Cole wrote: >>>>> >>>>> Is there a MAKEFLAGS or CTEST_BUILD_FLAGS in your environment? >>>>> >>>>> Where does the -j16 come from? (CTest should not be injecting that >>>>> unless you are telling it to somehow, so it either comes from one of >>>>> your scripts, or your environment...) >>>>> >>>>> grep for just "\-j" -- the value 16 may come from a variable evaluation. >>>>> >>>>> >>>>> HTH, >>>>> David C. >>>>> >>>>> >>>>> On Thu, Jun 18, 2015 at 8:51 AM, Michael Jackson >>>>> wrote: >>>>>> We have a nightly build for our project as reported here http://my.cdash.org/viewBuildError.php?buildid=781789 which is producing an error. The short of it is that CTest is using xcodebuild (which is correct) but is trying to pass the ?-j16? style that normal ?MakeFiles? would use. I have looked through our CTest scripts (Which were adapted from VTK?s nightly builds) but I am not seeing anything about that flag being explicitly called out. >>>>>> >>>>>> Could anyone with nightly build experience help us out? >>>>>> >>>>>> Thanks >>>>>> Mike Jackson >>>>>> BlueQuartz Software >>>>>> -- >>>>>> >>>>>> 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 mike.jackson at bluequartz.net Thu Jun 18 15:46:37 2015 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Thu, 18 Jun 2015 15:46:37 -0400 Subject: [CMake] Running CTest with Xcode build results in Error In-Reply-To: <2500203E-3BC7-4257-83E7-B11B3CD7E2F9@bluequartz.net> References: <910D7217-A955-4487-94DD-2880A55224BB@bluequartz.net> <1DDCD453-3A9A-492F-B6DA-26A6BFA71D4C@bluequartz.net> <9AD1449F-D3FC-464B-A094-21FD48FE0F12@bluequartz.net> <2500203E-3BC7-4257-83E7-B11B3CD7E2F9@bluequartz.net> Message-ID: <338347AA-8956-4A18-B50C-EFE47DF9E038@bluequartz.net> And I will follow that up quickly with ".. it was buried down in our project?.". Thanks for the help. Mike J. On Jun 18, 2015, at 3:45 PM, Michael Jackson wrote: > Found the source. the generated CTestConfig.cmake is the following: > > > ## This file should be placed in the root directory of your project. > ## Then modify the CMakeLists.txt file in the root directory of your > ## project to incorporate the testing dashboard. > ## # The following are required to uses Dart and the Cdash dashboard > ## ENABLE_TESTING() > ## INCLUDE(CTest) > set(CTEST_PROJECT_NAME "DREAM3D") > set(CTEST_NIGHTLY_START_TIME "01:00:00 UTC") > > set(CTEST_DROP_METHOD "http") > set(CTEST_DROP_SITE "my.cdash.org") > set(CTEST_DROP_LOCATION "/submit.php?project=DREAM3D") > set(CTEST_DROP_SITE_CDASH TRUE) > > # Use multiple CPU cores to build > include(ProcessorCount) > ProcessorCount(N) > if(NOT N EQUAL 0) > if(NOT WIN32) > set(CTEST_BUILD_FLAGS "-j${N}") > endif(NOT WIN32) > set(ctest_test_args ${ctest_test_args} PARALLEL_LEVEL ${N}) > > endif() > > So that explains where it is coming from. Does CMake generate this or does my project generate this? > > Mike J > > On Jun 18, 2015, at 3:40 PM, David Cole wrote: > >> The error shown in your CDash build error output page could be coming >> from something that is built within your project as an >> ExternalProject. >> >> Do you have any of those? >> >> Have you grepped your source tree for -j yet? >> >> >> On Thu, Jun 18, 2015 at 3:17 PM, Michael Jackson >> wrote: >>> I will have to admit that I don't pretend to completely understand the CMake file that I am using as I started with something from VTK and changed things to work with our project and setup. I will attach the files to the email. Maybe you can see something that I am missing: >>> >>> >>> >>> >>> >>> Thanks >>> Mike Jackson >>> >>> On Jun 18, 2015, at 3:08 PM, David Cole via CMake wrote: >>> >>>> Are you using Eclipse or Kate? >>>> >>>> Did you do a grep -E "\-j" on all of the files included by the script >>>> that drives the build? (And in your source tree?) >>>> >>>> The only -j possibilities that look likely in CMake itself are shown >>>> in the git grep results from a CMake checkout: >>>> >>>> $ git grep -E "\-j" >>>> >>>> Modules/CMakeFindEclipseCDT4.cmake:# Try to find out how many CPUs we >>>> have and set the -j >>>> Modules/CMakeFindEclipseCDT4.cmake:# Only set -j if we are under UNIX >>>> and if the make-tool >>>> Modules/CMakeFindEclipseCDT4.cmake: >>>> set(_CMAKE_ECLIPSE_INITIAL_MAKE_ARGS "-j${_CMAKE_ECLI >>>> Modules/CMakeFindEclipseCDT4.cmake:set(CMAKE_ECLIPSE_MAKE_ARGUMENTS >>>> "${_CMAKE_ECLIPSE_INIT >>>> Modules/CMakeFindKate.cmake:# Try to find out how many CPUs we have >>>> and set the -j argumen >>>> Modules/CMakeFindKate.cmake:# Only set -j if we are under UNIX and if >>>> the make-tool used a >>>> Modules/CMakeFindKate.cmake: set(_CMAKE_KATE_INITIAL_MAKE_ARGS >>>> "-j${_CMAKE_KATE_PROCESSOR >>>> Modules/CMakeFindKate.cmake:set(CMAKE_KATE_MAKE_ARGUMENTS >>>> "${_CMAKE_KATE_INITIAL_MAKE_ARGS >>>> >>>> And it looks like those try to restrict it to a "make" tool, so they >>>> shouldn't be using it in the case of xcodebuild... >>>> >>>> Mystery. We're missing something. >>>> >>>> >>>> >>>> On Thu, Jun 18, 2015 at 12:23 PM, Michael Jackson >>>> wrote: >>>>> Nope. Neither one of those are on my environment. I am also running at Root for this build and I have a clean .bashrc for both accounts. There must be something in my chest.cmake file that makes CTest think it is running with a makefile generator. >>>>> >>>>> Should I post my various files? >>>>> >>>>> Mike Jackson >>>>> >>>>>> On Jun 18, 2015, at 9:56 AM, David Cole wrote: >>>>>> >>>>>> Is there a MAKEFLAGS or CTEST_BUILD_FLAGS in your environment? >>>>>> >>>>>> Where does the -j16 come from? (CTest should not be injecting that >>>>>> unless you are telling it to somehow, so it either comes from one of >>>>>> your scripts, or your environment...) >>>>>> >>>>>> grep for just "\-j" -- the value 16 may come from a variable evaluation. >>>>>> >>>>>> >>>>>> HTH, >>>>>> David C. >>>>>> >>>>>> >>>>>> On Thu, Jun 18, 2015 at 8:51 AM, Michael Jackson >>>>>> wrote: >>>>>>> We have a nightly build for our project as reported here http://my.cdash.org/viewBuildError.php?buildid=781789 which is producing an error. The short of it is that CTest is using xcodebuild (which is correct) but is trying to pass the ?-j16? style that normal ?MakeFiles? would use. I have looked through our CTest scripts (Which were adapted from VTK?s nightly builds) but I am not seeing anything about that flag being explicitly called out. >>>>>>> >>>>>>> Could anyone with nightly build experience help us out? >>>>>>> >>>>>>> Thanks >>>>>>> Mike Jackson >>>>>>> BlueQuartz Software >>>>>>> -- >>>>>>> >>>>>>> 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 DLRdave at aol.com Thu Jun 18 15:50:30 2015 From: DLRdave at aol.com (David Cole) Date: Thu, 18 Jun 2015 15:50:30 -0400 Subject: [CMake] Running CTest with Xcode build results in Error In-Reply-To: <338347AA-8956-4A18-B50C-EFE47DF9E038@bluequartz.net> References: <910D7217-A955-4487-94DD-2880A55224BB@bluequartz.net> <1DDCD453-3A9A-492F-B6DA-26A6BFA71D4C@bluequartz.net> <9AD1449F-D3FC-464B-A094-21FD48FE0F12@bluequartz.net> <2500203E-3BC7-4257-83E7-B11B3CD7E2F9@bluequartz.net> <338347AA-8956-4A18-B50C-EFE47DF9E038@bluequartz.net> Message-ID: CMake does not generate it. You may have received it as a "suggestion" from CDash when you set the project up, and then you put it in your top level source tree and forget about it usually. But I don't think CDash would suggest using -j with "if(NOT WIN32) logic" (although I could be wrong)... so I'd suspect committers of that file in your source tree. Glad you found it -- stuff like that is frustrating. D On Thu, Jun 18, 2015 at 3:46 PM, Michael Jackson wrote: > And I will follow that up quickly with ".. it was buried down in our project?.". > > Thanks for the help. > > Mike J. > > On Jun 18, 2015, at 3:45 PM, Michael Jackson wrote: > >> Found the source. the generated CTestConfig.cmake is the following: >> >> >> ## This file should be placed in the root directory of your project. >> ## Then modify the CMakeLists.txt file in the root directory of your >> ## project to incorporate the testing dashboard. >> ## # The following are required to uses Dart and the Cdash dashboard >> ## ENABLE_TESTING() >> ## INCLUDE(CTest) >> set(CTEST_PROJECT_NAME "DREAM3D") >> set(CTEST_NIGHTLY_START_TIME "01:00:00 UTC") >> >> set(CTEST_DROP_METHOD "http") >> set(CTEST_DROP_SITE "my.cdash.org") >> set(CTEST_DROP_LOCATION "/submit.php?project=DREAM3D") >> set(CTEST_DROP_SITE_CDASH TRUE) >> >> # Use multiple CPU cores to build >> include(ProcessorCount) >> ProcessorCount(N) >> if(NOT N EQUAL 0) >> if(NOT WIN32) >> set(CTEST_BUILD_FLAGS "-j${N}") >> endif(NOT WIN32) >> set(ctest_test_args ${ctest_test_args} PARALLEL_LEVEL ${N}) >> >> endif() >> >> So that explains where it is coming from. Does CMake generate this or does my project generate this? >> >> Mike J >> >> On Jun 18, 2015, at 3:40 PM, David Cole wrote: >> >>> The error shown in your CDash build error output page could be coming >>> from something that is built within your project as an >>> ExternalProject. >>> >>> Do you have any of those? >>> >>> Have you grepped your source tree for -j yet? >>> >>> >>> On Thu, Jun 18, 2015 at 3:17 PM, Michael Jackson >>> wrote: >>>> I will have to admit that I don't pretend to completely understand the CMake file that I am using as I started with something from VTK and changed things to work with our project and setup. I will attach the files to the email. Maybe you can see something that I am missing: >>>> >>>> >>>> >>>> >>>> >>>> Thanks >>>> Mike Jackson >>>> >>>> On Jun 18, 2015, at 3:08 PM, David Cole via CMake wrote: >>>> >>>>> Are you using Eclipse or Kate? >>>>> >>>>> Did you do a grep -E "\-j" on all of the files included by the script >>>>> that drives the build? (And in your source tree?) >>>>> >>>>> The only -j possibilities that look likely in CMake itself are shown >>>>> in the git grep results from a CMake checkout: >>>>> >>>>> $ git grep -E "\-j" >>>>> >>>>> Modules/CMakeFindEclipseCDT4.cmake:# Try to find out how many CPUs we >>>>> have and set the -j >>>>> Modules/CMakeFindEclipseCDT4.cmake:# Only set -j if we are under UNIX >>>>> and if the make-tool >>>>> Modules/CMakeFindEclipseCDT4.cmake: >>>>> set(_CMAKE_ECLIPSE_INITIAL_MAKE_ARGS "-j${_CMAKE_ECLI >>>>> Modules/CMakeFindEclipseCDT4.cmake:set(CMAKE_ECLIPSE_MAKE_ARGUMENTS >>>>> "${_CMAKE_ECLIPSE_INIT >>>>> Modules/CMakeFindKate.cmake:# Try to find out how many CPUs we have >>>>> and set the -j argumen >>>>> Modules/CMakeFindKate.cmake:# Only set -j if we are under UNIX and if >>>>> the make-tool used a >>>>> Modules/CMakeFindKate.cmake: set(_CMAKE_KATE_INITIAL_MAKE_ARGS >>>>> "-j${_CMAKE_KATE_PROCESSOR >>>>> Modules/CMakeFindKate.cmake:set(CMAKE_KATE_MAKE_ARGUMENTS >>>>> "${_CMAKE_KATE_INITIAL_MAKE_ARGS >>>>> >>>>> And it looks like those try to restrict it to a "make" tool, so they >>>>> shouldn't be using it in the case of xcodebuild... >>>>> >>>>> Mystery. We're missing something. >>>>> >>>>> >>>>> >>>>> On Thu, Jun 18, 2015 at 12:23 PM, Michael Jackson >>>>> wrote: >>>>>> Nope. Neither one of those are on my environment. I am also running at Root for this build and I have a clean .bashrc for both accounts. There must be something in my chest.cmake file that makes CTest think it is running with a makefile generator. >>>>>> >>>>>> Should I post my various files? >>>>>> >>>>>> Mike Jackson >>>>>> >>>>>>> On Jun 18, 2015, at 9:56 AM, David Cole wrote: >>>>>>> >>>>>>> Is there a MAKEFLAGS or CTEST_BUILD_FLAGS in your environment? >>>>>>> >>>>>>> Where does the -j16 come from? (CTest should not be injecting that >>>>>>> unless you are telling it to somehow, so it either comes from one of >>>>>>> your scripts, or your environment...) >>>>>>> >>>>>>> grep for just "\-j" -- the value 16 may come from a variable evaluation. >>>>>>> >>>>>>> >>>>>>> HTH, >>>>>>> David C. >>>>>>> >>>>>>> >>>>>>> On Thu, Jun 18, 2015 at 8:51 AM, Michael Jackson >>>>>>> wrote: >>>>>>>> We have a nightly build for our project as reported here http://my.cdash.org/viewBuildError.php?buildid=781789 which is producing an error. The short of it is that CTest is using xcodebuild (which is correct) but is trying to pass the ?-j16? style that normal ?MakeFiles? would use. I have looked through our CTest scripts (Which were adapted from VTK?s nightly builds) but I am not seeing anything about that flag being explicitly called out. >>>>>>>> >>>>>>>> Could anyone with nightly build experience help us out? >>>>>>>> >>>>>>>> Thanks >>>>>>>> Mike Jackson >>>>>>>> BlueQuartz Software >>>>>>>> -- >>>>>>>> >>>>>>>> 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 Anthony.R.Ette at controlsdata.com Thu Jun 18 16:01:49 2015 From: Anthony.R.Ette at controlsdata.com (Ette, Anthony (CDS)) Date: Thu, 18 Jun 2015 20:01:49 +0000 Subject: [CMake] Support for Concurrent Fortran 77 Compiler (was: fortran compiler failed to compile simple test program) In-Reply-To: <5582F720.50701@kitware.com> References: <2A375B5C08C24643A8A3F8CC2B98C1084BAD8011@USINDPR-MBX003.Rolls-Royce.Local> <557F045F.30804@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD809E@USINDPR-MBX003.Rolls-Royce.Local> <557F13CA.50903@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD80FC@USINDPR-MBX003.Rolls-Royce.Local> <557F2532.5000403@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD8142@USINDPR-MBX003.Rolls-Royce.Local> <557F2F6D.6040804@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD82C0@USINDPR-MBX003.Rolls-Royce.Local> <55801A96.7080600@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD83FB@USINDPR-MBX003.Rolls-Royce.Local> <558029DF.9090403@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD84B8@USINDPR-MBX003.Rolls-Royce.Local> <55802DC2.4040205@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD86E8@USINDPR-MBX003.Rolls-Royce.Local> <55806223.5080305@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD8AA3@USINDPR-MBX003.Rolls-Royce.Local> <5582BD31.5080002@kitware.com> <5582F720.50701@kitware.com> Message-ID: <2A375B5C08C24643A8A3F8CC2B98C1084BAD9BB2@USINDPR-MBX003.Rolls-Royce.Local> > Please try building CMake from commit 7cd539b1 to see if it detects the compiler id as "CCur". Once that works we can look at updating the flags used for the compiler. Looks like this patch (which includes the commit to remove -rdynamic from GNU fortran compilers - f43defaec4e8610e90886a831dcc0a15fdeea1cb) was what we needed (see below)! I still need to go back and adapt to my original project and see where I am wrt this. Also, presumably, my team can continue working ahead with this patch in place in our local cmake install. How will I know when this is rolled into official distro so we can resinstall on all of our client machines? rts1-4:/home/bzpl46/test2> cmake -G "Unix Makefiles" -- The Fortran compiler identification is CCur -- Check for working Fortran compiler: /usr/ccs/bin/cf77 -- Check for working Fortran compiler: /usr/ccs/bin/cf77 -- works -- Detecting Fortran compiler ABI info -- Detecting Fortran compiler ABI info - done -- Checking whether /usr/ccs/bin/cf77 supports Fortran 90 -- Checking whether /usr/ccs/bin/cf77 supports Fortran 90 -- no -- Configuring done -- Generating done -- Build files have been written to: /home/bzpl46/test2 Thanks! Tony This e-mail (including attachments) contains contents owned by Rolls-Royce plc and its subsidiaries, affiliated companies or customers and covered by the laws of England and Wales, Brazil, US, or Canada (federal, state or provincial). The information contained in this email is intended to be confidential, may be legally privileged and subject to export controls which may restrict the access to and transfer of the information. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, interception or copying of this communication is strictly prohibited and may subject you to further legal action. Reply to the sender if you received this email by accident, and then delete the email and any attachments. From brad.king at kitware.com Thu Jun 18 16:22:06 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 18 Jun 2015 16:22:06 -0400 Subject: [CMake] Support for Concurrent Fortran 77 Compiler In-Reply-To: <2A375B5C08C24643A8A3F8CC2B98C1084BAD9BB2@USINDPR-MBX003.Rolls-Royce.Local> References: <2A375B5C08C24643A8A3F8CC2B98C1084BAD8011@USINDPR-MBX003.Rolls-Royce.Local> <557F13CA.50903@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD80FC@USINDPR-MBX003.Rolls-Royce.Local> <557F2532.5000403@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD8142@USINDPR-MBX003.Rolls-Royce.Local> <557F2F6D.6040804@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD82C0@USINDPR-MBX003.Rolls-Royce.Local> <55801A96.7080600@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD83FB@USINDPR-MBX003.Rolls-Royce.Local> <558029DF.9090403@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD84B8@USINDPR-MBX003.Rolls-Royce.Local> <55802DC2.4040205@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD86E8@USINDPR-MBX003.Rolls-Royce.Local> <55806223.5080305@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD8AA3@USINDPR-MBX003.Rolls-Royce.Local> <5582BD31.5080002@kitware.com> <5582F720.50701@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD9BB2@USINDPR-MBX003.Rolls-Royce.Local> Message-ID: <5583286E.1060506@kitware.com> On 06/18/2015 04:01 PM, Ette, Anthony (CDS) wrote: > rts1-4:/home/bzpl46/test2> cmake -G "Unix Makefiles" > -- The Fortran compiler identification is CCur > -- Check for working Fortran compiler: /usr/ccs/bin/cf77 > -- Check for working Fortran compiler: /usr/ccs/bin/cf77 -- works Great! Thanks for testing this. For reference, the commit you mentioned that drops -rdynamic for gfortran can be viewed here: GNU: Drop -rdynamic flag from Fortran http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f43defae > How will I know when this is rolled into official distro? It will be in the 3.4 release, which should come in the Fall. Thanks for your help adding support for this compiler. -Brad From dan at su-root.co.uk Thu Jun 18 17:24:52 2015 From: dan at su-root.co.uk (Dan Liew) Date: Thu, 18 Jun 2015 14:24:52 -0700 Subject: [CMake] Recursively include target include directories only In-Reply-To: References: Message-ID: Hi, On 18 June 2015 at 12:16, Robert Dailey wrote: > On Thu, Jun 18, 2015 at 12:02 PM, Dan Liew wrote: >>> Can you explain what you mean by "strong" and "weak" symbols? >> >> >> Google is your friend >> >> https://en.wikipedia.org/wiki/Weak_symbol >> >> http://stackoverflow.com/questions/2290587/gcc-style-weak-linking-in-visual-studio > > Normally Google is my friend, but today it hates me. Because no such > feature exists for MSVC that I saw. The stackoverflow suggests it is possible for MSVC. Thinking about it some more I think what I'm suggesting is the wrong approach. If you're writing C++ code you should avoid coupling your classes to allow dependency injection (i.e. you pick how classes are coupled at run time not at compile time). If your classes are written with dependency injection in mind then you don't need the weak symbol stuff I was talking about. From rcdailey.lists at gmail.com Thu Jun 18 21:56:03 2015 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Thu, 18 Jun 2015 20:56:03 -0500 Subject: [CMake] Recursively include target include directories only In-Reply-To: References: Message-ID: On Thu, Jun 18, 2015 at 4:24 PM, Dan Liew wrote: > Hi, > > On 18 June 2015 at 12:16, Robert Dailey wrote: >> On Thu, Jun 18, 2015 at 12:02 PM, Dan Liew wrote: >>>> Can you explain what you mean by "strong" and "weak" symbols? >>> >>> >>> Google is your friend >>> >>> https://en.wikipedia.org/wiki/Weak_symbol >>> >>> http://stackoverflow.com/questions/2290587/gcc-style-weak-linking-in-visual-studio >> >> Normally Google is my friend, but today it hates me. Because no such >> feature exists for MSVC that I saw. > > The stackoverflow suggests it is possible for MSVC. > > Thinking about it some more I think what I'm suggesting is the wrong > approach. If you're writing C++ code you should avoid coupling your > classes to allow dependency injection (i.e. you pick how classes are > coupled at run time not at compile time). If your classes are written > with dependency injection in mind then you don't need the weak symbol > stuff I was talking about. I managed to find MSVC information outside of the SO question (No, I never skimmed through it sufficiently to find any information directly there on it). Apparently MSVC will prioritize symbols in .OBJ files over those found in .LIB without any warnings or errors. So only special case logic is needed for GCC on Linux (the #pragma weak format). I agree with the principle of runtime dependency injection. It's necessary when mocking across library boundaries. However, my two main concerns: 1) Complexity overhead (Objects will now become more complex to construct, as dependencies must be fulfilled externally). This appears to be a common concern with dependency injection, however factories and reasonable defaults normally will help counter the issue. 2) Compile time polymorphism for dependency injection (i.e. templates) may not be an option. Template classes are not compiled into static libs, so there may even be a way to do this. However slightly related to #1, it forces a class to become a template when it otherwise would not need to be one (remedy would be an alias serving a default template argument). I think I can make this work, thanks to the fine suggestions here. Much appreciated guys. From jamesbigler at gmail.com Fri Jun 19 04:53:31 2015 From: jamesbigler at gmail.com (James Bigler) Date: Fri, 19 Jun 2015 10:53:31 +0200 Subject: [CMake] CUDA OBJECT libraries? In-Reply-To: <55818BC1.2020503@txcorp.com> References: <55818BC1.2020503@txcorp.com> Message-ID: I looked at it briefly one day, and I couldn't figure out a way to tie the output of custom commands to the list of objects that add_library(OBJECTS) produces. Alternatively since all you want is a list of objects, FindCUDA can produce this just as well. Use the CUDA_WRAP_SRCS macro. It produces a list of object files from .cu files. You can use this list and link multiple libraries from the same objects. Look at the documentation for CUDA_WRAP_SRCS too see how to call it. On Wed, Jun 17, 2015 at 5:01 PM, JR Cary wrote: > I would like to use OBJECT libraries with CUDA. > > If I try > > cuda_add_library(foo OBJECT ) > > I get > > CMake Error at > /opt/contrib-clangcxx11/cmake-3.2.2-ser/share/cmake-3.2/Modules/FindCUDA.cmake:1518 > (add_library): > OBJECT library "txsbaseobj" contains: > > txsbaseobj_generated_TxsGpuInterpolator.cu.o > txsbaseobj_generated_TxsBaseTestKernels.cu.o > txsbaseobj_intermediate_link.o > > > Is there a standard way of dealing with this? > > Thx....... > > -- > > 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 mjklaim at gmail.com Fri Jun 19 06:07:48 2015 From: mjklaim at gmail.com (=?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?=) Date: Fri, 19 Jun 2015 12:07:48 +0200 Subject: [CMake] How does :: actually works? In-Reply-To: References: <6642590.gJq68crCL0@ersa> <10549345.795GcQO5j7@ersa> Message-ID: On 17 June 2015 at 22:58, Stephen Kelly wrote: > Klaim - Jo?l Lamotte wrote: > > > Thinking about boost, if package files works well with header-only > > libraries (which I > > suppose it should as long as the boost define header-only targets) > > then it would be very useful indeed. > > Yes, I wrote some cmake 3.0 features specifically for the Boost use cases > (header only and lots of cyclic dependencies). > > > Then I have to have all my libraries to link with all the boost libraries > > listed in the boost > > library variable generated by FindBoost. > > I don't have working knowledge of FindBoost, so I can't give a good answer. > The documentation at the top of the file says it creates a variable per > library though. > > Yes it seems that I missed that part when I worked on it, totally my mistake. > > If I understand correctly, if FindBoost was supporting imported targets > > and using "Boost" as a > > namespace (like Qt does), then I could link my libraries to boost > > libraries in a more > > precise way as I would link each library separately instead of everything > > FindBoost > > put in the boost libraries variable. > > This still has other advantages anyway, such as transitivity, conciseness, > consistency, better error messages etc. > > Thanks, > > Steve. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Anthony.R.Ette at controlsdata.com Fri Jun 19 10:54:13 2015 From: Anthony.R.Ette at controlsdata.com (Ette, Anthony (CDS)) Date: Fri, 19 Jun 2015 14:54:13 +0000 Subject: [CMake] Support for Concurrent Fortran 77 Compiler In-Reply-To: <5583286E.1060506@kitware.com> References: <2A375B5C08C24643A8A3F8CC2B98C1084BAD8011@USINDPR-MBX003.Rolls-Royce.Local> <557F13CA.50903@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD80FC@USINDPR-MBX003.Rolls-Royce.Local> <557F2532.5000403@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD8142@USINDPR-MBX003.Rolls-Royce.Local> <557F2F6D.6040804@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD82C0@USINDPR-MBX003.Rolls-Royce.Local> <55801A96.7080600@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD83FB@USINDPR-MBX003.Rolls-Royce.Local> <558029DF.9090403@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD84B8@USINDPR-MBX003.Rolls-Royce.Local> <55802DC2.4040205@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD86E8@USINDPR-MBX003.Rolls-Royce.Local> <55806223.5080305@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD8AA3@USINDPR-MBX003.Rolls-Royce.Local> <5582BD31.5080002@kitware.com> <5582F720.50701@kitware.com> <2A375B5C08C24643A8A3F8CC2B98C1084BAD9BB2@USINDPR-MBX003.Rolls-Royce.Local> <5583286E.1060506@kitware.com> Message-ID: <2A375B5C08C24643A8A3F8CC2B98C1084BAD9E02@USINDPR-MBX003.Rolls-Royce.Local> > Great! Thanks for testing this. No problem - thank YOU for supporting this compiler! > It will be in the 3.4 release, which should come in the Fall. Great -will keep an eye out for 3.4 release. Thanks again, Tony This e-mail (including attachments) contains contents owned by Rolls-Royce plc and its subsidiaries, affiliated companies or customers and covered by the laws of England and Wales, Brazil, US, or Canada (federal, state or provincial). The information contained in this email is intended to be confidential, may be legally privileged and subject to export controls which may restrict the access to and transfer of the information. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, interception or copying of this communication is strictly prohibited and may subject you to further legal action. Reply to the sender if you received this email by accident, and then delete the email and any attachments. From rjvbertin at gmail.com Fri Jun 19 12:53:49 2015 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Fri, 19 Jun 2015 18:53:49 +0200 Subject: [CMake] --prefix commandline option? Message-ID: <2029157.8md0xcCItq@portia.local> Hello, I discovered by accident that cmake (3.2.2) apparently respects the --prefix command line option, with a result that's somewhat different from setting CMAKE_INSTALL_PREFIX. I cannot seem to find any documentation on this feature though: have I overlooked it, or is this indeed an undocumented feature that shouldn't be used? If that latter option, is there a -DCMAKE_??? equivalent that has the same effects? Thanks, Ren? From tom.kacvinsky at vectorcast.com Fri Jun 19 13:17:02 2015 From: tom.kacvinsky at vectorcast.com (Tom Kacvinsky) Date: Fri, 19 Jun 2015 13:17:02 -0400 Subject: [CMake] Creating two libraries from the same set of source code, but with different compiler options Message-ID: I have need to build two libraries, each based on the same base code, but each library is built with different compiler options. I know how to force the compilation options to be what I want, the problem I am having is envisioning how to do this within one CMakeLists.txt file. What I am hung up on is this: if I change the file properties, I am afraid the properties will apply to both libraries. Is there a way of instruction cmake to apply those file properties to only one target, or will I have to split the building of the libraries into two CMakeLists.txt files? Thanks, Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.noulard at gmail.com Fri Jun 19 13:59:15 2015 From: eric.noulard at gmail.com (Eric Noulard) Date: Fri, 19 Jun 2015 19:59:15 +0200 Subject: [CMake] Creating two libraries from the same set of source code, but with different compiler options In-Reply-To: References: Message-ID: 2015-06-19 19:17 GMT+02:00 Tom Kacvinsky : > I have need to build two libraries, each based on the same base code, but > each library is built with different compiler options. I know how to force > the compilation options to be what I want, the problem I am having is > envisioning how to do this within one CMakeLists.txt file. What I am hung > up on is this: if I change the file properties, I am afraid the properties > will apply to both libraries. Is there a way of instruction cmake to apply > those file properties to only one target, or will I have to split the > building of the libraries into two CMakeLists.txt files? > The COMPILE_FLAGS property may be set on a per-target basis and not source file basis. see set_target_properties vs set_source_files_properties Eric > > Thanks, > > Tom > > -- > > 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 rainer.poisel at gmail.com Fri Jun 19 15:13:23 2015 From: rainer.poisel at gmail.com (Rainer Poisel) Date: Fri, 19 Jun 2015 21:13:23 +0200 Subject: [CMake] CPack: Different installation prefixes per CPACK_GENERATOR Message-ID: Dear list, how can I specify different installation prefixes for the different CPACK_GENERATORs? For example: * the DEB package should be installed to `/opt/project` * the TGZ archive should consist only of the `project` directory >From the documentation I understood that I would have to use the CPACK_PROJECT_CONFIG_FILE variable. Using that, it should be possible to achieve the desired goal. However, it did not work for me. This is my CPack configuration: 8<============================ set(CPACK_GENERATOR "DEB;TGZ") set(CPACK_PROJECT_CONFIG_FILE ${CMAKE_SOURCE_DIR}/cmake/package.linux.txt) 8<============================ And this is my ${CMAKE_SOURCE_DIR}/cmake/package.linux.txt file: 8<============================ IF (CPACK_GENERATOR MATCHES "DEB") set(CPACK_NATIVE_INSTALL_DIRECTORY "/opt") set(CMAKE_INSTALL_PREFIX "/opt") set(CPACK_PACKAGING_INSTALL_PREFIX "/opt") set(CPACK_INSTALL_DIRECTORY "/opt") ELSEIF(CPACK_GENERATOR MATCHES "TGZ") set(CPACK_NATIVE_INSTALL_DIRECTORY "") set(CMAKE_INSTALL_PREFIX "") set(CPACK_PACKAGING_INSTALL_PREFIX "") set(CPACK_INSTALL_DIRECTORY "") ENDIF() 8<============================ I ensured that all files get parsed using MESSAGE() directives, but the prefix of my packages is always /usr/local. Thanks for giving me a few hints, Rainer From eric.noulard at gmail.com Fri Jun 19 16:38:39 2015 From: eric.noulard at gmail.com (Eric Noulard) Date: Fri, 19 Jun 2015 22:38:39 +0200 Subject: [CMake] CPack: Different installation prefixes per CPACK_GENERATOR In-Reply-To: References: Message-ID: 2015-06-19 21:13 GMT+02:00 Rainer Poisel : > Dear list, > > how can I specify different installation prefixes for the different > CPACK_GENERATORs? > > For example: > > * the DEB package should be installed to `/opt/project` > * the TGZ archive should consist only of the `project` directory > > From the documentation I understood that I would have to use the > CPACK_PROJECT_CONFIG_FILE variable. Using that, it should be possible > to achieve the desired goal. However, it did not work for me. > > This is my CPack configuration: > > 8<============================ > set(CPACK_GENERATOR "DEB;TGZ") > set(CPACK_PROJECT_CONFIG_FILE ${CMAKE_SOURCE_DIR}/cmake/package.linux.txt) > 8<============================ > Did you set those before include(CPack) ? > > And this is my ${CMAKE_SOURCE_DIR}/cmake/package.linux.txt file: > > 8<============================ > IF (CPACK_GENERATOR MATCHES "DEB") > set(CPACK_NATIVE_INSTALL_DIRECTORY "/opt") > set(CMAKE_INSTALL_PREFIX "/opt") > set(CPACK_PACKAGING_INSTALL_PREFIX "/opt") > set(CPACK_INSTALL_DIRECTORY "/opt") > ELSEIF(CPACK_GENERATOR MATCHES "TGZ") > set(CPACK_NATIVE_INSTALL_DIRECTORY "") > set(CMAKE_INSTALL_PREFIX "") > set(CPACK_PACKAGING_INSTALL_PREFIX "") > set(CPACK_INSTALL_DIRECTORY "") > ENDIF() > 8<============================ > > I ensured that all files get parsed using MESSAGE() directives, but > the prefix of my packages is always /usr/local. > Looks good Strange enough... Would you be able to give us a standalone strip down example project of this and may be tell us which version of CPack/CMake you are using on which platform. What happen if you do something like; cpack -G DEB -D CPACK_PACKAGING_INSTALL_PREFIX=/tmp ? > > Thanks for giving me a few hints, > Rainer > -- > > 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 rainer.poisel at gmail.com Sat Jun 20 01:53:04 2015 From: rainer.poisel at gmail.com (Rainer Poisel) Date: Sat, 20 Jun 2015 07:53:04 +0200 Subject: [CMake] CPack: Different installation prefixes per CPACK_GENERATOR In-Reply-To: References: Message-ID: Hi, and thanks for your quick reply! Starting from a minimal, stripped down version of my build configuration (thx for the tip!) I found that what I described initially actually works. The reason it was not working was, that I had turned the CPACK_SET_DESTDIR flag on in another place. After removing the relevant SET() directive the installation prefixes worked as desired. For the record, this is my minimal, stripped down working version: 8<======== CMakeLists.txt ============= cmake_minimum_required(VERSION 3.2) project(stripped-down C) add_executable(main main.c) install(TARGETS main RUNTIME DESTINATION bin ) set(CPACK_GENERATOR "DEB;TGZ") set(CPACK_PROJECT_CONFIG_FILE ${CMAKE_SOURCE_DIR}/package.txt) set(CPACK_PACKAGE_CONTACT "Some One ") include(CPack) 8<================================= 8<======== ${CMAKE_SOURCE_DIR}/package.txt) ============= IF (CPACK_GENERATOR MATCHES "DEB") set(CPACK_PACKAGING_INSTALL_PREFIX "/opt") ELSEIF(CPACK_GENERATOR MATCHES "TGZ") set(CPACK_PACKAGING_INSTALL_PREFIX "") ENDIF() 8<================================================== Best regards, Rainer On Fri, Jun 19, 2015 at 10:38 PM, Eric Noulard wrote: > > > 2015-06-19 21:13 GMT+02:00 Rainer Poisel : >> >> Dear list, >> >> how can I specify different installation prefixes for the different >> CPACK_GENERATORs? >> >> For example: >> >> * the DEB package should be installed to `/opt/project` >> * the TGZ archive should consist only of the `project` directory >> >> From the documentation I understood that I would have to use the >> CPACK_PROJECT_CONFIG_FILE variable. Using that, it should be possible >> to achieve the desired goal. However, it did not work for me. >> >> This is my CPack configuration: >> >> 8<============================ >> set(CPACK_GENERATOR "DEB;TGZ") >> set(CPACK_PROJECT_CONFIG_FILE ${CMAKE_SOURCE_DIR}/cmake/package.linux.txt) >> 8<============================ > > > Did you set those before include(CPack) ? >> >> >> And this is my ${CMAKE_SOURCE_DIR}/cmake/package.linux.txt file: >> >> 8<============================ >> IF (CPACK_GENERATOR MATCHES "DEB") >> set(CPACK_NATIVE_INSTALL_DIRECTORY "/opt") >> set(CMAKE_INSTALL_PREFIX "/opt") >> set(CPACK_PACKAGING_INSTALL_PREFIX "/opt") >> set(CPACK_INSTALL_DIRECTORY "/opt") >> ELSEIF(CPACK_GENERATOR MATCHES "TGZ") >> set(CPACK_NATIVE_INSTALL_DIRECTORY "") >> set(CMAKE_INSTALL_PREFIX "") >> set(CPACK_PACKAGING_INSTALL_PREFIX "") >> set(CPACK_INSTALL_DIRECTORY "") >> ENDIF() >> 8<============================ >> >> I ensured that all files get parsed using MESSAGE() directives, but >> the prefix of my packages is always /usr/local. > > > Looks good Strange enough... > Would you be able to give us a standalone strip down example project of > this > and may be tell us which version of CPack/CMake you are using on which > platform. > > > What happen if you do something like; > > cpack -G DEB -D CPACK_PACKAGING_INSTALL_PREFIX=/tmp > > ? >> >> >> Thanks for giving me a few hints, >> Rainer >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake > > > > > -- > Eric From roman.wueger at gmx.at Sat Jun 20 04:10:21 2015 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Sat, 20 Jun 2015 10:10:21 +0200 Subject: [CMake] [cmake-developers] Problems when creating config files and add_dependencies In-Reply-To: <557ECECE.8030905@kitware.com> References: <07e401d0a501$b1e77230$15b65690$@gmx.at> <557ECECE.8030905@kitware.com> Message-ID: <80D05633-73D2-4D9D-B5F5-C42255FEBC06@gmx.at> Hello Brad, but the problem with this command is, that for multi configuration environments (e.g. Visual Studio), it requires $ in the filename which then creates 4 header files. One for each configuration. Maybe I didn't understand something, but after that I also need to call configure_file to resolve the rest of the CMake variables. After the 4 header files are generated, which one should I include in the unit test for example? Do you understand the problem? Thanks Roman > Am 15.06.2015 um 15:10 schrieb Brad King : > >> On 06/12/2015 07:19 AM, Roman W?ger wrote: >> It would be great if generator expressions can be used with >> configure_file to avoid such overhead. >> >> Does anyone have an idea on how to solve that? > > See file(GENERATE). > > -Brad > From scott at towel42.com Sat Jun 20 04:19:05 2015 From: scott at towel42.com (Scott Aron Bloom) Date: Sat, 20 Jun 2015 08:19:05 +0000 Subject: [CMake] Any plans for Win64 + Win32 VS generators? Message-ID: Is there any plan, on merging the Win32 and Win64 generators for the current set of VS 20XX generators? I know there are a couple of non-kitware attempts.. but nothing that I would call ready for the commercial world. Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From salilvishnukapur at gmail.com Sat Jun 20 08:47:59 2015 From: salilvishnukapur at gmail.com (salil vishnu Kapur) Date: Sat, 20 Jun 2015 18:17:59 +0530 Subject: [CMake] Regarding CMake usage in creating User Defined Functions in mysql on windows OS Message-ID: Hello community ! I am presently going through the steps in here https://dev.mysql.com/doc/refman/5.0/en/udf-compiling.html for creating UDF .The points with which i am concerned are numbered as 1 , 2 , 3 .... at the end of the above link .Can you guide me how to go ahead with the 4 , 5 and 6 steps where CMake is being used. Sorry if i am asking a very silly question, the problem is i am novice with regard to CMake. Hope to get help. -------------- next part -------------- An HTML attachment was scrubbed... URL: From scott at towel42.com Sat Jun 20 10:12:04 2015 From: scott at towel42.com (Scott Aron Bloom) Date: Sat, 20 Jun 2015 14:12:04 +0000 Subject: [CMake] Regarding CMake usage in creating User Defined Functions in mysql on windows OS In-Reply-To: References: Message-ID: What have you tried? And what is causing you problems? From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of salil vishnu Kapur Sent: Saturday, June 20, 2015 5:48 AM To: CMake at cmake.org Subject: [CMake] Regarding CMake usage in creating User Defined Functions in mysql on windows OS Hello community ! I am presently going through the steps in here https://dev.mysql.com/doc/refman/5.0/en/udf-compiling.html for creating UDF .The points with which i am concerned are numbered as 1 , 2 , 3 .... at the end of the above link .Can you guide me how to go ahead with the 4 , 5 and 6 steps where CMake is being used. Sorry if i am asking a very silly question, the problem is i am novice with regard to CMake. Hope to get help. -------------- next part -------------- An HTML attachment was scrubbed... URL: From scott at towel42.com Sat Jun 20 15:41:18 2015 From: scott at towel42.com (Scott Aron Bloom) Date: Sat, 20 Jun 2015 19:41:18 +0000 Subject: [CMake] Regarding CMake usage in creating User Defined Functions in mysql on windows OS In-Reply-To: References: Message-ID: Generator is the target build system. If you run cmake ?help, it will give you a list of available generators. Scott From: salil vishnu Kapur [mailto:salilvishnukapur at gmail.com] Sent: Saturday, June 20, 2015 10:55 AM To: Scott Aron Bloom Subject: Re: [CMake] Regarding CMake usage in creating User Defined Functions in mysql on windows OS As per the link that i specified in the mail , I downloaded this make-3.3.0-rc2-win32-x86 .Then , made a CMakeLists.txt as per step number 4. After that i tried to run this command cmake -G "" , but as i could not understand what Generator did stand for , so i failed to run this command , although i tried alot to understand it by using cmake --help. So my request to the community is to please go through the step numbers 4, 5 and 6 of the link specified in the earlier mail . Any kind of help will be deeply appreciated . On Sat, Jun 20, 2015 at 7:42 PM, Scott Aron Bloom > wrote: What have you tried? And what is causing you problems? From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of salil vishnu Kapur Sent: Saturday, June 20, 2015 5:48 AM To: CMake at cmake.org Subject: [CMake] Regarding CMake usage in creating User Defined Functions in mysql on windows OS Hello community ! I am presently going through the steps in here https://dev.mysql.com/doc/refman/5.0/en/udf-compiling.html for creating UDF .The points with which i am concerned are numbered as 1 , 2 , 3 .... at the end of the above link .Can you guide me how to go ahead with the 4 , 5 and 6 steps where CMake is being used. Sorry if i am asking a very silly question, the problem is i am novice with regard to CMake. Hope to get help. -------------- next part -------------- An HTML attachment was scrubbed... URL: From steveire at gmail.com Sun Jun 21 12:11:19 2015 From: steveire at gmail.com (Stephen Kelly) Date: Sun, 21 Jun 2015 18:11:19 +0200 Subject: [CMake] Recursively include target include directories only References: Message-ID: Petr Kmoch wrote: > On Thu, Jun 18, 2015 at 1:43 AM, Robert Dailey > wrote: > >> On Wed, Jun 17, 2015 at 4:31 PM, Dan Liew >> wrote: >> > On 17 June 2015 at 12:28, Robert Dailey >> > >> wrote: >> >> Is there a way to only take (recursively) the include directiories >> >> from a target or set of targets? I know that include directories >> >> propagate when passing targets to target_link_libraries(), but I do >> >> not want to link the libs; I only want the include directories. >> >> >> >> How can I do this? Thanks. >> > > I haven't tested this, but it should be possible to drag in the interface > properties explicitly with generator expressions. Something like this: > > add_executable(Depender ...) > target_include_directories(Depender PRIVATE > $ > $ > ) > > dtto for other INTERFACE_... properties you might need. He seems to want INCLUDE_DIRECTORIES, not INTERFACE_INCLUDE_DIRECTORIES as he's compiling a file from the target. Thanks, Steve. From Micha.Renner at t-online.de Mon Jun 22 03:39:13 2015 From: Micha.Renner at t-online.de (Micha Renner) Date: Mon, 22 Jun 2015 09:39:13 +0200 Subject: [CMake] FIND_LIBRARY_USE_LIB64_PATHS on Win64 Message-ID: <1434958753.5033.7.camel@t-online.de> Hi, does FIND_LIBRARY_USE_LIB64_PATHS work with Windows64. >From this ... https://public.kitware.com/Bug/view.php?id=15301#c37449 ...one might conclude it does, but on my Win64-System PROJECT(T LANGUAGES C) CMAKE_MINIMUM_REQUIRED(VERSION 3.0) GET_PROPERTY(r22 GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS) it is always FALSE. Greetings Michael From brad.king at kitware.com Mon Jun 22 09:17:48 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 22 Jun 2015 09:17:48 -0400 Subject: [CMake] [cmake-developers] Problems when creating config files and add_dependencies In-Reply-To: <80D05633-73D2-4D9D-B5F5-C42255FEBC06@gmx.at> References: <07e401d0a501$b1e77230$15b65690$@gmx.at> <557ECECE.8030905@kitware.com> <80D05633-73D2-4D9D-B5F5-C42255FEBC06@gmx.at> Message-ID: <55880AFC.2060307@kitware.com> On 06/20/2015 04:10 AM, Roman W?ger wrote: > but the problem with this command is, that for multi configuration > environments (e.g. Visual Studio), it requires $ in the > filename which then creates 4 header files. One for each configuration. Yes, because generator expressions can reference things that depend on the configuration. configure_file does not support them because its result does not depend on the configuration. I guess I didn't understand what you meant by "generator expressions can be used with configure_file to avoid such overhead". Returning to the original problem, the circular dependency may appear because using $ in a custom target results in an ordering dependency on the target named in the generator expression. To confirm this, try hard-coding the path by hand for one example. -Brad From cedric.doucet at inria.fr Mon Jun 22 12:02:01 2015 From: cedric.doucet at inria.fr (Cedric Doucet) Date: Mon, 22 Jun 2015 18:02:01 +0200 (CEST) Subject: [CMake] Automatic management of Eclipse projects In-Reply-To: <1198379247.16136951.1434988623275.JavaMail.zimbra@inria.fr> Message-ID: <18548708.16138099.1434988921742.JavaMail.zimbra@inria.fr> Hello, I am testing the possibility of generating Eclipse projects with CMake. I use the following command line: cmake -G"Eclipse CDT4 - Unix Makefiles" -D CMAKE_BUILD_TYPE=Debug ../src It works fine. However, I would like to go further in this direction. - What could I put in CMakeLists.txt to not to have to pass the "-G" option to cmake? - How could I be able to switch between debug and release modes in Eclipse? Thank you very much for your help! C?dric -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.neundorf-work at gmx.net Mon Jun 22 14:52:44 2015 From: a.neundorf-work at gmx.net (Alexander Neundorf) Date: Mon, 22 Jun 2015 20:52:44 +0200 Subject: [CMake] Automatic management of Eclipse projects In-Reply-To: <18548708.16138099.1434988921742.JavaMail.zimbra@inria.fr> References: <18548708.16138099.1434988921742.JavaMail.zimbra@inria.fr> Message-ID: <1685259.TrcQV5dVPO@tuxedo.neundorf.net> On Monday, June 22, 2015 18:02:01 Cedric Doucet wrote: > Hello, > > I am testing the possibility of generating Eclipse projects with CMake. > I use the following command line: > cmake -G"Eclipse CDT4 - Unix Makefiles" -D CMAKE_BUILD_TYPE=Debug ../src > It works fine. > > However, I would like to go further in this direction. > - What could I put in CMakeLists.txt to not to have to pass the "-G" option > to cmake? Currently you have have to use -G, or use cmake-gui. Support for a cmake-specific environmnent variable like CMAKE_DEFAULT_GENERATOR could be added. > - How could I be able to switch between debug and release modes > in Eclipse? Generate two build trees (projects), and import them both in cmake. Alex From ghleclerc at gmail.com Mon Jun 22 15:36:20 2015 From: ghleclerc at gmail.com (Ghyslain Leclerc) Date: Mon, 22 Jun 2015 15:36:20 -0400 Subject: [CMake] Multiple targets Message-ID: Hello, We have a modular in-house library that we use for our software. ?Let?s call it lib_x. ?Let?s call a few of the modules (we have 7 I think) mod_y, mod_z, mod_u and mod_v. ?Let?s say I have two applications that use all of this and call them app_1 and app_2. The way I have setup our CMake builds is that I first find out what modules of lib_x the applications app_1 and app_2 depend on. ?Then I build a single library lib_x which include the selected modules and finally, I build each app independently and link against the single library. For instance, let?s say app_1 depends on mod_y and mod_z and app_2 depends on mod_y, mod_z and mod_u. ?Then, I would build lib_x with everything for modules y, z and u (excluding module v) and build app_1 and app_2 linking against lib_x Might not be explained properly (my apologies), willing to answer any questions on that. I am looking into changing/modernizing our build system. ?From what I understand, instead of building everything into a single library, I could build separate libraries, export them as targets and link against them. ?(Pretty sure I could have done that before, but just coming around to do it.) Am I wrong ? ?Am I completely missing the point ? ?If I am not and it is a reasonable approach, is there a place where a tutorial is available ? ?I am trying really hard to read the documentation on export command and targets and such, but I am having a real hard time when trying to actually implement anything concrete. I first attempted to do this: include_directories( "${LIB_ROOT_DIR}/include" ) add_library( general ${GENERAL_SRCS} ? ? ? ? ? ? ? ? ? ? ?${GENERAL_HDRS} ? ? ? ? ? ? ? ? ? ? ?${LIB_ROOT_DIR}/include/hdqrt/always_inline.h ? ? ? ? ? ? ? ? ? ? ?${LIB_ROOT_DIR}/include/hdqrt/debug.h ? ? ? ? ? ? ? ? ? ? ?${LIB_ROOT_DIR}/include/hdqrt/Error.h ? ? ? ? ? ? ? ? ? ? ?${LIB_ROOT_DIR}/include/hdqrt/warn_stop.h ? ? ? ? ? ? ? ? ? ? ?${LIB_ROOT_DIR}/include/hdqrt/warn_restart.h ? ? ? ? ? ? ) set_property( TARGET general PROPERTY CXX_STANDARD 14 ) export( TARGETS general FILE general.cmake ) but then, the general.cmake file is nowhere to be found. ?And if I test in another (parent) CMakeLists.txt to see if the target is defined, it is not. Sorry if this is a silly question. ?Trying to figure this out. Thanks in advance. Ghyslain -------------- next part -------------- An HTML attachment was scrubbed... URL: From Anthony.R.Ette at controlsdata.com Mon Jun 22 18:45:27 2015 From: Anthony.R.Ette at controlsdata.com (Ette, Anthony (CDS)) Date: Mon, 22 Jun 2015 22:45:27 +0000 Subject: [CMake] SET(CMAKE_Fortran_FLAGS) not always taking effect Message-ID: <2A375B5C08C24643A8A3F8CC2B98C1084BADA8CD@USINDPR-MBX003.Rolls-Royce.Local> So I am forcing some flags in a high-level CMakeLists.txt for all fortran sources using the subject command. When I invoke via one environment (via python subprocess.popen with modified environment), cmake succeeds and all the build files are generated, however, my flags don't appear in the CMAKE build dir file flags.make. When I launch another environment to build (cmd with modified environment), the build first fails (because my flags weren't thrown), but if I force cmake to run in the cmd env, flags.make then gets updated with my flags and the build succeeds. Can you help me understand this behavior? What triggers cmake to write SET(CMAKE_Fortran_FLAGS) to the flags.make file and why might I not be satisfying it in the first environment? Thanks in advance, Anthony Ette Systems Engineer Simulation and Modeling Controls and Data Services Inc. Part of the Rolls-Royce Group 7661 N Perimeter Rd Indianapolis, IN 46241 tel: +1 (317) 230-6943 mob: +1 (317) 864-7975 email: Anthony.R.Ette at controlsdata.com www.controlsdata.com This e-mail (including attachments) contains contents owned by Rolls-Royce plc and its subsidiaries, affiliated companies or customers and covered by the laws of England and Wales, Brazil, US, or Canada (federal, state or provincial). The information contained in this email is intended to be confidential, may be legally privileged and subject to export controls which may restrict the access to and transfer of the information. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, interception or copying of this communication is strictly prohibited and may subject you to further legal action. Reply to the sender if you received this email by accident, and then delete the email and any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Anthony.R.Ette at controlsdata.com Mon Jun 22 21:17:33 2015 From: Anthony.R.Ette at controlsdata.com (Ette, Anthony (CDS)) Date: Tue, 23 Jun 2015 01:17:33 +0000 Subject: [CMake] SET(CMAKE_Fortran_FLAGS) not always taking effect Message-ID: <2A375B5C08C24643A8A3F8CC2B98C1084BADA92A@USINDPR-MBX003.Rolls-Royce.Local> More information on this. I just discovered it has nothing to do with my different environments, just that cmake has to run twice (in either environment) for the flags.make file to reflect my SET(CMAKE_Fortran_FLAGS) command. Is this expected behavior? If so, I'll setup a script that runs cmake twice so our developers are good to go out-of-box with our src tree. Thanks, Anthony Ette Systems Engineer Simulation and Modeling Controls and Data Services Inc. Part of the Rolls-Royce Group tel: +1 (317) 230-6943 mob: +1 (317) 864-7975 email: Anthony.R.Ette at controlsdata.com www.controlsdata.com From: Ette, Anthony (CDS) Sent: Monday, June 22, 2015 6:45 PM To: CMake at cmake.org Subject: SET(CMAKE_Fortran_FLAGS) not always taking effect So I am forcing some flags in a high-level CMakeLists.txt for all fortran sources using the subject command. When I invoke via one environment (via python subprocess.popen with modified environment), cmake succeeds and all the build files are generated, however, my flags don't appear in the CMAKE build dir file flags.make. When I launch another environment to build (cmd with modified environment), the build first fails (because my flags weren't thrown), but if I force cmake to run in the cmd env, flags.make then gets updated with my flags and the build succeeds. Can you help me understand this behavior? What triggers cmake to write SET(CMAKE_Fortran_FLAGS) to the flags.make file and why might I not be satisfying it in the first environment? Thanks in advance, Anthony Ette Systems Engineer Simulation and Modeling Controls and Data Services Inc. Part of the Rolls-Royce Group 7661 N Perimeter Rd Indianapolis, IN 46241 tel: +1 (317) 230-6943 mob: +1 (317) 864-7975 email: Anthony.R.Ette at controlsdata.com www.controlsdata.com This e-mail (including attachments) contains contents owned by Rolls-Royce plc and its subsidiaries, affiliated companies or customers and covered by the laws of England and Wales, Brazil, US, or Canada (federal, state or provincial). The information contained in this email is intended to be confidential, may be legally privileged and subject to export controls which may restrict the access to and transfer of the information. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, interception or copying of this communication is strictly prohibited and may subject you to further legal action. Reply to the sender if you received this email by accident, and then delete the email and any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Anthony.R.Ette at controlsdata.com Mon Jun 22 21:49:35 2015 From: Anthony.R.Ette at controlsdata.com (Ette, Anthony (CDS)) Date: Tue, 23 Jun 2015 01:49:35 +0000 Subject: [CMake] SET(CMAKE_Fortran_FLAGS) not always taking effect Message-ID: <2A375B5C08C24643A8A3F8CC2B98C1084BADA944@USINDPR-MBX003.Rolls-Royce.Local> Yet more info. How foolish of me to think it's ok to have to run cmake twice. I found that the heart of the problem was the use of ${CMAKE_BINARY_DIR} in LINK_DIRECTORIES for the FORTRAN target in question (a static library, which other parts of the project depend on). So I have a CXX project (a subdir in my src tree) that depends on a fortran static library (also built from a subdir in my src tree). In this situation, the solution is to not use LINK_DIRECTORIES at all to point to the FORTRAN target, just specify full path in TARGET_LINK_DIRECTORIES. I understand that best practice is to always specify full path in TARGET_LINK_DIRECTORIES, but this can be quite cumbersome for large, disparate projects. Anyway, hope my pain helps someone else. Anthony Ette Systems Engineer Simulation and Modeling Controls and Data Services Inc. Part of the Rolls-Royce Group tel: +1 (317) 230-6943 mob: +1 (317) 864-7975 email: Anthony.R.Ette at controlsdata.com www.controlsdata.com From: Ette, Anthony (CDS) Sent: Monday, June 22, 2015 9:18 PM To: CMake at cmake.org Subject: RE: SET(CMAKE_Fortran_FLAGS) not always taking effect More information on this. I just discovered it has nothing to do with my different environments, just that cmake has to run twice (in either environment) for the flags.make file to reflect my SET(CMAKE_Fortran_FLAGS) command. Is this expected behavior? If so, I'll setup a script that runs cmake twice so our developers are good to go out-of-box with our src tree. Thanks, Anthony Ette Systems Engineer Simulation and Modeling Controls and Data Services Inc. Part of the Rolls-Royce Group tel: +1 (317) 230-6943 mob: +1 (317) 864-7975 email: Anthony.R.Ette at controlsdata.com www.controlsdata.com From: Ette, Anthony (CDS) Sent: Monday, June 22, 2015 6:45 PM To: CMake at cmake.org Subject: SET(CMAKE_Fortran_FLAGS) not always taking effect So I am forcing some flags in a high-level CMakeLists.txt for all fortran sources using the subject command. When I invoke via one environment (via python subprocess.popen with modified environment), cmake succeeds and all the build files are generated, however, my flags don't appear in the CMAKE build dir file flags.make. When I launch another environment to build (cmd with modified environment), the build first fails (because my flags weren't thrown), but if I force cmake to run in the cmd env, flags.make then gets updated with my flags and the build succeeds. Can you help me understand this behavior? What triggers cmake to write SET(CMAKE_Fortran_FLAGS) to the flags.make file and why might I not be satisfying it in the first environment? Thanks in advance, Anthony Ette Systems Engineer Simulation and Modeling Controls and Data Services Inc. Part of the Rolls-Royce Group 7661 N Perimeter Rd Indianapolis, IN 46241 tel: +1 (317) 230-6943 mob: +1 (317) 864-7975 email: Anthony.R.Ette at controlsdata.com www.controlsdata.com This e-mail (including attachments) contains contents owned by Rolls-Royce plc and its subsidiaries, affiliated companies or customers and covered by the laws of England and Wales, Brazil, US, or Canada (federal, state or provincial). The information contained in this email is intended to be confidential, may be legally privileged and subject to export controls which may restrict the access to and transfer of the information. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, interception or copying of this communication is strictly prohibited and may subject you to further legal action. Reply to the sender if you received this email by accident, and then delete the email and any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.hoffman at kitware.com Tue Jun 23 13:11:21 2015 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Tue, 23 Jun 2015 13:11:21 -0400 Subject: [CMake] SET(CMAKE_Fortran_FLAGS) not always taking effect In-Reply-To: <2A375B5C08C24643A8A3F8CC2B98C1084BADA944@USINDPR-MBX003.Rolls-Royce.Local> References: <2A375B5C08C24643A8A3F8CC2B98C1084BADA944@USINDPR-MBX003.Rolls-Royce.Local> Message-ID: <55899339.1070700@kitware.com> On 6/22/2015 9:49 PM, Ette, Anthony (CDS) wrote: > Yet more info. How foolish of me to think it?s ok to have to run cmake > twice. I found that the heart of the problem was the use of > ${CMAKE_BINARY_DIR} in LINK_DIRECTORIES for the FORTRAN target in > question (a static library, which other parts of the project depend > on). So I have a CXX project (a subdir in my src tree) that depends on > a fortran static library (also built from a subdir in my src tree). In > this situation, the solution is to not use LINK_DIRECTORIES at all to > point to the FORTRAN target, just specify full path in > TARGET_LINK_DIRECTORIES. I understand that best practice is to always > specify full path in TARGET_LINK_DIRECTORIES, but this can be quite > cumbersome for large, disparate projects. > > Anyway, hope my pain helps someone else. > For any target in CMake you should link to just the target name. add_library(foo foo.c) add_executable(bar bar.c) target_link_library(bar foo) You should not use TARGET_LINK_DIRECTORIES just the target name. -Bill From schroeter at epsitec.ch Wed Jun 24 08:12:58 2015 From: schroeter at epsitec.ch (Mathieu Schroeter) Date: Wed, 24 Jun 2015 14:12:58 +0200 Subject: [CMake] CPack and mswindows MAX_PATH for temporary work In-Reply-To: <557EEB8F.7070106@epsitec.ch> References: <557EEB8F.7070106@epsitec.ch> Message-ID: <558A9ECA.6000400@epsitec.ch> On 15/06/2015 17:13, Mathieu Schroeter wrote: > Is MAX_PATH a problem with CPack? I received the following error when > the destination is longer than MAX_PATH (here, 264 chars): > > CPack Error: Problem copying file: > S:/devel/bootstrap-windev/sysroot/toolchain/var/tmp/wpkg/source/epsitec+lydia/usr/share/epsitec/lydia/cache/data/Lydia.Arc.Components/lydia/electrum-arc/components/forms/options/CheckboxField/CheckboxField.styles.js > -> > S:/devel/bootstrap-windev/sysroot/toolchain/var/tmp/wpkg-8424/build/_CPack_Packages/win64-Source/TGZ/epsitec+lydia_0.1.0.0////usr/share/epsitec/lydia/cache/data/Lydia.Arc.Components/lydia/electrum-arc/components/forms/options/CheckboxField/CheckboxField.styles.js > > > set(CPACK_SOURCE_GENERATOR "TGZ") > set(CPACK_SOURCE_PACKAGE_FILE_NAME "epsitec+lydia_0.1.0.0") > include(CPack) > > > If I reduce the longer, it works fine. I've just looked a bit in the > sources. It seems that it uses UNC paths then I don't understand. > I'm using CMake 3.2.3. Hello, I've fixed this problem with the following patch: --- a/Source/cmSystemTools.cxx Wed Jun 24 13:44:50 2015 +++ b/Source/cmSystemTools.cxx Wed Jun 24 13:45:01 2015 @@ -1949,14 +1949,14 @@ { #if defined(_WIN32) && !defined(__CYGWIN__) cmSystemToolsWindowsHandle hFrom = - CreateFileW(cmsys::Encoding::ToWide(fromFile).c_str(), + CreateFileW(SystemTools::ConvertToWindowsExtendedPath(fromFile).c_str(), GENERIC_READ, FILE_SHARE_READ, 0, OPEN_EXISTING, 0, 0); cmSystemToolsWindowsHandle hTo = - CreateFileW(cmsys::Encoding::ToWide(toFile).c_str(), + CreateFileW(SystemTools::ConvertToWindowsExtendedPath(toFile).c_str(), GENERIC_WRITE, 0, 0, OPEN_EXISTING, 0, 0); if(!hFrom || !hTo) { return false; } FILETIME timeCreation; It's the cmSystemTools::CopyFileTime function where the paths are not converted to UNC. But now I've an other problem: CPack Error: Problem while adding file< S:/devel/bootstrap-windev/sysroot/toolchain/var/tmp/wpkg-7680/build/_CPack_Packages/win64-Source/TGZ/epsitec+lydia_0.1.0.0/usr/share/epsitec/lydia/cache/data/Lydia.Arc.Components/lydia/electrum-arc/components/forms/options/CheckboxField/CheckboxField.styles.js> to archive .ERROR =Error opening "epsitec+lydia_0.1.0.0/usr/share/epsitec/lydia/cache/data/Lydia.Arc.Components/lydia/electrum-arc/components/forms/options/CheckboxField/CheckboxField.styles.js": No such file or directory CPack Error: Problem compressing the directory Err: CPack Error: Error when generating package: Project It seems that there are several MAX_PATH problems with CPack. Regards, Mathieu From dhirvonen at elucideye.com Wed Jun 24 14:18:33 2015 From: dhirvonen at elucideye.com (headupinclouds) Date: Wed, 24 Jun 2015 11:18:33 -0700 (MST) Subject: [CMake] iOS multi-arch library target and xcodebuild In-Reply-To: <20150401165823.GC24598@io.lakedaemon.net> References: <20150401165823.GC24598@io.lakedaemon.net> Message-ID: <1435169913540-7590919.post@n2.nabble.com> Jason, This link ( Building-universal-ios-library ) provides details on creating iOS Universal (multi-arch) builds with CMake. It shows both a manual process and a patched CMake version that will accomplish this for you. I've been using this in combination with the Hunter CMake package manager for Android and iOS universal builds. For convenience, here is a link to the patched CMake version from that page CMake . Note that this will currently build static universal libraries only, but I believe support for dynamic libraries (for use in iOS 8 dynamic frameworks) is currently being added. To build the patched CMake with proper external project behavior, I had to pass it CMAKE_USE_SYSTEM_CURLE=YES. So given your system cmake, you could build it with something like this (with your preferred cmake install prefix): wget https://github.com/ruslo/CMake/archive/v3.2.1-p3.tar.gz tar zxvf v3.2.1-p3.tar.gz cd CMake-3.2.1-p3 cmake -H. -B_builds -DCMAKE_BUILD_TYPE=Release -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_PREFIX=_install -DCMAKE_USE_SYSTEM_CURL=YES David -- View this message in context: http://cmake.3232098.n2.nabble.com/iOS-multi-arch-library-target-and-xcodebuild-tp7590155p7590919.html Sent from the CMake mailing list archive at Nabble.com. From gurenchan at gmail.com Wed Jun 24 14:38:06 2015 From: gurenchan at gmail.com (Owen Alanzo Hogarth) Date: Thu, 25 Jun 2015 02:38:06 +0800 Subject: [CMake] A little help with cmake and external libraries Message-ID: Hi ladies and gentlemen I've just started using cmake a week or so ago but I am having some difficulties getting cmake to find external libraries. I am not new to programming just new to cmake. I am making a very simple project with a structure like this project ...cmakelists.txt project/source ...cmakelists.txt ...main.c project/source/core cmakelists.txt ...source1.h ...source1.c project/source/core/module1 project/source/core/module2 project/source/core/moduleN the main.c will include source1.h, source1.h will include headers from the sub modules as i build them out. The submodule1.h includes external libraries. This is what my main cmakelists looks like CMAKE_MINIMUM_REQUIRED(VERSION 2.6) PROJECT(bluengine) SET(VERSION_MAJOR "0") SET(VERSION_MINOR "1") SET(VERSION_PATCH "0") SET(VERSION "${VERSION_MAJOR}.${VERSION_MINOR}.${VERSION_PATCH}") MESSAGE("Binary tree path ${PROJECT_SOURCE_DIR}") MESSAGE("Version ${VERSION}") ADD_SUBDIRECTORY(source) the source cmake project looks like this: PROJECT(launcher) SET(SRC_FILES main.c) ADD_EXECUTABLE(launcher, "${SRC_FILES}") ADD_SUBDIRECTORY(source) This project starts to build but fails because of the import that's included in main.c I am on a mac and I know where the files are located, the headers are located at /Library/Frameworks/SDL2.framework/Headers but I am unsure how to set this project to go there and find the files. I've read a few tutorials but they don't quite explain this in a way that I can follow. Hoping someone on this mailing list can help me figure this out. Best, Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.hoffman at kitware.com Wed Jun 24 16:03:27 2015 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Wed, 24 Jun 2015 16:03:27 -0400 Subject: [CMake] iOS multi-arch library target and xcodebuild In-Reply-To: <1435169913540-7590919.post@n2.nabble.com> References: <20150401165823.GC24598@io.lakedaemon.net> <1435169913540-7590919.post@n2.nabble.com> Message-ID: <558B0D0F.5010805@kitware.com> What is in the patched CMake? CMake already supports mulit-arch libraries on the Apple platform. On 6/24/2015 2:18 PM, headupinclouds wrote: > Jason, > > This link ( Building-universal-ios-library > ) > provides details on creating iOS Universal (multi-arch) builds with CMake. > It shows both a manual process and a patched CMake version that will > accomplish this for you. I've been using this in combination with the > Hunter CMake package manager for Android > and iOS universal builds. > > For convenience, here is a link to the patched CMake version from that page > CMake . Note that this will currently > build static universal libraries only, but I believe support for dynamic > libraries (for use in iOS 8 dynamic frameworks) is currently being added. > > To build the patched CMake with proper external project behavior, I had to > pass it CMAKE_USE_SYSTEM_CURLE=YES. So given your system cmake, you could > build it with something like this (with your preferred cmake install > prefix): > > wget https://github.com/ruslo/CMake/archive/v3.2.1-p3.tar.gz > tar zxvf v3.2.1-p3.tar.gz > cd CMake-3.2.1-p3 > cmake -H. -B_builds -DCMAKE_BUILD_TYPE=Release -DCMAKE_VERBOSE_MAKEFILE=ON > -DCMAKE_INSTALL_PREFIX=_install -DCMAKE_USE_SYSTEM_CURL=YES > > David > > > > -- > View this message in context: http://cmake.3232098.n2.nabble.com/iOS-multi-arch-library-target-and-xcodebuild-tp7590155p7590919.html > Sent from the CMake mailing list archive at Nabble.com. > -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 bill.hoffman at kitware.com http://www.kitware.com 518 881-4905 (Direct) 518 371-3971 x105 Fax (518) 371-4573 From dhirvonen at elucideye.com Wed Jun 24 17:00:43 2015 From: dhirvonen at elucideye.com (headupinclouds) Date: Wed, 24 Jun 2015 14:00:43 -0700 (MST) Subject: [CMake] iOS multi-arch library target and xcodebuild In-Reply-To: <558B0D0F.5010805@kitware.com> References: <20150401165823.GC24598@io.lakedaemon.net> <1435169913540-7590919.post@n2.nabble.com> <558B0D0F.5010805@kitware.com> Message-ID: The original post was asking for a universal "armv7, arm64, x86_64 (iOS and simulator)" build. I had thought that the iOS simulator x86_64 architecture was not supported in the same FAT library as the arm architectures without the patch, but I could be wrong. Let me know if you think this patch isn't needed and I can test without it. On Wed, Jun 24, 2015 at 1:03 PM, Bill Hoffman [via CMake] < ml-node+s3232098n7590921h56 at n2.nabble.com> wrote: > What is in the patched CMake? CMake already supports mulit-arch > libraries on the Apple platform. > > On 6/24/2015 2:18 PM, headupinclouds wrote: > > > Jason, > > > > This link ( Building-universal-ios-library > > ) > > provides details on creating iOS Universal (multi-arch) builds with > CMake. > > It shows both a manual process and a patched CMake version that will > > accomplish this for you. I've been using this in combination with the > > Hunter CMake package manager for > Android > > and iOS universal builds. > > > > For convenience, here is a link to the patched CMake version from that > page > > CMake . Note that this will > currently > > build static universal libraries only, but I believe support for dynamic > > libraries (for use in iOS 8 dynamic frameworks) is currently being > added. > > > > To build the patched CMake with proper external project behavior, I had > to > > pass it CMAKE_USE_SYSTEM_CURLE=YES. So given your system cmake, you > could > > build it with something like this (with your preferred cmake install > > prefix): > > > > wget https://github.com/ruslo/CMake/archive/v3.2.1-p3.tar.gz > > tar zxvf v3.2.1-p3.tar.gz > > cd CMake-3.2.1-p3 > > cmake -H. -B_builds -DCMAKE_BUILD_TYPE=Release > -DCMAKE_VERBOSE_MAKEFILE=ON > > -DCMAKE_INSTALL_PREFIX=_install -DCMAKE_USE_SYSTEM_CURL=YES > > > > David > > > > > > > > -- > > View this message in context: > http://cmake.3232098.n2.nabble.com/iOS-multi-arch-library-target-and-xcodebuild-tp7590155p7590919.html > > Sent from the CMake mailing list archive at Nabble.com. > > > > > -- > Bill Hoffman > Kitware, Inc. > 28 Corporate Drive > Clifton Park, NY 12065 > [hidden email] > http://www.kitware.com > 518 881-4905 (Direct) > 518 371-3971 x105 > Fax (518) 371-4573 > -- > > 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 > > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > > http://cmake.3232098.n2.nabble.com/iOS-multi-arch-library-target-and-xcodebuild-tp7590155p7590921.html > To unsubscribe from iOS multi-arch library target and xcodebuild, click > here > > . > NAML > > -- View this message in context: http://cmake.3232098.n2.nabble.com/iOS-multi-arch-library-target-and-xcodebuild-tp7590155p7590922.html Sent from the CMake mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ruslan_baratov at yahoo.com Wed Jun 24 17:58:33 2015 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Thu, 25 Jun 2015 00:58:33 +0300 Subject: [CMake] iOS multi-arch library target and xcodebuild In-Reply-To: <558B0D0F.5010805@kitware.com> References: <20150401165823.GC24598@io.lakedaemon.net> <1435169913540-7590919.post@n2.nabble.com> <558B0D0F.5010805@kitware.com> Message-ID: <558B2809.3050900@yahoo.com> On 24-Jun-15 23:03, Bill Hoffman wrote: > What is in the patched CMake? * workaround for bug: http://public.kitware.com/Bug/view.php?id=12506 * installing universal simulator + device library > CMake already supports mulit-arch libraries on the Apple platform. As far as I know you can build two libraries: one for simulator, like [ i386 + x86_64 ] and one ARM, like [ armv7 + armv7s + arm64 ]. Patched CMake version run some extra CMake commands to link them together into [ armv7 + armv7s + arm64 + i386 + x86_64 ] fat library. On 25-Jun-15 00:00, headupinclouds wrote: > I had thought that the iOS simulator x86_64 architecture was not > supported in the same FAT library as the arm architectures without the > patch, but I could be wrong. Exactly From ewmailing at gmail.com Wed Jun 24 19:26:06 2015 From: ewmailing at gmail.com (Eric Wing) Date: Wed, 24 Jun 2015 16:26:06 -0700 Subject: [CMake] iOS multi-arch library target and xcodebuild In-Reply-To: <558B2809.3050900@yahoo.com> References: <20150401165823.GC24598@io.lakedaemon.net> <1435169913540-7590919.post@n2.nabble.com> <558B0D0F.5010805@kitware.com> <558B2809.3050900@yahoo.com> Message-ID: On 6/24/15, Ruslan Baratov via CMake wrote: > On 24-Jun-15 23:03, Bill Hoffman wrote: >> What is in the patched CMake? > * workaround for bug: http://public.kitware.com/Bug/view.php?id=12506 > * installing universal simulator + device library >> CMake already supports mulit-arch libraries on the Apple platform. > As far as I know you can build two libraries: one for simulator, like [ > i386 + x86_64 ] and one ARM, like [ armv7 + armv7s + arm64 ]. Patched > CMake version run some extra CMake commands to link them together into [ > armv7 + armv7s + arm64 + i386 + x86_64 ] fat library. > > On 25-Jun-15 00:00, headupinclouds wrote: >> I had thought that the iOS simulator x86_64 architecture was not >> supported in the same FAT library as the arm architectures without the >> patch, but I could be wrong. > Exactly > -- Ooh. This sounds really interesting. Does this also mean that CMake doesn't need to use an external iOS toolchain anymore? So to clarify, these were some of the problems I have (had?) with CMake on iOS: - Almost all the problems stem from how the SDK root is defined in CMake. - iOS simulator and iOS device use different SDKs and Xcode is supposed to dynamically switch them depending on your current Xcode selection (either in the GUI or command line invocation). - iOS treats these as separate SDKs with completely different paths for both inputs (e.g. headers, dynamic libraries, etc), and outputs (build products) - iOS doesn't combine simulator and device binaries into fat binaries and instead opts for two completely different paths for everything. This has created extraordinary pain for 3rd party middleware developers or people wanting to use pre-built frameworks. Apple has done pretty much nothing to make this situation bearable. - As such, developers make their own fat binaries by manually combining the device and simulator binaries together with lipo. - Apple engineers have warned not to do that. However, their lack of providing any other reasonable solution after 7 years just makes them seem obstinate. (I suspect they want to keep room open for a mythical x86 iOS device, and refuse to solve our real problems of today.) - The new iOS framework feature throws another monkey wrench for the manual lipo workaround because in building the final app, the framework gets bundled as-is, with all the architectures in place. Without manual intervention, you will attempt to ship an iOS app to the store that contains simulator binaries and will likely be rejected. (There was a recent mailing list thread asking how to solve this...no good solution was found.) - Anyway, CMake has trouble with singular SDK root. - FIND_LIBRARY is problematic for system frameworks because the path needs to change depending on device or simulator. My workaround is to manually write "-framework Foo" instead of using FIND_LIBRARY for Apple system frameworks. (I can continue to use FIND_LIBRARY for 3rd party frameworks, but must make sure they are fat.) - I believe I had to tweak my toolchain to write values that matched Xcode more closely, otherwise switching between device and simulator wouldn't work. - Because Xcode/xcodebuild put products in different directories for device vs simulator, I end up manually running standalone shell scripts to find these products and lipo them. - I would like to be able to write shell scripts that get run as part of Xcode's built-in shell-script phase because certain useful Xcode environmental variables are set/available when you do that. But CMake doesn't have a mechanism to do this as far as I know, so I have to hard code things that are variable by Xcode and subject to change. Then there are other CMake problems not directly related to this, such as switching codesigning keys, invoking the Archive feature (kind of needed for deploying), setting entitlements, and still clumsy areas where the CMake generated Xcode UI is missing stuff from a normal Xcode project. (Setting things like entitlements, Game Center stuff, orientation settings, and just being able to quick add a framework for experimentation.) And many of these are problems for Mac too now. Thanks, Eric From julien.jomier at kitware.com Thu Jun 25 03:32:53 2015 From: julien.jomier at kitware.com (Julien Jomier) Date: Thu, 25 Jun 2015 09:32:53 +0200 Subject: [CMake] ANN: CMake Course - Sept 7 in Lyon, France In-Reply-To: <5534C5BF.2020605@kitware.com> References: <53BD4650.6070909@kitware.com> <5534C5BF.2020605@kitware.com> Message-ID: <558BAEA5.4090509@kitware.com> Kitware will be holding a CMake training course on September 7, 2015 at Kitware's office in Lyon, France. This one-day course will cover CMake, CTest, CPack and CDash. Visit our website for more information and registration details (early registration and student discounts available): http://training.kitware.fr/browse/80 Note that the course will be taught in English. If you have any questions, please contact me directly or training at kitware.fr. We are looking forward to seeing you in Lyon, Julien -- Kitware SAS 26 rue Louis Gu?rin 69100 Villeurbanne, France http://www.kitware.eu From ruslan_baratov at yahoo.com Thu Jun 25 04:29:12 2015 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Thu, 25 Jun 2015 11:29:12 +0300 Subject: [CMake] iOS multi-arch library target and xcodebuild In-Reply-To: References: <20150401165823.GC24598@io.lakedaemon.net> <1435169913540-7590919.post@n2.nabble.com> <558B0D0F.5010805@kitware.com> <558B2809.3050900@yahoo.com> Message-ID: <558BBBD8.7040505@yahoo.com> On 25-Jun-15 02:26, Eric Wing wrote: > On 6/24/15, Ruslan Baratov via CMake wrote: >> On 24-Jun-15 23:03, Bill Hoffman wrote: >>> What is in the patched CMake? >> * workaround for bug: http://public.kitware.com/Bug/view.php?id=12506 >> * installing universal simulator + device library >>> CMake already supports mulit-arch libraries on the Apple platform. >> As far as I know you can build two libraries: one for simulator, like [ >> i386 + x86_64 ] and one ARM, like [ armv7 + armv7s + arm64 ]. Patched >> CMake version run some extra CMake commands to link them together into [ >> armv7 + armv7s + arm64 + i386 + x86_64 ] fat library. >> >> On 25-Jun-15 00:00, headupinclouds wrote: >>> I had thought that the iOS simulator x86_64 architecture was not >>> supported in the same FAT library as the arm architectures without the >>> patch, but I could be wrong. >> Exactly >> -- > Ooh. This sounds really interesting. Does this also mean that CMake > doesn't need to use an external iOS toolchain anymore? > > So to clarify, these were some of the problems I have (had?) with CMake on iOS: > > - Almost all the problems stem from how the SDK root is defined in CMake. > > - iOS simulator and iOS device use different SDKs and Xcode is > supposed to dynamically switch them depending on your current Xcode > selection (either in the GUI or command line invocation). > > - iOS treats these as separate SDKs with completely different paths > for both inputs (e.g. headers, dynamic libraries, etc), and outputs > (build products) > > - iOS doesn't combine simulator and device binaries into fat binaries > and instead opts for two completely different paths for everything. > This has created extraordinary pain for 3rd party middleware > developers or people wanting to use pre-built frameworks. Apple has > done pretty much nothing to make this situation bearable. > > - As such, developers make their own fat binaries by manually > combining the device and simulator binaries together with lipo. > > - Apple engineers have warned not to do that. However, their lack of > providing any other reasonable solution after 7 years just makes them > seem obstinate. (I suspect they want to keep room open for a mythical > x86 iOS device, and refuse to solve our real problems of today.) > > - The new iOS framework feature throws another monkey wrench for the > manual lipo workaround because in building the final app, the > framework gets bundled as-is, with all the architectures in place. > Without manual intervention, you will attempt to ship an iOS app to > the store that contains simulator binaries and will likely be > rejected. (There was a recent mailing list thread asking how to solve > this...no good solution was found.) > > > > - Anyway, CMake has trouble with singular SDK root. > > - FIND_LIBRARY is problematic for system frameworks because the path > needs to change depending on device or simulator. My workaround is to > manually write "-framework Foo" instead of using FIND_LIBRARY for > Apple system frameworks. (I can continue to use FIND_LIBRARY for 3rd > party frameworks, but must make sure they are fat.) > > - I believe I had to tweak my toolchain to write values that matched > Xcode more closely, otherwise switching between device and simulator > wouldn't work. > > - Because Xcode/xcodebuild put products in different directories for > device vs simulator, I end up manually running standalone shell > scripts to find these products and lipo them. > > - I would like to be able to write shell scripts that get run as part > of Xcode's built-in shell-script phase because certain useful Xcode > environmental variables are set/available when you do that. But CMake > doesn't have a mechanism to do this as far as I know, so I have to > hard code things that are variable by Xcode and subject to change. > > > Then there are other CMake problems not directly related to this, such > as switching codesigning keys, invoking the Archive feature (kind of > needed for deploying), setting entitlements, and still clumsy areas > where the CMake generated Xcode UI is missing stuff from a normal > Xcode project. (Setting things like entitlements, Game Center stuff, > orientation settings, and just being able to quick add a framework for > experimentation.) And many of these are problems for Mac too now. > > Thanks, > Eric tl;dr Everything works fine. This project https://github.com/ruslo/weather uploaded to AppStore without problems: https://itunes.apple.com/us/app/weather-with-hunter/id885350236 * iOS toolchains I'm using: https://github.com/ruslo/polly (used to switch between different SDKs + to add some flags, like -std=c++11) * Hunter install 5-arch 3rd party fat libraries so I can run simulator/device in single Xcode instance * when I run "Archive" for preparing my application for uploading to AppStore Xcode uses only device architectures. Just set "Build Active Architecture Only" to NO and universal application for device will be built * I see no point of using frameworks for managing 3rd parties. Plain `/include` and `/lib` layout works for iOS (and for all others platforms like MSVC, MinGW, ...) * toolchain used to switch between different SDK's. You just need to set environment variable IOS_X_Y_DEVELOPER_DIR. See https://github.com/ruslo/polly/wiki/Toolchain-list#ios * Hunter automatically set CMAKE_PREFIX_PATH and _ROOT to the root directory of 3rd party libraries so `find_package` works fine Since you've touched too many aspects I may miss something. Let me know if I've not covered some important stuff. From ewmailing at gmail.com Thu Jun 25 05:14:40 2015 From: ewmailing at gmail.com (Eric Wing) Date: Thu, 25 Jun 2015 02:14:40 -0700 Subject: [CMake] iOS multi-arch library target and xcodebuild In-Reply-To: <558BBBD8.7040505@yahoo.com> References: <20150401165823.GC24598@io.lakedaemon.net> <1435169913540-7590919.post@n2.nabble.com> <558B0D0F.5010805@kitware.com> <558B2809.3050900@yahoo.com> <558BBBD8.7040505@yahoo.com> Message-ID: > * iOS toolchains I'm using: https://github.com/ruslo/polly (used to > switch between different SDKs + to add some flags, like -std=c++11) Do you have to use a different toolchain for every different variant and different OS version? That's rather unfortunate if so. My current tweaks don't require this. > * when I run "Archive" for preparing my application for uploading to > AppStore Xcode uses only device architectures. Just set "Build Active > Architecture Only" to NO and universal application for device will be built I think I saw this mentioned elsewhere and am employing that. Still, I'm a little concerned this might be a hack that is working around a more underlying problem that could break. > * I see no point of using frameworks for managing 3rd parties. Plain > `/include` and `/lib` layout works for iOS (and for all > others platforms like MSVC, MinGW, ...) Frameworks vs. dylibs isn't the issue at all here and completely misses the point. The point is the way FIND_LIBRARIES anchors absolute paths to everything. This won't work with SYSTEM framewoks because the paths dynamically change depending on device or simulator. 3rd party fat binaries installed in a single location regardless of frameworks or dylibs. This is annoying because you must remember whether you are dealing with a system provided library or a third party library in the way you write your CMake files now. A disgression: my understanding is that for iOS, officially for 3rd party dynamic libraries, only frameworks and not dylibs are supported. > * Hunter automatically set CMAKE_PREFIX_PATH and _ROOT to the > root directory of 3rd party libraries so `find_package` works fine Okay, I think I've done something similar by setting the CMAKE_ROOT_PATH to look in the CMAKE_PREFIX_PATH, CMAKE_LIBRARY_PATH, CMAKE_INCLUDE_PATH. I needed this for Android's NDK Module system convention too. > * toolchain used to switch between different SDK's. You just need to set > environment variable IOS_X_Y_DEVELOPER_DIR. See > https://github.com/ruslo/polly/wiki/Toolchain-list#ios Okay, I think my tweaks have done better than this. I don't need to set any environmental variable changes. I can use the built-in Xcode UI to switch between SDKs and my tweaks are mostly agnostic to which iOS SDK version you have. (It always detects the default installed.) My concerns are not merely one-shot automation builds. I do manual, every day development in Xcode and expect/follow a mostly natural Xcode developer work flow and other developers on the platform expect the same. Being able to switch between simulator and device without a roundtrip CMake generation is extremely useful (and expected), along with being able to test the different architecture variants (32-bit, 64-bit). I plan to do a write up of some kind to show my workflow and present my tweaks I made to try to improve things for all the platforms I work on to make the every day workflows more natural for each respective platform. But I do suspect the fat device/simulator binary build patch would be very useful to have. Thanks, Eric From ruslan_baratov at yahoo.com Thu Jun 25 07:30:13 2015 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Thu, 25 Jun 2015 14:30:13 +0300 Subject: [CMake] iOS multi-arch library target and xcodebuild In-Reply-To: References: <20150401165823.GC24598@io.lakedaemon.net> <1435169913540-7590919.post@n2.nabble.com> <558B0D0F.5010805@kitware.com> <558B2809.3050900@yahoo.com> <558BBBD8.7040505@yahoo.com> Message-ID: <558BE645.5080304@yahoo.com> On 25-Jun-15 12:14, Eric Wing wrote: >> * iOS toolchains I'm using: https://github.com/ruslo/polly (used to >> switch between different SDKs + to add some flags, like -std=c++11) > Do you have to use a different toolchain for every different variant > and different OS version? That's rather unfortunate if so. My current > tweaks don't require this. Can you clarify what you mean by "different variant"? Yes different OS - different toolchain. So what is the alternative? I think '--toolchain ios-8-2' is shorter than '-DCMAKE_TOOLCHAIN_FILE=/path/to/iOS.cmake -DIOS_OS_VERSION=8.2 -B_builds/ios-8-2'. > >> * when I run "Archive" for preparing my application for uploading to >> AppStore Xcode uses only device architectures. Just set "Build Active >> Architecture Only" to NO and universal application for device will be built > I think I saw this mentioned elsewhere and am employing that. Still, > I'm a little concerned this might be a hack that is working around a > more underlying problem that could break. ... > >> * I see no point of using frameworks for managing 3rd parties. Plain >> `/include` and `/lib` layout works for iOS (and for all >> others platforms like MSVC, MinGW, ...) > Frameworks vs. dylibs isn't the issue at all here and completely > misses the point. The point is the way FIND_LIBRARIES anchors absolute > paths to everything. This won't work with SYSTEM framewoks because the > paths dynamically change depending on device or simulator. 3rd party > fat binaries installed in a single location regardless of frameworks > or dylibs. This is annoying because you must remember whether you are > dealing with a system provided library or a third party library in the > way you write your CMake files now. I guess it's a general problem, not just about iOS. To avoid absolute paths problem you need to use `find_package(... CONFIG` and add @rpath to RPATH. See this overview: https://github.com/ruslo/hunter/wiki/example.find_package.config#relocation-challenge > > A disgression: my understanding is that for iOS, officially for 3rd > party dynamic libraries, only frameworks and not dylibs are supported. Well Xcode is not "officially" CMake-friendly and CMake do not "officially" support iOS. We are just sharing some solutions that *really* works. > > > >> * Hunter automatically set CMAKE_PREFIX_PATH and _ROOT to the >> root directory of 3rd party libraries so `find_package` works fine > Okay, I think I've done something similar by setting the > CMAKE_ROOT_PATH to look in the CMAKE_PREFIX_PATH, CMAKE_LIBRARY_PATH, > CMAKE_INCLUDE_PATH. I needed this for Android's NDK Module system > convention too. This works for Android too. > > > >> * toolchain used to switch between different SDK's. You just need to set >> environment variable IOS_X_Y_DEVELOPER_DIR. See >> https://github.com/ruslo/polly/wiki/Toolchain-list#ios > Okay, I think my tweaks have done better than this. I don't need to > set any environmental variable changes. I can use the built-in Xcode > UI to switch between SDKs and my tweaks are mostly agnostic to which > iOS SDK version you have. (It always detects the default installed.) IOS_X_Y_DEVELOPER_DIR can point to different Xcode locations. I guess you use xcode-select to set current Xcode and then you use SDKs available from `xcodebuild -showsdks` (?) It's not hard to add such feature. My current workflow: just set new IOS_X_Y_DEVELOPER_DIR environment variable to .bashrc when new Xcode available. I can use all Xcodes I have in such way. Also it's possible to add default one. Actually there was simple `ios` toolchain in collection that works such way. I've removed it because I think it's quite convenient to use version explicitly because it not break things "suddenly" because you install new Xcode or add new SDK. > My concerns are not merely one-shot automation builds. I do manual, > every day development in Xcode and expect/follow a mostly natural > Xcode developer work flow and other developers on the platform expect > the same. Being able to switch between simulator and device without a > roundtrip CMake generation is extremely useful (and expected), along > with being able to test the different architecture variants (32-bit, > 64-bit). I guess it's not related to SDK's switching. As I mentioned earlier you can use one Xcode instance to run device/simulator for all available architectures. > > > I plan to do a write up of some kind to show my workflow and present > my tweaks I made to try to improve things for all the platforms I work > on to make the every day workflows more natural for each respective > platform. > > > But I do suspect the fat device/simulator binary build patch would be > very useful to have. > > Thanks, > Eric From ramey at rrsd.com Thu Jun 25 10:44:40 2015 From: ramey at rrsd.com (Robert Ramey) Date: Thu, 25 Jun 2015 07:44:40 -0700 Subject: [CMake] CDash problems Message-ID: I set up a project on the cdash.org website. When I invoke the "experimental" target it runs the tests and uploads the results to cdash.org. So far so good. In my github project and documentation I've encouraged uses of this project to use CMake to build it and test it and run the "experimental" target so that their test results will also appear on the cdash dashboard. But when someone other than myself tries to do this, I get an emal from admin at cdhash.org which says: Object: Cannot create handler based on XML content An XML submission from 42.156.137.83 to the project Safe Numerics cannot be parsed. The content of the file is as follow: -CDash on my.cdash.org What do I have to do to find out the problem and fix this? The project is "Safe Numerics" http://my.cdash.org/index.php?project=Safe+Numerics Robert Ramey From DLRdave at aol.com Thu Jun 25 12:16:11 2015 From: DLRdave at aol.com (David Cole) Date: Thu, 25 Jun 2015 12:16:11 -0400 Subject: [CMake] CDash problems In-Reply-To: References: Message-ID: I cloned your project [Safe Numerics](https://github.com/robertramey/safe_numerics) to try to help you out by attempting to reproduce this problem. I see the most recent activity is in the "policies" branch, but I don't see anything in the whole repo, in either 'master' or 'policies' branches that refer to how to build it via CMake, or how to attempt to submit a CDash build... I browsed through the html docs and did a 'git grep -i experimental' to no avail. Do you have build instructions? Should I just configure using the "CMake/CMakeLists.txt" file and then try to build the Experimental target? Will it build ok on Windows with VS 2013, or Ninja plus that compiler? Thx, David C. On Thu, Jun 25, 2015 at 10:44 AM, Robert Ramey wrote: > I set up a project on the cdash.org website. > > When I invoke the "experimental" target it runs the tests and uploads the > results to cdash.org. So far so good. In my github project and > documentation I've encouraged uses of this project to use CMake to build it > and test it and run the "experimental" target so that their test results > will also appear on the cdash dashboard. But when someone other than myself > tries to do this, I get an emal from admin at cdhash.org which says: > > Object: Cannot create handler based on XML content > An XML submission from 42.156.137.83 to the project Safe Numerics cannot be > parsed. The content of the file is as follow: > > -CDash on my.cdash.org > > What do I have to do to find out the problem and fix this? > > The project is "Safe Numerics" > > http://my.cdash.org/index.php?project=Safe+Numerics > > > Robert Ramey > > -- > > 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 fifteenknots505 at gmail.com Thu Jun 25 13:32:58 2015 From: fifteenknots505 at gmail.com (Martin Weber) Date: Thu, 25 Jun 2015 19:32:58 +0200 Subject: [CMake] Automatic management of Eclipse projects In-Reply-To: <18548708.16138099.1434988921742.JavaMail.zimbra@inria.fr> References: <18548708.16138099.1434988921742.JavaMail.zimbra@inria.fr> Message-ID: <2306179.K8VaNrY1xA@linux> Am Montag, 22. Juni 2015, 18:02:01 schrieb Cedric Doucet: > Hello, > > I am testing the possibility of generating Eclipse projects with CMake. If you want to generate the from teh Eclipse workbench and are familiar with CDT, try this >https://marketplace.eclipse.org/content/cmake4eclipse> -- Cd wrttn wtht vwls s mch trsr. From gurenchan at gmail.com Thu Jun 25 15:03:40 2015 From: gurenchan at gmail.com (Owen Alanzo Hogarth) Date: Fri, 26 Jun 2015 03:03:40 +0800 Subject: [CMake] A little help please? Message-ID: I wrote this post on SO and hoping to get some help sorting this out. Please help with this build setup and linking. http://stackoverflow.com/questions/31058688/cmake-not-properly-linking-files-after-successful-build -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrick.griffiths at gmail.com Thu Jun 25 16:43:43 2015 From: patrick.griffiths at gmail.com (Patrick Griffiths) Date: Thu, 25 Jun 2015 14:43:43 -0600 Subject: [CMake] Using generator expressions with set_target_properties Message-ID: I'm trying to add the /PDBSTRIPPED option LINK_FLAGS_RELWITHDEBINFO config (Visual Studio generator, obviously): set_target_properties(target PROPERTIES LINK_FLAGS_RELWITHDEBINFO "/PDBSTRIPPED:$/stripped/$.pdb") Unfortunately the generator expressions aren't being expanded. Any suggestions on how I might accomplish this in a reasonable way? Thanks Patrick -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.wirtz at simtech.uni-stuttgart.de Fri Jun 26 03:53:31 2015 From: daniel.wirtz at simtech.uni-stuttgart.de (Daniel Wirtz) Date: Fri, 26 Jun 2015 09:53:31 +0200 Subject: [CMake] Long command lines Message-ID: <558D04FB.20205@simtech.uni-stuttgart.de> Hey all, i've recently run into a problem (both windows/mingw and unix/intel) where the cmake-generated build files create too long command lines that break the overall build. more precisely, the build system uses architecture paths etc and hence there are long include directories for many packages; e.g. the fortran preprocessor from intel (in the version we have, cant be upgraded) only allows 4K command lines :-( are there any setting in cmake that could help with that? does anyone have experience with that? thanks! -- Dr. Daniel Wirtz Dipl. Math. Dipl. Inf. SRC SimTech Pfaffenwaldring 5a +49 711 685 60044 From michael.stuermer at schaeffler.com Fri Jun 26 10:47:14 2015 From: michael.stuermer at schaeffler.com (Stuermer, Michael SP/HZA-ZSEP) Date: Fri, 26 Jun 2015 14:47:14 +0000 Subject: [CMake] C# support? Message-ID: <4797EDAAB4843944A70CA99A7DE7D8BD0400AAC9@DE012432.schaeffler.com> Hi and sorry for cross-posting this on both lists, I checked the mailing list history about the C#/.NET support topic and realized that the interest in C# support seems to have declined a bit. I am right now in the need of good C# support and adding external project files is not that much of an option to me. So I started hacking away everything that is needed for .csproj generation and support of mixed managed/unmanaged targets. Not yet done, but there is a light at the end of the tunnel. Now the question: is there any real interest at all in this feature? Does it have a realistic chance to be accepted for upstream or will I have to maintain my own fork of CMake? best regards, Michael St?rmer From JamesJ at motionview3d.com Fri Jun 26 12:16:06 2015 From: JamesJ at motionview3d.com (James Johnston) Date: Fri, 26 Jun 2015 16:16:06 -0000 Subject: [CMake] C# support? In-Reply-To: <4797EDAAB4843944A70CA99A7DE7D8BD0400AAC9@DE012432.schaeffler.com> References: <4797EDAAB4843944A70CA99A7DE7D8BD0400AAC9@DE012432.schaeffler.com> Message-ID: <168401d0b02b$68533430$38f99c90$@motionview3d.com> > -----Original Message----- > From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Stuermer, > Michael SP/HZA-ZSEP > Sent: Friday, June 26, 2015 14:47 > To: cmake-developers at cmake.org; cmake at cmake.org > Subject: [CMake] C# support? > > Hi and sorry for cross-posting this on both lists, > > I checked the mailing list history about the C#/.NET support topic and realized > that the interest in C# support seems to have declined a bit. > > I am right now in the need of good C# support and adding external project > files is not that much of an option to me. So I started hacking away > everything that is needed for .csproj generation and support of mixed > managed/unmanaged targets. Not yet done, but there is a light at the end of > the tunnel. > > Now the question: is there any real interest at all in this feature? Does it have > a realistic chance to be accepted for upstream or will I have to maintain my > own fork of CMake? > Well, I have only just recently started using CMake. So I am not speaking from a great deal of experience. But I am currently converting over a bunch of stuff into a set of CMake projects. (must be multiple CMake projects built by a superbuild via ExternalProject because we use three different C/C++ compilers and target three different CPU architectures.) Part of that "stuff" involves a mixture of Visual Studio projects involving (1) 100% unmanaged C++ code: this is the easy stuff to move to CMake, (2) C++/CLI mixed mode projects, (3) C# projects that consume the mixed mode C++/CLI projects. I have yet to start working on that part of the CMake migration, but I'm not looking forward to figuring out how to make the C# projects consume the build output from the C++/CLI projects and still have the Visual C# projects be easy to add/remove files from. All these particular projects are targeting Visual Studio 2008 32-bit, so it *ought* be possible to use them all from one single CMake build tree & one single Visual Studio solution... I have seen include_external_msproject CMake command: http://www.cmake.org/cmake/help/v3.3/command/include_external_msproject.html But it's not clear to me how I'd make the C# project depend on other CMake targets (i.e. the mixed mode C++ projects). The best I've thought of would be to use configure_file to modify the project to substitute the compiled C++ DLLs in the references section of the project. But then it will be a pain to modify the original C# projects in SOURCE_DIR. And also, the C# project normally has relative paths, so if it gets configure_file'd into BINARY_DIR all the source code paths will break. I guess all the above is to say, I'm interested in that feature. But I may be too much of a newbie at CMake to say whether that is a good "CMake way" of doing things. I still need to experiment with the above command, and read up on old mailing list messages on the subject. But it seems to me the logical way for supporting C# would be: (1) it becomes a first-class language that can be mentioned in the project() command, (2) therefore, all the generators can use it, so you aren't restricted to Visual Studio generator (I like the Ninja generator because it's faster than Visual Studio), (3) Visual Studio generator would emit a solution containing generated VC++/VC# projects. Anything else feels like a bit of a hack to me. But #1 thru #3 sounds like a lot of work though... Also, C# doesn't compile to object files - does CMake currently support the concept of a language that doesn't require separate compiling/linking steps? Best regards, James Johnston From robert.maynard at kitware.com Fri Jun 26 14:35:39 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 26 Jun 2015 14:35:39 -0400 Subject: [CMake] [ANNOUNCE] CMake 3.3.0-rc3 is now ready! Message-ID: I am proud to announce the third CMake 3.3 release candidate. Sources and binaries are available at: http://www.cmake.org/download/ Documentation is available at: http://www.cmake.org/cmake/help/v3.3 Release notes appear below and are also published at http://www.cmake.org/cmake/help/v3.3/release/3.3.html Some of the more significant features of CMake 3.3 are: * The "if()" command learned a new "IN_LIST" operator that evaluates to true if a given element is contained in a named list. * The "add_dependencies()" command learned to allow dependencies to be added to *interface libraries*. Dependencies added to an interface library are followed transitively in its place since the target itself does not build. * The "find_library()", "find_path()", and "find_file()" commands now search in installation prefixes derived from the "PATH" environment variable. * The "_VISIBILITY_PRESET" and "VISIBILITY_INLINES_HIDDEN" target properties now affect compilation in sources of all target types. See policy "CMP0063". * A "_INCLUDE_WHAT_YOU_USE" target property and supporting "CMAKE__INCLUDE_WHAT_YOU_USE" variable were introduced to tell the *Makefile Generators* and the "Ninja" generator to run "include- what-you-use" along with the compiler for "C" and "CXX" languages. Deprecated and Removed Features: * The "ctest_build()" and "build_command()" commands no longer tell "make" tools to ignore errors with the "-i" option. Previously this was done for *Makefile Generators* but not others. See policy "CMP0061". * The "Visual Studio 7" generator (.NET 2002) is now deprecated and will be removed in a future version of CMake. * The "Visual Studio 6" generator is now deprecated and will be removed in a future version of CMake. * The "add_definitions()" command no longer causes a "DEFINITIONS" directory property to be populated. See policy "CMP0059". CMake 3.3 Release Notes *********************** Changes made since CMake 3.2 include the following. New Features ============ Generators ---------- * The *Makefile Generators* now add ".DELETE_ON_ERROR" to the makefiles that contain the actual build rules for files on disk. This tells GNU make to remove rule outputs when their recipe modifies an output but fails. * The *Visual Studio Generators* learned to support ".xaml" source files and automatically associate them with corresponding ".h" and ".cpp" sources. * A new experimental "Green Hills MULTI" generator was added on Windows. Green Hills MULTI is an IDE for embedded real-time systems. Commands -------- * The "add_dependencies()" command learned to allow dependencies to be added to *interface libraries*. Dependencies added to an interface library are followed transitively in its place since the target itself does not build. * The "execute_process()" command learned to support specifying the same file for "OUTPUT_FILE" and "ERROR_FILE". * The "file(GLOB)" and "file(GLOB_RECURSE)" commands learned a new "LIST_DIRECTORIES " option to specify whether the glob result should include directories. * The "find_library()", "find_path()", and "find_file()" commands now search in installation prefixes derived from the "PATH" environment variable. * The "if()" command learned a new "IN_LIST" operator that evaluates to true if a given element is contained in a named list. * The "install(EXPORT)" and "export()" commands learned to export targets that populate the "INTERFACE_SOURCES" target property. * The "install(TARGETS)" command learned to support generator expressions in the "DESTINATION" value. Variables --------- * The version of some Fortran compilers is now detected and stored in the "CMAKE_Fortran_COMPILER_VERSION" variable. * The *Visual Studio Generators* learned a new "CMAKE_VS_INCLUDE_INSTALL_TO_DEFAULT_BUILD" option to put the "INSTALL" target in the default build of a solution (".sln") file. Properties ---------- * A "CROSSCOMPILING_EMULATOR" target property and supporting "CMAKE_CROSSCOMPILING_EMULATOR" variable were introduced to allow target platform binaries to run on the host during cross compiling. * A "_INCLUDE_WHAT_YOU_USE" target property and supporting "CMAKE__INCLUDE_WHAT_YOU_USE" variable were introduced to tell the *Makefile Generators* and the "Ninja" generator to run "include- what-you-use" along with the compiler for "C" and "CXX" languages. * The "_VISIBILITY_PRESET" and "VISIBILITY_INLINES_HIDDEN" target properties now affect compilation in sources of all target types. See policy "CMP0063". * The "XCODE_ATTRIBUTE_" target property learned to support generator expressions. Modules ------- * The "CheckFortranCompilerFlag" module was introduced to check "Fortran" compiler flags, much like the "CheckCCompilerFlag" module already does for "C". * The "ExternalData" module learned a new "ExternalData_NO_SYMLINKS" option to disable use of symbolic links to populate the real data files and use copies instead. * The "ExternalData" module learned a new "RECURSE:" option in "DATA{}" references specifying directories. This allows an entire directory tree of associated files to be matched. * The "ExternalData" module learned a new URL template placeholder "%(algo:)" to allow custom mapping from algorithm name to URL component through configuration of new "ExternalData_URL_ALGO__" variables. This allows more flexibility in remote URLs. * The "ExternalProject" module learned to replace tokens like "" in the "BYPRODUCTS" of each step. * The "ExternalProject" module APIs learned to support "generator expressions" when using "LOG_*" options and in CMake initial cache options. * The "FindBoost" module now tracks the directories containing libraries separately for RELEASE and DEBUG configurations. * The "FindCUDA" module now defaults to using the static CUDA runtime library if it is available. A new "CUDA_USE_STATIC_CUDA_RUNTIME" option is offered to control this behavior. * The "FindMatlab" module was completely rewritten. It learned about versions and components and to find Matlab in a more precise and multiplatform way. The module now offers APIs to create mex extensions, documentation, and unit tests. * The "FindPackageHandleStandardArgs" module "FIND_PACKAGE_HANDLE_STANDARD_ARGS" function now always populates both the "_FOUND" and "_FOUND" variables (the latter for backwards compatibility). The "FOUND_VAR" option is now ignored except to enforce its allowed values. * The "InstallRequiredSystemLibraries" module learned a new "CMAKE_INSTALL_SYSTEM_RUNTIME_COMPONENT" option to specify the installation component. Generator Expressions --------------------- * A new "COMPILE_LANGUAGE" generator expression was introduced to allow specification of compile options for target files based on the "LANGUAGE" of each source file. Due to limitations of the underlying native build tools, this feature has varying support across generators. See the "cmake-generator-expressions(7)" manual for details. CTest ----- * The "ctest(1)" tool learned a new "--repeat-until-fail " option to help find sporadic test failures. * The "CTestCoverageCollectGCOV" module learned to support the same "CTEST_CUSTOM_COVERAGE_EXCLUDE" option as the "ctest_coverage()" command. CPack ----- * The "cpack(1)" "IFW" generator and the "CPackIFW" module learned to support Qt Framework Installer 2.0 tools. * The "CPackDeb" module learned a new "CPACK_DEBIAN__PACKAGE_SHLIBDEPS" variable to specify per-component use of "dpkg-shlibdeps". * The "CPackDeb" module learned a new "CPACK_DEBIAN__PACKAGE_DEPENDS" option to specify per- component dependencies. * The "CPackRPM" module learned to package symbolic links more cleanly and now supports directory symlinks with recent "rpmbuild" versions. * The "CPackRPM" module learned a new "CPACK_RPM_ADDITIONAL_MAN_DIRS" variable to specify directories containing man pages for the brp- compress RPM macro. * The "CPackRPM" module learned a new "CPACK_RPM__PACKAGE_ARCHITECTURE" variable to specify a component-specific package architecture. * The CPack WIX generator learned the new "CPACK_START_MENU_SHORTCUTS", "CPACK_DESKTOP_SHORTCUTS" and "CPACK_STARTUP_SHORTCUTS" installed file properties which can be used to install shorcuts in the Start Menu, on the Desktop and in the Startup Folder respectively. Other ----- * The "Compile Features" functionality is now aware of features supported by GNU compilers on Windows, versions 4.4 through 5.0. * The "cmake(1)" "-E tar" command learned a new "--format" option to specify the archive format to be written. * On OS X, CMake learned to create XCTest bundles to test Frameworks and App Bundles within Xcode. The "FindXCTest" module provides convenience functions to handle "XCTEST" bundles. Deprecated and Removed Features =============================== * On OS X the "cmake-gui(1)" no longer has the "Install For Command Line Use" menu item. Instead there is a "How to Install For Command Line Use" menu item that shows an informational dialog box explaining how to make the command line tools available. For example: /Applications/CMake.app/Contents/bin/cmake-gui --install * The "ctest_build()" and "build_command()" commands no longer tell "make" tools to ignore errors with the "-i" option. Previously this was done for *Makefile Generators* but not others. See policy "CMP0061". * The "Visual Studio 10 2010" generator no longer checks for running VS IDEs with the project open or asks them to reload. This was originally done for VS 10 because it had been done for VS 7 through 9 to avoid prompting for every project in a solution. Since VS >= 10 allow the whole solution to reload at once they do not need CMake to help them. * The "Visual Studio 7" generator (.NET 2002) is now deprecated and will be removed in a future version of CMake. * The "Visual Studio 6" generator is now deprecated and will be removed in a future version of CMake. * The "find_package()" command no longer considers project build trees recently configured in a "cmake-gui(1)". This was previously done only on Windows and is now never done. The "NO_CMAKE_BUILDS_PATH" option is now ignored if given and effectively always on. Projects may populate the *User Package Registry* to aid users building multiple dependent projects one after another. * The "add_definitions()" command no longer causes a "DEFINITIONS" directory property to be populated. See policy "CMP0059". * With Visual Studio 7, 8, and 9 generators the value of the "$(OutDir)" placeholder no longer evaluates to the configuration name. Projects should use "$(ConfigurationName)" for that instead. * Using the output of "export()" with the "install(FILES)" command is no longer allowed. See policy "CMP0062" for details. Other Changes ============= * The "Ninja" generator now requires that calls to the "add_custom_command()" and "add_custom_target()" commands use the "BYPRODUCTS" option to explicitly specify any files generated by the custom commands that are not listed as outputs (perhaps because their timestamps are allowed to be older than the inputs). See policy "CMP0058". * Build-time progress output of *Makefile Generators* has been improved. It no longer mixes progress and build rule messages during parallel builds. The link rule messages now have progress and are displayed as bold green instead of bold red (since red is often associated with an error message). * The "CMAKE_CFG_INTDIR" variable value for Visual Studio 7, 8, and 9 is now "$(ConfigurationName)" instead of "$(OutDir)". This should have no effect on the intended use cases of the variable. * Linking to library files by a full path in an implicit linker search directory (e.g. "/usr/lib/libfoo.a") no longer asks the linker to search for the library (e.g. "-lfoo") and now links by full path. See policy "CMP0060". ------------------------------------------------------------------- Changes made since CMake 3.3.0-rc2: Brad King (7): Help: Fix typo in CMAKE_GENERATOR_PLATFORM docs (#15621) Fix assertion failure on unmatched function or macro cmake-gui: Change --install to use /usr/local/bin by default (#15627) cmTarget: Fix diagnostic of target_link_libraries in wrong directory (#15626) Help: Revise CheckIncludeFile* documentation Help: Revise CMAKE_*_PATH and CMAKE_SYSTEM_*_PATH variable docs (#15631) CMake 3.3.0-rc3 Erik Sj?lund (1): Help: Fix a typo in cmake-buildsystem(7) manual ------------------------------------------------------------------- From tgamblin at llnl.gov Fri Jun 26 20:05:37 2015 From: tgamblin at llnl.gov (Todd Gamblin) Date: Fri, 26 Jun 2015 17:05:37 -0700 Subject: [CMake] CMake adds -qalias=noansi by for XLC Message-ID: Hi, I noticed while poking around CMake's compiler modules that the defaults for XL are kind of inconsistent. Specifically, If you look here: https://github.com/Kitware/CMake/blob/master/Modules/Compiler/XL-C.cmake CMake adds -qalias=noansi by default, which prevents a bunch of optimizations. CMake does not add that for XL C++. It also doesn't tweak any default aliasing settings for other compilers. Why XLC? At LLNL, we don't like qalias=noansi because it prevents a lot of optimizations, so we typically recommend that users NOT use that flag. It's been surprising for us that CMake adds it by default when it's not a default for XL, which uses -qalias=ansi (type-based aliasing) by default. Is there some reason CMake adds it? Could it be removed in future versions for consistency with the C++ settings? I can push a feature branch if people agree that this is a good idea. -Todd -------------- next part -------------- An HTML attachment was scrubbed... URL: From elfring at users.sourceforge.net Sat Jun 27 05:21:44 2015 From: elfring at users.sourceforge.net (SF Markus Elfring) Date: Sat, 27 Jun 2015 11:21:44 +0200 Subject: [CMake] Long command lines In-Reply-To: <558D04FB.20205@simtech.uni-stuttgart.de> References: <558D04FB.20205@simtech.uni-stuttgart.de> Message-ID: <558E6B28.2050202@users.sourceforge.net> > i've recently run into a problem (both windows/mingw and unix/intel) where the cmake-generated build files > create too long command lines that break the overall build. more precisely, the build system uses architecture paths etc > and hence there are long include directories for many packages; e.g. the fortran preprocessor from intel > (in the version we have, cant be upgraded) only allows 4K command lines :-( Can your tool process command-line parameters also from other external input files? Have you got any experiences around the reuse of "response files"? Regards, Markus From rajaram126 at gmail.com Sun Jun 28 03:05:09 2015 From: rajaram126 at gmail.com (rajaram shetty) Date: Sun, 28 Jun 2015 00:05:09 -0700 Subject: [CMake] cmake and xcconfig files. Message-ID: Hi, Is there a way to generate an Xcode project based on a given xcconfig file using cmake? Thanks -- r -------------- next part -------------- An HTML attachment was scrubbed... URL: From elfring at users.sourceforge.net Mon Jun 29 07:08:34 2015 From: elfring at users.sourceforge.net (SF Markus Elfring) Date: Mon, 29 Jun 2015 13:08:34 +0200 Subject: [CMake] Long command lines In-Reply-To: <5590F601.8000205@simtech.uni-stuttgart.de> References: <558D04FB.20205@simtech.uni-stuttgart.de> <558E6B28.2050202@users.sourceforge.net> <5590F601.8000205@simtech.uni-stuttgart.de> Message-ID: <55912732.1000301@users.sourceforge.net> > unfortunately i dont quite understand what you mean with "your tool". How many efforts would you like to invest so that limitations around software like a fortran preprocessor can be circumvented? http://www.cmake.org/Wiki/CMake_FAQ#How_can_I_avoid_the_error_.22Arg_list_too_long.22_when_running_make.3F > it's cmake, and ideally that's all i'm gonna use to solve my problem :-) > and no, i dont have any experiences around the a) use or b) re-use of response files. In which companion files can you handle long command-line parameters for your software environment? Do you see chances to achieve progress with custom commands? http://www.cmake.org/cmake/help/v3.3/command/add_custom_command.html Regards, Markus From bill at classdesign.com Mon Jun 29 07:06:07 2015 From: bill at classdesign.com (Bill Somerville) Date: Mon, 29 Jun 2015 12:06:07 +0100 Subject: [CMake] cmake-qt: controlling includes order Message-ID: <5591269F.8060706@classdesign.com> Hi All, I have an issue with cmake-qt where i need to ensure an include path set by the include_directories() command is after include paths that are added by the target_link_libraries() command or by the qt5_use_modules() command. In both cases the AFTER option on the include_directories() command doesn't seem to help me. Most of the Qt include paths get added to the end of the list, for some reason QtCore doesn't, and I can't find a way to force the ordering I need. I don't know if this an issue with the Qt CMake files or a generic issue with target properties vs. using the include_directories() command. Any ideas how I can control the ordering or reorder the TARGET_INCLUDE_DIRECTORIES property? TIA Bill. From elfring at users.sourceforge.net Mon Jun 29 07:56:11 2015 From: elfring at users.sourceforge.net (SF Markus Elfring) Date: Mon, 29 Jun 2015 13:56:11 +0200 Subject: [CMake] Long command lines In-Reply-To: <559129AE.40102@simtech.uni-stuttgart.de> References: <558D04FB.20205@simtech.uni-stuttgart.de> <558E6B28.2050202@users.sourceforge.net> <5590F601.8000205@simtech.uni-stuttgart.de> <55912732.1000301@users.sourceforge.net> <559129AE.40102@simtech.uni-stuttgart.de> Message-ID: <5591325B.8010305@users.sourceforge.net> >> http://www.cmake.org/Wiki/CMake_FAQ#How_can_I_avoid_the_error_.22Arg_list_too_long.22_when_running_make.3F > so both the means suggested on that page dont apply to us. > the problem is very specifically for some compiler versions, > and i was looking for a native cmake solution that /does not/ depend > on a specific environment. > we're providing a larger framework, which in turn consumes > many upstream packages (some of which we are writing CMakeLists for, > but do not interfer with/change the code itself). > as the overall build is controlled by a superproject > (using external projects), the external project partially consume > other external frameworks. > now, if they are placed under an architecture directory > (mpi/release|debug/static|shared etc), the include paths > to the libraries tend to get longer and e.g. fail for > the intel compsuite 12, where the maximum argument buffer is 4k. Can corresponding tools process the needed parameters also by passing them in dedicated input files? Would special file formats be usable for your software? > i know custom commands, and unfortunately, no they wont help in our situation. Why not? Regards, Markus From paul at mad-scientist.net Mon Jun 29 08:20:43 2015 From: paul at mad-scientist.net (Paul Smith) Date: Mon, 29 Jun 2015 08:20:43 -0400 Subject: [CMake] Long command lines In-Reply-To: <55912732.1000301@users.sourceforge.net> References: <558D04FB.20205@simtech.uni-stuttgart.de> <558E6B28.2050202@users.sourceforge.net> <5590F601.8000205@simtech.uni-stuttgart.de> <55912732.1000301@users.sourceforge.net> Message-ID: <1435580443.12367.15.camel@mad-scientist.net> On Mon, 2015-06-29 at 13:08 +0200, SF Markus Elfring wrote: > > unfortunately i dont quite understand what you mean with "your > tool". > > How many efforts would you like to invest so that limitations > around software like a fortran preprocessor can be circumvented? > > http://www.cmake.org/Wiki/CMake_FAQ#How_can_I_avoid_the_error_.22Arg_list_too_long.22_when_running_make.3F Just to be clear, this isn't a problem with make per se. The operating system itself has a limitation on the amount of data in the environment (which consists of both environment variables and command line arguments) that can be passed from one process to its child process. No program, whether it's make or something else like the shell, can exceed that limit. From jsvanbethlehem at gmail.com Mon Jun 29 09:09:51 2015 From: jsvanbethlehem at gmail.com (Jakob van Bethlehem) Date: Mon, 29 Jun 2015 15:09:51 +0200 Subject: [CMake] Putting ctest in a 'watch' mode? Message-ID: <912737C0-C48C-45C8-924F-2AF8BC740F97@gmail.com> Dear users, While developing a bunch of tests, I started wondering whether it is possible to put ctest in a kind of ?watch? mode, where it is continuously watching a set of test executable, and automatically running any (or all) of them when the compiler creates a new version of the test executable. I?m working with cmake 3.2.2 on Windows 7, the compiler is mdvc 2013. I have been looking through cmake --help, but I couldn?t find anything obvious there. Sincerely, Jakob van Bethlehem From patrick.griffiths at gmail.com Mon Jun 29 17:48:36 2015 From: patrick.griffiths at gmail.com (Patrick Griffiths) Date: Mon, 29 Jun 2015 15:48:36 -0600 Subject: [CMake] target_link_libraries can't set linker options with Visual Studio generator Message-ID: I'm using CMake 3.2.3. I really need to be able to add options to LINK_FLAGS using generator expressions. When I use LINK_FLAGS with set_target_properties or set_property, generator expressions are not expanded. I noticed that the documentation for target_link_libraries says: "Item names starting with -, but not -l or -framework, are treated as linker flags...." So I tried setting options with target_link_libraries. Unfortunately, it doesn't work. Some generator expressions (e.g. $) error out during generation: "Expressions which require the linker language may not be used while evaluating link libraries". In case where the generator expressions do evaluate, the VS generator treats all options as if they were link libraries, so my options end-up in the list of libraries to link. For example, I end-up with -PDBSTRIPPED:c:/path/to/lib/mylib.pdb in the Linker>Additional Dependencies setting. I'm really stuck. How can I set linker flags that use generator expressions? -------------- next part -------------- An HTML attachment was scrubbed... URL: From glenn.coombs at gmail.com Tue Jun 30 09:16:04 2015 From: glenn.coombs at gmail.com (Glenn Coombs) Date: Tue, 30 Jun 2015 14:16:04 +0100 Subject: [CMake] Cannot add target-level dependencies to non-existent target Message-ID: I am getting the error in the subject. The code I have looks like this: if (PRE_COMPILED_HEADERS_FOUND) ADD_PRECOMPILED_HEADER(${header_pch} ${source_pch} sources systemc) endif() add_library(systemc ${sources} ${sources_no_pch} ${headers}) where the call to add_dependency is in the ADD_PRECOMPILED_HEADER macro and is adding a dependency on the systemc target about to be created on the next line. I could split the macro into 2 and call one before the add_library and one after the add_library but that is rather messy. At the point I try to add the dependency the target does not exist, but it is added shortly after. Is this the way CMake is supposed to behave or should it only cause an error if the target doesn't exist at generate time ? -- Glenn -------------- next part -------------- An HTML attachment was scrubbed... URL: From parag at ionicsecurity.com Tue Jun 30 10:35:30 2015 From: parag at ionicsecurity.com (Parag Chandra) Date: Tue, 30 Jun 2015 14:35:30 +0000 Subject: [CMake] Cannot add target-level dependencies to non-existent target In-Reply-To: References: Message-ID: I?ve run into similar problems, but I think this is by design: CMake isn?t going to let you do anything to a target until that target exists. For me, it was pretty straightforward to adjust my CMakeLists to satisfy the requirement. If you don?t want to split apart your macro, one thing you might try is checking for the existence of the target inside your macro, and then creating it if it doesn?t. Something like: IF (NOT TARGET targetName) ADD_LIBRARY(targetName ${sources} ${sources_no_pch} ${headers}) ENDIF () You would need additional parameters in your macro, which could make this pretty messy. Parag Chandra Senior Software Engineer, Mobile Team Mobile: +1.919.824.1410 [https://www.ionicsecurity.com/IonicSigHz.png] Ionic Security Inc. 1170 Peachtree St. NE STE 400, Atlanta, GA 30309 From: Glenn Coombs > Reply-To: "glenn.coombs at gmail.com" > Date: Tuesday, June 30, 2015 at 9:16 AM To: cmake Mailing List > Subject: [CMake] Cannot add target-level dependencies to non-existent target I am getting the error in the subject. The code I have looks like this: if (PRE_COMPILED_HEADERS_FOUND) ADD_PRECOMPILED_HEADER(${header_pch} ${source_pch} sources systemc) endif() add_library(systemc ${sources} ${sources_no_pch} ${headers}) where the call to add_dependency is in the ADD_PRECOMPILED_HEADER macro and is adding a dependency on the systemc target about to be created on the next line. I could split the macro into 2 and call one before the add_library and one after the add_library but that is rather messy. At the point I try to add the dependency the target does not exist, but it is added shortly after. Is this the way CMake is supposed to behave or should it only cause an error if the target doesn't exist at generate time ? -- Glenn -------------- next part -------------- An HTML attachment was scrubbed... URL: From Joseph.Gagnon at ll.mit.edu Tue Jun 30 14:35:36 2015 From: Joseph.Gagnon at ll.mit.edu (Gagnon, Joseph - 0553 - MITLL) Date: Tue, 30 Jun 2015 18:35:36 +0000 Subject: [CMake] How to build just one library from a source directory hierarchy Message-ID: I have a small C++ project for which the source code is distributed in a small directory hierarchy. I have a "master" CMakeLists.txt file at the project root as well as one for each source subdirectory. How would I configure the CMakeLists.txt files so that the build produces a single library file that comprises the entire hierarchy? I am using CMake 3.2.2 that came bundled with JetBrains CLion 1.0.4. The software is being developed on CentOS 6.6. I have tried to find out how this might be done by looking at various links on the CMake wiki and in the cmake documentation, but haven't had any luck getting something to work. The files I have currently build a library file at each directory, which is not what I want. I saw an option to the add_library() command where you could define the library as an "object" library. This sounds like what I would need, but when I added the OBJECT token to the call, CMake complained: Error:Target llxcc has dependency information when it shouldn't. Your cache is probably stale. Please remove the entry llxcc_LIB_DEPENDS from the cache. I'm not sure what this means. I looked in the cache view and found the entry referred to, but it had no value. Any suggestions on how to do this would be appreciated. Thanks, Joseph Gagnon Engineer II Group 53 - Secure Resilient Systems and Technology MIT Lincoln Laboratory Lexington, MA -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5625 bytes Desc: not available URL: From steveire at gmail.com Tue Jun 30 17:26:24 2015 From: steveire at gmail.com (Stephen Kelly) Date: Tue, 30 Jun 2015 23:26:24 +0200 Subject: [CMake] Using generator expressions with set_target_properties References: Message-ID: Patrick Griffiths wrote: > I'm trying to add the /PDBSTRIPPED option LINK_FLAGS_RELWITHDEBINFO config > (Visual Studio generator, obviously): > > set_target_properties(target PROPERTIES > LINK_FLAGS_RELWITHDEBINFO > > "/PDBSTRIPPED: $/stripped/$.pdb") > > Unfortunately the generator expressions aren't being expanded. > > Any suggestions on how I might accomplish this in a reasonable way? Add the flag with target_link_libraries instead. Thanks, Steve. From steveire at gmail.com Tue Jun 30 17:28:59 2015 From: steveire at gmail.com (Stephen Kelly) Date: Tue, 30 Jun 2015 23:28:59 +0200 Subject: [CMake] cmake-qt: controlling includes order References: <5591269F.8060706@classdesign.com> Message-ID: Bill Somerville wrote: > Any ideas how I can control the ordering or reorder the > TARGET_INCLUDE_DIRECTORIES property? add_executable(hello main.cpp) target_link_libraries(hello Qt5::Widgets) target_include_directories( $ ${otherIncludes} ) Thanks, Steve. From steveire at gmail.com Tue Jun 30 17:30:56 2015 From: steveire at gmail.com (Stephen Kelly) Date: Tue, 30 Jun 2015 23:30:56 +0200 Subject: [CMake] Using generator expressions with set_target_properties References: Message-ID: Stephen Kelly wrote: >> Any suggestions on how I might accomplish this in a reasonable way? > > Add the flag with target_link_libraries instead. Ah, I see you tried that, sorry for the noise. Thanks, Steve. From steveire at gmail.com Tue Jun 30 17:34:05 2015 From: steveire at gmail.com (Stephen Kelly) Date: Tue, 30 Jun 2015 23:34:05 +0200 Subject: [CMake] Cannot add target-level dependencies to non-existent target References: Message-ID: Glenn Coombs wrote: > I am getting the error in the subject. The code I have looks like this: > > if (PRE_COMPILED_HEADERS_FOUND) > ADD_PRECOMPILED_HEADER(${header_pch} ${source_pch} sources > systemc) > endif() > > add_library(systemc ${sources} ${sources_no_pch} ${headers}) > Use target_sources after the target is created. add_library(systemc ${sources} ${headers}) if (PRE_COMPILED_HEADERS_FOUND) ADD_PRECOMPILED_HEADER(${header_pch} ${source_pch} pch_files systemc) target_sources(systemc PRIVATE ${pch_files}) endif() Thanks, Steve. From bill at classdesign.com Tue Jun 30 20:17:35 2015 From: bill at classdesign.com (Bill Somerville) Date: Wed, 01 Jul 2015 01:17:35 +0100 Subject: [CMake] cmake-qt: controlling includes order In-Reply-To: References: <5591269F.8060706@classdesign.com> Message-ID: <5593319F.2090708@classdesign.com> On 30/06/2015 22:28, Stephen Kelly wrote: Hi Steve, thanks for looking at this. > Bill Somerville wrote: > >> Any ideas how I can control the ordering or reorder the >> TARGET_INCLUDE_DIRECTORIES property? > > add_executable(hello main.cpp) > target_link_libraries(hello Qt5::Widgets) > target_include_directories( > $ > ${otherIncludes} > ) OK, so that doesn't work but the following does: add_executable(hello main.cpp) target_link_libraries(hello Qt5::Widgets Qt5::Network ${other_LIBRARIES}) target_include_directories( hello PRIVATE $ $ ${other_INCLUDE_DIRS} ) Note that every top level Qt5 include directory property used has to be mentioned. This is pretty painful given the intent is simply to put ${other_INCLUDE_DIRS} at the end of the list. Also this is all due to a Mac issue where having MacPorts Qt4 installed causes it to be pulled in when some other MacPorts library is used, in this case FFTW3. Most of our developers work on Windows and Linux and are not going to know that this abomination is required to stop the Mac build breaking. I see target_include_directories() has a BEFORE option but no AFTER option, I would have thought that is necessary to be the equivalent of he directory level include_directories() command. It would also help to understand how the Qt5 include directories get added when they are not specified at all, i.e. when something like: add_executable(hello main.cpp) target_link_libraries(hello Qt5::Widgets) is used alone. > > Thanks, > > Steve. > Regards Bill.