From jay.custin at hpe.com Sun Nov 1 16:19:43 2015 From: jay.custin at hpe.com (Custin, Jay (CSC Sw Middleware)) Date: Sun, 1 Nov 2015 21:19:43 +0000 Subject: [CMake] =?windows-1252?q?CMake_on_OpenVMS_-_Bootstrap_CMake_compl?= =?windows-1252?q?aining_that_=93pid=5Ft_doesn=92t_exist_on_this_platform?= =?windows-1252?q?=3F=94?= Message-ID: Still kicking myself? ?normally? I would ?delete? files that I had modified by first renaming them to ?hide? them and only then actually delete them? Well sure enough the one time I feel confident apparently I whacked something I shouldn?t have (guessing)? Regardless of which the CMake execution at the tail end of the bootstrap now complains about pid_t not existing? as you can see in the following excerpt from manually executing the command with the ?trace option: /PRJ_ROOT/CMAKE-3_3_2/Modules/CheckTypeSize.cmake(246): set(PID_T_KEYS ) /PRJ_ROOT/CMAKE-3_3_2/Modules/CheckTypeSize.cmake(247): set(_map_file ${CMAKE_BINARY_DIR}/${CMAKE_FILES_DIRECTORY}/CheckTypeSize/PID_T.cmake ) /PRJ_ROOT/CMAKE-3_3_2/Modules/CheckTypeSize.cmake(248): if(NOT DEFINED HAVE_PID_T ) /PRJ_ROOT/CMAKE-3_3_2/Modules/CheckTypeSize.cmake(251): include(${_map_file} OPTIONAL ) /PRJ_ROOT/CMAKE-3_3_2/Modules/CheckTypeSize.cmake(252): set(_map_file ) /PRJ_ROOT/CMAKE-3_3_2/Modules/CheckTypeSize.cmake(253): set(_builtin ) /PRJ_ROOT/CMAKE-3_3_2/Modules/CheckTypeSize.cmake(256): if(PID_T_KEYS ) /PRJ_ROOT/CMAKE-3_3_2/Modules/CheckTypeSize.cmake(265): elseif(PID_T ) /PRJ_ROOT/CMAKE-3_3_2/Modules/CheckTypeSize.cmake(267): else() /PRJ_ROOT/CMAKE-3_3_2/Modules/CheckTypeSize.cmake(268): set(PID_T_CODE /* #undef PID_T */ ) /PRJ_ROOT/CMAKE-3_3_2/Utilities/cmlibarchive/CMakeLists.txt(1128): IF(NOT HAVE_PID_T ) /PRJ_ROOT/CMAKE-3_3_2/Utilities/cmlibarchive/CMakeLists.txt(1129): IF(WIN32 ) /PRJ_ROOT/CMAKE-3_3_2/Utilities/cmlibarchive/CMakeLists.txt(1131): ELSE(WIN32 ) /PRJ_ROOT/CMAKE-3_3_2/Utilities/cmlibarchive/CMakeLists.txt(1132): MESSAGE(FATAL_ERROR pid_t doesn't exist on this platform? ) CMake Error at Utilities/cmlibarchive/CMakeLists.txt:1132 (MESSAGE): pid_t doesn't exist on this platform? I > thought < about simply tweaking the code to override the apparent ?missing? definition, but then decided that clearly something else prevents CMake from finding it and so thought I would pose the question here to see if anyone has any ideas. The problem with this comes from knowing for certain that pid_t DOES exist in the default HP C header: ITAN1> sea/num unistd.h "ifndef __PID_T"/win=(0,3) 353 # ifndef __PID_T 354 # define __PID_T 1 355 typedef __pid_t pid_t; 356 # endif And ITAN1> sea unistd.h/num "types.h" 31 #include ITAN1> sea types.h /num/win=(0,3) "#if !defined __PID_T" 104 #if !defined __PID_T && !defined _DECC_V4_SOURCE 105 # define __PID_T 1 106 typedef __pid_t pid_t; 107 #endif The error occurs in this section of Utilities/cmlibarchive/CMakeLists.txt: Line# 1127 CHECK_TYPE_SIZE(pid_t PID_T) 1128 IF(NOT HAVE_PID_T) 1129 IF(WIN32) 1130 SET(pid_t "int") 1131 ELSE(WIN32) 1132 MESSAGE(FATAL_ERROR "pid_t doesn't exist on this platform?") 1133 ENDIF(WIN32) 1134 ENDIF(NOT HAVE_PID_T) Anyone have any ideas? JayC -------------- next part -------------- An HTML attachment was scrubbed... URL: From boud at valdyas.org Mon Nov 2 04:26:27 2015 From: boud at valdyas.org (Boudewijn Rempt) Date: Mon, 2 Nov 2015 10:26:27 +0100 (CET) Subject: [CMake] getting the rpath right on osx Message-ID: I checked the manual and the blog post about rpath on osx, but I'm still confused, and still not getting it right... I build and installed Qt 5.6 alpha like this: ./configure -prefix /Users/boudewijnrempt/kf5/i Then I made a small test project, consisting of nothing but a main that links to QtCore. If I build that with qmake, with this .pro file: QT += core QT -= gui TARGET = rpathqmake CONFIG += console CONFIG -= app_bundle TEMPLATE = app SOURCES += main.cpp The r-path is set: Boudewijns-Mac-mini:test boudewijnrempt$ otool -L rpathqmake rpathqmake: @rpath/QtCore.framework/Versions/5/QtCore (compatibility version 5.6.0, current version 5.6.0) /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0) /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0) Boudewijns-Mac-mini:test boudewijnrempt$ otool -L rpathqmake | grep -i rpath rpathqmake: @rpath/QtCore.framework/Versions/5/QtCore (compatibility version 5.6.0, current version 5.6.0 If I try a minimal cmakelists.txt, the rpath isn't set, I tried with and without all those RPATH related lines, they don't seem to make a difference. I'm using cmake 3.3.2. cmake_minimum_required(VERSION 2.8.12) cmake_policy(SET CMP0042 NEW) set(CMAKE_MACOSX_RPATH ON) SET(CMAKE_SKIP_BUILD_RPATH TRUE) SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE) SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE) set(REQUIRED_QT_VERSION 5.3.0) find_package(Qt5 ${REQUIRED_QT_VERSION} CONFIG REQUIRED Core) add_executable(rpathcmake main.cpp) target_link_libraries(rpathcmake Qt5::Core) install(TARGETS rpathcmake DESTINATION /Users/boudewijnrempt/kf5/i/bin) Only adding something like this makes it work: set_target_properties(rpathcmake PROPERTIES INSTALL_RPATH "/Users/boudewijnrempt/kf5/i/lib") Which I'm pretty sure is something I don't want. Boudewijns-Mac-mini:test boudewijnrempt$ make install [100%] Built target rpathcmake Install the project... -- Install configuration: "" -- Up-to-date: /Users/boudewijnrempt/kf5/i/bin/rpathcmake Boudewijns-Mac-mini:test boudewijnrempt$ otool -L /Users/boudewijnrempt/kf5/i/bin/rpathcmake /Users/boudewijnrempt/kf5/i/bin/rpathcmake: @rpath/QtCore.framework/Versions/5/QtCore (compatibility version 5.6.0, current version 5.6.0) /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1) Boudewijns-Mac-mini:test boudewijnrempt$ ~/kf5/i/bin/rpathcmake dyld: Library not loaded: @rpath/QtCore.framework/Versions/5/QtCore Referenced from: /Users/boudewijnrempt/kf5/i/bin/rpathcmake Reason: image not found Trace/BPT trap: 5 Boudewijns-Mac-mini:test boudewijnrempt$ otool -L /Users/boudewijnrempt/kf5/i/bin/rpathcmake /Users/boudewijnrempt/kf5/i/bin/rpathcmake: @rpath/QtCore.framework/Versions/5/QtCore (compatibility version 5.6.0, current version 5.6.0) /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1) What should I do? -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org From gjasny at googlemail.com Mon Nov 2 05:06:40 2015 From: gjasny at googlemail.com (Gregor Jasny) Date: Mon, 2 Nov 2015 11:06:40 +0100 Subject: [CMake] Greediness of kwsys regex Message-ID: <563735B0.6030702@googlemail.com> Hello, Today I stumbled across funny behavior of string(REGEX REPLACE: This one would lead to an empty match: > string(REGEX REPLACE "(.*)" "\\1Proxy.cpp" _out "IConnectionCallback") This one would match whole "IConnectionCallback" > string(REGEX REPLACE "(.+)" "\\1Proxy.cpp" _out "IConnectionCallback") Principle of least surprise makes me expect that both variants (* vs. +) either contain the full string or the minimal set: empty for *, first character for +. Could someone please explain what's going on here? Thanks, Gregor From michael.jaentsch at in.tum.de Mon Nov 2 06:41:34 2015 From: michael.jaentsch at in.tum.de (=?ISO-8859-1?Q?Michael_J=E4ntsch?=) Date: Mon, 02 Nov 2015 12:41:34 +0100 Subject: [CMake] Visual Studio Cross Compile In-Reply-To: <44e308e464e4495c8ff063b9f7de58f3@in.tum.de> References: <44e308e464e4495c8ff063b9f7de58f3@in.tum.de> Message-ID: <4D0BE10A-4830-4AF6-A30A-F2B02013E32D@in.tum.de> Hi again, Is there nobody who can help me? I thought it would be a common thing to use cmake to cross compile!? Has nobody ever used visual studio to do so? Cheers Michael Am 29. Oktober 2015 15:21:41 MEZ, schrieb Michael Jaentsch : >Hi all, > >I have a question concerning Cross Compiling with CMake on Windows. I >would like to use Visual Studio but this is not a must. What I do is, I > >setup a project for Cross Compiling on Linux and it works fine. Now I >want to transfer to Windows, so I set up a toolchain file which sets >the >following variables: >CMAKE_SYSTEM_NAME >CMAKE_SYSTEM_PROCESSOR >CMAKE_FIND_ROOT_PATH >CMAKE_C_COMPILER >CMAKE_CXX_COMPILER > >and some more stuff. Then I run my cmake gui (I tried 3.2 and 3.4rc2) >on Windows and tell it to generate a project for Visual Studio 10 and >to >use the toolchain file. However, the output shows that it is trying to >use the Visual Studio compiler and then subsequently the build fails >because of some unkown compiler flags. > >So my question is: Is it even possible to do what I'm trying to do? Can > >I cross compile with Visual Studio or do I have to use a different >generator? All I found in the documentation is that it is possible to >cross compile with a toolchain file... > >Cheers >Michael > > >-- >Technische Universit?t M?nchen >Michael J?ntsch >Fakult?t f?r Informatik >Robotics and Embedded Systems >Parkring 13 >85748 Garching bei M?nchen >michael.jaentsch at in.tum.de >www6.in.tum.de >-- > >Powered by www.kitware.com > >Please keep messages on-topic and check the CMake FAQ at: >http://www.cmake.org/Wiki/CMake_FAQ > >Kitware offers various services to support the CMake community. For >more information on each offering, please visit: > >CMake Support: http://cmake.org/cmake/help/support.html >CMake Consulting: http://cmake.org/cmake/help/consulting.html >CMake Training Courses: http://cmake.org/cmake/help/training.html > >Visit other Kitware open-source projects at >http://www.kitware.com/opensource/opensource.html > >Follow this link to subscribe/unsubscribe: >http://public.kitware.com/mailman/listinfo/cmake -- Sent from my mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Mon Nov 2 07:16:01 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Mon, 2 Nov 2015 13:16:01 +0100 Subject: [CMake] Visual Studio Cross Compile In-Reply-To: <4D0BE10A-4830-4AF6-A30A-F2B02013E32D@in.tum.de> References: <44e308e464e4495c8ff063b9f7de58f3@in.tum.de> <4D0BE10A-4830-4AF6-A30A-F2B02013E32D@in.tum.de> Message-ID: <56375401.60005@gmail.com> On 11/02/2015 12:41 PM, Michael J?ntsch wrote: > Hi again, > > Is there nobody who can help me? I thought it would be a common thing > to use cmake to cross compile!? Has nobody ever used visual studio to > do so? Visual Studio itself does not have compiler selection in the same sense as is available with e.g. Makefiles or Ninja. It can not be directly told to use specific compiler paths (you will not find any compiler paths in the generated solutions/projects). It does support "Platform Toolset"s which in manually created projects can be set/seen in the "General" project settings and in CMake generated projects can be set via the -T option [1]. I'd stick to Ninja or Makefiles for cross-compiles unless you are targeting something with pre-existing toolset support. I think e.g. Android is supported via CMAKE_SYSTEM_NAME "Android" and NVIDIA Nsight Tegra integration [2]. Nils [1] https://cmake.org/cmake/help/v3.3/variable/CMAKE_GENERATOR_TOOLSET.html [2] https://cmake.org/cmake/help/v3.3/release/3.1.html#nvidia-nsight-tegra From apaku at gmx.de Mon Nov 2 08:44:23 2015 From: apaku at gmx.de (Andreas Pakulat) Date: Mon, 2 Nov 2015 14:44:23 +0100 Subject: [CMake] getting the rpath right on osx In-Reply-To: References: Message-ID: Hi, On Mon, Nov 2, 2015 at 10:26 AM, Boudewijn Rempt wrote: > I checked the manual and the blog post about rpath on osx, but I'm still > confused, and still not getting it right... > > I build and installed Qt 5.6 alpha like this: > > ./configure -prefix /Users/boudewijnrempt/kf5/i > > Then I made a small test project, consisting of nothing but a main that > links to QtCore. > > If I build that with qmake, with this .pro file: > > QT += core > QT -= gui > TARGET = rpathqmake > CONFIG += console > CONFIG -= app_bundle > TEMPLATE = app > SOURCES += main.cpp > > The r-path is set: > > Boudewijns-Mac-mini:test boudewijnrempt$ otool -L rpathqmake > rpathqmake: > @rpath/QtCore.framework/Versions/5/QtCore (compatibility version > 5.6.0, current version 5.6.0) > > /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration > (compatibility version 1.0.0, current version 1.0.0) > /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit > (compatibility version 1.0.0, current version 275.0.0) > /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version > 120.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current > version 1213.0.0) > > Boudewijns-Mac-mini:test boudewijnrempt$ otool -L rpathqmake | grep -i > rpath > rpathqmake: > @rpath/QtCore.framework/Versions/5/QtCore (compatibility version > 5.6.0, current version 5.6.0 > Thats not the rpath in your executable, thats just the install name of the QtCore library. And the install name indicates that you need to set an rpath in your executable that points to the installation directory of Qt. In order to see the rpath entries of your executable you'll need to check for the LC_RPATH command in the output of this: otool -l rpathqmake It will show the absolute path to the Qt installation on your system. > If I try a minimal cmakelists.txt, the rpath isn't set, I tried with and > without all those RPATH related lines, > they don't seem to make a difference. I'm using cmake 3.3.2. > > cmake_minimum_required(VERSION 2.8.12) > cmake_policy(SET CMP0042 NEW) > set(CMAKE_MACOSX_RPATH ON) > SET(CMAKE_SKIP_BUILD_RPATH TRUE) > SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE) > SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE) > set(REQUIRED_QT_VERSION 5.3.0) > find_package(Qt5 ${REQUIRED_QT_VERSION} CONFIG REQUIRED Core) > add_executable(rpathcmake main.cpp) > target_link_libraries(rpathcmake Qt5::Core) > install(TARGETS rpathcmake DESTINATION /Users/boudewijnrempt/kf5/i/bin) > > Only adding something like this makes it work: > > set_target_properties(rpathcmake PROPERTIES INSTALL_RPATH > "/Users/boudewijnrempt/kf5/i/lib") > I guess thats where your Qt is installed to? Then yes, that is exactly what you want since thats where Qt is and the Qt libraries require an rpath to be set to be found since 5.5 on OSX. You just don't want to hardcode this, but rather calculate it off of the path of the QtCore library. Or even better would be if the Qt5 cmake modules would provide some provision to add the necessary linker commandline argument to inject the rpath during linking into the executable. Thats how qmake makes things 'work out of the box', it knows Qt has been built with the rpath-flag (default since 5.5) and then adds something like -Wl,-rpath, to the linker commandline of the generated Makefile. I think the idea of using @rpath as install name of the Qt libraries is geared towards the usecase of shipping Qt within the application bundle of the application. In that case all you need is set the rpath @executable_path/../Frameworks or so in the executable and thus the app-bundle is relocatable. In order to get that with CMake you'll likely need to use the BundleUtilities, though its been so long since I used those I don't know if they can handle this scenario out of the box. Andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: From boud at valdyas.org Mon Nov 2 08:49:35 2015 From: boud at valdyas.org (Boudewijn Rempt) Date: Mon, 2 Nov 2015 14:49:35 +0100 (CET) Subject: [CMake] getting the rpath right on osx In-Reply-To: References: Message-ID: On Mon, 2 Nov 2015, Andreas Pakulat wrote: > I think the idea of using @rpath as install name of the Qt libraries is geared towards the usecase > of shipping Qt within the application bundle of the application. In that case all you need is set > the rpath @executable_path/../Frameworks or so in the executable and thus the app-bundle is > relocatable. In order to get that with CMake you'll likely need to use the BundleUtilities, though > its been so long since I used those I don't know if they can handle this scenario out of the box. > Yes, that's what I'm trying to do -- well, I'm trying to do two things. One is setup a build environment where kde apps like desktoptojson can run, the other is creating a bundle, preferably using the same Qt. I got quite far by manually fixing up the applications built as part of kcoreaddons and then manually patching up the executable inside the bundle to have the @executable_path/../Frameworks rpath added. But I'm still not sure why with a really simple example things don't work out of the box: I guess I had better build Qt with -norpath. Boudewijn From Anthony.R.Ette at controlsdata.com Mon Nov 2 09:09:43 2015 From: Anthony.R.Ette at controlsdata.com (Ette, Anthony (CDS)) Date: Mon, 2 Nov 2015 14:09:43 +0000 Subject: [CMake] FIND_LIBRARY & TARGET_LINK_LIBRARIES Message-ID: <2A375B5C08C24643A8A3F8CC2B98C10862C78094@USINDPR-MBX003.Rolls-Royce.Local> Background info: On version 3.3.20150618. RedHawk Linux 5.1.1 (real-time variant of RHEL5). Description: I am not understanding the behavior of these two commands or am getting inconsistent results. Sometimes when the results of a found static library from FIND_LIBRARY are passed to TARGET_LINK_LIBRARIES, it generates "/path/to/lib" linker syntax BUT other times it produces a "-Wl,-Bstatic -llib -Wl,-Bdynamic" syntax. I've confirmed that both lib vars as returned from FIND_LIBRARY are full paths to .a static archive files so how can the different handling at the linker CLI be explained? Steps to reproduce: Unknown. Some libs are handled one way and others are handled another. The only potential lead may be that they come from different paths on the file system (say one from /usr/lib and another from LIB_DIR=/sim/lib/v67/ihawk). Example: PROJECT(ec_interface) # static arhive #1 from /sim/lib/v67/ihawk FILE(TO_CMAKE_PATH $ENV{LIB_DIR} LIB_D) FIND_LIBRARY(libshm NAMES shm PATHS ${LIB_D} NO_DEFAULT_PATH) MESSAGE("libshm: " ${libshm}) # static archive #2 from /usr/lib FILE(TO_CMAKE_PATH /usr/lib USR_LIB) FIND_LIBRARY(libccur_fbsched NAMES libccur_fbsched.a PATHS ${USR_LIB} NO_DEFAULT_PATH) MESSAGE("libccur_fbsched: " ${libccur_fbsched}) SET(SOURCES ec_interface.cpp) ADD_EXECUTABLE(ec_interface ${SOURCES}) TARGET_LINK_LIBRARIES(ec_interface ${libshm} ${libccur_fbsched}) Notice in the resulting linker command below how libshm and libccur_fbsched are handled very differently, why is this?: /usr/bin/g++ -O3 -DNDEBUG CMakeFiles/ec_interface.dir/ec_interface.cpp.o -o ../../../../ec_interface -rdynamic /sim/lib/v67/ihawk/libshm.a -Wl,-Bstatic -lccur_fbsched -Wl,-Bdynamic If I remove libccur_fbsched from the TARGET_LINK_LIBRARIES, the resulting linker command is: /usr/bin/g++ -O3 -DNDEBUG CMakeFiles/ec_interface.dir/ec_interface.cpp.o -o ../../../../ec_interface -rdynamic /sim/lib/v67/ihawk/libshm.a I guess it's also important to note that in LIB_D, only .a files exist (i.e. there is only a libshm.a and no libshm.so file). However, in /usr/lib, there are multiple files by the same name with different suffixes (e.g. libccur_fbsched.a, libccur_fbsched.so, etc.). That is why I am specifying the ".a" explicitly in the FIND_LIBRARY command for libccur_fbsched in an attempt to force it to pick up the static archive and not the dynamic ones. The message I'm printing seems to indicate it is using the static, so I still don't understand the resulting link command. How fine tuned of control do I have over the resulting link command? I.e. can I force libccur_fbsched to show up as "/usr/lib/libccur_fbsched.a" and not as "-Wl,-Bstatic -lccur_fbsched -Wl,-Bdynamic"? Lastly, I've found that if I instead ADD_LIBRARY as shown below, I can force the generated link command to use simply "/usr/lib/libccur_fbsched.a" as desired although I don't believe this is the recommended way of doing things. I thought FIND_LIBRARY was supposed to be used here (whereas ADD_LIBRARY is intended to be used when the library is created within the scope of current CMake project)? Can anyone explain how/why CMake is generating different linker output for different static archives that are found using the same method (i.e. using FIND_LIBRARY then passing result to TARGET_LINK_LIBRARIES) where the extension is specified in one case but not the other? ADD_LIBRARY(libccur_fbsched STATIC IMPORTED) SET_PROPERTY(TARGET libccur_fbsched PROPERTY IMPORTED_LOCATION ${USR_LIB}/libccur_fbsched${LIBEXT}) TARGET_LINK_LIBRARIES(ec_interface ${libshm} libccur_fbsched) /usr/bin/g++ -O3 -DNDEBUG CMakeFiles/ec_interface.dir/ec_interface.cpp.o -o ../../../../ec_interface -rdynamic /sim/lib/v67/ihawk/libshm.a /usr/lib/libccur_fbsched.a Thanks, Anthony Ette Technical Specialist, Software & Modeling Rolls-Royce Controls and Data Services 7661 N Perimeter Rd Indianapolis, IN 46241 tel: +1 (317) 230-6943 mob: +1 (317) 864-7975 email: Anthony.R.Ette at 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 parag at ionicsecurity.com Mon Nov 2 09:51:46 2015 From: parag at ionicsecurity.com (Parag Chandra) Date: Mon, 2 Nov 2015 14:51:46 +0000 Subject: [CMake] Visual Studio Cross Compile In-Reply-To: <44e308e464e4495c8ff063b9f7de58f3@in.tum.de> References: <44e308e464e4495c8ff063b9f7de58f3@in.tum.de> Message-ID: Hi Michael, Meant to reply sooner. As Nils pointed out, Visual Studio isn?t quite as flexible with cross-compilation as some other build systems. Having said that, it is indeed possible to cross-compile with Visual Studio, but there has to be a cross toolchain compatible with the IDE. Some examples of this include: Google?s Native Client - I have successfully targeted this environment with Visual Studio 2010 and Cmake; Windows Phone 8.1/10 - Have targeted this as well. While you may be thinking ?that?s just another flavor of Windows?, it is nevertheless cross-compiling for ARM; Several options for Android development: Nvidia Tegra Studio; Visual Studio 2015 - Microsoft now offers first-party support within VS 2015; VS-Android; Commercial/paid add-ons that seem to support arbitrary GCC toolchains: Visual GDB - This one may be your best bet for what you are trying to accomplish. Supports Linux, Android, Raspberry Pi, etc. out of the box, and they claim to have an extensibility model to add your own platforms; WinGDB - similarly seems to support the GNU toolchain directly. Anyway, hopefully you get the idea. It is possible, but out of the box, you?re only going to be able to target Windows Phone and Android. Parag Chandra Senior Software Engineer, Mobile Team Mobile: +1.919.824.1410 Ionic Security Inc. 1170 Peachtree St. NE STE 400, Atlanta, GA 30309 On 10/29/15, 10:21 AM, "CMake on behalf of Michael Jaentsch" wrote: >Hi all, > >I have a question concerning Cross Compiling with CMake on Windows. I >would like to use Visual Studio but this is not a must. What I do is, I >setup a project for Cross Compiling on Linux and it works fine. Now I >want to transfer to Windows, so I set up a toolchain file which sets the >following variables: >CMAKE_SYSTEM_NAME >CMAKE_SYSTEM_PROCESSOR >CMAKE_FIND_ROOT_PATH >CMAKE_C_COMPILER >CMAKE_CXX_COMPILER > >and some more stuff. Then I run my cmake gui (I tried 3.2 and 3.4rc2) >on Windows and tell it to generate a project for Visual Studio 10 and to >use the toolchain file. However, the output shows that it is trying to >use the Visual Studio compiler and then subsequently the build fails >because of some unkown compiler flags. > >So my question is: Is it even possible to do what I'm trying to do? Can >I cross compile with Visual Studio or do I have to use a different >generator? All I found in the documentation is that it is possible to >cross compile with a toolchain file... > >Cheers >Michael > > >-- >Technische Universit?t M?nchen >Michael J?ntsch >Fakult?t f?r Informatik >Robotics and Embedded Systems >Parkring 13 >85748 Garching bei M?nchen >michael.jaentsch at in.tum.de >www6.in.tum.de >-- > >Powered by www.kitware.com > >Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > >Kitware offers various services to support the CMake community. For more information on each offering, please visit: > >CMake Support: http://cmake.org/cmake/help/support.html >CMake Consulting: http://cmake.org/cmake/help/consulting.html >CMake Training Courses: http://cmake.org/cmake/help/training.html > >Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > >Follow this link to subscribe/unsubscribe: >http://public.kitware.com/mailman/listinfo/cmake From apaku at gmx.de Mon Nov 2 10:08:55 2015 From: apaku at gmx.de (Andreas Pakulat) Date: Mon, 2 Nov 2015 16:08:55 +0100 Subject: [CMake] getting the rpath right on osx In-Reply-To: References: Message-ID: Hi, On Mon, Nov 2, 2015 at 2:49 PM, Boudewijn Rempt wrote: > On Mon, 2 Nov 2015, Andreas Pakulat wrote: > > I think the idea of using @rpath as install name of the Qt libraries is >> geared towards the usecase >> of shipping Qt within the application bundle of the application. In that >> case all you need is set >> the rpath @executable_path/../Frameworks or so in the executable and thus >> the app-bundle is >> relocatable. In order to get that with CMake you'll likely need to use >> the BundleUtilities, though >> its been so long since I used those I don't know if they can handle this >> scenario out of the box. >> >> > Yes, that's what I'm trying to do -- well, I'm trying to do two > things. One is setup a build environment where kde apps like desktoptojson > can run, the other is creating a bundle, preferably using the same > Qt. I got quite far by manually fixing up the applications built as part > of kcoreaddons That would be fixed in kcoreaddons by extending the linker flags to include the mentioned -Wl,-rpath,. There's no provisioning for this inside CMake afaik since its hard for it to guess what the intention is. My understanding (not a OSX expert yet here) is also that having the install name of a framework on OSX be something like @rpath is quite unusual. Thats usually something that users are 'patching' when they bundle their application via install_name_tool. And thats what CMake supports doing via the BundleUtilities module. > and then manually patching up the executable inside the > bundle to have the @executable_path/../Frameworks rpath added. But I'm > still not sure why with a really simple example things don't work out > of the box: I guess I had better build Qt with -norpath. See above, I think the way the Qt frameworks are setup when using -rpath is simply not expected/anticipated so far by CMake (or the people maintaining the qt5 cmake modules inside Qt). However I never tried to use BundleUtilities with such a framework, maybe they do manage to 'fixup' things for that as well. For a Qt4-based project I'm using INSTALL_QT4_EXECUTABLE which eventually forwards to fixup_bundle from BundleUtilities, so may be worth a try to avoid the manual steps. Even a Qt built with -norpath would require doing some 'manual' things to get a all-in-one app bundle for the application (or use of BundleUtilities), to copy things around and adjust the install and link names in all the frameworks and executables to be related and thus make the application relocatable. Andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.hoffman at kitware.com Mon Nov 2 10:20:22 2015 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Mon, 2 Nov 2015 10:20:22 -0500 Subject: [CMake] =?utf-8?q?CMake_on_OpenVMS_-_Bootstrap_CMake_complaining_?= =?utf-8?q?that_=E2=80=9Cpid=5Ft_doesn=E2=80=99t_exist_on_this_platform=3F?= =?utf-8?b?4oCd?= In-Reply-To: References: Message-ID: <56377F36.2090509@kitware.com> On 11/1/2015 4:19 PM, Custin, Jay (CSC Sw Middleware) wrote: > Anyone have any ideas? > Look in the CMakeError.log file and find out why it is not finding pid_t. -Bill From clinton at elemtech.com Mon Nov 2 10:26:54 2015 From: clinton at elemtech.com (Clinton Stimpson) Date: Mon, 02 Nov 2015 08:26:54 -0700 Subject: [CMake] getting the rpath right on osx In-Reply-To: References: Message-ID: <5923224.XKIQ6vTeSp@stryke> On Monday, November 02, 2015 04:08:55 PM Andreas Pakulat wrote: > Hi, > > On Mon, Nov 2, 2015 at 2:49 PM, Boudewijn Rempt wrote: > > On Mon, 2 Nov 2015, Andreas Pakulat wrote: > > > > I think the idea of using @rpath as install name of the Qt libraries is > > > >> geared towards the usecase > >> of shipping Qt within the application bundle of the application. In that > >> case all you need is set > >> the rpath @executable_path/../Frameworks or so in the executable and thus > >> the app-bundle is > >> relocatable. In order to get that with CMake you'll likely need to use > >> the BundleUtilities, though > >> its been so long since I used those I don't know if they can handle this > >> scenario out of the box. > > > > Yes, that's what I'm trying to do -- well, I'm trying to do two > > things. One is setup a build environment where kde apps like desktoptojson > > can run, the other is creating a bundle, preferably using the same > > Qt. I got quite far by manually fixing up the applications built as part > > of kcoreaddons > > That would be fixed in kcoreaddons by extending the linker flags to include > the mentioned -Wl,-rpath,. There's no provisioning for this > inside CMake afaik since its hard for it to guess what the intention is. CMake does automatically handle this. If a library being linked has @rpath for its install ID, then CMake will insert the linker flag. This takes care of the build time rpath. And works for any library in target_link_libraries() where CMake knows its full path. A -L/-l approach does not work, but that is usually done for system libraries, in which case we normally don't care about rpaths. This kind of thing isn't handled automatically at install time, and requires the INSTALL_RPATH property to be set. > My > understanding (not a OSX expert yet here) is also that having the install > name of a framework on OSX be something like @rpath is quite unusual. Thats > usually something that users are 'patching' when they bundle their > application via install_name_tool. And thats what CMake supports doing via > the BundleUtilities module. If install rpaths are set correctly, and all copied 3rd party libraries use @rpath, there is no need for patching with install_name_tool. > > > and then manually patching up the executable inside the > > bundle to have the @executable_path/../Frameworks rpath added. But I'm > > still not sure why with a really simple example things don't work out > > of the box: I guess I had better build Qt with -norpath. > > See above, I think the way the Qt frameworks are setup when using -rpath is > simply not expected/anticipated so far by CMake (or the people maintaining > the qt5 cmake modules inside Qt). It is handled fine by CMake. If not, it would be a bug. > > However I never tried to use BundleUtilities with such a framework, maybe > they do manage to 'fixup' things for that as well. For a Qt4-based project > I'm using INSTALL_QT4_EXECUTABLE which eventually forwards to fixup_bundle > from BundleUtilities, so may be worth a try to avoid the manual steps. > > Even a Qt built with -norpath would require doing some 'manual' things to > get a all-in-one app bundle for the application (or use of > BundleUtilities), to copy things around and adjust the install and link > names in all the frameworks and executables to be related and thus make the > application relocatable. Yes, a Qt built with -norpath will require extra patching steps with install_name_tool. Clint From clinton at elemtech.com Mon Nov 2 08:23:56 2015 From: clinton at elemtech.com (clinton at elemtech.com) Date: Mon, 2 Nov 2015 06:23:56 -0700 (MST) Subject: [CMake] getting the rpath right on osx In-Reply-To: References: Message-ID: <402909997.17174488.1446470636396.JavaMail.zimbra@elemtech.com> ----- On Nov 2, 2015, at 2:26 AM, Boudewijn Rempt boud at valdyas.org wrote: > I checked the manual and the blog post about rpath on osx, but I'm still > confused, and still not getting it right... > > I build and installed Qt 5.6 alpha like this: > > ./configure -prefix /Users/boudewijnrempt/kf5/i > > Then I made a small test project, consisting of nothing but a main that links to > QtCore. > > If I build that with qmake, with this .pro file: > > QT += core > QT -= gui > TARGET = rpathqmake > CONFIG += console > CONFIG -= app_bundle > TEMPLATE = app > SOURCES += main.cpp > > The r-path is set: > > Boudewijns-Mac-mini:test boudewijnrempt$ otool -L rpathqmake > rpathqmake: > @rpath/QtCore.framework/Versions/5/QtCore (compatibility version 5.6.0, current > version 5.6.0) > /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration > (compatibility version 1.0.0, current version 1.0.0) > /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility > version 1.0.0, current version 275.0.0) > /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version > 1213.0.0) > > Boudewijns-Mac-mini:test boudewijnrempt$ otool -L rpathqmake | grep -i rpath > rpathqmake: > @rpath/QtCore.framework/Versions/5/QtCore (compatibility version 5.6.0, current > version 5.6.0 Keep in mind, "otool -L" doesn't show rpaths. @rpath/QtCore.framework/Versions/5/QtCore is not an rpath. @rpath is a place holder where an rpath can be substituted. Anytime you see "@rpath" what it means is that the dependent library wants to be found using rpaths. Use "otool -l" | grep -A2 LC_RPATH to see the rpaths. > > If I try a minimal cmakelists.txt, the rpath isn't set, I tried with and without > all those RPATH related lines, > they don't seem to make a difference. I'm using cmake 3.3.2. > > cmake_minimum_required(VERSION 2.8.12) > cmake_policy(SET CMP0042 NEW) > set(CMAKE_MACOSX_RPATH ON) > SET(CMAKE_SKIP_BUILD_RPATH TRUE) > SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE) > SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE) > set(REQUIRED_QT_VERSION 5.3.0) > find_package(Qt5 ${REQUIRED_QT_VERSION} CONFIG REQUIRED Core) > add_executable(rpathcmake main.cpp) > target_link_libraries(rpathcmake Qt5::Core) > install(TARGETS rpathcmake DESTINATION /Users/boudewijnrempt/kf5/i/bin) If you remove set(CMAKE_MACOSX_RPATH ON) SET(CMAKE_SKIP_BUILD_RPATH TRUE) SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE) SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE) then, it would probably be a minimal example. > > Only adding something like this makes it work: > > set_target_properties(rpathcmake PROPERTIES INSTALL_RPATH > "/Users/boudewijnrempt/kf5/i/lib") > > Which I'm pretty sure is something I don't want. To fix the errors below, you actually to do something like this. set_target_properties(rpathcmake PROPERTIES INSTALL_RPATH "/Users/boudewijnrempt/kf5/i/lib") What you probably want is to use a variable instead of an absolute path. set_target_properties(rpathcmake PROPERTIES INSTALL_RPATH "@loader_path/../lib") That property along with MACOSX_RPATH, or the global property CMAKE_MACOSX_RPATH are the 2 first variables you would set. MACOSX_RPATH property on a target indicates that its install 'ID' contains @rpath, and it wants to be found using rpaths. INSTALL_RPATH property is a list of rpaths to help find dependencies which want to be found using rpaths. > > Boudewijns-Mac-mini:test boudewijnrempt$ make install > [100%] Built target rpathcmake > Install the project... > -- Install configuration: "" > -- Up-to-date: /Users/boudewijnrempt/kf5/i/bin/rpathcmake > Boudewijns-Mac-mini:test boudewijnrempt$ otool -L > /Users/boudewijnrempt/kf5/i/bin/rpathcmake > /Users/boudewijnrempt/kf5/i/bin/rpathcmake: > @rpath/QtCore.framework/Versions/5/QtCore (compatibility version 5.6.0, current > version 5.6.0) > /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version > 1197.1.1) > Boudewijns-Mac-mini:test boudewijnrempt$ ~/kf5/i/bin/rpathcmake > dyld: Library not loaded: @rpath/QtCore.framework/Versions/5/QtCore > Referenced from: /Users/boudewijnrempt/kf5/i/bin/rpathcmake > Reason: image not found > Trace/BPT trap: 5 > Boudewijns-Mac-mini:test boudewijnrempt$ otool -L > /Users/boudewijnrempt/kf5/i/bin/rpathcmake > /Users/boudewijnrempt/kf5/i/bin/rpathcmake: > @rpath/QtCore.framework/Versions/5/QtCore (compatibility version 5.6.0, current > version 5.6.0) > /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version > 1197.1.1) > > What should I do? Set the INSTALL_RPATH target property. Clint From apaku at gmx.de Mon Nov 2 11:30:49 2015 From: apaku at gmx.de (Andreas Pakulat) Date: Mon, 2 Nov 2015 17:30:49 +0100 Subject: [CMake] getting the rpath right on osx In-Reply-To: <5923224.XKIQ6vTeSp@stryke> References: <5923224.XKIQ6vTeSp@stryke> Message-ID: Hi, On Mon, Nov 2, 2015 at 4:26 PM, Clinton Stimpson wrote: > On Monday, November 02, 2015 04:08:55 PM Andreas Pakulat wrote: > > Hi, > > > > On Mon, Nov 2, 2015 at 2:49 PM, Boudewijn Rempt > wrote: > > > On Mon, 2 Nov 2015, Andreas Pakulat wrote: > > > > > > I think the idea of using @rpath as install name of the Qt libraries is > > > > > >> geared towards the usecase > > >> of shipping Qt within the application bundle of the application. In > that > > >> case all you need is set > > >> the rpath @executable_path/../Frameworks or so in the executable and > thus > > >> the app-bundle is > > >> relocatable. In order to get that with CMake you'll likely need to use > > >> the BundleUtilities, though > > >> its been so long since I used those I don't know if they can handle > this > > >> scenario out of the box. > > > > > > Yes, that's what I'm trying to do -- well, I'm trying to do two > > > things. One is setup a build environment where kde apps like > desktoptojson > > > can run, the other is creating a bundle, preferably using the same > > > Qt. I got quite far by manually fixing up the applications built as > part > > > of kcoreaddons > > > > That would be fixed in kcoreaddons by extending the linker flags to > include > > the mentioned -Wl,-rpath,. There's no provisioning for this > > inside CMake afaik since its hard for it to guess what the intention is. > > CMake does automatically handle this. If a library being linked has @rpath > for its install ID, then CMake will insert the linker flag. This takes > care of > the build time rpath. And works for any library in target_link_libraries() > where CMake knows its full path. A -L/-l approach does not work, but that > is > usually done for system libraries, in which case we normally don't care > about > rpaths. > > This kind of thing isn't handled automatically at install time, and > requires > the INSTALL_RPATH property to be set. Thanks for correcting me - didn't see your first mail until now either. It seems I'm really out of touch with CMake these days :) So I guess KDE frameworks that generate development-tools lack the INSTALL_RPATH - at least that would explain the necessity to manually patch them. A relative path like you mentioned should work as long as Qt is installed in the same prefix as those tools - which is likely the common case. An end-user application then can either decide to be installed in the same way or it wants an app-bundle, then it could use an INSTALL_RPATH like @executable/../Frameworks and bunlde the Qt frameworks inside that subdirectory. Andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.jaentsch at in.tum.de Mon Nov 2 12:36:42 2015 From: michael.jaentsch at in.tum.de (=?UTF-8?Q?Michael_J=c3=a4ntsch?=) Date: Mon, 2 Nov 2015 18:36:42 +0100 Subject: [CMake] Visual Studio Cross Compile In-Reply-To: References: <44e308e464e4495c8ff063b9f7de58f3@in.tum.de> Message-ID: <56379F2A.8070100@in.tum.de> Hi, thanks for your replies. So it seems that Visual Studio is generally not a great idea for cross-compiling... So eclipse and some make system it's gonna be then. Any suggestions what works best? Coming from the Linux world, I obviously use Unix make, but there is also Ninja, nmake, ...? Michael On 02.11.2015 15:51, Parag Chandra wrote: > Hi Michael, > > Meant to reply sooner. As Nils pointed out, Visual Studio isn?t quite as flexible with cross-compilation as some other build systems. Having said that, it is indeed possible to cross-compile with Visual Studio, but there has to be a cross toolchain compatible with the IDE. Some examples of this include: > > Google?s Native Client - I have successfully targeted this environment with Visual Studio 2010 and Cmake; > > Windows Phone 8.1/10 - Have targeted this as well. While you may be thinking ?that?s just another flavor of Windows?, it is nevertheless cross-compiling for ARM; > > Several options for Android development: > Nvidia Tegra Studio; > Visual Studio 2015 - Microsoft now offers first-party support within VS 2015; > VS-Android; > > Commercial/paid add-ons that seem to support arbitrary GCC toolchains: > Visual GDB - This one may be your best bet for what you are trying to accomplish. Supports Linux, Android, Raspberry Pi, etc. out of the box, and they claim to have an extensibility model to add your own platforms; > WinGDB - similarly seems to support the GNU toolchain directly. > > Anyway, hopefully you get the idea. It is possible, but out of the box, you?re only going to be able to target Windows Phone and Android. > > > Parag Chandra > Senior Software Engineer, Mobile Team > Mobile: +1.919.824.1410 > > > > Ionic Security Inc. > 1170 Peachtree St. NE STE 400, Atlanta, GA 30309 > > > > > > > > > > > > > > On 10/29/15, 10:21 AM, "CMake on behalf of Michael Jaentsch" wrote: > >> Hi all, >> >> I have a question concerning Cross Compiling with CMake on Windows. I >> would like to use Visual Studio but this is not a must. What I do is, I >> setup a project for Cross Compiling on Linux and it works fine. Now I >> want to transfer to Windows, so I set up a toolchain file which sets the >> following variables: >> CMAKE_SYSTEM_NAME >> CMAKE_SYSTEM_PROCESSOR >> CMAKE_FIND_ROOT_PATH >> CMAKE_C_COMPILER >> CMAKE_CXX_COMPILER >> >> and some more stuff. Then I run my cmake gui (I tried 3.2 and 3.4rc2) >> on Windows and tell it to generate a project for Visual Studio 10 and to >> use the toolchain file. However, the output shows that it is trying to >> use the Visual Studio compiler and then subsequently the build fails >> because of some unkown compiler flags. >> >> So my question is: Is it even possible to do what I'm trying to do? Can >> I cross compile with Visual Studio or do I have to use a different >> generator? All I found in the documentation is that it is possible to >> cross compile with a toolchain file... >> >> Cheers >> Michael >> >> >> -- >> Technische Universit?t M?nchen >> Michael J?ntsch >> Fakult?t f?r Informatik >> Robotics and Embedded Systems >> Parkring 13 >> 85748 Garching bei M?nchen >> michael.jaentsch at in.tum.de >> www6.in.tum.de >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake -- Technische Universit?t M?nchen Michael J?ntsch Fakult?t f?r Informatik Robotics and Embedded Systems Boltzmannstr. 3 85748 Garching bei M?nchen michael.jaentsch at in.tum.de www6.in.tum.de From jay.custin at hpe.com Mon Nov 2 12:55:20 2015 From: jay.custin at hpe.com (Custin, Jay (CSC Sw Middleware)) Date: Mon, 2 Nov 2015 17:55:20 +0000 Subject: [CMake] =?windows-1252?q?CMake_on_OpenVMS_-_Bootstrap_CMake_compl?= =?windows-1252?q?aining_that_=93pid=5Ft_doesn=92t_exist_on_this_platform?= =?windows-1252?q?=3F=94?= In-Reply-To: References: Message-ID: Please disregard my query regarding pid_t. Apparently something ?lingered? around in my code environment. When I wiped out the code tree leaving nothing except my VMS-related modifications and rebuilt CMake it built without the pid_t error. Go figure. Back to trying to determine where the bootstrapped CMake of the CMake code (to generate the final ?image?) fails). JayC -------------- next part -------------- An HTML attachment was scrubbed... URL: From pgquiles at elpauer.org Mon Nov 2 14:45:58 2015 From: pgquiles at elpauer.org (Pau Garcia i Quiles) Date: Mon, 2 Nov 2015 20:45:58 +0100 Subject: [CMake] FOSDEM Desktops DevRoom 2016: Call for Participation Message-ID: FOSDEM Desktops DevRoom 2016 Call for Participation FOSDEM is one of the largest gatherings of Free Software contributors in the world and happens each February in Brussels (Belgium, Europe). One of the tracks will be the Desktops DevRoom (formerly known as ?CrossDesktop DevRoom?), which will host Desktop-related talks. We are now inviting proposals for talks about Free/Libre/Open-source Software on the topics of Desktop development, Desktop applications and interoperability amongst Desktop Environments. This is a unique opportunity to show novel ideas and developments to a wide technical audience. Topics accepted include, but are not limited to: - Open Desktops: Gnome, KDE, Unity, Enlightenment, XFCE, Razor, MATE, Cinnamon, ReactOS, etc - Closed desktops: Windows, Mac OS X, CDE, MorphOS, etc (when talking about a FLOSS topic) - Software development for the desktop - Development tools - Applications that enhance desktops - General desktop matters - Cross-platform software development - Web Talks can be very specific, such as the advantages/disadvantages of development with Qt on Wayland over X11/Mir; or as general as predictions for the fusion of Desktop and web in 5 years time. Topics that are of interest to the users and developers of all desktop environments are especially welcome. The FOSDEM 2015 schedule[1] might give you some inspiration. Submissions Please include the following information when submitting a proposal: - Your name - The title of your talk (please be descriptive, as titles will be listed with around 400 from other projects) - Short abstract of one or two paragraphs - Short bio (with photo) - Requested time: from 15 to 45 minutes. Normal duration is 30 minutes. Longer duration requests must be properly justified. You may be assigned LESS time than you request. How to submit All submissions are made in the Pentabarf event planning tool: https://penta.fosdem.org/submission/FOSDEM16 When submitting your talk, make sure to select the "Desktops" devroom as the "Track". Otherwise your talk will not be even considered for any devroom. If you already have a Pentabarf account from a previous year, even if your talk was not accepted, please reuse it. Create an account if, and only if, you don?t have one from a previous year. If you have any issues with Pentabarf, please contact pgquiles at elpauer dot org. Deadline The deadline for submissions is December 6th 2015. FOSDEM will be held on the weekend of January 30th and 31st 2015 and the Desktops DevRoom will take place on Sunday, January 31st 2015. We will contact every submitter with a "yes" or "no" before December 18th 2015. Recording permission The talks in the Desktops devroom will be audio and video recorded, and possibly streamed live too. By submitting a proposal you consent to be recorded and agree to license the content of your talk under a Creative Commons (CC-BY) license. If you want us to stop the recording in the Q & A part (should you have one), please tell us. We can do that but only for the Q & A part. More information The official communication channel for the Desktops DevRoom is its mailing list desktops-devroom at lists.fosdem.org. Use this page to manage your subscription: https://lists.fosdem.org/listinfo/desktops-devroom Organization The Desktops DevRoom 2016 is managed by a team representing the most notable open desktops: - Pau Garcia i Quiles, KDE - Christophe Fergeau, Gnome - Michael Zanetti, Unity - Philippe Caseiro, Enlightenment - J?rome Leclanche, Razor If you want to join the team, please contact pgquiles at elpauer dot org -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Mon Nov 2 15:26:41 2015 From: d3ck0r at gmail.com (J Decker) Date: Mon, 2 Nov 2015 12:26:41 -0800 Subject: [CMake] Visual Studio Cross Compile In-Reply-To: <56379F2A.8070100@in.tum.de> References: <44e308e464e4495c8ff063b9f7de58f3@in.tum.de> <56379F2A.8070100@in.tum.de> Message-ID: for windows platform using cmake, you just need mingw (mingw64 is probably better) On Mon, Nov 2, 2015 at 9:36 AM, Michael J?ntsch wrote: > Hi, > > thanks for your replies. So it seems that Visual Studio is generally not > a great idea for cross-compiling... > So eclipse and some make system it's gonna be then. Any suggestions what > works best? Coming from the Linux world, I obviously use Unix make, but > there is also Ninja, nmake, ...? > > Michael > > > On 02.11.2015 15:51, Parag Chandra wrote: >> Hi Michael, >> >> Meant to reply sooner. As Nils pointed out, Visual Studio isn?t quite as flexible with cross-compilation as some other build systems. Having said that, it is indeed possible to cross-compile with Visual Studio, but there has to be a cross toolchain compatible with the IDE. Some examples of this include: >> >> Google?s Native Client - I have successfully targeted this environment with Visual Studio 2010 and Cmake; >> >> Windows Phone 8.1/10 - Have targeted this as well. While you may be thinking ?that?s just another flavor of Windows?, it is nevertheless cross-compiling for ARM; >> >> Several options for Android development: >> Nvidia Tegra Studio; >> Visual Studio 2015 - Microsoft now offers first-party support within VS 2015; >> VS-Android; >> >> Commercial/paid add-ons that seem to support arbitrary GCC toolchains: >> Visual GDB - This one may be your best bet for what you are trying to accomplish. Supports Linux, Android, Raspberry Pi, etc. out of the box, and they claim to have an extensibility model to add your own platforms; >> WinGDB - similarly seems to support the GNU toolchain directly. >> >> Anyway, hopefully you get the idea. It is possible, but out of the box, you?re only going to be able to target Windows Phone and Android. >> >> >> Parag Chandra >> Senior Software Engineer, Mobile Team >> Mobile: +1.919.824.1410 >> >> >> >> Ionic Security Inc. >> 1170 Peachtree St. NE STE 400, Atlanta, GA 30309 >> >> >> >> >> >> >> >> >> >> >> >> >> >> On 10/29/15, 10:21 AM, "CMake on behalf of Michael Jaentsch" wrote: >> >>> Hi all, >>> >>> I have a question concerning Cross Compiling with CMake on Windows. I >>> would like to use Visual Studio but this is not a must. What I do is, I >>> setup a project for Cross Compiling on Linux and it works fine. Now I >>> want to transfer to Windows, so I set up a toolchain file which sets the >>> following variables: >>> CMAKE_SYSTEM_NAME >>> CMAKE_SYSTEM_PROCESSOR >>> CMAKE_FIND_ROOT_PATH >>> CMAKE_C_COMPILER >>> CMAKE_CXX_COMPILER >>> >>> and some more stuff. Then I run my cmake gui (I tried 3.2 and 3.4rc2) >>> on Windows and tell it to generate a project for Visual Studio 10 and to >>> use the toolchain file. However, the output shows that it is trying to >>> use the Visual Studio compiler and then subsequently the build fails >>> because of some unkown compiler flags. >>> >>> So my question is: Is it even possible to do what I'm trying to do? Can >>> I cross compile with Visual Studio or do I have to use a different >>> generator? All I found in the documentation is that it is possible to >>> cross compile with a toolchain file... >>> >>> Cheers >>> Michael >>> >>> >>> -- >>> Technische Universit?t M?nchen >>> Michael J?ntsch >>> Fakult?t f?r Informatik >>> Robotics and Embedded Systems >>> Parkring 13 >>> 85748 Garching bei M?nchen >>> michael.jaentsch at in.tum.de >>> www6.in.tum.de >>> -- >>> >>> Powered by www.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >>> >>> CMake Support: http://cmake.org/cmake/help/support.html >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/cmake > > -- > Technische Universit?t M?nchen > Michael J?ntsch > Fakult?t f?r Informatik > Robotics and Embedded Systems > Boltzmannstr. 3 > 85748 Garching bei M?nchen > michael.jaentsch at in.tum.de > www6.in.tum.de > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 gurenchan at gmail.com Tue Nov 3 08:11:42 2015 From: gurenchan at gmail.com (Owen Alanzo Hogarth) Date: Tue, 3 Nov 2015 21:11:42 +0800 Subject: [CMake] find module configuration not found Message-ID: I just ran into some difficulties. I migrated a development system to debian 8. I had a project on mac os x that built w/ no problems now I am running my cmake but I get this error: CMake Error at CMakeLists.txt:4 (FIND_PACKAGE): By not providing "FindOPENGL.cmake" in CMAKE_MODULE_PATH this project has asked CMake to find a package configuration file provided by "OPENGL", but CMake did not find one. Could not find a package configuration file provided by "OPENGL" with any of the following names: OPENGLConfig.cmake opengl-config.cmake Add the installation prefix of "OPENGL" to CMAKE_PREFIX_PATH or set "OPENGL_DIR" to a directory containing one of the above files. If "OPENGL" provides a separate development package or SDK, be sure it has been installed. -- Configuring incomplete, errors occurred! now it seems finding opengl was a deffault config file on mac os x but not so on linux. I have cmake 3.0.2-1 installed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From steinbach at scionics.de Tue Nov 3 08:10:54 2015 From: steinbach at scionics.de (Peter Steinbach) Date: Tue, 03 Nov 2015 14:10:54 +0100 Subject: [CMake] cmake needs 2 runs to find boost Message-ID: <1673808.u7i9PThpbx@schorle.mpi-cbg.de> Hi to all, I tested this with cmake 3.2.2 and 3.3.2 and still get the same problem. I'd like to use boost with gcc on windows 7 64bit. I installed boost and gcc with msys2 as I cannot use MSVC for the actual project I am looking into for this. the funny thing, if I use the attached CMakeLists.txt on the machine and call: ``` $ cmake -G "MSYS Makefiles" -DBOOST_ROOT=C:/msys64/mingw64 - DBOOST_LIBRARYDIR==C:/msys64/mingw64/lib .. -- The CXX compiler identification is GNU 4.9.2 -- Check for working CXX compiler: C:/msys64/usr/bin/g++.exe -- Check for working CXX compiler: C:/msys64/usr/bin/g++.exe -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done setting win specific stuff CMake Error at C:/Program Files (x86)/CMake/share/cmake-3.2/Modules/FindBoost.cmake:1182 (message): Unable to find the requested Boost libraries. Boost version: 1.57.0 Boost include path: C:/msys64/mingw64/include Could not find the following static Boost libraries: boost_filesystem boost_system No Boost libraries were found. You may need to set BOOST_LIBRARYDIR to the directory containing Boost libraries or BOOST_ROOT to the location of Boost. Call Stack (most recent call first): CMakeLists.txt:17 (FIND_PACKAGE) CMake Error at CMakeLists.txt:24 (MESSAGE): Boost not found (C:/msys64/mingw64) -- Configuring incomplete, errors occurred! See also "C:/msys64/home/steinbac/development/cmake_sandbox/find_boost/build/CMakeFiles/CMakeOutput.log". $ cmake -G "MSYS Makefiles" -DBOOST_ROOT=C:/msys64/mingw64 - DBOOST_LIBRARYDIR==C:/msys64/mingw64/lib .. setting win specific stuff Boost 1.57 found __ -- Configuring done -- Generating done -- Build files have been written to: C:/msys64/home/steinbac/development/cmake_sandbox/find_boost/build ``` I'd like to link statically to multithreaded libboost_*-mt.a from my app. But it proofes really hard to find Boost in the first place. Any ideas? Peter -------------- next part -------------- A non-text attachment was scrubbed... Name: CMakeLists.txt Type: text/x-cmake Size: 782 bytes Desc: not available URL: From petr.kmoch at gmail.com Tue Nov 3 08:34:01 2015 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Tue, 3 Nov 2015 14:34:01 +0100 Subject: [CMake] find module configuration not found In-Reply-To: References: Message-ID: Hi Owen, the find module which comes with CMake is called FindOpenGL, and is supposed to be used as: find_package(OpenGL ...) Note the case. From the error messages, it seems you're calling find_package(OPENGL). This could work on a case-insensitive system (which I believe Mac OS X uses by default), but would definitely not work on a case-sensitive one such as normal Linux filesystems. Petr On Tue, Nov 3, 2015 at 2:11 PM, Owen Alanzo Hogarth wrote: > I just ran into some difficulties. > > I migrated a development system to debian 8. > > I had a project on mac os x that built w/ no problems now I am running my > cmake but I get this error: > > CMake Error at CMakeLists.txt:4 (FIND_PACKAGE): > By not providing "FindOPENGL.cmake" in CMAKE_MODULE_PATH this project has > asked CMake to find a package configuration file provided by "OPENGL", > but > CMake did not find one. > > Could not find a package configuration file provided by "OPENGL" with any > of the following names: > > OPENGLConfig.cmake > opengl-config.cmake > > Add the installation prefix of "OPENGL" to CMAKE_PREFIX_PATH or set > "OPENGL_DIR" to a directory containing one of the above files. If > "OPENGL" > provides a separate development package or SDK, be sure it has been > installed. > > > -- Configuring incomplete, errors occurred! > > now it seems finding opengl was a deffault config file on mac os x but not > so on linux. > > I have cmake 3.0.2-1 installed. > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 gurenchan at gmail.com Tue Nov 3 09:37:12 2015 From: gurenchan at gmail.com (Owen Alanzo Hogarth) Date: Tue, 3 Nov 2015 22:37:12 +0800 Subject: [CMake] find module configuration not found In-Reply-To: References: Message-ID: That was definitely the problem. I had the wrong case.... This is something. One more question. Now I am getting a error: loop initial declarations are only allowed in C99 it's great that the compiler is watching out for me but I do want to stick to the C99 standard. All my code is formatted that way, how can I set it so that cmake passes that flag for this whole project? Do I have to add something to each CMakeLists.txt? On Tue, Nov 3, 2015 at 9:34 PM, Petr Kmoch wrote: > Hi Owen, > > the find module which comes with CMake is called FindOpenGL, and is > supposed to be used as: > > find_package(OpenGL ...) > > Note the case. From the error messages, it seems you're calling > find_package(OPENGL). This could work on a case-insensitive system (which I > believe Mac OS X uses by default), but would definitely not work on a > case-sensitive one such as normal Linux filesystems. > > Petr > > On Tue, Nov 3, 2015 at 2:11 PM, Owen Alanzo Hogarth > wrote: > >> I just ran into some difficulties. >> >> I migrated a development system to debian 8. >> >> I had a project on mac os x that built w/ no problems now I am running my >> cmake but I get this error: >> >> CMake Error at CMakeLists.txt:4 (FIND_PACKAGE): >> By not providing "FindOPENGL.cmake" in CMAKE_MODULE_PATH this project >> has >> asked CMake to find a package configuration file provided by "OPENGL", >> but >> CMake did not find one. >> >> Could not find a package configuration file provided by "OPENGL" with >> any >> of the following names: >> >> OPENGLConfig.cmake >> opengl-config.cmake >> >> Add the installation prefix of "OPENGL" to CMAKE_PREFIX_PATH or set >> "OPENGL_DIR" to a directory containing one of the above files. If >> "OPENGL" >> provides a separate development package or SDK, be sure it has been >> installed. >> >> >> -- Configuring incomplete, errors occurred! >> >> now it seems finding opengl was a deffault config file on mac os x but >> not so on linux. >> >> I have cmake 3.0.2-1 installed. >> >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Tue Nov 3 13:18:08 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 3 Nov 2015 13:18:08 -0500 Subject: [CMake] [ANNOUNCE] CMake 3.4.0-rc3 is now ready! Message-ID: I am proud to announce the third CMake 3.4 release candidate. Sources and binaries are available at: https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.4 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.4/release/3.4.html Some of the more significant features of CMake 3.4 are: * The "if()" command learned a new "TEST" operator that evaluates to true if a given test name has been defined by the "add_test()" command. See policy "CMP0064". * The "install(DIRECTORY)" command "DESTINATION" option learned to support "generator expressions". * The "install(FILES)" command "DESTINATION" option learned to support "generator expressions". * CMake learned to honor "*.manifest" source files with MSVC tools. Manifest files named as sources of ".exe" and ".dll" targets will be merged with linker-generated manifests and embedded in the binary. Deprecated and Removed Features: * The "CMakeExpandImportedTargets" module is now documented as deprecated. See module documentation for an explanation. * The "CMAKE_USE_RELATIVE_PATHS" variable no longer has any effect. Previously it was partially implemented and unreliable. CMake 3.4 Release Notes *********************** Changes made since CMake 3.3 include the following. New Features ============ Generators ---------- * The "Visual Studio 14 2015" generator learned to select a Windows 10 SDK based on the value of the "CMAKE_SYSTEM_VERSION" variable and the SDKs available on the host. * CMake learned rudimentary support for the Apple Swift language. When using the "Xcode" generator with Xcode 6.1 or higher, one may enable the "Swift" language with the "enable_language()" command or the "project()" command (this is an error with other generators or when Xcode is too old). Then one may list ".swift" source files in targets for compilation. Commands -------- * The "find_program()" command learned a "NAMES_PER_DIR" option to consider all given "NAMES" in each directory before moving on to the next directory. * The "get_filename_component()" command learned a new "BASE_DIR" subcommand. This is used to specify a base directory when calculating an absolute path from a relative path. * The "if()" command learned a new "TEST" operator that evaluates to true if a given test name has been defined by the "add_test()" command. See policy "CMP0064". * The "install(DIRECTORY)" command "DESTINATION" option learned to support "generator expressions". * The "install(FILES)" command "DESTINATION" option learned to support "generator expressions". * The "string()" command learned a new "APPEND" subcommand. Variables --------- * The Makefile Generators and the "Ninja" generator learned to add compiler launcher tools like distcc and ccache along with the compiler for "C" and "CXX" languages. See the "CMAKE__COMPILER_LAUNCHER" variable and "_COMPILER_LAUNCHER" target property for details. * New "CMAKE_LINK_SEARCH_START_STATIC" and "CMAKE_LINK_SEARCH_END_STATIC" variables were introduced to initialize the "LINK_SEARCH_START_STATIC" and "LINK_SEARCH_END_STATIC" target properties, respectively. Properties ---------- * Visual Studio Generators learned to support additonal target properties to customize projects for NVIDIA Nsight Tegra Visual Studio Edition: * "ANDROID_ANT_ADDITIONAL_OPTIONS" * "ANDROID_ARCH" * "ANDROID_ASSETS_DIRECTORIES" * "ANDROID_JAR_DEPENDENCIES" * "ANDROID_JAR_DIRECTORIES" * "ANDROID_JAVA_SOURCE_DIR" * "ANDROID_NATIVE_LIB_DEPENDENCIES" * "ANDROID_NATIVE_LIB_DIRECTORIES" * "ANDROID_PROCESS_MAX" * "ANDROID_PROGUARD" * "ANDROID_PROGUARD_CONFIG_PATH" * "ANDROID_SECURE_PROPS_PATH" * "ANDROID_SKIP_ANT_STEP" * "ANDROID_STL_TYPE" * The "ARCHIVE_OUTPUT_DIRECTORY", "LIBRARY_OUTPUT_DIRECTORY", and "RUNTIME_OUTPUT_DIRECTORY" target properties learned to support "generator expressions". * The "SOURCE_DIR" and "BINARY_DIR" target properties were introduced to allow project code to query where a target is defined. * The "OUTPUT_NAME" target property and its variants learned to support "generator expressions". * A "TARGET_MESSAGES" global property was added to tell the Makefile Generators whether to generate commands to print output after each target is completed. * On Windows with MS-compatible tools, CMake learned to optionally generate a module definition (".def") file for "SHARED" libraries. See the "WINDOWS_EXPORT_ALL_SYMBOLS" target property. Modules ------- * The "ExternalProject" module "ExternalProject_Add()" function "GIT_SUBMODULES" option now also limits the set of submodules that are initialized in addition to the prior behavior of limiting the set of submodules that are updated. * The "ExternalProject" module learned new "USES_TERMINAL" arguments for giving steps exclusive terminal access. This is useful with the "Ninja" generator to monitor CMake superbuild progress and prevent CPU oversubscription. * The "FindBISON" module "BISON_TARGET" macro learned a new "DEFINES_FILE" option to specify a custom output header to be generated. * The "FindHDF5" module learend a new "HDF5_PREFER_PARALLEL" option allowing users to specify that a parallel HDF5 tool is preferred if both are available. * The "FindIce" module now provides imported targets. * The "FindJava" module learned to optionally find the "idlj" and "jarsigner" tools. * The "FindOpenSSL" module now provides imported targets. * The "FindOpenSSL" module learned a new "OPENSSL_USE_STATIC_LIBS" option to search only for static libraries. * The "FindPkgConfig" learned a new "pkg_get_variable()" command which may be used to query for arbitrary variables from a package (such as for related tools or data and plugin install paths). * The "FindProtobuf" module gained a new "protobuf_generate_python()" function to generate python sources from ".proto" files. * The "FindTIFF" module learned to search separately for debug and release variants. * The "FindwxWidgets" module learned to support version requests. * The "FindXercesC" module learned to search separately for debug and release variants. * The "FindZLIB" module learned to search separately for debug and release variants. * The "GNUInstallDirs" module learned special default values for certain installation prefixes according to the GNU Coding Standards and the Filesystem Hierarchy Standard. * The "UseJava" module "add_jar" function learned to support response files (e.g. "@srcs.txt") for source specification. * The "UseJava" module "install_jar" function learned new "DESTINATION" and "COMPONENT" options to specify the corresponding "install()" command options. * The "UseJava" module gained a new "create_javah" function to create C headers from Java classes. Generator Expressions --------------------- * A new "$" "generator expression" has been added. CTest ----- * CTest learned to optionally measure the CPU load during parallel testing and avoid starting tests that may cause the load to exceed a given threshold. See the "ctest(1)" command "--test-load" option, the "TestLoad" setting of the CTest Test Step, the "CTEST_TEST_LOAD" variable, and the "TEST_LOAD" option of the "ctest_test()" command. * "ctest(1)" learned options "--test-output-size-passed" and "-- test- output-size-failed" to customize the limit on test output size submitted when running as a Dashboard Client. CPack ----- * The "CPackDeb" module learned to set package dependencies per component. See variables: * "CPACK_DEBIAN__PACKAGE_BREAKS" * "CPACK_DEBIAN__PACKAGE_CONFLICTS" * "CPACK_DEBIAN__PACKAGE_ENHANCES" * "CPACK_DEBIAN__PACKAGE_PREDEPENDS" * "CPACK_DEBIAN__PACKAGE_PROVIDES" * "CPACK_DEBIAN__PACKAGE_RECOMMENDS" * "CPACK_DEBIAN__PACKAGE_REPLACES" * "CPACK_DEBIAN__PACKAGE_SUGGESTS" * The "CPack" module learned to package empty directories. * The "CPack" module gained a new setting, "CPACK_VERBATIM_VARIABLES", which can be used to ensure the cpack program receives the settings' values exactly as they were set, even if they contain CMake-special characters. For compatibility, it's off by default. Other ----- * The "Compile Features" functionality is now aware of features supported by GNU C compilers on Windows. * CMake learned to honor "*.manifest" source files with MSVC tools. Manifest files named as sources of ".exe" and ".dll" targets will be merged with linker-generated manifests and embedded in the binary. * The Concurrent Fortran 77 compiler is now supported. Its "compiler id" is "CCur". * "cmake(1)" gained a new "--trace-expand" command line option that is like "--trace" but expands variable references in the output. Deprecated and Removed Features =============================== * The "CMakeExpandImportedTargets" module is now documented as deprecated. See module documentation for an explanation. * The "CMAKE_USE_RELATIVE_PATHS" variable no longer has any effect. Previously it was partially implemented and unreliable. Other Changes ============= * The "CheckFunctionExists", "CheckLibraryExists", "CheckSymbolExists", and "FindThreads" modules learned to work in environments where only CXX is enabled. * The "CPackDeb" module now correctly excludes symlinks during package checksum calculation. * The "CPackDeb" no longer uses fakeroot and system tar program for packaging. * The "CPack" module no longer mangles settings with CMake-special characters when they're used as defaults for other settings. The macro "cpack_set_if_not_set", which was responsible for this, is now deprecated. * CMake no longer links executables with flags to export symbols unless the "ENABLE_EXPORTS" target property is set. See policy "CMP0065". * The "SONAME" field is no longer set for "MODULE" libraries created with the "add_library()" command. "MODULE" libraries are meant for explicit dynamic loading at runtime. They cannot be linked so "SONAME" is not useful. * The internal "CMAKE__COMPILE_OBJECT" rule variable now substitutes compiler include flags in a separate "" placeholder instead of the main "" placeholder. -------------------------------------------------------------------------- Changes made since CMake 3.4.0-rc2: Andrew Shaitorov (1): VS: Add support for `.resw` files (#15811) Brad King (6): CTest: Fix regression in handling of a RUN_SERIAL test that fails Intel: Recognize MSVC version for Intel Fortran 2016 (#15809) Revert "cmQtAutoGenerators: Fix rcc invocation for Qt 5.0 and 5.1 (#15644)" find_program: Fix regression in finding an already-known path Help: Document target properties setting Info.plist fields (#15820) CMake 3.4.0-rc3 Christopher Dembia (1): Help: Add missing parenthesis in add_executable docs Raffi Enficiaud (1): CPackDEB: Use proper compression scheme for control.tar.gz From fifteenknots505 at gmail.com Tue Nov 3 15:54:53 2015 From: fifteenknots505 at gmail.com (Martin Weber) Date: Tue, 03 Nov 2015 21:54:53 +0100 Subject: [CMake] Unable to download older releases: Directory index no longer supported Message-ID: <5246474.rUNzs4a1SU@linux> Hi cmake developers, I hope some of the cmake developers will chime in here... The download site [1] seems to have been revamped. Since then, it does no longer allow to download older releases. If the devs decided to disable directory listings due to excessive download traffic caused by Jenkins instances, please let me know. I am the maintainer of a Jenkins-plugin [2], that invokes cmake to generate the build scripts. I recently added a feature to that plugin, which downloads a cmake binary (.tar.gz) from cmake.org and installs it for use of jenkins only. This feature seems to be very useful for people that run jenkins build nodes under windows or Linuxes that ship with older versions of cmake (e.g. RHEL-7 still ships with cmake 2.8.6). Since the revamp, the download feature fails [3]. Download traffic on cmake.org is caused by the following: - Jenkins backend crawler [4], runs every ~10 days on the download sites and detects newer releases of cmake and announces new versions to plugin users. - Jenkins slaves (aka worker nodes) that download from cmake.org. Downloads happen once per slave and per cmake version, but not per build [5]. It would be nice to keep the download feature working. TIA, Martin [1] http://www.cmake.org/files/ [2] https://wiki.jenkins-ci.org/display/JENKINS/cmakebuilder+Plugin [3] https://issues.jenkins-ci.org/browse/JENKINS-31371?focusedCommentId=240827&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-240827 [4] https://github.com/jenkinsci/backend-crawler/blob/master/cmake.groovy [5] https://github.com/jenkinsci/cmakebuilder-plugin/commit/1ed695b9c059ab5d70833f1938ecbe68d68a031b -- Cd wrttn wtht vwls s mch trsr. From stephan.menzel at gmail.com Wed Nov 4 04:31:55 2015 From: stephan.menzel at gmail.com (Stephan Menzel) Date: Wed, 4 Nov 2015 10:31:55 +0100 Subject: [CMake] Canonical way to amend location names Message-ID: Hello, I am currently bringing a rather complex CMake based build system up to speed with current versions and hope to get rid of old quirks and workarounds. One of which being the way I have to amend version information. It is primarily used in a MSVC11 scenario and contains a number of macros that wrap native CMake commands such as add_library. My add_library contains code like that: set(LIBSTRING "_${ARG_MAJOR}") set_target_properties(${name} PROPERTIES SUFFIX "${LIBSTRING}.dll") set_target_properties(${name} PROPERTIES IMPORT_SUFFIX "${LIBSTRING}.lib") get_target_property(location ${name} LOCATION) get_filename_component(location_we ${location} NAME_WE) get_filename_component(path ${location} PATH) set(pdbname "${path}/${location_we}.pdb") set(pdbdname "${path}/${location_we}_d.pdb") file(TO_NATIVE_PATH ${pdbname} result) file(TO_NATIVE_PATH ${pdbdname} dresult) set_target_properties(${name} PROPERTIES LINK_FLAGS_RELEASE "/PDB:\"${result}\"") set_target_properties(${name} PROPERTIES LINK_FLAGS_RELWITHDEBINFO "/PDB:\"${result}\"") set_target_properties(${name} PROPERTIES LINK_FLAGS_DEBUG "/PDB:\"${dresult}\"") This was used to maintain pdbs and add a "_d" suffix to dll names resulting from debug builds. Main purpose however was to amend the resulting artifact with LIBSTRING, which would transform a add_library(mylib ... ) yielding mylib.dll to MY_ADD_LIBRARY(mylib ... MAJOR 1 MINOR 0) yielding a mylib_1.dll There is quite an amount of code doing this and on recent CMake releases, not set to old policies this yields errors such as: The LOCATION property may not be read from target "mylib". Use the target name directly with add_custom_command, or use the generator expression $, as appropriate. So I would gladly change all this to reflect the "canonical way" to solve this, as long as it exists. So my questions are: Does it? Is this functionality available in CMake nowadays without own code or workarounds? If yes, what is it? If no, can I do this more elegantly without having to resort to old policies? Thanks for any advice, Stephan -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Wed Nov 4 09:55:10 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 04 Nov 2015 09:55:10 -0500 Subject: [CMake] Unable to download older releases: Directory index no longer supported In-Reply-To: <5246474.rUNzs4a1SU@linux> References: <5246474.rUNzs4a1SU@linux> Message-ID: <563A1C4E.1010900@kitware.com> On 11/03/2015 03:54 PM, Martin Weber wrote: > The download site [1] seems to have been revamped. Since then, it does no > longer allow to download older releases. The directory index was disabled but old direct links should still have worked. > If the devs decided to disable directory listings due to excessive download Our admins reported occasional mass downloads by various bots walking the indexed directory listing. > traffic caused by Jenkins instances, please let me know. I don't think that was it. The traffic you list sounds reasonable. > It would be nice to keep the download feature working. We've restored the indexing until another solution can be chosen. Thanks, -Brad From omnijack at gmail.com Wed Nov 4 10:23:57 2015 From: omnijack at gmail.com (Jack Stalnaker) Date: Wed, 4 Nov 2015 09:23:57 -0600 Subject: [CMake] detecting fortran c interface Message-ID: Hi, I see that there is a built-in FortranCInterface module that provides a lot of useful information for calling Fortran from C and C++. However, is there a module that does the opposite? Specifically, I need to check that the Fortran compiler supports calling C routines. In our autoconf script we do this by test linking a program like so: AC_LINK_IFELSE(AC_LANG_PROGRAM([],[use iso_c_binding])], [action-if-yes],[action-if-no]) which just attempts to compile and link a one line program "use iso_c_binding". I know I can simply recreate this in cmake, but if there is a module that does it already, or if FortranCInterface does it already, I'd like to avoid reinventing the wheel. Is there something that does this? --Jack -------------- next part -------------- An HTML attachment was scrubbed... URL: From fifteenknots505 at gmail.com Wed Nov 4 13:28:54 2015 From: fifteenknots505 at gmail.com (Martin Weber) Date: Wed, 04 Nov 2015 19:28:54 +0100 Subject: [CMake] Unable to download older releases: Directory index no longer supported In-Reply-To: <563A1C4E.1010900@kitware.com> References: <5246474.rUNzs4a1SU@linux> <563A1C4E.1010900@kitware.com> Message-ID: <2034206.iaPxAQyR2h@linux> Am Mittwoch, 4. November 2015, 09:55:10 schrieb Brad King: > On 11/03/2015 03:54 PM, Martin Weber wrote: > > The download site [1] seems to have been revamped. Since then, it does no > > longer allow to download older releases. > > The directory index was disabled but old direct links should still have > worked. Sure. But with the next crawler run, it did not find any download links and each jenkins installation forgot the old download links when they did its daily update. BTW, the crawler runs daily, not every 10 days, as earlier reported. [...] > > > It would be nice to keep the download feature working. > > We've restored the indexing until another solution can be chosen. Thank you for restoring index listing. Solutions could be - Selective index listing by user-agent header. - Hosting releases on bintray (it has a query API) Thank you! Martin -- Cd wrttn wtht vwls s mch trsr. From rwan.work at gmail.com Wed Nov 4 20:42:18 2015 From: rwan.work at gmail.com (Raymond Wan) Date: Thu, 5 Nov 2015 09:42:18 +0800 Subject: [CMake] Handling dependencies between projects Message-ID: Dear all, I know this is a frequent question on this mailing list, but I'm being a bit overwhelmed with information and not too sure which direction I should head. Basically, I have executables X and Y who are each top-level projects. They make use of library A. Library A in turn makes use of library B. Both A and B are libraries which are linked to, but they are also executables -- I compile with a temporary main () function in order to do some tests. That is, their CMakeLists.txt generate both a library and an executable. So, the dependencies are like this: X <-- A <-- B Y <-- A <-- B What I'm confused about are: 1) Should all 4 have their own Project () lines? 2) Should X and Y have ExternalProject () lines to A? 3) Should A have ExternalProject () lines to B? 4) Or maybe instead of ExternalProject (), I should use Add_Subdirectory ()? 5) Or should X and Y have Target_Include_Directories () to A; should A have a Target_Include_Directories () to B? ...or maybe something else? What I think is that they should all have their own Project (). And perhaps A and B should have Install () lines that install libraries into ${CMAKE_INSTALL_PREFIX}/lib/ and header files to ${CMAKE_INSTALL_PREFIX}/include/. Then, X, Y, and A needs Target_Include_Directories () to this path and *NOT* the where the source code of A and B reside. All this removes ExternalProject () from the picture... It's true what I'm including is mine but these libraries could be used separately by other programs (i.e., Y). I hope this is clear -- there are just too many options and the documentation is thorough but the difference between each seems small. At least too small for me to distinguish... Thank you! Ray From nikita.barawade at einfochips.com Thu Nov 5 02:05:18 2015 From: nikita.barawade at einfochips.com (Nikita Barawade) Date: Thu, 5 Nov 2015 07:05:18 +0000 Subject: [CMake] Cmake not working for VS13 Message-ID: Hi, New to cmake utility, I am trying to build sample program given here https://cognitivewaves.wordpress.com/cmake-and-visual-studio/ with VS13 on windows 7. Getting following error: CMake Error at CMakeLists.txt:5 (project): No CMAKE_C_COMPILER could be found. CMake Error at CMakeLists.txt:5 (project): No CMAKE_CXX_COMPILER could be found. I searched on Internet but not getting required info. Note: cmake version 3.4.0 using native compiler option to configure. Can anyone give some pointers ? CMake and Visual Studio | Cognitive Waves cognitivewaves.wordpress.com Introduction Visual Studio to CMake Mapping Example Source Structure Execute CMake Visual Studio Solution Explorer View Build and Run Regards, Nikita ************************************************************************************************************************************************************* eInfochips Business Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated. Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. ************************************************************************************************************************************************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: From steinbach at scionics.de Thu Nov 5 03:10:11 2015 From: steinbach at scionics.de (Peter Steinbach) Date: Thu, 05 Nov 2015 09:10:11 +0100 Subject: [CMake] cmake needs 2 runs to find boost In-Reply-To: <1673808.u7i9PThpbx@schorle.mpi-cbg.de> References: <1673808.u7i9PThpbx@schorle.mpi-cbg.de> Message-ID: <1628259.mK12dr5Fip@schorle.mpi-cbg.de> I guess, nobody has a hint on what to look at or what to try? Best, Peter On Tuesday, November 03, 2015 02:10:54 PM Peter Steinbach wrote: > Hi to all, > > I tested this with cmake 3.2.2 and 3.3.2 and still get the same problem. > I'd like to use boost with gcc on windows 7 64bit. I installed boost and gcc > with msys2 as I cannot use MSVC for the actual project I am looking into > for this. > > the funny thing, if I use the attached CMakeLists.txt on the machine and > call: ``` > $ cmake -G "MSYS Makefiles" -DBOOST_ROOT=C:/msys64/mingw64 - > DBOOST_LIBRARYDIR==C:/msys64/mingw64/lib .. > -- The CXX compiler identification is GNU 4.9.2 > -- Check for working CXX compiler: C:/msys64/usr/bin/g++.exe > -- Check for working CXX compiler: C:/msys64/usr/bin/g++.exe -- works > -- Detecting CXX compiler ABI info > -- Detecting CXX compiler ABI info - done > -- Detecting CXX compile features > -- Detecting CXX compile features - done > setting win specific stuff > CMake Error at C:/Program Files > (x86)/CMake/share/cmake-3.2/Modules/FindBoost.cmake:1182 (message): > Unable to find the requested Boost libraries. > > Boost version: 1.57.0 > > Boost include path: C:/msys64/mingw64/include > > Could not find the following static Boost libraries: > > boost_filesystem > boost_system > > No Boost libraries were found. You may need to set BOOST_LIBRARYDIR to > the directory containing Boost libraries or BOOST_ROOT to the location of > Boost. > Call Stack (most recent call first): > CMakeLists.txt:17 (FIND_PACKAGE) > > > CMake Error at CMakeLists.txt:24 (MESSAGE): > Boost not found (C:/msys64/mingw64) > > > -- Configuring incomplete, errors occurred! > See also > "C:/msys64/home/steinbac/development/cmake_sandbox/find_boost/build/CMakeFil > es/CMakeOutput.log". $ cmake -G "MSYS Makefiles" > -DBOOST_ROOT=C:/msys64/mingw64 - > DBOOST_LIBRARYDIR==C:/msys64/mingw64/lib .. > setting win specific stuff > Boost 1.57 found __ > -- Configuring done > -- Generating done > -- Build files have been written to: > C:/msys64/home/steinbac/development/cmake_sandbox/find_boost/build > ``` > > I'd like to link statically to multithreaded libboost_*-mt.a from my app. > But it proofes really hard to find Boost in the first place. > Any ideas? > > Peter -- Peter Steinbach, Dr. rer. nat. HPC Developer Scionics Computer Innovation GmbH L?scherstr. 16 01309 Dresden fon: +49 351 210 2882 fax: +49 351 210 1689 http://www.scionics.de Sitz der Gesellschaft: Dresden (Main office) Amtsgericht - Registergericht: Dresden HRB 20337 (Commercial Registry) Ust-IdNr.: DE813263791 (VAT ID Number) Gesch?ftsf?hrer: John Duperon, Jeff Oegema (Managing Directors) From benedikt.hegner at cern.ch Thu Nov 5 05:41:10 2015 From: benedikt.hegner at cern.ch (Benedikt Hegner) Date: Thu, 5 Nov 2015 11:41:10 +0100 Subject: [CMake] cmake needs 2 runs to find boost In-Reply-To: <1673808.u7i9PThpbx@schorle.mpi-cbg.de> References: <1673808.u7i9PThpbx@schorle.mpi-cbg.de> Message-ID: <563B3246.6030409@cern.ch> Hi Peter, as I don't use windows at all, this is just a very wild guess... Could it be that in the second run you actually don't use /CMake/share/cmake-3.2/Modules/FindBoost.cmake but boost-config.cmake, which it now finds in the cached environment of the first run? This assumes of course that you built boost w/ CMake and not bjam... Cheers, Benedikt On 03.11.2015 14:10, Peter Steinbach wrote: > Hi to all, > > I tested this with cmake 3.2.2 and 3.3.2 and still get the same problem. > I'd like to use boost with gcc on windows 7 64bit. I installed boost and gcc > with msys2 as I cannot use MSVC for the actual project I am looking into for > this. > > the funny thing, if I use the attached CMakeLists.txt on the machine and call: > ``` > $ cmake -G "MSYS Makefiles" -DBOOST_ROOT=C:/msys64/mingw64 - > DBOOST_LIBRARYDIR==C:/msys64/mingw64/lib .. > -- The CXX compiler identification is GNU 4.9.2 > -- Check for working CXX compiler: C:/msys64/usr/bin/g++.exe > -- Check for working CXX compiler: C:/msys64/usr/bin/g++.exe -- works > -- Detecting CXX compiler ABI info > -- Detecting CXX compiler ABI info - done > -- Detecting CXX compile features > -- Detecting CXX compile features - done > setting win specific stuff > CMake Error at C:/Program Files > (x86)/CMake/share/cmake-3.2/Modules/FindBoost.cmake:1182 (message): > Unable to find the requested Boost libraries. > > Boost version: 1.57.0 > > Boost include path: C:/msys64/mingw64/include > > Could not find the following static Boost libraries: > > boost_filesystem > boost_system > > No Boost libraries were found. You may need to set BOOST_LIBRARYDIR to the > directory containing Boost libraries or BOOST_ROOT to the location of > Boost. > Call Stack (most recent call first): > CMakeLists.txt:17 (FIND_PACKAGE) > > > CMake Error at CMakeLists.txt:24 (MESSAGE): > Boost not found (C:/msys64/mingw64) > > > -- Configuring incomplete, errors occurred! > See also > "C:/msys64/home/steinbac/development/cmake_sandbox/find_boost/build/CMakeFiles/CMakeOutput.log". > $ cmake -G "MSYS Makefiles" -DBOOST_ROOT=C:/msys64/mingw64 - > DBOOST_LIBRARYDIR==C:/msys64/mingw64/lib .. > setting win specific stuff > Boost 1.57 found __ > -- Configuring done > -- Generating done > -- Build files have been written to: > C:/msys64/home/steinbac/development/cmake_sandbox/find_boost/build > ``` > > I'd like to link statically to multithreaded libboost_*-mt.a from my app. But > it proofes really hard to find Boost in the first place. > Any ideas? > > Peter > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mohammedrashadkm at gmail.com Thu Nov 5 06:27:05 2015 From: mohammedrashadkm at gmail.com (Rashad M) Date: Thu, 5 Nov 2015 12:27:05 +0100 Subject: [CMake] [CDash] CTEST_CUSTOM_WARNING_EXECPTION Message-ID: Hello all, I have CTestCustom.cmake.in file in source tree with the following contents https://git.orfeo-toolbox.org/otb.git/blob/refs/heads/develop:/CMake/CTestCustom.cmake.in during ctest build CTestCustom.cmake file is getting generated inside the build tree. But however the warnings are not filtered out on the dashboard. For instance, see the dashboard submission http://dash.orfeo-toolbox.org/viewBuildError.php?type=1&buildid=206112 and see the exception for vcl_deprecated_header https://git.orfeo-toolbox.org/otb.git/blob/refs/heads/develop:/CMake/CTestCustom.cmake.in#l69 The warning appears on dashobard anyway. Can someone point me in the right direction. ? Thanks in advance. CMake Version: 2.8.12.2 CDash Version: 2.2.3 uname -a Linux ubuntu 3.13.0-65-generic #106-Ubuntu SMP Fri Oct 2 22:08:27 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux -- Regards, Rashad -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Thu Nov 5 07:30:33 2015 From: DLRdave at aol.com (David Cole) Date: Thu, 5 Nov 2015 07:30:33 -0500 Subject: [CMake] Cmake not working for VS13 In-Reply-To: References: Message-ID: What version of Visual Studio do you have installed? On Thursday, November 5, 2015, Nikita Barawade < nikita.barawade at einfochips.com> wrote: > Hi, > > > New to cmake utility, > > I am trying to build sample program given here > https://cognitivewaves.wordpress.com/cmake-and-visual-studio/ with VS13 > on windows 7. > > Getting following error: > > CMake Error at CMakeLists.txt:5 (project): No CMAKE_C_COMPILER could be > found. > > CMake Error at CMakeLists.txt:5 (project): No CMAKE_CXX_COMPILER could be > found. > > > I searched on Internet but not getting required info. > > > Note: > > cmake version 3.4.0 > > using native compiler option to configure. > > > > Can anyone give some pointers ? > > > CMake and Visual Studio | Cognitive Waves > > cognitivewaves.wordpress.com > Introduction Visual Studio to CMake Mapping Example Source Structure > Execute CMake Visual Studio Solution Explorer View Build and Run > > > > Regards, > Nikita > > ************************************************************************************************************************************************************* > eInfochips Business Disclaimer: This e-mail message and all attachments > transmitted with it are intended solely for the use of the addressee and > may contain legally privileged and confidential information. If the reader > of this message is not the intended recipient, or an employee or agent > responsible for delivering this message to the intended recipient, you are > hereby notified that any dissemination, distribution, copying, or other use > of this message or its attachments is strictly prohibited. If you have > received this message in error, please notify the sender immediately by > replying to this message and please delete it from your computer. Any views > expressed in this message are those of the individual sender unless > otherwise stated. Company has taken enough precautions to prevent the > spread of viruses. However the company accepts no liability for any damage > caused by any virus transmitted by this email. > ************************************************************************************************************************************************************* > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steinbach at scionics.de Thu Nov 5 07:41:33 2015 From: steinbach at scionics.de (Peter Steinbach) Date: Thu, 05 Nov 2015 13:41:33 +0100 Subject: [CMake] cmake needs 2 runs to find boost In-Reply-To: <563B3246.6030409@cern.ch> References: <1673808.u7i9PThpbx@schorle.mpi-cbg.de> <563B3246.6030409@cern.ch> Message-ID: <3127961.sqCQkrRBnt@schorle.mpi-cbg.de> Hi Benedikt, interesting thought, however I wonder why cmake is then capable of deducing the right boost version and include path. Just inside the first error message, I see: (x86)/CMake/share/cmake-3.2/Modules/FindBoost.cmake:1182 (message): > > Unable to find the requested Boost libraries. > > > > Boost version: 1.57.0 > > > > Boost include path: C:/msys64/mingw64/include > > > > Could not find the following static Boost libraries: > > boost_filesystem > > boost_system strange, isn't it? Peter On Thursday, November 05, 2015 11:41:10 AM Benedikt Hegner wrote: > Hi Peter, > > as I don't use windows at all, this is just a very wild guess... > > Could it be that in the second run you actually don't use > /CMake/share/cmake-3.2/Modules/FindBoost.cmake > but boost-config.cmake, which it now finds in the cached environment of > the first run? > > This assumes of course that you built boost w/ CMake and not bjam... > > Cheers, > Benedikt > > On 03.11.2015 14:10, Peter Steinbach wrote: > > Hi to all, > > > > I tested this with cmake 3.2.2 and 3.3.2 and still get the same problem. > > I'd like to use boost with gcc on windows 7 64bit. I installed boost and > > gcc with msys2 as I cannot use MSVC for the actual project I am looking > > into for this. > > > > the funny thing, if I use the attached CMakeLists.txt on the machine and > > call: ``` > > $ cmake -G "MSYS Makefiles" -DBOOST_ROOT=C:/msys64/mingw64 - > > DBOOST_LIBRARYDIR==C:/msys64/mingw64/lib .. > > -- The CXX compiler identification is GNU 4.9.2 > > -- Check for working CXX compiler: C:/msys64/usr/bin/g++.exe > > -- Check for working CXX compiler: C:/msys64/usr/bin/g++.exe -- works > > -- Detecting CXX compiler ABI info > > -- Detecting CXX compiler ABI info - done > > -- Detecting CXX compile features > > -- Detecting CXX compile features - done > > setting win specific stuff > > CMake Error at C:/Program Files > > > > (x86)/CMake/share/cmake-3.2/Modules/FindBoost.cmake:1182 (message): > > Unable to find the requested Boost libraries. > > > > Boost version: 1.57.0 > > > > Boost include path: C:/msys64/mingw64/include > > > > Could not find the following static Boost libraries: > > boost_filesystem > > boost_system > > > > No Boost libraries were found. You may need to set BOOST_LIBRARYDIR to > > the > > directory containing Boost libraries or BOOST_ROOT to the location of > > Boost. > > > > Call Stack (most recent call first): > > CMakeLists.txt:17 (FIND_PACKAGE) > > > > CMake Error at CMakeLists.txt:24 (MESSAGE): > > Boost not found (C:/msys64/mingw64) > > > > -- Configuring incomplete, errors occurred! > > See also > > "C:/msys64/home/steinbac/development/cmake_sandbox/find_boost/build/CMakeF > > iles/CMakeOutput.log". $ cmake -G "MSYS Makefiles" > > -DBOOST_ROOT=C:/msys64/mingw64 - > > DBOOST_LIBRARYDIR==C:/msys64/mingw64/lib .. > > setting win specific stuff > > Boost 1.57 found __ > > -- Configuring done > > -- Generating done > > -- Build files have been written to: > > C:/msys64/home/steinbac/development/cmake_sandbox/find_boost/build > > ``` > > > > I'd like to link statically to multithreaded libboost_*-mt.a from my app. > > But it proofes really hard to find Boost in the first place. > > Any ideas? > > > > Peter -- Peter Steinbach, Dr. rer. nat. HPC Developer Scionics Computer Innovation GmbH L?scherstr. 16 01309 Dresden fon: +49 351 210 2882 fax: +49 351 210 1689 http://www.scionics.de Sitz der Gesellschaft: Dresden (Main office) Amtsgericht - Registergericht: Dresden HRB 20337 (Commercial Registry) Ust-IdNr.: DE813263791 (VAT ID Number) Gesch?ftsf?hrer: John Duperon, Jeff Oegema (Managing Directors) From DLRdave at aol.com Thu Nov 5 07:46:39 2015 From: DLRdave at aol.com (David Cole) Date: Thu, 5 Nov 2015 07:46:39 -0500 Subject: [CMake] [CDash] CTEST_CUSTOM_WARNING_EXECPTION In-Reply-To: References: Message-ID: Does your ctest -S script call ctest_read_custom_files https://cmake.org/cmake/help/v3.4/command/ctest_read_custom_files.html after ctest_configure? On Thursday, November 5, 2015, Rashad M wrote: > Hello all, > > I have CTestCustom.cmake.in file in source tree with the following > contents > > > https://git.orfeo-toolbox.org/otb.git/blob/refs/heads/develop:/CMake/CTestCustom.cmake.in > > during ctest build CTestCustom.cmake file is getting generated inside the > build tree. > > But however the warnings are not filtered out on the dashboard. For > instance, see the dashboard submission > http://dash.orfeo-toolbox.org/viewBuildError.php?type=1&buildid=206112 > > and see the exception for vcl_deprecated_header > > > https://git.orfeo-toolbox.org/otb.git/blob/refs/heads/develop:/CMake/CTestCustom.cmake.in#l69 > > The warning appears on dashobard anyway. Can someone point me in the right > direction. ? > > Thanks in advance. > > > CMake Version: > 2.8.12.2 > > CDash Version: > 2.2.3 > > uname -a > Linux ubuntu > > 3.13.0-65-generic #106-Ubuntu SMP Fri Oct 2 22:08:27 UTC 2015 x86_64 > x86_64 x86_64 GNU/Linux > -- > Regards, > Rashad > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikita.barawade at einfochips.com Thu Nov 5 07:50:39 2015 From: nikita.barawade at einfochips.com (Nikita Barawade) Date: Thu, 5 Nov 2015 12:50:39 +0000 Subject: [CMake] Cmake not working for VS13 In-Reply-To: References: , Message-ID: Hi, Thanks for reply . I am using visual studio 13. I managed to get it done , I had to repair Visual studio . Regards, Nikita Barawade Engineer | PES ________________________________ From: David Cole Sent: 05 November 2015 06:00 PM To: Nikita Barawade Cc: cmake at cmake.org Subject: Re: [CMake] Cmake not working for VS13 What version of Visual Studio do you have installed? On Thursday, November 5, 2015, Nikita Barawade > wrote: Hi, New to cmake utility, I am trying to build sample program given here https://cognitivewaves.wordpress.com/cmake-and-visual-studio/ with VS13 on windows 7. Getting following error: CMake Error at CMakeLists.txt:5 (project): No CMAKE_C_COMPILER could be found. CMake Error at CMakeLists.txt:5 (project): No CMAKE_CXX_COMPILER could be found. I searched on Internet but not getting required info. Note: cmake version 3.4.0 using native compiler option to configure. Can anyone give some pointers ? CMake and Visual Studio | Cognitive Waves cognitivewaves.wordpress.com Introduction Visual Studio to CMake Mapping Example Source Structure Execute CMake Visual Studio Solution Explorer View Build and Run Regards, Nikita ************************************************************************************************************************************************************* eInfochips Business Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated. Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. ************************************************************************************************************************************************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: From steinbach at scionics.de Thu Nov 5 08:26:25 2015 From: steinbach at scionics.de (Peter Steinbach) Date: Thu, 05 Nov 2015 14:26:25 +0100 Subject: [CMake] cmake needs 2 runs to find boost In-Reply-To: <3127961.sqCQkrRBnt@schorle.mpi-cbg.de> References: <1673808.u7i9PThpbx@schorle.mpi-cbg.de> <563B3246.6030409@cern.ch> <3127961.sqCQkrRBnt@schorle.mpi-cbg.de> Message-ID: <3807206.1Xz3Ss7Xex@schorle.mpi-cbg.de> Hi to all, ok, I tried the attached minimal CMakeLists.txt again and found out that it fails in the way I described only with the "MSYS Makefiles" generator. If I use the same CMakeLists.txt without a custom generator (so MSVS is the default IIRC), the libraries are found alright! Any ideas? Best, Peter On Thursday, November 05, 2015 01:41:33 PM Peter Steinbach wrote: > Hi Benedikt, > > interesting thought, however I wonder why cmake is then capable of deducing > the right boost version and include path. Just inside the first error > message, I see: > > (x86)/CMake/share/cmake-3.2/Modules/FindBoost.cmake:1182 (message): > > > Unable to find the requested Boost libraries. > > > > > > Boost version: 1.57.0 > > > > > > Boost include path: C:/msys64/mingw64/include > > > > > > Could not find the following static Boost libraries: > > > boost_filesystem > > > boost_system > > strange, isn't it? > Peter > > On Thursday, November 05, 2015 11:41:10 AM Benedikt Hegner wrote: > > Hi Peter, > > > > as I don't use windows at all, this is just a very wild guess... > > > > Could it be that in the second run you actually don't use > > > > /CMake/share/cmake-3.2/Modules/FindBoost.cmake > > > > but boost-config.cmake, which it now finds in the cached environment of > > the first run? > > > > This assumes of course that you built boost w/ CMake and not bjam... > > > > Cheers, > > > > Benedikt > > > > On 03.11.2015 14:10, Peter Steinbach wrote: > > > Hi to all, > > > > > > I tested this with cmake 3.2.2 and 3.3.2 and still get the same problem. > > > I'd like to use boost with gcc on windows 7 64bit. I installed boost and > > > gcc with msys2 as I cannot use MSVC for the actual project I am looking > > > into for this. > > > > > > the funny thing, if I use the attached CMakeLists.txt on the machine and > > > call: ``` > > > $ cmake -G "MSYS Makefiles" -DBOOST_ROOT=C:/msys64/mingw64 - > > > DBOOST_LIBRARYDIR==C:/msys64/mingw64/lib .. > > > -- The CXX compiler identification is GNU 4.9.2 > > > -- Check for working CXX compiler: C:/msys64/usr/bin/g++.exe > > > -- Check for working CXX compiler: C:/msys64/usr/bin/g++.exe -- works > > > -- Detecting CXX compiler ABI info > > > -- Detecting CXX compiler ABI info - done > > > -- Detecting CXX compile features > > > -- Detecting CXX compile features - done > > > setting win specific stuff > > > CMake Error at C:/Program Files > > > > > > (x86)/CMake/share/cmake-3.2/Modules/FindBoost.cmake:1182 (message): > > > Unable to find the requested Boost libraries. > > > > > > Boost version: 1.57.0 > > > > > > Boost include path: C:/msys64/mingw64/include > > > > > > Could not find the following static Boost libraries: > > > boost_filesystem > > > boost_system > > > > > > No Boost libraries were found. You may need to set BOOST_LIBRARYDIR > > > to > > > the > > > directory containing Boost libraries or BOOST_ROOT to the location of > > > Boost. > > > > > > Call Stack (most recent call first): > > > CMakeLists.txt:17 (FIND_PACKAGE) > > > > > > CMake Error at CMakeLists.txt:24 (MESSAGE): > > > Boost not found (C:/msys64/mingw64) > > > > > > -- Configuring incomplete, errors occurred! > > > See also > > > "C:/msys64/home/steinbac/development/cmake_sandbox/find_boost/build/CMak > > > eF > > > iles/CMakeOutput.log". $ cmake -G "MSYS Makefiles" > > > -DBOOST_ROOT=C:/msys64/mingw64 - > > > DBOOST_LIBRARYDIR==C:/msys64/mingw64/lib .. > > > setting win specific stuff > > > Boost 1.57 found __ > > > -- Configuring done > > > -- Generating done > > > -- Build files have been written to: > > > C:/msys64/home/steinbac/development/cmake_sandbox/find_boost/build > > > ``` > > > > > > I'd like to link statically to multithreaded libboost_*-mt.a from my > > > app. > > > But it proofes really hard to find Boost in the first place. > > > Any ideas? > > > > > > Peter -- Peter Steinbach, Dr. rer. nat. HPC Developer Scionics Computer Innovation GmbH L?scherstr. 16 01309 Dresden fon: +49 351 210 2882 fax: +49 351 210 1689 http://www.scionics.de Sitz der Gesellschaft: Dresden (Main office) Amtsgericht - Registergericht: Dresden HRB 20337 (Commercial Registry) Ust-IdNr.: DE813263791 (VAT ID Number) Gesch?ftsf?hrer: John Duperon, Jeff Oegema (Managing Directors) -------------- next part -------------- A non-text attachment was scrubbed... Name: CMakeLists.txt Type: text/x-cmake Size: 696 bytes Desc: not available URL: From mohammedrashadkm at gmail.com Thu Nov 5 10:01:56 2015 From: mohammedrashadkm at gmail.com (Rashad M) Date: Thu, 5 Nov 2015 16:01:56 +0100 Subject: [CMake] [CDash] CTEST_CUSTOM_WARNING_EXECPTION In-Reply-To: References: Message-ID: yes. On Thu, Nov 5, 2015 at 1:46 PM, David Cole wrote: > Does your ctest -S script call ctest_read_custom_files > https://cmake.org/cmake/help/v3.4/command/ctest_read_custom_files.html > after ctest_configure? > > > On Thursday, November 5, 2015, Rashad M > wrote: > >> Hello all, >> >> I have CTestCustom.cmake.in file in source tree with the following >> contents >> >> >> https://git.orfeo-toolbox.org/otb.git/blob/refs/heads/develop:/CMake/CTestCustom.cmake.in >> >> during ctest build CTestCustom.cmake file is getting generated inside the >> build tree. >> >> But however the warnings are not filtered out on the dashboard. For >> instance, see the dashboard submission >> http://dash.orfeo-toolbox.org/viewBuildError.php?type=1&buildid=206112 >> >> and see the exception for vcl_deprecated_header >> >> >> https://git.orfeo-toolbox.org/otb.git/blob/refs/heads/develop:/CMake/CTestCustom.cmake.in#l69 >> >> The warning appears on dashobard anyway. Can someone point me in the >> right direction. ? >> >> Thanks in advance. >> >> >> CMake Version: >> 2.8.12.2 >> >> CDash Version: >> 2.2.3 >> >> uname -a >> Linux ubuntu >> >> 3.13.0-65-generic #106-Ubuntu SMP Fri Oct 2 22:08:27 UTC 2015 x86_64 >> x86_64 x86_64 GNU/Linux >> -- >> Regards, >> Rashad >> > -- Regards, Rashad -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Thu Nov 5 10:49:47 2015 From: DLRdave at aol.com (David Cole) Date: Thu, 5 Nov 2015 10:49:47 -0500 Subject: [CMake] [CDash] CTEST_CUSTOM_WARNING_EXECPTION In-Reply-To: References: Message-ID: Looks to me like it might be (I'm hopeful) working at ignoring the line which matches the expression ".*vcl_deprecated_header.h.*" ... But then, the following line is: # warning "deprecated" Since that line does not match any of your expressions, maybe that's the one triggering this warning slipping through as unignored? HTH, D On Thu, Nov 5, 2015 at 10:01 AM, Rashad M wrote: > yes. > > On Thu, Nov 5, 2015 at 1:46 PM, David Cole wrote: >> >> Does your ctest -S script call ctest_read_custom_files >> https://cmake.org/cmake/help/v3.4/command/ctest_read_custom_files.html after >> ctest_configure? >> >> >> On Thursday, November 5, 2015, Rashad M >> wrote: >>> >>> Hello all, >>> >>> I have CTestCustom.cmake.in file in source tree with the following >>> contents >>> >>> >>> https://git.orfeo-toolbox.org/otb.git/blob/refs/heads/develop:/CMake/CTestCustom.cmake.in >>> >>> during ctest build CTestCustom.cmake file is getting generated inside the >>> build tree. >>> >>> But however the warnings are not filtered out on the dashboard. For >>> instance, see the dashboard submission >>> http://dash.orfeo-toolbox.org/viewBuildError.php?type=1&buildid=206112 >>> >>> and see the exception for vcl_deprecated_header >>> >>> >>> https://git.orfeo-toolbox.org/otb.git/blob/refs/heads/develop:/CMake/CTestCustom.cmake.in#l69 >>> >>> The warning appears on dashobard anyway. Can someone point me in the >>> right direction. ? >>> >>> Thanks in advance. >>> >>> >>> CMake Version: >>> 2.8.12.2 >>> >>> CDash Version: >>> 2.2.3 >>> >>> uname -a >>> Linux ubuntu >>> >>> 3.13.0-65-generic #106-Ubuntu SMP Fri Oct 2 22:08:27 UTC 2015 x86_64 >>> x86_64 x86_64 GNU/Linux >>> -- >>> Regards, >>> Rashad > > > > > -- > Regards, > Rashad From steinbach at scionics.de Thu Nov 5 11:29:16 2015 From: steinbach at scionics.de (Peter Steinbach) Date: Thu, 05 Nov 2015 17:29:16 +0100 Subject: [CMake] Fwd: Re: cmake needs 2 runs to find boost Message-ID: <1921165.Wu4ixSjSQz@schorle.mpi-cbg.de> ---------- Forwarded Message ---------- Subject: Re: [CMake] cmake needs 2 runs to find boost Date: Thursday, November 05, 2015, 04:41:51 PM From: Andreas Naumann To: Peter Steinbach Hey Peter, It is not a solution, but I would set Boost_DEBUG to ON and compare the output of the first and the second cmake run. Andreas Am 05.11.2015 um 14:26 schrieb Peter Steinbach: > Hi to all, > > ok, I tried the attached minimal CMakeLists.txt again and found out that it > fails in the way I described only with the "MSYS Makefiles" generator. If I > use the same CMakeLists.txt without a custom generator (so MSVS is the default > IIRC), the libraries are found alright! > > Any ideas? > Best, > Peter > > On Thursday, November 05, 2015 01:41:33 PM Peter Steinbach wrote: >> Hi Benedikt, >> >> interesting thought, however I wonder why cmake is then capable of deducing >> the right boost version and include path. Just inside the first error >> message, I see: >> >> (x86)/CMake/share/cmake-3.2/Modules/FindBoost.cmake:1182 (message): >>>> Unable to find the requested Boost libraries. >>>> >>>> Boost version: 1.57.0 >>>> >>>> Boost include path: C:/msys64/mingw64/include >>>> >>>> Could not find the following static Boost libraries: >>>> boost_filesystem >>>> boost_system >> strange, isn't it? >> Peter >> >> On Thursday, November 05, 2015 11:41:10 AM Benedikt Hegner wrote: >>> Hi Peter, >>> >>> as I don't use windows at all, this is just a very wild guess... >>> >>> Could it be that in the second run you actually don't use >>> >>> /CMake/share/cmake-3.2/Modules/FindBoost.cmake >>> >>> but boost-config.cmake, which it now finds in the cached environment of >>> the first run? >>> >>> This assumes of course that you built boost w/ CMake and not bjam... >>> >>> Cheers, >>> >>> Benedikt >>> >>> On 03.11.2015 14:10, Peter Steinbach wrote: >>>> Hi to all, >>>> >>>> I tested this with cmake 3.2.2 and 3.3.2 and still get the same problem. >>>> I'd like to use boost with gcc on windows 7 64bit. I installed boost and >>>> gcc with msys2 as I cannot use MSVC for the actual project I am looking >>>> into for this. >>>> >>>> the funny thing, if I use the attached CMakeLists.txt on the machine and >>>> call: ``` >>>> $ cmake -G "MSYS Makefiles" -DBOOST_ROOT=C:/msys64/mingw64 - >>>> DBOOST_LIBRARYDIR==C:/msys64/mingw64/lib .. >>>> -- The CXX compiler identification is GNU 4.9.2 >>>> -- Check for working CXX compiler: C:/msys64/usr/bin/g++.exe >>>> -- Check for working CXX compiler: C:/msys64/usr/bin/g++.exe -- works >>>> -- Detecting CXX compiler ABI info >>>> -- Detecting CXX compiler ABI info - done >>>> -- Detecting CXX compile features >>>> -- Detecting CXX compile features - done >>>> setting win specific stuff >>>> CMake Error at C:/Program Files >>>> >>>> (x86)/CMake/share/cmake-3.2/Modules/FindBoost.cmake:1182 (message): >>>> Unable to find the requested Boost libraries. >>>> >>>> Boost version: 1.57.0 >>>> >>>> Boost include path: C:/msys64/mingw64/include >>>> >>>> Could not find the following static Boost libraries: >>>> boost_filesystem >>>> boost_system >>>> >>>> No Boost libraries were found. You may need to set BOOST_LIBRARYDIR >>>> to >>>> the >>>> directory containing Boost libraries or BOOST_ROOT to the location of >>>> Boost. >>>> >>>> Call Stack (most recent call first): >>>> CMakeLists.txt:17 (FIND_PACKAGE) >>>> >>>> CMake Error at CMakeLists.txt:24 (MESSAGE): >>>> Boost not found (C:/msys64/mingw64) >>>> >>>> -- Configuring incomplete, errors occurred! >>>> See also >>>> "C:/msys64/home/steinbac/development/cmake_sandbox/find_boost/build/CMak >>>> eF >>>> iles/CMakeOutput.log". $ cmake -G "MSYS Makefiles" >>>> -DBOOST_ROOT=C:/msys64/mingw64 - >>>> DBOOST_LIBRARYDIR==C:/msys64/mingw64/lib .. >>>> setting win specific stuff >>>> Boost 1.57 found __ >>>> -- Configuring done >>>> -- Generating done >>>> -- Build files have been written to: >>>> C:/msys64/home/steinbac/development/cmake_sandbox/find_boost/build >>>> ``` >>>> >>>> I'd like to link statically to multithreaded libboost_*-mt.a from my >>>> app. >>>> But it proofes really hard to find Boost in the first place. >>>> Any ideas? >>>> >>>> Peter > > ----------------------------------------- -- Peter Steinbach, Dr. rer. nat. HPC Developer Scionics Computer Innovation GmbH L?scherstr. 16 01309 Dresden fon: +49 351 210 2882 fax: +49 351 210 1689 http://www.scionics.de Sitz der Gesellschaft: Dresden (Main office) Amtsgericht - Registergericht: Dresden HRB 20337 (Commercial Registry) Ust-IdNr.: DE813263791 (VAT ID Number) Gesch?ftsf?hrer: John Duperon, Jeff Oegema (Managing Directors) From jay.custin at hpe.com Thu Nov 5 13:28:19 2015 From: jay.custin at hpe.com (Custin, Jay (CSC Sw Middleware)) Date: Thu, 5 Nov 2015 18:28:19 +0000 Subject: [CMake] Question about the "logic" behind Utilities/KWIML/INT.h.in statement: @KWIML@_INT__VERIFY_TYPE(@KWIML@_INT_intptr_t, sizeof(void*)); Message-ID: >From INT.h.in: 828 #if !defined(@KWIML at _INT_NO_INTPTR_T) 829 @KWIML at _INT__VERIFY_TYPE(@KWIML at _INT_intptr_t, sizeof(void*)); 830 #endif 831 #if !defined(@KWIML at _INT_NO_UINTPTR_T) 832 @KWIML at _INT__VERIFY_TYPE(@KWIML at _INT_uintptr_t, sizeof(void*)); 833 #endif Now this statement blows up in the make Makefile process as follows: cmIML_INT__VERIFY_TYPE(cmIML_INT_intptr_t, sizeof(void*)); ^ %CXX-E-NOTCOMPREDEC, declaration is incompatible with "int (*cmIML_INT_intptr_t__VERIFY__)[4U]" (declared at line 829) at line number 829 in file LCL_ROOT:[cmake-3_3_2.Bootstrap_cmk.cmIML]INT.h;11 I wrote a simple C application to confirm the compiler's values, compiled-and-linked the application on both OpenVMS and Fedora Linux (x64) and noticed a discrepancy... ITAN1* ty foo.c #include #include #include int main(void) { printf( "sizeof(intptr_t) = %d\n", sizeof(intptr_t)); printf( "sizeof(uintptr_t) = %d\n", sizeof(uintptr_t)); printf( "sizeof(void *) = %d\n", sizeof(void *)); return EXIT_SUCCESS; } On OpenVMS this application displays the following: ITAN1* r foo sizeof(intptr_t) = 8 sizeof(uintptr_t) = 8 sizeof(void *) = 4 sizeof(int *) = 4 and clearly sizeof(void *) = 4 < does NOT equal > sizeof(intptr_t) = 8 On Fedora22 the exact same application displays the following: [jpcustin at localhost ~]$ ./foo sizeof(intptr_t) = 8 sizeof(uintptr_t) = 8 sizeof(void *) = 8 sizeof(int *) = 8 [jpcustin at localhost ~]$ http://en.cppreference.com/w/c/types/integer describes intptr_t as: "integer type capable of holding a pointer" http://pubs.opengroup.org/onlinepubs/009695399/basedefs/stdint.h.html goes a little further: Integer types capable of holding object pointers The following type designates a signed integer type with the property that any valid pointer to void can be converted to this type, then converted back to a pointer to void, and the result will compare equal to the original pointer: intptr_t The following type designates an unsigned integer type with the property that any valid pointer to void can be converted to this type, then converted back to a pointer to void, and the result will compare equal to the original pointer: uintptr_t This begs the question... Why does the CMake test rely on checking if sizeof(intptr_t) equals sizeof(void *) instead of sizeof(intptr_t) greater than or equal to sizeof(void *) (so can an intptr_t "hold" a void *)? JayC From jay.custin at hpe.com Thu Nov 5 14:35:41 2015 From: jay.custin at hpe.com (Custin, Jay (CSC Sw Middleware)) Date: Thu, 5 Nov 2015 19:35:41 +0000 Subject: [CMake] Question about the "logic" behind Utilities/KWIML/INT.h.in statement: @KWIML@_INT__VERIFY_TYPE(@KWIML@_INT_intptr_t, sizeof(void*)); Message-ID: Probably a moot question at this point... I posed the same question to some of the language/compiler experts at HPE and got the following explanation: Looking quickly, I suspect that he is not using the /pointer=long qualifier at compile time. The default pointer size is 32-bit (4 bytes), but there are a few different ways to get 64-bit pointers. The /pointer=long is the easiest. Hope this helps. XXXX05>hpcc/pointer=long ptr_test XXXX05>link ptr_test XXXX05>r ptr_test sizeof(intptr_t) = 8 sizeof(uintptr_t) = 8 sizeof(void *) = 8 sizeof(int *) = 8 XXXX05> -----Original Message----- From: Custin, Jay (CSC Sw Middleware) Sent: Thursday, November 05, 2015 1:28 PM To: cmake at cmake.org Subject: Question about the "logic" behind Utilities/KWIML/INT.h.in statement: @KWIML at _INT__VERIFY_TYPE(@KWIML at _INT_intptr_t, sizeof(void*)); >From INT.h.in: 828 #if !defined(@KWIML at _INT_NO_INTPTR_T) 829 @KWIML at _INT__VERIFY_TYPE(@KWIML at _INT_intptr_t, sizeof(void*)); 830 #endif 831 #if !defined(@KWIML at _INT_NO_UINTPTR_T) 832 @KWIML at _INT__VERIFY_TYPE(@KWIML at _INT_uintptr_t, sizeof(void*)); 833 #endif Now this statement blows up in the make Makefile process as follows: cmIML_INT__VERIFY_TYPE(cmIML_INT_intptr_t, sizeof(void*)); ^ %CXX-E-NOTCOMPREDEC, declaration is incompatible with "int (*cmIML_INT_intptr_t__VERIFY__)[4U]" (declared at line 829) at line number 829 in file LCL_ROOT:[cmake-3_3_2.Bootstrap_cmk.cmIML]INT.h;11 I wrote a simple C application to confirm the compiler's values, compiled-and-linked the application on both OpenVMS and Fedora Linux (x64) and noticed a discrepancy... ITAN1* ty foo.c #include #include #include int main(void) { printf( "sizeof(intptr_t) = %d\n", sizeof(intptr_t)); printf( "sizeof(uintptr_t) = %d\n", sizeof(uintptr_t)); printf( "sizeof(void *) = %d\n", sizeof(void *)); return EXIT_SUCCESS; } On OpenVMS this application displays the following: ITAN1* r foo sizeof(intptr_t) = 8 sizeof(uintptr_t) = 8 sizeof(void *) = 4 sizeof(int *) = 4 and clearly sizeof(void *) = 4 < does NOT equal > sizeof(intptr_t) = 8 On Fedora22 the exact same application displays the following: [jpcustin at localhost ~]$ ./foo sizeof(intptr_t) = 8 sizeof(uintptr_t) = 8 sizeof(void *) = 8 sizeof(int *) = 8 [jpcustin at localhost ~]$ http://en.cppreference.com/w/c/types/integer describes intptr_t as: "integer type capable of holding a pointer" http://pubs.opengroup.org/onlinepubs/009695399/basedefs/stdint.h.html goes a little further: Integer types capable of holding object pointers The following type designates a signed integer type with the property that any valid pointer to void can be converted to this type, then converted back to a pointer to void, and the result will compare equal to the original pointer: intptr_t The following type designates an unsigned integer type with the property that any valid pointer to void can be converted to this type, then converted back to a pointer to void, and the result will compare equal to the original pointer: uintptr_t This begs the question... Why does the CMake test rely on checking if sizeof(intptr_t) equals sizeof(void *) instead of sizeof(intptr_t) greater than or equal to sizeof(void *) (so can an intptr_t "hold" a void *)? JayC From krueger at ind.rwth-aachen.de Thu Nov 5 16:16:44 2015 From: krueger at ind.rwth-aachen.de (=?UTF-8?Q?Hauke_Kr=c3=bcger?=) Date: Thu, 5 Nov 2015 22:16:44 +0100 Subject: [CMake] Problems with cmake in Windows related to maximum path length Message-ID: <563BC73C.4000207@ind.rwth-aachen.de> Hi everybody, I am a new user of cmake and a new member of this mailing list. Apologies in case the reason for my problem is the fact that I am not experienced with using cmake. I use cmake to generate "nmake Makefiles" in Windows (Visual Studio compiler). The project is rather large, hence, I tend to run into max path limitation problems. I have understood that I should not run into these problems since the hashing of the paths is intended to cope with most of these problems. I have then downloaded the latest version of the cmake source code and found the reason for this problem: Let us assume we have defined a project XX which defines two targets 1) "XX" 2) "XX_variant1_with_modification_a" which, e.g., are shared libraries. I use very long path names and run into the system maximum path limitations. I understood that the maximum path length is 250 on Windows and leads to the shortened version of the object paths in case the path turns out to be too large. The shortening is based on the MD5 hashing mechanism. I found that the object filename shortening happens in file "cmLocalGenerator.cxx". In that function, all object file lengths are checked against the maximum path length given. The function declaration is "bool cmLocalGeneratorCheckObjectName(std::string& objName, std::string::size_type dir_len, std::string::size_type max_total_len)", the object file path is characterized by the "dir_len" and the "objName", the path limitation is specified by "max_total_len". In the path length comparison, the "dir_len" value comes from an evaluation of the variable "dir_max" which originates from a function called void "cmLocalUnixMakefileGenerator3::ComputeObjectFilenames(std::map& mapping,cmGeneratorTarget const* gt) in "cmLocalUnixMakefileGenerator3.cpp" (involving functions "CreateSafeUniqueObjectFileName" and "GetObjectFileNameWithoutTarget"). As far as I understood, the variable "dir_max" and with it value of "dir_len" are incorrect: Coming back to our situation with the two targets which are derived from the project name, cmake generates object files in subfolders of "/CMakeFiles/XX.dir" and "/CMakeFiles/XX_variant1_with_modification_a.dir". In the function "cmLocalGeneratorCheckObjectName", however, the variable "dir_len" is related to a value of "dir_max" which corresponds to the "/CMakeFiles/XX.dir". This is not the maximum directory length as would be expected: In my opinion, the value of "dir_max" should be "/CMakeFiles/XX_variant1_with_modification_a.dir"! If an object filename meets the constraints given the directory "/CMakeFiles/XX.dir" to not cause the filename shortening, it may happen that the path is too long for the directory "/CMakeFiles/XX_variant1_with_modification_a.dir". In the current implementation, the hashing/shortening mechanism is not triggered, the resulting object file name path is longer than 250 and I see a hard-to-understand build error. The conclusion: the variable "dir_max" does not really contain the maximum length directory name given all targets but only the directory name of the first target or the project name - i did not follow this in detail. My solution to overcome this problem currently: I set the CMAKE_OBJECT_PATH_MAX value to a value lower than 250, e.g., set(CMAKE_OBJECT_PATH_MAX 240) in order to take into account that the maximum target path directory length is by maximum 10 larger than the project directory path. Does anyone else have an opinion on this? Or am I doing something in a forbidden way? Thank you for any comment and best regards Hauke From clinton at elemtech.com Thu Nov 5 19:00:35 2015 From: clinton at elemtech.com (clinton at elemtech.com) Date: Thu, 5 Nov 2015 17:00:35 -0700 (MST) Subject: [CMake] autouic problem with Visual Studio Message-ID: <1593418427.24144808.1446768035992.JavaMail.zimbra@elemtech.com> Hi, I'm trying out the autouic feature in Visual Studio, and I noticed that if I change a .ui file, the corresponding ui_*.h file is not regenerated when I hit the build button. I don't see this problem under Makefiles. For makefiles, it appears a phony target is used and "cmake -E cmake_autogen" is always run each time make is called. For visual studio, the build rule to execute "cmake -E cmake_autogen" has a list of dependencies. This list of dependencies includes all the files listed in a .qrc file, but none of the .ui files. If I right click on the file representing this build rule, and click "compile", it then runs "cmake -E cmake_autogen" and the ui_*.h files are incrementally updated (only those for which corresponding .ui files were changed). This appears to be a bug. The setup is different between the two, and perhaps the build rule under visual studio should list all the dependent .ui files. Is anyone else seeing this behavior? Thanks, Clint -------------- next part -------------- An HTML attachment was scrubbed... URL: From steinbach at scionics.de Fri Nov 6 04:02:08 2015 From: steinbach at scionics.de (Peter Steinbach) Date: Fri, 06 Nov 2015 10:02:08 +0100 Subject: [CMake] Fwd: Re: cmake needs 2 runs to find boost In-Reply-To: <1921165.Wu4ixSjSQz@schorle.mpi-cbg.de> References: <1921165.Wu4ixSjSQz@schorle.mpi-cbg.de> Message-ID: <2310174.8d9UscCb33@schorle.mpi-cbg.de> Hi to all, {sorry for the email mess, anyway here is my to answer to Andreas as it affects this mail thread) thanks for the Boost_DEBUG hint. The output is much more concise and digestible than "--trace". Good News: It works now. I discovered I had a cmake Windows build installed on the machine that the MSYS2 terminal picked up. Once that was removed and I used the msys internal cmake, it works out nicely. However, the MSVS build target is gone now. So I have to find a way to use either version in parallel somehow. Bad News: I didn't follow through why the problem occurred in the first place. Once thing is for sure, the FindBoost module acutally triggered BOOST_FOUND=1! But finding the actual libraries of boost failed. Best, Peter On Thursday, November 05, 2015 05:29:16 PM Peter Steinbach wrote: > ---------- Forwarded Message ---------- > > Subject: Re: [CMake] cmake needs 2 runs to find boost > Date: Thursday, November 05, 2015, 04:41:51 PM > From: Andreas Naumann > To: Peter Steinbach > > Hey Peter, > > It is not a solution, but I would set Boost_DEBUG to ON and compare the > output of the first and the second cmake run. > > Andreas > > Am 05.11.2015 um 14:26 schrieb Peter Steinbach: > > Hi to all, > > > > ok, I tried the attached minimal CMakeLists.txt again and found out that > > it > > fails in the way I described only with the "MSYS Makefiles" generator. If > > I > > use the same CMakeLists.txt without a custom generator (so MSVS is the > > default > > > IIRC), the libraries are found alright! > > > > Any ideas? > > Best, > > Peter > > > > On Thursday, November 05, 2015 01:41:33 PM Peter Steinbach wrote: > >> Hi Benedikt, > >> > >> interesting thought, however I wonder why cmake is then capable of > >> deducing > >> the right boost version and include path. Just inside the first error > >> message, I see: > >> > >> (x86)/CMake/share/cmake-3.2/Modules/FindBoost.cmake:1182 (message): > >>>> Unable to find the requested Boost libraries. > >>>> > >>>> Boost version: 1.57.0 > >>>> > >>>> Boost include path: C:/msys64/mingw64/include > >>>> > >>>> Could not find the following static Boost libraries: > >>>> boost_filesystem > >>>> boost_system > >> > >> strange, isn't it? > >> Peter > >> > >> On Thursday, November 05, 2015 11:41:10 AM Benedikt Hegner wrote: > >>> Hi Peter, > >>> > >>> as I don't use windows at all, this is just a very wild guess... > >>> > >>> Could it be that in the second run you actually don't use > >>> > >>> /CMake/share/cmake-3.2/Modules/FindBoost.cmake > >>> > >>> but boost-config.cmake, which it now finds in the cached environment of > >>> the first run? > >>> > >>> This assumes of course that you built boost w/ CMake and not bjam... > >>> > >>> Cheers, > >>> > >>> Benedikt > >>> > >>> On 03.11.2015 14:10, Peter Steinbach wrote: > >>>> Hi to all, > >>>> > >>>> I tested this with cmake 3.2.2 and 3.3.2 and still get the same > >>>> problem. > >>>> I'd like to use boost with gcc on windows 7 64bit. I installed boost > >>>> and > >>>> gcc with msys2 as I cannot use MSVC for the actual project I am looking > >>>> into for this. > >>>> > >>>> the funny thing, if I use the attached CMakeLists.txt on the machine > >>>> and > >>>> call: ``` > >>>> $ cmake -G "MSYS Makefiles" -DBOOST_ROOT=C:/msys64/mingw64 - > >>>> DBOOST_LIBRARYDIR==C:/msys64/mingw64/lib .. > >>>> -- The CXX compiler identification is GNU 4.9.2 > >>>> -- Check for working CXX compiler: C:/msys64/usr/bin/g++.exe > >>>> -- Check for working CXX compiler: C:/msys64/usr/bin/g++.exe -- works > >>>> -- Detecting CXX compiler ABI info > >>>> -- Detecting CXX compiler ABI info - done > >>>> -- Detecting CXX compile features > >>>> -- Detecting CXX compile features - done > >>>> setting win specific stuff > >>>> CMake Error at C:/Program Files > >>>> > >>>> (x86)/CMake/share/cmake-3.2/Modules/FindBoost.cmake:1182 (message): > >>>> Unable to find the requested Boost libraries. > >>>> > >>>> Boost version: 1.57.0 > >>>> > >>>> Boost include path: C:/msys64/mingw64/include > >>>> > >>>> Could not find the following static Boost libraries: > >>>> boost_filesystem > >>>> boost_system > >>>> > >>>> No Boost libraries were found. You may need to set > >>>> BOOST_LIBRARYDIR > >>>> to > >>>> the > >>>> directory containing Boost libraries or BOOST_ROOT to the location > >>>> of > >>>> Boost. > >>>> > >>>> Call Stack (most recent call first): > >>>> CMakeLists.txt:17 (FIND_PACKAGE) > >>>> > >>>> CMake Error at CMakeLists.txt:24 (MESSAGE): > >>>> Boost not found (C:/msys64/mingw64) > >>>> > >>>> -- Configuring incomplete, errors occurred! > >>>> See also > >>>> "C:/msys64/home/steinbac/development/cmake_sandbox/find_boost/build/CMa > >>>> k > >>>> eF > >>>> iles/CMakeOutput.log". $ cmake -G "MSYS Makefiles" > >>>> -DBOOST_ROOT=C:/msys64/mingw64 - > >>>> DBOOST_LIBRARYDIR==C:/msys64/mingw64/lib .. > >>>> setting win specific stuff > >>>> Boost 1.57 found __ > >>>> -- Configuring done > >>>> -- Generating done > >>>> -- Build files have been written to: > >>>> C:/msys64/home/steinbac/development/cmake_sandbox/find_boost/build > >>>> ``` > >>>> > >>>> I'd like to link statically to multithreaded libboost_*-mt.a from my > >>>> app. > >>>> But it proofes really hard to find Boost in the first place. > >>>> Any ideas? > >>>> > >>>> Peter > > ----------------------------------------- -- Peter Steinbach, Dr. rer. nat. HPC Developer Scionics Computer Innovation GmbH L?scherstr. 16 01309 Dresden fon: +49 351 210 2882 fax: +49 351 210 1689 http://www.scionics.de Sitz der Gesellschaft: Dresden (Main office) Amtsgericht - Registergericht: Dresden HRB 20337 (Commercial Registry) Ust-IdNr.: DE813263791 (VAT ID Number) Gesch?ftsf?hrer: John Duperon, Jeff Oegema (Managing Directors) From mohammedrashadkm at gmail.com Fri Nov 6 07:09:06 2015 From: mohammedrashadkm at gmail.com (Rashad M) Date: Fri, 6 Nov 2015 13:09:06 +0100 Subject: [CMake] [CDash] CTEST_CUSTOM_WARNING_EXECPTION In-Reply-To: References: Message-ID: So using *.#warning.*deprecated.* should work? I will test this and let you know. On Thu, Nov 5, 2015 at 4:49 PM, David Cole wrote: > Looks to me like it might be (I'm hopeful) working at ignoring the > line which matches the expression ".*vcl_deprecated_header.h.*" ... > > But then, the following line is: > > # warning "deprecated" > > Since that line does not match any of your expressions, maybe that's > the one triggering this warning slipping through as unignored? > > > HTH, > D > > > > > On Thu, Nov 5, 2015 at 10:01 AM, Rashad M > wrote: > > yes. > > > > On Thu, Nov 5, 2015 at 1:46 PM, David Cole wrote: > >> > >> Does your ctest -S script call ctest_read_custom_files > >> https://cmake.org/cmake/help/v3.4/command/ctest_read_custom_files.html > after > >> ctest_configure? > >> > >> > >> On Thursday, November 5, 2015, Rashad M > >> wrote: > >>> > >>> Hello all, > >>> > >>> I have CTestCustom.cmake.in file in source tree with the following > >>> contents > >>> > >>> > >>> > https://git.orfeo-toolbox.org/otb.git/blob/refs/heads/develop:/CMake/CTestCustom.cmake.in > >>> > >>> during ctest build CTestCustom.cmake file is getting generated inside > the > >>> build tree. > >>> > >>> But however the warnings are not filtered out on the dashboard. For > >>> instance, see the dashboard submission > >>> http://dash.orfeo-toolbox.org/viewBuildError.php?type=1&buildid=206112 > >>> > >>> and see the exception for vcl_deprecated_header > >>> > >>> > >>> > https://git.orfeo-toolbox.org/otb.git/blob/refs/heads/develop:/CMake/CTestCustom.cmake.in#l69 > >>> > >>> The warning appears on dashobard anyway. Can someone point me in the > >>> right direction. ? > >>> > >>> Thanks in advance. > >>> > >>> > >>> CMake Version: > >>> 2.8.12.2 > >>> > >>> CDash Version: > >>> 2.2.3 > >>> > >>> uname -a > >>> Linux ubuntu > >>> > >>> 3.13.0-65-generic #106-Ubuntu SMP Fri Oct 2 22:08:27 UTC 2015 x86_64 > >>> x86_64 x86_64 GNU/Linux > >>> -- > >>> Regards, > >>> Rashad > > > > > > > > > > -- > > Regards, > > Rashad > -- Regards, Rashad -------------- next part -------------- An HTML attachment was scrubbed... URL: From mohammedrashadkm at gmail.com Fri Nov 6 09:20:16 2015 From: mohammedrashadkm at gmail.com (Rashad M) Date: Fri, 6 Nov 2015 15:20:16 +0100 Subject: [CMake] Visual Studio Cross Compile In-Reply-To: References: <44e308e464e4495c8ff063b9f7de58f3@in.tum.de> <56379F2A.8070100@in.tum.de> Message-ID: Hello all, I had tried what Michael was saying for another project with MinGW. And it works perfectly. I even had HowTo on our wiki [1] to setup windows development using cmake Eclipse IDE. Note that the "xdk" archive I was saying was generated using cross compile on linux [1] http://wiki.orfeo-toolbox.org/index.php/OTB_development_on_Windows On Mon, Nov 2, 2015 at 9:26 PM, J Decker wrote: > for windows platform using cmake, you just need mingw (mingw64 is > probably better) > > On Mon, Nov 2, 2015 at 9:36 AM, Michael J?ntsch > wrote: > > Hi, > > > > thanks for your replies. So it seems that Visual Studio is generally not > > a great idea for cross-compiling... > > So eclipse and some make system it's gonna be then. Any suggestions what > > works best? Coming from the Linux world, I obviously use Unix make, but > > there is also Ninja, nmake, ...? > > > > Michael > > > > > > On 02.11.2015 15:51, Parag Chandra wrote: > >> Hi Michael, > >> > >> Meant to reply sooner. As Nils pointed out, Visual Studio isn?t quite > as flexible with cross-compilation as some other build systems. Having said > that, it is indeed possible to cross-compile with Visual Studio, but there > has to be a cross toolchain compatible with the IDE. Some examples of this > include: > >> > >> Google?s Native Client - I have successfully targeted this environment > with Visual Studio 2010 and Cmake; > >> > >> Windows Phone 8.1/10 - Have targeted this as well. While you may be > thinking ?that?s just another flavor of Windows?, it is nevertheless > cross-compiling for ARM; > >> > >> Several options for Android development: > >> Nvidia Tegra Studio; > >> Visual Studio 2015 - Microsoft now offers first-party support within VS > 2015; > >> VS-Android; > >> > >> Commercial/paid add-ons that seem to support arbitrary GCC toolchains: > >> Visual GDB - This one may be your best bet for what you are trying to > accomplish. Supports Linux, Android, Raspberry Pi, etc. out of the box, and > they claim to have an extensibility model to add your own platforms; > >> WinGDB - similarly seems to support the GNU toolchain directly. > >> > >> Anyway, hopefully you get the idea. It is possible, but out of the box, > you?re only going to be able to target Windows Phone and Android. > >> > >> > >> Parag Chandra > >> Senior Software Engineer, Mobile Team > >> Mobile: +1.919.824.1410 > >> > >> > >> > >> Ionic Security Inc. > >> 1170 Peachtree St. NE STE 400, Atlanta, GA 30309 > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> On 10/29/15, 10:21 AM, "CMake on behalf of Michael Jaentsch" < > cmake-bounces at cmake.org on behalf of michael.jaentsch at in.tum.de> wrote: > >> > >>> Hi all, > >>> > >>> I have a question concerning Cross Compiling with CMake on Windows. I > >>> would like to use Visual Studio but this is not a must. What I do is, I > >>> setup a project for Cross Compiling on Linux and it works fine. Now I > >>> want to transfer to Windows, so I set up a toolchain file which sets > the > >>> following variables: > >>> CMAKE_SYSTEM_NAME > >>> CMAKE_SYSTEM_PROCESSOR > >>> CMAKE_FIND_ROOT_PATH > >>> CMAKE_C_COMPILER > >>> CMAKE_CXX_COMPILER > >>> > >>> and some more stuff. Then I run my cmake gui (I tried 3.2 and 3.4rc2) > >>> on Windows and tell it to generate a project for Visual Studio 10 and > to > >>> use the toolchain file. However, the output shows that it is trying to > >>> use the Visual Studio compiler and then subsequently the build fails > >>> because of some unkown compiler flags. > >>> > >>> So my question is: Is it even possible to do what I'm trying to do? Can > >>> I cross compile with Visual Studio or do I have to use a different > >>> generator? All I found in the documentation is that it is possible to > >>> cross compile with a toolchain file... > >>> > >>> Cheers > >>> Michael > >>> > >>> > >>> -- > >>> Technische Universit?t M?nchen > >>> Michael J?ntsch > >>> Fakult?t f?r Informatik > >>> Robotics and Embedded Systems > >>> Parkring 13 > >>> 85748 Garching bei M?nchen > >>> michael.jaentsch at in.tum.de > >>> www6.in.tum.de > >>> -- > >>> > >>> Powered by www.kitware.com > >>> > >>> Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > >>> > >>> Kitware offers various services to support the CMake community. For > more information on each offering, please visit: > >>> > >>> CMake Support: http://cmake.org/cmake/help/support.html > >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html > >>> CMake Training Courses: http://cmake.org/cmake/help/training.html > >>> > >>> Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > >>> > >>> Follow this link to subscribe/unsubscribe: > >>> http://public.kitware.com/mailman/listinfo/cmake > > > > -- > > Technische Universit?t M?nchen > > Michael J?ntsch > > Fakult?t f?r Informatik > > Robotics and Embedded Systems > > Boltzmannstr. 3 > > 85748 Garching bei M?nchen > > michael.jaentsch at in.tum.de > > www6.in.tum.de > > > > -- > > > > Powered by www.kitware.com > > > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > > > CMake Support: http://cmake.org/cmake/help/support.html > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > > Visit other Kitware 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 > -- Regards, Rashad -------------- next part -------------- An HTML attachment was scrubbed... URL: From kgt at lanl.gov Fri Nov 6 12:05:42 2015 From: kgt at lanl.gov (Thompson, KT) Date: Fri, 6 Nov 2015 17:05:42 +0000 Subject: [CMake] looking for help with "ctest_drop_method scp" Message-ID: <0458DF31F610EF42BFC78C497E806C7B4ABF3841@ECS-EXG-P-MB03.win.lanl.gov> Hi, I am looking for information or examples on using CTEST_DROP_METHOD ?scp?. I am aware of the documentation at (1) https://cmake.org/Wiki/CMake/Testing_With_CTest and (2) https://cmake.org/Wiki/CTest:Submission_Issues I support a test system that does not have http(s) access to the outside world, so it cannot post results to CDash using the normal protocol. I have setup my ctest script to use the scp method and this successfully copies the xml files to another machine that does have http access to my cdash server. However, I don?t understand how to load the xml files into CDash once they are scp?d onto a machine that can see my CDash server. The two reference pages I list above talk about a TRIGGER_SITE (a perl script). I don?t understand what this script is supposed to do or how to rework it for my system. Does anyone have examples or instructions that they can send me? Is there a way to use curl to call cdash/submit.php? Thanks for any information. -kt -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.stijnman at gmail.com Fri Nov 6 14:06:36 2015 From: mark.stijnman at gmail.com (Mark Stijnman) Date: Fri, 6 Nov 2015 20:06:36 +0100 Subject: [CMake] WIX installer fails for shared files Message-ID: I'm using CPack with WIX to create multi-component installers, and I'm having issues with components (or WIX features) that share files. A common use case would be two executables which require the same DLLs. To reproduce the issue, you can use following minimal CMakeLists.txt with three text files 1.txt, 2.txt and common.txt: @ install(FILES 1.txt common.txt DESTINATION bin COMPONENT comp1) install(FILES 2.txt common.txt DESTINATION bin COMPONENT comp2) set(CPACK_GENERATOR WIX) set(CPACK_COMPONENTS_ALL comp1 comp2) include(CPack) @ running cmake and then cpack results in: CPack Error: Fatal WiX Generator Error CPack Error: Problem compressing the directory CPack Error: Error when generating package: Project In wix.log, you will find the real error: error LGHT0369 : Component/@Id='CM_CP_comp2.bin.common.txt' has a @Guid value '{8D160A50-70B9-5BCA-8491-AB9A79C696F3}' that duplicates another component in this package. It is recommended to give each component its own unique GUID. This seems to be caused by the fact that CPack makes separate staging folders for each component, so that comp1\bin\common.txt and comp2\bin\common.txt are different files to CPack. However, since they both install to bin\common.txt, WIX thinks they should be the same file with the same GUID. A partial workaround is to put shared files in a separate, hidden CPack component/WIX feature, and set component dependencies. However, with many shared DLLs, maintaining this gets complex really fast, so I'd rather not have to do this. So how can I get the WIX generator to do this the WIX way: generate just one entry for a common file, and reference that entry from both features? As an aside, is it really necessary to have separate staging folders for each component? It should be safe to just have one staging folder, unless two components in the same package install two different files to the same destination - but shouldn't that be an error that CPack should check for anyway? best regards Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From scott at towel42.com Fri Nov 6 16:14:05 2015 From: scott at towel42.com (Scott Aron Bloom) Date: Fri, 6 Nov 2015 21:14:05 +0000 Subject: [CMake] Ctest executable dll/so search path Message-ID: I have a unit test, that I have have avoided deploying, because its executable (gmock/gtest based) depends on a third party dll. Essentially it's a unit test to test our interface to the thirdparty library. So for much of the application unittesting, I have a mock to simulate the 3rd party lib.. But for this set of tests, I really want to make sure the ACTUAL interface works. How can I add/set the PATH for an executable to run with so it picks up the DLL (or so on linux)? Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Fri Nov 6 16:42:28 2015 From: d3ck0r at gmail.com (J Decker) Date: Fri, 6 Nov 2015 13:42:28 -0800 Subject: [CMake] CPack NSIS Silent install option Message-ID: Would be nice to be able to define a default option for uninstall message box for silent install.. something like CPACK_NSIS_SILENT_UNINSTALL_DEFAULT which could be set with SET( CPACK_NSIS_SILENT_UNINSTALL_DEFAULT /SD IDYES ) # or IDNO or something Modify Modules/NSIS.template.in .. add silent uninstall default before option list.... MessageBox MB_YESNOCANCEL|MB_ICONEXCLAMATION \ "@CPACK_NSIS_PACKAGE_NAME@ is already installed. $\n$\nDo you want to uninstall the old version before installing the new one?" \ @CPACK_NSIS_SILENT_UNINSTALL_DEFAULT@ IDYES uninst IDNO inst Abort From gurenchan at gmail.com Sun Nov 8 09:28:56 2015 From: gurenchan at gmail.com (Owen Alanzo Hogarth) Date: Sun, 8 Nov 2015 22:28:56 +0800 Subject: [CMake] find___.cmake module Message-ID: HI I am having some issue getting my findSDL2_image.cmake module to work. I moved to linux and the strict character case is causing me a lot of trouble. Here is the error when running the cmake build script Argument not separated from preceding token by whitespace. This warning is for project developers. Use -Wno-dev to suppress it. -- Could NOT find SDL2_image (missing: SDL2_IMAGE_LIBRARIES SDL2_IMAGE_INCLUDE_DIRS) message SDL2_IMAGE_INCLUDE_DIR-NOTFOUND CMake Error: The following variables are used in this project, but they are set to NOTFOU ND. Please set them or make sure they are set and tested correctly in the CMake files: SDL2_IMAGE_INCLUDE_DIR (ADVANCED) used as include directory in directory ../resource_utils SDL2_IMAGE_LIBRARY (ADVANCED) linked by target "resource_utils" in directory ../utils/resource_utils Here is the cmakelists file SET(CMAKE_MACOSX_RPATH 1) FIND_PACKAGE(SDL2 REQUIRED) INCLUDE_DIRECTORIES(${SDL2_INCLUDE_DIR}) FIND_PACKAGE(SDL2_image) INCLUDE_DIRECTORIES(${SDL2_image_INCLUDE_DIR}) SET(HEADER_FILES ${CMAKE_CURRENT_SOURCE_DIR}/headers/resource_utils.h) SET(SRC_FILES ${CMAKE_CURRENT_SOURCE_DIR}/resource_utils.c) SET(TARGET_LIBS ${SDL2_LIBRARY} ${SDL2_image_LIBRARY}) ADD_LIBRARY(resource_utils ${SRC_FILES} ${HEADER_FILES}) TARGET_LINK_LIBRARIES(resource_utils ${TARGET_LIBS}) the .cmake file is named: FindSDL2_image.cmake and it's in my cmake_modules path. This is the contents of that file # Locate SDL2_image library # This module defines # SDL2_IMAGE_LIBRARY, the name of the library to link against # SDL2_IMAGE_FOUND, if false, do not try to link to SDL2_image # SDL2_IMAGE_INCLUDE_DIR, where to find SDL_image.h # # Additional Note: If you see an empty SDL2_IMAGE_LIBRARY_TEMP in your configuration # and no SDL2_IMAGE_LIBRARY, it means CMake did not find your SDL2_Image library # (SDL2_image.dll, libsdl2_image.so, SDL2_image.framework, etc). # Set SDL2_IMAGE_LIBRARY_TEMP to point to your SDL2 library, and configure again. # Similarly, if you see an empty SDL2MAIN_LIBRARY, you should set this value # as appropriate. These values are used to generate the final SDL2_IMAGE_LIBRARY # variable, but when these values are unset, SDL2_IMAGE_LIBRARY does not get initialized. # # $SDL2 is an environment variable that would # correspond to the ./configure --prefix=$SDL2 # used in building SDL2. # l.e.galup 9-20-02 # # Modified by Eric Wing. # Added code to assist with automated building by using environmental variables # and providing a more controlled/consistent search behavior. # Added new modifications to recognize OS X frameworks and # additional Unix paths (FreeBSD, etc). # Also corrected the header search path to follow "proper" SDL2 guidelines. # Added a search for SDL2main which is needed by some platforms. # Added a search for threads which is needed by some platforms. # Added needed compile switches for MinGW. # # On OSX, this will prefer the Framework version (if found) over others. # People will have to manually change the cache values of # SDL2_IMAGE_LIBRARY to override this selection or set the CMake environment # CMAKE_INCLUDE_PATH to modify the search paths. # # Note that the header path has changed from SDL2/SDL.h to just SDL.h # This needed to change because "proper" SDL2 convention # is #include "SDL.h", not . This is done for portability # reasons because not all systems place things in SDL2/ (see FreeBSD). # # Ported by Johnny Patterson. This is a literal port for SDL2 of the FindSDL.cmake # module with the minor edit of changing "SDL" to "SDL2" where necessary. This # was not initialized for redistribution, and exists temporarily pending official # SDL2 CMake modules. # # Note that on windows this will only search for the 32bit libraries, to search # for 64bit change x86/i686-w64 to x64/x86_64-w64 #============================================================================= # Copyright 2003-2009 Kitware, Inc. # # CMake - Cross Platform Makefile Generator # Copyright 2000-2014 Kitware, Inc. # Copyright 2000-2011 Insight Software Consortium # All rights reserved. # # Redistribution and use in source and binary forms, with or without # modification, are permitted provided that the following conditions # are met: # # * Redistributions of source code must retain the above copyright # notice, this list of conditions and the following disclaimer. # # * Redistributions in binary form must reproduce the above copyright # notice, this list of conditions and the following disclaimer in the # documentation and/or other materials provided with the distribution. # # * Neither the names of Kitware, Inc., the Insight Software Consortium, # nor the names of their contributors may be used to endorse or promote # products derived from this software without specific prior written # permission. # # THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS # "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT # LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR # A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT # HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, # SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT # LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, # DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY # THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT # (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE # OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. # # This software is distributed WITHOUT ANY WARRANTY; without even the # implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. # See the License for more information. #============================================================================= # (To distribute this file outside of CMake, substitute the full # License text for the above reference.) FIND_PATH(SDL2_IMAGE_INCLUDE_DIR SDL_image.h HINTS ${SDL2} $ENV{SDL2} $ENV{SDL2_IMAGE} PATH_SUFFIXES include/SDL2 include SDL2 i686-w64-mingw32/include/SDL2 x86_64-w64-mingw32/include/SDL2 PATHS ~/Library/Frameworks /Library/Frameworks /usr/local/include/SDL2 /usr/include/SDL2 /sw # Fink /opt/local # DarwinPorts /opt/csw # Blastwave /opt ) # Lookup the 64 bit libs on x64 IF(CMAKE_SIZEOF_VOID_P EQUAL 8) FIND_LIBRARY(SDL2_IMAGE_LIBRARY_TEMP NAMES SDL2_image HINTS ${SDL2} $ENV{SDL2} $ENV{SDL2_IMAGE} PATH_SUFFIXES lib64 lib lib/x64 x86_64-w64-mingw32/lib PATHS /sw /opt/local /opt/csw /opt ) # On 32bit build find the 32bit libs ELSE(CMAKE_SIZEOF_VOID_P EQUAL 8) FIND_LIBRARY(SDL2_IMAGE_LIBRARY_TEMP NAMES SDL2_image HINTS ${SDL2} $ENV{SDL2} $ENV{SDL2_IMAGE} PATH_SUFFIXES lib lib/x86 i686-w64-mingw32/lib PATHS /sw /opt/local /opt/csw /opt ) ENDIF(CMAKE_SIZEOF_VOID_P EQUAL 8) SET(SDL2_IMAGE_FOUND "NO") IF(SDL2_IMAGE_LIBRARY_TEMP) # Set the final string here so the GUI reflects the final state. SET(SDL2_IMAGE_LIBRARY ${SDL2_IMAGE_LIBRARY_TEMP} CACHE STRING "Where the SDL2_image Library can be found") # Set the temp variable to INTERNAL so it is not seen in the CMake GUI SET(SDL2_IMAGE_LIBRARY_TEMP "${SDL2_IMAGE_LIBRARY_TEMP}" CACHE INTERNAL "") SET(SDL2_IMAGE_FOUND "YES") ENDIF(SDL2_IMAGE_LIBRARY_TEMP) INCLUDE(FindPackageHandleStandardArgs) FIND_PACKAGE_HANDLE_STANDARD_ARGS(SDL2_IMAGE REQUIRED_VARS SDL2_IMAGE_LIBRARY SDL2_IMAGE_INCLUDE_DIR) -------------- next part -------------- An HTML attachment was scrubbed... URL: From iosif.neitzke+cmake at gmail.com Sun Nov 8 10:02:08 2015 From: iosif.neitzke+cmake at gmail.com (Iosif Neitzke) Date: Sun, 8 Nov 2015 09:02:08 -0600 Subject: [CMake] Ctest executable dll/so search path In-Reply-To: References: Message-ID: A problem long-suffered on Windows and when lacking RPATH. Have seen approaches where DLL dependencies are POST_BUILD customed-command-copied-if-different into the executable directory, or gymnastics with add_test WORKING_DIRECTORY, or setting a test's ENVIRONMENT property. On Fri, Nov 6, 2015 at 3:14 PM, Scott Aron Bloom wrote: > I have a unit test, that I have have avoided deploying, because its > executable (gmock/gtest based) depends on a third party dll. Essentially > it?s a unit test to test our interface to the thirdparty library. So for > much of the application unittesting, I have a mock to simulate the 3rd party > lib.. But for this set of tests, I really want to make sure the ACTUAL > interface works. > > > > How can I add/set the PATH for an executable to run with so it picks up the > DLL (or so on linux)? > > > Scott > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 boud at valdyas.org Mon Nov 9 05:36:32 2015 From: boud at valdyas.org (Boudewijn Rempt) Date: Mon, 9 Nov 2015 11:36:32 +0100 (CET) Subject: [CMake] Fwd: Re: cmake needs 2 runs to find boost In-Reply-To: <2310174.8d9UscCb33@schorle.mpi-cbg.de> References: <1921165.Wu4ixSjSQz@schorle.mpi-cbg.de> <2310174.8d9UscCb33@schorle.mpi-cbg.de> Message-ID: I'm actually hitting a similar problem -- I know I've got boost_system installed in c:\dev2\i\lib\boost_system-vc-mt-1_55.dll c:\dev2\i\lib\boost_system-vc-mt-1_55.lib I run cmake like this: cmake ..\krita -G"Visual Studio 14 Win64" -DBoost_DEBUG=ON -DBoost_FIND_QUIETLY=FALSE -DBOOST_INCLUDEDIR=c:\dev2\i\include -DBOOST_ROOT=c:\dev2\i -DBOOST_LIBRARYDIR=c:\dev2\i\lib -DCMAKE_INSTALL_PREFIX=c:\dev2\i -DCMAKE_PREFIX_PATH=c:\dev2\i -DCMAKE_BUILD_TYPE=Release And the output is that boost_system isn't found, because it's looking for vc140, instead of vc, it seems: -- [ C:/Program Files (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:515 ] _boost_TEST_VERSIONS = 1.58.0;1.58;1.57.0;1.57;1.56.0;1.56;1.55.0;1.55;1.54.0;1.54;1.53.0; 1.53;1.52.0;1.52;1.51.0;1.51;1.50.0;1.50;1.49.0;1.49;1.48.0;1.48;1.47.0;1.47;1.46.1;1.46.0;1.46;1.45.0;1.45;1.44.0;1.44;1.43.0;1.43;1.42.0;1.42;1.41.0;1.41;1.40.0;1.40;1. 39.0;1.39;1.38.0;1.38;1.37.0;1.37;1.36.1;1.36.0;1.36;1.35.1;1.35.0;1.35;1.34.1;1.34.0;1.34;1.33.1;1.33.0;1.33 -- [ C:/Program Files (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:517 ] Boost_USE_MULTITHREADED = TRUE -- [ C:/Program Files (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:519 ] Boost_USE_STATIC_LIBS = -- [ C:/Program Files (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:521 ] Boost_USE_STATIC_RUNTIME = -- [ C:/Program Files (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:523 ] Boost_ADDITIONAL_VERSIONS = -- [ C:/Program Files (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:525 ] Boost_NO_SYSTEM_PATHS = -- [ C:/Program Files (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:577 ] Declared as CMake or Environmental Variables: -- [ C:/Program Files (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:579 ] BOOST_ROOT = c:\dev2\i -- [ C:/Program Files (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:581 ] BOOST_INCLUDEDIR = c:\dev2\i\include -- [ C:/Program Files (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:583 ] BOOST_LIBRARYDIR = c:\dev2\i\lib -- [ C:/Program Files (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:585 ] _boost_TEST_VERSIONS = 1.58.0;1.58;1.57.0;1.57;1.56.0;1.56;1.55.0;1.55;1.54.0;1.54;1.53.0; 1.53;1.52.0;1.52;1.51.0;1.51;1.50.0;1.50;1.49.0;1.49;1.48.0;1.48;1.47.0;1.47;1.46.1;1.46.0;1.46;1.45.0;1.45;1.44.0;1.44;1.43.0;1.43;1.42.0;1.42;1.41.0;1.41;1.40.0;1.40;1. 39.0;1.39;1.38.0;1.38;1.37.0;1.37;1.36.1;1.36.0;1.36;1.35.1;1.35.0;1.35;1.34.1;1.34.0;1.34;1.33.1;1.33.0;1.33 -- [ C:/Program Files (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:654 ] Include debugging info: -- [ C:/Program Files (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:656 ] _boost_INCLUDE_SEARCH_DIRS = c:\dev2\i\include;c:\dev2\i/include;c:\dev2\i;PATHS;C:/boos t/include;C:/boost;/sw/local/include -- [ C:/Program Files (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:658 ] _boost_PATH_SUFFIXES = boost-1_58_0;boost_1_58_0;boost/boost-1_58_0;boost/boost_1_58_0;b oost-1_58;boost_1_58;boost/boost-1_58;boost/boost_1_58;boost-1_57_0;boost_1_57_0;boost/boost-1_57_0;boost/boost_1_57_0;boost-1_57;boost_1_57;boost/boost-1_57;boost/boost_ 1_57;boost-1_56_0;boost_1_56_0;boost/boost-1_56_0;boost/boost_1_56_0;boost-1_56;boost_1_56;boost/boost-1_56;boost/boost_1_56;boost-1_55_0;boost_1_55_0;boost/boost-1_55_0; boost/boost_1_55_0;boost-1_55;boost_1_55;boost/boost-1_55;boost/boost_1_55;boost-1_54_0;boost_1_54_0;boost/boost-1_54_0;boost/boost_1_54_0;boost-1_54;boost_1_54;boost/boo st-1_54;boost/boost_1_54;boost-1_53_0;boost_1_53_0;boost/boost-1_53_0;boost/boost_1_53_0;boost-1_53;boost_1_53;boost/boost-1_53;boost/boost_1_53;boost-1_52_0;boost_1_52_0 ;boost/boost-1_52_0;boost/boost_1_52_0;boost-1_52;boost_1_52;boost/boost-1_52;boost/boost_1_52;boost-1_51_0;boost_1_51_0;boost/boost-1_51_0;boost/boost_1_51_0;boost-1_51; boost_1_51;boost/boost-1_51;boost/boost_1_51;boost-1_50_0;boost_1_50_0;boost/boost-1_50_0;boost/boost_1_50_0;boost-1_50;boost_1_50;boost/boost-1_50;boost/boost_1_50;boost -1_49_0;boost_1_49_0;boost/boost-1_49_0;boost/boost_1_49_0;boost-1_49;boost_1_49;boost/boost-1_49;boost/boost_1_49;boost-1_48_0;boost_1_48_0;boost/boost-1_48_0;boost/boos t_1_48_0;boost-1_48;boost_1_48;boost/boost-1_48;boost/boost_1_48;boost-1_47_0;boost_1_47_0;boost/boost-1_47_0;boost/boost_1_47_0;boost-1_47;boost_1_47;boost/boost-1_47;bo ost/boost_1_47;boost-1_46_1;boost_1_46_1;boost/boost-1_46_1;boost/boost_1_46_1;boost-1_46_0;boost_1_46_0;boost/boost-1_46_0;boost/boost_1_46_0;boost-1_46;boost_1_46;boost /boost-1_46;boost/boost_1_46;boost-1_45_0;boost_1_45_0;boost/boost-1_45_0;boost/boost_1_45_0;boost-1_45;boost_1_45;boost/boost-1_45;boost/boost_1_45;boost-1_44_0;boost_1_ 44_0;boost/boost-1_44_0;boost/boost_1_44_0;boost-1_44;boost_1_44;boost/boost-1_44;boost/boost_1_44;boost-1_43_0;boost_1_43_0;boost/boost-1_43_0;boost/boost_1_43_0;boost-1 _43;boost_1_43;boost/boost-1_43;boost/boost_1_43;boost-1_42_0;boost_1_42_0;boost/boost-1_42_0;boost/boost_1_42_0;boost-1_42;boost_1_42;boost/boost-1_42;boost/boost_1_42;b oost-1_41_0;boost_1_41_0;boost/boost-1_41_0;boost/boost_1_41_0;boost-1_41;boost_1_41;boost/boost-1_41;boost/boost_1_41;boost-1_40_0;boost_1_40_0;boost/boost-1_40_0;boost/ boost_1_40_0;boost-1_40;boost_1_40;boost/boost-1_40;boost/boost_1_40;boost-1_39_0;boost_1_39_0;boost/boost-1_39_0;boost/boost_1_39_0;boost-1_39;boost_1_39;boost/boost-1_3 9;boost/boost_1_39;boost-1_38_0;boost_1_38_0;boost/boost-1_38_0;boost/boost_1_38_0;boost-1_38;boost_1_38;boost/boost-1_38;boost/boost_1_38;boost-1_37_0;boost_1_37_0;boost /boost-1_37_0;boost/boost_1_37_0;boost-1_37;boost_1_37;boost/boost-1_37;boost/boost_1_37;boost-1_36_1;boost_1_36_1;boost/boost-1_36_1;boost/boost_1_36_1;boost-1_36_0;boos t_1_36_0;boost/boost-1_36_0;boost/boost_1_36_0;boost-1_36;boost_1_36;boost/boost-1_36;boost/boost_1_36;boost-1_35_1;boost_1_35_1;boost/boost-1_35_1;boost/boost_1_35_1;boo st-1_35_0;boost_1_35_0;boost/boost-1_35_0;boost/boost_1_35_0;boost-1_35;boost_1_35;boost/boost-1_35;boost/boost_1_35;boost-1_34_1;boost_1_34_1;boost/boost-1_34_1;boost/bo ost_1_34_1;boost-1_34_0;boost_1_34_0;boost/boost-1_34_0;boost/boost_1_34_0;boost-1_34;boost_1_34;boost/boost-1_34;boost/boost_1_34;boost-1_33_1;boost_1_33_1;boost/boost-1 _33_1;boost/boost_1_33_1;boost-1_33_0;boost_1_33_0;boost/boost-1_33_0;boost/boost_1_33_0;boost-1_33;boost_1_33;boost/boost-1_33;boost/boost_1_33 -- [ C:/Program Files (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:678 ] location of version.hpp: c:/dev2/i/include/boost-1_55/boost/version.hpp -- [ C:/Program Files (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:702 ] version.hpp reveals boost 1.55.0 -- [ C:/Program Files (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:787 ] guessed _boost_COMPILER = -vc140 -- [ C:/Program Files (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:797 ] _boost_MULTITHREADED = -mt -- [ C:/Program Files (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:840 ] _boost_RELEASE_ABI_TAG = - -- [ C:/Program Files (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:842 ] _boost_DEBUG_ABI_TAG = -gd -- [ C:/Program Files (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:890 ] _boost_LIBRARY_SEARCH_DIRS = c:\dev2\i\lib;c:\dev2\i/lib;c:\dev2\i/stage/lib;c:/dev2/i/inc lude/boost-1_55/lib;c:/dev2/i/include/boost-1_55/../lib;c:/dev2/i/include/boost-1_55/stage/lib;PATHS;C:/boost/lib;C:/boost;/sw/local/lib -- [ C:/Program Files (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:1001 ] Searching for SYSTEM_LIBRARY_RELEASE: boost_system-vc140-mt-1_55;boost_system-vc140-mt;bo ost_system-mt-1_55;boost_system-mt;boost_system -- [ C:/Program Files (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:1037 ] Searching for SYSTEM_LIBRARY_DEBUG: boost_system-vc140-mt-gd-1_55;boost_system-vc140-mt-g d;boost_system-mt-gd-1_55;boost_system-mt-gd;boost_system-mt;boost_system -- [ C:/Program Files (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:1088 ] Boost_FOUND = 1 CMake Error at C:/Program Files (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:1182 (message): Unable to find the requested Boost libraries. Boost version: 1.55.0 Boost include path: c:/dev2/i/include/boost-1_55 Could not find the following Boost libraries: boost_system No Boost libraries were found. You may need to set BOOST_LIBRARYDIR to the directory containing Boost libraries or BOOST_ROOT to the location of Boost. Call Stack (most recent call first): CMakeLists.txt:305 (find_package) CMake Error at CMakeLists.txt:307 (message): Did not find Boost. Boost is required for the core libraries, stage, sheets and krita. -- Configuring incomplete, errors occurred! -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org On Fri, 6 Nov 2015, Peter Steinbach wrote: > Hi to all, {sorry for the email mess, anyway here is my to answer to Andreas > as it affects this mail thread) > > thanks for the Boost_DEBUG hint. The output is much more concise and > digestible than "--trace". > > Good News: It works now. I discovered I had a cmake Windows build installed on > the machine that the MSYS2 terminal picked up. Once that was removed and I > used the msys internal cmake, it works out nicely. However, the MSVS > build target is gone now. So I have to find a way to use either version in > parallel somehow. > > Bad News: I didn't follow through why the problem occurred in the first place. > Once thing is for sure, the FindBoost module acutally triggered BOOST_FOUND=1! > But finding the actual libraries of boost failed. > > Best, > Peter > > > On Thursday, November 05, 2015 05:29:16 PM Peter Steinbach wrote: >> ---------- Forwarded Message ---------- >> >> Subject: Re: [CMake] cmake needs 2 runs to find boost >> Date: Thursday, November 05, 2015, 04:41:51 PM >> From: Andreas Naumann >> To: Peter Steinbach >> >> Hey Peter, >> >> It is not a solution, but I would set Boost_DEBUG to ON and compare the >> output of the first and the second cmake run. >> >> Andreas >> >> Am 05.11.2015 um 14:26 schrieb Peter Steinbach: >>> Hi to all, >>> >>> ok, I tried the attached minimal CMakeLists.txt again and found out that >>> it >>> fails in the way I described only with the "MSYS Makefiles" generator. If >>> I >>> use the same CMakeLists.txt without a custom generator (so MSVS is the >> >> default >> >>> IIRC), the libraries are found alright! >>> >>> Any ideas? >>> Best, >>> Peter >>> >>> On Thursday, November 05, 2015 01:41:33 PM Peter Steinbach wrote: >>>> Hi Benedikt, >>>> >>>> interesting thought, however I wonder why cmake is then capable of >>>> deducing >>>> the right boost version and include path. Just inside the first error >>>> message, I see: >>>> >>>> (x86)/CMake/share/cmake-3.2/Modules/FindBoost.cmake:1182 (message): >>>>>> Unable to find the requested Boost libraries. >>>>>> >>>>>> Boost version: 1.57.0 >>>>>> >>>>>> Boost include path: C:/msys64/mingw64/include >>>>>> >>>>>> Could not find the following static Boost libraries: >>>>>> boost_filesystem >>>>>> boost_system >>>> >>>> strange, isn't it? >>>> Peter >>>> >>>> On Thursday, November 05, 2015 11:41:10 AM Benedikt Hegner wrote: >>>>> Hi Peter, >>>>> >>>>> as I don't use windows at all, this is just a very wild guess... >>>>> >>>>> Could it be that in the second run you actually don't use >>>>> >>>>> /CMake/share/cmake-3.2/Modules/FindBoost.cmake >>>>> >>>>> but boost-config.cmake, which it now finds in the cached environment of >>>>> the first run? >>>>> >>>>> This assumes of course that you built boost w/ CMake and not bjam... >>>>> >>>>> Cheers, >>>>> >>>>> Benedikt >>>>> >>>>> On 03.11.2015 14:10, Peter Steinbach wrote: >>>>>> Hi to all, >>>>>> >>>>>> I tested this with cmake 3.2.2 and 3.3.2 and still get the same >>>>>> problem. >>>>>> I'd like to use boost with gcc on windows 7 64bit. I installed boost >>>>>> and >>>>>> gcc with msys2 as I cannot use MSVC for the actual project I am looking >>>>>> into for this. >>>>>> >>>>>> the funny thing, if I use the attached CMakeLists.txt on the machine >>>>>> and >>>>>> call: ``` >>>>>> $ cmake -G "MSYS Makefiles" -DBOOST_ROOT=C:/msys64/mingw64 - >>>>>> DBOOST_LIBRARYDIR==C:/msys64/mingw64/lib .. >>>>>> -- The CXX compiler identification is GNU 4.9.2 >>>>>> -- Check for working CXX compiler: C:/msys64/usr/bin/g++.exe >>>>>> -- Check for working CXX compiler: C:/msys64/usr/bin/g++.exe -- works >>>>>> -- Detecting CXX compiler ABI info >>>>>> -- Detecting CXX compiler ABI info - done >>>>>> -- Detecting CXX compile features >>>>>> -- Detecting CXX compile features - done >>>>>> setting win specific stuff >>>>>> CMake Error at C:/Program Files >>>>>> >>>>>> (x86)/CMake/share/cmake-3.2/Modules/FindBoost.cmake:1182 (message): >>>>>> Unable to find the requested Boost libraries. >>>>>> >>>>>> Boost version: 1.57.0 >>>>>> >>>>>> Boost include path: C:/msys64/mingw64/include >>>>>> >>>>>> Could not find the following static Boost libraries: >>>>>> boost_filesystem >>>>>> boost_system >>>>>> >>>>>> No Boost libraries were found. You may need to set >>>>>> BOOST_LIBRARYDIR >>>>>> to >>>>>> the >>>>>> directory containing Boost libraries or BOOST_ROOT to the location >>>>>> of >>>>>> Boost. >>>>>> >>>>>> Call Stack (most recent call first): >>>>>> CMakeLists.txt:17 (FIND_PACKAGE) >>>>>> >>>>>> CMake Error at CMakeLists.txt:24 (MESSAGE): >>>>>> Boost not found (C:/msys64/mingw64) >>>>>> >>>>>> -- Configuring incomplete, errors occurred! >>>>>> See also >>>>>> "C:/msys64/home/steinbac/development/cmake_sandbox/find_boost/build/CMa >>>>>> k >>>>>> eF >>>>>> iles/CMakeOutput.log". $ cmake -G "MSYS Makefiles" >>>>>> -DBOOST_ROOT=C:/msys64/mingw64 - >>>>>> DBOOST_LIBRARYDIR==C:/msys64/mingw64/lib .. >>>>>> setting win specific stuff >>>>>> Boost 1.57 found __ >>>>>> -- Configuring done >>>>>> -- Generating done >>>>>> -- Build files have been written to: >>>>>> C:/msys64/home/steinbac/development/cmake_sandbox/find_boost/build >>>>>> ``` >>>>>> >>>>>> I'd like to link statically to multithreaded libboost_*-mt.a from my >>>>>> app. >>>>>> But it proofes really hard to find Boost in the first place. >>>>>> Any ideas? >>>>>> >>>>>> Peter >> >> ----------------------------------------- > > -- > Peter Steinbach, Dr. rer. nat. > HPC Developer > > Scionics Computer Innovation GmbH > L?scherstr. 16 > 01309 Dresden > fon: +49 351 210 2882 > fax: +49 351 210 1689 > http://www.scionics.de > > Sitz der Gesellschaft: Dresden (Main office) > Amtsgericht - Registergericht: Dresden HRB 20337 (Commercial Registry) > Ust-IdNr.: DE813263791 (VAT ID Number) > Gesch?ftsf?hrer: John Duperon, Jeff Oegema (Managing Directors) > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > From nilsgladitz at gmail.com Mon Nov 9 10:09:12 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Mon, 9 Nov 2015 16:09:12 +0100 Subject: [CMake] WIX installer fails for shared files In-Reply-To: References: Message-ID: <5640B718.1010803@gmail.com> On 11/06/2015 08:06 PM, Mark Stijnman wrote: > > install(FILES 1.txt common.txt DESTINATION bin COMPONENT comp1) > install(FILES 2.txt common.txt DESTINATION bin COMPONENT comp2) > CMake does not implement any diagnostics that would prevent you from doing so but installing distinct files (or even the same file multiple times) to the same destination path is ill defined irregardless of it being in the same or distinct components. > > A partial workaround is to put shared files in a separate, hidden > CPack component/WIX feature, and set component dependencies. However, > with many shared DLLs, maintaining this gets complex really fast, so > I'd rather not have to do this. I think from CPack's point of view this is the proper thing to do. > > As an aside, is it really necessary to have separate staging folders > for each component? It should be safe to just have one staging folder, > unless two components in the same package install two different files > to the same destination - but shouldn't that be an error that CPack > should check for anyway? The (default) installation logic itself is implemented by cmake (cmake_install.cmake) and external to CPack. All the information CPack has available has to come from CPackConfig.cmake (+ files included from it) and what CPack finds in the staging areas after performing the installations. This includes only a subset of the information available to cmake. If installation were performed into a shared staging area CPack would not as easily be able to tell which file belongs to which component. Nils From Andreas-Naumann at gmx.net Mon Nov 9 11:34:32 2015 From: Andreas-Naumann at gmx.net (Andreas Naumann) Date: Mon, 9 Nov 2015 17:34:32 +0100 Subject: [CMake] Fwd: Re: cmake needs 2 runs to find boost In-Reply-To: References: <1921165.Wu4ixSjSQz@schorle.mpi-cbg.de> <2310174.8d9UscCb33@schorle.mpi-cbg.de> Message-ID: <5640CB18.6030309@gmx.net> Did boost change the naming convention? The documentation says, it should be named with vc. And therefore, cmake cannot find the library... Even the boost header files rely on the names in Visual studio. So, I would assume, your boost installation to be broken? Regards, Andreas Am 09.11.2015 um 11:36 schrieb Boudewijn Rempt: > I'm actually hitting a similar problem -- I know I've got boost_system > installed in > > c:\dev2\i\lib\boost_system-vc-mt-1_55.dll > c:\dev2\i\lib\boost_system-vc-mt-1_55.lib > > I run cmake like this: > > cmake ..\krita -G"Visual Studio 14 Win64" -DBoost_DEBUG=ON > -DBoost_FIND_QUIETLY=FALSE -DBOOST_INCLUDEDIR=c:\dev2\i\include > -DBOOST_ROOT=c:\dev2\i -DBOOST_LIBRARYDIR=c:\dev2\i\lib > -DCMAKE_INSTALL_PREFIX=c:\dev2\i -DCMAKE_PREFIX_PATH=c:\dev2\i > -DCMAKE_BUILD_TYPE=Release > > And the output is that boost_system isn't found, because it's looking > for vc140, instead of vc, it seems: > > > -- [ C:/Program Files > (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:515 ] > _boost_TEST_VERSIONS = > 1.58.0;1.58;1.57.0;1.57;1.56.0;1.56;1.55.0;1.55;1.54.0;1.54;1.53.0; > 1.53;1.52.0;1.52;1.51.0;1.51;1.50.0;1.50;1.49.0;1.49;1.48.0;1.48;1.47.0;1.47;1.46.1;1.46.0;1.46;1.45.0;1.45;1.44.0;1.44;1.43.0;1.43;1.42.0;1.42;1.41.0;1.41;1.40.0;1.40;1. > > 39.0;1.39;1.38.0;1.38;1.37.0;1.37;1.36.1;1.36.0;1.36;1.35.1;1.35.0;1.35;1.34.1;1.34.0;1.34;1.33.1;1.33.0;1.33 > > -- [ C:/Program Files > (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:517 ] > Boost_USE_MULTITHREADED = TRUE > -- [ C:/Program Files > (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:519 ] > Boost_USE_STATIC_LIBS = > -- [ C:/Program Files > (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:521 ] > Boost_USE_STATIC_RUNTIME = > -- [ C:/Program Files > (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:523 ] > Boost_ADDITIONAL_VERSIONS = > -- [ C:/Program Files > (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:525 ] > Boost_NO_SYSTEM_PATHS = > -- [ C:/Program Files > (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:577 ] Declared as > CMake or Environmental Variables: > -- [ C:/Program Files > (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:579 ] BOOST_ROOT = > c:\dev2\i > -- [ C:/Program Files > (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:581 ] > BOOST_INCLUDEDIR = c:\dev2\i\include > -- [ C:/Program Files > (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:583 ] > BOOST_LIBRARYDIR = c:\dev2\i\lib > -- [ C:/Program Files > (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:585 ] > _boost_TEST_VERSIONS = > 1.58.0;1.58;1.57.0;1.57;1.56.0;1.56;1.55.0;1.55;1.54.0;1.54;1.53.0; > 1.53;1.52.0;1.52;1.51.0;1.51;1.50.0;1.50;1.49.0;1.49;1.48.0;1.48;1.47.0;1.47;1.46.1;1.46.0;1.46;1.45.0;1.45;1.44.0;1.44;1.43.0;1.43;1.42.0;1.42;1.41.0;1.41;1.40.0;1.40;1. > > 39.0;1.39;1.38.0;1.38;1.37.0;1.37;1.36.1;1.36.0;1.36;1.35.1;1.35.0;1.35;1.34.1;1.34.0;1.34;1.33.1;1.33.0;1.33 > > -- [ C:/Program Files > (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:654 ] Include > debugging info: > -- [ C:/Program Files > (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:656 ] > _boost_INCLUDE_SEARCH_DIRS = > c:\dev2\i\include;c:\dev2\i/include;c:\dev2\i;PATHS;C:/boos > t/include;C:/boost;/sw/local/include > -- [ C:/Program Files > (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:658 ] > _boost_PATH_SUFFIXES = > boost-1_58_0;boost_1_58_0;boost/boost-1_58_0;boost/boost_1_58_0;b > oost-1_58;boost_1_58;boost/boost-1_58;boost/boost_1_58;boost-1_57_0;boost_1_57_0;boost/boost-1_57_0;boost/boost_1_57_0;boost-1_57;boost_1_57;boost/boost-1_57;boost/boost_ > > 1_57;boost-1_56_0;boost_1_56_0;boost/boost-1_56_0;boost/boost_1_56_0;boost-1_56;boost_1_56;boost/boost-1_56;boost/boost_1_56;boost-1_55_0;boost_1_55_0;boost/boost-1_55_0; > > boost/boost_1_55_0;boost-1_55;boost_1_55;boost/boost-1_55;boost/boost_1_55;boost-1_54_0;boost_1_54_0;boost/boost-1_54_0;boost/boost_1_54_0;boost-1_54;boost_1_54;boost/boo > > st-1_54;boost/boost_1_54;boost-1_53_0;boost_1_53_0;boost/boost-1_53_0;boost/boost_1_53_0;boost-1_53;boost_1_53;boost/boost-1_53;boost/boost_1_53;boost-1_52_0;boost_1_52_0 > > ;boost/boost-1_52_0;boost/boost_1_52_0;boost-1_52;boost_1_52;boost/boost-1_52;boost/boost_1_52;boost-1_51_0;boost_1_51_0;boost/boost-1_51_0;boost/boost_1_51_0;boost-1_51; > > boost_1_51;boost/boost-1_51;boost/boost_1_51;boost-1_50_0;boost_1_50_0;boost/boost-1_50_0;boost/boost_1_50_0;boost-1_50;boost_1_50;boost/boost-1_50;boost/boost_1_50;boost > > -1_49_0;boost_1_49_0;boost/boost-1_49_0;boost/boost_1_49_0;boost-1_49;boost_1_49;boost/boost-1_49;boost/boost_1_49;boost-1_48_0;boost_1_48_0;boost/boost-1_48_0;boost/boos > > t_1_48_0;boost-1_48;boost_1_48;boost/boost-1_48;boost/boost_1_48;boost-1_47_0;boost_1_47_0;boost/boost-1_47_0;boost/boost_1_47_0;boost-1_47;boost_1_47;boost/boost-1_47;bo > > ost/boost_1_47;boost-1_46_1;boost_1_46_1;boost/boost-1_46_1;boost/boost_1_46_1;boost-1_46_0;boost_1_46_0;boost/boost-1_46_0;boost/boost_1_46_0;boost-1_46;boost_1_46;boost > > /boost-1_46;boost/boost_1_46;boost-1_45_0;boost_1_45_0;boost/boost-1_45_0;boost/boost_1_45_0;boost-1_45;boost_1_45;boost/boost-1_45;boost/boost_1_45;boost-1_44_0;boost_1_ > > 44_0;boost/boost-1_44_0;boost/boost_1_44_0;boost-1_44;boost_1_44;boost/boost-1_44;boost/boost_1_44;boost-1_43_0;boost_1_43_0;boost/boost-1_43_0;boost/boost_1_43_0;boost-1 > > _43;boost_1_43;boost/boost-1_43;boost/boost_1_43;boost-1_42_0;boost_1_42_0;boost/boost-1_42_0;boost/boost_1_42_0;boost-1_42;boost_1_42;boost/boost-1_42;boost/boost_1_42;b > > oost-1_41_0;boost_1_41_0;boost/boost-1_41_0;boost/boost_1_41_0;boost-1_41;boost_1_41;boost/boost-1_41;boost/boost_1_41;boost-1_40_0;boost_1_40_0;boost/boost-1_40_0;boost/ > > boost_1_40_0;boost-1_40;boost_1_40;boost/boost-1_40;boost/boost_1_40;boost-1_39_0;boost_1_39_0;boost/boost-1_39_0;boost/boost_1_39_0;boost-1_39;boost_1_39;boost/boost-1_3 > > 9;boost/boost_1_39;boost-1_38_0;boost_1_38_0;boost/boost-1_38_0;boost/boost_1_38_0;boost-1_38;boost_1_38;boost/boost-1_38;boost/boost_1_38;boost-1_37_0;boost_1_37_0;boost > > /boost-1_37_0;boost/boost_1_37_0;boost-1_37;boost_1_37;boost/boost-1_37;boost/boost_1_37;boost-1_36_1;boost_1_36_1;boost/boost-1_36_1;boost/boost_1_36_1;boost-1_36_0;boos > > t_1_36_0;boost/boost-1_36_0;boost/boost_1_36_0;boost-1_36;boost_1_36;boost/boost-1_36;boost/boost_1_36;boost-1_35_1;boost_1_35_1;boost/boost-1_35_1;boost/boost_1_35_1;boo > > st-1_35_0;boost_1_35_0;boost/boost-1_35_0;boost/boost_1_35_0;boost-1_35;boost_1_35;boost/boost-1_35;boost/boost_1_35;boost-1_34_1;boost_1_34_1;boost/boost-1_34_1;boost/bo > > ost_1_34_1;boost-1_34_0;boost_1_34_0;boost/boost-1_34_0;boost/boost_1_34_0;boost-1_34;boost_1_34;boost/boost-1_34;boost/boost_1_34;boost-1_33_1;boost_1_33_1;boost/boost-1 > > _33_1;boost/boost_1_33_1;boost-1_33_0;boost_1_33_0;boost/boost-1_33_0;boost/boost_1_33_0;boost-1_33;boost_1_33;boost/boost-1_33;boost/boost_1_33 > > -- [ C:/Program Files > (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:678 ] location of > version.hpp: c:/dev2/i/include/boost-1_55/boost/version.hpp > -- [ C:/Program Files > (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:702 ] version.hpp > reveals boost 1.55.0 > -- [ C:/Program Files > (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:787 ] guessed > _boost_COMPILER = -vc140 > -- [ C:/Program Files > (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:797 ] > _boost_MULTITHREADED = -mt > -- [ C:/Program Files > (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:840 ] > _boost_RELEASE_ABI_TAG = - > -- [ C:/Program Files > (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:842 ] > _boost_DEBUG_ABI_TAG = -gd > -- [ C:/Program Files > (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:890 ] > _boost_LIBRARY_SEARCH_DIRS = > c:\dev2\i\lib;c:\dev2\i/lib;c:\dev2\i/stage/lib;c:/dev2/i/inc > lude/boost-1_55/lib;c:/dev2/i/include/boost-1_55/../lib;c:/dev2/i/include/boost-1_55/stage/lib;PATHS;C:/boost/lib;C:/boost;/sw/local/lib > > -- [ C:/Program Files > (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:1001 ] Searching > for SYSTEM_LIBRARY_RELEASE: > boost_system-vc140-mt-1_55;boost_system-vc140-mt;bo > ost_system-mt-1_55;boost_system-mt;boost_system > -- [ C:/Program Files > (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:1037 ] Searching > for SYSTEM_LIBRARY_DEBUG: > boost_system-vc140-mt-gd-1_55;boost_system-vc140-mt-g > d;boost_system-mt-gd-1_55;boost_system-mt-gd;boost_system-mt;boost_system > -- [ C:/Program Files > (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:1088 ] Boost_FOUND > = 1 > CMake Error at C:/Program Files > (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:1182 (message): > Unable to find the requested Boost libraries. > > Boost version: 1.55.0 > > Boost include path: c:/dev2/i/include/boost-1_55 > > Could not find the following Boost libraries: > > boost_system > > No Boost libraries were found. You may need to set BOOST_LIBRARYDIR > to the > directory containing Boost libraries or BOOST_ROOT to the location of > Boost. > Call Stack (most recent call first): > CMakeLists.txt:305 (find_package) > > > CMake Error at CMakeLists.txt:307 (message): > Did not find Boost. Boost is required for the core libraries, stage, > sheets and krita. > > > -- Configuring incomplete, errors occurred! > > > > From boud at valdyas.org Mon Nov 9 11:51:04 2015 From: boud at valdyas.org (Boudewijn Rempt) Date: Mon, 9 Nov 2015 17:51:04 +0100 (CET) Subject: [CMake] Fwd: Re: cmake needs 2 runs to find boost In-Reply-To: <5640CB18.6030309@gmx.net> References: <1921165.Wu4ixSjSQz@schorle.mpi-cbg.de> <2310174.8d9UscCb33@schorle.mpi-cbg.de> <5640CB18.6030309@gmx.net> Message-ID: On Mon, 9 Nov 2015, Andreas Naumann wrote: > Did boost change the naming convention? The documentation says, it should be > named with vc. And therefore, cmake cannot find the library... > Even the boost header files rely on the names in Visual studio. So, I would > assume, your boost installation to be broken? I don't know, I built boost using the included cmakelists.txt, like this: ExternalProject_Add( ext_boost DOWNLOAD_DIR ${EXTERNALS_DOWNLOAD_DIR} URL http://downloads.sourceforge.net/boost/boost_1_55_0.tar.bz2 #URL_MD5 3a855e0f919107e0ca4de4d84ad3f750 CONFIGURE_COMMAND /bootstrap.bat --prefix=${PREFIX_ext_boost} BUILD_COMMAND /b2.exe --with-system --build-dir=build-dir --prefix=${PREFIX_ext_boost} toolset=msvc variant=release link=shared threading=multi architecture=x86 address-model=64 variant=release install INSTALL_COMMAND "" INSTALL_DIR ${EXTPREFIX_boost} UPDATE_COMMAND "" ALWAYS 0 BUILD_IN_SOURCE 1 ) If that results in a broken boost, it's boost that broke stuff. Boudewijn From mark.stijnman at gmail.com Mon Nov 9 14:29:22 2015 From: mark.stijnman at gmail.com (Mark Stijnman) Date: Mon, 9 Nov 2015 20:29:22 +0100 Subject: [CMake] WIX installer fails for shared files In-Reply-To: <5640B718.1010803@gmail.com> References: <5640B718.1010803@gmail.com> Message-ID: Hi Nils, thanks for the reply. On Mon, Nov 9, 2015 at 4:09 PM, Nils Gladitz wrote: > CMake does not implement any diagnostics that would prevent you from doing > so but installing distinct files (or even the same file multiple times) to > the same destination path is ill defined irregardless of it being in the > same or distinct components. > Not in WiX, though - installing the same file from more than one feature is common practice. The shared component will just get a higher reference count. Installing different files to the same location, on the other hand, *is* an error in WiX, which is what I'm running into (even though they're really the same file). It also works as expected in the archive generators - as long as both files are the same, that is, otherwise it is indeed ill-defined. I think there should be a change in the CMake/CPack behavior here, regardless of whether the WiX generator will be extended to support this use case. For generators that support the same file to be installed from more than one component, such as the archive generators, it should check if the files are the same, and if not, report an error. Generators that don't support two files with the same destination at all should give an error when that occurs. A partial workaround is to put shared files in a separate, hidden CPack >> component/WIX feature, and set component dependencies. However, with many >> shared DLLs, maintaining this gets complex really fast, so I'd rather not >> have to do this. >> > > I think from CPack's point of view this is the proper thing to do. It's probably the most portable solution to do this at the CPack level, indeed. However, I found that the CPack WiX generator doesn't support cross-feature dependencies, so I can't automatically install the required files based on the user's feature selections. This is understandable, as WiX itself doesn't appear to have support for this. From what information I could find, the common approach in WiX is indeed to reference the common components (or component groups) from each feature that need them. I'll have to think about the best way to do this. best regards Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From scott at towel42.com Mon Nov 9 14:40:46 2015 From: scott at towel42.com (Scott Aron Bloom) Date: Mon, 9 Nov 2015 19:40:46 +0000 Subject: [CMake] Ctest executable dll/so search path In-Reply-To: References: Message-ID: The solution I came up with was the following.. SET_TESTS_PROPERTIES( ${TEST_NAME} PROPERTIES ENVIRONMENT "PATH=${TCL_BINDIR};$ENV{PATH}" ) It worked like a charm. Scott -----Original Message----- From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Iosif Neitzke Sent: Sunday, November 8, 2015 7:02 AM To: cmake at cmake.org Subject: Re: [CMake] Ctest executable dll/so search path A problem long-suffered on Windows and when lacking RPATH. Have seen approaches where DLL dependencies are POST_BUILD customed-command-copied-if-different into the executable directory, or gymnastics with add_test WORKING_DIRECTORY, or setting a test's ENVIRONMENT property. On Fri, Nov 6, 2015 at 3:14 PM, Scott Aron Bloom wrote: > I have a unit test, that I have have avoided deploying, because its > executable (gmock/gtest based) depends on a third party dll. > Essentially it?s a unit test to test our interface to the thirdparty > library. So for much of the application unittesting, I have a mock to > simulate the 3rd party lib.. But for this set of tests, I really want > to make sure the ACTUAL interface works. > > > > How can I add/set the PATH for an executable to run with so it picks > up the DLL (or so on linux)? > > > Scott > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For > more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 csiga.biga at aol.com Mon Nov 9 17:21:58 2015 From: csiga.biga at aol.com (=?utf-8?Q?Nagy-Egri_M=C3=A1t=C3=A9_Ferenc?=) Date: Mon, 9 Nov 2015 23:21:58 +0100 Subject: [CMake] Benchmarking with CMake Message-ID: Hi! Can anyone tell me if CMake (or CTest) can be customized in a way to produce decent benchmark output? An .xlsx perhaps, or something GnuPlot friendly? I have not found any examples of CTest being (ab)used in this way. Is my feeling correct, that this should be something like CBench? Cheers, M?t? -------------- next part -------------- An HTML attachment was scrubbed... URL: From irwin at beluga.phys.uvic.ca Mon Nov 9 21:02:29 2015 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Mon, 9 Nov 2015 18:02:29 -0800 (PST) Subject: [CMake] [ANNOUNCE] CMake 3.4.0-rc1 is now ready! In-Reply-To: <56291D38.6070409@kitware.com> References: <56148ABA.5070303@cora.nwra.com> <56154C15.3030806@cora.nwra.com> <562900AE.1060704@cora.nwra.com> <56291D38.6070409@kitware.com> Message-ID: On 2015-10-22 13:30-0400 Brad King wrote: [...] > Plplot's Ada support uses CMake internal APIs so it is plplot's > responsibility to adapt to our changes: [...] > Where Plplot currently writes: > > SET(CMAKE_Ada_COMPILE_OBJECT > " -c -o > ") > > try: > > if(NOT CMAKE_VERSION VERSION_LESS 3.4) > set(CMAKE_Ada_COMPILE_OBJECT > " -c -o ") > else() > set(CMAKE_Ada_COMPILE_OBJECT > " -c -o ") > endif() To bring this thread to conclusion, Orion implemented Brad's idea for PLplot's Ada language support (see ), and I just did the same thing for PLplot's D language support (see ) with good test results for Ada and D examples for both shared and static libraries and both CMake-3.3.2 and CMake-3.4.0-rc3. Thanks, Brad, for your essential help in solving these PLplot Ada and D issues caused by the internal changes in CMake's language support infrastructure for CMake-3.4. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From nilsgladitz at gmail.com Tue Nov 10 03:22:54 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 10 Nov 2015 09:22:54 +0100 Subject: [CMake] WIX installer fails for shared files In-Reply-To: References: <5640B718.1010803@gmail.com> Message-ID: <5641A95E.5040900@gmail.com> On 11/09/2015 08:29 PM, Mark Stijnman wrote: > > Not in WiX, though - installing the same file from more than one > feature is common practice. The shared component will just get a > higher reference count. Installing different files to the same > location, on the other hand, *is* an error in WiX, which is what I'm > running into (even though they're really the same file). It also works > as expected in the archive generators - as long as both files are the > same, that is, otherwise it is indeed ill-defined. > > I think there should be a change in the CMake/CPack behavior here, > regardless of whether the WiX generator will be extended to support > this use case. For generators that support the same file to be > installed from more than one component, such as the archive > generators, it should check if the files are the same, and if not, > report an error. Generators that don't support two files with the same > destination at all should give an error when that occurs. The installation (staging) logic is out of scope for CPack itself (CPack and CMake are distinct entities; CPack can be used without CMake) and within CMake it probably won't work either... CMake allows the installation to replace pre-existing files and tries to do so efficiently by using timestamp comparisons and omitting the operation if the source is not in fact newer than the destination. Even though this logic is not required when invoked through CPack (the staging area always starts out empty) it is still there. So replacing an existing file (which may have distinct content from the source) is expected and legal and actually comparing content is probably considered too expensive either way. > > A partial workaround is to put shared files in a separate, > hidden CPack component/WIX feature, and set component > dependencies. However, with many shared DLLs, maintaining this > gets complex really fast, so I'd rather not have to do this. > > > I think from CPack's point of view this is the proper thing to do. > > > It's probably the most portable solution to do this at the CPack > level, indeed. However, I found that the CPack WiX generator doesn't > support cross-feature dependencies, so I can't automatically install > the required files based on the user's feature selections. This is > understandable, as WiX itself doesn't appear to have support for this. > From what information I could find, the common approach in WiX is > indeed to reference the common components (or component groups) from > each feature that need them. I'll have to think about the best way to > do this. > In the WIX generator I suppose I could perhaps detect reused destination paths (in distinct components) and reuse references but I am not sure I like the idea of actually doing file content comparisons (though in this case it would be much more selective than doing it for the install step). Also this behavior would be specific to the WIX generator and would likely break semantically with every other generator. I wonder if I could perhaps instead do this automagically by merging hidden dependee components into their dependers. If you still think this is a good idea and something you would intend to use please open an issue. Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.stuermer at schaeffler.com Tue Nov 10 05:51:45 2015 From: michael.stuermer at schaeffler.com (Stuermer, Michael SP/HZA-ZSEP) Date: Tue, 10 Nov 2015 10:51:45 +0000 Subject: [CMake] Visual Studio variable in include_directories path? Message-ID: <4797EDAAB4843944A70CA99A7DE7D8BD06B53311@DE012432.schaeffler.com> I would like to add a Visual Studio variable such as $(VCInstallDir) to the include directories of a target. include_directories() obviously does not work, as cmake thinks the path is relative and the project path is prepended to my initial value. Any hints how I can do this? PS: the same with link_directories() and some link paths :( Best Regards Michael St?rmer SP/HZA-ZSEP Postcode HZA 13-4-06 SZ.Prozessdatenverarbeitung Schaeffler Technologies AG & Co. KG Industriestra?e 1-3 91074 Herzogenaurach (Germany) Tel. +49 91 32 / 82 - 86350 ? Fax +49 91 32 / 82 - 45 86350 Mobil.: +49 171 6860010 mailto:michael.stuermer at schaeffler.com ? http://www.ina.de Registered Seat: Herzogenaurach Commercial Register: AG F?rth HRA 9349 General Partner: INA Beteiligungsgesellschaft mit beschr?nkter Haftung Registered Seat: Herzogenaurach (Germany) Commercial Register: AG F?rth HRB 2379 Managing Directors: Klaus Rosenfeld (CEO), Prof. Dr. Peter Gutzmer, Norbert Indlekofer, Oliver Jung, Kurt Mirlach, Prof. Dr. Peter Pleus, Robert Schullan This e-mail message is intended only for the use of the named recipient-(s) and contains information which may be confidential or privileged. If you are not the intended recipient, be aware that any distribution, or use of the contents of this information is prohibited. If you have received this electronic transmission in error, please notify the sender and delete the material from the computer. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.stijnman at gmail.com Tue Nov 10 07:42:22 2015 From: mark.stijnman at gmail.com (Mark Stijnman) Date: Tue, 10 Nov 2015 13:42:22 +0100 Subject: [CMake] WIX installer fails for shared files In-Reply-To: <5641A95E.5040900@gmail.com> References: <5640B718.1010803@gmail.com> <5641A95E.5040900@gmail.com> Message-ID: On Tue, Nov 10, 2015 at 9:22 AM, Nils Gladitz wrote: > On 11/09/2015 08:29 PM, Mark Stijnman wrote: > > I think there should be a change in the CMake/CPack behavior here, > regardless of whether the WiX generator will be extended to support this > use case. For generators that support the same file to be installed from > more than one component, such as the archive generators, it should check if > the files are the same, and if not, report an error. Generators that don't > support two files with the same destination at all should give an error > when that occurs. > > > The installation (staging) logic is out of scope for CPack itself (CPack > and CMake are distinct entities; CPack can be used without CMake) and > within CMake it probably won't work either... > > CMake allows the installation to replace pre-existing files and tries to > do so efficiently by using timestamp comparisons and omitting the operation > if the source is not in fact newer than the destination. > Even though this logic is not required when invoked through CPack (the > staging area always starts out empty) it is still there. > So replacing an existing file (which may have distinct content from the > source) is expected and legal and actually comparing content is probably > considered too expensive either way. > > I understand, but this check for files with the same destination could (and IMHO should) still be done during the CPack generator stage. > In the WIX generator I suppose I could perhaps detect reused destination > paths (in distinct components) and reuse references but I am not sure I > like the idea of actually doing file content comparisons (though in this > case it would be much more selective than doing it for the install step). > That's what I've been thinking could be done, yes, but maybe it's not needed if dependencies would work (and definitely not needed if we simply not allow this situation at all, see below). > Also this behavior would be specific to the WIX generator and would likely > break semantically with every other generator. > Not every generator: at least the archive generators already allow this. But this is why I'm advocating to rigorously define (and enforce) the semantics of this situation for all CPack generators. However, I've just found that in https://cmake.org/Wiki/CMake:Component_Install_With_CPack, it says, under rules for components: "1. An object cannot belong to several COMPONENT" - so I guess it's already defined, just not enforced, leading to unspecified behavior. I think either all generators should enforce this rule (at the risk of breaking projects that depend on unspecified behavior) or rule 1 should be relaxed (in which case I'd like the WiX generator to support the relaxed rule). I think I'll file this as a separate issue report (not specific to the WiX generator). > I wonder if I could perhaps instead do this automagically by merging > hidden dependee components into their dependers. > > If you still think this is a good idea and something you would intend to > use please open an issue. > > Nils > I think WiX generator support for CPACK_COMPONENT_${COMPNAME}_DEPENDS would be good to have, regardless of what happens with the "two files with same destination" issue. I'll file an issue report for this. Thanks, best regards Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephan.menzel at gmail.com Tue Nov 10 10:26:06 2015 From: stephan.menzel at gmail.com (Stephan Menzel) Date: Tue, 10 Nov 2015 16:26:06 +0100 Subject: [CMake] Configuration dependent link Message-ID: Hello, I am trying to have config dependent link. Basically, coming from a set of 3rd party location scripts I have a Visual Studio target which I would like to equip with imported libs rather than the existing "manual" scripts. With that I have a few trouble that maybe someone can help me with. Configuration types are set (CMAKE_CONFIGURATION_TYPES "Debug;Release;RelWithDebInfo" CACHE STRING "..." FORCE) Libs usually come in 2 flavors, Release and Debug. So I create imported libs and put the configurations in: ... create imported lib set_property(TARGET ${name} PROPERTY IMPORTED_CONFIGURATIONS "") set_property(TARGET ${name} APPEND PROPERTY IMPORTED_CONFIGURATIONS "Debug") set_property(TARGET ${name} APPEND PROPERTY IMPORTED_CONFIGURATIONS "Release") set_property(TARGET ${name} APPEND PROPERTY IMPORTED_CONFIGURATIONS "RelWithDebInfo") So my first question, what is the relation here? Do I have to do this? Is the configuration name case sensitive? So then I worked my way through creating the imported libs and augmented the scripts in order to put locations and dependencies in the target's properties: set_property(TARGET ${name} APPEND PROPERTY IMPORTED_IMPLIB_Release ${implib}) set_property(TARGET ${name} APPEND PROPERTY IMPORTED_IMPLIB_RelWithDebInfo ${implib}) set_property(TARGET ${name} APPEND PROPERTY IMPORTED_IMPLIB_Debug ${implib}) ...and same for locations (DLLs) "implib" is the configuration specific lib here. After the procedure the property IMPORTED_IMPLIB_Debug and so on contain all the libs. When all the imported libs are created I was hoping to be able to link against them like so: target_link_libraries(${mylib} PUBLIC ${someimportedlib}) My problem is: Which Config is chosen? How can I tell target_link_libraries to link ${mylib} in Config Debug against ${someimportedlib} with the IMPORTED_IMPLIB_Debug properties? I was hoping this would be automatic as it is obvious information but that doesn't seem to work. Instead I usually get an additional linker dependency named my::lib.obj-NOTFOUND Also when doing all this manually appending to the property multiple times (as for example boost or Qt libraries with lots of libs to link against) seems to cause errors eventually. They appear in Visual Studio's properties dialog as _one_ Linker Dependency. For example: Like I add (resolved) add_library(sys::boost SHARED GLOBAL) ... setup lib ... set_property(TARGET sys::boost APPEND PROPERTY IMPORTED_IMPLIB_Release D:\3rd_party\boost_1_59_0\lib\vc110\x64\boost_atomic-vc110-mt-1_59.lib) set_property(TARGET sys::boost APPEND PROPERTY IMPORTED_IMPLIB_Release D:\3rd_party\boost_1_59_0\lib\vc110\x64\boost_chrono-vc110-mt-1_59.lib) set_property(TARGET sys::boost APPEND PROPERTY IMPORTED_IMPLIB_Release D:\3rd_party\boost_1_59_0\lib\vc110\x64\boost_date_time-vc110-mt-1_59.lib) ... and so on and the same for corresponding DLLs as location... eventually yields _one_ linker dependency called: D:\3rd_party\boost_1_59_0\lib\vc110\x64\boost_chrono-vc110-mt-1_59.lib%3BE:\3rd_party\boost_1_59_0\lib\vc110\x64\boost_date_time-vc110-mt-1_59.lib%3BE:\3rd_party\boost_1_59_0\lib\vc110\x64\boost_filesystem-vc110-mt-1_59.lib%3BE:\3rd_party\boost_1_59_0\lib\vc110 .... and so on. Visual Studio seems to hate that and throws errors. So I thought about extracting this property, foreach() it and then add the tokens as linker dependencies one at a time. Can I do that somehow? Config specific? And if so: why? When I dive this deep into what I would hope CMake is all about, I might as well keep the old hand made script based system that doesn't use imported targets. Sooo..... TL;DR 1) How can I have config specifc imported targets with multiple IMPLIBs? 2) Why should I? Isn't there a better, more canonical way? Hasn't this wheel been invented hundreds of times? Thanks a bunch for any hints here... I'm lost in properties. Stephan -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.mccormick at kitware.com Tue Nov 10 16:36:12 2015 From: matt.mccormick at kitware.com (Matt McCormick) Date: Tue, 10 Nov 2015 16:36:12 -0500 Subject: [CMake] Benchmarking with CMake In-Reply-To: <20151109222727.10855C3F39@public.kitware.com> References: <20151109222727.10855C3F39@public.kitware.com> Message-ID: Hi Mate, This blog post has an example of parsing and visualizing CTestCostData.txt. Although, that file was not created for that purpose: http://www.kitware.com/blog/home/post/556 Cheers, Matt On Mon, Nov 9, 2015 at 5:21 PM, Nagy-Egri M?t? Ferenc wrote: > Hi! > > > > Can anyone tell me if CMake (or CTest) can be customized in a way to produce > decent benchmark output? An .xlsx perhaps, or something GnuPlot friendly? I > have not found any examples of CTest being (ab)used in this way. > > > > Is my feeling correct, that this should be something like CBench? > > > > Cheers, > > M?t? > > > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 stephan.menzel at gmail.com Wed Nov 11 10:13:21 2015 From: stephan.menzel at gmail.com (Stephan Menzel) Date: Wed, 11 Nov 2015 16:13:21 +0100 Subject: [CMake] Configuration dependent link In-Reply-To: References: Message-ID: I have investigated further into this and still have no solution, but a hint, which anyone may be able to confirm. It appears like I was led astray by a number of bugs in target_link_libraries() which I was mistaking for intentional behavior and so I started to re-create the behavior manually. Which was wrong in the first place. So it boils down to the following: I create an imported lib add_library(my::imp SHARED IMPORTED GLOBAL) and import libraries and dlls like so (for all 3 configurations): set_property(TARGET my::imp APPEND PROPERTY IMPORTED_LOCATION_DEBUG some_debug.dll) set_property(TARGET my::imp APPEND PROPERTY INTERFACE_LINK_LIBRARIES_DEBUG some_debug.lib) and then link my own target to the imported: target_link_libraries(mylib PUBLIC myimp) When I do this without any .lib files being present in there, it will add an (implicit ?) link dependency to "my::imp-NOTFOUND.obj" - rather than nothing at all - which will choke the linker. I have tried all possible combinations of properties, not using the config specifics, using the INTERFACE_ prefixed rather than IMPORTED_ prefixed but that doesn't seem to make much difference. I have however reason to believe that it does work with at least one lib present. Unfortunately with boost far down as base dependency I cannot set libs unless risk of interference with boost's autolink feature. Turning it off and linking myself yielded a different error. It then adds something causing the linker to not find ".obj". This is however invisible in the MSVCs properties dialog. So I rather go with autolink on, as this at least gives me a visible faulty entry. Maybe this sheds some light on this. Still hope someone has a hint where I could look for ways of removing the faulty obj entry. Thanks, Stephan -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom.kacvinsky at vectorcast.com Wed Nov 11 11:30:07 2015 From: tom.kacvinsky at vectorcast.com (Tom Kacvinsky) Date: Wed, 11 Nov 2015 11:30:07 -0500 Subject: [CMake] Regression in 3.3.2 for linking Message-ID: I am seeing a regression is 3.3.2 (compiled from source on 64 bit Linux - CentOS 5.0) in the link phase whereby libraries/object files are repeated on the link line, resulting in multiple definition errors (and I don't want to use -Wl,-z,muldefs). There is also another issue where Qt shared libraries appear in the link line before the object files, so I get link errors because the DSO is not specified after the object files. I am not sure if this is related to how the Qt package has changed in 3.3.2. We are using a fairly old methods of obtaining Qt support. I can always try the newer method to see if I have any luck Any help would be appreciated. Coming up with a simple reproducer is going to take a while because our cmake configuration is fairly compliated -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob.a.mcdonald at gmail.com Wed Nov 11 14:04:13 2015 From: rob.a.mcdonald at gmail.com (Rob McDonald) Date: Wed, 11 Nov 2015 11:04:13 -0800 Subject: [CMake] SuperProject package/install Message-ID: All, I have a SuperProject set up with ExternalProject_add the way some other projects do. The SuperProject has two EP's -- Libraries and Main. Libraries has a bunch of its own EP's. Main is my core project. When some users use this setup, they're confused at the end -- everything has worked, but the project hasn't been installed, and the results of compilation are buried several directories deep. My Main project has a 'package' target set up by CPack. I'd like the SuperProject to conclude by executing that build target, and then copying the resulting file to the top-level build directory from the SuperProject. To complicate things, the target file name is not fixed, it uses the version number -- which is not known to the SuperProject level. Right now, the Main ExternalProject_add INSTALL_COMMAND is "". How can I change this (or add another step) to build the package target (I don't want to just hard-code make package, as it should work with MSVC too). I've tried things like '${CMAKE_COMMAND} cmake--build package' but haven't had any luck. Once I get package running, how can I get the system to copy the resulting *.zip file out to the top level directory? I'd like it to end up in the CMake build directory at the top of the SuperProject, but I haven't figured out how to make that happen yet. Thanks, Rob From omnijack at gmail.com Wed Nov 11 16:51:06 2015 From: omnijack at gmail.com (Jack Stalnaker) Date: Wed, 11 Nov 2015 15:51:06 -0600 Subject: [CMake] CMP0022 not set Message-ID: I'm getting a new warning from cmake version 2.8.12 Policy CMP0022 is not set: INTERFACE_LINK_LIBRARIES defines the link interface. etc... Target "xxx" has an INTERFACE_LINK_PROPERTIES property ... I've not set this property anywhere explicitly. I'm getting the warning from a target_link_libraries call where the library is a target defined in the same CMakeLists.txt file. Why am I getting this warning? Furthermore, if I set the cmake_policy as requested, I still get the same warning, with the same message that the cmake_policy has not been set. I do: cmake_policy (SET CMP0022 NEW) cmake_policy (GET CMP0022 Foo) message (STATUS "${Foo}") The message shows that CMP0022 is NEW, yet I still get the message that its undefiined. What am I doing wrong? --Jack -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.wirtz at simtech.uni-stuttgart.de Thu Nov 12 03:54:09 2015 From: daniel.wirtz at simtech.uni-stuttgart.de (Daniel Wirtz) Date: Thu, 12 Nov 2015 09:54:09 +0100 Subject: [CMake] Custom message if target fails Message-ID: <564453B1.5050306@simtech.uni-stuttgart.de> Dear all, i've been thinking on this for a while but i can't seem to get my head around how to solve this. The task is simple: How can i display a custom error message if a target fails to build for whatever reason? - cmake .. - make - - below the (compile-tool dependent error output) i'd like to print something like "Whoops it went wrong, type this and that or visit this or that website for help" i know this should ALSO be in the documentation, but you know how people intuitively avoid reading those important parts :-) any help/ideas are appreciated. -- Dr. Daniel Wirtz Dipl. Math. Dipl. Inf. SRC SimTech Pfaffenwaldring 5a +49 711 685 60044 From nilsgladitz at gmail.com Thu Nov 12 04:10:30 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 12 Nov 2015 10:10:30 +0100 Subject: [CMake] Custom message if target fails In-Reply-To: <564453B1.5050306@simtech.uni-stuttgart.de> References: <564453B1.5050306@simtech.uni-stuttgart.de> Message-ID: <56445786.5030103@gmail.com> On 11/12/2015 09:54 AM, Daniel Wirtz wrote: > Dear all, > > i've been thinking on this for a while but i can't seem to get my head > around how to solve this. > The task is simple: How can i display a custom error message if a > target fails to build for whatever reason? > - cmake .. > - make > - > - below the (compile-tool dependent error output) i'd like to print > something like "Whoops it went wrong, type this and that or visit this > or that website for help" > There is no generic build system feature for this. You haven't provided any details on what kind of target this concerns or what is to be diagnosed specifically but ... Assuming this is a custom target / custom command you could replace the actual command with a wrapper (e.g. cmake -P script) that: - runs the actual command (e.g. execute_process()) - outputs a message based on the actual command's exit status (e.g. message("This and that")) - exits with (roughly) the same exit status as the actual command (e.g. message(FATAL_ERROR) on failure)) For regular build targets (executables, libraries) there is nothing to be done at build time. Depending on what it is you are actually diagnosing you might want to try to diagnose it during configuration rather than during the build. Nils From stephan.menzel at gmail.com Thu Nov 12 04:50:19 2015 From: stephan.menzel at gmail.com (Stephan Menzel) Date: Thu, 12 Nov 2015 10:50:19 +0100 Subject: [CMake] Configuration dependent link In-Reply-To: References: Message-ID: Hey all, I have a few more findings about this before I finally give up and resort my old self made approach: It looks to me like the imported target mechanism is not propagating properties the way it could and probably should. Es specially not like it is described here: https://cmake.org/cmake/help/v3.4/command/target_link_libraries.html As an example consider the following example in which I try to create an imported target out of boost, taking the FindBoost Module as import: set(BOOST_REQUIRED_COMPONENTS atomic chrono date_time filesystem iostreams log math_tr1 program_options random regex serialization signals system unit_test_framework thread ) find_package(Boost ${Boost_REQUIRED_VERSION} REQUIRED COMPONENTS ${BOOST_REQUIRED_COMPONENTS} ) add_library(sys::boost SHARED IMPORTED GLOBAL) function(add_boost_imported_target component_name) if (NOT DEFINED component_name) message(SEND_ERROR "Error, the variable 'component_name' is not defined!") else() boost_target_name(${component_name} target prefix) add_library(${target} SHARED IMPORTED GLOBAL) set_property(TARGET ${target} PROPERTY INTERFACE_LINK_LIBRARIES_DEBUG ${${prefix}_LIBRARY_DEBUG}) set_property(TARGET ${target} PROPERTY INTERFACE_LINK_LIBRARIES_RELEASE ${${prefix}_LIBRARY_RELEASE}) set_property(TARGET ${target} PROPERTY INTERFACE_LINK_LIBRARIES_RELWITHDEBINFO ${${prefix}_LIBRARY_RELEASE}) set_property(TARGET ${target} PROPERTY INTERFACE_INCLUDE_DIRECTORIES ${Boost_INCLUDE_DIR}) set_property(TARGET ${target} PROPERTY INCLUDE_DIRECTORIES ${Boost_INCLUDE_DIR}) target_link_libraries(sys::boost INTERFACE ${target}) endif() endfunction(add_boost_imported_target) foreach (comp ${BOOST_REQUIRED_COMPONENTS}) add_boost_imported_target(${comp}) endforeach() Now as far as I can tell this should give me an IMPORTED target called sys::boost and create a number of sub-targets for each boost components. This appeared necessary to me as there is no way to have one sys::boost with multiple IMPLIBs on it. Alas, the target doesn't contain any libs at all: get_target_property(libs sys::boost LINK_LIBRARIES_DEBUG) message ("boost link: ${libs}") will yield empty output. However the manual clearly states that "Usage requirements are propagated by reading the INTERFACE_ variants of target properties from dependencies and appending the values to the non- INTERFACE_ variants of the operand." So INTERFACE_LINK_LIBRARIES_DEBUG of, say, sys::boost_atomic should appear as LINK_LIBRARIES_DEBUG of sys::boost_atomic. Which is not the case and in my opinion a bug. Which means I cannot have imported targets depending on each other (and propagating their libs) to create a structure with multiple implibs, nor can I put multiple implibs in one imported target. At least not for MSVC. As much as I liked the approach of IMPORTED libs, this forces me to go back to the self made scripts. I just wanted to put it out here in case anybody attempts the same. Cheers, Stephan -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.wirtz at simtech.uni-stuttgart.de Thu Nov 12 05:05:31 2015 From: daniel.wirtz at simtech.uni-stuttgart.de (Daniel Wirtz) Date: Thu, 12 Nov 2015 11:05:31 +0100 Subject: [CMake] Custom message if target fails In-Reply-To: <56445786.5030103@gmail.com> References: <564453B1.5050306@simtech.uni-stuttgart.de> <56445786.5030103@gmail.com> Message-ID: <5644646B.80204@simtech.uni-stuttgart.de> Hey, neat idea, i've tried and it works (i have custom targets there). However, the "nice" colored build text output of such a solution gets lost completely (pipes etc); are there any alternative ideas/solutions? thanks again! Dr. Daniel Wirtz Dipl. Math. Dipl. Inf. SRC SimTech Pfaffenwaldring 5a +49 711 685 60044 On 11/12/2015 10:10 AM, Nils Gladitz wrote: > On 11/12/2015 09:54 AM, Daniel Wirtz wrote: >> Dear all, >> >> i've been thinking on this for a while but i can't seem to get my >> head around how to solve this. >> The task is simple: How can i display a custom error message if a >> target fails to build for whatever reason? >> - cmake .. >> - make >> - >> - below the (compile-tool dependent error output) i'd like to print >> something like "Whoops it went wrong, type this and that or visit >> this or that website for help" >> > > There is no generic build system feature for this. > > You haven't provided any details on what kind of target this concerns > or what is to be diagnosed specifically but ... > > Assuming this is a custom target / custom command you could replace > the actual command with a wrapper (e.g. cmake -P script) that: > - runs the actual command (e.g. execute_process()) > - outputs a message based on the actual command's exit status > (e.g. message("This and that")) > - exits with (roughly) the same exit status as the actual command > (e.g. message(FATAL_ERROR) on failure)) > > For regular build targets (executables, libraries) there is nothing to > be done at build time. > Depending on what it is you are actually diagnosing you might want to > try to diagnose it during configuration rather than during the build. > > Nils From toth at fi.muni.cz Thu Nov 12 07:22:49 2015 From: toth at fi.muni.cz (=?UTF-8?B?xaBpbW9uIFTDs3Ro?=) Date: Thu, 12 Nov 2015 13:22:49 +0100 Subject: [CMake] Porting to CMAKE and utilizing the CPack Message-ID: <56448499.5060409@fi.muni.cz> I have managed to port my SW to CMake fine, but now I'm running into issues with the CPack package generation (debian packages for now). I'm using the "dh_xxxx" commands in the package generation for debian. What would be the equivalent in CMake? In particular, installing cron scripts, init.d scripts and systemd service files. Also is there a way to detect the presence systemd (and install systemd service file if this is the case, init.d script otherwise)? -- RNDr. ?imon T?th FI at MU (toth at fi.muni.cz) | CESNET (simon at cesnet.cz) From mkeeler at tenable.com Thu Nov 12 09:02:23 2015 From: mkeeler at tenable.com (Matthew Keeler) Date: Thu, 12 Nov 2015 14:02:23 +0000 Subject: [CMake] Porting to CMAKE and utilizing the CPack In-Reply-To: <56448499.5060409@fi.muni.cz> References: <56448499.5060409@fi.muni.cz> Message-ID: Installing arbitrary files is accomplished by adding install commands into your CMakeLists. The documentation for the command is here: https://cmake.org/cmake/help/v3.3/command/install.html For something like an init script or systemd unit file they are going to live outside the normal installation prefix. So you will need to do something like the following: if (IS_DIRECTORY /usr/lib/systemd/system) install(FILES myprog.service DESTINATION /usr/lib/systemd/system) else() install(FILES myprog DESTINATION /etc/init.d) endif() That code block will install the myprog.service file into /usr/lib/systemd/system if that directory exists and if not will install the myprog file (init script) int /etc/init.d I have found that checking if the usual systemd directory exists is sufficient to determine that systemd is present on the build system. If you are compiling on one debian version but want to support multiple versions then you will most likely install your init script and systemd files into some place specific to your application and use a post install script to detect which version should get installed. This will however bypass the package manager for installing these and thus if the package is removed/altered dpkg wont handle anything for you regarding these files. Check out the CpackDeb documentation for all the various variables that can be set to alter how the package builds and installs: https://cmake.org/cmake/help/v3.3/module/CPackDeb.html In particular if you need to have postinstall scripts then you will want to set the variable CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA -- Matt Keeler On November 12, 2015 at 07:37:14, ?imon T?th (toth at fi.muni.cz) wrote: I have managed to port my SW to CMake fine, but now I'm running into issues with the CPack package generation (debian packages for now). I'm using the "dh_xxxx" commands in the package generation for debian. What would be the equivalent in CMake? In particular, installing cron scripts, init.d scripts and systemd service files. Also is there a way to detect the presence systemd (and install systemd service file if this is the case, init.d script otherwise)? -- RNDr. ?imon T?th FI at MU (toth at fi.muni.cz) | CESNET (simon at cesnet.cz) -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware 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 irwin at beluga.phys.uvic.ca Thu Nov 12 12:07:16 2015 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Thu, 12 Nov 2015 09:07:16 -0800 (PST) Subject: [CMake] SuperProject package/install In-Reply-To: References: Message-ID: On 2015-11-11 11:04-0800 Rob McDonald wrote: > Right now, the Main ExternalProject_add INSTALL_COMMAND is "". How > can I change this (or add another step) to build the package target (I > don't want to just hard-code make package, as it should work with MSVC > too). I've tried things like '${CMAKE_COMMAND} cmake--build package' > but haven't had any luck. Hi Rob: Here is what I suggest you use: INSTALL_COMMAND ${INSTALL_COMMAND} where for the Unix-like case (Linux, Mac OS X, Cygwin, MinGW-w64/MSYS2, etc) I recommend you set the INSTALL_COMMAND variable to something like ${ENV_EXECUTABLE} PATH=${EPA_PATH} ${EPA_PARALLEL_BUILD_COMMAND} install where ENV_EXECUTABLE is the Unix env command, PATH is set appropriately for that command, and EPA_PARALLEL_BUILD_COMMAND is typically "make -j4". Of course, this logic is currently only suitable for the Unix case, but once I extend my own epa_build project to use MSVC, I plan to set the INSTALL_COMMAND variable to whatever is appropriate ("nmake install"?) for that case. Hope these ideas help. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From dschepler at scalable-networks.com Thu Nov 12 12:43:37 2015 From: dschepler at scalable-networks.com (Daniel Schepler) Date: Thu, 12 Nov 2015 17:43:37 +0000 Subject: [CMake] Custom message if target fails In-Reply-To: <5644646B.80204@simtech.uni-stuttgart.de> References: <564453B1.5050306@simtech.uni-stuttgart.de> <56445786.5030103@gmail.com>,<5644646B.80204@simtech.uni-stuttgart.de> Message-ID: I'm assuming this is under a Unix platform - in my experience, on Windows, I get the color escape codes even running cmake builds under Jenkins. On Unix platforms, you could install expect and use the unbuffer tool, e.g. "unbuffer make -j8 -k". -- Daniel Schepler ________________________________________ From: CMake [cmake-bounces at cmake.org] on behalf of Daniel Wirtz [daniel.wirtz at simtech.uni-stuttgart.de] Sent: Thursday, November 12, 2015 2:05 AM To: cmake at cmake.org Subject: Re: [CMake] Custom message if target fails Hey, neat idea, i've tried and it works (i have custom targets there). However, the "nice" colored build text output of such a solution gets lost completely (pipes etc); are there any alternative ideas/solutions? thanks again! Dr. Daniel Wirtz Dipl. Math. Dipl. Inf. SRC SimTech Pfaffenwaldring 5a +49 711 685 60044 On 11/12/2015 10:10 AM, Nils Gladitz wrote: > On 11/12/2015 09:54 AM, Daniel Wirtz wrote: >> Dear all, >> >> i've been thinking on this for a while but i can't seem to get my >> head around how to solve this. >> The task is simple: How can i display a custom error message if a >> target fails to build for whatever reason? >> - cmake .. >> - make >> - >> - below the (compile-tool dependent error output) i'd like to print >> something like "Whoops it went wrong, type this and that or visit >> this or that website for help" >> > > There is no generic build system feature for this. > > You haven't provided any details on what kind of target this concerns > or what is to be diagnosed specifically but ... > > Assuming this is a custom target / custom command you could replace > the actual command with a wrapper (e.g. cmake -P script) that: > - runs the actual command (e.g. execute_process()) > - outputs a message based on the actual command's exit status > (e.g. message("This and that")) > - exits with (roughly) the same exit status as the actual command > (e.g. message(FATAL_ERROR) on failure)) > > For regular build targets (executables, libraries) there is nothing to > be done at build time. > Depending on what it is you are actually diagnosing you might want to > try to diagnose it during configuration rather than during the build. > > Nils -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake From robert.maynard at kitware.com Thu Nov 12 13:56:05 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 12 Nov 2015 13:56:05 -0500 Subject: [CMake] [ANNOUNCE] CMake 3.4.0 Released Message-ID: I am proud to announce that CMake 3.4.0 is now available for download at: https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.4 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.4/release/3.4.html Some of the more significant features of CMake 3.4 are: * The "if()" command learned a new "TEST" operator that evaluates to true if a given test name has been defined by the "add_test()" command. See policy "CMP0064". * The "install(DIRECTORY)" command "DESTINATION" option learned to support "generator expressions". * The "install(FILES)" command "DESTINATION" option learned to support "generator expressions". * CMake learned to honor "*.manifest" source files with MSVC tools. Manifest files named as sources of ".exe" and ".dll" targets will be merged with linker-generated manifests and embedded in the binary. Deprecated and Removed Features: * The "CMakeExpandImportedTargets" module is now documented as deprecated. See module documentation for an explanation. * The "CMAKE_USE_RELATIVE_PATHS" variable no longer has any effect. Previously it was partially implemented and unreliable. CMake 3.4 Release Notes *********************** Changes made since CMake 3.3 include the following. New Features ============ Generators ---------- * The "Visual Studio 14 2015" generator learned to select a Windows 10 SDK based on the value of the "CMAKE_SYSTEM_VERSION" variable and the SDKs available on the host. * CMake learned rudimentary support for the Apple Swift language. When using the "Xcode" generator with Xcode 6.1 or higher, one may enable the "Swift" language with the "enable_language()" command or the "project()" command (this is an error with other generators or when Xcode is too old). Then one may list ".swift" source files in targets for compilation. Commands -------- * The "find_program()" command learned a "NAMES_PER_DIR" option to consider all given "NAMES" in each directory before moving on to the next directory. * The "get_filename_component()" command learned a new "BASE_DIR" subcommand. This is used to specify a base directory when calculating an absolute path from a relative path. * The "if()" command learned a new "TEST" operator that evaluates to true if a given test name has been defined by the "add_test()" command. See policy "CMP0064". * The "install(DIRECTORY)" command "DESTINATION" option learned to support "generator expressions". * The "install(FILES)" command "DESTINATION" option learned to support "generator expressions". * The "string()" command learned a new "APPEND" subcommand. Variables --------- * The Makefile Generators and the "Ninja" generator learned to add compiler launcher tools like distcc and ccache along with the compiler for "C" and "CXX" languages. See the "CMAKE__COMPILER_LAUNCHER" variable and "_COMPILER_LAUNCHER" target property for details. * New "CMAKE_LINK_SEARCH_START_STATIC" and "CMAKE_LINK_SEARCH_END_STATIC" variables were introduced to initialize the "LINK_SEARCH_START_STATIC" and "LINK_SEARCH_END_STATIC" target properties, respectively. Properties ---------- * Visual Studio Generators learned to support additonal target properties to customize projects for NVIDIA Nsight Tegra Visual Studio Edition: * "ANDROID_ANT_ADDITIONAL_OPTIONS" * "ANDROID_ARCH" * "ANDROID_ASSETS_DIRECTORIES" * "ANDROID_JAR_DEPENDENCIES" * "ANDROID_JAR_DIRECTORIES" * "ANDROID_JAVA_SOURCE_DIR" * "ANDROID_NATIVE_LIB_DEPENDENCIES" * "ANDROID_NATIVE_LIB_DIRECTORIES" * "ANDROID_PROCESS_MAX" * "ANDROID_PROGUARD" * "ANDROID_PROGUARD_CONFIG_PATH" * "ANDROID_SECURE_PROPS_PATH" * "ANDROID_SKIP_ANT_STEP" * "ANDROID_STL_TYPE" * The "ARCHIVE_OUTPUT_DIRECTORY", "LIBRARY_OUTPUT_DIRECTORY", and "RUNTIME_OUTPUT_DIRECTORY" target properties learned to support "generator expressions". * The "SOURCE_DIR" and "BINARY_DIR" target properties were introduced to allow project code to query where a target is defined. * The "OUTPUT_NAME" target property and its variants learned to support "generator expressions". * A "TARGET_MESSAGES" global property was added to tell the Makefile Generators whether to generate commands to print output after each target is completed. * On Windows with MS-compatible tools, CMake learned to optionally generate a module definition (".def") file for "SHARED" libraries. See the "WINDOWS_EXPORT_ALL_SYMBOLS" target property. Modules ------- * The "ExternalProject" module "ExternalProject_Add()" function "GIT_SUBMODULES" option now also limits the set of submodules that are initialized in addition to the prior behavior of limiting the set of submodules that are updated. * The "ExternalProject" module learned new "USES_TERMINAL" arguments for giving steps exclusive terminal access. This is useful with the "Ninja" generator to monitor CMake superbuild progress and prevent CPU oversubscription. * The "FindBISON" module "BISON_TARGET" macro learned a new "DEFINES_FILE" option to specify a custom output header to be generated. * The "FindHDF5" module learend a new "HDF5_PREFER_PARALLEL" option allowing users to specify that a parallel HDF5 tool is preferred if both are available. * The "FindIce" module now provides imported targets. * The "FindJava" module learned to optionally find the "idlj" and "jarsigner" tools. * The "FindOpenSSL" module now provides imported targets. * The "FindOpenSSL" module learned a new "OPENSSL_USE_STATIC_LIBS" option to search only for static libraries. * The "FindPkgConfig" learned a new "pkg_get_variable()" command which may be used to query for arbitrary variables from a package (such as for related tools or data and plugin install paths). * The "FindProtobuf" module gained a new "protobuf_generate_python()" function to generate python sources from ".proto" files. * The "FindTIFF" module learned to search separately for debug and release variants. * The "FindwxWidgets" module learned to support version requests. * The "FindXercesC" module learned to search separately for debug and release variants. * The "FindZLIB" module learned to search separately for debug and release variants. * The "GNUInstallDirs" module learned special default values for certain installation prefixes according to the GNU Coding Standards and the Filesystem Hierarchy Standard. * The "UseJava" module "add_jar" function learned to support response files (e.g. "@srcs.txt") for source specification. * The "UseJava" module "install_jar" function learned new "DESTINATION" and "COMPONENT" options to specify the corresponding "install()" command options. * The "UseJava" module gained a new "create_javah" function to create C headers from Java classes. Generator Expressions --------------------- * A new "$" "generator expression" has been added. CTest ----- * CTest learned to optionally measure the CPU load during parallel testing and avoid starting tests that may cause the load to exceed a given threshold. See the "ctest(1)" command "--test-load" option, the "TestLoad" setting of the CTest Test Step, the "CTEST_TEST_LOAD" variable, and the "TEST_LOAD" option of the "ctest_test()" command. * "ctest(1)" learned options "--test-output-size-passed" and "-- test- output-size-failed" to customize the limit on test output size submitted when running as a Dashboard Client. CPack ----- * The "CPackDeb" module learned to set package dependencies per component. See variables: * "CPACK_DEBIAN__PACKAGE_BREAKS" * "CPACK_DEBIAN__PACKAGE_CONFLICTS" * "CPACK_DEBIAN__PACKAGE_ENHANCES" * "CPACK_DEBIAN__PACKAGE_PREDEPENDS" * "CPACK_DEBIAN__PACKAGE_PROVIDES" * "CPACK_DEBIAN__PACKAGE_RECOMMENDS" * "CPACK_DEBIAN__PACKAGE_REPLACES" * "CPACK_DEBIAN__PACKAGE_SUGGESTS" * The "CPack" module learned to package empty directories. * The "CPack" module gained a new setting, "CPACK_VERBATIM_VARIABLES", which can be used to ensure the cpack program receives the settings' values exactly as they were set, even if they contain CMake-special characters. For compatibility, it's off by default. Other ----- * The "Compile Features" functionality is now aware of features supported by GNU C compilers on Windows. * CMake learned to honor "*.manifest" source files with MSVC tools. Manifest files named as sources of ".exe" and ".dll" targets will be merged with linker-generated manifests and embedded in the binary. * The Concurrent Fortran 77 compiler is now supported. Its "compiler id" is "CCur". * "cmake(1)" gained a new "--trace-expand" command line option that is like "--trace" but expands variable references in the output. Deprecated and Removed Features =============================== * The "CMakeExpandImportedTargets" module is now documented as deprecated. See module documentation for an explanation. * The "CMAKE_USE_RELATIVE_PATHS" variable no longer has any effect. Previously it was partially implemented and unreliable. Other Changes ============= * The "CheckFunctionExists", "CheckLibraryExists", "CheckSymbolExists", and "FindThreads" modules learned to work in environments where only CXX is enabled. * The "CPackDeb" module now correctly excludes symlinks during package checksum calculation. * The "CPackDeb" no longer uses fakeroot and system tar program for packaging. * The "CPack" module no longer mangles settings with CMake-special characters when they're used as defaults for other settings. The macro "cpack_set_if_not_set", which was responsible for this, is now deprecated. * CMake no longer links executables with flags to export symbols unless the "ENABLE_EXPORTS" target property is set. See policy "CMP0065". * The "SONAME" field is no longer set for "MODULE" libraries created with the "add_library()" command. "MODULE" libraries are meant for explicit dynamic loading at runtime. They cannot be linked so "SONAME" is not useful. * The internal "CMAKE__COMPILE_OBJECT" rule variable now substitutes compiler include flags in a separate "" placeholder instead of the main "" placeholder. -------------------------------------------------------------------- Changes made since CMake 3.4.0-rc3: Brad King (1): CMake 3.4.0 Stephen Kelly (1): Install: Move SetHaveInstallRule to a more-obvious place From Kent.Knox at amd.com Thu Nov 12 11:53:32 2015 From: Kent.Knox at amd.com (Knox, Kent) Date: Thu, 12 Nov 2015 16:53:32 +0000 Subject: [CMake] SuperProject package/install In-Reply-To: References: Message-ID: [rm] Right now, the Main ExternalProject_add INSTALL_COMMAND is "". How can I change this (or add another step) to build the package target (I don't want to just hard-code make package, as it should work with MSVC too). I've tried things like '${CMAKE_COMMAND} cmake--build package' but haven't had any luck. [kk] 'package' is a target of your generated build environment. You can specify to 'cmake --build' a target of your choosing. Look at the '--build' docs here: https://cmake.org/cmake/help/v3.3/manual/cmake.1.html BUILD_COMMAND ${CMAKE_COMMAND} --build --target package [rm] Once I get package running, how can I get the system to copy the resulting *.zip file out to the top level directory? [kk] Add a custom step to your external project, which depends on the build/install step to finish to copy whatever you want ExternalProject_Add_Step( myEPname copyPackage COMMAND ${CMAKE_COMMAND} -E copy_directory ${myLibDir} ${packageDir}/${LIB_DIR} COMMAND ${CMAKE_COMMAND} -E copy_directory /include ${packageDir}/include DEPENDEES build ) ---------------------------------------------------------------------- Message: 1 Date: Wed, 11 Nov 2015 11:04:13 -0800 From: Rob McDonald To: CMake ML Subject: [CMake] SuperProject package/install Message-ID: Content-Type: text/plain; charset=UTF-8 All, I have a SuperProject set up with ExternalProject_add the way some other projects do. The SuperProject has two EP's -- Libraries and Main. Libraries has a bunch of its own EP's. Main is my core project. When some users use this setup, they're confused at the end -- everything has worked, but the project hasn't been installed, and the results of compilation are buried several directories deep. My Main project has a 'package' target set up by CPack. I'd like the SuperProject to conclude by executing that build target, and then copying the resulting file to the top-level build directory from the SuperProject. To complicate things, the target file name is not fixed, it uses the version number -- which is not known to the SuperProject level. Right now, the Main ExternalProject_add INSTALL_COMMAND is "". How can I change this (or add another step) to build the package target (I don't want to just hard-code make package, as it should work with MSVC too). I've tried things like '${CMAKE_COMMAND} cmake--build package' but haven't had any luck. Once I get package running, how can I get the system to copy the resulting *.zip file out to the top level directory? I'd like it to end up in the CMake build directory at the top of the SuperProject, but I haven't figured out how to make that happen yet. Thanks, Rob From a.neundorf-work at gmx.net Thu Nov 12 15:23:51 2015 From: a.neundorf-work at gmx.net (Alexander Neundorf) Date: Thu, 12 Nov 2015 21:23:51 +0100 Subject: [CMake] Benchmarking with CMake In-Reply-To: <20151109222727.07D1FC3F38@public.kitware.com> References: <20151109222727.07D1FC3F38@public.kitware.com> Message-ID: <6737644.GvHR0EEI07@tuxedo.neundorf.net> On Monday, November 09, 2015 23:21:58 Nagy-Egri M?t? Ferenc via CMake wrote: > Hi! > > Can anyone tell me if CMake (or CTest) can be customized in a way to produce > decent benchmark output? An .xlsx perhaps, or something GnuPlot friendly? I > have not found any examples of CTest being (ab)used in this way. > > Is my feeling correct, that this should be something like CBench? depending on what you want... You can make your test output tags, and cdash will create graphs from the measured numbers. I think they can also be exported to csv. Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From csiga.biga at aol.com Fri Nov 13 08:41:35 2015 From: csiga.biga at aol.com (=?utf-8?Q?Nagy-Egri_M=C3=A1t=C3=A9_Ferenc?=) Date: Fri, 13 Nov 2015 14:41:35 +0100 Subject: [CMake] Benchmarking with CMake In-Reply-To: <20151109222727.35C2FC3F42@public.kitware.com> References: <20151109222727.35C2FC3F42@public.kitware.com> Message-ID: Thank you all for your resonses, My use case is that I have a set of executables that function as unit tests. Currently I use the return value of the .exe as a means of indicating success, though I know there is way to match std::cout against a regex for more complex tests. However, the timings of the tests are not always suitable for benchmarking, because I only want the timings of a particular part of the tests. Their initialization times are comparable to their runtimes. While I could tune a parameter so that the init phase is negligable, but then benchmarking would take for ages. I want to write benchmark executables (similar to unit tests) that write a single number to the console and nothing else. Run some command (make bench?, cbench?) which runs, these tests, fetches the sole number from the std::cout and prints those numbers as output instead of the total run time presented by ctest. @Peter: I also encountered Google Benchmark. I have already seen it?s output and is perfectly fine. I am however a bit reluctant to grab another dependency that all my consumers would be advised to install. CMake is a fairly full blown suite and I was hoping to find something that could provide similar results. @Matt: Seems nice. Python is not much a dependency, but VTK is less evident to be present on all machines. @Alexander: I still have to look into this, because information seems a little scarce on doing it. It seems to me, that CDash has to be installed somewhere to be able visualize the data. Is there a way to generate the HTML-r for local consumption instead of submitting somewhere? (Ideally bypassing a local installation of CDash) I know, I have a lot of problems. Ultimately I will choose one of the above, I was just looking for the one that is the least painful. I am very reluctant on obtaining dependencies. CMake is such a good tool, it seems strange to me that no direct benchmarking support has been added yet. Any ideas? Felad?: Nagy-Egri M?t? Ferenc via CMake Elk?ldve: 2015. november 9., h?tf? 23:27 C?mzett: CMake felhaszn?l?k T?rgy: [CMake] Benchmarking with CMake Hi! Can anyone tell me if CMake (or CTest) can be customized in a way to produce decent benchmark output? An .xlsx perhaps, or something GnuPlot friendly? I have not found any examples of CTest being (ab)used in this way. Is my feeling correct, that this should be something like CBench? Cheers, M?t? -------------- next part -------------- An HTML attachment was scrubbed... URL: From houssen at ipgp.fr Fri Nov 13 12:28:51 2015 From: houssen at ipgp.fr (houssen) Date: Fri, 13 Nov 2015 18:28:51 +0100 Subject: [CMake] Executable using a library (.a or .so) Message-ID: <994cad0c31293c616cf21547cfe3c4b0@imap.ipgp.fr> Hello, How to write a library (myLib as .a or .so) that can be used from an executable (myExe) ? I read the CMake doc but, obviously, I still miss some major points !... My understanding is that, I need : - to write a FindMyLib.cmake for myExe to find myLib (= finding include/library directories, and, libraries to link with) - to use find_package from myExe to find myLib I tried to write a mini-project (attached to this mail) to do that but it doesn't work: find_package doesn't find FindMyLib.cmake although CMAKE_MODULE_PATH has been updated. Can somebody help me on making this project to work ? (not able to find FindMyLib.cmake, not sure to know the "good" way to write FindMyLib.cmake, others... - I would appreciate any remarks to explain me the "good" way to do thing) Thanks, Franck Note: I set CMAKE_MODULE_PATH in the CMakeLists.txt of myLib (doing that from myExe sounds not relevant: if you know where the package is, no need to call find_package). Note: my understanding is that when this will work, I would be possible to build myLib as a .a or a .so, am I correct ? -------------- next part -------------- A non-text attachment was scrubbed... Name: myProject.tar.gz Type: application/x-gzip Size: 1087 bytes Desc: not available URL: From d3ck0r at gmail.com Fri Nov 13 12:51:46 2015 From: d3ck0r at gmail.com (J Decker) Date: Fri, 13 Nov 2015 09:51:46 -0800 Subject: [CMake] Executable using a library (.a or .so) In-Reply-To: <994cad0c31293c616cf21547cfe3c4b0@imap.ipgp.fr> References: <994cad0c31293c616cf21547cfe3c4b0@imap.ipgp.fr> Message-ID: is this library required to be separate from the executable? If not; it's far easier... add_library( MyLib libsource1.c libsource2.cpp ) add_exectubable( MyExe exesource1.c ) target_link_libraries( MyExe MyLib ) On Fri, Nov 13, 2015 at 9:28 AM, houssen wrote: > Hello, > > How to write a library (myLib as .a or .so) that can be used from an > executable (myExe) ? > > I read the CMake doc but, obviously, I still miss some major points !... My > understanding is that, I need : > - to write a FindMyLib.cmake for myExe to find myLib (= finding > include/library directories, and, libraries to link with) > - to use find_package from myExe to find myLib > > I tried to write a mini-project (attached to this mail) to do that but it > doesn't work: find_package doesn't find FindMyLib.cmake although > CMAKE_MODULE_PATH has been updated. > > Can somebody help me on making this project to work ? (not able to find > FindMyLib.cmake, not sure to know the "good" way to write FindMyLib.cmake, > others... - I would appreciate any remarks to explain me the "good" way to > do thing) > > Thanks, > > Franck > > Note: I set CMAKE_MODULE_PATH in the CMakeLists.txt of myLib (doing that > from myExe sounds not relevant: if you know where the package is, no need to > call find_package). > Note: my understanding is that when this will work, I would be possible to > build myLib as a .a or a .so, am I correct ? > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 Fri Nov 13 12:53:24 2015 From: d3ck0r at gmail.com (J Decker) Date: Fri, 13 Nov 2015 09:53:24 -0800 Subject: [CMake] Executable using a library (.a or .so) In-Reply-To: References: <994cad0c31293c616cf21547cfe3c4b0@imap.ipgp.fr> Message-ID: On Fri, Nov 13, 2015 at 9:51 AM, J Decker wrote: > is this library required to be separate from the executable? > If not; it's far easier... > # in MyLib/CmakeLists.txt > add_library( MyLib libsource1.c libsource2.cpp ) # in MyExe/CmakeLists.txt > add_exectubable( MyExe exesource1.c ) > target_link_libraries( MyExe MyLib ) > theose can be spread ito sepatate CMakeLists... with a root CmakeLists.txt like... --- cmake_minimum_version(something) add_subdirectory( mylib ) add_subdirectory( myExe) > > On Fri, Nov 13, 2015 at 9:28 AM, houssen wrote: >> Hello, >> >> How to write a library (myLib as .a or .so) that can be used from an >> executable (myExe) ? >> >> I read the CMake doc but, obviously, I still miss some major points !... My >> understanding is that, I need : >> - to write a FindMyLib.cmake for myExe to find myLib (= finding >> include/library directories, and, libraries to link with) >> - to use find_package from myExe to find myLib >> >> I tried to write a mini-project (attached to this mail) to do that but it >> doesn't work: find_package doesn't find FindMyLib.cmake although >> CMAKE_MODULE_PATH has been updated. >> >> Can somebody help me on making this project to work ? (not able to find >> FindMyLib.cmake, not sure to know the "good" way to write FindMyLib.cmake, >> others... - I would appreciate any remarks to explain me the "good" way to >> do thing) >> >> Thanks, >> >> Franck >> >> Note: I set CMAKE_MODULE_PATH in the CMakeLists.txt of myLib (doing that >> from myExe sounds not relevant: if you know where the package is, no need to >> call find_package). >> Note: my understanding is that when this will work, I would be possible to >> build myLib as a .a or a .so, am I correct ? >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware 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 jay.custin at hpe.com Fri Nov 13 15:07:22 2015 From: jay.custin at hpe.com (Custin, Jay (CSC Sw Middleware)) Date: Fri, 13 Nov 2015 20:07:22 +0000 Subject: [CMake] CMake port to OpenVMS - confusing behavior in cmliblzma code tree, specifically the config.h file generated from config.h.in Message-ID: After somewhat of an archeological dig I have finally traced down the following error message: [ 12%] Building C object Utilities/cmliblzma/CMakeFiles/cmliblzma_dir/liblzma/check/check.c.o cd /PRJ_ROOT/CMAKE-3_3_2/Utilities/cmliblzma && /bin/cc -Wc/warnings=disable=all/lis/show=all -w -I/PRJ_ROOT/CMAKE-3_3_2/Utilities -I/PRJ_ROOT/CMAKE-3_3_2/Utilities/cmliblzma/common -I/PRJ_ROOT/CMAKE-3_3_2/Utilities/cmliblzma/liblzma/api -I/PRJ_ROOT/CMAKE-3_3_2/ Utilities/cmliblzma/liblzma/check -I/PRJ_ROOT/CMAKE-3_3_2/Utilities/cmliblzma/liblzma/common -I/PRJ_ROOT/CMAKE-3_3_2/Utilities/cmlib lzma/liblzma/delta -I/PRJ_ROOT/CMAKE-3_3_2/Utilities/cmliblzma/liblzma/lz -I/PRJ_ROOT/CMAKE-3_3_2/Utilities/cmliblzma/liblzma/lzma - I/PRJ_ROOT/CMAKE-3_3_2/Utilities/cmliblzma/liblzma/rangecoder -I/PRJ_ROOT/CMAKE-3_3_2/Utilities/cmliblzma/liblzma/simple -I/PRJ_ROOT /CMAKE-3_3_2/Utilities/cmliblzma -o CMakeFiles/cmliblzma_dir/liblzma/check/check.c.o -c /PRJ_ROOT/CMAKE-3_3_2/Utilities/cmliblz ma/liblzma/check/check.c typedef uint64_t uintptr_t; ....................^ %CC-E-NOLINKAGE, In this declaration, "uint32_t" has no linkage and has a prior declaration in this scope at line number 174 in file LCL_ROOT:[cmake-3_3_2.Utilities.cmliblzma]config.h;7. at line number 75 in module INTTYPES of text library SYS$COMMON:[SYSLIB]DECC$RTLDEF.TLB;1 make[2]: *** [Utilities/cmliblzma/CMakeFiles/cmliblzma_dir/liblzma/check/check.c.o] Error 2 make[2]: Leaving directory `/PRJ_ROOT/CMAKE-3_3_2' make[1]: *** [Utilities/cmliblzma/CMakeFiles/cmliblzma_dir/all] Error 2 make[1]: Leaving directory `/PRJ_ROOT/CMAKE-3_3_2' make: *** [all] Error 2 to a somewhat confusing (at least to me) behavior of the config.h header file generated from the config.h.in file. Line Statement 6 /* First, we need to know if the system has already defined them. */ 7 #cmakedefine HAVE_INT16_T 8 #cmakedefine HAVE_INT32_T 9 #cmakedefine HAVE_INT64_T 10 #cmakedefine HAVE_INTMAX_T 11 12 #cmakedefine HAVE_UINT8_T 13 #cmakedefine HAVE_UINT16_T 14 #cmakedefine HAVE_UINT32_T 15 #cmakedefine HAVE_UINT64_T 16 #cmakedefine HAVE_UINTMAX_T Generates these statements in the config.h header file 6 /* First, we need to know if the system has already defined them. */ 7 /* #undef HAVE_INT16_T */ 8 /* #undef HAVE_INT32_T */ 9 /* #undef HAVE_INT64_T */ 10 /* #undef HAVE_INTMAX_T */ 11 12 /* #undef HAVE_UINT8_T */ 13 /* #undef HAVE_UINT16_T */ 14 /* #undef HAVE_UINT32_T */ 15 /* #undef HAVE_UINT64_T */ 16 /* #undef HAVE_UINTMAX_T */ Except the generated files Bootstrap_cmk/cmIML/int.h and Utilities/cmIML/int.h (which contain identical content) contain the following sections: #if defined(__VMS) # define cmIML_INT_NO_STDINT_H # define cmIML_INT_HAVE_INTTYPES_H #endif And #if defined(cmIML_INT_HAVE_STDINT_H) || defined(cmIML_INT_HAVE_INTTYPES_H) #define cmIML_INT_HAVE_INT8_T 1 #define cmIML_INT_HAVE_UINT8_T 1 #define cmIML_INT_HAVE_INT16_T 1 #define cmIML_INT_HAVE_UINT16_T 1 #define cmIML_INT_HAVE_INT32_T 1 #define cmIML_INT_HAVE_UINT32_T 1 #define cmIML_INT_HAVE_INT64_T 1 #define cmIML_INT_HAVE_UINT64_T 1 #define cmIML_INT_NO_INTPTR_T 1 #define cmIML_INT_NO_UINTPTR_T 1 #endif Near as I can tell no connection exists between the HAVE_xyz_T macros and the cmIML_INT_HAVE_xyz_T macros. Likewise I can't seem to find anywhere that would actually define the HAVE_xyz_T macros which seems equally confusing. Aside from having to manually edit the config.h.in can anyone suggest a way to work this? Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicholas11braden at gmail.com Sat Nov 14 01:10:54 2015 From: nicholas11braden at gmail.com (Nicholas Braden) Date: Sat, 14 Nov 2015 00:10:54 -0600 Subject: [CMake] How do I allow an ExternalProject to fail? Message-ID: I want to use ExternalProject_Add to download a git repository and try to compile it, and allow it to fail so I can either fall back on another method or disable certain functionality in my project. It looks like try_compile can try to compile a whole project, but I am not sure of an easy way to use this with ExternalProject_Add - I want CMake to automatically download and update the git repository and try to rebuild it again when there are changes, if possible. What would be the best way to go about doing this? I am using CMake 3.4.0 Thanks, Nicholas Braden From rleigh at codelibre.net Sat Nov 14 06:53:11 2015 From: rleigh at codelibre.net (Roger Leigh) Date: Sat, 14 Nov 2015 11:53:11 +0000 Subject: [CMake] Creating relocatable export files Message-ID: <564720A7.8000206@codelibre.net> Hi, I'm wanting to create -config scripts for my libraries so that dependent projects can find them with find_package and use them transparently. I have a number of header-only and shared/static libs, and I'd like to retain their relationships, plus any additional libraries they are linked with. I was previously using hand-crafted templates, e.g. with this type of generated structure: --------------------------------------------------------------------------- set(OME_COMMON_FOUND TRUE) set(OME_COMMON_VERSION "5.2.0-pre0-7-gfc53ca3") set(OME_COMMON_VERSION_MAJOR "5") set(OME_COMMON_VERSION_MINOR "2") set(OME_COMMON_VERSION_PATCH "0") set(OME_COMMON_VERSION_EXTRA "-pre0-7-gfc53ca3") find_path(OME_COMMON_INCLUDE_DIR ome/common/module.h HINTS "/tmp/split/include") find_library(OME_COMMON_LIBRARY NAMES ome-common libome-common HINTS "/tmp/split/lib") --------------------------------------------------------------------------- They unfortuately did not handle interface targets or public library dependencies required by use in the headers. I've switched to using install(EXPORT): https://github.com/rleigh-dundee/ome-common-cpp/blob/develop/lib/ome/common/CMakeLists.txt#L123 --------------------------------------------------------------------------- target_link_libraries(ome-common ome-compat ${Boost_LOG_SETUP_LIBRARY_RELEASE} ${Boost_LOG_LIBRARY_RELEASE} ${Boost_FILESYSTEM_LIBRARY_RELEASE} ${Boost_SYSTEM_LIBRARY_RELEASE} ${LibDl_LIBRARIES} ${XercesC_LIBRARIES}) set_target_properties(ome-common PROPERTIES LINKER_LANGUAGE CXX) set_target_properties(ome-common PROPERTIES VERSION ${OME_VERSION_SHORT}) install(TARGETS ome-common EXPORT ome-common-config RUNTIME DESTINATION ${CMAKE_INSTALL_FULL_BINDIR} LIBRARY DESTINATION ${CMAKE_INSTALL_FULL_LIBDIR} ARCHIVE DESTINATION ${CMAKE_INSTALL_FULL_LIBDIR}) install(EXPORT ome-common-config DESTINATION ${CMAKE_INSTALL_FULL_LIBDIR}/cmake/ome-common) --------------------------------------------------------------------------- This does a much better job of the dependencies. It's preserving the dependencies for the internal targets, plus the external libraries. However, it's lacking: - any setting of the include path via FOO_INCLUDE_DIR, unless it's just not done in an obvious manner - it's hardcoded the absolute paths of the various boost and xerces libs; I'd like it to be relocatable so it can work in a superbuild and continue to work after moving elsewhere - it doesn't appear to recursively find needed import targets, e.g. I need to find_package(ome-compat) before find_package(ome-common); it would be nice if this was transparent so the user doesn't need to do this I'd be interested to know if anyone else has run into these issues, and if so what your solutions were? I'm quite new to this part of cmake, so it may well just be I'm not doing things exactly as expected. Would it be easier to construct the template myself and then call find_package for the external libs to avoid hardcoding the paths? Is it safe to recursively call find_package inside find_package? Thanks all, Roger From houssen at ipgp.fr Sat Nov 14 10:05:10 2015 From: houssen at ipgp.fr (houssen) Date: Sat, 14 Nov 2015 16:05:10 +0100 Subject: [CMake] Executable using a library (.a or .so) In-Reply-To: References: <994cad0c31293c616cf21547cfe3c4b0@imap.ipgp.fr> Message-ID: <29a6c5a8c808cac9abfd0e33e4a43909@imap.ipgp.fr> is this library required to be separate from the executable? No in this specific case, but, the question still holds from a general comprenhension of CMake (I'd like to get !...) and the answer may be yes in futur cases. I tested your proposal (need to add target_include_directories to find headers) : # in MyLib/CmakeLists.txt add_library( MyLib libsource1.c libsource2.cpp ) # in MyExe/CmakeLists.txt add_exectubable( MyExe exesource1.c ) target_include_directories(myExe PUBLIC ../myLib/hdr) target_link_libraries( MyExe MyLib ) This is working, so OK I can use that. But what if the user wants to build myLib as a .a or a .so ? It seems it not possible to change that from ccmake (I've just checked). It should be possible when using Find*.cmake, no ? ... But, precisely, when typing target_include_directory you need to know the path to headers directory (+ path to libraries directory ?): this is why I felt like "Okay, I need to write a FindMyLib.cmake to handle this". My understanding is that a (internal or external) library is a library, so, it should be managed with a FindMyLib.cmake. Am I correct ? (I try to understand the "CMake way" to do thing - I am more an autotools user, so, I just try to understand CMake) Franck Le 2015-11-13 18:53, J Decker a ?crit?: > On Fri, Nov 13, 2015 at 9:51 AM, J Decker wrote: >> is this library required to be separate from the executable? >> If not; it's far easier... >> > # in MyLib/CmakeLists.txt >> add_library( MyLib libsource1.c >> libsource2.cpp ) > > # in MyExe/CmakeLists.txt >> add_exectubable( MyExe exesource1.c ) >> target_link_libraries( MyExe MyLib ) >> > > theose can be spread ito sepatate CMakeLists... with a root > CmakeLists.txt like... > > --- > cmake_minimum_version(something) > > add_subdirectory( mylib ) > add_subdirectory( myExe) > > > >> >> On Fri, Nov 13, 2015 at 9:28 AM, houssen wrote: >>> Hello, >>> >>> How to write a library (myLib as .a or .so) that can be used from >>> an >>> executable (myExe) ? >>> >>> I read the CMake doc but, obviously, I still miss some major points >>> !... My >>> understanding is that, I need : >>> - to write a FindMyLib.cmake for myExe to find myLib (= finding >>> include/library directories, and, libraries to link with) >>> - to use find_package from myExe to find myLib >>> >>> I tried to write a mini-project (attached to this mail) to do that >>> but it >>> doesn't work: find_package doesn't find FindMyLib.cmake although >>> CMAKE_MODULE_PATH has been updated. >>> >>> Can somebody help me on making this project to work ? (not able to >>> find >>> FindMyLib.cmake, not sure to know the "good" way to write >>> FindMyLib.cmake, >>> others... - I would appreciate any remarks to explain me the "good" >>> way to >>> do thing) >>> >>> Thanks, >>> >>> Franck >>> >>> Note: I set CMAKE_MODULE_PATH in the CMakeLists.txt of myLib (doing >>> that >>> from myExe sounds not relevant: if you know where the package is, >>> no need to >>> call find_package). >>> Note: my understanding is that when this will work, I would be >>> possible to >>> build myLib as a .a or a .so, am I correct ? >>> -- >>> >>> Powered by www.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: >>> http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For >>> more >>> information on each offering, please visit: >>> >>> CMake Support: http://cmake.org/cmake/help/support.html >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/cmake From rwan.work at gmail.com Sat Nov 14 10:37:01 2015 From: rwan.work at gmail.com (Raymond Wan) Date: Sat, 14 Nov 2015 23:37:01 +0800 Subject: [CMake] Executable using a library (.a or .so) In-Reply-To: <29a6c5a8c808cac9abfd0e33e4a43909@imap.ipgp.fr> References: <994cad0c31293c616cf21547cfe3c4b0@imap.ipgp.fr> <29a6c5a8c808cac9abfd0e33e4a43909@imap.ipgp.fr> Message-ID: Hi Franck, On Sat, Nov 14, 2015 at 11:05 PM, houssen wrote: > I tested your proposal (need to add target_include_directories to find > headers) : > # in MyLib/CmakeLists.txt > add_library( MyLib libsource1.c > libsource2.cpp ) > # in MyExe/CmakeLists.txt > add_exectubable( MyExe exesource1.c ) > target_include_directories(myExe PUBLIC ../myLib/hdr) > target_link_libraries( MyExe MyLib ) > > This is working, so OK I can use that. But what if the user wants to build > myLib as a .a or a .so ? It seems it not possible to change that from ccmake > (I've just checked). It should be possible when using Find*.cmake, no ? I'm not a CMake expert, but I think you will issue two add_library ()'s, one for the shared and one for static. I don't think I can say it any better than this: http://stackoverflow.com/questions/2152077/is-it-possible-to-get-cmake-to-build-both-a-static-and-shared-version-of-the-sam (even though it's 5 years old, I think it's still relevant). If we're talking about the source code associated with the CMakeLists.txt you're processing, then presumably you already know about libsource1.c, exesource1.c, etc. so you don't need to do Find them. However, if it's a set of files, libraries, etc. that has been installed independently of the source code in question (i.e., Boost or something you wrote that you've required the user to have done a "make install" beforehand), then you would issue a Find*.cmake (or write one if it's your own libraries). I'm not too sure about this, but I think that's the distinction between when to use Find*.cmake and when you don't need to. > ... But, precisely, when typing target_include_directory you need to know > the path to headers directory (+ path to libraries directory ?): this is why > I felt like "Okay, I need to write a FindMyLib.cmake to handle this". My > understanding is that a (internal or external) library is a library, so, it > should be managed with a FindMyLib.cmake. Am I correct ? (I try to > understand the "CMake way" to do thing - I am more an autotools user, so, I > just try to understand CMake) In my source code, I might have some module A rely on a module B. However, both are within the same source tree. So, I can do Include_Directories () to add paths to header files or Add_Subdirectory () to add a subdirectory to the build. As it's all within the same source tree, I can find them using relative path names. However, if it's a .h or .hpp header file that was compiled and installed separately, then I would need to use ExternalSource () to acquire and compile it *or* use Find*.cmake to go to system paths to look for it. Incidentally, I've been looking into this the past week and I don't know if I got it right. But to summarize, this is what I think: 1) Include_Directories and Add_Subdirectory if the header files / modules are within the same source tree. 2) ExternalSource if this software is not part of the source tree and needs to be acquired *during* the build/compilation process. 3) use Find*.cmake if this software was acquired and built *before* the current build/compilation process. If you use Boost, then you would use FindBoost.cmake if you want the user to have installed Boost separately beforehand. You would use ExternalSource if you want Boost to be downloaded and installed in the same CMake binary tree as you're currently on. Not too sure...hopefully someone can correct me! Ray From houssen at ipgp.fr Sat Nov 14 12:23:13 2015 From: houssen at ipgp.fr (houssen) Date: Sat, 14 Nov 2015 18:23:13 +0100 Subject: [CMake] Executable using a library (.a or .so) In-Reply-To: References: <994cad0c31293c616cf21547cfe3c4b0@imap.ipgp.fr> <29a6c5a8c808cac9abfd0e33e4a43909@imap.ipgp.fr> Message-ID: Ray, What you say sounds totally logical to me ! So I'll stick to option 1 as you described it. Thanks for explanations, this is helpfull. Franck Le 2015-11-14 16:37, Raymond Wan a ?crit?: > Hi Franck, > > > On Sat, Nov 14, 2015 at 11:05 PM, houssen wrote: >> I tested your proposal (need to add target_include_directories to >> find >> headers) : >> # in MyLib/CmakeLists.txt >> add_library( MyLib libsource1.c >> libsource2.cpp ) >> # in MyExe/CmakeLists.txt >> add_exectubable( MyExe exesource1.c ) >> target_include_directories(myExe PUBLIC ../myLib/hdr) >> target_link_libraries( MyExe MyLib ) >> >> This is working, so OK I can use that. But what if the user wants to >> build >> myLib as a .a or a .so ? It seems it not possible to change that >> from ccmake >> (I've just checked). It should be possible when using Find*.cmake, >> no ? > > > I'm not a CMake expert, but I think you will issue two add_library > ()'s, one for the shared and one for static. I don't think I can say > it any better than this: > > > http://stackoverflow.com/questions/2152077/is-it-possible-to-get-cmake-to-build-both-a-static-and-shared-version-of-the-sam > > (even though it's 5 years old, I think it's still relevant). > > If we're talking about the source code associated with the > CMakeLists.txt you're processing, then presumably you already know > about libsource1.c, exesource1.c, etc. so you don't need to do Find > them. However, if it's a set of files, libraries, etc. that has been > installed independently of the source code in question (i.e., Boost > or > something you wrote that you've required the user to have done a > "make > install" beforehand), then you would issue a Find*.cmake (or write > one > if it's your own libraries). > > I'm not too sure about this, but I think that's the distinction > between when to use Find*.cmake and when you don't need to. > > >> ... But, precisely, when typing target_include_directory you need to >> know >> the path to headers directory (+ path to libraries directory ?): >> this is why >> I felt like "Okay, I need to write a FindMyLib.cmake to handle >> this". My >> understanding is that a (internal or external) library is a >> library, so, it >> should be managed with a FindMyLib.cmake. Am I correct ? (I try to >> understand the "CMake way" to do thing - I am more an autotools >> user, so, I >> just try to understand CMake) > > > In my source code, I might have some module A rely on a module B. > However, both are within the same source tree. So, I can do > Include_Directories () to add paths to header files or > Add_Subdirectory () to add a subdirectory to the build. As it's all > within the same source tree, I can find them using relative path > names. > > However, if it's a .h or .hpp header file that was compiled and > installed separately, then I would need to use ExternalSource () to > acquire and compile it *or* use Find*.cmake to go to system paths to > look for it. > > Incidentally, I've been looking into this the past week and I don't > know if I got it right. But to summarize, this is what I think: > > 1) Include_Directories and Add_Subdirectory if the header files / > modules are within the same source tree. > 2) ExternalSource if this software is not part of the source tree > and > needs to be acquired *during* the build/compilation process. > 3) use Find*.cmake if this software was acquired and built *before* > the current build/compilation process. > > If you use Boost, then you would use FindBoost.cmake if you want the > user to have installed Boost separately beforehand. You would use > ExternalSource if you want Boost to be downloaded and installed in > the > same CMake binary tree as you're currently on. > > Not too sure...hopefully someone can correct me! > > Ray From nicholas11braden at gmail.com Sat Nov 14 13:19:11 2015 From: nicholas11braden at gmail.com (Nicholas Braden) Date: Sat, 14 Nov 2015 12:19:11 -0600 Subject: [CMake] Creating relocatable export files In-Reply-To: <564720A7.8000206@codelibre.net> References: <564720A7.8000206@codelibre.net> Message-ID: Instead of using FOO_INCLUDE_DIR, I believe you should use target_include_directories() with the INTERFACE or PUBLIC options - this will export the include directories properly and they will be used when someone target_link_library()s your exported target. https://cmake.org/cmake/help/latest/command/target_include_directories.html?highlight=INTERFACE There seems to be a section in the documentation on making sure your packages are relocatable: https://cmake.org/cmake/help/latest/manual/cmake-packages.7.html#creating-relocatable-packages See also: https://cmake.org/cmake/help/latest/module/CMakePackageConfigHelpers.html As for recursively finding packages, I honestly don't know on this front. I would imagine that everything might work if everything was using exported/imported targets, but I'm not sure. The problem is that you have to consider what happens if you relocate your relocatable package to a system that doesn't have the dependencies installed. I don't think exported/imported targets or relocatable packages can solve that problem easily, but I am not very knowledgeable in this area myself. On Sat, Nov 14, 2015 at 5:53 AM, Roger Leigh wrote: > Hi, > > I'm wanting to create -config scripts for my libraries so that dependent > projects can find them with find_package and use them transparently. I have > a number of header-only and shared/static libs, and I'd like to retain their > relationships, plus any additional libraries they are linked with. > > I was previously using hand-crafted templates, e.g. with this type of > generated structure: > > --------------------------------------------------------------------------- > set(OME_COMMON_FOUND TRUE) > > set(OME_COMMON_VERSION "5.2.0-pre0-7-gfc53ca3") > set(OME_COMMON_VERSION_MAJOR "5") > set(OME_COMMON_VERSION_MINOR "2") > set(OME_COMMON_VERSION_PATCH "0") > set(OME_COMMON_VERSION_EXTRA "-pre0-7-gfc53ca3") > > find_path(OME_COMMON_INCLUDE_DIR ome/common/module.h HINTS > "/tmp/split/include") > find_library(OME_COMMON_LIBRARY NAMES ome-common libome-common HINTS > "/tmp/split/lib") > --------------------------------------------------------------------------- > > They unfortuately did not handle interface targets or public library > dependencies required by use in the headers. I've switched to using > install(EXPORT): > > https://github.com/rleigh-dundee/ome-common-cpp/blob/develop/lib/ome/common/CMakeLists.txt#L123 > --------------------------------------------------------------------------- > target_link_libraries(ome-common ome-compat > ${Boost_LOG_SETUP_LIBRARY_RELEASE} > ${Boost_LOG_LIBRARY_RELEASE} > ${Boost_FILESYSTEM_LIBRARY_RELEASE} > ${Boost_SYSTEM_LIBRARY_RELEASE} > ${LibDl_LIBRARIES} > ${XercesC_LIBRARIES}) > > set_target_properties(ome-common PROPERTIES LINKER_LANGUAGE CXX) > set_target_properties(ome-common PROPERTIES VERSION ${OME_VERSION_SHORT}) > > install(TARGETS ome-common > EXPORT ome-common-config > RUNTIME DESTINATION ${CMAKE_INSTALL_FULL_BINDIR} > LIBRARY DESTINATION ${CMAKE_INSTALL_FULL_LIBDIR} > ARCHIVE DESTINATION ${CMAKE_INSTALL_FULL_LIBDIR}) > install(EXPORT ome-common-config > DESTINATION ${CMAKE_INSTALL_FULL_LIBDIR}/cmake/ome-common) > --------------------------------------------------------------------------- > > This does a much better job of the dependencies. It's preserving the > dependencies for the internal targets, plus the external libraries. However, > it's lacking: > > - any setting of the include path via FOO_INCLUDE_DIR, unless it's just not > done in an obvious manner > - it's hardcoded the absolute paths of the various boost and xerces libs; > I'd like it to be relocatable so it can work in a superbuild and continue to > work after moving elsewhere > - it doesn't appear to recursively find needed import targets, e.g. I need > to find_package(ome-compat) before find_package(ome-common); it would be > nice if this was transparent so the user doesn't need to do this > > I'd be interested to know if anyone else has run into these issues, and if > so what your solutions were? I'm quite new to this part of cmake, so it may > well just be I'm not doing things exactly as expected. > > Would it be easier to construct the template myself and then call > find_package for the external libs to avoid hardcoding the paths? Is it > safe to recursively call find_package inside find_package? > > > Thanks all, > Roger > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From cedric.doucet at inria.fr Sat Nov 14 14:23:51 2015 From: cedric.doucet at inria.fr (Cedric Doucet) Date: Sat, 14 Nov 2015 20:23:51 +0100 (CET) Subject: [CMake] How to build cmake to have http support? In-Reply-To: <484799078.19902642.1447528830661.JavaMail.zimbra@inria.fr> Message-ID: <350855440.19902743.1447529031156.JavaMail.zimbra@inria.fr> Hello, I would like to build cmake on a cluster where I don't have any administrator privilege. Since I use the ExternalProject_Add command in my configuration script, I need to have https support with curl. But when one build cmake without specific option, it does not support https. I managed to compile cmake such that it support https by the past, but I can't remember how I did it. I remember I installed openssl and pass some flags to cmake. Could anyone remember me how to do it? Or, is it possible to recover passed flags from a local installation of cmake? Thank you! C?dric -------------- next part -------------- An HTML attachment was scrubbed... URL: From tamas.kenez at gmail.com Sat Nov 14 16:20:38 2015 From: tamas.kenez at gmail.com (=?UTF-8?B?VGFtw6FzIEtlbsOpeg==?=) Date: Sat, 14 Nov 2015 22:20:38 +0100 Subject: [CMake] Creating relocatable export files In-Reply-To: References: <564720A7.8000206@codelibre.net> Message-ID: You need to manually write your config module which takes care of the dependencies. Of course you will still use the generated exports, too. For now let's say `ome-common` has one dependency: `omedep` and its config-module, `omedep-config.cmake` creates the imported lib target `omedep::omedep`. The in `ome-common`'s CMakeLists.txt: target_link_libraries(ome-common PUBLIC omedep::omedep) install(TARGETS ome-common EXPORT ome-common-targets ....) install(EXPORT ome-common-targets DESTINATION cmake/ome-common) install(FILES ome-common-config.cmake DESTINATION cmake/ome-common) The `ome-common-config.cmake` should look like this: include(CMakeFindDependencyMacro) find_dependency(omedep) include(${CMAKE_CURRENT_LIST_DIR}/ome-common-targets.cmake) Note: for CMake versions < 3.0 you need to use `find_package` instead of `find_dependency`. Okay, so that's the solution if `ome-common`'s dependency creates an imported lib target. If `omedep` has an oldschool config-module which provides only variables like OMEDEP_LIBRARIES containing absolute paths, then these paths will be hardcoded in `ome-common-targets.cmake`. In this case the recommended method is to convert these paths to relative paths in a postprocess step after installation. See this: https://gist.github.com/tamaskenez/7ca4cba352525985ea70 as an example for such a script. Of course this can only be used if `omedep` is a dependency which is installed into the same install tree as `ome-common`. If you have a dependency in a separate install-tree which does not create imported lib targets then you need to do it yourself both in `ome-common`'s CMakeLists.txt and config-modules. This is not a trivial operation but always can be done with more or less additional logic. For a simple case where `omedep` consists of a single library file: `ome-common`'s CMakeLists.txt: find_package(omedep REQUIRED) add_library(ome-common::omedep STATIC IMPORTED) # STATIC or SHARED or UNKNOWN set_target_properties(ome-common::omedep PROPERTIES INTERFACE_INCLUDE_DIRECTORIES ${OMEDEP_INCLUDE_DIRS} IMPORTED_LINK_INTERFACE_LANGUAGES "C" IMPORTED_LOCATION ${OMEDEP_LIBRARIES} # a single library ) target_link_libraries(ome-common PUBLIC ome-common::omedep) ... which should be repeated in `ome-common-config.cmake`: include(CMakeFindDependencyMacro) find_dependency(omedep) set_target_properties(ome-common::omedep PROPERTIES INTERFACE_INCLUDE_DIRECTORIES ${OMEDEP_INCLUDE_DIRS} IMPORTED_LINK_INTERFACE_LANGUAGES "C" IMPORTED_LOCATION ${OMEDEP_LIBRARIES} # a single library ) include(${CMAKE_CURRENT_LIST_DIR}/ome-targets.cmake) Things get more complicated when OMEDEP_LIBRARIES has per-config variants or further dependencies. You can check the generated `ome-common-targets.cmake` and `ome-common-targets-Debug/Relase.cmake` files for an example on how to set up such an imported lib target. On Sat, Nov 14, 2015 at 7:19 PM, Nicholas Braden wrote: > Instead of using FOO_INCLUDE_DIR, I believe you should use > target_include_directories() with the INTERFACE or PUBLIC options - > this will export the include directories properly and they will be > used when someone target_link_library()s your exported target. > > https://cmake.org/cmake/help/latest/command/target_include_directories.html?highlight=INTERFACE > > There seems to be a section in the documentation on making sure your > packages are relocatable: > > https://cmake.org/cmake/help/latest/manual/cmake-packages.7.html#creating-relocatable-packages > > See also: > https://cmake.org/cmake/help/latest/module/CMakePackageConfigHelpers.html > > As for recursively finding packages, I honestly don't know on this > front. I would imagine that everything might work if everything was > using exported/imported targets, but I'm not sure. The problem is that > you have to consider what happens if you relocate your relocatable > package to a system that doesn't have the dependencies installed. I > don't think exported/imported targets or relocatable packages can > solve that problem easily, but I am not very knowledgeable in this > area myself. > > On Sat, Nov 14, 2015 at 5:53 AM, Roger Leigh wrote: > > Hi, > > > > I'm wanting to create -config scripts for my libraries so that dependent > > projects can find them with find_package and use them transparently. I > have > > a number of header-only and shared/static libs, and I'd like to retain > their > > relationships, plus any additional libraries they are linked with. > > > > I was previously using hand-crafted templates, e.g. with this type of > > generated structure: > > > > > --------------------------------------------------------------------------- > > set(OME_COMMON_FOUND TRUE) > > > > set(OME_COMMON_VERSION "5.2.0-pre0-7-gfc53ca3") > > set(OME_COMMON_VERSION_MAJOR "5") > > set(OME_COMMON_VERSION_MINOR "2") > > set(OME_COMMON_VERSION_PATCH "0") > > set(OME_COMMON_VERSION_EXTRA "-pre0-7-gfc53ca3") > > > > find_path(OME_COMMON_INCLUDE_DIR ome/common/module.h HINTS > > "/tmp/split/include") > > find_library(OME_COMMON_LIBRARY NAMES ome-common libome-common HINTS > > "/tmp/split/lib") > > > --------------------------------------------------------------------------- > > > > They unfortuately did not handle interface targets or public library > > dependencies required by use in the headers. I've switched to using > > install(EXPORT): > > > > > https://github.com/rleigh-dundee/ome-common-cpp/blob/develop/lib/ome/common/CMakeLists.txt#L123 > > > --------------------------------------------------------------------------- > > target_link_libraries(ome-common ome-compat > > ${Boost_LOG_SETUP_LIBRARY_RELEASE} > > ${Boost_LOG_LIBRARY_RELEASE} > > ${Boost_FILESYSTEM_LIBRARY_RELEASE} > > ${Boost_SYSTEM_LIBRARY_RELEASE} > > ${LibDl_LIBRARIES} > > ${XercesC_LIBRARIES}) > > > > set_target_properties(ome-common PROPERTIES LINKER_LANGUAGE CXX) > > set_target_properties(ome-common PROPERTIES VERSION ${OME_VERSION_SHORT}) > > > > install(TARGETS ome-common > > EXPORT ome-common-config > > RUNTIME DESTINATION ${CMAKE_INSTALL_FULL_BINDIR} > > LIBRARY DESTINATION ${CMAKE_INSTALL_FULL_LIBDIR} > > ARCHIVE DESTINATION ${CMAKE_INSTALL_FULL_LIBDIR}) > > install(EXPORT ome-common-config > > DESTINATION ${CMAKE_INSTALL_FULL_LIBDIR}/cmake/ome-common) > > > --------------------------------------------------------------------------- > > > > This does a much better job of the dependencies. It's preserving the > > dependencies for the internal targets, plus the external libraries. > However, > > it's lacking: > > > > - any setting of the include path via FOO_INCLUDE_DIR, unless it's just > not > > done in an obvious manner > > - it's hardcoded the absolute paths of the various boost and xerces libs; > > I'd like it to be relocatable so it can work in a superbuild and > continue to > > work after moving elsewhere > > - it doesn't appear to recursively find needed import targets, e.g. I > need > > to find_package(ome-compat) before find_package(ome-common); it would be > > nice if this was transparent so the user doesn't need to do this > > > > I'd be interested to know if anyone else has run into these issues, and > if > > so what your solutions were? I'm quite new to this part of cmake, so it > may > > well just be I'm not doing things exactly as expected. > > > > Would it be easier to construct the template myself and then call > > find_package for the external libs to avoid hardcoding the paths? Is it > > safe to recursively call find_package inside find_package? > > > > > > Thanks all, > > Roger > > -- > > > > Powered by www.kitware.com > > > > Please keep messages on-topic and check the CMake FAQ at: > > http://www.cmake.org/Wiki/CMake_FAQ > > > > Kitware offers various services to support the CMake community. For more > > information on each offering, please visit: > > > > CMake Support: http://cmake.org/cmake/help/support.html > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/cmake > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 audiofanatic at gmail.com Sat Nov 14 18:11:44 2015 From: audiofanatic at gmail.com (Craig Scott) Date: Sun, 15 Nov 2015 10:11:44 +1100 Subject: [CMake] How to build cmake to have http support? Message-ID: I recently went through this exact same problem. In my case, when building CMake from source, I had to enable the configure option to use the system-provided curl instead of the one provided with CMake itself (I was on Linux using Centos 6). With that configure option, https support worked fine. ---------- Forwarded message ---------- > From: Cedric Doucet > To: cmake at cmake.org > Cc: > Date: Sat, 14 Nov 2015 20:23:51 +0100 (CET) > Subject: [CMake] How to build cmake to have http support? > > Hello, > > I would like to build cmake on a cluster where I don't have any > administrator privilege. > Since I use the ExternalProject_Add command in my configuration script, I > need to have https support with curl. > But when one build cmake without specific option, it does not support > https. > > I managed to compile cmake such that it support https by the past, but I > can't remember how I did it. > I remember I installed openssl and pass some flags to cmake. > > Could anyone remember me how to do it? > Or, is it possible to recover passed flags from a local installation of > cmake? > > Thank you! > > C?dric > > > -- Craig Scott Melbourne, Australia http://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From cedric.doucet at inria.fr Sat Nov 14 18:15:27 2015 From: cedric.doucet at inria.fr (Cedric Doucet) Date: Sun, 15 Nov 2015 00:15:27 +0100 (CET) Subject: [CMake] How to build cmake to have http support? In-Reply-To: References: Message-ID: <1244556439.19916072.1447542927070.JavaMail.zimbra@inria.fr> Hello Craig, yes, I know it's possible to do that. However, I need to build cmake on a cluster where nothing seems to be installed (except make and some basic tools). Nevertheless, I will try this solution to be sure. Thank you for your answer! ----- Mail original ----- > De: "Craig Scott" > ?: "Cedric Doucet" > Cc: cmake at cmake.org > Envoy?: Dimanche 15 Novembre 2015 00:11:44 > Objet: [CMake] How to build cmake to have http support? > I recently went through this exact same problem. In my case, when building > CMake from source, I had to enable the configure option to use the > system-provided curl instead of the one provided with CMake itself (I was on > Linux using Centos 6). With that configure option, https support worked > fine. > > ---------- Forwarded message ---------- > > > From: Cedric Doucet < cedric.doucet at inria.fr > > > > To: cmake at cmake.org > > > Cc: > > > Date: Sat, 14 Nov 2015 20:23:51 +0100 (CET) > > > Subject: [CMake] How to build cmake to have http support? > > > Hello, > > > I would like to build cmake on a cluster where I don't have any > > administrator > > privilege. > > > Since I use the ExternalProject_Add command in my configuration script, I > > need to have https support with curl. > > > But when one build cmake without specific option, it does not support > > https. > > > I managed to compile cmake such that it support https by the past, but I > > can't remember how I did it. > > > I remember I installed openssl and pass some flags to cmake. > > > Could anyone remember me how to do it? > > > Or, is it possible to recover passed flags from a local installation of > > cmake? > > > Thank you! > > > C?dric > > -- > Craig Scott > Melbourne, Australia > http://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From attila.krasznahorkay at gmail.com Sat Nov 14 22:04:42 2015 From: attila.krasznahorkay at gmail.com (Attila Krasznahorkay) Date: Sat, 14 Nov 2015 19:04:42 -0800 Subject: [CMake] Custom message if target fails In-Reply-To: References: <564453B1.5050306@simtech.uni-stuttgart.de> <56445786.5030103@gmail.com> <5644646B.80204@simtech.uni-stuttgart.de> Message-ID: <801CAA8E-A5DB-4CC1-876B-8BD62AC7CB6B@gmail.com> Hi Daniel, You could even do it in a *much* more general way. We write custom log files about our builds by providing a "replacement" for the ctest executable. So that when we configure the build with -DCTEST_USE_LAUNCHERS , our script would catch *all* the build commands. (To have a chance to put the commands and their results into various log files. We forward the actual build command execution to the "normal" ctest executable.) You could use such a script to print a custom failure message. Cheers, Attila > On 12 Nov 2015, at 09:43, Daniel Schepler wrote: > > I'm assuming this is under a Unix platform - in my experience, on Windows, I get the color escape codes even running cmake builds under Jenkins. On Unix platforms, you could install expect and use the unbuffer tool, e.g. "unbuffer make -j8 -k". > -- > Daniel Schepler > ________________________________________ > From: CMake [cmake-bounces at cmake.org] on behalf of Daniel Wirtz [daniel.wirtz at simtech.uni-stuttgart.de] > Sent: Thursday, November 12, 2015 2:05 AM > To: cmake at cmake.org > Subject: Re: [CMake] Custom message if target fails > > Hey, > > neat idea, i've tried and it works (i have custom targets there). > However, the "nice" colored build text output of such a solution gets > lost completely (pipes etc); are there any alternative ideas/solutions? > > thanks again! > > Dr. Daniel Wirtz > Dipl. Math. Dipl. Inf. > SRC SimTech > Pfaffenwaldring 5a > +49 711 685 60044 > > On 11/12/2015 10:10 AM, Nils Gladitz wrote: >> On 11/12/2015 09:54 AM, Daniel Wirtz wrote: >>> Dear all, >>> >>> i've been thinking on this for a while but i can't seem to get my >>> head around how to solve this. >>> The task is simple: How can i display a custom error message if a >>> target fails to build for whatever reason? >>> - cmake .. >>> - make >>> - >>> - below the (compile-tool dependent error output) i'd like to print >>> something like "Whoops it went wrong, type this and that or visit >>> this or that website for help" >>> >> >> There is no generic build system feature for this. >> >> You haven't provided any details on what kind of target this concerns >> or what is to be diagnosed specifically but ... >> >> Assuming this is a custom target / custom command you could replace >> the actual command with a wrapper (e.g. cmake -P script) that: >> - runs the actual command (e.g. execute_process()) >> - outputs a message based on the actual command's exit status >> (e.g. message("This and that")) >> - exits with (roughly) the same exit status as the actual command >> (e.g. message(FATAL_ERROR) on failure)) >> >> For regular build targets (executables, libraries) there is nothing to >> be done at build time. >> Depending on what it is you are actually diagnosing you might want to >> try to diagnose it during configuration rather than during the build. >> >> Nils > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 magnus at therning.org Sun Nov 15 06:00:25 2015 From: magnus at therning.org (Magnus Therning) Date: Sun, 15 Nov 2015 12:00:25 +0100 Subject: [CMake] Running a C source file through the pre-processor Message-ID: <20151115110025.GA2958@tatooine> I have a tool that, given a C source file, spits out some linker flags that's necessary to link the file into the final target. Now the C source file has grown rather large and I'd like to split some of it into a header file (those things are also useful in other files to reducing duplication of code is another reason to do this). This however means that it's not enough to pass the C source file through the tool, I need to pass the pre-processed source to the tool! The question is then if I can do this easily in some way? I was thinking of doing it manually so to speak, but then I quickly ran into the problem of finding the effective CFLAGS used for a source/target. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus at therning.org jabber: magnus at therning.org twitter: magthe http://therning.org/magnus Finagle's Sixth Law: Don't believe in miracles -- rely on them. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From gjasny at gmail.com Sun Nov 15 09:25:37 2015 From: gjasny at gmail.com (Gregor Jasny) Date: Sun, 15 Nov 2015 15:25:37 +0100 Subject: [CMake] How to build cmake to have http support? In-Reply-To: <350855440.19902743.1447529031156.JavaMail.zimbra@inria.fr> References: <350855440.19902743.1447529031156.JavaMail.zimbra@inria.fr> Message-ID: <564895E1.9010601@googlemail.com> Hello, On 14/11/15 20:23, Cedric Doucet wrote: > I managed to compile cmake such that it support https by the past, but I can't remember how I did it. > I remember I installed openssl and pass some flags to cmake. > > Could anyone remember me how to do it? HTTPS support worked for me after passing --system-curl to configure. Thanks, Gregor From cedric.doucet at inria.fr Sun Nov 15 10:52:48 2015 From: cedric.doucet at inria.fr (Cedric Doucet) Date: Sun, 15 Nov 2015 16:52:48 +0100 (CET) Subject: [CMake] How to build cmake to have http support? In-Reply-To: <564895E1.9010601@googlemail.com> References: <350855440.19902743.1447529031156.JavaMail.zimbra@inria.fr> <564895E1.9010601@googlemail.com> Message-ID: <2013283520.19966253.1447602768345.JavaMail.zimbra@inria.fr> Thank you Gregor! As I feared, this solution does not work in my particular case. This is because something is missing in the system and I can't installed it since I'm not an administrator of the cluster: -- Could NOT find ZLIB (missing: ZLIB_LIBRARY ZLIB_INCLUDE_DIR) CMake Error at CMakeLists.txt:279 (message): CMAKE_USE_SYSTEM_ZLIB is ON but a zlib is not found! Call Stack (most recent call first): CMakeLists.txt:546 (CMAKE_BUILD_UTILITIES) -- Configuring incomplete, errors occurred! See also "/home/doucetc/logiciels/cmake-3.4.0/CMakeFiles/CMakeOutput.log". See also "/home/doucetc/logiciels/cmake-3.4.0/CMakeFiles/CMakeError.log". --------------------------------------------- Error when bootstrapping CMake: Problem while running initial CMake --------------------------------------------- I know it's possible to overcome this problem by installing openssl and telling cmake to use it, because it worked for me before. I will try again to find how I did that. Best, C?dric ----- Mail original ----- > De: "Gregor Jasny" > ?: cmake at cmake.org, "cedric doucet" > Envoy?: Dimanche 15 Novembre 2015 15:25:37 > Objet: Re: [CMake] How to build cmake to have http support? > > Hello, > > On 14/11/15 20:23, Cedric Doucet wrote: > > I managed to compile cmake such that it support https by the past, but I > > can't remember how I did it. > > I remember I installed openssl and pass some flags to cmake. > > > > Could anyone remember me how to do it? > > HTTPS support worked for me after passing --system-curl to configure. > > Thanks, > Gregor > From digitalriptide at gmail.com Sun Nov 15 15:13:46 2015 From: digitalriptide at gmail.com (digitalriptide) Date: Sun, 15 Nov 2015 12:13:46 -0800 Subject: [CMake] target_include_directories SYSTEM adds -isystem to Clang, but not GCC In-Reply-To: <55D5EE6B.80405@googlemail.com> References: <55D5EE6B.80405@googlemail.com> Message-ID: Did this fix make it into 3.4? After upgrading to 3.4, GCC still seems to lack -isystem flags on OS X. Is there anything extra I need to do? Thank you!! On Thu, Aug 20, 2015 at 8:12 AM, Gregor Jasny wrote: > Hello, > > On 17/08/15 01:01, digitalriptide wrote: > >> When I add SYSTEM to target_include_directories, for example using >> target_include_directories( my_target SYSTEM PUBLIC ${MY_LIBRARIES} ) >> in Clang, CMake prepends -isystem to the relavent -I/my/library/path >> type flags. With GCC, however, I see no -isystem added. >> >> For reference, this is CMake 3.2.3 on OS X with Apple LLVM version 6.0 >> and GCC 5 provided via MacPorts. >> >> Should SYSTEM add -isystem with GCC? >> > > this is a know bug: http://www.cmake.org/Bug/view.php?id=15687 > > I plan to work on it during the next days so that it may be fixed with > CMake 3.4. > > Thanks, > Gregor > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicholas11braden at gmail.com Sun Nov 15 15:21:35 2015 From: nicholas11braden at gmail.com (Nicholas Braden) Date: Sun, 15 Nov 2015 14:21:35 -0600 Subject: [CMake] How to build cmake to have http support? In-Reply-To: <2013283520.19966253.1447602768345.JavaMail.zimbra@inria.fr> References: <350855440.19902743.1447529031156.JavaMail.zimbra@inria.fr> <564895E1.9010601@googlemail.com> <2013283520.19966253.1447602768345.JavaMail.zimbra@inria.fr> Message-ID: Have you tried installing the required parts locally (e.g. in your home directory) and just telling CMake to look there instead of the default system locations? On Sun, Nov 15, 2015 at 9:52 AM, Cedric Doucet wrote: > > Thank you Gregor! > > As I feared, this solution does not work in my particular case. > This is because something is missing in the system and I can't installed it since I'm not an administrator of the cluster: > > -- Could NOT find ZLIB (missing: ZLIB_LIBRARY ZLIB_INCLUDE_DIR) > CMake Error at CMakeLists.txt:279 (message): > CMAKE_USE_SYSTEM_ZLIB is ON but a zlib is not found! > Call Stack (most recent call first): > CMakeLists.txt:546 (CMAKE_BUILD_UTILITIES) > > > -- Configuring incomplete, errors occurred! > See also "/home/doucetc/logiciels/cmake-3.4.0/CMakeFiles/CMakeOutput.log". > See also "/home/doucetc/logiciels/cmake-3.4.0/CMakeFiles/CMakeError.log". > --------------------------------------------- > Error when bootstrapping CMake: > Problem while running initial CMake > --------------------------------------------- > > I know it's possible to overcome this problem by installing openssl and telling cmake to use it, because it worked for me before. > I will try again to find how I did that. > > Best, > > C?dric > > > > ----- Mail original ----- >> De: "Gregor Jasny" >> ?: cmake at cmake.org, "cedric doucet" >> Envoy?: Dimanche 15 Novembre 2015 15:25:37 >> Objet: Re: [CMake] How to build cmake to have http support? >> >> Hello, >> >> On 14/11/15 20:23, Cedric Doucet wrote: >> > I managed to compile cmake such that it support https by the past, but I >> > can't remember how I did it. >> > I remember I installed openssl and pass some flags to cmake. >> > >> > Could anyone remember me how to do it? >> >> HTTPS support worked for me after passing --system-curl to configure. >> >> Thanks, >> Gregor >> > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 cedric.doucet at inria.fr Sun Nov 15 15:23:20 2015 From: cedric.doucet at inria.fr (Cedric Doucet) Date: Sun, 15 Nov 2015 21:23:20 +0100 (CET) Subject: [CMake] How to build cmake to have http support? In-Reply-To: References: <350855440.19902743.1447529031156.JavaMail.zimbra@inria.fr> <564895E1.9010601@googlemail.com> <2013283520.19966253.1447602768345.JavaMail.zimbra@inria.fr> Message-ID: <832197302.19996581.1447619000000.JavaMail.zimbra@inria.fr> Yes, I finally managed to do it! :) This is exactly what I did! Thank you! ----- Mail original ----- > De: "Nicholas Braden" > ?: "Cedric Doucet" > Cc: cmake at cmake.org > Envoy?: Dimanche 15 Novembre 2015 21:21:35 > Objet: Re: [CMake] How to build cmake to have http support? > > Have you tried installing the required parts locally (e.g. in your > home directory) and just telling CMake to look there instead of the > default system locations? > > On Sun, Nov 15, 2015 at 9:52 AM, Cedric Doucet > wrote: > > > > Thank you Gregor! > > > > As I feared, this solution does not work in my particular case. > > This is because something is missing in the system and I can't installed it > > since I'm not an administrator of the cluster: > > > > -- Could NOT find ZLIB (missing: ZLIB_LIBRARY ZLIB_INCLUDE_DIR) > > CMake Error at CMakeLists.txt:279 (message): > > CMAKE_USE_SYSTEM_ZLIB is ON but a zlib is not found! > > Call Stack (most recent call first): > > CMakeLists.txt:546 (CMAKE_BUILD_UTILITIES) > > > > > > -- Configuring incomplete, errors occurred! > > See also "/home/doucetc/logiciels/cmake-3.4.0/CMakeFiles/CMakeOutput.log". > > See also "/home/doucetc/logiciels/cmake-3.4.0/CMakeFiles/CMakeError.log". > > --------------------------------------------- > > Error when bootstrapping CMake: > > Problem while running initial CMake > > --------------------------------------------- > > > > I know it's possible to overcome this problem by installing openssl and > > telling cmake to use it, because it worked for me before. > > I will try again to find how I did that. > > > > Best, > > > > C?dric > > > > > > > > ----- Mail original ----- > >> De: "Gregor Jasny" > >> ?: cmake at cmake.org, "cedric doucet" > >> Envoy?: Dimanche 15 Novembre 2015 15:25:37 > >> Objet: Re: [CMake] How to build cmake to have http support? > >> > >> Hello, > >> > >> On 14/11/15 20:23, Cedric Doucet wrote: > >> > I managed to compile cmake such that it support https by the past, but I > >> > can't remember how I did it. > >> > I remember I installed openssl and pass some flags to cmake. > >> > > >> > Could anyone remember me how to do it? > >> > >> HTTPS support worked for me after passing --system-curl to configure. > >> > >> Thanks, > >> Gregor > >> > > -- > > > > Powered by www.kitware.com > > > > Please keep messages on-topic and check the CMake FAQ at: > > http://www.cmake.org/Wiki/CMake_FAQ > > > > Kitware offers various services to support the CMake community. For more > > information on each offering, please visit: > > > > CMake Support: http://cmake.org/cmake/help/support.html > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > > Visit other Kitware 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 a.neundorf-work at gmx.net Sun Nov 15 16:23:28 2015 From: a.neundorf-work at gmx.net (Alexander Neundorf) Date: Sun, 15 Nov 2015 22:23:28 +0100 Subject: [CMake] Benchmarking with CMake In-Reply-To: <20151113134141.3CACBC3E84@public.kitware.com> References: <20151109222727.35C2FC3F42@public.kitware.com> <20151113134141.3CACBC3E84@public.kitware.com> Message-ID: <1754074.AamfJ6elm5@tuxedo.neundorf.net> On Friday, November 13, 2015 14:41:35 Nagy-Egri M?t? Ferenc via CMake wrote: > Thank you all for your resonses, > > My use case is that I have a set of executables that function as unit tests. > Currently I use the return value of the .exe as a means of indicating > success, though I know there is way to match std::cout against a regex for > more complex tests. However, the timings of the tests are not always > suitable for benchmarking, because I only want the timings of a particular > part of the tests. Their initialization times are comparable to their > runtimes. While I could tune a parameter so that the init phase is > negligable, but then benchmarking would take for ages. I want to write > benchmark executables (similar to unit tests) that write a single number to > the console and nothing else. Run some command (make bench?, cbench?) which > runs, these tests, fetches the sole number from the std::cout and prints > those numbers as output instead of the total run time presented by ctest. > > @Peter: I also encountered Google Benchmark. I have already seen it?s output > and is perfectly fine. I am however a bit reluctant to grab another > dependency that all my consumers would be advised to install. CMake is a > fairly full blown suite and I was hoping to find something that could > provide similar results. > > @Matt: Seems nice. Python is not much a dependency, but VTK is less evident > to be present on all machines. > > @Alexander: I still have to look into this, because information seems a > little scarce on doing it. It seems to me, that CDash has to be installed > somewhere to be able visualize the data. Yes. > Is there a way to generate the > HTML-r for local consumption instead of submitting somewhere? (Ideally > bypassing a local installation of CDash) I don't think so. Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From imbacen at gmail.com Sun Nov 15 18:34:01 2015 From: imbacen at gmail.com (=?UTF-8?B?S2xlbWVuIEZlcmphbsSNacSN?=) Date: Mon, 16 Nov 2015 00:34:01 +0100 Subject: [CMake] CMake fails to find sys/event.h on FreeBSD 10.2 Message-ID: <56491669.8060005@gmail.com> FreeBSD 10.2-STABLE CMake 3.3.1 Our projects needs kqueue which means that sys/types.h and sys/event.h need to be found. Googling around also revealed that event.h is not self inclusive but depends on type.h. Not sure if that has to do with anything though. CMakeLists.txt: check_include_file_cxx(sys/types.h HAVE_SYS_TYPES_H) if (HAVE_SYS_TYPES_H) check_include_file_cxx(sys/event.h HAVE_SYS_EVENT_H) endif() Result: cmake -G "Unix Makefiles" -H./ -B./build -- Looking for C++ include sys/types.h -- Looking for C++ include sys/types.h - found -- Looking for C++ include sys/event.h -- Looking for C++ include sys/event.h - not found Both files exist in /usr/include/sys. Tried with check_include_file too but same problem. Can anyone tell me if I am doing something wrong and any idea why event.h is not found? From eike at sf-mail.de Mon Nov 16 01:35:56 2015 From: eike at sf-mail.de (Rolf Eike Beer) Date: Mon, 16 Nov 2015 07:35:56 +0100 Subject: [CMake] CMake fails to find sys/event.h on FreeBSD 10.2 In-Reply-To: <56491669.8060005@gmail.com> References: <56491669.8060005@gmail.com> Message-ID: <8644972.EHJBYKRVxt@caliban.sf-tec.de> Am Montag, 16. November 2015, 00:34:01 schrieb Klemen Ferjan?i?: > FreeBSD 10.2-STABLE > CMake 3.3.1 > > Our projects needs kqueue which means that sys/types.h and sys/event.h > need to be found. Googling around also revealed that event.h is not self > inclusive but depends on type.h. Not sure if that has to do with > anything though. > > CMakeLists.txt: > check_include_file_cxx(sys/types.h HAVE_SYS_TYPES_H) > if (HAVE_SYS_TYPES_H) > check_include_file_cxx(sys/event.h HAVE_SYS_EVENT_H) > endif() cmake --help-module CheckIncludeFileCXX -> CMAKE_REQUIRED_INCLUDES Eike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From imbacen at gmail.com Mon Nov 16 04:47:49 2015 From: imbacen at gmail.com (=?UTF-8?B?S2xlbWVuIEZlcmphbsSNacSN?=) Date: Mon, 16 Nov 2015 10:47:49 +0100 Subject: [CMake] CMake fails to find sys/event.h on FreeBSD 10.2 In-Reply-To: <8644972.EHJBYKRVxt@caliban.sf-tec.de> References: <56491669.8060005@gmail.com> <8644972.EHJBYKRVxt@caliban.sf-tec.de> Message-ID: <5649A645.60706@gmail.com> Can you clarify what you meant with this? To add /usr/incude in CMAKE_REQUIRED_INCLUDES? Doesn't seem to change anything. On 16. 11. 2015 07:35, Rolf Eike Beer wrote: > Am Montag, 16. November 2015, 00:34:01 schrieb Klemen Ferjan?i?: >> FreeBSD 10.2-STABLE >> CMake 3.3.1 >> >> Our projects needs kqueue which means that sys/types.h and sys/event.h >> need to be found. Googling around also revealed that event.h is not self >> inclusive but depends on type.h. Not sure if that has to do with >> anything though. >> >> CMakeLists.txt: >> check_include_file_cxx(sys/types.h HAVE_SYS_TYPES_H) >> if (HAVE_SYS_TYPES_H) >> check_include_file_cxx(sys/event.h HAVE_SYS_EVENT_H) >> endif() > > cmake --help-module CheckIncludeFileCXX > > -> CMAKE_REQUIRED_INCLUDES > > Eike > From Jakub.Golebiewski at dnvgl.com Mon Nov 16 05:37:46 2015 From: Jakub.Golebiewski at dnvgl.com (Golebiewski, Jakub) Date: Mon, 16 Nov 2015 10:37:46 +0000 Subject: [CMake] Speeding up configuration/generation. Message-ID: Hi, I have a windows application consisting of about 550 Visual Studio projects. Entire CMake run on this takes about 3 minutes, with VS 2010 generator, and I've been thinking about ways to speed it up. So if I understand correctly, now, when I have the entire build generated and I change one CMakeLists.txt file, the entire configuration/generation is rerun from scratch (right?). So I've been thinking if It would be possible to cache results of configuration phase and only run the scripts in their entirety when they has been changed (determined by timestamp or hash). Otherwise only add_subdirectory functions are executed. I've looked into the code only a bit so I might be wrong about how it works - if so please correct me. Did you guys maybe think about something like this? Regards, J ************************************************************************************** This e-mail and any attachments thereto may contain confidential information and/or information protected by intellectual property rights for the exclusive attention of the intended addressees named above. If you have received this transmission in error, please immediately notify the sender by return e-mail and delete this message and its attachments. Unauthorized use, copying or further full or partial distribution of this e-mail or its contents is prohibited. ************************************************************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: From eike at sf-mail.de Mon Nov 16 06:00:58 2015 From: eike at sf-mail.de (Rolf Eike Beer) Date: Mon, 16 Nov 2015 12:00:58 +0100 Subject: [CMake] CMake fails to find sys/event.h on FreeBSD 10.2 In-Reply-To: <5649A645.60706@gmail.com> References: <56491669.8060005@gmail.com> <8644972.EHJBYKRVxt@caliban.sf-tec.de> <5649A645.60706@gmail.com> Message-ID: <6b123d7d3c98f938cf967917697d9ae4@sf-mail.de> Am 16.11.2015 10:47, schrieb Klemen Ferjan?i?: > Can you clarify what you meant with this? To add /usr/incude in > CMAKE_REQUIRED_INCLUDES? Doesn't seem to change anything. > > On 16. 11. 2015 07:35, Rolf Eike Beer wrote: >> Am Montag, 16. November 2015, 00:34:01 schrieb Klemen Ferjan?i?: >>> FreeBSD 10.2-STABLE >>> CMake 3.3.1 >>> >>> Our projects needs kqueue which means that sys/types.h and >>> sys/event.h >>> need to be found. Googling around also revealed that event.h is not >>> self >>> inclusive but depends on type.h. Not sure if that has to do with >>> anything though. >>> >>> CMakeLists.txt: >>> check_include_file_cxx(sys/types.h HAVE_SYS_TYPES_H) >>> if (HAVE_SYS_TYPES_H) >>> check_include_file_cxx(sys/event.h HAVE_SYS_EVENT_H) >>> endif() >> >> cmake --help-module CheckIncludeFileCXX >> >> -> CMAKE_REQUIRED_INCLUDES Sorry, I was indeed confusing modules. Since it's a C header you can just use CheckIncludeFiles (not the trailing 's'), which can check several headers at once. Greetings, Eike From imbacen at gmail.com Mon Nov 16 08:38:56 2015 From: imbacen at gmail.com (=?UTF-8?B?S2xlbWVuIEZlcmphbsSNacSN?=) Date: Mon, 16 Nov 2015 14:38:56 +0100 Subject: [CMake] CMake fails to find sys/event.h on FreeBSD 10.2 In-Reply-To: <6b123d7d3c98f938cf967917697d9ae4@sf-mail.de> References: <56491669.8060005@gmail.com> <8644972.EHJBYKRVxt@caliban.sf-tec.de> <5649A645.60706@gmail.com> <6b123d7d3c98f938cf967917697d9ae4@sf-mail.de> Message-ID: <5649DC70.6000503@gmail.com> Thank you, that did it. On 16. 11. 2015 12:00, Rolf Eike Beer wrote: > Am 16.11.2015 10:47, schrieb Klemen Ferjan?i?: >> Can you clarify what you meant with this? To add /usr/incude in >> CMAKE_REQUIRED_INCLUDES? Doesn't seem to change anything. >> >> On 16. 11. 2015 07:35, Rolf Eike Beer wrote: >>> Am Montag, 16. November 2015, 00:34:01 schrieb Klemen Ferjan?i?: >>>> FreeBSD 10.2-STABLE >>>> CMake 3.3.1 >>>> >>>> Our projects needs kqueue which means that sys/types.h and sys/event.h >>>> need to be found. Googling around also revealed that event.h is not >>>> self >>>> inclusive but depends on type.h. Not sure if that has to do with >>>> anything though. >>>> >>>> CMakeLists.txt: >>>> check_include_file_cxx(sys/types.h HAVE_SYS_TYPES_H) >>>> if (HAVE_SYS_TYPES_H) >>>> check_include_file_cxx(sys/event.h HAVE_SYS_EVENT_H) >>>> endif() >>> >>> cmake --help-module CheckIncludeFileCXX >>> >>> -> CMAKE_REQUIRED_INCLUDES > > Sorry, I was indeed confusing modules. Since it's a C header you can > just use CheckIncludeFiles (not the trailing 's'), which can check > several headers at once. > > Greetings, > > Eike From houssen at ipgp.fr Tue Nov 17 05:44:01 2015 From: houssen at ipgp.fr (houssen) Date: Tue, 17 Nov 2015 11:44:01 +0100 Subject: [CMake] =?utf-8?q?How_to_link_archives_=28=2Ea=29_into_shared_obj?= =?utf-8?q?ect_=28=2Eso=29_with_cmake_=3F?= Message-ID: <5912285fd489e5544c007ba6e180e24f@imap.ipgp.fr> Hello, How to link archives (.a) into shared object (.so) with cmake ? I have an archive: ADD_LIBRARY ( myArchive STATIC ${SRC} ) That I need to link with a shared object: ADD_LIBRARY ( mySharedObject SHARED ${SRC} ) TARGET_LINK_LIBRARIES ( mySharedObject PUBLIC myArchive ) I get a compilation error that says "you need to compile with -fPIC !" As far as I understand, I need to use "-Wl,--whole-archive" : http://stackoverflow.com/questions/7935421/linking-archives-a-into-shared-object-so... But I can't figure out how to do that with CMake. Could someone help ? Franck From marc.chevrier at sap.com Tue Nov 17 06:34:30 2015 From: marc.chevrier at sap.com (CHEVRIER, Marc) Date: Tue, 17 Nov 2015 11:34:30 +0000 Subject: [CMake] How to link archives (.a) into shared object (.so) with cmake ? In-Reply-To: <5912285fd489e5544c007ba6e180e24f@imap.ipgp.fr> References: <5912285fd489e5544c007ba6e180e24f@imap.ipgp.fr> Message-ID: <490BA9C4-1131-42A3-827B-421A1C062C3E@sap.com> Hi, Shared libraries required position independent code (PIC) for objects. By default, in CMake, static libraries objects are not compiled with this mode? So your problem. The easiest solution is to add this line to your CMakeLists.txt file: Set (CMAKE_POSITION_INDEPENDENT_CODE ON) Marc On 17/11/15 11:44, "CMake on behalf of houssen" wrote: >Hello, > >How to link archives (.a) into shared object (.so) with cmake ? > >I have an archive: >ADD_LIBRARY ( myArchive STATIC ${SRC} ) >That I need to link with a shared object: >ADD_LIBRARY ( mySharedObject SHARED ${SRC} ) >TARGET_LINK_LIBRARIES ( mySharedObject PUBLIC myArchive ) >I get a compilation error that says "you need to compile with -fPIC !" > >As far as I understand, I need to use "-Wl,--whole-archive" : >http://stackoverflow.com/questions/7935421/linking-archives-a-into-shared-object-so... >But I can't figure out how to do that with CMake. Could someone help ? > >Franck >-- > >Powered by www.kitware.com > >Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > >Kitware offers various services to support the CMake community. For more information on each offering, please visit: > >CMake Support: http://cmake.org/cmake/help/support.html >CMake Consulting: http://cmake.org/cmake/help/consulting.html >CMake Training Courses: http://cmake.org/cmake/help/training.html > >Visit other Kitware 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 houssen at ipgp.fr Tue Nov 17 07:48:47 2015 From: houssen at ipgp.fr (houssen) Date: Tue, 17 Nov 2015 13:48:47 +0100 Subject: [CMake] =?utf-8?q?How_to_link_archives_=28=2Ea=29_into_shared_obj?= =?utf-8?q?ect_=28=2Eso=29_with_cmake_=3F?= In-Reply-To: <490BA9C4-1131-42A3-827B-421A1C062C3E@sap.com> References: <5912285fd489e5544c007ba6e180e24f@imap.ipgp.fr> <490BA9C4-1131-42A3-827B-421A1C062C3E@sap.com> Message-ID: Unfortunately, that does not work !... But indeed, for me, it should have ?!... Franck Le 2015-11-17 12:34, CHEVRIER, Marc a ?crit?: > Hi, > > Shared libraries required position independent code (PIC) for > objects. > By default, in CMake, static libraries objects are not compiled with > this mode? So your problem. > > The easiest solution is to add this line to your CMakeLists.txt file: > Set (CMAKE_POSITION_INDEPENDENT_CODE ON) > > Marc > > > > > On 17/11/15 11:44, "CMake on behalf of houssen" > wrote: > >>Hello, >> >>How to link archives (.a) into shared object (.so) with cmake ? >> >>I have an archive: >>ADD_LIBRARY ( myArchive STATIC ${SRC} ) >>That I need to link with a shared object: >>ADD_LIBRARY ( mySharedObject SHARED ${SRC} ) >>TARGET_LINK_LIBRARIES ( mySharedObject PUBLIC myArchive ) >>I get a compilation error that says "you need to compile with -fPIC >> !" >> >>As far as I understand, I need to use "-Wl,--whole-archive" : >>http://stackoverflow.com/questions/7935421/linking-archives-a-into-shared-object-so... >>But I can't figure out how to do that with CMake. Could someone help >> ? >> >>Franck >>-- >> >>Powered by www.kitware.com >> >>Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >>Kitware offers various services to support the CMake community. For >> more information on each offering, please visit: >> >>CMake Support: http://cmake.org/cmake/help/support.html >>CMake Consulting: http://cmake.org/cmake/help/consulting.html >>CMake Training Courses: http://cmake.org/cmake/help/training.html >> >>Visit other Kitware 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 marc.chevrier at sap.com Tue Nov 17 07:54:56 2015 From: marc.chevrier at sap.com (CHEVRIER, Marc) Date: Tue, 17 Nov 2015 12:54:56 +0000 Subject: [CMake] How to link archives (.a) into shared object (.so) with cmake ? In-Reply-To: References: <5912285fd489e5544c007ba6e180e24f@imap.ipgp.fr> <490BA9C4-1131-42A3-827B-421A1C062C3E@sap.com> Message-ID: <3F9FE780-3388-418C-918E-98070B11051A@sap.com> Set of variable CMAKE_POSITION_INDEPENDENT_CODE must be done BEFORE add_library (? STATIC?). Are you sure you re-generate makefiles? This approach works perfectly for me on Linux with GNU compiler. Marc On 17/11/15 13:48, "CMake on behalf of houssen" wrote: >Unfortunately, that does not work !... But indeed, for me, it should >have ?!... > >Franck > >Le 2015-11-17 12:34, CHEVRIER, Marc a ?crit : >> Hi, >> >> Shared libraries required position independent code (PIC) for >> objects. >> By default, in CMake, static libraries objects are not compiled with >> this mode? So your problem. >> >> The easiest solution is to add this line to your CMakeLists.txt file: >> Set (CMAKE_POSITION_INDEPENDENT_CODE ON) >> >> Marc >> >> >> >> >> On 17/11/15 11:44, "CMake on behalf of houssen" >> wrote: >> >>>Hello, >>> >>>How to link archives (.a) into shared object (.so) with cmake ? >>> >>>I have an archive: >>>ADD_LIBRARY ( myArchive STATIC ${SRC} ) >>>That I need to link with a shared object: >>>ADD_LIBRARY ( mySharedObject SHARED ${SRC} ) >>>TARGET_LINK_LIBRARIES ( mySharedObject PUBLIC myArchive ) >>>I get a compilation error that says "you need to compile with -fPIC >>> !" >>> >>>As far as I understand, I need to use "-Wl,--whole-archive" : >>>http://stackoverflow.com/questions/7935421/linking-archives-a-into-shared-object-so... >>>But I can't figure out how to do that with CMake. Could someone help >>> ? >>> >>>Franck >>>-- >>> >>>Powered by www.kitware.com >>> >>>Please keep messages on-topic and check the CMake FAQ at: >>> http://www.cmake.org/Wiki/CMake_FAQ >>> >>>Kitware offers various services to support the CMake community. For >>> more information on each offering, please visit: >>> >>>CMake Support: http://cmake.org/cmake/help/support.html >>>CMake Consulting: http://cmake.org/cmake/help/consulting.html >>>CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>>Visit other Kitware 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 jack.stalnaker at gmail.com Tue Nov 17 10:37:25 2015 From: jack.stalnaker at gmail.com (Jack Stalnaker) Date: Tue, 17 Nov 2015 09:37:25 -0600 Subject: [CMake] actually using cmake alternative to convenience libraries Message-ID: I'm trying to figure out the best way to handle something that was a convenience lib under autotools. I realize that there's a FAQ entry here: https://cmake.org/Wiki/CMake_FAQ#Does_CMake_support_.22convenience.22_libraries.3F But its terse 2 paragraphs don't say how to actually do what it suggests. My problem is this. I have this source tree: lib |--foo.c |--foo.h |--bar.c |--bar.h |--baz.c src |--goo.c In lib, I need to somehow collectively refer to foo and bar. Okay, so I can create a variable: set(foobarSRCS foo.c bar.c) set(foobarLIBS ${externalLibFound}) which is what the FAQ entry seems to suggest. However, this variable is not visible to goo.c. Okay, so as an alternative, I can do this: set(foobarSRCS foo.c bar.c PARENT_SCOPE), etc. but now the variable is not visible to baz.c, which also must include the srcs to create a module library called _baz! I can of course do something like this: set(foobarSRCSLOC foo.c bar.c) set(foobarSRCS ${foobarSRCSLOC} PARENT_SCOPE) but this feels dirty and repetitive. I also realize that I can just create the variables in src, but that kind of defeats the entire purpose of walling of the common libs and their dependencies in the first place. Is this the right way to work, or am I missing something simple? --Jack -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.hoffman at kitware.com Tue Nov 17 12:14:53 2015 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Tue, 17 Nov 2015 12:14:53 -0500 Subject: [CMake] actually using cmake alternative to convenience libraries In-Reply-To: References: Message-ID: <564B608D.1060803@kitware.com> On 11/17/2015 10:37 AM, Jack Stalnaker wrote: > I'm trying to figure out the best way to handle something that was a > convenience lib under autotools. I realize that there's a FAQ entry here: > > https://cmake.org/Wiki/CMake_FAQ#Does_CMake_support_.22convenience.22_libraries.3F > > But its terse 2 paragraphs don't say how to actually do what it > suggests. My problem is this. I have this source tree: > > lib > |--foo.c > |--foo.h > |--bar.c > |--bar.h > |--baz.c > src > |--goo.c > > In lib, I need to somehow collectively refer to foo and bar. Okay, so I > can create a variable: > > set(foobarSRCS foo.c bar.c) > set(foobarLIBS ${externalLibFound}) > > which is what the FAQ entry seems to suggest. However, this variable is > not visible to goo.c. Okay, so as an alternative, I can do this: > > set(foobarSRCS foo.c bar.c PARENT_SCOPE), etc. > > but now the variable is not visible to baz.c, which also must include > the srcs to create a module library called _baz! I can of course do > something like this: > > set(foobarSRCSLOC foo.c bar.c) > set(foobarSRCS ${foobarSRCSLOC} PARENT_SCOPE) > > but this feels dirty and repetitive. > > I also realize that I can just create the variables in src, but that > kind of defeats the entire purpose of walling of the common libs and > their dependencies in the first place. > > Is this the right way to work, or am I missing something simple? There is a new feature to do that: https://cmake.org/Wiki/CMake/Tutorials/Object_Library -- 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 jack.stalnaker at gmail.com Tue Nov 17 14:46:38 2015 From: jack.stalnaker at gmail.com (Jack Stalnaker) Date: Tue, 17 Nov 2015 13:46:38 -0600 Subject: [CMake] actually using cmake alternative to convenience libraries In-Reply-To: <564B608D.1060803@kitware.com> References: <564B608D.1060803@kitware.com> Message-ID: I read about those, but they don't seem to provide a way to add linked in libraries, so it didn't seem to add a lot over a list of sources. In autotools, you could bind your convenience lib with any dependencies via a LIBADD primary, and the added libs would automatically propagate to the final target. This of course works in cmake if I build a real library, but if I try to link a library (e.g. say the system math library) to the object library, cmake tells me it cannot do that for object libraries. In that case, it seems like I still need to create the foobarLIBRARIES variable to provide to target_link_libraries later. Am I missing something, or is there a way to somehow attach the necessary external libraries to the object library as well? Thanks, --Jack On Tue, Nov 17, 2015 at 11:14 AM, Bill Hoffman wrote: > On 11/17/2015 10:37 AM, Jack Stalnaker wrote: > >> I'm trying to figure out the best way to handle something that was a >> convenience lib under autotools. I realize that there's a FAQ entry here: >> >> >> https://cmake.org/Wiki/CMake_FAQ#Does_CMake_support_.22convenience.22_libraries.3F >> >> But its terse 2 paragraphs don't say how to actually do what it >> suggests. My problem is this. I have this source tree: >> >> lib >> |--foo.c >> |--foo.h >> |--bar.c >> |--bar.h >> |--baz.c >> src >> |--goo.c >> >> In lib, I need to somehow collectively refer to foo and bar. Okay, so I >> can create a variable: >> >> set(foobarSRCS foo.c bar.c) >> set(foobarLIBS ${externalLibFound}) >> >> which is what the FAQ entry seems to suggest. However, this variable is >> not visible to goo.c. Okay, so as an alternative, I can do this: >> >> set(foobarSRCS foo.c bar.c PARENT_SCOPE), etc. >> >> but now the variable is not visible to baz.c, which also must include >> the srcs to create a module library called _baz! I can of course do >> something like this: >> >> set(foobarSRCSLOC foo.c bar.c) >> set(foobarSRCS ${foobarSRCSLOC} PARENT_SCOPE) >> >> but this feels dirty and repetitive. >> >> I also realize that I can just create the variables in src, but that >> kind of defeats the entire purpose of walling of the common libs and >> their dependencies in the first place. >> >> Is this the right way to work, or am I missing something simple? >> > There is a new feature to do that: > > https://cmake.org/Wiki/CMake/Tutorials/Object_Library > > -- > 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 > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 houssen at ipgp.fr Wed Nov 18 03:47:23 2015 From: houssen at ipgp.fr (houssen) Date: Wed, 18 Nov 2015 09:47:23 +0100 Subject: [CMake] =?utf-8?q?How_to_link_archives_=28=2Ea=29_into_shared_obj?= =?utf-8?q?ect_=28=2Eso=29_with_cmake_=3F?= In-Reply-To: <3F9FE780-3388-418C-918E-98070B11051A@sap.com> References: <5912285fd489e5544c007ba6e180e24f@imap.ipgp.fr> <490BA9C4-1131-42A3-827B-421A1C062C3E@sap.com> <3F9FE780-3388-418C-918E-98070B11051A@sap.com> Message-ID: <9dfb53e4d44f7fe9abeec788b0fa9c52@imap.ipgp.fr> You are right, thanks for the tip ! I didn't pay attention and, indeed, I set CMAKE_POSITION_INDEPENDENT_CODE after ADD_LIBRARY (I believed it could be handled afterwards) Franck Le 2015-11-17 13:54, CHEVRIER, Marc a ?crit?: > Set of variable CMAKE_POSITION_INDEPENDENT_CODE must be done BEFORE > add_library (? STATIC?). > > Are you sure you re-generate makefiles? > > This approach works perfectly for me on Linux with GNU compiler. > > Marc > > > > On 17/11/15 13:48, "CMake on behalf of houssen" > wrote: > >>Unfortunately, that does not work !... But indeed, for me, it should >>have ?!... >> >>Franck >> >>Le 2015-11-17 12:34, CHEVRIER, Marc a ?crit : >>> Hi, >>> >>> Shared libraries required position independent code (PIC) for >>> objects. >>> By default, in CMake, static libraries objects are not compiled >>> with >>> this mode? So your problem. >>> >>> The easiest solution is to add this line to your CMakeLists.txt >>> file: >>> Set (CMAKE_POSITION_INDEPENDENT_CODE ON) >>> >>> Marc >>> >>> >>> >>> >>> On 17/11/15 11:44, "CMake on behalf of houssen" >>> wrote: >>> >>>>Hello, >>>> >>>>How to link archives (.a) into shared object (.so) with cmake ? >>>> >>>>I have an archive: >>>>ADD_LIBRARY ( myArchive STATIC ${SRC} ) >>>>That I need to link with a shared object: >>>>ADD_LIBRARY ( mySharedObject SHARED ${SRC} ) >>>>TARGET_LINK_LIBRARIES ( mySharedObject PUBLIC myArchive ) >>>>I get a compilation error that says "you need to compile with -fPIC >>>> !" >>>> >>>>As far as I understand, I need to use "-Wl,--whole-archive" : >>>>http://stackoverflow.com/questions/7935421/linking-archives-a-into-shared-object-so... >>>>But I can't figure out how to do that with CMake. Could someone >>>> help >>>> ? >>>> >>>>Franck >>>>-- >>>> >>>>Powered by www.kitware.com >>>> >>>>Please keep messages on-topic and check the CMake FAQ at: >>>> http://www.cmake.org/Wiki/CMake_FAQ >>>> >>>>Kitware offers various services to support the CMake community. For >>>> more information on each offering, please visit: >>>> >>>>CMake Support: http://cmake.org/cmake/help/support.html >>>>CMake Consulting: http://cmake.org/cmake/help/consulting.html >>>>CMake Training Courses: http://cmake.org/cmake/help/training.html >>>> >>>>Visit other Kitware 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 magnus at therning.org Wed Nov 18 08:16:33 2015 From: magnus at therning.org (Magnus Therning) Date: Wed, 18 Nov 2015 14:16:33 +0100 Subject: [CMake] actually using cmake alternative to convenience libraries In-Reply-To: References: Message-ID: <20151118131633.GC17700@sobel.cipherstone.com> On Tue, Nov 17, 2015 at 09:37:25AM -0600, Jack Stalnaker wrote: > I'm trying to figure out the best way to handle something that was a > convenience lib under autotools. I realize that there's a FAQ entry here: > > https://cmake.org/Wiki/CMake_FAQ#Does_CMake_support_.22convenience.22_libraries.3F > > But its terse 2 paragraphs don't say how to actually do what it suggests. > My problem is this. I have this source tree: > > lib > |--foo.c > |--foo.h > |--bar.c > |--bar.h > |--baz.c > src > |--goo.c > > In lib, I need to somehow collectively refer to foo and bar. Okay, so I can > create a variable: > > set(foobarSRCS foo.c bar.c) > set(foobarLIBS ${externalLibFound}) > > which is what the FAQ entry seems to suggest. However, this variable is not > visible to goo.c. Okay, so as an alternative, I can do this: > > set(foobarSRCS foo.c bar.c PARENT_SCOPE), etc. > > but now the variable is not visible to baz.c, which also must include the > srcs to create a module library called _baz! I can of course do something > like this: > > set(foobarSRCSLOC foo.c bar.c) > set(foobarSRCS ${foobarSRCSLOC} PARENT_SCOPE) > > but this feels dirty and repetitive. > > I also realize that I can just create the variables in src, but that kind > of defeats the entire purpose of walling of the common libs and their > dependencies in the first place. > > Is this the right way to work, or am I missing something simple? From your text above it sounds like foo.{c,h} and bar.{c,h} don't really belong together with baz.c (it's not part of the convenience lib). So, why not separate them? Another thought, you can always put a CMakeLists.txt in the parent dir to lib&src with set(foobarSRCS lib/foo.c lib/bar.c) (maybe with the use of CMAKE_CURRENT_SOURCE_DIR too). A final questin, why was it a convenience lib in the autotools setup? Unless there's really a need to compile the files multiple times the whole issue can be side stepped by making it a static lib. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus at therning.org jabber: magnus at therning.org twitter: magthe http://therning.org/magnus As we enjoy great advantages from the inventions of others we should be glad of an opportunity to serve others by any invention of ours, and this we should do freely and generously. -- Benjamin Franklin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From jack.stalnaker at gmail.com Wed Nov 18 09:16:39 2015 From: jack.stalnaker at gmail.com (Jack Stalnaker) Date: Wed, 18 Nov 2015 08:16:39 -0600 Subject: [CMake] actually using cmake alternative to convenience libraries In-Reply-To: <20151118131633.GC17700@sobel.cipherstone.com> References: <20151118131633.GC17700@sobel.cipherstone.com> Message-ID: In the real source code, baz is a thin wrapper for the foo/bar lib. It combines them into a Python module library, and doesn't really contain any substantial code of its own. It's a convenience lib because in the real code, multiple executables and libs are built from the source tree, and the stuff in lib is common to most, if not all of these. I could make it a static lib, but it doesn't need to be installed. I did initially get it working by simply not installing the lib and setting a POSITION_INDEPENDENT_CODE property on the static lib, but that didn't feel properly "cmake-ish". I'm trying to recreate the FAQ's suggestion of simply listing the convenience lib sources. As for the last suggestion, I was specifically trying to avoid listing the sources in the top level CMakeLists.txt file. To me, that pollutes the top-level file with stuff it shouldn't care about. In the likely event that I have to change the contents of src or lib, I have to change the top-level CMakeLists, which seems non-intuitive. I realize all of this sounds incredibly pedantic, since I've found so many workarounds by now, but I guess I'm trying to get to the bottom of the CMake crew's vision of how what used to be convenience libs in autotools should work in CMake. The idea of smashing together a set of common objects and their dependencies into a convenient partially compiled/linked block and passing it around without installing it just seems so, well, convenient and clean, and I am trying to envision the alternative since otherwise cmake seems so convenient and clean compared to autotools. --Jack On Wed, Nov 18, 2015 at 7:16 AM, Magnus Therning wrote: > On Tue, Nov 17, 2015 at 09:37:25AM -0600, Jack Stalnaker wrote: > > I'm trying to figure out the best way to handle something that was a > > convenience lib under autotools. I realize that there's a FAQ entry here: > > > > > https://cmake.org/Wiki/CMake_FAQ#Does_CMake_support_.22convenience.22_libraries.3F > > > > But its terse 2 paragraphs don't say how to actually do what it suggests. > > My problem is this. I have this source tree: > > > > lib > > |--foo.c > > |--foo.h > > |--bar.c > > |--bar.h > > |--baz.c > > src > > |--goo.c > > > > In lib, I need to somehow collectively refer to foo and bar. Okay, so I > can > > create a variable: > > > > set(foobarSRCS foo.c bar.c) > > set(foobarLIBS ${externalLibFound}) > > > > which is what the FAQ entry seems to suggest. However, this variable is > not > > visible to goo.c. Okay, so as an alternative, I can do this: > > > > set(foobarSRCS foo.c bar.c PARENT_SCOPE), etc. > > > > but now the variable is not visible to baz.c, which also must include the > > srcs to create a module library called _baz! I can of course do something > > like this: > > > > set(foobarSRCSLOC foo.c bar.c) > > set(foobarSRCS ${foobarSRCSLOC} PARENT_SCOPE) > > > > but this feels dirty and repetitive. > > > > I also realize that I can just create the variables in src, but that kind > > of defeats the entire purpose of walling of the common libs and their > > dependencies in the first place. > > > > Is this the right way to work, or am I missing something simple? > > From your text above it sounds like foo.{c,h} and bar.{c,h} don't really > belong together with baz.c (it's not part of the convenience lib). So, > why not separate them? > > Another thought, you can always put a CMakeLists.txt in the parent dir > to lib&src with > > set(foobarSRCS lib/foo.c lib/bar.c) > > (maybe with the use of CMAKE_CURRENT_SOURCE_DIR too). > > A final questin, why was it a convenience lib in the autotools setup? > Unless there's really a need to compile the files multiple times the > whole issue can be side stepped by making it a static lib. > > /M > > -- > Magnus Therning OpenPGP: 0xAB4DFBA4 > email: magnus at therning.org jabber: magnus at therning.org > twitter: magthe http://therning.org/magnus > > As we enjoy great advantages from the inventions of others we should > be glad of an opportunity to serve others by any invention of > ours, and this we should do freely and generously. > -- Benjamin Franklin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus at therning.org Wed Nov 18 09:26:39 2015 From: magnus at therning.org (Magnus Therning) Date: Wed, 18 Nov 2015 15:26:39 +0100 Subject: [CMake] actually using cmake alternative to convenience libraries In-Reply-To: References: <20151118131633.GC17700@sobel.cipherstone.com> Message-ID: <20151118142639.GA23926@sobel.cipherstone.com> On Wed, Nov 18, 2015 at 08:16:39AM -0600, Jack Stalnaker wrote: > In the real source code, baz is a thin wrapper for the foo/bar lib. It > combines them into a Python module library, and doesn't really contain > any substantial code of its own. Ah, that justifies its location then :) > As for the last suggestion, I was specifically trying to avoid listing > the sources in the top level CMakeLists.txt file. To me, that pollutes > the top-level file with stuff it shouldn't care about. In the likely > event that I have to change the contents of src or lib, I have to > change the top-level CMakeLists, which seems non-intuitive. What about using `include()` to bring the variables into the top-level (or really any level)? (Do note I haven't thought that suggestion through properly!) > I realize all of this sounds incredibly pedantic, since I've found so > many workarounds by now, but I guess I'm trying to get to the bottom > of the CMake crew's vision of how what used to be convenience libs in > autotools should work in CMake. The idea of smashing together a set of > common objects and their dependencies into a convenient partially > compiled/linked block and passing it around without installing it just > seems so, well, convenient and clean, and I am trying to envision the > alternative since otherwise cmake seems so convenient and clean > compared to autotools. Oh, how I recognize that feeling. :) Sometimes CMake feels clean and convenient, and then all of a sudden one has to start thinking about what's available at which state and frustration grows... I guess build systems are a bit like mail readers, they all suck, one just have to find one that sucks less than the previous one used. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus at therning.org jabber: magnus at therning.org twitter: magthe http://therning.org/magnus If voting could really change things it would be illegal. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From attila.krasznahorkay at gmail.com Wed Nov 18 12:55:49 2015 From: attila.krasznahorkay at gmail.com (Attila Krasznahorkay) Date: Wed, 18 Nov 2015 18:55:49 +0100 Subject: [CMake] How to depend on files generated in a subdirectory? Message-ID: <6C26B256-A650-4BCF-A637-D6809389B35F@gmail.com> Dear All, I'm trying to do something that may be very easy to implement, but I'm really struggling with it at the moment... I have a project in which I generate various files in subdirectories. Which I add to the main project file using add_subdirectory(...). Some of these files I need to merge into a single file at the end of the build. For which I tried to set up a custom command in my main project file. But I can't convince this main project file to find out how to generate the files whose generation rule sits in a subdirectory. Attached is a simple example of what I mean. In this example it is possible to execute the following commands successfully: make SubdirTarget make Since by the time the main target is built, its source files are already available. But if I try to just execute "make" first, I get: Scanning dependencies of target MergeFiles make[2]: *** No rule to make target `subdir/file3.txt', needed by `merged.txt'. Stop. make[1]: *** [CMakeFiles/MergeFiles.dir/all] Error 2 make: *** [all] Error 2 I tried a number of different directory/file name combinations by now, but the problematic thing in the end seems to be that these files are generated in a different directory than where I try to use them. Do you have a suggestion on how I could do something like this? Cheers, Attila -------------- next part -------------- A non-text attachment was scrubbed... Name: mergeGeneratedExample.tar.bz2 Type: application/x-bzip2 Size: 644 bytes Desc: not available URL: From zbergquist99 at gmail.com Wed Nov 18 18:23:07 2015 From: zbergquist99 at gmail.com (Zac Bergquist) Date: Wed, 18 Nov 2015 18:23:07 -0500 Subject: [CMake] How to depend on files generated in a subdirectory? In-Reply-To: <6C26B256-A650-4BCF-A637-D6809389B35F@gmail.com> References: <6C26B256-A650-4BCF-A637-D6809389B35F@gmail.com> Message-ID: Would this work? add_dependencies(MergeFiles SubdirTarget) On Nov 18, 2015 12:56 PM, "Attila Krasznahorkay" < attila.krasznahorkay at gmail.com> wrote: > Dear All, > > I'm trying to do something that may be very easy to implement, but I'm > really struggling with it at the moment... > > I have a project in which I generate various files in subdirectories. > Which I add to the main project file using add_subdirectory(...). Some of > these files I need to merge into a single file at the end of the build. For > which I tried to set up a custom command in my main project file. But I > can't convince this main project file to find out how to generate the files > whose generation rule sits in a subdirectory. > > Attached is a simple example of what I mean. In this example it is > possible to execute the following commands successfully: > > make SubdirTarget > make > > Since by the time the main target is built, its source files are already > available. But if I try to just execute "make" first, I get: > > Scanning dependencies of target MergeFiles > make[2]: *** No rule to make target `subdir/file3.txt', needed by > `merged.txt'. Stop. > make[1]: *** [CMakeFiles/MergeFiles.dir/all] Error 2 > make: *** [all] Error 2 > > I tried a number of different directory/file name combinations by now, but > the problematic thing in the end seems to be that these files are generated > in a different directory than where I try to use them. > > Do you have a suggestion on how I could do something like this? > > Cheers, > Attila > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 attila.krasznahorkay at gmail.com Thu Nov 19 03:01:41 2015 From: attila.krasznahorkay at gmail.com (Attila Krasznahorkay) Date: Thu, 19 Nov 2015 09:01:41 +0100 Subject: [CMake] How to depend on files generated in a subdirectory? In-Reply-To: References: <6C26B256-A650-4BCF-A637-D6809389B35F@gmail.com> Message-ID: Hi Zac, Interesting. I was convinced that it wouldn't work with Ninja. But it does. Thanks! Attila > On 19 Nov 2015, at 00:23, Zac Bergquist wrote: > > Would this work? > > add_dependencies(MergeFiles SubdirTarget) > > On Nov 18, 2015 12:56 PM, "Attila Krasznahorkay" wrote: > Dear All, > > I'm trying to do something that may be very easy to implement, but I'm really struggling with it at the moment... > > I have a project in which I generate various files in subdirectories. Which I add to the main project file using add_subdirectory(...). Some of these files I need to merge into a single file at the end of the build. For which I tried to set up a custom command in my main project file. But I can't convince this main project file to find out how to generate the files whose generation rule sits in a subdirectory. > > Attached is a simple example of what I mean. In this example it is possible to execute the following commands successfully: > > make SubdirTarget > make > > Since by the time the main target is built, its source files are already available. But if I try to just execute "make" first, I get: > > Scanning dependencies of target MergeFiles > make[2]: *** No rule to make target `subdir/file3.txt', needed by `merged.txt'. Stop. > make[1]: *** [CMakeFiles/MergeFiles.dir/all] Error 2 > make: *** [all] Error 2 > > I tried a number of different directory/file name combinations by now, but the problematic thing in the end seems to be that these files are generated in a different directory than where I try to use them. > > Do you have a suggestion on how I could do something like this? > > Cheers, > Attila > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 merikankoyun at gmail.com Thu Nov 19 04:30:57 2015 From: merikankoyun at gmail.com (Merikan Koyun) Date: Thu, 19 Nov 2015 10:30:57 +0100 Subject: [CMake] Cross compile for ADSP SHARC using the CrossCore toolchain In-Reply-To: <564D95E5.8000109@gmail.com> References: <564D95E5.8000109@gmail.com> Message-ID: <564D96D1.9010705@gmail.com> Hi, I am trying extend my CMake toolchain of a C project, to be able to cross compile for an Analog Devices SHARC DSP, specifically the SC589, which is a fairly new model. This C project is split up into several modules, which should each be build as a separate library. I saw that people seem to have successfully cross compile with CMake using the CMakeADSP toolchain as described in the CMake wiki. This uses the VisualDSP++ suite from Analog Devices. However, Analog Devices have released a new IDE/toolchain for developing on DSPs, which is called CrossCore Embedded Studio. And that is where I am struggling to make it work. What I did was getting the Generic-ADSP-Common.cmake and the Generic-ADSP-C.cmake files. I modified them to fit the new folder structure of CrossCore, which is slightly different to the VisualDSP++ one. So it can find the correct DSP specific libraries etc. Then I wrote a toolchain file adsp.cmake: SET( CMAKE_SYSTEM_NAME ADSP-C ) SET( CMAKE_MAKE_PROGRAM "C:/Analog\ Devices/CrossCore\ Embedded\ Studio\ 2.1.0/make.exe" ) SET( CMAKE_GENERATOR "Unix Makefiles") SET( ADSP_PROCESSOR "ADSP-SC589" ) SET( ADSP_PROCESSOR_SILICIUM_REVISION "none" ) # specify the cross compiler SET( CMAKE_C_COMPILER "C:/Analog\ Devices/CrossCore\ Embedded Studio\ 2.1.0/cc21k.exe" ) SET( CMAKE_CXX_COMPILER "C:/Analog\ Devices/CrossCore\ Embedded Studio\ 2.1.0/cc21k.exe" ) SET( CMAKE_CXX_COMPILER_ARG1 "-c++" CACHE STRING "First argument" ) SET( CMAKE_ASM_COMPILER "C:/Analog\ Devices/CrossCore\ Embedded\ Studio\ 2.1.0/easm21k.exe" ) SET( CMAKE_LINKER "C:/Analog\ Devices/CrossCore\ Embedded\ Studio\ 2.1.0/linker.exe" ) I am not sure, if this is actually even close to being correct. But it seems from the CMake build output, it actually does something remotely useful... Then I invoke CMake via cmake -DCMAKE_TOOLCHAIN_FILE=../adsp.cmake -G "Unix Makefiles" .. This is when I get a bunch of errors(see the bottom of the mail). From the errors, it seems that it wants to link against some 160_hdr.doj. I looked into the directory in which all the libraries reside for my DSP and could not find it. Then I looked for libraries of the older DSPsand found out that only the ADSP 21160 requires this library. So I assume thatsomehow I could not manage to create a correct toolchain, because it still searches for the libraries of an older model? Did anyone manage to cross compile using the new CrossCore toolchain and can give some info or can anyone elaborate on some steps I am quite possibly missing here? Or will it not be possible to use the new ADSP CrossCore toolchain without performing in depth changes to the CMake code? Thanks a lot in advance, Merikan CMakeError.log: The C compiler identification could not be found in "C:/Users/mym/cproj/bin/CMakeFiles/3.3.0-rc2/CompilerIdC/CMakeCCompilerId.dxe" The C compiler identification could not be found in "C:/Users/mym/cproj/bin/CMakeFiles/3.3.0-rc2/CompilerIdC/CMakeCCompilerId.doj" The C compiler identification could not be found in "C:/Users/mym/cproj/bin/CMakeFiles/3.3.0-rc2/CompilerIdC/CMakeCCompilerId.dxe" Checking whether the C compiler is IAR using "" did not match "IAR .+ Compiler": cc3101: fatal error: No source files specified The CXX compiler identification could not be found in "C:/Users/mym/cproj/bin/CMakeFiles/3.3.0-rc2/CompilerIdCXX/CMakeCXXCompilerId.dxe" The CXX compiler identification could not be found in "C:/Users/mym/cproj/bin/CMakeFiles/3.3.0-rc2/CompilerIdCXX/CMakeCXXCompilerId.doj" Checking whether the CXX compiler is IAR using "" did not match "IAR .+ Compiler": cc3101: fatal error: No source files specified Determining if the C compiler works failed with the following output: Change Dir: C:/Users/mym/cproj/bin/CMakeFiles/CMakeTmp Run Build Command:"c:/ANALOG~1/CROSSC~1.0/make.exe" "cmTC_5c20e/fast" c:/ANALOG~1/CROSSC~1.0/make.exe -f CMakeFiles/cmTC_5c20e.dir/build.make CMakeFiles/cmTC_5c20e.dir/build make.exe[1]: Entering directory `C:/Users/mym/cproj/bin/CMakeFiles/CMakeTmp' Building C object CMakeFiles/cmTC_5c20e.dir/testCCompiler.c.doj "C:/Analog Devices/CrossCore Embedded Studio 2.1.0/cc21k.exe" -o CMakeFiles/cmTC_5c20e.dir/testCCompiler.c.doj -c C:/Users/mym/cproj/bin/CMakeFiles/CMakeTmp/testCCompiler.c Linking C executable cmTC_5c20e.dxe "C:/Analog Devices/CrossCore Embedded Studio 2.1.0/cc21k.exe" "CMakeFiles/cmTC_5c20e.dir/testCCompiler.c.doj" -o cmTC_5c20e.dxe -L"C:/Analog Devices/CrossCore Embedded Studio 2.1.0/SHARC/lib/sc589_rev_none" [Error li1021] The following symbols referenced in processor 'p0' could not be resolved: '_dispatcher_CB15I [__dispatcher_CB15I]' referenced from '160_hdr.doj' '_dispatcher_CB7I [__dispatcher_CB7I]' referenced from '160_hdr.doj' '_dispatcher_EP0I [__dispatcher_EP0I]' referenced from '160_hdr.doj' '_dispatcher_EP1I [__dispatcher_EP1I]' referenced from '160_hdr.doj' '_dispatcher_EP2I [__dispatcher_EP2I]' referenced from '160_hdr.doj' '_dispatcher_EP3I [__dispatcher_EP3I]' referenced from '160_hdr.doj' '_dispatcher_FIXI [__dispatcher_FIXI]' referenced from '160_hdr.doj' '_dispatcher_FLTII [__dispatcher_FLTII]' referenced from '160_hdr.doj' '_dispatcher_FLTOI [__dispatcher_FLTOI]' referenced from '160_hdr.doj' '_dispatcher_FLTUI [__dispatcher_FLTUI]' referenced from '160_hdr.doj' '_dispatcher_IICDI [__dispatcher_IICDI]' referenced from '160_hdr.doj' '_dispatcher_IRQ0I [__dispatcher_IRQ0I]' referenced from '160_hdr.doj' '_dispatcher_IRQ1I [__dispatcher_IRQ1I]' referenced from '160_hdr.doj' '_dispatcher_IRQ2I [__dispatcher_IRQ2I]' referenced from '160_hdr.doj' '_dispatcher_LP0I [__dispatcher_LP0I]' referenced from '160_hdr.doj' '_dispatcher_LP1I [__dispatcher_LP1I]' referenced from '160_hdr.doj' '_dispatcher_LP2I [__dispatcher_LP2I]' referenced from '160_hdr.doj' '_dispatcher_LP3I [__dispatcher_LP3I]' referenced from '160_hdr.doj' '_dispatcher_LP4I [__dispatcher_LP4I]' referenced from '160_hdr.doj' '_dispatcher_LP5I [__dispatcher_LP5I]' referenced from '160_hdr.doj' '_dispatcher_LSRQI [__dispatcher_LSRQI]' referenced from '160_hdr.doj' '_dispatcher_SFT0I [__dispatcher_SFT0I]' referenced from '160_hdr.doj' '_dispatcher_SFT1I [__dispatcher_SFT1I]' referenced from '160_hdr.doj' '_dispatcher_SFT2I [__dispatcher_SFT2I]' referenced from '160_hdr.doj' '_dispatcher_SFT3I [__dispatcher_SFT3I]' referenced from '160_hdr.doj' '_dispatcher_SOVFI [__dispatcher_SOVFI]' referenced from '160_hdr.doj' '_dispatcher_SPR0I [__dispatcher_SPR0I]' referenced from '160_hdr.doj' '_dispatcher_SPR1I [__dispatcher_SPR1I]' referenced from '160_hdr.doj' '_dispatcher_SPT0I [__dispatcher_SPT0I]' referenced from '160_hdr.doj' '_dispatcher_SPT1I [__dispatcher_SPT1I]' referenced from '160_hdr.doj' '_dispatcher_TMZHI [__dispatcher_TMZHI]' referenced from '160_hdr.doj' '_dispatcher_TMZLI [__dispatcher_TMZLI]' referenced from '160_hdr.doj' '_dispatcher_VIRPTI [__dispatcher_VIRPTI]' referenced from '160_hdr.doj' 'adi_osal_Init [_adi_osal_Init]' referenced from '160_hdr.doj' Linker finished with 1 error cc3089: fatal error: Link failed (code:1) make.exe[1]: *** [cmTC_5c20e.dxe] Error 1 make.exe[1]: Leaving directory `C:/Users/mym/cproj/bin/CMakeFiles/CMakeTmp' make.exe: *** [cmTC_5c20e/fast] Error 2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tamas.kenez at gmail.com Thu Nov 19 17:04:13 2015 From: tamas.kenez at gmail.com (=?UTF-8?B?VGFtw6FzIEtlbsOpeg==?=) Date: Thu, 19 Nov 2015 23:04:13 +0100 Subject: [CMake] actually using cmake alternative to convenience libraries In-Reply-To: References: Message-ID: > set(foobarSRCS foo.c bar.c) > set(foobarLIBS ${externalLibFound}) > > which is what the FAQ entry seems to suggest. However, this variable is not visible to goo.c. Okay, so as an alternative, I can do this: > > set(foobarSRCS foo.c bar.c PARENT_SCOPE), etc. In similar cases I create CACHE variables: set(foobarSRCS foo.c bar.c CACHE INTERNAL "" FORCE) set(foobarLIBS ${externalLibFound} CACHE INTERNAL "" FORCE) You can also write a set_cache() macro. Tamas On Tue, Nov 17, 2015 at 4:37 PM, Jack Stalnaker wrote: > I'm trying to figure out the best way to handle something that was a > convenience lib under autotools. I realize that there's a FAQ entry here: > > > https://cmake.org/Wiki/CMake_FAQ#Does_CMake_support_.22convenience.22_libraries.3F > > But its terse 2 paragraphs don't say how to actually do what it suggests. > My problem is this. I have this source tree: > > lib > |--foo.c > |--foo.h > |--bar.c > |--bar.h > |--baz.c > src > |--goo.c > > In lib, I need to somehow collectively refer to foo and bar. Okay, so I > can create a variable: > > set(foobarSRCS foo.c bar.c) > set(foobarLIBS ${externalLibFound}) > > which is what the FAQ entry seems to suggest. However, this variable is > not visible to goo.c. Okay, so as an alternative, I can do this: > > set(foobarSRCS foo.c bar.c PARENT_SCOPE), etc. > > but now the variable is not visible to baz.c, which also must include the > srcs to create a module library called _baz! I can of course do something > like this: > > set(foobarSRCSLOC foo.c bar.c) > set(foobarSRCS ${foobarSRCSLOC} PARENT_SCOPE) > > but this feels dirty and repetitive. > > I also realize that I can just create the variables in src, but that kind > of defeats the entire purpose of walling of the common libs and their > dependencies in the first place. > > Is this the right way to work, or am I missing something simple? > > --Jack > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 nikita.barawade at einfochips.com Fri Nov 20 07:39:23 2015 From: nikita.barawade at einfochips.com (Nikita Barawade) Date: Fri, 20 Nov 2015 12:39:23 +0000 Subject: [CMake] Cmake : undefined reference to `udev_device_get_devnode' Message-ID: Dear All, I am building an application using cmake with external shared library libLLAPI.so on Ububtu . I am getting following error: make -f Source/CMakeFiles/app.dir/build.make Source/CMakeFiles/app.dir/build make[2]: Entering directory `/home/nikita/intel/CMake_intel/API/Build/Cmake/LLAPI_TestApp/Build' Linking CXX executable app cd /home/nikita/intel/CMake_intel/API/Build/Cmake/LLAPI_TestApp/Build/Source && /usr/bin/cmake -E cmake_link_script CMakeFiles/app.dir/link.txt --verbose=1 /usr/bin/c++ CMakeFiles/app.dir/__/Include/moc_cansettings.cxx.o CMakeFiles/app.dir/__/Include/moc_Logfile.cxx.o CMakeFiles/app.dir/__/Include/moc_SpmGui.cxx.o CMakeFiles/app.dir/main.cpp.o CMakeFiles/app.dir/AllModule.cpp.o CMakeFiles/app.dir/analogmeasure.cpp.o CMakeFiles/app.dir/Can.cpp.o CMakeFiles/app.dir/cansettings.cpp.o CMakeFiles/app.dir/ccTalk.cpp.o CMakeFiles/app.dir/Channel.cpp.o CMakeFiles/app.dir/Common.cpp.o CMakeFiles/app.dir/Dex.cpp.o CMakeFiles/app.dir/Fan.cpp.o CMakeFiles/app.dir/Firmware.cpp.o CMakeFiles/app.dir/Gpio.cpp.o CMakeFiles/app.dir/I2c.cpp.o CMakeFiles/app.dir/LocalPortI2C.cpp.o CMakeFiles/app.dir/LocalPortSerial.cpp.o CMakeFiles/app.dir/Logfile.cpp.o CMakeFiles/app.dir/Mdb.cpp.o CMakeFiles/app.dir/Motor.cpp.o CMakeFiles/app.dir/Onewire.cpp.o CMakeFiles/app.dir/PowerModule.cpp.o CMakeFiles/app.dir/protocolA.cpp.o CMakeFiles/app.dir/rtc.cpp.o CMakeFiles/app.dir/SafeMem.cpp.o CMakeFiles/app.dir/Serial.cpp.o CMakeFiles/app.dir/SevenSegment.cpp.o CMakeFiles/app.dir/Spi.cpp.o CMakeFiles/app.dir/SpmGui.cpp.o CMakeFiles/app.dir/ThreadProcess.cpp.o CMakeFiles/app.dir/USBRelayModule.cpp.o CMakeFiles/app.dir/WriteFile.cpp.o CMakeFiles/app.dir/app_automoc.cpp.o -o app -rdynamic -lQtGui -lQtCore ../../../LLAPI/build/Source/libLLAPI.so -Wl,-rpath,/home/nikita/intel/CMake_intel/API/Build/Cmake/LLAPI_TestApp/Build/../../LLAPI/build/Source CMakeFiles/app.dir/SpmGui.cpp.o: In function `SpmGui::pbPushSelectClicked()': SpmGui.cpp:(.text+0x3904): undefined reference to `llapiVersionRead' ../../../LLAPI/build/Source/libLLAPI.so: undefined reference to `udev_device_get_devnode' ../../../LLAPI/build/Source/libLLAPI.so: undefined reference to `udev_device_new_from_syspath' ../../../LLAPI/build/Source/libLLAPI.so: undefined reference to `udev_device_unref' ../../../LLAPI/build/Source/libLLAPI.so: undefined reference to `udev_enumerate_get_list_entry' ../../../LLAPI/build/Source/libLLAPI.so: undefined reference to `udev_enumerate_add_match_subsystem' ../../../LLAPI/build/Source/libLLAPI.so: undefined reference to `udev_enumerate_scan_devices' ../../../LLAPI/build/Source/libLLAPI.so: undefined reference to `udev_device_get_sysattr_value' ../../../LLAPI/build/Source/libLLAPI.so: undefined reference to `udev_device_new_from_devnum' ../../../LLAPI/build/Source/libLLAPI.so: undefined reference to `udev_device_get_parent_with_subsystem_devtype' ../../../LLAPI/build/Source/libLLAPI.so: undefined reference to `udev_unref' ../../../LLAPI/build/Source/libLLAPI.so: undefined reference to `udev_list_entry_get_name' ../../../LLAPI/build/Source/libLLAPI.so: undefined reference to `udev_enumerate_new' ../../../LLAPI/build/Source/libLLAPI.so: undefined reference to `udev_list_entry_get_next' ../../../LLAPI/build/Source/libLLAPI.so: undefined reference to `udev_new' ../../../LLAPI/build/Source/libLLAPI.so: undefined reference to `udev_enumerate_unref' collect2: error: ld returned 1 exit status make[2]: *** [Source/app] Error 1 make[2]: Leaving directory `/home/nikita/intel/CMake_intel/API/Build/Cmake/LLAPI_TestApp/Build' make[1]: *** [Source/CMakeFiles/app.dir/all] Error 2 make[1]: Leaving directory `/home/nikita/intel/CMake_intel/API/Build/Cmake/LLAPI_TestApp/Build' make: *** [all] Error 2 Before this, while building a library libLLAPI.so I got error " fatal error: libudev.h: No such file or directory" . It worked fine after installing libudev-dev . CmakeList.txt for app: include_directories (../../../Lib/LLAPI/Include) include_directories (../Include) include_directories (../../LLAPI/Include) include_directories (../../../Build/Cmake/LLAPI_TestApp/Build/Source) QT4_WRAP_UI(UISrcs ../Form/cansettings.ui ../Form/Logfile.ui ../Form/ssbGui.ui) QT4_WRAP_CPP(MOCSrcs ../Include/cansettings.h ../Include/Logfile.h ../Include/ssbGui.h) add_library(LLAPI SHARED IMPORTED) set_property(TARGET LLAPI PROPERTY IMPORTED_LOCATION ${CMAKE_BINARY_DIR}/../../LLAPI/build/Source/libLLAPI.so) add_executable (app ${UISrcs} ${MOCSrcs} main.cpp cansettings.cpp Logfile.cpp ssbGui.cpp) target_link_libraries (app ${QT_LIBRARIES} LLAPI) #target_link_libraries (app ${QT_LIBRARIES} Qt4::QtGui Qt4::QtXml LLAPI) install (TARGETS app RUNTIME DESTINATION ${PROJECT_BINARY_DIR}/lib) Searched on Internet for solution but could not fix it. Please guide . Regards, Nikita ************************************************************************************************************************************************************* eInfochips Business Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated. Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. ************************************************************************************************************************************************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Fri Nov 20 08:04:41 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 20 Nov 2015 14:04:41 +0100 Subject: [CMake] Cmake : undefined reference to `udev_device_get_devnode' In-Reply-To: References: Message-ID: <564F1A69.7010209@gmail.com> On 11/20/2015 01:39 PM, Nikita Barawade wrote: > > ../../../LLAPI/build/Source/libLLAPI.so: undefined reference to > `udev_device_get_devnode' > > > Before this, while buildinga library libLLAPI.so I got error " fatal > error: libudev.h: No such file or directory" . > > It worked fine after installing libudev-dev . > > These errors indicate that libLLAPI.so uses function from libudev but probably does not actually link to the library. Assuming it is missing you will need an appropriate target_link_libraries() call for your LLAPI target so that it links to libudev. Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.stijnman at gmail.com Fri Nov 20 09:18:49 2015 From: mark.stijnman at gmail.com (Mark Stijnman) Date: Fri, 20 Nov 2015 15:18:49 +0100 Subject: [CMake] actually using cmake alternative to convenience libraries In-Reply-To: References: Message-ID: On Thu, Nov 19, 2015 at 11:04 PM, Tam?s Ken?z wrote: > > set(foobarSRCS foo.c bar.c) > > set(foobarLIBS ${externalLibFound}) > > > > which is what the FAQ entry seems to suggest. However, this variable is > not visible to goo.c. Okay, so as an alternative, I can do this: > > > > set(foobarSRCS foo.c bar.c PARENT_SCOPE), etc. > > In similar cases I create CACHE variables: > > set(foobarSRCS foo.c bar.c CACHE INTERNAL "" FORCE) > set(foobarLIBS ${externalLibFound} CACHE INTERNAL "" FORCE) > > You can also write a set_cache() macro. > > Tamas > I'd prefer using the PARENT_SCOPE option here, which will make the variables available in the parent CMakeLists.txt. set(foobarSRCS foo.c bar.c PARENT_SCOPE) set(foobarLIBS ${externalLibFound} PARENT_SCOPE) -------------- next part -------------- An HTML attachment was scrubbed... URL: From tamas.kenez at gmail.com Fri Nov 20 11:14:47 2015 From: tamas.kenez at gmail.com (=?UTF-8?B?VGFtw6FzIEtlbsOpeg==?=) Date: Fri, 20 Nov 2015 17:14:47 +0100 Subject: [CMake] actually using cmake alternative to convenience libraries In-Reply-To: References: Message-ID: > I'd prefer using the PARENT_SCOPE option here... Jack's initial email continues with "but now the variable is not visible to baz.c" so using PARENT_SCOPE does not meet his requirements. > which will make the variables available in the parent CMakeLists.txt. So does using cache variables. On Fri, Nov 20, 2015 at 3:18 PM, Mark Stijnman wrote: > On Thu, Nov 19, 2015 at 11:04 PM, Tam?s Ken?z > wrote: > >> > set(foobarSRCS foo.c bar.c) >> > set(foobarLIBS ${externalLibFound}) >> > >> > which is what the FAQ entry seems to suggest. However, this variable is >> not visible to goo.c. Okay, so as an alternative, I can do this: >> > >> > set(foobarSRCS foo.c bar.c PARENT_SCOPE), etc. >> >> In similar cases I create CACHE variables: >> >> set(foobarSRCS foo.c bar.c CACHE INTERNAL "" FORCE) >> set(foobarLIBS ${externalLibFound} CACHE INTERNAL "" FORCE) >> >> You can also write a set_cache() macro. >> >> Tamas >> > > I'd prefer using the PARENT_SCOPE option here, which will make the > variables available in the parent CMakeLists.txt. > set(foobarSRCS foo.c bar.c PARENT_SCOPE) > set(foobarLIBS ${externalLibFound} PARENT_SCOPE) > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 gjasny at googlemail.com Fri Nov 20 11:28:14 2015 From: gjasny at googlemail.com (Gregor Jasny) Date: Fri, 20 Nov 2015 17:28:14 +0100 Subject: [CMake] target_include_directories SYSTEM adds -isystem to Clang, but not GCC In-Reply-To: References: <55D5EE6B.80405@googlemail.com> Message-ID: <564F4A1E.60105@googlemail.com> On 15/11/15 21:13, digitalriptide wrote: > Did this fix make it into 3.4? After upgrading to 3.4, GCC still seems > to lack -isystem flags on OS X. Is there anything extra I need to do? It should be fixed for the Makefile and Ninja generators but not Xcode. My proposed fix broke older Xcode versions so that I had to revert it back. I did not find time to pick this up again. Thanks, Gregor From zbergquist99 at gmail.com Fri Nov 20 13:02:29 2015 From: zbergquist99 at gmail.com (Zac Bergquist) Date: Fri, 20 Nov 2015 13:02:29 -0500 Subject: [CMake] Imported ExternalProject Libraries with Ninja Message-ID: Hello, I'm using ExternalProject to build libxml2 into a static library, which I link my application to. I've read a few warnings about combining ExternalProject with standard CMake targets, but I'm pretty sure this is the approach I want to take. I do not want to install libxml2 globally because I'm configuring it with a very specific set of options. I have something like this: # build libxml2 ExternalProject_Add(libxml2 BINARY_DIR ${CMAKE_CURRENT_BINARY_DIR}/libxml2-2.9.1 CONFIGURE_COMMAND ${XML_SRC}/configure ${CONFIGURE_FLAGS} ... ) # tell CMake that the ExternalProject generated a library add_library(xml2 STATIC IMPORTED GLOBAL) set_property(TARGET xml2 PROPERTY IMPORTED_LOCATION ${CMAKE_CURRENT_BINARY_DIR}/libxml2-2.9.1/.libs/libxml2.a ) add_executable(foo ${SOURCES}) add_dependency(foo libxml2) target_link_libraries(foo xml2) I realize that this isn't as portable as it could [should] be because I'm including information about where the build files will be generated, but I'm okay with this. With the standard Unix makefile generator, everything works fine. I can run `make foo` and it configures and builds libxml2, then builds foo and links to the static library. However, with the ninja generator, I get an error: ninja: error: "libxml2-2.9.1/.libs/libxml2.a', needed by 'out/bin/foo', missing and no known rule to make it For some reason the Ninja build is not picking up on the fact that libxml2.a is generated by the external project. The only way I'm able to get this to build is to run `ninja xml2` followed by `ninja foo`. Am I doing something wrong or could this be a bug in CMake? If so, are there any workarounds. I just started using Ninja and am really enjoying the speed advantage over make. Thanks, Zac -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.hoffman at kitware.com Fri Nov 20 14:23:56 2015 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Fri, 20 Nov 2015 14:23:56 -0500 Subject: [CMake] actually using cmake alternative to convenience libraries In-Reply-To: References: <564B608D.1060803@kitware.com> Message-ID: <564F734C.5090409@kitware.com> On 11/17/2015 2:46 PM, Jack Stalnaker wrote: > I read about those, but they don't seem to provide a way to add linked > in libraries, so it didn't seem to add a lot over a list of sources. In > autotools, you could bind your convenience lib with any dependencies via > a LIBADD primary, and the added libs would automatically propagate to > the final target. This of course works in cmake if I build a real > library, but if I try to link a library (e.g. say the system math > library) to the object library, cmake tells me it cannot do that for > object libraries. In that case, it seems like I still need to create the > foobarLIBRARIES variable to provide to target_link_libraries later. > > Am I missing something, or is there a way to somehow attach the > necessary external libraries to the object library as well? It is a feature that has not been implemented. However, I would say that it does add something over lists of sources. It avoids all the cache and parent scope in this thread. Seems like it would still be more simple to use object libraries than to try and do it via lists of sources. To add that feature would be some work, but is possible: https://cmake.org/Bug/view.php?id=14778 https://cmake.org/Bug/view.php?id=14970 I still think the object libraries might work for you. -Bill From nico.schloemer at gmail.com Sat Nov 21 17:46:28 2015 From: nico.schloemer at gmail.com (=?UTF-8?Q?Nico_Schl=C3=B6mer?=) Date: Sat, 21 Nov 2015 22:46:28 +0000 Subject: [CMake] download file, modify, add test from it Message-ID: Hi everyone, I would like to create a CMake test that does the following: * Download a file from an external resource * Do something with the file * compile an executable myTest * execute myTest outputfile Using ExternalData for downloading the file works well, but the second step (file conversion, in this example cp for simplicity) does not work: ``` cmake_minimum_required(VERSION 3.2) project(mytest) # Download the files INCLUDE(ExternalData) set( ExternalData_URL_TEMPLATES "https://downloads.sourceforge.net/project/noshdata/%(algo)/%(hash)" ) ExternalData_Expand_Arguments( testFetchData OUT_DATA DATA{${CMAKE_SOURCE_DIR}/test.e} ) ExternalData_Add_Target(testFetchData) add_custom_command( OUTPUT test.g COMMAND cp test.e test.g DEPENDS test.e ) ADD_EXECUTABLE("myTest" main.cpp) add_test(myTest test.g) ``` I suppose I'm missing something about the dependencies here; after all, the `add_custom_command` has to wait for `testFetchData` to complete. Likewise, `add_test` has to wait for `add_custom_command` to complete. Hints appreciated. Cheers, Nico -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Sat Nov 21 21:18:53 2015 From: DLRdave at aol.com (David Cole) Date: Sat, 21 Nov 2015 21:18:53 -0500 Subject: [CMake] download file, modify, add test from it In-Reply-To: References: Message-ID: Did you try using full path names for the add_custom_command file names? And the NAME/COMMAND form of the add_test command? Also, I've always found custom commands to work best when they're associated with a target. And if it was part of a target you could make the target depend on the external data target with add_dependencies if necessary. HTH, David C. On Saturday, November 21, 2015, Nico Schl?mer wrote: > Hi everyone, > > I would like to create a CMake test that does the following: > * Download a file from an external resource > * Do something with the file > * compile an executable myTest > * execute myTest outputfile > > Using ExternalData for downloading the file works well, but the second > step (file conversion, in this example cp for simplicity) does not work: > ``` > cmake_minimum_required(VERSION 3.2) > > project(mytest) > > # Download the files > INCLUDE(ExternalData) > set( > ExternalData_URL_TEMPLATES > "https://downloads.sourceforge.net/project/noshdata/%(algo)/%(hash)" > ) > ExternalData_Expand_Arguments( > testFetchData > OUT_DATA DATA{${CMAKE_SOURCE_DIR}/test.e} > ) > ExternalData_Add_Target(testFetchData) > > add_custom_command( > OUTPUT test.g > COMMAND cp test.e test.g > DEPENDS test.e > ) > > ADD_EXECUTABLE("myTest" main.cpp) > > add_test(myTest test.g) > ``` > I suppose I'm missing something about the dependencies here; after all, > the `add_custom_command` has to wait for `testFetchData` to complete. > Likewise, `add_test` has to wait for `add_custom_command` to complete. > > Hints appreciated. > > Cheers, > Nico > -------------- next part -------------- An HTML attachment was scrubbed... URL: From attila.krasznahorkay at gmail.com Sun Nov 22 03:41:56 2015 From: attila.krasznahorkay at gmail.com (Attila Krasznahorkay) Date: Sun, 22 Nov 2015 09:41:56 +0100 Subject: [CMake] Imported ExternalProject Libraries with Ninja In-Reply-To: References: Message-ID: <54E4CEFE-20CD-4E66-B227-7BB220A0D827@gmail.com> Hi Zac, In recent versions of CMake (not sure when it was introduced, but it's available in 3.2.X) you have an extra argument for ExternalProject_Add: BUILD_BYPRODUCTS. https://cmake.org/cmake/help/v3.2/module/ExternalProject.html I use this in a setup very similar to yours to declare all the shared libraries that my external project target will make. This way Ninja knows where to expect those files from. Cheers, Attila > On 20 Nov 2015, at 19:02, Zac Bergquist wrote: > > Hello, > > I'm using ExternalProject to build libxml2 into a static library, which I link my application to. I've read a few warnings about combining ExternalProject with standard CMake targets, but I'm pretty sure this is the approach I want to take. I do not want to install libxml2 globally because I'm configuring it with a very specific set of options. > > I have something like this: > > # build libxml2 > ExternalProject_Add(libxml2 > BINARY_DIR ${CMAKE_CURRENT_BINARY_DIR}/libxml2-2.9.1 > CONFIGURE_COMMAND ${XML_SRC}/configure ${CONFIGURE_FLAGS} > ... > ) > > # tell CMake that the ExternalProject generated a library > add_library(xml2 STATIC IMPORTED GLOBAL) > set_property(TARGET xml2 PROPERTY > IMPORTED_LOCATION ${CMAKE_CURRENT_BINARY_DIR}/libxml2-2.9.1/.libs/libxml2.a > ) > > add_executable(foo ${SOURCES}) > > add_dependency(foo libxml2) > > target_link_libraries(foo xml2) > > I realize that this isn't as portable as it could [should] be because I'm including information about where the build files will be generated, but I'm okay with this. > > With the standard Unix makefile generator, everything works fine. I can run `make foo` and it configures and builds libxml2, then builds foo and links to the static library. > > However, with the ninja generator, I get an error: > > ninja: error: "libxml2-2.9.1/.libs/libxml2.a', needed by 'out/bin/foo', missing and no known rule to make it > > For some reason the Ninja build is not picking up on the fact that libxml2.a is generated by the external project. The only way I'm able to get this to build is to run `ninja xml2` followed by `ninja foo`. > > Am I doing something wrong or could this be a bug in CMake? If so, are there any workarounds. I just started using Ninja and am really enjoying the speed advantage over make. > > Thanks, > Zac > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 nico.schloemer at gmail.com Sun Nov 22 14:02:24 2015 From: nico.schloemer at gmail.com (=?UTF-8?Q?Nico_Schl=C3=B6mer?=) Date: Sun, 22 Nov 2015 19:02:24 +0000 Subject: [CMake] download file, modify, add test from it In-Reply-To: References: Message-ID: Thanks for the hints! I'm almost there now, the only thing missing is to have my test depend on the custom_target. This ``` SET_TESTS_PROPERTIES(testname PROPERTIES DEPENDS convert) ``` doesn't do the trick: The target `convert` isn't executed before `ctest`. Any hints? Cheers, Nico On Sun, Nov 22, 2015 at 3:18 AM David Cole wrote: > Did you try using full path names for the add_custom_command file names? > > And the NAME/COMMAND form of the add_test command? > > Also, I've always found custom commands to work best when they're > associated with a target. And if it was part of a target you could make the > target depend on the external data target with add_dependencies if > necessary. > > > HTH, > David C. > > > On Saturday, November 21, 2015, Nico Schl?mer > wrote: > >> Hi everyone, >> >> I would like to create a CMake test that does the following: >> * Download a file from an external resource >> * Do something with the file >> * compile an executable myTest >> * execute myTest outputfile >> >> Using ExternalData for downloading the file works well, but the second >> step (file conversion, in this example cp for simplicity) does not work: >> ``` >> cmake_minimum_required(VERSION 3.2) >> >> project(mytest) >> >> # Download the files >> INCLUDE(ExternalData) >> set( >> ExternalData_URL_TEMPLATES >> "https://downloads.sourceforge.net/project/noshdata/%(algo)/%(hash)" >> ) >> ExternalData_Expand_Arguments( >> testFetchData >> OUT_DATA DATA{${CMAKE_SOURCE_DIR}/test.e} >> ) >> ExternalData_Add_Target(testFetchData) >> >> add_custom_command( >> OUTPUT test.g >> COMMAND cp test.e test.g >> DEPENDS test.e >> ) >> >> ADD_EXECUTABLE("myTest" main.cpp) >> >> add_test(myTest test.g) >> ``` >> I suppose I'm missing something about the dependencies here; after all, >> the `add_custom_command` has to wait for `testFetchData` to complete. >> Likewise, `add_test` has to wait for `add_custom_command` to complete. >> >> Hints appreciated. >> >> Cheers, >> Nico >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Sun Nov 22 14:46:45 2015 From: DLRdave at aol.com (David Cole) Date: Sun, 22 Nov 2015 14:46:45 -0500 Subject: [CMake] download file, modify, add test from it In-Reply-To: References: Message-ID: What do you mean by "depend" in this case? All libs and exes should be built during a "make" or "make all" or "make install" ... And all that should be done before any tests get run. Simply typing "ctest" to execute all the tests never does any building. The assumed workflow is that you build stuff first and then run the tests. If you want, you can add a custom target that runs a test, and make that custom target depend on any other targets, but ctest still won't know about it. Only "make custom_test_target" will... D On Sunday, November 22, 2015, Nico Schl?mer wrote: > Thanks for the hints! > I'm almost there now, the only thing missing is to have my test depend on > the custom_target. This > ``` > SET_TESTS_PROPERTIES(testname PROPERTIES DEPENDS convert) > ``` > doesn't do the trick: The target `convert` isn't executed before `ctest`. > > Any hints? > > Cheers, > Nico > > > On Sun, Nov 22, 2015 at 3:18 AM David Cole > wrote: > >> Did you try using full path names for the add_custom_command file names? >> >> And the NAME/COMMAND form of the add_test command? >> >> Also, I've always found custom commands to work best when they're >> associated with a target. And if it was part of a target you could make the >> target depend on the external data target with add_dependencies if >> necessary. >> >> >> HTH, >> David C. >> >> >> On Saturday, November 21, 2015, Nico Schl?mer > > wrote: >> >>> Hi everyone, >>> >>> I would like to create a CMake test that does the following: >>> * Download a file from an external resource >>> * Do something with the file >>> * compile an executable myTest >>> * execute myTest outputfile >>> >>> Using ExternalData for downloading the file works well, but the second >>> step (file conversion, in this example cp for simplicity) does not work: >>> ``` >>> cmake_minimum_required(VERSION 3.2) >>> >>> project(mytest) >>> >>> # Download the files >>> INCLUDE(ExternalData) >>> set( >>> ExternalData_URL_TEMPLATES >>> "https://downloads.sourceforge.net/project/noshdata/%(algo)/%(hash)" >>> ) >>> ExternalData_Expand_Arguments( >>> testFetchData >>> OUT_DATA DATA{${CMAKE_SOURCE_DIR}/test.e} >>> ) >>> ExternalData_Add_Target(testFetchData) >>> >>> add_custom_command( >>> OUTPUT test.g >>> COMMAND cp test.e test.g >>> DEPENDS test.e >>> ) >>> >>> ADD_EXECUTABLE("myTest" main.cpp) >>> >>> add_test(myTest test.g) >>> ``` >>> I suppose I'm missing something about the dependencies here; after all, >>> the `add_custom_command` has to wait for `testFetchData` to complete. >>> Likewise, `add_test` has to wait for `add_custom_command` to complete. >>> >>> Hints appreciated. >>> >>> Cheers, >>> Nico >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From nico.schloemer at gmail.com Sun Nov 22 14:54:10 2015 From: nico.schloemer at gmail.com (=?UTF-8?Q?Nico_Schl=C3=B6mer?=) Date: Sun, 22 Nov 2015 19:54:10 +0000 Subject: [CMake] download file, modify, add test from it In-Reply-To: References: Message-ID: I was under the impression that if I don't explicitly build a target, it won't get build. Perhaps I'm wrong here. In any case, this ``` add_custom_target(convert) add_dependencies(convert testFetchData) add_custom_command( TARGET convert COMMAND cp test.e test.g ) ``` never gets executed on `make`, unlike all other targets (e.g., ` testFetchData`). (Full CMakeLists.txt at [1].) Explicitly calling `make convert` works alright. Any idea why that might be? Cheers, Nico [1] http://chunk.io/f/729beeab41fb4a7385ceb98b31a2ea0a On Sun, Nov 22, 2015 at 8:46 PM David Cole wrote: > What do you mean by "depend" in this case? All libs and exes should be > built during a "make" or "make all" or "make install" ... And all that > should be done before any tests get run. > > Simply typing "ctest" to execute all the tests never does any building. > The assumed workflow is that you build stuff first and then run the tests. > > If you want, you can add a custom target that runs a test, and make that > custom target depend on any other targets, but ctest still won't know about > it. Only "make custom_test_target" will... > > > D > > > > On Sunday, November 22, 2015, Nico Schl?mer > wrote: > >> Thanks for the hints! >> I'm almost there now, the only thing missing is to have my test depend on >> the custom_target. This >> ``` >> SET_TESTS_PROPERTIES(testname PROPERTIES DEPENDS convert) >> ``` >> doesn't do the trick: The target `convert` isn't executed before `ctest`. >> >> Any hints? >> >> Cheers, >> Nico >> >> >> On Sun, Nov 22, 2015 at 3:18 AM David Cole wrote: >> >>> Did you try using full path names for the add_custom_command file names? >>> >>> And the NAME/COMMAND form of the add_test command? >>> >>> Also, I've always found custom commands to work best when they're >>> associated with a target. And if it was part of a target you could make the >>> target depend on the external data target with add_dependencies if >>> necessary. >>> >>> >>> HTH, >>> David C. >>> >>> >>> On Saturday, November 21, 2015, Nico Schl?mer >>> wrote: >>> >>>> Hi everyone, >>>> >>>> I would like to create a CMake test that does the following: >>>> * Download a file from an external resource >>>> * Do something with the file >>>> * compile an executable myTest >>>> * execute myTest outputfile >>>> >>>> Using ExternalData for downloading the file works well, but the second >>>> step (file conversion, in this example cp for simplicity) does not work: >>>> ``` >>>> cmake_minimum_required(VERSION 3.2) >>>> >>>> project(mytest) >>>> >>>> # Download the files >>>> INCLUDE(ExternalData) >>>> set( >>>> ExternalData_URL_TEMPLATES >>>> "https://downloads.sourceforge.net/project/noshdata/%(algo)/%(hash)" >>>> ) >>>> ExternalData_Expand_Arguments( >>>> testFetchData >>>> OUT_DATA DATA{${CMAKE_SOURCE_DIR}/test.e} >>>> ) >>>> ExternalData_Add_Target(testFetchData) >>>> >>>> add_custom_command( >>>> OUTPUT test.g >>>> COMMAND cp test.e test.g >>>> DEPENDS test.e >>>> ) >>>> >>>> ADD_EXECUTABLE("myTest" main.cpp) >>>> >>>> add_test(myTest test.g) >>>> ``` >>>> I suppose I'm missing something about the dependencies here; after all, >>>> the `add_custom_command` has to wait for `testFetchData` to complete. >>>> Likewise, `add_test` has to wait for `add_custom_command` to complete. >>>> >>>> Hints appreciated. >>>> >>>> Cheers, >>>> Nico >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Sun Nov 22 14:58:07 2015 From: DLRdave at aol.com (David Cole) Date: Sun, 22 Nov 2015 14:58:07 -0500 Subject: [CMake] download file, modify, add test from it In-Reply-To: References: Message-ID: The DEPENDS property of a test is meant to ensure test running order in the case of parallel testing... It simply ensures that one test runs before another. It is not connected to the build system at all. It's different than target dependencies. D On Sunday, November 22, 2015, David Cole wrote: > What do you mean by "depend" in this case? All libs and exes should be > built during a "make" or "make all" or "make install" ... And all that > should be done before any tests get run. > > Simply typing "ctest" to execute all the tests never does any building. > The assumed workflow is that you build stuff first and then run the tests. > > If you want, you can add a custom target that runs a test, and make that > custom target depend on any other targets, but ctest still won't know about > it. Only "make custom_test_target" will... > > > D > > > > On Sunday, November 22, 2015, Nico Schl?mer > wrote: > >> Thanks for the hints! >> I'm almost there now, the only thing missing is to have my test depend on >> the custom_target. This >> ``` >> SET_TESTS_PROPERTIES(testname PROPERTIES DEPENDS convert) >> ``` >> doesn't do the trick: The target `convert` isn't executed before `ctest`. >> >> Any hints? >> >> Cheers, >> Nico >> >> >> On Sun, Nov 22, 2015 at 3:18 AM David Cole wrote: >> >>> Did you try using full path names for the add_custom_command file names? >>> >>> And the NAME/COMMAND form of the add_test command? >>> >>> Also, I've always found custom commands to work best when they're >>> associated with a target. And if it was part of a target you could make the >>> target depend on the external data target with add_dependencies if >>> necessary. >>> >>> >>> HTH, >>> David C. >>> >>> >>> On Saturday, November 21, 2015, Nico Schl?mer >>> wrote: >>> >>>> Hi everyone, >>>> >>>> I would like to create a CMake test that does the following: >>>> * Download a file from an external resource >>>> * Do something with the file >>>> * compile an executable myTest >>>> * execute myTest outputfile >>>> >>>> Using ExternalData for downloading the file works well, but the second >>>> step (file conversion, in this example cp for simplicity) does not work: >>>> ``` >>>> cmake_minimum_required(VERSION 3.2) >>>> >>>> project(mytest) >>>> >>>> # Download the files >>>> INCLUDE(ExternalData) >>>> set( >>>> ExternalData_URL_TEMPLATES >>>> "https://downloads.sourceforge.net/project/noshdata/%(algo)/%(hash)" >>>> ) >>>> ExternalData_Expand_Arguments( >>>> testFetchData >>>> OUT_DATA DATA{${CMAKE_SOURCE_DIR}/test.e} >>>> ) >>>> ExternalData_Add_Target(testFetchData) >>>> >>>> add_custom_command( >>>> OUTPUT test.g >>>> COMMAND cp test.e test.g >>>> DEPENDS test.e >>>> ) >>>> >>>> ADD_EXECUTABLE("myTest" main.cpp) >>>> >>>> add_test(myTest test.g) >>>> ``` >>>> I suppose I'm missing something about the dependencies here; after all, >>>> the `add_custom_command` has to wait for `testFetchData` to complete. >>>> Likewise, `add_test` has to wait for `add_custom_command` to complete. >>>> >>>> Hints appreciated. >>>> >>>> Cheers, >>>> Nico >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From nico.schloemer at gmail.com Sun Nov 22 15:07:19 2015 From: nico.schloemer at gmail.com (=?UTF-8?Q?Nico_Schl=C3=B6mer?=) Date: Sun, 22 Nov 2015 20:07:19 +0000 Subject: [CMake] download file, modify, add test from it In-Reply-To: References: Message-ID: Aha, this was a misunderstanding of me then. Thanks! How do I make a test depend on a target then? Cheers, Nico On Sun, Nov 22, 2015 at 8:58 PM David Cole wrote: > The DEPENDS property of a test is meant to ensure test running order in > the case of parallel testing... It simply ensures that one test runs before > another. It is not connected to the build system at all. It's different > than target dependencies. > > > D > > > > On Sunday, November 22, 2015, David Cole wrote: > >> What do you mean by "depend" in this case? All libs and exes should be >> built during a "make" or "make all" or "make install" ... And all that >> should be done before any tests get run. >> >> Simply typing "ctest" to execute all the tests never does any building. >> The assumed workflow is that you build stuff first and then run the tests. >> >> If you want, you can add a custom target that runs a test, and make that >> custom target depend on any other targets, but ctest still won't know about >> it. Only "make custom_test_target" will... >> >> >> D >> >> >> >> On Sunday, November 22, 2015, Nico Schl?mer >> wrote: >> >>> Thanks for the hints! >>> I'm almost there now, the only thing missing is to have my test depend >>> on the custom_target. This >>> ``` >>> SET_TESTS_PROPERTIES(testname PROPERTIES DEPENDS convert) >>> ``` >>> doesn't do the trick: The target `convert` isn't executed before `ctest`. >>> >>> Any hints? >>> >>> Cheers, >>> Nico >>> >>> >>> On Sun, Nov 22, 2015 at 3:18 AM David Cole wrote: >>> >>>> Did you try using full path names for the add_custom_command file names? >>>> >>>> And the NAME/COMMAND form of the add_test command? >>>> >>>> Also, I've always found custom commands to work best when they're >>>> associated with a target. And if it was part of a target you could make the >>>> target depend on the external data target with add_dependencies if >>>> necessary. >>>> >>>> >>>> HTH, >>>> David C. >>>> >>>> >>>> On Saturday, November 21, 2015, Nico Schl?mer >>>> wrote: >>>> >>>>> Hi everyone, >>>>> >>>>> I would like to create a CMake test that does the following: >>>>> * Download a file from an external resource >>>>> * Do something with the file >>>>> * compile an executable myTest >>>>> * execute myTest outputfile >>>>> >>>>> Using ExternalData for downloading the file works well, but the second >>>>> step (file conversion, in this example cp for simplicity) does not work: >>>>> ``` >>>>> cmake_minimum_required(VERSION 3.2) >>>>> >>>>> project(mytest) >>>>> >>>>> # Download the files >>>>> INCLUDE(ExternalData) >>>>> set( >>>>> ExternalData_URL_TEMPLATES >>>>> "https://downloads.sourceforge.net/project/noshdata/%(algo)/%(hash)" >>>>> ) >>>>> ExternalData_Expand_Arguments( >>>>> testFetchData >>>>> OUT_DATA DATA{${CMAKE_SOURCE_DIR}/test.e} >>>>> ) >>>>> ExternalData_Add_Target(testFetchData) >>>>> >>>>> add_custom_command( >>>>> OUTPUT test.g >>>>> COMMAND cp test.e test.g >>>>> DEPENDS test.e >>>>> ) >>>>> >>>>> ADD_EXECUTABLE("myTest" main.cpp) >>>>> >>>>> add_test(myTest test.g) >>>>> ``` >>>>> I suppose I'm missing something about the dependencies here; after >>>>> all, the `add_custom_command` has to wait for `testFetchData` to complete. >>>>> Likewise, `add_test` has to wait for `add_custom_command` to complete. >>>>> >>>>> Hints appreciated. >>>>> >>>>> Cheers, >>>>> Nico >>>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Sun Nov 22 17:53:05 2015 From: DLRdave at aol.com (David Cole) Date: Sun, 22 Nov 2015 17:53:05 -0500 Subject: [CMake] download file, modify, add test from it In-Reply-To: References: Message-ID: Use ALL to include your custom target in the default build of all. https://cmake.org/cmake/help/v3.4/command/add_custom_target.html D On Sunday, November 22, 2015, Nico Schl?mer wrote: > I was under the impression that if I don't explicitly build a target, it > won't get build. Perhaps I'm wrong here. In any case, this > ``` > add_custom_target(convert) > add_dependencies(convert testFetchData) > add_custom_command( > TARGET convert > COMMAND cp test.e test.g > ) > ``` > never gets executed on `make`, unlike all other targets (e.g., ` > testFetchData`). (Full CMakeLists.txt at [1].) Explicitly calling `make > convert` works alright. > > Any idea why that might be? > > Cheers, > Nico > > [1] http://chunk.io/f/729beeab41fb4a7385ceb98b31a2ea0a > > On Sun, Nov 22, 2015 at 8:46 PM David Cole > wrote: > >> What do you mean by "depend" in this case? All libs and exes should be >> built during a "make" or "make all" or "make install" ... And all that >> should be done before any tests get run. >> >> Simply typing "ctest" to execute all the tests never does any building. >> The assumed workflow is that you build stuff first and then run the tests. >> >> If you want, you can add a custom target that runs a test, and make that >> custom target depend on any other targets, but ctest still won't know about >> it. Only "make custom_test_target" will... >> >> >> D >> >> >> >> On Sunday, November 22, 2015, Nico Schl?mer > > wrote: >> >>> Thanks for the hints! >>> I'm almost there now, the only thing missing is to have my test depend >>> on the custom_target. This >>> ``` >>> SET_TESTS_PROPERTIES(testname PROPERTIES DEPENDS convert) >>> ``` >>> doesn't do the trick: The target `convert` isn't executed before `ctest`. >>> >>> Any hints? >>> >>> Cheers, >>> Nico >>> >>> >>> On Sun, Nov 22, 2015 at 3:18 AM David Cole wrote: >>> >>>> Did you try using full path names for the add_custom_command file names? >>>> >>>> And the NAME/COMMAND form of the add_test command? >>>> >>>> Also, I've always found custom commands to work best when they're >>>> associated with a target. And if it was part of a target you could make the >>>> target depend on the external data target with add_dependencies if >>>> necessary. >>>> >>>> >>>> HTH, >>>> David C. >>>> >>>> >>>> On Saturday, November 21, 2015, Nico Schl?mer >>>> wrote: >>>> >>>>> Hi everyone, >>>>> >>>>> I would like to create a CMake test that does the following: >>>>> * Download a file from an external resource >>>>> * Do something with the file >>>>> * compile an executable myTest >>>>> * execute myTest outputfile >>>>> >>>>> Using ExternalData for downloading the file works well, but the second >>>>> step (file conversion, in this example cp for simplicity) does not work: >>>>> ``` >>>>> cmake_minimum_required(VERSION 3.2) >>>>> >>>>> project(mytest) >>>>> >>>>> # Download the files >>>>> INCLUDE(ExternalData) >>>>> set( >>>>> ExternalData_URL_TEMPLATES >>>>> "https://downloads.sourceforge.net/project/noshdata/%(algo)/%(hash)" >>>>> ) >>>>> ExternalData_Expand_Arguments( >>>>> testFetchData >>>>> OUT_DATA DATA{${CMAKE_SOURCE_DIR}/test.e} >>>>> ) >>>>> ExternalData_Add_Target(testFetchData) >>>>> >>>>> add_custom_command( >>>>> OUTPUT test.g >>>>> COMMAND cp test.e test.g >>>>> DEPENDS test.e >>>>> ) >>>>> >>>>> ADD_EXECUTABLE("myTest" main.cpp) >>>>> >>>>> add_test(myTest test.g) >>>>> ``` >>>>> I suppose I'm missing something about the dependencies here; after >>>>> all, the `add_custom_command` has to wait for `testFetchData` to complete. >>>>> Likewise, `add_test` has to wait for `add_custom_command` to complete. >>>>> >>>>> Hints appreciated. >>>>> >>>>> Cheers, >>>>> Nico >>>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Sun Nov 22 17:59:00 2015 From: DLRdave at aol.com (David Cole) Date: Sun, 22 Nov 2015 17:59:00 -0500 Subject: [CMake] download file, modify, add test from it In-Reply-To: References: Message-ID: You don't. You just assume all relevant targets have already been built by the time you run the tests... There's no such thing as a test from an add_test call depending on a target. There **is** a dependency, of course, if you are using one of the build products in your test, but it's assumed that everything is already built at test time. There is not yet a notion of connecting certain tests to certain build targets. So, for example, there is no way to re-run only the tests affected by things which have changed since the last build, because there is no connection between targets and tests. People have artificially created such connections using test labels, and running subsets of tests by label, but there is no official dependency from tests back to targets. D On Sunday, November 22, 2015, Nico Schl?mer wrote: > Aha, this was a misunderstanding of me then. Thanks! > How do I make a test depend on a target then? > > Cheers, > Nico > > > On Sun, Nov 22, 2015 at 8:58 PM David Cole > wrote: > >> The DEPENDS property of a test is meant to ensure test running order in >> the case of parallel testing... It simply ensures that one test runs before >> another. It is not connected to the build system at all. It's different >> than target dependencies. >> >> >> D >> >> >> >> On Sunday, November 22, 2015, David Cole > > wrote: >> >>> What do you mean by "depend" in this case? All libs and exes should be >>> built during a "make" or "make all" or "make install" ... And all that >>> should be done before any tests get run. >>> >>> Simply typing "ctest" to execute all the tests never does any building. >>> The assumed workflow is that you build stuff first and then run the tests. >>> >>> If you want, you can add a custom target that runs a test, and make that >>> custom target depend on any other targets, but ctest still won't know about >>> it. Only "make custom_test_target" will... >>> >>> >>> D >>> >>> >>> >>> On Sunday, November 22, 2015, Nico Schl?mer >>> wrote: >>> >>>> Thanks for the hints! >>>> I'm almost there now, the only thing missing is to have my test depend >>>> on the custom_target. This >>>> ``` >>>> SET_TESTS_PROPERTIES(testname PROPERTIES DEPENDS convert) >>>> ``` >>>> doesn't do the trick: The target `convert` isn't executed before >>>> `ctest`. >>>> >>>> Any hints? >>>> >>>> Cheers, >>>> Nico >>>> >>>> >>>> On Sun, Nov 22, 2015 at 3:18 AM David Cole wrote: >>>> >>>>> Did you try using full path names for the add_custom_command file >>>>> names? >>>>> >>>>> And the NAME/COMMAND form of the add_test command? >>>>> >>>>> Also, I've always found custom commands to work best when they're >>>>> associated with a target. And if it was part of a target you could make the >>>>> target depend on the external data target with add_dependencies if >>>>> necessary. >>>>> >>>>> >>>>> HTH, >>>>> David C. >>>>> >>>>> >>>>> On Saturday, November 21, 2015, Nico Schl?mer < >>>>> nico.schloemer at gmail.com> wrote: >>>>> >>>>>> Hi everyone, >>>>>> >>>>>> I would like to create a CMake test that does the following: >>>>>> * Download a file from an external resource >>>>>> * Do something with the file >>>>>> * compile an executable myTest >>>>>> * execute myTest outputfile >>>>>> >>>>>> Using ExternalData for downloading the file works well, but the >>>>>> second step (file conversion, in this example cp for simplicity) does not >>>>>> work: >>>>>> ``` >>>>>> cmake_minimum_required(VERSION 3.2) >>>>>> >>>>>> project(mytest) >>>>>> >>>>>> # Download the files >>>>>> INCLUDE(ExternalData) >>>>>> set( >>>>>> ExternalData_URL_TEMPLATES >>>>>> "https://downloads.sourceforge.net/project/noshdata/%(algo)/%(hash) >>>>>> " >>>>>> ) >>>>>> ExternalData_Expand_Arguments( >>>>>> testFetchData >>>>>> OUT_DATA DATA{${CMAKE_SOURCE_DIR}/test.e} >>>>>> ) >>>>>> ExternalData_Add_Target(testFetchData) >>>>>> >>>>>> add_custom_command( >>>>>> OUTPUT test.g >>>>>> COMMAND cp test.e test.g >>>>>> DEPENDS test.e >>>>>> ) >>>>>> >>>>>> ADD_EXECUTABLE("myTest" main.cpp) >>>>>> >>>>>> add_test(myTest test.g) >>>>>> ``` >>>>>> I suppose I'm missing something about the dependencies here; after >>>>>> all, the `add_custom_command` has to wait for `testFetchData` to complete. >>>>>> Likewise, `add_test` has to wait for `add_custom_command` to complete. >>>>>> >>>>>> Hints appreciated. >>>>>> >>>>>> Cheers, >>>>>> Nico >>>>>> >>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikita.barawade at einfochips.com Mon Nov 23 01:53:15 2015 From: nikita.barawade at einfochips.com (Nikita Barawade) Date: Mon, 23 Nov 2015 06:53:15 +0000 Subject: [CMake] Cmake : undefined reference to `udev_device_get_devnode' In-Reply-To: <564F1A69.7010209@gmail.com> References: , <564F1A69.7010209@gmail.com> Message-ID: Hi Nils, Got It ! As per your suggestion, linked libudev to LLAPI target and rebuilt both LLAPI lib and App . No errors now . Thank you ! /Cmake/LLAPI/build$ ldd Source/libLLAPI.so linux-vdso.so.1 => (0x00007ffccff9c000) libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x00007fb8d2235000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fb8d202d000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fb8d1d29000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fb8d1b13000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb8d174e000) libcgmanager.so.0 => /lib/x86_64-linux-gnu/libcgmanager.so.0 (0x00007fb8d1533000) libnih.so.1 => /lib/x86_64-linux-gnu/libnih.so.1 (0x00007fb8d131b000) libnih-dbus.so.1 => /lib/x86_64-linux-gnu/libnih-dbus.so.1 (0x00007fb8d1111000) libdbus-1.so.3 => /lib/x86_64-linux-gnu/libdbus-1.so.3 (0x00007fb8d0ecc000) /lib64/ld-linux-x86-64.so.2 (0x00007fb8d2b6f000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fb8d0cae000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fb8d09a8000) Regards, Nikita Barawade Engineer | PES ________________________________ From: Nils Gladitz Sent: 20 November 2015 06:34 PM To: Nikita Barawade; cmake at cmake.org Subject: Re: [CMake] Cmake : undefined reference to `udev_device_get_devnode' On 11/20/2015 01:39 PM, Nikita Barawade wrote: ../../../LLAPI/build/Source/libLLAPI.so: undefined reference to `udev_device_get_devnode' Before this, while building a library libLLAPI.so I got error " fatal error: libudev.h: No such file or directory" . It worked fine after installing libudev-dev . These errors indicate that libLLAPI.so uses function from libudev but probably does not actually link to the library. Assuming it is missing you will need an appropriate target_link_libraries() call for your LLAPI target so that it links to libudev. Nils ************************************************************************************************************************************************************* eInfochips Business Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated. Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. ************************************************************************************************************************************************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: From nico.schloemer at gmail.com Mon Nov 23 04:14:27 2015 From: nico.schloemer at gmail.com (=?UTF-8?Q?Nico_Schl=C3=B6mer?=) Date: Mon, 23 Nov 2015 09:14:27 +0000 Subject: [CMake] download file, modify, add test from it In-Reply-To: References: Message-ID: Thanks David for your explanations. I've now reached a good solution: Fetch the data: ``` INCLUDE(ExternalData) set( ExternalData_URL_TEMPLATES "https://downloads.sourceforge.net/project/noshdata/%(algo)/%(hash)" ) foreach(file ${input_files}) ExternalData_Expand_Arguments( noshTestFetchData OUT_DATA DATA{${CMAKE_SOURCE_DIR}/test/data/${file}.e} ) endforeach() ExternalData_Add_Target(noshTestFetchData) ``` Define conversion commands: ``` foreach(file ${input_files}) LIST(APPEND FILES2 ${file}-2.h5m) add_custom_command( DEPENDS ${file}.e COMMAND convert ${file}.e ${file}.h5m OUTPUT ${file}.h5m ) endforeach() ``` Add a custom target with ALL: ``` add_custom_target(split2 ALL SOURCES ${FILES2} ) ``` Adding the output files to the SOURCES makes the target do what's its supposed to do. Cheers, Nico On Sun, Nov 22, 2015 at 11:59 PM David Cole wrote: > You don't. You just assume all relevant targets have already been built by > the time you run the tests... There's no such thing as a test from > an add_test call depending on a target. > > There **is** a dependency, of course, if you are using one of the build > products in your test, but it's assumed that everything is already built at > test time. > > There is not yet a notion of connecting certain tests to certain build > targets. > > So, for example, there is no way to re-run only the tests affected by > things which have changed since the last build, because there is no > connection between targets and tests. > > People have artificially created such connections using test labels, and > running subsets of tests by label, but there is no official dependency from > tests back to targets. > > > D > > > > On Sunday, November 22, 2015, Nico Schl?mer > wrote: > >> Aha, this was a misunderstanding of me then. Thanks! >> How do I make a test depend on a target then? >> >> Cheers, >> Nico >> >> >> On Sun, Nov 22, 2015 at 8:58 PM David Cole wrote: >> >>> The DEPENDS property of a test is meant to ensure test running order in >>> the case of parallel testing... It simply ensures that one test runs before >>> another. It is not connected to the build system at all. It's different >>> than target dependencies. >>> >>> >>> D >>> >>> >>> >>> On Sunday, November 22, 2015, David Cole wrote: >>> >>>> What do you mean by "depend" in this case? All libs and exes should be >>>> built during a "make" or "make all" or "make install" ... And all that >>>> should be done before any tests get run. >>>> >>>> Simply typing "ctest" to execute all the tests never does any building. >>>> The assumed workflow is that you build stuff first and then run the tests. >>>> >>>> If you want, you can add a custom target that runs a test, and make >>>> that custom target depend on any other targets, but ctest still won't know >>>> about it. Only "make custom_test_target" will... >>>> >>>> >>>> D >>>> >>>> >>>> >>>> On Sunday, November 22, 2015, Nico Schl?mer >>>> wrote: >>>> >>>>> Thanks for the hints! >>>>> I'm almost there now, the only thing missing is to have my test depend >>>>> on the custom_target. This >>>>> ``` >>>>> SET_TESTS_PROPERTIES(testname PROPERTIES DEPENDS convert) >>>>> ``` >>>>> doesn't do the trick: The target `convert` isn't executed before >>>>> `ctest`. >>>>> >>>>> Any hints? >>>>> >>>>> Cheers, >>>>> Nico >>>>> >>>>> >>>>> On Sun, Nov 22, 2015 at 3:18 AM David Cole wrote: >>>>> >>>>>> Did you try using full path names for the add_custom_command file >>>>>> names? >>>>>> >>>>>> And the NAME/COMMAND form of the add_test command? >>>>>> >>>>>> Also, I've always found custom commands to work best when they're >>>>>> associated with a target. And if it was part of a target you could make the >>>>>> target depend on the external data target with add_dependencies if >>>>>> necessary. >>>>>> >>>>>> >>>>>> HTH, >>>>>> David C. >>>>>> >>>>>> >>>>>> On Saturday, November 21, 2015, Nico Schl?mer < >>>>>> nico.schloemer at gmail.com> wrote: >>>>>> >>>>>>> Hi everyone, >>>>>>> >>>>>>> I would like to create a CMake test that does the following: >>>>>>> * Download a file from an external resource >>>>>>> * Do something with the file >>>>>>> * compile an executable myTest >>>>>>> * execute myTest outputfile >>>>>>> >>>>>>> Using ExternalData for downloading the file works well, but the >>>>>>> second step (file conversion, in this example cp for simplicity) does not >>>>>>> work: >>>>>>> ``` >>>>>>> cmake_minimum_required(VERSION 3.2) >>>>>>> >>>>>>> project(mytest) >>>>>>> >>>>>>> # Download the files >>>>>>> INCLUDE(ExternalData) >>>>>>> set( >>>>>>> ExternalData_URL_TEMPLATES >>>>>>> " >>>>>>> https://downloads.sourceforge.net/project/noshdata/%(algo)/%(hash)" >>>>>>> ) >>>>>>> ExternalData_Expand_Arguments( >>>>>>> testFetchData >>>>>>> OUT_DATA DATA{${CMAKE_SOURCE_DIR}/test.e} >>>>>>> ) >>>>>>> ExternalData_Add_Target(testFetchData) >>>>>>> >>>>>>> add_custom_command( >>>>>>> OUTPUT test.g >>>>>>> COMMAND cp test.e test.g >>>>>>> DEPENDS test.e >>>>>>> ) >>>>>>> >>>>>>> ADD_EXECUTABLE("myTest" main.cpp) >>>>>>> >>>>>>> add_test(myTest test.g) >>>>>>> ``` >>>>>>> I suppose I'm missing something about the dependencies here; after >>>>>>> all, the `add_custom_command` has to wait for `testFetchData` to complete. >>>>>>> Likewise, `add_test` has to wait for `add_custom_command` to complete. >>>>>>> >>>>>>> Hints appreciated. >>>>>>> >>>>>>> Cheers, >>>>>>> Nico >>>>>>> >>>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Mon Nov 23 06:45:49 2015 From: DLRdave at aol.com (David Cole) Date: Mon, 23 Nov 2015 06:45:49 -0500 Subject: [CMake] download file, modify, add test from it In-Reply-To: References: Message-ID: You're welcome. I see you have ${file}-2.h5m in only one place, though... Is that a leftover, or is the other reference to -2 just omitted from your example...? Cheers, David C. On Monday, November 23, 2015, Nico Schl?mer wrote: > Thanks David for your explanations. I've now reached a good solution: > > Fetch the data: > ``` > INCLUDE(ExternalData) > set( > ExternalData_URL_TEMPLATES > "https://downloads.sourceforge.net/project/noshdata/%(algo)/%(hash)" > ) > foreach(file ${input_files}) > ExternalData_Expand_Arguments( > noshTestFetchData > OUT_DATA DATA{${CMAKE_SOURCE_DIR}/test/data/${file}.e} > ) > endforeach() > ExternalData_Add_Target(noshTestFetchData) > ``` > Define conversion commands: > ``` > foreach(file ${input_files}) > LIST(APPEND FILES2 ${file}-2.h5m) > add_custom_command( > DEPENDS ${file}.e > COMMAND convert ${file}.e ${file}.h5m > OUTPUT ${file}.h5m > ) > endforeach() > ``` > Add a custom target with ALL: > ``` > add_custom_target(split2 ALL > SOURCES ${FILES2} > ) > ``` > Adding the output files to the SOURCES makes the target do what's its > supposed to do. > > Cheers, > Nico > > On Sun, Nov 22, 2015 at 11:59 PM David Cole > wrote: > >> You don't. You just assume all relevant targets have already been built >> by the time you run the tests... There's no such thing as a test from >> an add_test call depending on a target. >> >> There **is** a dependency, of course, if you are using one of the build >> products in your test, but it's assumed that everything is already built at >> test time. >> >> There is not yet a notion of connecting certain tests to certain build >> targets. >> >> So, for example, there is no way to re-run only the tests affected by >> things which have changed since the last build, because there is no >> connection between targets and tests. >> >> People have artificially created such connections using test labels, and >> running subsets of tests by label, but there is no official dependency from >> tests back to targets. >> >> >> D >> >> >> >> On Sunday, November 22, 2015, Nico Schl?mer > > wrote: >> >>> Aha, this was a misunderstanding of me then. Thanks! >>> How do I make a test depend on a target then? >>> >>> Cheers, >>> Nico >>> >>> >>> On Sun, Nov 22, 2015 at 8:58 PM David Cole wrote: >>> >>>> The DEPENDS property of a test is meant to ensure test running order in >>>> the case of parallel testing... It simply ensures that one test runs before >>>> another. It is not connected to the build system at all. It's different >>>> than target dependencies. >>>> >>>> >>>> D >>>> >>>> >>>> >>>> On Sunday, November 22, 2015, David Cole wrote: >>>> >>>>> What do you mean by "depend" in this case? All libs and exes should be >>>>> built during a "make" or "make all" or "make install" ... And all that >>>>> should be done before any tests get run. >>>>> >>>>> Simply typing "ctest" to execute all the tests never does any >>>>> building. The assumed workflow is that you build stuff first and then run >>>>> the tests. >>>>> >>>>> If you want, you can add a custom target that runs a test, and make >>>>> that custom target depend on any other targets, but ctest still won't know >>>>> about it. Only "make custom_test_target" will... >>>>> >>>>> >>>>> D >>>>> >>>>> >>>>> >>>>> On Sunday, November 22, 2015, Nico Schl?mer >>>>> wrote: >>>>> >>>>>> Thanks for the hints! >>>>>> I'm almost there now, the only thing missing is to have my test >>>>>> depend on the custom_target. This >>>>>> ``` >>>>>> SET_TESTS_PROPERTIES(testname PROPERTIES DEPENDS convert) >>>>>> ``` >>>>>> doesn't do the trick: The target `convert` isn't executed before >>>>>> `ctest`. >>>>>> >>>>>> Any hints? >>>>>> >>>>>> Cheers, >>>>>> Nico >>>>>> >>>>>> >>>>>> On Sun, Nov 22, 2015 at 3:18 AM David Cole wrote: >>>>>> >>>>>>> Did you try using full path names for the add_custom_command file >>>>>>> names? >>>>>>> >>>>>>> And the NAME/COMMAND form of the add_test command? >>>>>>> >>>>>>> Also, I've always found custom commands to work best when they're >>>>>>> associated with a target. And if it was part of a target you could make the >>>>>>> target depend on the external data target with add_dependencies if >>>>>>> necessary. >>>>>>> >>>>>>> >>>>>>> HTH, >>>>>>> David C. >>>>>>> >>>>>>> >>>>>>> On Saturday, November 21, 2015, Nico Schl?mer < >>>>>>> nico.schloemer at gmail.com> wrote: >>>>>>> >>>>>>>> Hi everyone, >>>>>>>> >>>>>>>> I would like to create a CMake test that does the following: >>>>>>>> * Download a file from an external resource >>>>>>>> * Do something with the file >>>>>>>> * compile an executable myTest >>>>>>>> * execute myTest outputfile >>>>>>>> >>>>>>>> Using ExternalData for downloading the file works well, but the >>>>>>>> second step (file conversion, in this example cp for simplicity) does not >>>>>>>> work: >>>>>>>> ``` >>>>>>>> cmake_minimum_required(VERSION 3.2) >>>>>>>> >>>>>>>> project(mytest) >>>>>>>> >>>>>>>> # Download the files >>>>>>>> INCLUDE(ExternalData) >>>>>>>> set( >>>>>>>> ExternalData_URL_TEMPLATES >>>>>>>> " >>>>>>>> https://downloads.sourceforge.net/project/noshdata/%(algo)/%(hash)" >>>>>>>> ) >>>>>>>> ExternalData_Expand_Arguments( >>>>>>>> testFetchData >>>>>>>> OUT_DATA DATA{${CMAKE_SOURCE_DIR}/test.e} >>>>>>>> ) >>>>>>>> ExternalData_Add_Target(testFetchData) >>>>>>>> >>>>>>>> add_custom_command( >>>>>>>> OUTPUT test.g >>>>>>>> COMMAND cp test.e test.g >>>>>>>> DEPENDS test.e >>>>>>>> ) >>>>>>>> >>>>>>>> ADD_EXECUTABLE("myTest" main.cpp) >>>>>>>> >>>>>>>> add_test(myTest test.g) >>>>>>>> ``` >>>>>>>> I suppose I'm missing something about the dependencies here; after >>>>>>>> all, the `add_custom_command` has to wait for `testFetchData` to complete. >>>>>>>> Likewise, `add_test` has to wait for `add_custom_command` to complete. >>>>>>>> >>>>>>>> Hints appreciated. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Nico >>>>>>>> >>>>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From nico.schloemer at gmail.com Mon Nov 23 06:48:53 2015 From: nico.schloemer at gmail.com (=?UTF-8?Q?Nico_Schl=C3=B6mer?=) Date: Mon, 23 Nov 2015 11:48:53 +0000 Subject: [CMake] download file, modify, add test from it In-Reply-To: References: Message-ID: > Is that a leftover, or is the other reference to -2 just omitted from your example...? That's a leftover indeed. :) --Nico On Mon, Nov 23, 2015 at 12:45 PM David Cole wrote: > You're welcome. > > I see you have ${file}-2.h5m in only one place, though... Is that a > leftover, or is the other reference to -2 just omitted from your example...? > > > Cheers, > David C. > > > > On Monday, November 23, 2015, Nico Schl?mer > wrote: > >> Thanks David for your explanations. I've now reached a good solution: >> >> Fetch the data: >> ``` >> INCLUDE(ExternalData) >> set( >> ExternalData_URL_TEMPLATES >> "https://downloads.sourceforge.net/project/noshdata/%(algo)/%(hash)" >> ) >> foreach(file ${input_files}) >> ExternalData_Expand_Arguments( >> noshTestFetchData >> OUT_DATA DATA{${CMAKE_SOURCE_DIR}/test/data/${file}.e} >> ) >> endforeach() >> ExternalData_Add_Target(noshTestFetchData) >> ``` >> Define conversion commands: >> ``` >> foreach(file ${input_files}) >> LIST(APPEND FILES2 ${file}-2.h5m) >> add_custom_command( >> DEPENDS ${file}.e >> COMMAND convert ${file}.e ${file}.h5m >> OUTPUT ${file}.h5m >> ) >> endforeach() >> ``` >> Add a custom target with ALL: >> ``` >> add_custom_target(split2 ALL >> SOURCES ${FILES2} >> ) >> ``` >> Adding the output files to the SOURCES makes the target do what's its >> supposed to do. >> >> Cheers, >> Nico >> >> On Sun, Nov 22, 2015 at 11:59 PM David Cole wrote: >> >>> You don't. You just assume all relevant targets have already been built >>> by the time you run the tests... There's no such thing as a test from >>> an add_test call depending on a target. >>> >>> There **is** a dependency, of course, if you are using one of the build >>> products in your test, but it's assumed that everything is already built at >>> test time. >>> >>> There is not yet a notion of connecting certain tests to certain build >>> targets. >>> >>> So, for example, there is no way to re-run only the tests affected by >>> things which have changed since the last build, because there is no >>> connection between targets and tests. >>> >>> People have artificially created such connections using test labels, and >>> running subsets of tests by label, but there is no official dependency from >>> tests back to targets. >>> >>> >>> D >>> >>> >>> >>> On Sunday, November 22, 2015, Nico Schl?mer >>> wrote: >>> >>>> Aha, this was a misunderstanding of me then. Thanks! >>>> How do I make a test depend on a target then? >>>> >>>> Cheers, >>>> Nico >>>> >>>> >>>> On Sun, Nov 22, 2015 at 8:58 PM David Cole wrote: >>>> >>>>> The DEPENDS property of a test is meant to ensure test running order >>>>> in the case of parallel testing... It simply ensures that one test runs >>>>> before another. It is not connected to the build system at all. It's >>>>> different than target dependencies. >>>>> >>>>> >>>>> D >>>>> >>>>> >>>>> >>>>> On Sunday, November 22, 2015, David Cole wrote: >>>>> >>>>>> What do you mean by "depend" in this case? All libs and exes should >>>>>> be built during a "make" or "make all" or "make install" ... And all that >>>>>> should be done before any tests get run. >>>>>> >>>>>> Simply typing "ctest" to execute all the tests never does any >>>>>> building. The assumed workflow is that you build stuff first and then run >>>>>> the tests. >>>>>> >>>>>> If you want, you can add a custom target that runs a test, and make >>>>>> that custom target depend on any other targets, but ctest still won't know >>>>>> about it. Only "make custom_test_target" will... >>>>>> >>>>>> >>>>>> D >>>>>> >>>>>> >>>>>> >>>>>> On Sunday, November 22, 2015, Nico Schl?mer >>>>>> wrote: >>>>>> >>>>>>> Thanks for the hints! >>>>>>> I'm almost there now, the only thing missing is to have my test >>>>>>> depend on the custom_target. This >>>>>>> ``` >>>>>>> SET_TESTS_PROPERTIES(testname PROPERTIES DEPENDS convert) >>>>>>> ``` >>>>>>> doesn't do the trick: The target `convert` isn't executed before >>>>>>> `ctest`. >>>>>>> >>>>>>> Any hints? >>>>>>> >>>>>>> Cheers, >>>>>>> Nico >>>>>>> >>>>>>> >>>>>>> On Sun, Nov 22, 2015 at 3:18 AM David Cole wrote: >>>>>>> >>>>>>>> Did you try using full path names for the add_custom_command file >>>>>>>> names? >>>>>>>> >>>>>>>> And the NAME/COMMAND form of the add_test command? >>>>>>>> >>>>>>>> Also, I've always found custom commands to work best when they're >>>>>>>> associated with a target. And if it was part of a target you could make the >>>>>>>> target depend on the external data target with add_dependencies if >>>>>>>> necessary. >>>>>>>> >>>>>>>> >>>>>>>> HTH, >>>>>>>> David C. >>>>>>>> >>>>>>>> >>>>>>>> On Saturday, November 21, 2015, Nico Schl?mer < >>>>>>>> nico.schloemer at gmail.com> wrote: >>>>>>>> >>>>>>>>> Hi everyone, >>>>>>>>> >>>>>>>>> I would like to create a CMake test that does the following: >>>>>>>>> * Download a file from an external resource >>>>>>>>> * Do something with the file >>>>>>>>> * compile an executable myTest >>>>>>>>> * execute myTest outputfile >>>>>>>>> >>>>>>>>> Using ExternalData for downloading the file works well, but the >>>>>>>>> second step (file conversion, in this example cp for simplicity) does not >>>>>>>>> work: >>>>>>>>> ``` >>>>>>>>> cmake_minimum_required(VERSION 3.2) >>>>>>>>> >>>>>>>>> project(mytest) >>>>>>>>> >>>>>>>>> # Download the files >>>>>>>>> INCLUDE(ExternalData) >>>>>>>>> set( >>>>>>>>> ExternalData_URL_TEMPLATES >>>>>>>>> " >>>>>>>>> https://downloads.sourceforge.net/project/noshdata/%(algo)/%(hash) >>>>>>>>> " >>>>>>>>> ) >>>>>>>>> ExternalData_Expand_Arguments( >>>>>>>>> testFetchData >>>>>>>>> OUT_DATA DATA{${CMAKE_SOURCE_DIR}/test.e} >>>>>>>>> ) >>>>>>>>> ExternalData_Add_Target(testFetchData) >>>>>>>>> >>>>>>>>> add_custom_command( >>>>>>>>> OUTPUT test.g >>>>>>>>> COMMAND cp test.e test.g >>>>>>>>> DEPENDS test.e >>>>>>>>> ) >>>>>>>>> >>>>>>>>> ADD_EXECUTABLE("myTest" main.cpp) >>>>>>>>> >>>>>>>>> add_test(myTest test.g) >>>>>>>>> ``` >>>>>>>>> I suppose I'm missing something about the dependencies here; after >>>>>>>>> all, the `add_custom_command` has to wait for `testFetchData` to complete. >>>>>>>>> Likewise, `add_test` has to wait for `add_custom_command` to complete. >>>>>>>>> >>>>>>>>> Hints appreciated. >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Nico >>>>>>>>> >>>>>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitrii.golub at gmail.com Mon Nov 23 18:38:48 2015 From: dmitrii.golub at gmail.com (Dmitrii Golub) Date: Tue, 24 Nov 2015 02:38:48 +0300 Subject: [CMake] xmlsec1 with cmake problem Message-ID: Hello, 2 folders: src/bin/cft.c <- cft target src/cft/signature.c and src/cft/ssl.c <- libcft target So libcft target: pkg_search_module(XMLSEC REQUIRED xmlsec1) include_directories(${XMLSEC_INCLUDE_DIRS}) add_library(libcft signature.c ssl.c) target_link_libraries(libcft ${XMLSEC_LIBRARIES}) target_compile_definitions(libcft PUBLIC ${XMLSEC_CFLAGS_OTHER}) Not cft target version 1: add_executable(cft cft.c) target_link_libraries(cft libcft) I have to say, that XMLSEC_CFLAGS_OTHER is bunch of definitions: -DXMLSEC_CRYPTO=\"openssl\" -DXMLSEC_CRYPTO_DYNAMIC_LOADING=1 -D__XMLSEC_FUNCTION__=__FUNCTION__ -DXMLSEC_NO_SIZE_T -DXMLSEC_NO_GOST=1 -DXMLSEC_NO_GOST2012=1 -DXMLSEC_DL_LIBLTDL=1 With cft target version 1 cmake doesnt use this definitions, So I got error: Linking C executable ../../bin/cft cd /mili/cp-proxy/src/bin && /usr/bin/cmake -E cmake_link_script CMakeFiles/cft.dir/link.txt --verbose=1 /usr/bin/cc CMakeFiles/cft.dir/cft.c.o -o ../../bin/cft -rdynamic ../cft/liblibcft.a -lcurl -lxmlsec1 -lltdl -lxslt -lxml2 -lssl -lcrypto /usr/local/lib/libxmlsec1.so ../lib/libBASE64.a -Wl,-rpath,/usr/local/lib ../cft/liblibcft.a(signature.c.o): In function `cft_utils_init': signature.c:(.text+0xac1): undefined reference to `xmlSecCryptoDLLoadLibrary' So here come cft target version 2: pkg_search_module(XMLSEC REQUIRED xmlsec1) add_executable(cft cft.c) target_compile_definitions(cft PUBLIC ${XMLSEC_CFLAGS_OTHER}) <-- main line here target_link_libraries(cft libcft) Again: Linking C executable ../../bin/cft cd /mili/cp-proxy/src/bin && /usr/bin/cmake -E cmake_link_script CMakeFiles/cft.dir/link.txt --verbose=1 /usr/bin/cc CMakeFiles/cft.dir/cft.c.o -o ../../bin/cft -rdynamic ../cft/liblibcft.a -lcurl -lxmlsec1 -lltdl -lxslt -lxml2 -lssl -lcrypto /usr/local/lib/libxmlsec1.so ../lib/libBASE64.a -Wl,-rpath,/usr/local/lib ../cft/liblibcft.a(signature.c.o): In function `cft_utils_init': signature.c:(.text+0xac1): undefined reference to `xmlSecCryptoDLLoadLibrary' cft version 3 I tried to add add_definition by hand, but no succes, cmake doesn't use these definitions for cft target. Any ideas how to compile that with xmlsec definitions? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From brlcad at mac.com Tue Nov 24 00:04:56 2015 From: brlcad at mac.com (Christopher Sean Morrison) Date: Tue, 24 Nov 2015 00:04:56 -0500 Subject: [CMake] print a message during a specific build target Message-ID: <13FCFD29-DBC8-4E1C-A5D8-0778E0ACA3C3@mac.com> Hi, I?m trying to print a message for a particular build target and am a bit stuck. I found that the IF statement has a TARGET keyword that should truthfully match for a particular build target, but it doesn?t seem to be working at least the way I?m trying to use it and would expect it to work. Snippet in question in a top-level CMakeLists.txt file looks like this: if (TARGET check) message(?special note about CHECK target??) elseif (TARGET test) message(?different note about TEST target??) endif (TARGET check) Now what happens is that the CHECK message is printed ? during cmake(!). What I?m trying to achieve is only have those messages printed during? ?make check? and ?make test?, etc. Ideally, I want to be able to inject a message before any target actions are taken and possibly after. I see in the docs that I can set COMMENT during add_custom_target(check ?) and that should print my message before any target actions, but how can I get a similar message printed during ?test? or ?all? or some other implicit target? Is there a better or more general way? Thanks for your assistance. Cheers! Sean From dmitrii.golub at gmail.com Tue Nov 24 04:50:00 2015 From: dmitrii.golub at gmail.com (Dmitrii Golub) Date: Tue, 24 Nov 2015 12:50:00 +0300 Subject: [CMake] xmlsec1 with cmake problem In-Reply-To: References: Message-ID: I found answer to this question, just forgot to target_link_libraries(libcft -L/usr/local/lib) 2015-11-24 2:38 GMT+03:00 Dmitrii Golub : > Hello, > > 2 folders: > src/bin/cft.c <- cft target > src/cft/signature.c and src/cft/ssl.c <- libcft target > > So libcft target: > > pkg_search_module(XMLSEC REQUIRED xmlsec1) > include_directories(${XMLSEC_INCLUDE_DIRS}) > > add_library(libcft signature.c ssl.c) > target_link_libraries(libcft ${XMLSEC_LIBRARIES}) > target_compile_definitions(libcft PUBLIC ${XMLSEC_CFLAGS_OTHER}) > > Not cft target version 1: > add_executable(cft cft.c) > target_link_libraries(cft libcft) > > > I have to say, that XMLSEC_CFLAGS_OTHER is bunch of definitions: > -DXMLSEC_CRYPTO=\"openssl\" -DXMLSEC_CRYPTO_DYNAMIC_LOADING=1 > -D__XMLSEC_FUNCTION__=__FUNCTION__ -DXMLSEC_NO_SIZE_T -DXMLSEC_NO_GOST=1 > -DXMLSEC_NO_GOST2012=1 -DXMLSEC_DL_LIBLTDL=1 > > With cft target version 1 cmake doesnt use this definitions, So I got > error: > > Linking C executable ../../bin/cft > cd /mili/cp-proxy/src/bin && /usr/bin/cmake -E cmake_link_script > CMakeFiles/cft.dir/link.txt --verbose=1 > /usr/bin/cc CMakeFiles/cft.dir/cft.c.o -o ../../bin/cft -rdynamic > ../cft/liblibcft.a -lcurl -lxmlsec1 -lltdl -lxslt -lxml2 -lssl -lcrypto > /usr/local/lib/libxmlsec1.so ../lib/libBASE64.a -Wl,-rpath,/usr/local/lib > ../cft/liblibcft.a(signature.c.o): In function `cft_utils_init': > signature.c:(.text+0xac1): undefined reference to > `xmlSecCryptoDLLoadLibrary' > > So here come cft target version 2: > > pkg_search_module(XMLSEC REQUIRED xmlsec1) > add_executable(cft cft.c) > target_compile_definitions(cft PUBLIC ${XMLSEC_CFLAGS_OTHER}) <-- main > line here > target_link_libraries(cft libcft) > > Again: > > Linking C executable ../../bin/cft > cd /mili/cp-proxy/src/bin && /usr/bin/cmake -E cmake_link_script > CMakeFiles/cft.dir/link.txt --verbose=1 > /usr/bin/cc CMakeFiles/cft.dir/cft.c.o -o ../../bin/cft -rdynamic > ../cft/liblibcft.a -lcurl -lxmlsec1 -lltdl -lxslt -lxml2 -lssl -lcrypto > /usr/local/lib/libxmlsec1.so ../lib/libBASE64.a -Wl,-rpath,/usr/local/lib > ../cft/liblibcft.a(signature.c.o): In function `cft_utils_init': > signature.c:(.text+0xac1): undefined reference to > `xmlSecCryptoDLLoadLibrary' > > cft version 3 > I tried to add add_definition by hand, but no succes, cmake doesn't use > these definitions for cft target. > > Any ideas how to compile that with xmlsec definitions? > > Thanks > -------------- next part -------------- An HTML attachment was scrubbed... URL: From parag at ionicsecurity.com Tue Nov 24 07:44:06 2015 From: parag at ionicsecurity.com (Parag Chandra) Date: Tue, 24 Nov 2015 12:44:06 +0000 Subject: [CMake] print a message during a specific build target In-Reply-To: <13FCFD29-DBC8-4E1C-A5D8-0778E0ACA3C3@mac.com> References: <13FCFD29-DBC8-4E1C-A5D8-0778E0ACA3C3@mac.com> Message-ID: The if() statements are executed when CMake runs, because you?re basically adding logic to the ?meta-build? process that generates your build system; not the build system itself. Maybe you can use ?add_custom_target? to create targets which do nothing but print the desired message, and then use ?add_dependencies? to tie these targets back to your original ones? So something like: add_custom_target(?test_print? ?) add_dependencies(test test_print) Parag Chandra Senior Software Engineer, Mobile Team Mobile: +1.919.824.1410 Ionic Security Inc. 1170 Peachtree St. NE STE 400, Atlanta, GA 30309 On 11/24/15, 12:04 AM, "CMake on behalf of Christopher Sean Morrison" wrote: > >Hi, > >I?m trying to print a message for a particular build target and am a bit stuck. I found that the IF statement has a TARGET keyword that should truthfully match for a particular build target, but it doesn?t seem to be working at least the way I?m trying to use it and would expect it to work. Snippet in question in a top-level CMakeLists.txt file looks like this: > >if (TARGET check) > message(?special note about CHECK target??) >elseif (TARGET test) > message(?different note about TEST target??) >endif (TARGET check) > >Now what happens is that the CHECK message is printed ? during cmake(!). What I?m trying to achieve is only have those messages printed during? ?make check? and ?make test?, etc. Ideally, I want to be able to inject a message before any target actions are taken and possibly after. > >I see in the docs that I can set COMMENT during add_custom_target(check ?) and that should print my message before any target actions, but how can I get a similar message printed during ?test? or ?all? or some other implicit target? Is there a better or more general way? Thanks for your assistance. > >Cheers! >Sean > >-- > >Powered by www.kitware.com > >Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > >Kitware offers various services to support the CMake community. For more information on each offering, please visit: > >CMake Support: http://cmake.org/cmake/help/support.html >CMake Consulting: http://cmake.org/cmake/help/consulting.html >CMake Training Courses: http://cmake.org/cmake/help/training.html > >Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > >Follow this link to subscribe/unsubscribe: >http://public.kitware.com/mailman/listinfo/cmake From robert.bielik at dirac.se Tue Nov 24 09:16:53 2015 From: robert.bielik at dirac.se (Robert Bielik) Date: Tue, 24 Nov 2015 15:16:53 +0100 Subject: [CMake] Kernel driver Windows Message-ID: <56547155.8040706@dirac.se> I'd like to incorporate our Kernel driver (.sys) into our CMake build system. Has anyone done such a thing ? There are quite a few settings in VS2013 that are "special" when doing kernel mode drivers with WDK... Regards /R From jay.custin at hpe.com Tue Nov 24 13:17:32 2015 From: jay.custin at hpe.com (Custin, Jay (CSC Sw Middleware)) Date: Tue, 24 Nov 2015 18:17:32 +0000 Subject: [CMake] Observation regarding Utilities/cmliblzma/CMakeLists.txt Message-ID: After some rather extensive banging of my head on my desk trying to resolve a variable definition issue I finally tracked it down to the Utilities/cmliblzma/CMakeLists.txt file. Line 26 contains the following statement: CHECK_INCLUDE_FILE(inttypes.h HAVE_INTTYPES_H) Absolutely nothing wrong with this EXCEPT while it CHECKS for that header file... it appears that this file never actually INCLUDES the header file later (beginning at line 79) when it starts to check type and size of data types: CHECK_TYPE_SIZE(int16_t INT16_T) After some digging in the documentation I spotted this in the list of variables which can get set before calling this macro: CMAKE_EXTRA_INCLUDE_FILES = list of extra headers to include Ultimately I worked around the compiler errors by adding the following inside a test for the OpenVMS operating system: if( (CMAKE_CXX_PLATFORM_ID MATCHES "OpenVMS") AND HAVE_INTTYPES_H ) SET( CMAKE_EXTRA_INCLUDE_FILES "inttypes.h" ) endif() It seems odd to me that someone would have to do this since the CMake build procedure had already gone painstaking tests to generate the ABI.h and INT.h header files for the operating system and in so doing had already identified the available/necessary data types. /SenseiC bows out -------------- next part -------------- An HTML attachment was scrubbed... URL: From grigore.silviu.catalin at gmail.com Tue Nov 24 13:48:17 2015 From: grigore.silviu.catalin at gmail.com (=?UTF-8?B?R3JpZ29yZSBTaWx2aXUgQ8SDdMSDbGlu?=) Date: Tue, 24 Nov 2015 20:48:17 +0200 Subject: [CMake] Visual Studio 2015 solution issue Message-ID: Hello, I am using cmake 3.4.0 to generate Visual Studio 2015 solution and projects for LLVM 3.6. I managed to generate the solution and build it, but I am not able to debug the executable files in Visual Studio. It seems that even on Debug configuration, C/C++>Optimization>Optimization is set to "Maximize speed(/O2)" and Linker>Debugging>Generate Debug Info is set to "false". I use Visual Studio 2015 Community edition on Windows 10 Professional. Any ideas where the problem may be? Thanks and regards, Silviu -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.stuermer at schaeffler.com Wed Nov 25 07:30:40 2015 From: michael.stuermer at schaeffler.com (Stuermer, Michael SP/HZA-ZSEP) Date: Wed, 25 Nov 2015 12:30:40 +0000 Subject: [CMake] avoid permanent rebuild of custom_target Message-ID: <4797EDAAB4843944A70CA99A7DE7D8BD06B55F81@DE012432.schaeffler.com> How can I avoid a custom target to be rebuild everytime I build my solution? I added my target like this: add_custom_target(CopyNugetPackages DEPENDS ${depends_list} COMMENT "======== copying nuget packages ========" VERBATIM ) set_target_properties(CopyNugetPackages PROPERTIES EXCLUDE_FROM_ALL TRUE FOLDER "CMakePredefinedTargets") The variable "depends_list" contains a list of custom_command outputs (essentially .dll files which are copied). All the custom commands are actually only executed once, but the custom target "CopyNugetPackages" is run over and over again. I would like to run "CopyNugetPackages" only as a dependency from other targets: add_dependencies(${target} CopyNugetPackages) So "CopyNugetPackages" should only be built if ${target} is built. How can I do this or is it impossible? Best Regards Michael St?rmer SP/HZA-ZSEP Postcode HZA 13-4-06 SZ.Prozessdatenverarbeitung Schaeffler Technologies AG & Co. KG Industriestra?e 1-3 91074 Herzogenaurach (Germany) Tel. +49 91 32 / 82 - 86350 ? Fax +49 91 32 / 82 - 45 86350 Mobil.: +49 171 6860010 mailto:michael.stuermer at schaeffler.com ? http://www.ina.de Registered Seat: Herzogenaurach Commercial Register: AG F?rth HRA 9349 General Partner: INA Beteiligungsgesellschaft mit beschr?nkter Haftung Registered Seat: Herzogenaurach (Germany) Commercial Register: AG F?rth HRB 2379 Managing Directors: Klaus Rosenfeld (CEO), Prof. Dr. Peter Gutzmer, Norbert Indlekofer, Oliver Jung, Kurt Mirlach, Prof. Dr. Peter Pleus, Robert Schullan This e-mail message is intended only for the use of the named recipient-(s) and contains information which may be confidential or privileged. If you are not the intended recipient, be aware that any distribution, or use of the contents of this information is prohibited. If you have received this electronic transmission in error, please notify the sender and delete the material from the computer. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at classdesign.com Wed Nov 25 18:01:05 2015 From: bill at classdesign.com (Bill Somerville) Date: Wed, 25 Nov 2015 23:01:05 +0000 Subject: [CMake] CPack: Debian package will not install on Linix-ppc Message-ID: <56563DB1.9060607@classdesign.com> Hi All, we are trying to get our Debian install package to install on a Linux PowerPC system running $ sudo dpkg -i wsjtx-prefix/build/wsjtx_1.6.0-rc2_powerpc.deb [sudo] password for g0oan: (Reading database ... 281162 files and directories currently installed.) Preparing to unpack .../wsjtx_1.6.0-rc2_powerpc.deb ... Unpacking wsjtx (1.6.0-rc2) ... dpkg: error processing archive wsjtx-prefix/build/wsjtx_1.6.0-rc2_powerpc.deb (--install): corrupted filesystem tarfile - corrupted package archive dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) Processing triggers for man-db (2.7.4-1) ... Processing triggers for desktop-file-utils (0.22-1ubuntu3) ... Processing triggers for bamfdaemon (0.5.2~bzr0+15.10.20150627.1-0ubuntu1) ... Rebuilding /usr/share/applications/bamf-2.index... Processing triggers for mime-support (3.58ubuntu1) ... Errors were encountered while processing: wsjtx-prefix/build/wsjtx_1.6.0-rc2_powerpc.deb The system is Ubuntu Mate 15.10 on a G5 IMac and the package was built on the same system. CMake script is here: https://sourceforge.net/p/wsjt/wsjt/HEAD/tree/branches/wsjtx-1.6/CMakeLists.txt I think the error is bogus because the package unpacks into a specified directory using 'dpkg -x ' or 'dpkg -X ' just fine. Any Ideas? Regards Bill. From doctorwhoguy at gmail.com Thu Nov 26 00:57:41 2015 From: doctorwhoguy at gmail.com (Patrick McMunn) Date: Wed, 25 Nov 2015 23:57:41 -0600 Subject: [CMake] cmake can't find non-readable programs: bug #10468 Message-ID: Bug number 10468 was opened over 5 & 1/2 years ago, and it is still causing downstream issues (see Gentoo bug 486270). Is there a developer who will take a look at this old bug and address it? -------------- next part -------------- An HTML attachment was scrubbed... URL: From tino.mettler at alcnetworx.de Thu Nov 26 03:18:16 2015 From: tino.mettler at alcnetworx.de (Tino Mettler) Date: Thu, 26 Nov 2015 09:18:16 +0100 Subject: [CMake] CPack: Debian package will not install on Linix-ppc In-Reply-To: <56563DB1.9060607@classdesign.com> References: <56563DB1.9060607@classdesign.com> Message-ID: <1448525896.4104.62.camel@alcnetworx.de> On Wed, 2015-11-25 at 23:01 +0000, Bill Somerville wrote: > CMake script is here: > > https://sourceforge.net/p/wsjt/wsjt/HEAD/tree/branches/wsjtx-1.6/CMakeLists.txt I don't know if this is related, but here seems to be a typo: set (CPACK_DEBIAN_PACKAGE_PACKAGE_SHLIBDEPS ON) I think the "PACKAGE_PACKAGE" should be only "PACKAGE". Regards, Tino From bill at classdesign.com Thu Nov 26 08:55:01 2015 From: bill at classdesign.com (Bill Somerville) Date: Thu, 26 Nov 2015 13:55:01 +0000 Subject: [CMake] CPack: Debian package will not install on Linix-ppc In-Reply-To: <1448525896.4104.62.camel@alcnetworx.de> References: <56563DB1.9060607@classdesign.com> <1448525896.4104.62.camel@alcnetworx.de> Message-ID: <56570F35.5000006@classdesign.com> On 26/11/2015 08:18, Tino Mettler wrote: > I don't know if this is related, but here seems to be a typo: > > set (CPACK_DEBIAN_PACKAGE_PACKAGE_SHLIBDEPS ON) > > I think the "PACKAGE_PACKAGE" should be only "PACKAGE". Hi Tino, thanks for looking at this and for spotting that typo. We don't currently package any libraries so it was benign but wrong nevertheless. Unfortunately it didn't help with the original problem :( 73 Bill G4WJS. From dzenan.zukic at kitware.com Thu Nov 26 11:48:25 2015 From: dzenan.zukic at kitware.com (Dzenan Zukic) Date: Thu, 26 Nov 2015 11:48:25 -0500 Subject: [CMake] MSVC version string Message-ID: Hi everybody, is there a way to get MSVC's version string (for the current generator) in form 12.0 for VS2013 as per this page ? Or is my best bet big if/else of the style: if (MSVC_VERSION EQUAL 1800) set(boost_toolset "msvc-12.0") elseif(MSVC_VERSION EQUAL 1900) set(boost_toolset "msvc-14.0") ... Regards, D?enan Zuki?, R&D Engineer, Kitware (Carrboro, N.C.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From scott at towel42.com Thu Nov 26 12:24:44 2015 From: scott at towel42.com (Scott Aron Bloom) Date: Thu, 26 Nov 2015 17:24:44 +0000 Subject: [CMake] MSVC version string In-Reply-To: References: Message-ID: I wound up doing exactly what you started?. From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Dzenan Zukic Sent: Thursday, November 26, 2015 8:48 AM To: CMake users Subject: [CMake] MSVC version string Hi everybody, is there a way to get MSVC's version string (for the current generator) in form 12.0 for VS2013 as per this page? Or is my best bet big if/else of the style: if (MSVC_VERSION EQUAL 1800) set(boost_toolset "msvc-12.0") elseif(MSVC_VERSION EQUAL 1900) set(boost_toolset "msvc-14.0") ... Regards, D?enan Zuki?, R&D Engineer, Kitware (Carrboro, N.C.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From domen.vrankar at gmail.com Fri Nov 27 03:05:34 2015 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Fri, 27 Nov 2015 09:05:34 +0100 Subject: [CMake] CPack: Debian package will not install on Linix-ppc In-Reply-To: <56563DB1.9060607@classdesign.com> References: <56563DB1.9060607@classdesign.com> Message-ID: 2015-11-26 0:01 GMT+01:00 Bill Somerville : > Hi All, > > we are trying to get our Debian install package to install on a Linux > PowerPC system running Which version of CMake have you tried? Version 3.4.0 had some changes regarding how DEB packages are packaged (libarchive instead of system tar) so try to see if that version works for you. > The system is Ubuntu Mate 15.10 on a G5 IMac and the package was built on > the same system. > > CMake script is here: > > https://sourceforge.net/p/wsjt/wsjt/HEAD/tree/branches/wsjtx-1.6/CMakeLists.txt Try to create a simple package first and see if the error still occurs and then go from there. Something like: cmake_minimum_required(VERSION 3.4 FATAL_ERROR) set(CPACK_PACKAGE_CONTACT "someone") install(FILES CMakeLists.txt DESTINATION foo COMPONENT test) set(CPACK_PACKAGE_NAME "minimal") set(CPACK_GENERATOR "DEB") include(CPack) Regards, Domen From dumont.guillaume at gmail.com Fri Nov 27 10:18:31 2015 From: dumont.guillaume at gmail.com (Guillaume Dumont) Date: Fri, 27 Nov 2015 10:18:31 -0500 Subject: [CMake] MSVC version string In-Reply-To: References: Message-ID: You can also emulate a map like so: set(boost_toolset_1800 "msvc-12.0") set(boost_toolset_1900 "msvc-14.0") set(boost_toolset ${boost_toolset_${MSVC_VERSION}}) It's probably best to add some check on MSVC_VERSION since the set statement will silently set the boost_toolset variable to nothing if your "map" is missing the entry for a particular MSVC_VERSION. HTH On Thu, Nov 26, 2015 at 12:24 PM, Scott Aron Bloom wrote: > I wound up doing exactly what you started?. > > > > *From:* CMake [mailto:cmake-bounces at cmake.org] *On Behalf Of *Dzenan Zukic > *Sent:* Thursday, November 26, 2015 8:48 AM > *To:* CMake users > *Subject:* [CMake] MSVC version string > > > > Hi everybody, > > > > is there a way to get MSVC's version string (for the current generator) in > form 12.0 for VS2013 as per this page > ? Or is my > best bet big if/else of the style: > > > > if (MSVC_VERSION EQUAL 1800) > > set(boost_toolset "msvc-12.0") > > elseif(MSVC_VERSION EQUAL 1900) > > set(boost_toolset "msvc-14.0") > > ... > > > > Regards, > > D?enan Zuki?, R&D Engineer, Kitware (Carrboro, N.C.) > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -- Guillaume Dumont ========================= dumont.guillaume at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From skobowsky at caos-gmbh.de Fri Nov 27 10:24:30 2015 From: skobowsky at caos-gmbh.de (Tilman Skobowsky) Date: Fri, 27 Nov 2015 16:24:30 +0100 Subject: [CMake] Visual Studio .sln post generate modifications? Message-ID: <61AFA029-5453-4F1C-9942-070C440D7B90@caos-gmbh.de> Hi, we currently use CMake 3.3.x (x >= 2) on a C++ source code with Windows target only. In our company we're exclusively using Visual Studio (Version 2015 right now). Since we're using remote debugging we have the following problem: In order to set up Remote Debugging with VS, you have to edit the settings in the "Debugging" pane of the target prefs (a.k.a add_executable() target). These debugger settings are stored in a ".vcxproj.user" file, which is perfect, because these files don't get touched by the cmake generator. However, in order to automatically deploy the target, one also has to set the "Deploy" checkmark in the "Configuration Manager" settings. Unfortunately, this setting is NOT saved in a user speciffic file. Instead it is saved in the main projects ".sln" file. (Thanks MS...). I just downloaded the 'cmake' sources to check how the section where this information goes is generated. For WinCE builds there is already code that emits the right information into the solution file. Now the best solution (for me) would be to add a target property that controls emiting this options. But I guess, this might not be an option that could be returned to the 'cmake' source tree, although I'd be willing to give it a try. (some info/references/pointers on how to do this are welcome) Second best solution would be a script or mechanism that can post process the SLN file after it has been generated by cmake but FROM WITHIN the configure/generate process. Is that possible in any way? Of course I know, that I could write some script in order to tweak the solution file after cmake is called, but I'd like to avoid this. I already made lot of use of additional options to shown up within CMakeGUI (which is really cool) and I'd like to be able to set some "ENABLE_REMOTE_DEBUGGING" switch of some sort so that this can be configured in one place. TIA skybow From petr.kmoch at gmail.com Fri Nov 27 10:58:01 2015 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Fri, 27 Nov 2015 16:58:01 +0100 Subject: [CMake] Visual Studio .sln post generate modifications? In-Reply-To: <61AFA029-5453-4F1C-9942-070C440D7B90@caos-gmbh.de> References: <61AFA029-5453-4F1C-9942-070C440D7B90@caos-gmbh.de> Message-ID: Hi. I don't know how exactly the Deploy checkbox value is stored inside the .sln file, but CMake has built-in ways of adding arbitrary sections and contents to the .sln file; see directory properties VS_GLOBAL_SECTION_PRE_
( https://cmake.org/cmake/help/latest/prop_dir/VS_GLOBAL_SECTION_PRE_section.html ) and VS_GLOBAL_SECTION_POST_
( https://cmake.org/cmake/help/latest/prop_dir/VS_GLOBAL_SECTION_POST_section.html ). Perhaps you could use them to store the information in the .sln? Petr On Fri, Nov 27, 2015 at 4:24 PM, Tilman Skobowsky wrote: > Hi, > > we currently use CMake 3.3.x (x >= 2) on a C++ source code with Windows > target only. > In our company we're exclusively using Visual Studio (Version 2015 right > now). > > Since we're using remote debugging we have the following problem: > > In order to set up Remote Debugging with VS, you have to edit the settings > in the "Debugging" pane of the target prefs (a.k.a add_executable() > target). These debugger settings are stored in a ".vcxproj.user" file, > which is perfect, because these files don't get touched by the cmake > generator. > > However, in order to automatically deploy the target, one also has to set > the "Deploy" checkmark in the "Configuration Manager" settings. > Unfortunately, this setting is NOT saved in a user speciffic file. Instead > it is saved in the main projects ".sln" file. (Thanks MS...). > > I just downloaded the 'cmake' sources to check how the section where this > information goes is generated. For WinCE builds there is already code that > emits the right information into the solution file. > > Now the best solution (for me) would be to add a target property that > controls emiting this options. But I guess, this might not be an option > that could be returned to the 'cmake' source tree, although I'd be willing > to give it a try. (some info/references/pointers on how to do this are > welcome) > > Second best solution would be a script or mechanism that can post process > the SLN file after it has been generated by cmake but FROM WITHIN the > configure/generate process. Is that possible in any way? > > Of course I know, that I could write some script in order to tweak the > solution file after cmake is called, but I'd like to avoid this. I already > made lot of use of additional options to shown up within CMakeGUI (which is > really cool) and I'd like to be able to set some "ENABLE_REMOTE_DEBUGGING" > switch of some sort so that this can be configured in one place. > > TIA > skybow > > > > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 Sun Nov 29 04:47:05 2015 From: dan at su-root.co.uk (Dan Liew) Date: Sun, 29 Nov 2015 09:47:05 +0000 Subject: [CMake] Obtaining header file dependencies of a source file manually Message-ID: Hi, # TL;DR I need a way of determining the header file dependencies of a source file and inform CMake about them. CMake doesn't do this automatically because I'm using custom commands for the compilation step so CMake doesn't do it's usual magic of automatically inferring source file header dependencies. This is because this part of the compilation step requires a separate C++ compiler (completely independent from the one that CMake detects at configure time). Is there a way of doing this that will also regenerate the dependencies if the source file changes? # Long version A C++ project that I work on [1] is (amongst other things) a compiler. In order to compile applications it needs to link in a supporting runtime that is compiled to LLVM bitcode which is linked into the applications it compiles. The supporting runtime is written in C++ and compiled with Clang. The compilation of the runtime is currently achieved using ``add_custom_command()`` and so I am not using CMake's in built support for detecting header file dependencies. The reason for doing it this way is because the LLVM bitcode compiler (i.e. Clang) **is not** the same compiler as the host C++ compiler for the project. For example the host code might be built with MSVC but the supporting runtime is **always** built with Clang. To see this concretely take a look at [2]. The build works correctly if you build from a clean build directory. It does not work correctly if you perform a rebuild and change one of the header files that the supporting runtime depends on. This is because CMake doesn't know that the runtime source files depend on the header files and so doesn't rebuild the relevant source files. I can obviously tell CMake about these manually (adding more entries under ``DEPENDS`` in the ``add_custom_command()`` invocation) but this is very cumbersome. What I really need is a way to * Automatically infer the dependencies of a source file and tell CMake about them * Have the dependencies automatically regenerated if the source file changes (someone could add or remove a header file include). In a simple Makefile build system this typically achieved by doing something like this: ``` all:: $(SRCS:.cpp:.o) SRCS := foo.cpp bar.cpp # Include SRC file dependencies generated by the compiler if they exist -include $(SRCs:.cpp=.d) %.o : %.cpp $(CXX) -c $< -o $@ -MP -MMD -MF $*.d ``` Note the ``-M*`` flags get the compiler when it runs to generate additional makefile rules that will get included next time a build happens. I don't really know how to do the same thing with CMake. One idea is at configure time invoke Clang with the ``-MP -MMD -MF`` flags on each runtime source file, extract the dependencies then pass them to ``DEPENDS`` in ``add_custom_command()``. If I wanted the dependencies regenerated if the runtime source file changes then I would need to somehow get CMake to reconfigure every time this happens. I don't like this idea very much due to * Having to invoke Clang manually to determine the dependencies. CMake already knows how to determine source file dependencies, but this functionality (AFAIK) isn't exposed to me. * Reconfiguring every time one of the runtime source file changes is annoying (configuring can be slow sometimes). Does anyone have any other ideas? CMake obviously knows how to do all this stuff already for source files being compiled for the detected host C++ compiler, I just don't know how to get at this logic for source files that need to be built with a second independent C++ compiler. [1] https://github.com/halide/Halide [2] https://github.com/halide/Halide/blob/master/src/CMakeLists.txt#L140 Thanks, Dan. From themiwi at gmail.com Sun Nov 29 05:10:13 2015 From: themiwi at gmail.com (Michael Wild) Date: Sun, 29 Nov 2015 10:10:13 +0000 Subject: [CMake] [cmake-developers] Obtaining header file dependencies of a source file manually In-Reply-To: References: Message-ID: On Sun, Nov 29, 2015, 10:47 Dan Liew wrote: Hi, # TL;DR I need a way of determining the header file dependencies of a source file and inform CMake about them. CMake doesn't do this automatically because I'm using custom commands for the compilation step so CMake doesn't do it's usual magic of automatically inferring source file header dependencies. This is because this part of the compilation step requires a separate C++ compiler (completely independent from the one that CMake detects at configure time). Is there a way of doing this that will also regenerate the dependencies if the source file changes? # Long version A C++ project that I work on [1] is (amongst other things) a compiler. In order to compile applications it needs to link in a supporting runtime that is compiled to LLVM bitcode which is linked into the applications it compiles. The supporting runtime is written in C++ and compiled with Clang. The compilation of the runtime is currently achieved using ``add_custom_command()`` and so I am not using CMake's in built support for detecting header file dependencies. The reason for doing it this way is because the LLVM bitcode compiler (i.e. Clang) **is not** the same compiler as the host C++ compiler for the project. For example the host code might be built with MSVC but the supporting runtime is **always** built with Clang. To see this concretely take a look at [2]. The build works correctly if you build from a clean build directory. It does not work correctly if you perform a rebuild and change one of the header files that the supporting runtime depends on. This is because CMake doesn't know that the runtime source files depend on the header files and so doesn't rebuild the relevant source files. I can obviously tell CMake about these manually (adding more entries under ``DEPENDS`` in the ``add_custom_command()`` invocation) but this is very cumbersome. What I really need is a way to * Automatically infer the dependencies of a source file and tell CMake about them * Have the dependencies automatically regenerated if the source file changes (someone could add or remove a header file include). In a simple Makefile build system this typically achieved by doing something like this: ``` all:: $(SRCS:.cpp:.o) SRCS := foo.cpp bar.cpp # Include SRC file dependencies generated by the compiler if they exist -include $(SRCs:.cpp=.d) %.o : %.cpp $(CXX) -c $< -o $@ -MP -MMD -MF $*.d ``` Note the ``-M*`` flags get the compiler when it runs to generate additional makefile rules that will get included next time a build happens. I don't really know how to do the same thing with CMake. One idea is at configure time invoke Clang with the ``-MP -MMD -MF`` flags on each runtime source file, extract the dependencies then pass them to ``DEPENDS`` in ``add_custom_command()``. If I wanted the dependencies regenerated if the runtime source file changes then I would need to somehow get CMake to reconfigure every time this happens. I don't like this idea very much due to * Having to invoke Clang manually to determine the dependencies. CMake already knows how to determine source file dependencies, but this functionality (AFAIK) isn't exposed to me. * Reconfiguring every time one of the runtime source file changes is annoying (configuring can be slow sometimes). Does anyone have any other ideas? CMake obviously knows how to do all this stuff already for source files being compiled for the detected host C++ compiler, I just don't know how to get at this logic for source files that need to be built with a second independent C++ compiler. [1] https://github.com/halide/Halide [2] https://github.com/halide/Halide/blob/master/src/CMakeLists.txt#L140 Thanks, Dan. Hi Dan, Not going into detail as I'm typing on the phone, but this really sounds like a case where a "SuperBuild" ( http://www.kitware.com/media/html/BuildingExternalProjectsWithCMake2.8.html) can help you to simplify things a lot. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From amdmi3 at amdmi3.ru Sun Nov 29 21:10:49 2015 From: amdmi3 at amdmi3.ru (Dmitry Marakasov) Date: Mon, 30 Nov 2015 05:10:49 +0300 Subject: [CMake] Best way to handle application data path for local run vs. installation Message-ID: <20151130021049.GH99499@hades.panopticon> Hi! This question bugs me for a long time so I though maybe someone has a solution. I have a project which includes an application and some data for it. An application needs to know path to its data files, so I pass it via compiler definition: ADD_DEFINITIONS(-DDATADIR="...") The problem is that this path is different based on whether I want to run the application from build directory: ADD_DEFINITIONS(-DDATADIR="${PROJECT_SOURCE_DIR}/data") or want to install it systemwide: ADD_DEFINITIONS(-DDATADIR="${CMAKE_INSTALL_PREFIX}/share/myapp") I want my project to both run from build directory and to be installable systemwide, without the need to rebuild or specify extra options. - I don't want to make an applications search for its data relative to executable path - There's no cross-platform way to get an executable path - This will break when executable is moved or hardlinked - I don't want to try both paths, as this is error prone, as installed executable may pick data files from repository or vice versa - I don't want to make user specify additional cmake flags like -DSYSTEMWIDE_INSTALLATION or -DRUN_LOCALLY. - I don't want to use any wrapper scripts - I don't want to build two executables The best solution would be for cmake to fix path in executable file right after installation, something similar to what cmake does with rpaths. Or there could be a cross-platform way for executable to know whether it was installed which I've missed. Any ideas? -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3 at amdmi3.ru ..: jabber: amdmi3 at jabber.ru http://amdmi3.ru From zbergquist99 at gmail.com Sun Nov 29 22:38:47 2015 From: zbergquist99 at gmail.com (Zac Bergquist) Date: Sun, 29 Nov 2015 22:38:47 -0500 Subject: [CMake] Best way to handle application data path for local run vs. installation In-Reply-To: <20151130021049.GH99499@hades.panopticon> References: <20151130021049.GH99499@hades.panopticon> Message-ID: So you want to hard code a location into the executable, but support multiple locations without making multiple executables? These sound like conflicting requirements. Supporting multiple locations seems reasonable, so this suggests that you'll have to change how your application looks for these data files. My suggestion would be to use the hard-coded location (the one you specify with add_definition) as the default location, and add an alternate way to look in other directories for when you want to run local (not installed) dev builds. I would either do this by: 1) searching the current working directory first, and falling back to the default only if you didn't find data files in the current directory. 2) checking an environment variable for a location and falling back to the default if the variable is not set. When you want to run out of your build directory you would just set the environment variable first. You could even have CMake copy a script into the build directory (but not the install directory) that sets up the environment for you to save a few keystrokes. Zac On Nov 29, 2015 9:17 PM, "Dmitry Marakasov" wrote: > Hi! > > This question bugs me for a long time so I though maybe someone has > a solution. I have a project which includes an application and some > data for it. An application needs to know path to its data files, so > I pass it via compiler definition: ADD_DEFINITIONS(-DDATADIR="...") > > The problem is that this path is different based on whether I want to > run the application from build directory: > > ADD_DEFINITIONS(-DDATADIR="${PROJECT_SOURCE_DIR}/data") > > or want to install it systemwide: > > ADD_DEFINITIONS(-DDATADIR="${CMAKE_INSTALL_PREFIX}/share/myapp") > > I want my project to both run from build directory and to be > installable systemwide, without the need to rebuild or specify extra > options. > > - I don't want to make an applications search for its data relative > to executable path > - There's no cross-platform way to get an executable path > - This will break when executable is moved or hardlinked > - I don't want to try both paths, as this is error prone, as installed > executable may pick data files from repository or vice versa > - I don't want to make user specify additional cmake flags like > -DSYSTEMWIDE_INSTALLATION or -DRUN_LOCALLY. > - I don't want to use any wrapper scripts > - I don't want to build two executables > > The best solution would be for cmake to fix path in executable file > right after installation, something similar to what cmake does with > rpaths. Or there could be a cross-platform way for executable to know > whether it was installed which I've missed. > > Any ideas? > > -- > Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D > amdmi3 at amdmi3.ru ..: jabber: amdmi3 at jabber.ru http://amdmi3.ru > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 gurenchan at gmail.com Sun Nov 29 23:41:01 2015 From: gurenchan at gmail.com (Owen Alanzo Hogarth) Date: Mon, 30 Nov 2015 12:41:01 +0800 Subject: [CMake] adding gprof to cmake project Message-ID: I have a project with many libs and one executable. I read this email exchange: https://cmake.org/pipermail/cmake/2009-December/033979.html on adding linker flags but this was from around 2009 and things most likely have changed a lot since then. in my executable my cmakelists.txt looks like this SET(CMAKE_MACOSX_RPATH 1) FIND_PACKAGE(SDL2 REQUIRED) FIND_PACKAGE(OpenGL REQUIRED) INCLUDE_DIRECTORIES( ${OPENGL_INCLUDE_DIR} ${SDL2_INCLUDE_DIR}) SET(HEADER_FILES ${CMAKE_CURRENT_SOURCE_DIR}/headers/core_engine.h) SET(SRC_FILES ${CMAKE_CURRENT_SOURCE_DIR}/core_engine.c) SET(TARGET_LIBS ${OPENGL_LIBRARIES} ${SDL2_LIBRARY} core_math default_shader_2D renderable_2D cam_2d resource_utils timer_utils) SET(CMAKE_C_FLAGS "-Wall -pg ${CMAKE_C_FLAGS}") SET(CMAKE_EXE_LINKER_FLAGS "-Wall -pg ${CMAKE_EXE_LINKER_FLAGS}") ADD_LIBRARY(core_engine SHARED ${SRC_FILES} ${HEADER_FILES}) TARGET_LINK_LIBRARIES(core_engine ${TARGET_LIBS}) i've set the cmake_c_flags as well as the cmake_exe_linker_flags but I still can't get the output from my executable after running cmake. How can I add the proper flags? -------------- next part -------------- An HTML attachment was scrubbed... URL: From petr.kmoch at gmail.com Mon Nov 30 03:09:37 2015 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Mon, 30 Nov 2015 09:09:37 +0100 Subject: [CMake] [cmake-developers] Obtaining header file dependencies of a source file manually In-Reply-To: References: Message-ID: Hi Dan, you could look into the IMPLICIT_DEPENDS argument of add_custom_command: https://cmake.org/cmake/help/latest/command/add_custom_command.html I don't have direct experience with it, but it looks like it could do what you're looking for. Petr On Sun, Nov 29, 2015 at 10:47 AM, Dan Liew wrote: > Hi, > > # TL;DR > > I need a way of determining the header file dependencies of a source > file and inform CMake about them. CMake doesn't do this automatically > because I'm using custom commands for the compilation step so CMake > doesn't do it's usual magic of automatically inferring source file > header dependencies. This is because this part of the compilation step > requires a separate C++ compiler (completely independent from the one > that CMake detects at configure time). > > Is there a way of doing this that will also regenerate the > dependencies if the source file changes? > > # Long version > > A C++ project that I work on [1] is (amongst other things) a compiler. > In order to compile applications it needs to link in a supporting > runtime that is compiled to LLVM bitcode which is linked into the > applications it compiles. > > The supporting runtime is written in C++ and compiled with Clang. The > compilation of the runtime is currently achieved using > ``add_custom_command()`` and so I am not using CMake's in built > support for detecting header file dependencies. The reason for doing > it this way is because the LLVM bitcode compiler (i.e. Clang) **is > not** the same compiler as the host C++ compiler for the project. For > example the host code might be built with MSVC but the supporting > runtime is **always** built with Clang. > > To see this concretely take a look at [2]. > > The build works correctly if you build from a clean build directory. > It does not work correctly if you perform a rebuild and change one of > the header files that the supporting runtime depends on. This is > because CMake doesn't know that the runtime source files depend on the > header files and so doesn't rebuild the relevant source files. > > I can obviously tell CMake about these manually (adding more entries > under ``DEPENDS`` in the ``add_custom_command()`` invocation) but this > is very cumbersome. > > What I really need is a way to > > * Automatically infer the dependencies of a source file and tell CMake > about them > * Have the dependencies automatically regenerated if the source file > changes (someone could add or remove a header file include). > > In a simple Makefile build system this typically achieved by doing > something like this: > > ``` > all:: $(SRCS:.cpp:.o) > > SRCS := foo.cpp bar.cpp > > # Include SRC file dependencies generated by the compiler if they exist > -include $(SRCs:.cpp=.d) > > %.o : %.cpp > $(CXX) -c $< -o $@ -MP -MMD -MF $*.d > ``` > > Note the ``-M*`` flags get the compiler when it runs to generate > additional makefile rules that will get included next time a build > happens. > > I don't really know how to do the same thing with CMake. One idea is > at configure time invoke Clang with the ``-MP -MMD -MF`` flags on each > runtime source file, extract the dependencies then pass them to > ``DEPENDS`` in ``add_custom_command()``. If I wanted the dependencies > regenerated if the runtime source file changes then I would need to > somehow get CMake to reconfigure every time this happens. > > I don't like this idea very much due to > > * Having to invoke Clang manually to determine the dependencies. CMake > already knows how to determine source file dependencies, but this > functionality (AFAIK) isn't exposed to me. > > * Reconfiguring every time one of the runtime source file changes is > annoying (configuring can be slow sometimes). > > Does anyone have any other ideas? CMake obviously knows how to do all > this stuff already for source files being compiled for the detected > host C++ compiler, I just don't know how to get at this logic for > source files that need to be built with a second independent C++ > compiler. > > [1] https://github.com/halide/Halide > [2] https://github.com/halide/Halide/blob/master/src/CMakeLists.txt#L140 > > Thanks, > Dan. > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake-developers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ruslan_baratov at yahoo.com Mon Nov 30 04:13:03 2015 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Mon, 30 Nov 2015 16:13:03 +0700 Subject: [CMake] Best way to handle application data path for local run vs. installation In-Reply-To: <20151130021049.GH99499@hades.panopticon> References: <20151130021049.GH99499@hades.panopticon> Message-ID: <565C131F.6070104@yahoo.com> On 30-Nov-15 09:10, Dmitry Marakasov wrote: > Hi! > > This question bugs me for a long time so I though maybe someone has > a solution. I have a project which includes an application and some > data for it. An application needs to know path to its data files, so > I pass it via compiler definition: ADD_DEFINITIONS(-DDATADIR="...") > > The problem is that this path is different based on whether I want to > run the application from build directory: > > ADD_DEFINITIONS(-DDATADIR="${PROJECT_SOURCE_DIR}/data") > > or want to install it systemwide: > > ADD_DEFINITIONS(-DDATADIR="${CMAKE_INSTALL_PREFIX}/share/myapp") > > I want my project to both run from build directory and to be > installable systemwide, without the need to rebuild or specify extra > options. > > - I don't want to make an applications search for its data relative > to executable path > - There's no cross-platform way to get an executable path It's tricky but not impossible. Might be helpful: * http://stackoverflow.com/a/1024937/2288008 * https://github.com/Kitware/CMake/blob/31b013b14ad3bf4838f4ba327b5392018f4853b6/Source/cmSystemTools.cxx#L2227 (see exe_dir) > - This will break when executable is moved or hardlinked > - I don't want to try both paths, as this is error prone, as installed > executable may pick data files from repository or vice versa > - I don't want to make user specify additional cmake flags like > -DSYSTEMWIDE_INSTALLATION or -DRUN_LOCALLY. > - I don't want to use any wrapper scripts > - I don't want to build two executables ... > The best solution would be for cmake to fix path in executable file > right after installation, something similar to what cmake does with > rpaths. I doubt there is a general way to patch data section with string in executable. At least with different size and in safe manner. For example Clang is smart enough to figure out 'strlen' of literal string at compile time, so changing string affects logic and hence is dangerous. And rpaths unlike data is designed to be modifiable (e.g. see install_name_tool for OS X) so it's okay to hack it back and forth. Second thought is that when you hardcode path in executable you make it non-relocatable. E.g. it's not possible to pack it to .dmg installer so user can unpack it wherever he wants. > Or there could be a cross-platform way for executable to know > whether it was installed which I've missed. > > Any ideas? > ... Ruslo From amdmi3 at amdmi3.ru Mon Nov 30 06:53:50 2015 From: amdmi3 at amdmi3.ru (Dmitry Marakasov) Date: Mon, 30 Nov 2015 14:53:50 +0300 Subject: [CMake] Best way to handle application data path for local run vs. installation In-Reply-To: <565C131F.6070104@yahoo.com> References: <20151130021049.GH99499@hades.panopticon> <565C131F.6070104@yahoo.com> Message-ID: <20151130115350.GI99499@hades.panopticon> * Ruslan Baratov (ruslan_baratov at yahoo.com) wrote: > > - I don't want to make an applications search for its data relative > > to executable path > > - There's no cross-platform way to get an executable path > It's tricky but not impossible. Might be helpful: > * http://stackoverflow.com/a/1024937/2288008 > * > https://github.com/Kitware/CMake/blob/31b013b14ad3bf4838f4ba327b5392018f4853b6/Source/cmSystemTools.cxx#L2227 > (see exe_dir) I know how it is done - I've patched numberless applications which only used /proc to work on FreeBSD, and that's why I absolutely don't want to go this way. Also this doesn't solve the problem of moving binary around without moving data. > > - This will break when executable is moved or hardlinked > > - I don't want to try both paths, as this is error prone, as installed > > executable may pick data files from repository or vice versa > > - I don't want to make user specify additional cmake flags like > > -DSYSTEMWIDE_INSTALLATION or -DRUN_LOCALLY. > > - I don't want to use any wrapper scripts > > - I don't want to build two executables > ... > > > The best solution would be for cmake to fix path in executable file > > right after installation, something similar to what cmake does with > > rpaths. > I doubt there is a general way to patch data section with string in > executable. At least with different size and in safe manner. For example > Clang is smart enough to figure out 'strlen' of literal string at > compile time, so changing string affects logic and hence is dangerous. I know that changing data is tricky, but I though more of something like having both paths compiled in and switching by changing a constant length data. > And rpaths unlike data is designed to be modifiable (e.g. see > install_name_tool for OS X) so it's okay to hack it back and forth. > > Second thought is that when you hardcode path in executable you make it > non-relocatable. E.g. it's not possible to pack it to .dmg installer so > user can unpack it wherever he wants. Hmm, I didn't think of that, probably some other systems may need this as well. Though I just understood that this problem is different than the one of making cmake produce executable suitable for both inplace run and installation: even if I produce a relocatable binary, I /still/ needs different (relative) paths to data for inplace/systemwide cases. Anyway for now, I did some research and solved the problem of inplace vs. systemwide compilation in a way that I find acceptable. I check for CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT to basically know whether a user has explicitly specified CMAKE_INSTALL_PREFIX. If user specified install prefix, I prepare for systemwide install, otherwise I prepare for inplace run. https://github.com/AMDmi3/hoverboard-sdl/blob/0.4.0/CMakeLists.txt This doesn't support inplace and systemwide /at the same time/, but still supports either of them cleanly, doesn't require extra actions from user and behaves sensibly by default. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3 at amdmi3.ru ..: jabber: amdmi3 at jabber.ru http://amdmi3.ru From bill at classdesign.com Mon Nov 30 07:02:03 2015 From: bill at classdesign.com (Bill Somerville) Date: Mon, 30 Nov 2015 12:02:03 +0000 Subject: [CMake] Best way to handle application data path for local run vs. installation In-Reply-To: <20151130021049.GH99499@hades.panopticon> References: <20151130021049.GH99499@hades.panopticon> Message-ID: <565C3ABB.9030009@classdesign.com> On 30/11/2015 02:10, Dmitry Marakasov wrote: > Hi! > > This question bugs me for a long time so I though maybe someone has > a solution. I have a project which includes an application and some > data for it. An application needs to know path to its data files, so > I pass it via compiler definition: ADD_DEFINITIONS(-DDATADIR="...") > > The problem is that this path is different based on whether I want to > run the application from build directory: > > ADD_DEFINITIONS(-DDATADIR="${PROJECT_SOURCE_DIR}/data") > > or want to install it systemwide: > > ADD_DEFINITIONS(-DDATADIR="${CMAKE_INSTALL_PREFIX}/share/myapp") > > I want my project to both run from build directory and to be > installable systemwide, without the need to rebuild or specify extra > options. > > - I don't want to make an applications search for its data relative > to executable path > - There's no cross-platform way to get an executable path > - This will break when executable is moved or hardlinked > - I don't want to try both paths, as this is error prone, as installed > executable may pick data files from repository or vice versa > - I don't want to make user specify additional cmake flags like > -DSYSTEMWIDE_INSTALLATION or -DRUN_LOCALLY. > - I don't want to use any wrapper scripts > - I don't want to build two executables > > The best solution would be for cmake to fix path in executable file > right after installation, something similar to what cmake does with > rpaths. Or there could be a cross-platform way for executable to know > whether it was installed which I've missed. > > Any ideas? > How about reading the path from a configuration file. The default when there is no configuration file can be a relative path in the build tree. Use an 'install(CODE ...)' command to write a configuration file to be shipped with the executable that contains the path to use when installed. Application reads configuration file if it is there and uses contents to determine the path to the data. Regards Bill. From attila.krasznahorkay at gmail.com Mon Nov 30 07:21:40 2015 From: attila.krasznahorkay at gmail.com (Attila Krasznahorkay) Date: Mon, 30 Nov 2015 13:21:40 +0100 Subject: [CMake] Custom command concurrency Message-ID: <2F3F192C-8A3C-42F7-9A43-D5FF22B95CB7@gmail.com> Dear All, I'm running into a new issue with my custom commands. :-( I have a project with many subdirectories. Where most subdirectories generate some files during the build. Some of which need to be merged into a single file at the end of the build. In my current implementation the subdirectories declare both a custom command and a custom target for generating these files. So that the merge command in the main directory could depend on the custom targets of the subdirectories. (As the merge command can't depend on the generated files themselves directly.) Now, the merge command is not the only use using these generated files. They are also used inside the subdirectories in order to build some libraries. And now the problem comes. Apparently CMake / GNU Make doesn't make sure that the generation command would only run once. Attached is a simple example. When running make in single-process mode, things happen as I would expect them to. Scanning dependencies of target SubdirTarget [ 33%] Generating partialFile.txt [ 33%] Built target SubdirTarget Scanning dependencies of target MergeTarget [ 66%] Generating merged.txt [ 66%] Built target MergeTarget Scanning dependencies of target CompileSubdirTarget [100%] Built target CompileSubdirTarget But when I use multiple build processes, I get: Scanning dependencies of target SubdirTarget Scanning dependencies of target CompileSubdirTarget [ 66%] Generating partialFile.txt [ 66%] Generating partialFile.txt [ 66%] Built target CompileSubdirTarget [ 66%] Built target SubdirTarget Scanning dependencies of target MergeTarget [100%] Generating merged.txt [100%] Built target MergeTarget So, the file generation gets triggered twice at the same time. Of course in this simple example this wouldn't matter. But the generator that I use in real life can't handle this. As it creates some temporary files as it runs, which interfere with each other. So I come out with a corrupt output file. Does anyone have any suggestions? I would really need to be able to make sure that this custom command would not be executed multiple times. And most of all, not multiple times at once. Cheers, Attila P.S. It seems that the Ninja generator is a bit better in this respect. But of course it's not an option to not have my project work correctly with the Makefile generator. -------------- next part -------------- A non-text attachment was scrubbed... Name: custom_command_concurrency.tar.bz2 Type: application/x-bzip2 Size: 535 bytes Desc: not available URL: From iosif.neitzke+cmake at gmail.com Mon Nov 30 08:04:46 2015 From: iosif.neitzke+cmake at gmail.com (iosif neitzke) Date: Mon, 30 Nov 2015 07:04:46 -0600 Subject: [CMake] [cmake-developers] Obtaining header file dependencies of a source file manually In-Reply-To: References: Message-ID: What does output_required_files() [0] do, and is it applicable here? [0] https://cmake.org/cmake/help/v3.4/command/output_required_files.html On Mon, Nov 30, 2015 at 2:09 AM, Petr Kmoch wrote: > Hi Dan, > > you could look into the IMPLICIT_DEPENDS argument of add_custom_command: > https://cmake.org/cmake/help/latest/command/add_custom_command.html > > I don't have direct experience with it, but it looks like it could do what > you're looking for. > > Petr > > On Sun, Nov 29, 2015 at 10:47 AM, Dan Liew wrote: >> >> Hi, >> >> # TL;DR >> >> I need a way of determining the header file dependencies of a source >> file and inform CMake about them. CMake doesn't do this automatically >> because I'm using custom commands for the compilation step so CMake >> doesn't do it's usual magic of automatically inferring source file >> header dependencies. This is because this part of the compilation step >> requires a separate C++ compiler (completely independent from the one >> that CMake detects at configure time). >> >> Is there a way of doing this that will also regenerate the >> dependencies if the source file changes? >> >> # Long version >> >> A C++ project that I work on [1] is (amongst other things) a compiler. >> In order to compile applications it needs to link in a supporting >> runtime that is compiled to LLVM bitcode which is linked into the >> applications it compiles. >> >> The supporting runtime is written in C++ and compiled with Clang. The >> compilation of the runtime is currently achieved using >> ``add_custom_command()`` and so I am not using CMake's in built >> support for detecting header file dependencies. The reason for doing >> it this way is because the LLVM bitcode compiler (i.e. Clang) **is >> not** the same compiler as the host C++ compiler for the project. For >> example the host code might be built with MSVC but the supporting >> runtime is **always** built with Clang. >> >> To see this concretely take a look at [2]. >> >> The build works correctly if you build from a clean build directory. >> It does not work correctly if you perform a rebuild and change one of >> the header files that the supporting runtime depends on. This is >> because CMake doesn't know that the runtime source files depend on the >> header files and so doesn't rebuild the relevant source files. >> >> I can obviously tell CMake about these manually (adding more entries >> under ``DEPENDS`` in the ``add_custom_command()`` invocation) but this >> is very cumbersome. >> >> What I really need is a way to >> >> * Automatically infer the dependencies of a source file and tell CMake >> about them >> * Have the dependencies automatically regenerated if the source file >> changes (someone could add or remove a header file include). >> >> In a simple Makefile build system this typically achieved by doing >> something like this: >> >> ``` >> all:: $(SRCS:.cpp:.o) >> >> SRCS := foo.cpp bar.cpp >> >> # Include SRC file dependencies generated by the compiler if they exist >> -include $(SRCs:.cpp=.d) >> >> %.o : %.cpp >> $(CXX) -c $< -o $@ -MP -MMD -MF $*.d >> ``` >> >> Note the ``-M*`` flags get the compiler when it runs to generate >> additional makefile rules that will get included next time a build >> happens. >> >> I don't really know how to do the same thing with CMake. One idea is >> at configure time invoke Clang with the ``-MP -MMD -MF`` flags on each >> runtime source file, extract the dependencies then pass them to >> ``DEPENDS`` in ``add_custom_command()``. If I wanted the dependencies >> regenerated if the runtime source file changes then I would need to >> somehow get CMake to reconfigure every time this happens. >> >> I don't like this idea very much due to >> >> * Having to invoke Clang manually to determine the dependencies. CMake >> already knows how to determine source file dependencies, but this >> functionality (AFAIK) isn't exposed to me. >> >> * Reconfiguring every time one of the runtime source file changes is >> annoying (configuring can be slow sometimes). >> >> Does anyone have any other ideas? CMake obviously knows how to do all >> this stuff already for source files being compiled for the detected >> host C++ compiler, I just don't know how to get at this logic for >> source files that need to be built with a second independent C++ >> compiler. >> >> [1] https://github.com/halide/Halide >> [2] https://github.com/halide/Halide/blob/master/src/CMakeLists.txt#L140 >> >> Thanks, >> Dan. >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake-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 petr.kmoch at gmail.com Mon Nov 30 08:08:43 2015 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Mon, 30 Nov 2015 14:08:43 +0100 Subject: [CMake] [cmake-developers] Obtaining header file dependencies of a source file manually In-Reply-To: References: Message-ID: On Mon, Nov 30, 2015 at 2:04 PM, iosif neitzke < iosif.neitzke+cmake at gmail.com> wrote: > What does output_required_files() [0] do, and is it applicable here? > > [0] https://cmake.org/cmake/help/v3.4/command/output_required_files.html First and foremost, it introduces deprecated behaviour into your code. The very first line in the docs you link to says that it was deprecated in CMake 3.0 and is this scheduled for removal. It should not be used in new code. Petr -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan at su-root.co.uk Mon Nov 30 13:01:55 2015 From: dan at su-root.co.uk (Dan Liew) Date: Mon, 30 Nov 2015 18:01:55 +0000 Subject: [CMake] [cmake-developers] Obtaining header file dependencies of a source file manually In-Reply-To: References: Message-ID: Hi Michael, > Not going into detail as I'm typing on the phone, but this really sounds > like a case where a "SuperBuild" > (http://www.kitware.com/media/html/BuildingExternalProjectsWithCMake2.8.html) > can help you to simplify things a lot. Thanks for the suggestion but this certainly is not a case where a "SuperBuild" would help. CMake does not know how to configure a compiler that can produce LLVM Bitcode so using a "SuperBuild" is not going to help. Dan. From dan at su-root.co.uk Mon Nov 30 13:03:26 2015 From: dan at su-root.co.uk (Dan Liew) Date: Mon, 30 Nov 2015 18:03:26 +0000 Subject: [CMake] [cmake-developers] Obtaining header file dependencies of a source file manually In-Reply-To: References: Message-ID: Hi, On 30 November 2015 at 08:09, Petr Kmoch wrote: > Hi Dan, > > you could look into the IMPLICIT_DEPENDS argument of add_custom_command: > https://cmake.org/cmake/help/latest/command/add_custom_command.html > > I don't have direct experience with it, but it looks like it could do what > you're looking for. Oh. That sounds exactly like what I'm looking for! Thanks, Dan. From dan at su-root.co.uk Mon Nov 30 13:32:07 2015 From: dan at su-root.co.uk (Dan Liew) Date: Mon, 30 Nov 2015 18:32:07 +0000 Subject: [CMake] [cmake-developers] Obtaining header file dependencies of a source file manually In-Reply-To: References: Message-ID: Hi, On 30 November 2015 at 18:03, Dan Liew wrote: > Hi, > > On 30 November 2015 at 08:09, Petr Kmoch wrote: >> Hi Dan, >> >> you could look into the IMPLICIT_DEPENDS argument of add_custom_command: >> https://cmake.org/cmake/help/latest/command/add_custom_command.html >> >> I don't have direct experience with it, but it looks like it could do what >> you're looking for. > > Oh. That sounds exactly like what I'm looking for! It works but only for makefile generators... That's an annoying limitation. I'll file a feature request to get this implemented for other generators. Dan. From brad.king at kitware.com Mon Nov 30 13:35:13 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 30 Nov 2015 13:35:13 -0500 Subject: [CMake] [cmake-developers] Obtaining header file dependencies of a source file manually In-Reply-To: References: Message-ID: <565C96E1.1000205@kitware.com> On 11/30/2015 01:32 PM, Dan Liew wrote: > It works but only for makefile generators... That's an annoying > limitation. I'll file a feature request to get this implemented for > other generators. It happens to work for Makefile generators because it was easy to implement since those generators already do their own scanning. For other generators it is not possible to implement. -Brad From dan at su-root.co.uk Mon Nov 30 13:56:03 2015 From: dan at su-root.co.uk (Dan Liew) Date: Mon, 30 Nov 2015 18:56:03 +0000 Subject: [CMake] [cmake-developers] Obtaining header file dependencies of a source file manually In-Reply-To: <565C96E1.1000205@kitware.com> References: <565C96E1.1000205@kitware.com> Message-ID: On 30 November 2015 at 18:35, Brad King wrote: > On 11/30/2015 01:32 PM, Dan Liew wrote: >> It works but only for makefile generators... That's an annoying >> limitation. I'll file a feature request to get this implemented for >> other generators. > > It happens to work for Makefile generators because it was easy to > implement since those generators already do their own scanning. > For other generators it is not possible to implement. Well I found the open issue [1]. It's been open for a while. It doesn't look completely impossible. For Ninja, it looks like it has some support for compiler generated dependency files [2]. Incorporating that into ``add_custom_command()`` would require an extra call to the host compiler to generate the dependencies when the custom command is invoked. For other generators that are Makefile or Ninja based I guess that approach wouldn't work. There is an alternative which I suggested in the post. Have CMake determine the dependencies of the files passed to ``IMPLICIT_DEPENDS`` at configure time and spit that into the build files of the generator (that would work for any generator). Then have any changes made to the files passed to ``IMPLICIT_DEPENDS`` trigger a reconfigure so that the dependencies can be recomputed. For Makefiles you can don't need to do this and can take the "fast path" instead. [1] https://cmake.org/Bug/view.php?id=13234 [2] https://ninja-build.org/manual.html#_depfile Dan. From dan at su-root.co.uk Mon Nov 30 13:57:35 2015 From: dan at su-root.co.uk (Dan Liew) Date: Mon, 30 Nov 2015 18:57:35 +0000 Subject: [CMake] [cmake-developers] Obtaining header file dependencies of a source file manually In-Reply-To: References: <565C96E1.1000205@kitware.com> Message-ID: > For other generators that are Makefile or Ninja based I guess that > approach wouldn't work. Sorry that should read For other generators that **aren't** Makefile or Ninja based I guess that approach wouldn't work. From brad.king at kitware.com Mon Nov 30 14:08:17 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 30 Nov 2015 14:08:17 -0500 Subject: [CMake] [cmake-developers] Obtaining header file dependencies of a source file manually In-Reply-To: References: <565C96E1.1000205@kitware.com> Message-ID: <565C9EA1.8020704@kitware.com> On 11/30/2015 01:56 PM, Dan Liew wrote: > It doesn't look completely impossible. For Ninja, it looks like it has > some support for compiler generated dependency files [2] Yes, it may be possible for Ninja. > There is an alternative which I suggested in the post. Have CMake > determine the dependencies of the files passed to ``IMPLICIT_DEPENDS`` > at configure time and spit that into the build files of the generator > (that would work for any generator). Then have any changes made to the > files passed to ``IMPLICIT_DEPENDS`` trigger a reconfigure so that the > dependencies can be recomputed. Perhaps, but after regenerating the project the build tool will not re-load the build files and start building again. That will take an additional invocation. The number of iterations required is bounded only by the depth of dependency chains. It may be much easier to pack all this inside a separate configure/build process using ExternalProject. -Brad From themiwi at gmail.com Mon Nov 30 15:53:49 2015 From: themiwi at gmail.com (Michael Wild) Date: Mon, 30 Nov 2015 21:53:49 +0100 Subject: [CMake] [cmake-developers] Obtaining header file dependencies of a source file manually In-Reply-To: References: Message-ID: On Mon, Nov 30, 2015 at 7:01 PM, Dan Liew wrote: > Hi Michael, > >> Not going into detail as I'm typing on the phone, but this really sounds >> like a case where a "SuperBuild" >> (http://www.kitware.com/media/html/BuildingExternalProjectsWithCMake2.8.html) >> can help you to simplify things a lot. > > Thanks for the suggestion but this certainly is not a case where a > "SuperBuild" would help. CMake does not know how to configure a > compiler that can produce LLVM Bitcode so using a "SuperBuild" is not > going to help. > > Dan. Hi Dan I fail to see why that should not work. Producing LLVM bitcode from C++ with Clang is just adding -emit-llvm flag, right? So, why can't the SuperBuild configure the child build to use Clang and this flag? And Bob's your uncle... Michael From a.neundorf-work at gmx.net Mon Nov 30 15:51:17 2015 From: a.neundorf-work at gmx.net (Alexander Neundorf) Date: Mon, 30 Nov 2015 21:51:17 +0100 Subject: [CMake] Best way to handle application data path for local run vs. installation In-Reply-To: <565C131F.6070104@yahoo.com> References: <20151130021049.GH99499@hades.panopticon> <565C131F.6070104@yahoo.com> Message-ID: <1469290.AThC99h1Gj@tuxedo.neundorf.net> On Monday, November 30, 2015 16:13:03 Ruslan Baratov via CMake wrote: > On 30-Nov-15 09:10, Dmitry Marakasov wrote: > > Hi! > > ... > > The best solution would be for cmake to fix path in executable file > > right after installation, something similar to what cmake does with > > rpaths. > > I doubt there is a general way to patch data section with string in > executable. At least with different size and in safe manner. For example > Clang is smart enough to figure out 'strlen' of literal string at > compile time, so changing string affects logic and hence is dangerous. > And rpaths unlike data is designed to be modifiable Not really. CMake has extra code to make sure the build rpath is as long as the install rpath will be, so it can be patched in later. > (e.g. see > install_name_tool for OS X) so it's okay to hack it back and forth. > > Second thought is that when you hardcode path in executable you make it > non-relocatable. E.g. on Linux $ORIGIN could be used in the RPATH. Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From ruslan_baratov at yahoo.com Mon Nov 30 19:17:35 2015 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Tue, 1 Dec 2015 07:17:35 +0700 Subject: [CMake] Best way to handle application data path for local run vs. installation In-Reply-To: <1469290.AThC99h1Gj@tuxedo.neundorf.net> References: <20151130021049.GH99499@hades.panopticon> <565C131F.6070104@yahoo.com> <1469290.AThC99h1Gj@tuxedo.neundorf.net> Message-ID: <565CE71F.9070707@yahoo.com> On 01-Dec-15 03:51, Alexander Neundorf wrote: > > On Monday, November 30, 2015 16:13:03 Ruslan Baratov via CMake wrote: > > > On 30-Nov-15 09:10, Dmitry Marakasov wrote: > > > > Hi! > > > > > > ... > > > > The best solution would be for cmake to fix path in executable file > > > > right after installation, something similar to what cmake does with > > > > rpaths. > > > > > > I doubt there is a general way to patch data section with string in > > > executable. At least with different size and in safe manner. For example > > > Clang is smart enough to figure out 'strlen' of literal string at > > > compile time, so changing string affects logic and hence is dangerous. > > > And rpaths unlike data is designed to be modifiable > > Not really. CMake has extra code to make sure the build rpath is as > long as the install rpath will be, so it can be patched in later. > Well, that's exactly what I said - RPATH can be patched. > > (e.g. see > > > install_name_tool for OS X) so it's okay to hack it back and forth. > > > > > > Second thought is that when you hardcode path in executable you make it > > > non-relocatable. > > E.g. on Linux $ORIGIN could be used in the RPATH. > > Alex > It's not about RPATH, it's about string literal with path in C++ code. E.g. if you have: const char* resources = "/usr/share/foo" and installing your package to "/home/username/tools" then executable will not find resources since there is no files in "/usr/share/foo" Ruslo -------------- next part -------------- An HTML attachment was scrubbed... URL: From dschepler at scalable-networks.com Mon Nov 30 19:42:21 2015 From: dschepler at scalable-networks.com (Daniel Schepler) Date: Tue, 1 Dec 2015 00:42:21 +0000 Subject: [CMake] Best way to handle application data path for local run vs. installation In-Reply-To: <20151130021049.GH99499@hades.panopticon> References: <20151130021049.GH99499@hades.panopticon> Message-ID: For what it's worth, what we do here is have the executable search for a file named paths.cfg in the same directory it's located in, and read settings from that file to get the paths to load resources from. Then our CMake system is set up to create one paths.cfg when building, and another when installing. Of course, we use Qt which makes it easy both to get the executable location directory (which you mentioned you don't want to do), and to read a configuration file. Also, our installation is designed to be in a self-contained directory, e.g. /opt/Scalable/product; but in an installation to system directories, you wouldn't want to clutter /usr/bin with a paths.cfg file, so you would probably want to have a hard-coded system directory fallback compiled in to use if paths.cfg doesn't exist. A possible hack that just occurred to me: maybe you could make use of the different RPATH by compiling a simple path configuration "plugin" - the executable would try to dlopen("mypaths.so") and if that's found call functions in the plugin to get the paths. The plugin would only be compiled in the build directory, and not installed. Of course, that would be totally non-portable to Windows. -- Daniel Schepler ________________________________________ From: CMake [cmake-bounces at cmake.org] on behalf of Dmitry Marakasov [amdmi3 at amdmi3.ru] Sent: Sunday, November 29, 2015 6:10 PM To: cmake at cmake.org Subject: [CMake] Best way to handle application data path for local run vs. installation Hi! This question bugs me for a long time so I though maybe someone has a solution. I have a project which includes an application and some data for it. An application needs to know path to its data files, so I pass it via compiler definition: ADD_DEFINITIONS(-DDATADIR="...") The problem is that this path is different based on whether I want to run the application from build directory: ADD_DEFINITIONS(-DDATADIR="${PROJECT_SOURCE_DIR}/data") or want to install it systemwide: ADD_DEFINITIONS(-DDATADIR="${CMAKE_INSTALL_PREFIX}/share/myapp") I want my project to both run from build directory and to be installable systemwide, without the need to rebuild or specify extra options. - I don't want to make an applications search for its data relative to executable path - There's no cross-platform way to get an executable path - This will break when executable is moved or hardlinked - I don't want to try both paths, as this is error prone, as installed executable may pick data files from repository or vice versa - I don't want to make user specify additional cmake flags like -DSYSTEMWIDE_INSTALLATION or -DRUN_LOCALLY. - I don't want to use any wrapper scripts - I don't want to build two executables The best solution would be for cmake to fix path in executable file right after installation, something similar to what cmake does with rpaths. Or there could be a cross-platform way for executable to know whether it was installed which I've missed. Any ideas? -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3 at amdmi3.ru ..: jabber: amdmi3 at jabber.ru http://amdmi3.ru -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake