From andrew.amaclean at gmail.com Sun Mar 1 17:58:16 2015 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Mon, 2 Mar 2015 09:58:16 +1100 Subject: [CMake] FindMPI.cmake and MS-MPI In-Reply-To: References: Message-ID: Some further information, ignore the CMP0054 warning it is not triggered when the CMake Minimum Version is 3.1 When running FindMPI.cmake, I discovered that I had a spurious registry entry for an older version of MPI so mpiexec.exe was not being found. When I deleted this it found mpiexec.exe in C:/Program Files/Microsoft MPI/Bin/mpiexec.exe OK. I think the key for HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\MPI should still be there before the other registry keys. You definitely need the new lib and include paths. I was able to use FindMPI.cmake and just add in these paths manually. Hope this helps. Regards Andrew On Sun, Mar 1, 2015 at 3:54 PM, Andrew Maclean wrote: > Re-sending because David in no longer at Kitware. > > I downloaded and installed MS-MPI from > http://www.microsoft.com/en-us/download/details.aspx?id=44990 > > This implementation does not work with FindMPI.cmake. > > The includes and libs are found in: > C:/Program Files (x86)/Microsoft SDKs/MPI/ > and mpiexec.exe is in: C:/Program Files/Microsoft MPI/Bin/ > > I had to do the following changes to get it working. Perhaps you would > like to edit FIndMPI.cmake to incorporate these changes: > ---------- > # Require MPI for this project: > if(WIN32) > #This is for finding MS-MPI. > #set(_MPI_PREFIX_PATH) > #list(APPEND _MPI_PREFIX_PATH > "[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\MPI;Path]/..") > set(MPIEXEC "C:/Program Files/Microsoft MPI/Bin/mpiexec.exe") > # For building MPI programs the selected Visual Studio compiler is used, > namely cl.exe. > # So there is no need to set a specific MPI compiler. > #set(MPI_CXX_COMPILER "${CMAKE_CXX_COMPILER}") > set(MPI_CXX_INCLUDE_PATH "C:/Program Files (x86)/Microsoft > SDKs/MPI/Include") > # Make sure the correct libraries (64-bit or 32-bit) are selected. > # Decide between 32-bit and 64-bit libraries for Microsoft's MPI > if("${CMAKE_SIZEOF_VOID_P}" EQUAL 8) > set(MS_MPI_ARCH_DIR x64) > else() > set(MS_MPI_ARCH_DIR x86) > endif() > set(MPI_CXX_LIBRARIES "C:/Program Files (x86)/Microsoft > SDKs/MPI/Lib/${MS_MPI_ARCH_DIR}/msmpi.lib") > set(MPI_C_INCLUDE_PATH "${MPI_CXX_INCLUDE_PATH}") > set(MPI_C_LIBRARIES "{${MPI_CXX_LIBRARIES}") > set(MPIEXEC_NUMPROC_FLAG "-np" CACHE STRING "Flag used by MPI to specify > the number of processes for MPIEXEC; the next option will be the number of > processes.") > else() > find_package(MPI REQUIRED) > endif() > -------- > Some of this is taken from FindMPI.cmake. > > Attached is a zipped up file of the working CMakeLists.txt file and a test > file for you. > > I looked at FindMPI.cmake but I think you guys are better placed to make > the changes. > > Also in the case of FindMPI.cmake, you will need to fix the following > warning message: > > CMake Warning (dev) at C:/Program Files > (x86)/CMake/share/cmake-3.1/Modules/FindMPI.cmake:163 (if): > Policy CMP0054 is not set: Only interpret if() arguments as variables or > keywords when unquoted. Run "cmake --help-policy CMP0054" for policy > details. Use the cmake_policy command to set the policy and suppress this > warning. > > Quoted variables like "MSVC" will no longer be dereferenced when the policy > is set to NEW. Since the policy is not set the OLD behavior will be used. > Call Stack (most recent call first): > CMakeLists.txt:5 (find_package) > This warning is for project developers. Use -Wno-dev to suppress it.CMake > Warning (dev) at C:/Program Files > (x86)/CMake/share/cmake-3.1/Modules/FindMPI.cmake:163 (if): > Policy CMP0054 is not set: Only interpret if() arguments as variables or > keywords when unquoted. Run "cmake --help-policy CMP0054" for policy > details. Use the cmake_policy command to set the policy and suppress this > warning. > > Quoted variables like "MSVC" will no longer be dereferenced when the policy > is set to NEW. Since the policy is not set the OLD behavior will be used. > Call Stack (most recent call first): > CMakeLists.txt:5 (find_package) > This warning is for project developers. Use -Wno-dev to suppress it. > > > Regards > > Andrew > > > -- > ___________________________________________ > Andrew J. P. Maclean > > ___________________________________________ > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.amaclean at gmail.com Mon Mar 2 02:31:22 2015 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Mon, 2 Mar 2015 18:31:22 +1100 Subject: [CMake] FindMPI.cmake and MS-MPI In-Reply-To: References: Message-ID: Please ignore my emails regarding this. Apparently Ben Boeckel has fixed these issues in CMake 3.2.0-rc1. Sorry for the unnecessary bandwidth utilization! I can confirm that the VTK master version works OK with MS-MPI. Regards Andrew On Mon, Mar 2, 2015 at 9:58 AM, Andrew Maclean wrote: > Some further information, ignore the CMP0054 warning it is not triggered > when the CMake Minimum Version is 3.1 > > When running FindMPI.cmake, I discovered that I had a spurious registry > entry for an older version of MPI so mpiexec.exe was not being found. When > I deleted this it found mpiexec.exe in C:/Program Files/Microsoft > MPI/Bin/mpiexec.exe OK. I think the key > for HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\MPI should still be there > before the other registry keys. > > You definitely need the new lib and include paths. > > I was able to use FindMPI.cmake and just add in these paths manually. > > Hope this helps. > > Regards > Andrew > > > On Sun, Mar 1, 2015 at 3:54 PM, Andrew Maclean > wrote: > >> Re-sending because David in no longer at Kitware. >> >> I downloaded and installed MS-MPI from >> http://www.microsoft.com/en-us/download/details.aspx?id=44990 >> >> This implementation does not work with FindMPI.cmake. >> >> The includes and libs are found in: >> C:/Program Files (x86)/Microsoft SDKs/MPI/ >> and mpiexec.exe is in: C:/Program Files/Microsoft MPI/Bin/ >> >> I had to do the following changes to get it working. Perhaps you would >> like to edit FIndMPI.cmake to incorporate these changes: >> ---------- >> # Require MPI for this project: >> if(WIN32) >> #This is for finding MS-MPI. >> #set(_MPI_PREFIX_PATH) >> #list(APPEND _MPI_PREFIX_PATH >> "[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\MPI;Path]/..") >> set(MPIEXEC "C:/Program Files/Microsoft MPI/Bin/mpiexec.exe") >> # For building MPI programs the selected Visual Studio compiler is >> used, namely cl.exe. >> # So there is no need to set a specific MPI compiler. >> #set(MPI_CXX_COMPILER "${CMAKE_CXX_COMPILER}") >> set(MPI_CXX_INCLUDE_PATH "C:/Program Files (x86)/Microsoft >> SDKs/MPI/Include") >> # Make sure the correct libraries (64-bit or 32-bit) are selected. >> # Decide between 32-bit and 64-bit libraries for Microsoft's MPI >> if("${CMAKE_SIZEOF_VOID_P}" EQUAL 8) >> set(MS_MPI_ARCH_DIR x64) >> else() >> set(MS_MPI_ARCH_DIR x86) >> endif() >> set(MPI_CXX_LIBRARIES "C:/Program Files (x86)/Microsoft >> SDKs/MPI/Lib/${MS_MPI_ARCH_DIR}/msmpi.lib") >> set(MPI_C_INCLUDE_PATH "${MPI_CXX_INCLUDE_PATH}") >> set(MPI_C_LIBRARIES "{${MPI_CXX_LIBRARIES}") >> set(MPIEXEC_NUMPROC_FLAG "-np" CACHE STRING "Flag used by MPI to >> specify the number of processes for MPIEXEC; the next option will be the >> number of processes.") >> else() >> find_package(MPI REQUIRED) >> endif() >> -------- >> Some of this is taken from FindMPI.cmake. >> >> Attached is a zipped up file of the working CMakeLists.txt file and a >> test file for you. >> >> I looked at FindMPI.cmake but I think you guys are better placed to make >> the changes. >> >> Also in the case of FindMPI.cmake, you will need to fix the following >> warning message: >> >> CMake Warning (dev) at C:/Program Files >> (x86)/CMake/share/cmake-3.1/Modules/FindMPI.cmake:163 (if): >> Policy CMP0054 is not set: Only interpret if() arguments as variables or >> keywords when unquoted. Run "cmake --help-policy CMP0054" for policy >> details. Use the cmake_policy command to set the policy and suppress this >> warning. >> >> Quoted variables like "MSVC" will no longer be dereferenced when the >> policy >> is set to NEW. Since the policy is not set the OLD behavior will be used. >> Call Stack (most recent call first): >> CMakeLists.txt:5 (find_package) >> This warning is for project developers. Use -Wno-dev to suppress it.CMake >> Warning (dev) at C:/Program Files >> (x86)/CMake/share/cmake-3.1/Modules/FindMPI.cmake:163 (if): >> Policy CMP0054 is not set: Only interpret if() arguments as variables or >> keywords when unquoted. Run "cmake --help-policy CMP0054" for policy >> details. Use the cmake_policy command to set the policy and suppress this >> warning. >> >> Quoted variables like "MSVC" will no longer be dereferenced when the >> policy >> is set to NEW. Since the policy is not set the OLD behavior will be used. >> Call Stack (most recent call first): >> CMakeLists.txt:5 (find_package) >> This warning is for project developers. Use -Wno-dev to suppress it. >> >> >> Regards >> >> Andrew >> >> >> -- >> ___________________________________________ >> Andrew J. P. Maclean >> >> ___________________________________________ >> > > > > -- > ___________________________________________ > Andrew J. P. Maclean > > ___________________________________________ > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From johannes.zarl at jku.at Mon Mar 2 05:35:12 2015 From: johannes.zarl at jku.at (Johannes Zarl) Date: Mon, 02 Mar 2015 11:35:12 +0100 Subject: [CMake] CMake Version Compatibility Matrix In-Reply-To: <54ED877C.5000906@astron.nl> References: <54ED877C.5000906@astron.nl> Message-ID: <21275016.r2C51HRj2c@ersa> Hi, > Is there any chance that the version compatibility matrix will be > updated for cmake 3.x features? Short answer: no. Longer answer: I've written and maintained the compatibility matrix before. The reasons I've stopped maintaining the page: (1) Distilling the changes between versions is quite some manual effort (diffing the help text and checking whether something some change reflects a change in cmake or just a doc change) . (2) The documentation format changed in cmake 3, which would have meant a very big one-time effort toget the differences between 2.8 and 3. (3) I still believe that this could be done much better by including annotations in the documentation itself ("Available since:", "Deprecated in:"). Hope that explains my reasons, Johannes From blessjah at jacekowski.org Mon Mar 2 07:47:56 2015 From: blessjah at jacekowski.org (blessjah at jacekowski.org) Date: Mon, 2 Mar 2015 13:47:56 +0100 Subject: [CMake] CMake Version Compatibility Matrix In-Reply-To: <21275016.r2C51HRj2c@ersa> References: <54ED877C.5000906@astron.nl> <21275016.r2C51HRj2c@ersa> Message-ID: <20150302124756.GA29379@jacekowski.org> Hi, Wouldn't it be better to have compability matrix generated automatically? Assuming we can automate process of building CMake and executing tests for any particular version we want, couldn't we create test suite checking if feature X works in version Y of CMake? This way we could maintain compability matrix by simply adding tests for new features? Also, including annotations "Available since" in documentations would be great idea. BR Michal On Mon, Mar 02, 2015 at 11:35:12AM +0100, Johannes Zarl wrote: > Hi, > > > Is there any chance that the version compatibility matrix will be > > updated for cmake 3.x features? > > Short answer: no. > > Longer answer: > I've written and maintained the compatibility matrix before. > > The reasons I've stopped maintaining the page: > (1) Distilling the changes between versions is quite some manual effort (diffing > the help text and checking whether something some change reflects a change in > cmake or just a doc change) . > (2) The documentation format changed in cmake 3, which would have meant a very > big one-time effort toget the differences between 2.8 and 3. > (3) I still believe that this could be done much better by including > annotations in the documentation itself ("Available since:", "Deprecated > in:"). > > Hope that explains my reasons, > Johannes > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From roolebo at gmail.com Mon Mar 2 11:33:38 2015 From: roolebo at gmail.com (Roman Bolshakov) Date: Mon, 2 Mar 2015 19:33:38 +0300 Subject: [CMake] Are CMAKE_CXX_FLAGS supposed to go on the link line? In-Reply-To: <1421943080.5495.45.camel@mad-scientist.net> References: <1420761121.3404.4.camel@mad-scientist.net> <1421943080.5495.45.camel@mad-scientist.net> Message-ID: Apparently, command line to link executable is quite different from a shared library (Modules/CMakeCXXInformation.cmake): if(NOT CMAKE_CXX_LINK_EXECUTABLE) set(CMAKE_CXX_LINK_EXECUTABLE " -o ") endif() set(CMAKE_CXX_CREATE_SHARED_LIBRARY " -o ") CMAKE_CXX_FLAGS/CMAKE_C_FLAGS which are filled into don't go into a linker command for executable. 2015-01-22 19:11 GMT+03:00 Paul Smith : > I didn't get a response to the question below. I've since reproduced > this with a simple test case; maybe someone can let me know why this > difference appears and how I should handle it? I'm using cmake 3.1.0: > > Sample CMakeLists.txt: > > $ cat >CMakeLists.txt < cmake_minimum_required(VERSION 3.1.0) > project(FlagTest) > set(CMAKE_CXX_FLAGS -pthread) > add_executable(foo foo.cpp) > EOF > > $ echo 'int main(int argc, char**argv) { return 0; }' > foo.cpp > > On MacOSX with Xcode installed, I see the following behavior: > > $ cmake -G Xcode . && cmake --build . 2>&1 | tee xc.out > > In the output I see that the "-pthread" flag DOES appear on the compile > line for "foo.o", but DOES NOT appear in the link line for "foo": > > $ grep pthread xc.out > /.../clang -x c++ ... -pthread ... -c /.../foo.cpp -o /.../foo.o > > This is correct for clang, which does not want -pthread on the link line > (unlike GCC, which wants it in both places). Now, I clean that up and > try with the Makefile generator, and I see the following behavior: > > $ cmake -G 'Unix Makefiles' . && cmake --build . -- VERBOSE=1 2>&1 | tee mk.out > clang: warning: argument unused during compilation: '-pthread' > > Now in this case we can see that the -pthread flag was added to BOTH the > compile and the link line: > > $ grep pthread mk.out > /usr/bin/c++ -pthread -o .../foo.cpp.o -c .../foo.cpp > /usr/bin/c++ -pthread .../foo.cpp.o -o foo > clang: warning: argument unused during compilation: '-pthread' > > This warning is totally bogus: it really means "unused during LINKING", > but anyway: I'm not sure what to do to get rid of this warning: I need > to support both Xcode and Makefiles on MacOSX (and Makefiles on Linux as > well as both GCC and Clang). > > Is the intent that CMAKE_CXX_FLAGS only ever appear on the compile line? > Or should it appear on both the compile and link lines? Is there an > equivalent flag to CMAKE_EXE_LINKER_FLAGS that always applies only to > compile lines, in all generators? Do we just have to continue to > bastardize add_definitions() for this, maybe? > > > On Thu, 2015-01-08 at 18:52 -0500, Paul Smith wrote: >> If I'm on OSX, then when I set CMAKE_CXX_FLAGS and do not set >> CMAKE_EXE_LINKER_FLAGS, for example, and I use the Xcode generator, >> then >> I see: >> * CMAKE_CXX_FLAGS show up on the compilation line >> * CMAKE_CXX_FLAGS do NOT show up in the linker line >> >> On the other hand if I'm on OSX and I use the Unix Makefiles >> generator, >> then I see: >> * CMAKE_CXX_FLAGS show up on the compilation line >> * CMAKE_CXX_FLAGS ALSO show up in the linker line >> >> I assume the Xcode output is correct and the makefile output (with >> CMAKE_CXX_FLAGS in both) is not correct... but there's nothing I can >> find in the docs that says this explicitly. >> >> I've printed the contents of the CMAKE_CXX_FLAGS and >> CMAKE_EXE_LINKER_FLAGS at the end of my CMakeLists.txt and they're >> just >> what I expect. It's just that the link line has extra flags, when >> invoked from make. > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 tgamblin at llnl.gov Mon Mar 2 12:19:00 2015 From: tgamblin at llnl.gov (Todd Gamblin) Date: Mon, 02 Mar 2015 09:19:00 -0800 Subject: [CMake] FindMPI.cmake and MS-MPI In-Reply-To: References: Message-ID: Andrew, Thanks for letting me know. Let me know if you have any more issues. Ben: at some point I was the maintainer for FindMPI. Are you the official maintainer now? Do you want to be? I have very limited ability to test on Windows, and that seems to be where most of the problems are. -Todd From: Andrew Maclean Reply-To: "andrew.amaclean at gmail.com" Date: Sunday, March 1, 2015 at 11:31 PM To: Todd Gamblin , "cmake at cmake.org" , Ben Boeckel Subject: Re: FindMPI.cmake and MS-MPI > Please ignore my emails regarding this. Apparently Ben Boeckel has fixed these > issues in CMake 3.2.0-rc1. Sorry for the unnecessary bandwidth utilization! > > I can confirm that the VTK master version works OK with MS-MPI. > > Regards > Andrew > > > On Mon, Mar 2, 2015 at 9:58 AM, Andrew Maclean > wrote: >> Some further information, ignore the CMP0054 warning it is not triggered when >> the CMake Minimum Version is 3.1 >> >> When running FindMPI.cmake, I discovered that I had a spurious registry entry >> for an older version of MPI so mpiexec.exe was not being found. When I >> deleted this it found mpiexec.exe in C:/Program Files/Microsoft >> MPI/Bin/mpiexec.exe OK. I think the key for >> HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\MPI should still be there before the >> other registry keys. >> >> You definitely need the new lib and include paths. >> >> I was able to use FindMPI.cmake and just add in these paths manually. >> >> Hope this helps. >> >> Regards >> Andrew >> >> >> On Sun, Mar 1, 2015 at 3:54 PM, Andrew Maclean >> wrote: >>> Re-sending because David in no longer at Kitware. >>> >>> I downloaded and installed MS-MPI from >>> http://www.microsoft.com/en-us/download/details.aspx?id=44990 >>> >>> This implementation does not work with FindMPI.cmake. >>> >>> The includes and libs are found in: >>> C:/Program Files (x86)/Microsoft SDKs/MPI/ >>> and mpiexec.exe is in: C:/Program Files/Microsoft MPI/Bin/ >>> >>> I had to do the following changes to get it working. Perhaps you would like >>> to edit FIndMPI.cmake to incorporate these changes: >>> ---------- >>> # Require MPI for this project: >>> if(WIN32) >>> #This is for finding MS-MPI. >>> #set(_MPI_PREFIX_PATH) >>> #list(APPEND _MPI_PREFIX_PATH >>> "[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\MPI;Path]/..") >>> set(MPIEXEC "C:/Program Files/Microsoft MPI/Bin/mpiexec.exe") >>> # For building MPI programs the selected Visual Studio compiler is used, >>> namely cl.exe. >>> # So there is no need to set a specific MPI compiler. >>> #set(MPI_CXX_COMPILER "${CMAKE_CXX_COMPILER}") >>> set(MPI_CXX_INCLUDE_PATH "C:/Program Files (x86)/Microsoft >>> SDKs/MPI/Include") >>> # Make sure the correct libraries (64-bit or 32-bit) are selected. >>> # Decide between 32-bit and 64-bit libraries for Microsoft's MPI >>> if("${CMAKE_SIZEOF_VOID_P}" EQUAL 8) >>> set(MS_MPI_ARCH_DIR x64) >>> else() >>> set(MS_MPI_ARCH_DIR x86) >>> endif() >>> set(MPI_CXX_LIBRARIES "C:/Program Files (x86)/Microsoft >>> SDKs/MPI/Lib/${MS_MPI_ARCH_DIR}/msmpi.lib") >>> set(MPI_C_INCLUDE_PATH "${MPI_CXX_INCLUDE_PATH}") >>> set(MPI_C_LIBRARIES "{${MPI_CXX_LIBRARIES}") >>> set(MPIEXEC_NUMPROC_FLAG "-np" CACHE STRING "Flag used by MPI to specify >>> the number of processes for MPIEXEC; the next option will be the number of >>> processes.") >>> else() >>> find_package(MPI REQUIRED) >>> endif() >>> -------- >>> Some of this is taken from FindMPI.cmake. >>> >>> Attached is a zipped up file of the working CMakeLists.txt file and a test >>> file for you. >>> >>> I looked at FindMPI.cmake but I think you guys are better placed to make the >>> changes. >>> >>> Also in the case of FindMPI.cmake, you will need to fix the following >>> warning message: >>> >>> CMake Warning (dev) at C:/Program Files >>> (x86)/CMake/share/cmake-3.1/Modules/FindMPI.cmake:163 (if): >>> Policy CMP0054 is not set: Only interpret if() arguments as variables or >>> keywords when unquoted. Run "cmake --help-policy CMP0054" for policy >>> details. Use the cmake_policy command to set the policy and suppress this >>> warning. >>> >>> Quoted variables like "MSVC" will no longer be dereferenced when the policy >>> is set to NEW. Since the policy is not set the OLD behavior will be used. >>> Call Stack (most recent call first): >>> CMakeLists.txt:5 (find_package) >>> This warning is for project developers. Use -Wno-dev to suppress it.CMake >>> Warning (dev) at C:/Program Files >>> (x86)/CMake/share/cmake-3.1/Modules/FindMPI.cmake:163 (if): >>> Policy CMP0054 is not set: Only interpret if() arguments as variables or >>> keywords when unquoted. Run "cmake --help-policy CMP0054" for policy >>> details. Use the cmake_policy command to set the policy and suppress this >>> warning. >>> >>> Quoted variables like "MSVC" will no longer be dereferenced when the policy >>> is set to NEW. Since the policy is not set the OLD behavior will be used. >>> Call Stack (most recent call first): >>> CMakeLists.txt:5 (find_package) >>> This warning is for project developers. Use -Wno-dev to suppress it. >>> >>> >>> Regards >>> >>> Andrew >>> >>> >>> -- >>> ___________________________________________ >>> Andrew J. P. Maclean >>> >>> ___________________________________________ >> >> >> >> -- >> ___________________________________________ >> Andrew J. P. Maclean >> >> ___________________________________________ > > > > -- > ___________________________________________ > Andrew J. P. Maclean > > ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From clinton at elemtech.com Mon Mar 2 11:45:04 2015 From: clinton at elemtech.com (Clinton Stimpson) Date: Mon, 02 Mar 2015 09:45:04 -0700 Subject: [CMake] Are CMAKE_CXX_FLAGS supposed to go on the link line? In-Reply-To: References: <1420761121.3404.4.camel@mad-scientist.net> <1421943080.5495.45.camel@mad-scientist.net> Message-ID: <1863784.SprpEIL0Yf@stryke> FYI, I also came across this discrepancy recently, and logged a bug for it. http://www.cmake.org/Bug/view.php?id=15427 With the example provided in the bug report, I am seeing link errors under Xcode which I do not see under Makefiles. Clint On Monday, March 02, 2015 07:33:38 PM Roman Bolshakov wrote: > Apparently, command line to link executable is quite different from a > shared library (Modules/CMakeCXXInformation.cmake): > > if(NOT CMAKE_CXX_LINK_EXECUTABLE) > set(CMAKE_CXX_LINK_EXECUTABLE > " > -o ") > endif() > > > set(CMAKE_CXX_CREATE_SHARED_LIBRARY > " > > > -o ") > > CMAKE_CXX_FLAGS/CMAKE_C_FLAGS which are filled into > don't go into a linker command for > executable. > > 2015-01-22 19:11 GMT+03:00 Paul Smith : > > I didn't get a response to the question below. I've since reproduced > > this with a simple test case; maybe someone can let me know why this > > difference appears and how I should handle it? I'm using cmake 3.1.0: > > > > Sample CMakeLists.txt: > > $ cat >CMakeLists.txt < > cmake_minimum_required(VERSION 3.1.0) > > project(FlagTest) > > set(CMAKE_CXX_FLAGS -pthread) > > add_executable(foo foo.cpp) > > EOF > > > > $ echo 'int main(int argc, char**argv) { return 0; }' > foo.cpp > > > > On MacOSX with Xcode installed, I see the following behavior: > > $ cmake -G Xcode . && cmake --build . 2>&1 | tee xc.out > > > > In the output I see that the "-pthread" flag DOES appear on the compile > > > > line for "foo.o", but DOES NOT appear in the link line for "foo": > > $ grep pthread xc.out > > /.../clang -x c++ ... -pthread ... -c /.../foo.cpp -o /.../foo.o > > > > This is correct for clang, which does not want -pthread on the link line > > (unlike GCC, which wants it in both places). Now, I clean that up and > > > > try with the Makefile generator, and I see the following behavior: > > $ cmake -G 'Unix Makefiles' . && cmake --build . -- VERBOSE=1 2>&1 | tee > > mk.out clang: warning: argument unused during compilation: '-pthread' > > > > Now in this case we can see that the -pthread flag was added to BOTH the > > > > compile and the link line: > > $ grep pthread mk.out > > /usr/bin/c++ -pthread -o .../foo.cpp.o -c .../foo.cpp > > /usr/bin/c++ -pthread .../foo.cpp.o -o foo > > clang: warning: argument unused during compilation: '-pthread' > > > > This warning is totally bogus: it really means "unused during LINKING", > > but anyway: I'm not sure what to do to get rid of this warning: I need > > to support both Xcode and Makefiles on MacOSX (and Makefiles on Linux as > > well as both GCC and Clang). > > > > Is the intent that CMAKE_CXX_FLAGS only ever appear on the compile line? > > Or should it appear on both the compile and link lines? Is there an > > equivalent flag to CMAKE_EXE_LINKER_FLAGS that always applies only to > > compile lines, in all generators? Do we just have to continue to > > bastardize add_definitions() for this, maybe? > > > > On Thu, 2015-01-08 at 18:52 -0500, Paul Smith wrote: > >> If I'm on OSX, then when I set CMAKE_CXX_FLAGS and do not set > >> CMAKE_EXE_LINKER_FLAGS, for example, and I use the Xcode generator, > >> then > >> > >> I see: > >> * CMAKE_CXX_FLAGS show up on the compilation line > >> * CMAKE_CXX_FLAGS do NOT show up in the linker line > >> > >> On the other hand if I'm on OSX and I use the Unix Makefiles > >> generator, > >> > >> then I see: > >> * CMAKE_CXX_FLAGS show up on the compilation line > >> * CMAKE_CXX_FLAGS ALSO show up in the linker line > >> > >> I assume the Xcode output is correct and the makefile output (with > >> CMAKE_CXX_FLAGS in both) is not correct... but there's nothing I can > >> find in the docs that says this explicitly. > >> > >> I've printed the contents of the CMAKE_CXX_FLAGS and > >> CMAKE_EXE_LINKER_FLAGS at the end of my CMakeLists.txt and they're > >> just > >> what I expect. It's just that the link line has extra flags, when > >> invoked from make. > > > > -- > > > > Powered by www.kitware.com > > > > Please keep messages on-topic and check the CMake FAQ at: > > http://www.cmake.org/Wiki/CMake_FAQ > > > > Kitware offers various services to support the CMake community. For more > > information on each offering, please visit: > > > > CMake Support: http://cmake.org/cmake/help/support.html > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > > Visit other Kitware 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 ben.boeckel at kitware.com Mon Mar 2 14:10:39 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 2 Mar 2015 14:10:39 -0500 Subject: [CMake] FindMPI.cmake and MS-MPI In-Reply-To: References: Message-ID: <20150302191039.GA18634@megas.kitwarein.com> On Mon, Mar 02, 2015 at 09:19:00 -0800, Todd Gamblin wrote: > Thanks for letting me know. Let me know if you have any more issues. > > Ben: at some point I was the maintainer for FindMPI. Are you the official > maintainer now? Do you want to be? I have very limited ability to test on > Windows, and that seems to be where most of the problems are. I'm not the official maintainer and am not *that* familiar with MPI, so I'm probably not the best choice. If you have issues with MPI on Windows, you can push them my way to test if you'd like. --Ben From tgamblin at llnl.gov Mon Mar 2 14:14:01 2015 From: tgamblin at llnl.gov (Todd Gamblin) Date: Mon, 02 Mar 2015 11:14:01 -0800 Subject: [CMake] FindMPI.cmake and MS-MPI In-Reply-To: <20150302191039.GA18634@megas.kitwarein.com> References: <20150302191039.GA18634@megas.kitwarein.com> Message-ID: Ok, sounds good to me! On 3/2/15, 11:10 AM, "Ben Boeckel" wrote: >On Mon, Mar 02, 2015 at 09:19:00 -0800, Todd Gamblin wrote: >> Thanks for letting me know. Let me know if you have any more issues. >> >> Ben: at some point I was the maintainer for FindMPI. Are you the >>official >> maintainer now? Do you want to be? I have very limited ability to >>test on >> Windows, and that seems to be where most of the problems are. > >I'm not the official maintainer and am not *that* familiar with MPI, so >I'm probably not the best choice. If you have issues with MPI on >Windows, you can push them my way to test if you'd like. > >--Ben From karo at cupdev.net Mon Mar 2 16:53:26 2015 From: karo at cupdev.net (Karolin Varner) Date: Mon, 02 Mar 2015 22:53:26 +0100 Subject: [CMake] find_library/find_path not working on mingw In-Reply-To: References: <54EFAC1A.2070406@cupdev.net> Message-ID: <54F4DBD6.5070605@cupdev.net> Hi Cl?ment, hi Omar, thanks for all you're tipps! It turns out that I had CMAKE_FIND_ROOT_PATH and the PATHS as well as the HINTS are not used if they're not somewhere under CMAKE_FIND_ROOT_PATH. Since all the libs are in a common prefix, I just added that to CMAKE_FIND_ROOT_PATH. On 02/27/2015 01:24 AM, Cl?ment Gregoire wrote: > Hi, you probably want to take a look at > http://www.cmake.org/Bug/view.php?id=15370 On 02/27/2015 10:27 AM, Omar Valerio wrote: > FIND_LIBRARY(ZMQ_LIB zmq HINTS "/usr/lib") > > Instead of FIND_PATH, you may want to use INCLUDE_DIRECTORIES. > http://www.cmake.org/cmake/help/v3.0/command/include_directories.html I am actually passing the result of find_path into include_directories. The point of using find_path is mostly to give some feedback "Hey, we could not find that stuff". Thank you very much, Karolin From Dave at Yost.com Mon Mar 2 20:38:56 2015 From: Dave at Yost.com (Dave Yost) Date: Mon, 2 Mar 2015 17:38:56 -0800 Subject: [CMake] creating a DLL with an OpenCV dependency Message-ID: <3A98C76F-4D0F-4409-B671-7DFB10EF2812@yost.com> Hi. I can?t divine how to get find_package to look for boost in the various places it might be on the various systems where we do builds. Boost might be in any of these places /usr/local/include/boost /usr/local/boost/1.57.0/include /usr/local/boost/1.56.0/include etc. /opt/local/include/boost /opt/local/var/macports/build/_private_tmp_boost149_boost/boost/work/boost_1_49_0/boost/ I tried modifying this in various ways according to the docs to no avail. find_package(Boost ${BOOST_VERSION} EXACT COMPONENTS filesystem program_options serialization system REQUIRED) Thanks From pablo.hernandez.cerdan at outlook.com Mon Mar 2 21:06:47 2015 From: pablo.hernandez.cerdan at outlook.com (=?iso-8859-1?B?UGFibG8gSGVybuFuZGV6?=) Date: Tue, 3 Mar 2015 03:06:47 +0100 Subject: [CMake] Linking header-only lib with external lib dependency in a subfolder Message-ID: I am generating libs from header-only source files, I have a simple header with no dependencies, and a header with boost_filesystem and boost_system dependencies. I am facing linking problems (ld) against boost, when I link the library to the test executable. Tests are in a subdirectory, with an extra CMakeLists.txt. With the no-dependency header, I have no problems. Top CMakeLists.txt: add_library(histo-header histo-header.h) set_target_properties(histo-header PROPERTIES LINKER_LANGUAGE CXX) FILE(COPY histo-header.h DESTINATION include) test/CMakeLists.txt: add_executable(test_histo.exe test_histo.cpp) target_link_libraries(test_histo.exe ${test_libraries}) target_link_libraries(test_histo.exe histo-header) All good here. But when I do the same with the library with boost dependencies: Top CMakeLists.txt: find_package(Boost COMPONENTS system filesystem REQUIRED) include_directories(${Boost_INCLUDE_DIRS}) add_library(histo-header-boost histo-header-boost.h ) target_link_libraries(histo-header-boost PUBLIC ${Boost_Libraries}) set_target_properties(histo-header-boost PROPERTIES LINKER_LANGUAGE CXX) FILE(COPY histo-header-boost.h DESTINATION include) test/CMakeLists.txt: SET( Boost_LIBRARIES ${Boost_LIBRARIES} PARENT_SCOPE ) add_executable(test_histo-boost.exe test_histo-boost.cpp ) target_link_libraries(test_histo-boost.exe ${test_libraries}) target_link_libraries(test_histo-boost.exe histo-header-boost) I face this error: CMakeFiles/test_histo-boost.exe.dir/test_histo-boost.cpp.o: In function `__static_initialization_and_destruction_0(int, int)': test_histo-boost.cpp:(.text+0x1c2): undefined reference to `boost::system::generic_category()' test_histo-boost.cpp:(.text+0x1ce): undefined reference to `boost::system::generic_category()' test_histo-boost.cpp:(.text+0x1da): undefined reference to `boost::system::system_category()' collect2: error: ld returned 1 exit status m What am I missing here? So -------------- next part -------------- An HTML attachment was scrubbed... URL: From pablo.hernandez.cerdan at outlook.com Mon Mar 2 22:05:42 2015 From: pablo.hernandez.cerdan at outlook.com (=?iso-8859-1?B?UGFibG8gSGVybuFuZGV6?=) Date: Tue, 3 Mar 2015 04:05:42 +0100 Subject: [CMake] Linking header-only lib with external lib dependency in a subfolder In-Reply-To: References: Message-ID: By the way, I am using: cmake version 3.2.20150216-gf724a -------------- next part -------------- An HTML attachment was scrubbed... URL: From Dave at Yost.com Tue Mar 3 05:20:49 2015 From: Dave at Yost.com (Dave Yost) Date: Tue, 3 Mar 2015 02:20:49 -0800 Subject: [CMake] finding boost Message-ID: <9455FC50-280D-43C4-89A6-FE1D9E2AF1EC@Yost.com> Hi. I?m having trouble with the find_package documentation w.r.t. boost. I can?t divine how to get find_package to look for boost in various places it might be on the various systems where we do builds. I know boost looks in several places, but I need to add to that list. Boost might be in any of these places /usr/local/include/boost /usr/local/boost/1.57.0/include /usr/local/boost/1.56.0/include etc. /opt/local/include/boost /opt/local/var/macports/build/_private_tmp_boost149_boost/boost/work/boost_1_49_0/boost/ I tried modifying this in various ways according to the docs to no avail. find_package(Boost ${BOOST_VERSION} EXACT COMPONENTS filesystem program_options serialization system REQUIRED) Thanks From rwan.work at gmail.com Tue Mar 3 08:15:38 2015 From: rwan.work at gmail.com (Raymond Wan) Date: Tue, 3 Mar 2015 21:15:38 +0800 Subject: [CMake] finding boost In-Reply-To: <9455FC50-280D-43C4-89A6-FE1D9E2AF1EC@Yost.com> References: <9455FC50-280D-43C4-89A6-FE1D9E2AF1EC@Yost.com> Message-ID: Hi Dave, On Tue, Mar 3, 2015 at 6:20 PM, Dave Yost wrote: > I?m having trouble with the find_package documentation w.r.t. boost. > > I can?t divine how to get find_package to look for boost in various places it might be on the various systems where we do builds. I know boost looks in several places, but I need to add to that list. > > Boost might be in any of these places > /usr/local/include/boost > /usr/local/boost/1.57.0/include > /usr/local/boost/1.56.0/include etc. > /opt/local/include/boost > /opt/local/var/macports/build/_private_tmp_boost149_boost/boost/work/boost_1_49_0/boost/ > > I tried modifying this in various ways according to the docs to no avail. > > find_package(Boost ${BOOST_VERSION} EXACT > COMPONENTS filesystem program_options serialization system > REQUIRED) If I'm not mistaken, the user can give "hints" to FindBoost via the BOOST_ROOT environment variable. Regardless of whether a user is using CMake or not, s/he should be setting this environment variable anyways. Take a look at this: http://www.cmake.org/cmake/help/v3.0/module/FindBoost.html In particular, the third green-background section on that page. Ray From robert.maynard at kitware.com Tue Mar 3 08:40:55 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 3 Mar 2015 08:40:55 -0500 Subject: [CMake] Linking header-only lib with external lib dependency in a subfolder In-Reply-To: References: Message-ID: It is Boost_LIBRARIES not Boost_Libraries On Mon, Mar 2, 2015 at 10:05 PM, Pablo Hern?ndez < pablo.hernandez.cerdan at outlook.com> wrote: > By the way, I am using: > cmake version 3.2.20150216-gf724a > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 Dave at Yost.com Tue Mar 3 15:23:45 2015 From: Dave at Yost.com (Dave Yost) Date: Tue, 3 Mar 2015 12:23:45 -0800 Subject: [CMake] cmake picks a compiler Message-ID: Hi. In our CMakeLists.txt file we want to force the user to pick a c++ compiler explicitly, something like this: if (NOT DEFINED CMAKE_CXX_COMPILER) set(CMAKE_CXX_COMPILER $ENV{CXX}) if (NOT DEFINED CMAKE_CXX_COMPILER) message(FATAL_ERROR " You must choose your compiler, in one of two ways: cmake -DCMAKE_CXX_COMPILER=/path/to/compiler++ CXX=/path/to/compiler++ cmake") endif() endif() message("CMAKE_CXX_COMPILER: ${CMAKE_CXX_COMPILER}") Problem is, CMAKE_CXX_COMPILER is already set because cmake looked around and picked a compiler (which causes a lot of messages to be output before cmake executes the above statements). Z% CMAKE_CXX_COMPILER=/usr/bin/clang++ cmake .. -- The CXX compiler identification is GNU 4.9.2 -- Checking whether CXX compiler has -isysroot -- Checking whether CXX compiler has -isysroot - yes -- Checking whether CXX compiler supports OSX deployment target flag -- Checking whether CXX compiler supports OSX deployment target flag - yes -- Check for working CXX compiler: /opt/local/bin/c++ -- Check for working CXX compiler: /opt/local/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done CMAKE_CXX_COMPILER: /opt/local/bin/c++ I need a command I can put in my CMakeLists.txt file to disable the cmake feature that automatically locates a c++ compiler. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Tue Mar 3 15:33:55 2015 From: DLRdave at aol.com (David Cole) Date: Tue, 3 Mar 2015 15:33:55 -0500 Subject: [CMake] cmake picks a compiler In-Reply-To: References: Message-ID: CMake picks the compiler when you enable the C++ language, which is either: the first project command encountered, or an explicit call to the enable_language command. Or, in rare cases, it could be an implicitly added project command in the top level CMakeLists.txt file for those files without either project or enable_language anywhere in the file... If you want to put instruction before the automatic picking happens, just put your instructions before the project command. HTH, David C. On Tue, Mar 3, 2015 at 3:23 PM, Dave Yost wrote: > Hi. > > In our CMakeLists.txt file we want to force the user to pick a c++ compiler > explicitly, something like this: > > if (NOT DEFINED CMAKE_CXX_COMPILER) > set(CMAKE_CXX_COMPILER $ENV{CXX}) > if (NOT DEFINED CMAKE_CXX_COMPILER) > message(FATAL_ERROR " > You must choose your compiler, in one of two ways: > cmake -DCMAKE_CXX_COMPILER=/path/to/compiler++ > CXX=/path/to/compiler++ cmake") > endif() > endif() > message("CMAKE_CXX_COMPILER: ${CMAKE_CXX_COMPILER}") > > > Problem is, CMAKE_CXX_COMPILER is already set because cmake looked around > and picked a compiler (which causes a lot of messages to be output before > cmake executes the above statements). > > Z% CMAKE_CXX_COMPILER=/usr/bin/clang++ cmake .. > -- The CXX compiler identification is GNU 4.9.2 > -- Checking whether CXX compiler has -isysroot > -- Checking whether CXX compiler has -isysroot - yes > -- Checking whether CXX compiler supports OSX deployment target flag > -- Checking whether CXX compiler supports OSX deployment target flag - yes > -- Check for working CXX compiler: /opt/local/bin/c++ > -- Check for working CXX compiler: /opt/local/bin/c++ -- works > -- Detecting CXX compiler ABI info > -- Detecting CXX compiler ABI info - done > -- Detecting CXX compile features > -- Detecting CXX compile features - done > CMAKE_CXX_COMPILER: /opt/local/bin/c++ > > > I need a command I can put in my CMakeLists.txt file to disable the cmake > feature that automatically locates a c++ compiler. > > Thanks > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From dan.zadeh at pathcore.ca Tue Mar 3 16:25:38 2015 From: dan.zadeh at pathcore.ca (dannyboy) Date: Tue, 3 Mar 2015 14:25:38 -0700 (MST) Subject: [CMake] Reactivate Issue 0012379 Message-ID: <1425417938162-7589908.post@n2.nabble.com> I would like to vote up issue 0012379 (EXCLUDE_FROM_DEFAULT_BUILD in MSVC breaks with dependencies). The feature is still broken in CMake 2.8 & 3.1. Any suggestions or workarounds would be appreciated. Cheers, Dan -- View this message in context: http://cmake.3232098.n2.nabble.com/Reactivate-Issue-0012379-tp7589908.html Sent from the CMake mailing list archive at Nabble.com. From robert.maynard at kitware.com Tue Mar 3 16:26:16 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 3 Mar 2015 16:26:16 -0500 Subject: [CMake] Mastering CMake updated to CMake 3.1 Message-ID: We just wanted to let everyone know that Mastering CMake ( http://www.kitware.com/products/books/CMakeBook.html) has been updated for version 3.1 and is available on Amazon. It is also available on Amazon's sites for Spain, the United Kingdom, Germany, France, and Italy. Please see http://www.kitware.com/products/books.php for the links. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan.zadeh at pathcore.ca Tue Mar 3 16:27:03 2015 From: dan.zadeh at pathcore.ca (dannyboy) Date: Tue, 3 Mar 2015 14:27:03 -0700 (MST) Subject: [CMake] Access denied error with cmake 3.1.1 -E env option (MSVC 11) In-Reply-To: <1423380725656-7589722.post@n2.nabble.com> References: <1423380725656-7589722.post@n2.nabble.com> Message-ID: <1425418023189-7589909.post@n2.nabble.com> Any suggestions regarding the issue would be appreciated. Cheers, Dan -- View this message in context: http://cmake.3232098.n2.nabble.com/Access-denied-error-with-cmake-3-1-1-E-env-option-MSVC-11-tp7589722p7589909.html Sent from the CMake mailing list archive at Nabble.com. From pablo.hernandez.cerdan at outlook.com Tue Mar 3 20:10:47 2015 From: pablo.hernandez.cerdan at outlook.com (=?iso-8859-1?B?UGFibG8gSGVybuFuZGV6?=) Date: Wed, 4 Mar 2015 02:10:47 +0100 Subject: [CMake] Avoid re-linking dependency of external shared lib in a new project. Message-ID: I want to generate in cmake a header-only library from header.h, that depends on libboost_system and filesystem. I can compile the library without problems with: find_package(Boost COMPONENTS system filesystem REQUIRED) include_directories(SYSTEM ${Boost_INCLUDE_DIRS}) add_library(mylib SHARED header.h) target_link_libraries(mylib PUBLIC ${Boost_LIBRARIES}) set_target_properties(mylib PROPERTIES LINKER_LANGUAGE CXX) But when I link to mylib elsewhere, it fails finding the boost library with a ld error. The failure makes sense, but I don't know how to solve it in CMake. How do I "store" the boost dependency on mylib? So I don't have to worry about finding the boost library in other external project? I am using cmake 3.2 When I use it in other project, the linker is not able to find the boost library: target_link_libraries(newproject.exe ${external_mylib}) undefined reference to symbol '_ZN5boost6system15system_categoryEv' /PATH/TO/libboost_system-mt-d.so.1.57.0: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status It is solved if I explicitly link again to the Boost_LIBRARIES. target_link_libraries(newproject.exe ${external_mylib} ${Boost_LIBRARIES)) This doesn't avoid finding again the boost_libraries, maybe the solution is to put the boost_libraries in the environment variable LD_LIBRARY_PATH? Can I avoid relinking to boost somehow? -------------- next part -------------- An HTML attachment was scrubbed... URL: From pablo.hernandez.cerdan at outlook.com Tue Mar 3 20:05:55 2015 From: pablo.hernandez.cerdan at outlook.com (=?iso-8859-1?B?UGFibG8gSGVybuFuZGV6?=) Date: Wed, 4 Mar 2015 02:05:55 +0100 Subject: [CMake] Linking header-only lib with external lib dependency in a subfolder In-Reply-To: References: , Message-ID: Pufff, thanks. From: robert.maynard at kitware.com Date: Tue, 3 Mar 2015 08:40:55 -0500 Subject: Re: [CMake] Linking header-only lib with external lib dependency in a subfolder To: pablo.hernandez.cerdan at outlook.com CC: cmake at cmake.org It is Boost_LIBRARIES not Boost_Libraries On Mon, Mar 2, 2015 at 10:05 PM, Pablo Hern?ndez wrote: By the way, I am using: cmake version 3.2.20150216-gf724a -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware 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 jhunter57 at gmail.com Tue Mar 3 23:13:01 2015 From: jhunter57 at gmail.com (jeffHunter) Date: Tue, 3 Mar 2015 21:13:01 -0700 (MST) Subject: [CMake] Nesting CMake packages Message-ID: <1425442381691-7589913.post@n2.nabble.com> I want to organize the code in a large program into a suite of CMake packages. It's all organized roughly like this: As far as I understand, these should be organized into shared libraries. If possible, for dependencies I'd like to use something similar to: Is it possible to include the geometry package like this without needing to refer to CGAL? Are there any good resources out there explaining the canonical way to create and use libraries like this? Does anyone have better suggestions? -- View this message in context: http://cmake.3232098.n2.nabble.com/Nesting-CMake-packages-tp7589913.html Sent from the CMake mailing list archive at Nabble.com. From m.estrada at alpi.fr Wed Mar 4 04:46:00 2015 From: m.estrada at alpi.fr (Matthieu Estrada) Date: Wed, 04 Mar 2015 10:46:00 +0100 Subject: [CMake] How to set the folder for intermediate files (like .obj) Message-ID: <11af2eb6.1d05660.1f391241.29@alpi.fr> Hello, I want to know if it's possible to change the directory in CMake for the .obj files ? With the normal configuration CMake put object files in a folder like this : Project.dir/src/.. Can I put this files in something like that : Project/Debug (for the debug .obj) And Project/Release (for the release .obj) Cordials, Estrada Matthieu Service Informatique / Int?gration -------------- next part -------------- An HTML attachment was scrubbed... URL: From omar.valerio at gmail.com Wed Mar 4 05:53:55 2015 From: omar.valerio at gmail.com (Omar Valerio) Date: Wed, 4 Mar 2015 11:53:55 +0100 Subject: [CMake] How to set the folder for intermediate files (like .obj) In-Reply-To: <11af2eb6.1d05660.1f391241.29@alpi.fr> References: <11af2eb6.1d05660.1f391241.29@alpi.fr> Message-ID: Hello Matthieu I wouldn't recommend to mess around with the project folder structure in CMake because targets down the line rely on finding those OBJ files at exactly those locations. But what you can do, is that if you have a particular requirement for the DEBUG and RELEASE to also contain the respective OBJ, you can use a COPY command in CMake. See for example: http://stackoverflow.com/questions/9994045/copy-target-file-to-another-location-in-a-post-build-step-in-cmake Best! On Wed, Mar 4, 2015 at 10:46 AM, Matthieu Estrada wrote: > Hello, > > > > I want to know if it?s possible to change the directory in CMake for the > .obj files ? > > > > With the normal configuration CMake put object files in a folder like > this : > > > > Project.dir/src/?. > > > > Can I put this files in something like that : > > > > Project/Debug (for the debug .obj) > > > > And > > > > Project/Release (for the release .obj) > > > > Cordials, > > *Estrada Matthieu* > > Service Informatique / Int?gration > > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 m.estrada at alpi.fr Wed Mar 4 07:10:00 2015 From: m.estrada at alpi.fr (Matthieu Estrada) Date: Wed, 04 Mar 2015 13:10:00 +0100 Subject: [CMake] Problem with different #include for precompiled Headers Message-ID: <34902e66.1d05674.1fbd0a7f.2cd6@alpi.fr> Hello, I have a CMakeLists.txt who contains the following : project(sql_sqlite) SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /W4 /D_USRDLL /DSQL_SQLITE_EXPORTS /D_UNICODE /DUNICODE") SET(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE} /Zi /GL /Oi /Gy /O2 /GR- /Gm- /OPT") SET(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} /WX- /ZI /Oy- /Gm /EHsc /MDd /GS /Gd ") set_source_files_properties(../sql_sqlite/stdafx.cpp PROPERTIES COMPILE_FLAGS "/Ycstdafx.h") set_source_files_properties(../sql_sqlite/sql_sqlite.cpp PROPERTIES COMPILE_FLAGS "/Yustdafx.h") set_source_files_properties(../sql_sqlite/win32/main.cpp PROPERTIES COMPILE_FLAGS /Yu"../stdafx.h") set_source_files_properties(../../../external/sqlite/sqlite3.c PROPERTIES COMPILE_FLAGS "/Y-") add_library( sql_sqlite SHARED ../sql_sqlite/stdafx.h ../../../external/sqlite/sqlite3.h ../sql_sqlite/sql_sqlite.cpp ../sql_sqlite/stdafx.cpp ../sql_sqlite/win32/main.cpp ../../../external/sqlite/sqlite3.c ) I've stdafx.cpp and sql-sqlite.cpp with #include "stdafx.h" (for them that's ok), but main.cpp with #include "../stdafx.h" doesn't work. When I generate Makefile with the NMake Makefiles generator, and type ? nmake ? I've the following issue : ? fatal error C1083: Cannot open precompiled header file: '../stdafx.pch': No such file or directory ? Why he doesn't find the stdafx.pch ? I've trying many way to resolve this problem : use backslah, slash, in CMakeLists.txt or my main.cpp.. Nothing works. How I can resolve this problem ? Is there a way to force it or a custom command special for precompiled header using relative path ? Cordials, Estrada Matthieu Service Informatique / Int?gration -------------- next part -------------- An HTML attachment was scrubbed... URL: From petr.kmoch at gmail.com Wed Mar 4 07:29:33 2015 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Wed, 4 Mar 2015 13:29:33 +0100 Subject: [CMake] Problem with different #include for precompiled Headers In-Reply-To: <34902e66.1d05674.1fbd0a7f.2cd6@alpi.fr> References: <34902e66.1d05674.1fbd0a7f.2cd6@alpi.fr> Message-ID: Hi Matthieu. This has nothing to do with CMake, it's a property of MSVC. The precompiled header must always be included in exactly the same way, no path changes. In other words, the name of the precompiled header as specified to /Yc and /Yu must match exactly. Pretty much the only sane way to do that is to always include it by pure name only and provide the appropriate include path to all source files which use the precompiled header. Petr On Wed, Mar 4, 2015 at 1:10 PM, Matthieu Estrada wrote: > Hello, > > > > I have a CMakeLists.txt who contains the following : > > > > project(sql_sqlite) > > > > SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /W4 /D_USRDLL /DSQL_SQLITE_EXPORTS > /D_UNICODE /DUNICODE") > > SET(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE} /Zi /GL /Oi /Gy > /O2 /GR- /Gm- /OPT") > > SET(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} /WX- /ZI /Oy- /Gm > /EHsc /MDd /GS /Gd ") > > > > set_source_files_properties(../sql_sqlite/stdafx.cpp > PROPERTIES COMPILE_FLAGS "/Ycstdafx.h") > > set_source_files_properties(../sql_sqlite/sql_sqlite.cpp > PROPERTIES COMPILE_FLAGS "/Yustdafx.h") > > set_source_files_properties(../sql_sqlite/win32/main.cpp > PROPERTIES COMPILE_FLAGS /Yu"../stdafx.h") > > > set_source_files_properties(../../../external/sqlite/sqlite3.c PROPERTIES > COMPILE_FLAGS "/Y-") > > > > add_library( > > > > sql_sqlite > > > > SHARED > > > > ../sql_sqlite/stdafx.h > > ../../../external/sqlite/sqlite3.h > > > > ../sql_sqlite/sql_sqlite.cpp > > ../sql_sqlite/stdafx.cpp > > ../sql_sqlite/win32/main.cpp > > ../../../external/sqlite/sqlite3.c > > > > ) > > > > I've stdafx.cpp and sql-sqlite.cpp with #include "stdafx.h" (for them > that's ok), but main.cpp with #include "../stdafx.h" doesn't work. When I > generate Makefile with the NMake Makefiles generator, and type ? nmake ? > I?ve the following issue : > > > > ? fatal error C1083: Cannot open precompiled header file: '../stdafx.pch': > No such file or directory ? > > > > Why he doesn?t find the stdafx.pch ? > > I?ve trying many way to resolve this problem : use backslah, slash, in > CMakeLists.txt or my main.cpp?. Nothing works. > > How I can resolve this problem ? Is there a way to force it or a custom > command special for precompiled header using relative path ? > > Cordials, > > *Estrada Matthieu* > > Service Informatique / Int?gration > > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 omar.valerio at gmail.com Wed Mar 4 08:46:14 2015 From: omar.valerio at gmail.com (Omar Valerio) Date: Wed, 4 Mar 2015 14:46:14 +0100 Subject: [CMake] Problem with different #include for precompiled Headers In-Reply-To: <34902e66.1d05674.1fbd0a7f.2cd6@alpi.fr> References: <34902e66.1d05674.1fbd0a7f.2cd6@alpi.fr> Message-ID: Hello Matthieu, Yes, using "../stdafx.h" in your include statements in main.cpp should work. There is a FindSqlLite3 module here: http://svn.openstreetmap.org/applications/utils/export/osm2poidb/cmake/Modules/FindSQLite3.cmake You can use that one instead with a FIND_LIBRARY( ) clause to avoid having to add the SQL library by yourself. It can be tricky if you''re not very familiar with CMake. Basically what is happening with your project is that you need to specify where are the headers for your library, and you specify apart the object compiled code of your library. I notice that you're a little confused on how this is done by looking at your ADD_LIBRARY() [I think you're confused with what HINTS stands for] Cheers On Wed, Mar 4, 2015 at 1:10 PM, Matthieu Estrada wrote: > Hello, > > > > I have a CMakeLists.txt who contains the following : > > > > project(sql_sqlite) > > > > SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /W4 /D_USRDLL /DSQL_SQLITE_EXPORTS > /D_UNICODE /DUNICODE") > > SET(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE} /Zi /GL /Oi /Gy > /O2 /GR- /Gm- /OPT") > > SET(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} /WX- /ZI /Oy- /Gm > /EHsc /MDd /GS /Gd ") > > > > set_source_files_properties(../sql_sqlite/stdafx.cpp > PROPERTIES COMPILE_FLAGS "/Ycstdafx.h") > > set_source_files_properties(../sql_sqlite/sql_sqlite.cpp > PROPERTIES COMPILE_FLAGS "/Yustdafx.h") > > set_source_files_properties(../sql_sqlite/win32/main.cpp > PROPERTIES COMPILE_FLAGS /Yu"../stdafx.h") > > > set_source_files_properties(../../../external/sqlite/sqlite3.c PROPERTIES > COMPILE_FLAGS "/Y-") > > > > add_library( > > > > sql_sqlite > > > > SHARED > > > > ../sql_sqlite/stdafx.h > > ../../../external/sqlite/sqlite3.h > > > > ../sql_sqlite/sql_sqlite.cpp > > ../sql_sqlite/stdafx.cpp > > ../sql_sqlite/win32/main.cpp > > ../../../external/sqlite/sqlite3.c > > > > ) > > > > I've stdafx.cpp and sql-sqlite.cpp with #include "stdafx.h" (for them > that's ok), but main.cpp with #include "../stdafx.h" doesn't work. When I > generate Makefile with the NMake Makefiles generator, and type ? nmake ? > I?ve the following issue : > > > > ? fatal error C1083: Cannot open precompiled header file: '../stdafx.pch': > No such file or directory ? > > > > Why he doesn?t find the stdafx.pch ? > > I?ve trying many way to resolve this problem : use backslah, slash, in > CMakeLists.txt or my main.cpp?. Nothing works. > > How I can resolve this problem ? Is there a way to force it or a custom > command special for precompiled header using relative path ? > > Cordials, > > *Estrada Matthieu* > > Service Informatique / Int?gration > > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 scott.bloom at onshorecs.com Wed Mar 4 12:03:18 2015 From: scott.bloom at onshorecs.com (Scott Aron Bloom) Date: Wed, 4 Mar 2015 17:03:18 +0000 Subject: [CMake] Multi-platform visual studio projects In-Reply-To: <6FD2E165340D9A429CF831C7A2D4F42E60069275@WIN-R92V03RFJ85.onshorecs.local> References: <6FD2E165340D9A429CF831C7A2D4F42E60068FAE@WIN-R92V03RFJ85.onshorecs.local> <6FD2E165340D9A429CF831C7A2D4F42E600691B5@WIN-R92V03RFJ85.onshorecs.local> <6FD2E165340D9A429CF831C7A2D4F42E60069275@WIN-R92V03RFJ85.onshorecs.local> Message-ID: <6FD2E165340D9A429CF831C7A2D4F42E60074FFD@WIN-R92V03RFJ85.onshorecs.local> Another question on this.. It appears, that cmake creates the proper solution, for 64 bits even if the shell is setup for 32 bits, and vice versa. Is this correct? Meaning when its checking the C compiler and CXX compiler ABI info and what not, its not looking for bit width, it uses the generator "Visual Studio...Win64" vs "Visual Studio" for bit width If Im not using a command line based build, does it matter how my command line is setup for running cmake? Scott -----Original Message----- From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Scott Aron Bloom Sent: Friday, February 27, 2015 8:26 AM To: John Drescher Cc: cmake at cmake.org Subject: Re: [CMake] Multi-platform visual studio projects Thanks! -----Original Message----- From: John Drescher [mailto:drescherjm at gmail.com] Sent: Friday, February 27, 2015 8:26 AM To: Scott Aron Bloom Cc: cmake at cmake.org Subject: Re: [CMake] Multi-platform visual studio projects > However, once the solution is created, does the "path" of the shell matter at all? No. John -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware 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 Pere.Mato at cern.ch Wed Mar 4 13:20:16 2015 From: Pere.Mato at cern.ch (Pere Mato Vila) Date: Wed, 4 Mar 2015 18:20:16 +0000 Subject: [CMake] Why policy CMP0054 does not survive cmake_minimum_required? Message-ID: <7D957D63-A674-4D1F-9C42-7A2ACA0E2A4D@cern.ch> Hi, With version 3.1.3, I have to define policy CMP0054 to NEW to avoid lots of warnings. My original approach was to define it at the top level CMakeLists.txt file hoping this will be inherited by all sub_directories of the project. Beware that some of the sub_directories contain a cmake_minimum_required() command because they can also be standalone projects with a project() command. To my surprise this does not work for policy CMP0054 and it works for others like for example CMP0005. Is there any reason for it? To test this behaviour is as simple cmaking the following CMakeLists.txt file: cmake_policy(SET CMP0005 NEW) cmake_policy(SET CMP0054 NEW) cmake_policy(GET CMP0005 cmp0005) cmake_policy(GET CMP0054 cmp0054) message("Policy CMP0005 before version ${cmp0005}") message("Policy CMP0054 before version ${cmp0054}") cmake_minimum_required(VERSION 2.8.8 FATAL_ERROR) cmake_policy(GET CMP0005 _cmp0005) cmake_policy(GET CMP0054 _cmp0054) message("Policy CMP0005 after version ${_cmp0005}") message("Policy CMP0054 after version ${_cmp0054}") The output is: Policy CMP0005 before version NEW Policy CMP0054 before version NEW Policy CMP0005 after version NEW Policy CMP0054 after version so, CMP0054 is undefined after the cmake_minimum_required() Cheers, Pere ------------------------------------------------------------- Pere Mato CERN, PH Department, CH 1211 Geneva 23, Switzerland e-mail: pere.mato at cern.ch tel: +41 22 76 78696 fax: +41 22 76 68792 gsm: +41 76 48 70855 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Wed Mar 4 13:40:35 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Wed, 04 Mar 2015 19:40:35 +0100 Subject: [CMake] Why policy CMP0054 does not survive cmake_minimum_required? In-Reply-To: <7D957D63-A674-4D1F-9C42-7A2ACA0E2A4D@cern.ch> References: <7D957D63-A674-4D1F-9C42-7A2ACA0E2A4D@cern.ch> Message-ID: <54F751A3.9090706@gmail.com> On 04.03.2015 19:20, Pere Mato Vila wrote: > Hi, > > With version 3.1.3, I have to define policy CMP0054 to NEW to avoid > lots of warnings. My original approach was to define it at the top > level CMakeLists.txt file hoping this will be inherited by all > sub_directories of the project. Beware that some of the > sub_directories contain a cmake_minimum_required() command because > they can also be standalone projects with a project() command. To > my surprise this does not work for policy CMP0054 and it works for > others like for example CMP0005. Is there any reason for it? > > To test this behaviour is as simple cmaking the following > CMakeLists.txt file: > cmake_policy(SET CMP0005 NEW) > cmake_policy(SET CMP0054 NEW) > > cmake_policy(GET CMP0005 cmp0005) > cmake_policy(GET CMP0054 cmp0054) > message("Policy CMP0005 before version ${cmp0005}") > message("Policy CMP0054 before version ${cmp0054}") > > cmake_minimum_required(VERSION 2.8.8 FATAL_ERROR) > > cmake_policy(GET CMP0005 _cmp0005) > cmake_policy(GET CMP0054 _cmp0054) > message("Policy CMP0005 after version ${_cmp0005}") > message("Policy CMP0054 after version ${_cmp0054}") > > > The output is: > > Policy CMP0005 before version NEW > Policy CMP0054 before version NEW > Policy CMP0005 after version NEW > Policy CMP0054 after version > > so, CMP0054 is undefined after the cmake_minimum_required() cmake_minimum_required() resets all policies according to the given version. CMP0005 was introduced in 2.6.0 so requiring 2.8.8 sets it to NEW. CMP0054 was introduced in 3.1 so requiring 2.8.8 clears the policy (since it did not exist in 2.8.8). Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: From bnewcomb at nvidia.com Wed Mar 4 18:29:47 2015 From: bnewcomb at nvidia.com (Bill Newcomb) Date: Wed, 4 Mar 2015 15:29:47 -0800 Subject: [CMake] rpath to libstdc++.so Message-ID: <54F7956B.4000006@nvidia.com> In cmake 2.6, I could do something kind of bogus like this: get_filename_component(MY_COMPILER_PREFIX ${CMAKE_C_COMPILER} PATH) set(MY_RPATH ${MY_COMPILER_PREFIX}/../CentOS-5.7/x86_64/lib) link_directories(${MY_RPATH}) set(CMAKE_BUILD_WITH_INSTALL_RPATH FALSE) set(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE) and cmake would add an rpath to the libstdc++.so so I didn't have to set LD_LIBRARY_PATH to run executables that I built. I know it's hideously non-portable, but this is for a project that has rather minimal portability requirements. That behavior seems to no longer be present in cmake 3.x. Is there a different way to achieve the same end? Thanks, B. ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ----------------------------------------------------------------------------------- From fabian.cordes at musterfabrik-berlin.de Thu Mar 5 07:43:21 2015 From: fabian.cordes at musterfabrik-berlin.de (Fabian Cordes) Date: Thu, 5 Mar 2015 12:43:21 +0000 Subject: [CMake] Building LLVM with CMaker fails Message-ID: <83D0199B392F604F9EC2AE187DFE4077F5F25F@MFB-SBS01.mfb.local> I've tried building the new Version of LLVM [llvm.org] which uses a CMake based build system. This gives errors similar to this one in various places of LLVMBuild.cmake. Some time ago, I was able to build an older Version of LLVM. Now even this old Version does not build correctly. There must be some kind of software I have installed in the mean time that interferes. I already tried cleaning the PATH environment variable, but that does not help. Some more technicalities, I am using win8 with Visual Studio 2012 and 2013 (errors occur in both generators) and used both CMake GUI and cli CMake. CMake Error at C:/Dev/llvm-current-bin/LLVMBuild.cmake:44 (configure_file): configure_file Problem configuring file Call Stack (most recent call first): CMakeLists.txt:437 (include) I've googled the error message, but it is not very specific and I cannot find useful resources. Maybe someone on this mailing list has a clue what the problem here is. Are there any good hints how to debug this error type? I already searched CMakeError.log and CMakeOutput.log for any hints, but there's nothing. Any help would be greatly appreciated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From csiga.biga at aol.com Thu Mar 5 11:51:37 2015 From: csiga.biga at aol.com (=?utf-8?Q?Nagy-Egri_M=C4=82=C4=84t=C4=82=C5=A0_Ferenc?=) Date: Thu, 5 Mar 2015 16:51:37 +0000 Subject: [CMake] =?utf-8?q?Mastering_CMake_updated_to_CMake_3=2E1?= In-Reply-To: References: Message-ID: Are there any plans on releasing a digital version (e-book) of this guide? I very much like reading books on my phablet, as it is always t hand and seems a lot more friendly, than a 700+ page book. Felad?: Robert Maynard Elk?ldve: ?kedd?, ?2015?. ?m?rcius? ?3?. ?22?:?26 C?mzett: cmake at cmake.org We just wanted to let everyone know that Mastering CMake ( http://www.kitware.com/products/books/CMakeBook.html) has been updated for version 3.1 and is available on Amazon. It is also available on Amazon's sites for Spain, the United Kingdom, Germany, France, and Italy. Please see http://www.kitware.com/products/books.php for the links. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Pere.Mato at cern.ch Thu Mar 5 12:50:09 2015 From: Pere.Mato at cern.ch (Pere Mato Vila) Date: Thu, 5 Mar 2015 17:50:09 +0000 Subject: [CMake] Why policy CMP0054 does not survive cmake_minimum_required? In-Reply-To: <54F751A3.9090706@gmail.com> References: <7D957D63-A674-4D1F-9C42-7A2ACA0E2A4D@cern.ch> <54F751A3.9090706@gmail.com> Message-ID: <85F4BE57-2CB0-442A-B645-AE26CD094F67@cern.ch> On 04 Mar 2015, at 19:40, Nils Gladitz > wrote: cmake_minimum_required() resets all policies according to the given version. CMP0005 was introduced in 2.6.0 so requiring 2.8.8 sets it to NEW. CMP0054 was introduced in 3.1 so requiring 2.8.8 clears the policy (since it did not exist in 2.8.8). Thanks very much for the explanation. Nevertheless I do not understand the logic. Running with 3.1 with the exactly the same code generates warnings that were not there in 2.8.8. In order to switch them off I need to set the policy to NEW, which gets cleared by requiring somehow a less restrictive condition. Cheers, Pere ------------------------------------------------------------- Pere Mato CERN, PH Department, CH 1211 Geneva 23, Switzerland e-mail: pere.mato at cern.ch tel: +41 22 76 78696 fax: +41 22 76 68792 gsm: +41 76 48 70855 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Pere.Mato at cern.ch Thu Mar 5 12:55:05 2015 From: Pere.Mato at cern.ch (Pere Mato Vila) Date: Thu, 5 Mar 2015 17:55:05 +0000 Subject: [CMake] Unexpected warnings with 3.2.0-rc2 Message-ID: <94A38EA7-D445-4FEE-BCAE-8E6BF222F12F@cern.ch> Using version 3.2.0-rc2 on the Mac OS X 10.10 I get tons of warnings like this: CMake Warning (dev) at cmake/modules/RootConfiguration.cmake:485 (configure_file): configure_file called with unknown argument(s): NEWLINE_STYLE UNIX According to the documentation, nothing has changed http://www.cmake.org/cmake/help/v3.2/command/configure_file.html Is there a logical explanation? Pere ------------------------------------------------------------- Pere Mato CERN, PH Department, CH 1211 Geneva 23, Switzerland e-mail: pere.mato at cern.ch tel: +41 22 76 78696 fax: +41 22 76 68792 gsm: +41 76 48 70855 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Thu Mar 5 13:04:37 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 05 Mar 2015 19:04:37 +0100 Subject: [CMake] Why policy CMP0054 does not survive cmake_minimum_required? In-Reply-To: <85F4BE57-2CB0-442A-B645-AE26CD094F67@cern.ch> References: <7D957D63-A674-4D1F-9C42-7A2ACA0E2A4D@cern.ch> <54F751A3.9090706@gmail.com> <85F4BE57-2CB0-442A-B645-AE26CD094F67@cern.ch> Message-ID: <54F89AB5.6070009@gmail.com> On 05.03.2015 18:50, Pere Mato Vila wrote: > >> On 04 Mar 2015, at 19:40, Nils Gladitz > > wrote: >> >> cmake_minimum_required() resets all policies according to the given >> version. >> >> CMP0005 was introduced in 2.6.0 so requiring 2.8.8 sets it to NEW. >> CMP0054 was introduced in 3.1 so requiring 2.8.8 clears the policy >> (since it did not exist in 2.8.8). > > > Thanks very much for the explanation. Nevertheless I do not understand > the logic. Running with 3.1 with the exactly the same code generates > warnings that were not there in 2.8.8. In order to switch them off I > need to set the policy to NEW, which gets cleared by requiring somehow > a less restrictive condition. Setting individual policies before a call to cmake_minimum_required() doesn't make sense given that it resets them all but you can set them after. The warnings are there so you as a developer of a project that conforms to CMake 2.8.8 know that the behavior will change as soon as you convert your project to 3.1. You can get rid of the warnings by working around the if() ambiguity so that behavior before and after CMake 3.1 is identical or by requiring 3.1. If you do switch to requiring 3.1 make sure the new behavior works for you. Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Thu Mar 5 13:52:47 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 5 Mar 2015 13:52:47 -0500 Subject: [CMake] Mastering CMake updated to CMake 3.1 In-Reply-To: <54f88ec9.4a70e00a.2d8b.7195SMTPIN_ADDED_MISSING@mx.google.com> References: <54f88ec9.4a70e00a.2d8b.7195SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: Hi, We currently have no plans to release the CMake book in an electronic format. On Thu, Mar 5, 2015 at 11:51 AM, Nagy-Egri M??t?? Ferenc wrote: > Are there any plans on releasing a digital version (e-book) of this > guide? I very much like reading books on my phablet, as it is always t hand > and seems a lot more friendly, than a 700+ page book. > > *Felad?:* Robert Maynard > *Elk?ldve:* ?kedd?, ?2015?. ?m?rcius? ?3?. ?22?:?26 > *C?mzett:* cmake at cmake.org > > We just wanted to let everyone know that Mastering CMake ( > http://www.kitware.com/products/books/CMakeBook.html) has been updated > for version 3.1 and is available on Amazon. > > It is also available on Amazon's sites for Spain, the United Kingdom, > Germany, France, and Italy. Please see > http://www.kitware.com/products/books.php for the links. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steveire at gmail.com Thu Mar 5 14:59:20 2015 From: steveire at gmail.com (Stephen Kelly) Date: Thu, 05 Mar 2015 20:59:20 +0100 Subject: [CMake] can I make an AUTOMOC generated file depend on something ? References: <1505810.OWG1IaMX4b@lapi.koller> Message-ID: Kim Rydhof Thor Hansen wrote: > On Wed, Feb 25, 2015 at 10:45 PM, Stephen Kelly > wrote: >> Kim Rydhof Thor Hansen wrote: >> >>> http://www.cmake.org/cmake/help/v3.0/prop_tgt/AUTOGEN_TARGET_DEPENDS.html >>> >>> I have a similar problem because automoc doesn't pick up that my >>> metadata.json file is a dependency to the generated moc_plugin.cpp >>> when building a Qt plugin >> >> Thanks for the testcase. I filed >> >> http://public.kitware.com/Bug/view.php?id=15419 >> >> with more information on what should be done to fix this. > > Thanks for your work on this. > > I can't find a good workaround, I tried using autoget_target_depends > without success but I suspect that it is because I have done something > wrong. > > Can anyone suggest a line to put in CMakeLists.txt in order to > manually register the dependency between metadata.json and > moc_plugin.cpp? A workaround would have to be based on changing the timestamp of the .h file. Here's an ugly workround: add_custom_command( OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/metadata.json" COMMAND ${CMAKE_COMMAND} -E copy "${CMAKE_CURRENT_SOURCE_DIR}/metadata.json.in" "${CMAKE_CURRENT_BINARY_DIR}/metadata.json" COMMAND ${CMAKE_COMMAND} -E copy "${CMAKE_CURRENT_SOURCE_DIR}/plugin.h.in" "${CMAKE_CURRENT_BINARY_DIR}/plugin.h" DEPENDS "${CMAKE_CURRENT_SOURCE_DIR}/metadata.json.in" "${CMAKE_CURRENT_SOURCE_DIR}/plugin.h.in" ) set_property(TARGET plugin PROPERTY AUTOGEN_TARGET_DEPENDS "${CMAKE_CURRENT_BINARY_DIR}/metadata.json") Depending on how you order your include directories, you might not have to rename the .h. Thanks, Steve. From orion at cora.nwra.com Thu Mar 5 22:40:02 2015 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 05 Mar 2015 20:40:02 -0700 Subject: [CMake] Fwd: [Bug 1199360] New: Parallel build of webkitgtk4 fails with cmake 3.2 In-Reply-To: References: Message-ID: <54F92192.6090307@cora.nwra.com> If any cmakers out there could help take a look at this, I'd very much appreciate it. - Orion -------- Forwarded Message -------- Subject: [Bug 1199360] New: Parallel build of webkitgtk4 fails with cmake 3.2 Date: Fri, 06 Mar 2015 03:29:34 +0000 From: bugzilla at redhat.com To: orion at cora.nwra.com https://bugzilla.redhat.com/show_bug.cgi?id=1199360 Bug ID: 1199360 Summary: Parallel build of webkitgtk4 fails with cmake 3.2 Product: Fedora Version: 22 Component: cmake Severity: medium Assignee: orion at cora.nwra.com Reporter: mcatanzaro at gnome.org QA Contact: extras-qa at fedoraproject.org CC: helio at kde.org, jreznik at redhat.com, ltinkl at redhat.com, orion at cora.nwra.com, pmachata at redhat.com, rdieter at math.unl.edu Description of problem: Parallel build of webkitgtk4 fails with cmake 3.2. I wonder if it's a WebKit bug or a CMake bug. Version-Release number of selected component (if applicable): cmake-3.2.0-0.1.rc1.fc22 How reproducible: ...eh... always? Steps to Reproduce: 1. Revert the latest commit to webkitgtk4 which disables parallel build 2. fedpkg build webkitgtk4 Actual results: https://kojipkgs.fedoraproject.org//work/tasks/2915/9132915/build.log The interesting part is this: [ 15%] cd /builddir/build/BUILD/webkitgtk-2.7.91/x86_64-redhat-linux-gnu/DerivedSources/WebCore && /usr/bin/perl -I/builddir/build/BUILD/webkitgtk-2.7.91/Source/WebCore/bindings/scripts /builddir/build/BUILD/webkitgtk-2.7.91/Source/WebCore/css/makeprop.pl --defines " ENABLE_3D_RENDERING ENABLE_ACCELERATED_2D_CANVAS ENABLE_ACCESSIBILITY ENABLE_CHANNEL_MESSAGING ENABLE_CONTEXT_MENUS ENABLE_CSS_BOX_DECORATION_BREAK ENABLE_CSS_IMAGE_SET ENABLE_CSS_REGIONS ENABLE_CSS_SELECTORS_LEVEL4 ENABLE_DETAILS_ELEMENT ENABLE_DRAG_SUPPORT ENABLE_FULLSCREEN_API ENABLE_GEOLOCATION ENABLE_ICONDATABASE ENABLE_INPUT_TYPE_COLOR ENABLE_JIT ENABLE_LEGACY_VENDOR_PREFIXES ENABLE_MATHML ENABLE_MEDIA_CONTROLS_SCRIPT ENABLE_MEMORY_SAMPLER ENABLE_METER_ELEMENT ENABLE_MHTML ENABLE_NAVIGATOR_HWCONCURRENCY ENABLE_NETSCAPE_PLUGIN_API ENABLE_NETWORK_PROCESS ENABLE_NOTIFICATIONS ENABLE_PICTURE_SIZES ENABLE_PROMISES ENABLE_REQUEST_ANIMATION_FRAME ENABLE_SATURATED_LAYOUT_ARITHMETIC ENABLE_SPELLCHECK ENABLE_STREAMS_API ENABLE_SVG_FONTS ENABLE_TEMPLATE_ELEMENT ENABLE_TOUCH_EVENTS ENABLE_USERSELECT_ALL ENABLE_USER_MESSAGE_HANDLERS ENABLE_VIDEO ENABLE_VIDEO_TRACK ENABLE_VIEW_MODE_CSS_MEDIA ENABLE_WEB_AUDIO ENABLE_WEB_SOCKETS ENABLE_WEB_TIMING ENABLE_WEBGL ENABLE_XHR_TIMEOUT ENABLE_XSLT ENABLE_PLUGIN_PROCESS_GTK2" --preprocessor "/usr/bin/c++ -E -P -x c++" /usr/bin/cmake -E cmake_progress_report /builddir/build/BUILD/webkitgtk-2.7.91/x86_64-redhat-linux-gnu/CMakeFiles /usr/bin/cmake -E cmake_progress_report /builddir/build/BUILD/webkitgtk-2.7.91/x86_64-redhat-linux-gnu/CMakeFiles /usr/bin/cmake -E cmake_progress_report /builddir/build/BUILD/webkitgtk-2.7.91/x86_64-redhat-linux-gnu/CMakeFiles /usr/bin/cmake -E cmake_progress_report /builddir/build/BUILD/webkitgtk-2.7.91/x86_64-redhat-linux-gnu/CMakeFiles /usr/bin/cmake -E cmake_progress_report /builddir/build/BUILD/webkitgtk-2.7.91/x86_64-redhat-linux-gnu/CMakeFiles /usr/bin/cmake -E cmake_progress_report /builddir/build/BUILD/webkitgtk-2.7.91/x86_64-redhat-linux-gnu/CMakeFiles [ 15%] [ 15%] [ 15%] [ 15%] [ 15%] Generating ../../DerivedSources/WebCore/SelectorPseudoElementTypeMap.gperf, ../../DerivedSources/WebCore/SelectorPseudoElementTypeMap.cpp [ 15%] CSSPropertyNames.gperf: The input file is empty! calling gperf failed: 256 at /builddir/build/BUILD/webkitgtk-2.7.91/Source/WebCore/css/makeprop.pl line 1032. Source/WebCore/CMakeFiles/WebCore.dir/build.make:155: recipe for target 'DerivedSources/WebCore/CSSPropertyNames.h' failed make[2]: *** [DerivedSources/WebCore/CSSPropertyNames.h] Error 25 make[2]: *** Waiting for unfinished jobs... Line 1032 of makeprop.pl: system("\"$gperf\" --key-positions=\"*\" -D -n -s 2 CSSPropertyNames.gperf --output-file=CSSPropertyNames.cpp") == 0 || die "calling gperf failed: $?"; So I guess CSSPropertyNames.gperf has not been built yet. Oh, but that file is built by makeprop.pl, beginning with line 113: open GPERF, ">CSSPropertyNames.gperf" || die "Could not open CSSPropertyNames.gperf for writing"; So it doesn't SEEM like a CMake dependency issue... but the script is a mess to read, and I can imagine it not working if CSSPropertyNames.in was not properly generated. Now, in WebKit/Source/WebCore/CMakeLists.txt we have this: # Generate CSS property names add_custom_command( OUTPUT ${DERIVED_SOURCES_WEBCORE_DIR}/CSSPropertyNames.in ${DERIVED_SOURCES_WEBCORE_DIR}/CSSPropertyNames.h ${DERIVED_SOURCES_WEBCORE_DIR}/CSSPropertyNames.cpp ${DERIVED_SOURCES_WEBCORE_DIR}/CSSPropertyNames.gperf ${DERIVED_SOURCES_WEBCORE_DIR}/StyleBuilder.cpp ${DERIVED_SOURCES_WEBCORE_DIR}/StylePropertyShorthandFunctions.h ${DERIVED_SOURCES_WEBCORE_DIR}/StylePropertyShorthandFunctions.cpp MAIN_DEPENDENCY ${WEBCORE_DIR}/css/makeprop.pl DEPENDS ${WebCore_CSS_PROPERTY_NAMES} WORKING_DIRECTORY ${DERIVED_SOURCES_WEBCORE_DIR} COMMAND ${PERL_EXECUTABLE} -ne "print" ${WebCore_CSS_PROPERTY_NAMES} > ${DERIVED_SOURCES_WEBCORE_DIR}/CSSPropertyNames.in COMMAND ${PERL_EXECUTABLE} -I${WEBCORE_DIR}/bindings/scripts ${WEBCORE_DIR}/css/makeprop.pl --defines "${FEATURE_DEFINES_WITH_SPACE_SEPARATOR}" --preprocessor "${CODE_GENERATOR_PREPROCESSOR}" VERBATIM) list(APPEND WebCore_SOURCES ${DERIVED_SOURCES_WEBCORE_DIR}/CSSPropertyNames.cpp) list(APPEND WebCore_SOURCES ${DERIVED_SOURCES_WEBCORE_DIR}/StyleBuilder.cpp) list(APPEND WebCore_SOURCES ${DERIVED_SOURCES_WEBCORE_DIR}/StylePropertyShorthandFunctions.cpp) ADD_SOURCE_WEBCORE_DERIVED_DEPENDENCIES(${WEBCORE_DIR}/css/CSSParser.cpp CSSValueKeywords.h) ADD_SOURCE_WEBCORE_DERIVED_DEPENDENCIES(${DERIVED_SOURCES_WEBCORE_DIR}/CSSGrammar.cpp CSSPropertyNames.h) Simple, right? :p And also: set(WebCore_CSS_PROPERTY_NAMES ${WEBCORE_DIR}/css/CSSPropertyNames.in ) ...looks right? At least, I don't notice anything wrong there. But I do notice higher up in the build log: [ 15%] [ 15%] [ 15%] Generating ../../DerivedSources/WebCore/CSSPropertyNames.in, ../../DerivedSources/WebCore/CSSPropertyNames.h, ../../DerivedSources/WebCore/CSSPropertyNames.cpp, ../../DerivedSources/WebCore/CSSPropertyNames.gperf, ../../DerivedSources/WebCore/StyleBuilder.cpp, ../../DerivedSources/WebCore/StylePropertyShorthandFunctions.h, ../../DerivedSources/WebCore/StylePropertyShorthandFunctions.cpp cd /builddir/build/BUILD/webkitgtk-2.7.91/x86_64-redhat-linux-gnu/DerivedSources/WebCore && /usr/bin/perl -ne print /builddir/build/BUILD/webkitgtk-2.7.91/Source/WebCore/css/CSSPropertyNames.in > /builddir/build/BUILD/webkitgtk-2.7.91/x86_64-redhat-linux-gnu/DerivedSources/WebCore/CSSPropertyNames.in Generating ../../DerivedSources/WebCore/CSSPropertyNames.in, ../../DerivedSources/WebCore/CSSPropertyNames.h, ../../DerivedSources/WebCore/CSSPropertyNames.cpp, ../../DerivedSources/WebCore/CSSPropertyNames.gperf, ../../DerivedSources/WebCore/StyleBuilder.cpp, ../../DerivedSources/WebCore/StylePropertyShorthandFunctions.h, ../../DerivedSources/WebCore/StylePropertyShorthandFunctions.cpp cd /builddir/build/BUILD/webkitgtk-2.7.91/x86_64-redhat-linux-gnu/DerivedSources/WebCore && /usr/bin/perl -ne print /builddir/build/BUILD/webkitgtk-2.7.91/Source/WebCore/css/CSSPropertyNames.in > /builddir/build/BUILD/webkitgtk-2.7.91/x86_64-redhat-linux-gnu/DerivedSources/WebCore/CSSPropertyNames.in Generating ../../DerivedSources/WebCore/CSSPropertyNames.in, ../../DerivedSources/WebCore/CSSPropertyNames.h, ../../DerivedSources/WebCore/CSSPropertyNames.cpp, ../../DerivedSources/WebCore/CSSPropertyNames.gperf, ../../DerivedSources/WebCore/StyleBuilder.cpp, ../../DerivedSources/WebCore/StylePropertyShorthandFunctions.h, ../../DerivedSources/WebCore/StylePropertyShorthandFunctions.cpp cd /builddir/build/BUILD/webkitgtk-2.7.91/x86_64-redhat-linux-gnu/DerivedSources/WebCore && /usr/bin/perl -ne print /builddir/build/BUILD/webkitgtk-2.7.91/Source/WebCore/css/CSSPropertyNames.in > /builddir/build/BUILD/webkitgtk-2.7.91/x86_64-redhat-linux-gnu/DerivedSources/WebCore/CSSPropertyNames.in /usr/bin/cmake -E cmake_progress_report /builddir/build/BUILD/webkitgtk-2.7.91/x86_64-redhat-linux-gnu/CMakeFiles Generating ../../DerivedSources/WebCore/CSSPropertyNames.in, ../../DerivedSources/WebCore/CSSPropertyNames.h, ../../DerivedSources/WebCore/CSSPropertyNames.cpp, ../../DerivedSources/WebCore/CSSPropertyNames.gperf, ../../DerivedSources/WebCore/StyleBuilder.cpp, ../../DerivedSources/WebCore/StylePropertyShorthandFunctions.h, ../../DerivedSources/WebCore/StylePropertyShorthandFunctions.cpp /usr/bin/cmake -E cmake_progress_report /builddir/build/BUILD/webkitgtk-2.7.91/x86_64-redhat-linux-gnu/CMakeFiles cd /builddir/build/BUILD/webkitgtk-2.7.91/x86_64-redhat-linux-gnu/DerivedSources/WebCore && /usr/bin/perl -ne print /builddir/build/BUILD/webkitgtk-2.7.91/Source/WebCore/css/CSSPropertyNames.in > /builddir/build/BUILD/webkitgtk-2.7.91/x86_64-redhat-linux-gnu/DerivedSources/WebCore/CSSPropertyNames.in Um, that command is run four times instead of once! And that is as far as I've gotten, but I guess that must be a CMake bug. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug. From post at hendrik-sattler.de Fri Mar 6 01:33:19 2015 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Fri, 06 Mar 2015 07:33:19 +0100 Subject: [CMake] Fwd: [Bug 1199360] New: Parallel build of webkitgtk4 fails with cmake 3.2 In-Reply-To: <54F92192.6090307@cora.nwra.com> References: <54F92192.6090307@cora.nwra.com> Message-ID: <3DAAE482-5B0C-4BC7-BB84-B57BE9DBB85E@hendrik-sattler.de> Hi, I'd assume that the problem is the perl script. It doesn't work correctly when run in parallel multiple times. This can happen when not all outputs are written before another make instance checks this rule. So the first run creates the .perf file which is already empty by another instance when the first instance wants to use it. HS Am 6. M?rz 2015 04:40:02 MEZ, schrieb Orion Poplawski : >If any cmakers out there could help take a look at this, I'd very much >appreciate it. > >- Orion > > >-------- Forwarded Message -------- >Subject: [Bug 1199360] New: Parallel build of webkitgtk4 fails with >cmake 3.2 >Date: Fri, 06 Mar 2015 03:29:34 +0000 >From: bugzilla at redhat.com >To: orion at cora.nwra.com > >https://bugzilla.redhat.com/show_bug.cgi?id=1199360 > > Bug ID: 1199360 > Summary: Parallel build of webkitgtk4 fails with cmake 3.2 > Product: Fedora > Version: 22 > Component: cmake > Severity: medium > Assignee: orion at cora.nwra.com > Reporter: mcatanzaro at gnome.org > QA Contact: extras-qa at fedoraproject.org > CC: helio at kde.org, jreznik at redhat.com, ltinkl at redhat.com, > orion at cora.nwra.com, pmachata at redhat.com, > rdieter at math.unl.edu > > > >Description of problem: Parallel build of webkitgtk4 fails with cmake >3.2. I >wonder if it's a WebKit bug or a CMake bug. > > >Version-Release number of selected component (if applicable): >cmake-3.2.0-0.1.rc1.fc22 > > >How reproducible: ...eh... always? > > >Steps to Reproduce: >1. Revert the latest commit to webkitgtk4 which disables parallel build >2. fedpkg build webkitgtk4 > > >Actual results: >https://kojipkgs.fedoraproject.org//work/tasks/2915/9132915/build.log > >The interesting part is this: > >[ 15%] cd >/builddir/build/BUILD/webkitgtk-2.7.91/x86_64-redhat-linux-gnu/DerivedSources/WebCore >&& /usr/bin/perl >-I/builddir/build/BUILD/webkitgtk-2.7.91/Source/WebCore/bindings/scripts >/builddir/build/BUILD/webkitgtk-2.7.91/Source/WebCore/css/makeprop.pl >--defines >" ENABLE_3D_RENDERING ENABLE_ACCELERATED_2D_CANVAS ENABLE_ACCESSIBILITY >ENABLE_CHANNEL_MESSAGING ENABLE_CONTEXT_MENUS >ENABLE_CSS_BOX_DECORATION_BREAK >ENABLE_CSS_IMAGE_SET ENABLE_CSS_REGIONS ENABLE_CSS_SELECTORS_LEVEL4 >ENABLE_DETAILS_ELEMENT ENABLE_DRAG_SUPPORT ENABLE_FULLSCREEN_API >ENABLE_GEOLOCATION ENABLE_ICONDATABASE ENABLE_INPUT_TYPE_COLOR >ENABLE_JIT >ENABLE_LEGACY_VENDOR_PREFIXES ENABLE_MATHML >ENABLE_MEDIA_CONTROLS_SCRIPT >ENABLE_MEMORY_SAMPLER ENABLE_METER_ELEMENT ENABLE_MHTML >ENABLE_NAVIGATOR_HWCONCURRENCY ENABLE_NETSCAPE_PLUGIN_API >ENABLE_NETWORK_PROCESS ENABLE_NOTIFICATIONS ENABLE_PICTURE_SIZES >ENABLE_PROMISES ENABLE_REQUEST_ANIMATION_FRAME >ENABLE_SATURATED_LAYOUT_ARITHMETIC ENABLE_SPELLCHECK ENABLE_STREAMS_API >ENABLE_SVG_FONTS ENABLE_TEMPLATE_ELEMENT ENABLE_TOUCH_EVENTS >ENABLE_USERSELECT_ALL ENABLE_USER_MESSAGE_HANDLERS ENABLE_VIDEO >ENABLE_VIDEO_TRACK ENABLE_VIEW_MODE_CSS_MEDIA ENABLE_WEB_AUDIO >ENABLE_WEB_SOCKETS ENABLE_WEB_TIMING ENABLE_WEBGL ENABLE_XHR_TIMEOUT >ENABLE_XSLT ENABLE_PLUGIN_PROCESS_GTK2" --preprocessor "/usr/bin/c++ -E > >-P -x >c++" >/usr/bin/cmake -E cmake_progress_report >/builddir/build/BUILD/webkitgtk-2.7.91/x86_64-redhat-linux-gnu/CMakeFiles >/usr/bin/cmake -E cmake_progress_report >/builddir/build/BUILD/webkitgtk-2.7.91/x86_64-redhat-linux-gnu/CMakeFiles >/usr/bin/cmake -E cmake_progress_report >/builddir/build/BUILD/webkitgtk-2.7.91/x86_64-redhat-linux-gnu/CMakeFiles >/usr/bin/cmake -E cmake_progress_report >/builddir/build/BUILD/webkitgtk-2.7.91/x86_64-redhat-linux-gnu/CMakeFiles >/usr/bin/cmake -E cmake_progress_report >/builddir/build/BUILD/webkitgtk-2.7.91/x86_64-redhat-linux-gnu/CMakeFiles >/usr/bin/cmake -E cmake_progress_report >/builddir/build/BUILD/webkitgtk-2.7.91/x86_64-redhat-linux-gnu/CMakeFiles >[ 15%] [ 15%] [ 15%] [ 15%] [ 15%] Generating >../../DerivedSources/WebCore/SelectorPseudoElementTypeMap.gperf, >../../DerivedSources/WebCore/SelectorPseudoElementTypeMap.cpp >[ 15%] CSSPropertyNames.gperf: The input file is empty! >calling gperf failed: 256 at >/builddir/build/BUILD/webkitgtk-2.7.91/Source/WebCore/css/makeprop.pl >line >1032. >Source/WebCore/CMakeFiles/WebCore.dir/build.make:155: recipe for target >'DerivedSources/WebCore/CSSPropertyNames.h' failed >make[2]: *** [DerivedSources/WebCore/CSSPropertyNames.h] Error 25 >make[2]: *** Waiting for unfinished jobs... > >Line 1032 of makeprop.pl: > >system("\"$gperf\" --key-positions=\"*\" -D -n -s 2 >CSSPropertyNames.gperf >--output-file=CSSPropertyNames.cpp") == 0 || die "calling gperf failed: >$?"; > >So I guess CSSPropertyNames.gperf has not been built yet. Oh, but that >file is >built by makeprop.pl, beginning with line 113: > >open GPERF, ">CSSPropertyNames.gperf" || die "Could not open >CSSPropertyNames.gperf for writing"; > >So it doesn't SEEM like a CMake dependency issue... but the script is a > >mess to >read, and I can imagine it not working if CSSPropertyNames.in was not >properly >generated. > >Now, in WebKit/Source/WebCore/CMakeLists.txt we have this: > ># Generate CSS property names >add_custom_command( > OUTPUT ${DERIVED_SOURCES_WEBCORE_DIR}/CSSPropertyNames.in >${DERIVED_SOURCES_WEBCORE_DIR}/CSSPropertyNames.h >${DERIVED_SOURCES_WEBCORE_DIR}/CSSPropertyNames.cpp >${DERIVED_SOURCES_WEBCORE_DIR}/CSSPropertyNames.gperf >${DERIVED_SOURCES_WEBCORE_DIR}/StyleBuilder.cpp >${DERIVED_SOURCES_WEBCORE_DIR}/StylePropertyShorthandFunctions.h >${DERIVED_SOURCES_WEBCORE_DIR}/StylePropertyShorthandFunctions.cpp > MAIN_DEPENDENCY ${WEBCORE_DIR}/css/makeprop.pl > DEPENDS ${WebCore_CSS_PROPERTY_NAMES} > WORKING_DIRECTORY ${DERIVED_SOURCES_WEBCORE_DIR} > COMMAND ${PERL_EXECUTABLE} -ne "print" ${WebCore_CSS_PROPERTY_NAMES} > >${DERIVED_SOURCES_WEBCORE_DIR}/CSSPropertyNames.in > COMMAND ${PERL_EXECUTABLE} -I${WEBCORE_DIR}/bindings/scripts >${WEBCORE_DIR}/css/makeprop.pl --defines >"${FEATURE_DEFINES_WITH_SPACE_SEPARATOR}" --preprocessor >"${CODE_GENERATOR_PREPROCESSOR}" > VERBATIM) >list(APPEND WebCore_SOURCES >${DERIVED_SOURCES_WEBCORE_DIR}/CSSPropertyNames.cpp) >list(APPEND WebCore_SOURCES >${DERIVED_SOURCES_WEBCORE_DIR}/StyleBuilder.cpp) >list(APPEND WebCore_SOURCES >${DERIVED_SOURCES_WEBCORE_DIR}/StylePropertyShorthandFunctions.cpp) >ADD_SOURCE_WEBCORE_DERIVED_DEPENDENCIES(${WEBCORE_DIR}/css/CSSParser.cpp >CSSValueKeywords.h) >ADD_SOURCE_WEBCORE_DERIVED_DEPENDENCIES(${DERIVED_SOURCES_WEBCORE_DIR}/CSSGrammar.cpp >CSSPropertyNames.h) > >Simple, right? :p > >And also: > >set(WebCore_CSS_PROPERTY_NAMES > ${WEBCORE_DIR}/css/CSSPropertyNames.in >) > >...looks right? At least, I don't notice anything wrong there. But I do > >notice >higher up in the build log: > >[ 15%] [ 15%] [ 15%] Generating >../../DerivedSources/WebCore/CSSPropertyNames.in, >../../DerivedSources/WebCore/CSSPropertyNames.h, >../../DerivedSources/WebCore/CSSPropertyNames.cpp, >../../DerivedSources/WebCore/CSSPropertyNames.gperf, >../../DerivedSources/WebCore/StyleBuilder.cpp, >../../DerivedSources/WebCore/StylePropertyShorthandFunctions.h, >../../DerivedSources/WebCore/StylePropertyShorthandFunctions.cpp >cd >/builddir/build/BUILD/webkitgtk-2.7.91/x86_64-redhat-linux-gnu/DerivedSources/WebCore >&& /usr/bin/perl -ne print >/builddir/build/BUILD/webkitgtk-2.7.91/Source/WebCore/css/CSSPropertyNames.in > > > >/builddir/build/BUILD/webkitgtk-2.7.91/x86_64-redhat-linux-gnu/DerivedSources/WebCore/CSSPropertyNames.in >Generating ../../DerivedSources/WebCore/CSSPropertyNames.in, >../../DerivedSources/WebCore/CSSPropertyNames.h, >../../DerivedSources/WebCore/CSSPropertyNames.cpp, >../../DerivedSources/WebCore/CSSPropertyNames.gperf, >../../DerivedSources/WebCore/StyleBuilder.cpp, >../../DerivedSources/WebCore/StylePropertyShorthandFunctions.h, >../../DerivedSources/WebCore/StylePropertyShorthandFunctions.cpp >cd >/builddir/build/BUILD/webkitgtk-2.7.91/x86_64-redhat-linux-gnu/DerivedSources/WebCore >&& /usr/bin/perl -ne print >/builddir/build/BUILD/webkitgtk-2.7.91/Source/WebCore/css/CSSPropertyNames.in > > > >/builddir/build/BUILD/webkitgtk-2.7.91/x86_64-redhat-linux-gnu/DerivedSources/WebCore/CSSPropertyNames.in >Generating ../../DerivedSources/WebCore/CSSPropertyNames.in, >../../DerivedSources/WebCore/CSSPropertyNames.h, >../../DerivedSources/WebCore/CSSPropertyNames.cpp, >../../DerivedSources/WebCore/CSSPropertyNames.gperf, >../../DerivedSources/WebCore/StyleBuilder.cpp, >../../DerivedSources/WebCore/StylePropertyShorthandFunctions.h, >../../DerivedSources/WebCore/StylePropertyShorthandFunctions.cpp >cd >/builddir/build/BUILD/webkitgtk-2.7.91/x86_64-redhat-linux-gnu/DerivedSources/WebCore >&& /usr/bin/perl -ne print >/builddir/build/BUILD/webkitgtk-2.7.91/Source/WebCore/css/CSSPropertyNames.in > > > >/builddir/build/BUILD/webkitgtk-2.7.91/x86_64-redhat-linux-gnu/DerivedSources/WebCore/CSSPropertyNames.in >/usr/bin/cmake -E cmake_progress_report >/builddir/build/BUILD/webkitgtk-2.7.91/x86_64-redhat-linux-gnu/CMakeFiles >Generating ../../DerivedSources/WebCore/CSSPropertyNames.in, >../../DerivedSources/WebCore/CSSPropertyNames.h, >../../DerivedSources/WebCore/CSSPropertyNames.cpp, >../../DerivedSources/WebCore/CSSPropertyNames.gperf, >../../DerivedSources/WebCore/StyleBuilder.cpp, >../../DerivedSources/WebCore/StylePropertyShorthandFunctions.h, >../../DerivedSources/WebCore/StylePropertyShorthandFunctions.cpp >/usr/bin/cmake -E cmake_progress_report >/builddir/build/BUILD/webkitgtk-2.7.91/x86_64-redhat-linux-gnu/CMakeFiles >cd >/builddir/build/BUILD/webkitgtk-2.7.91/x86_64-redhat-linux-gnu/DerivedSources/WebCore >&& /usr/bin/perl -ne print >/builddir/build/BUILD/webkitgtk-2.7.91/Source/WebCore/css/CSSPropertyNames.in > > > >/builddir/build/BUILD/webkitgtk-2.7.91/x86_64-redhat-linux-gnu/DerivedSources/WebCore/CSSPropertyNames.in > >Um, that command is run four times instead of once! And that is as far >as I've >gotten, but I guess that must be a CMake bug. From Pere.Mato at cern.ch Fri Mar 6 04:22:50 2015 From: Pere.Mato at cern.ch (Pere Mato Vila) Date: Fri, 6 Mar 2015 09:22:50 +0000 Subject: [CMake] Wrong behavior with 3.2.0-rc2 Message-ID: Using version 3.2.0-rc2 on the Mac OS X 10.10 with the make generator. The following example executes the custom to create A.txt and B.txt twice when building with make -jN ????????- cmake_minimum_required(VERSION 2.8.8 FATAL_ERROR) add_custom_target(Main ALL DEPENDS A.txt B.txt) add_custom_command(OUTPUT A.txt B.txt COMMAND touch A.txt COMMAND touch B.txt) ????????- $ make clean $ make -j10 -- Configuring done -- Generating done -- Build files have been written to: /Users/mato/Development/ROOT/build.master/temp [100%] [100%] Generating A.txt, B.txt Generating A.txt, B.txt [100%] Built target Main This is not the case for version 3.1.3. Cheers, Pere ------------------------------------------------------------- Pere Mato CERN, PH Department, CH 1211 Geneva 23, Switzerland e-mail: pere.mato at cern.ch tel: +41 22 76 78696 fax: +41 22 76 68792 gsm: +41 76 48 70855 -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.molcard at arturia.com Fri Mar 6 06:14:02 2015 From: kevin.molcard at arturia.com (Kevin MOLCARD) Date: Fri, 06 Mar 2015 12:14:02 +0100 Subject: [CMake] How to activate SSE2 only for Win32 architecture build Message-ID: <54F98BFA.6080705@arturia.com> Hi all, I would like to activate sse2 on my Windows build but only for 32 bit. I am using the foolowing code: SET(CMAKE_CXX_FLAGS "/arch:SSE2") However, this generates a warning for x64 build: ignoring unknown option '/arch:SSE2' Indeed, this is not needed for x64 because SSE2 is activated by default for the architecture. Does anyone know how to activate this flag only for Win32 build? Thanks in advance Kevin From nilsgladitz at gmail.com Fri Mar 6 06:57:04 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 06 Mar 2015 12:57:04 +0100 Subject: [CMake] Wrong behavior with 3.2.0-rc2 In-Reply-To: References: Message-ID: <54F99610.7070503@gmail.com> On 03/06/2015 10:22 AM, Pere Mato Vila wrote: > Using version 3.2.0-rc2 on the Mac OS X 10.10 with the make generator. > The following example executes the custom to create A.txt and B.txt > twice when building with make -jN > > ????????- > cmake_minimum_required(VERSION 2.8.8 FATAL_ERROR) > add_custom_target(Main ALL DEPENDS A.txt B.txt) > add_custom_command(OUTPUT A.txt B.txt > COMMAND touch A.txt > COMMAND touch B.txt) > > ????????- > $ make clean > $ make -j10 > -- Configuring done > -- Generating done > -- Build files have been written to: > /Users/mato/Development/ROOT/build.master/temp > [100%] [100%] *Generating A.txt, B.txt* > *Generating A.txt, B.txt* > [100%] Built target Main > > > This is not the case for version 3.1.3. This seems to be the case since [644b4688d71cc52f8499d6103495de0909319557] Makefile: Fix rebuild with multiple custom command outputs (#15116) Nils From jzakrzewski at e2e.ch Fri Mar 6 06:55:43 2015 From: jzakrzewski at e2e.ch (Jakub Zakrzewski) Date: Fri, 6 Mar 2015 11:55:43 +0000 Subject: [CMake] How to activate SSE2 only for Win32 architecture build In-Reply-To: <54F98BFA.6080705@arturia.com> References: <54F98BFA.6080705@arturia.com> Message-ID: > I would like to activate sse2 on my Windows build but only for 32 bit. > I am using the foolowing code: > SET(CMAKE_CXX_FLAGS "/arch:SSE2") > Does anyone know how to activate this flag only for Win32 build? Maybe like that: if(CMAKE_SIZEOF_VOID_P EQUAL 4) # 32-bit SET(CMAKE_CXX_FLAGS "/arch:SSE2") endif() From kevin.molcard at arturia.com Fri Mar 6 07:28:24 2015 From: kevin.molcard at arturia.com (Kevin MOLCARD) Date: Fri, 06 Mar 2015 13:28:24 +0100 Subject: [CMake] How to activate SSE2 only for Win32 architecture build In-Reply-To: References: <54F98BFA.6080705@arturia.com> Message-ID: <54F99D68.6080601@arturia.com> Thanks, this worked like a charm. On 3/6/15 12:55 PM, Jakub Zakrzewski wrote: >> I would like to activate sse2 on my Windows build but only for 32 bit. >> I am using the foolowing code: >> SET(CMAKE_CXX_FLAGS "/arch:SSE2") >> Does anyone know how to activate this flag only for Win32 build? > Maybe like that: > > if(CMAKE_SIZEOF_VOID_P EQUAL 4) # 32-bit > SET(CMAKE_CXX_FLAGS "/arch:SSE2") > endif() -- Kevin Molcard Senior Software Engineer t.+33 438 020 555 ? f.+33 438 020 525 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Logo-Baseline-0.15x.png Type: image/png Size: 9430 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature_img.png Type: image/png Size: 42873 bytes Desc: not available URL: From phil at voltage.com Fri Mar 6 10:51:29 2015 From: phil at voltage.com (Phil Smith) Date: Fri, 6 Mar 2015 07:51:29 -0800 Subject: [CMake] CMake "permission denied" problem (Windows 7 64-bit, CMake 2.8.1) Message-ID: <84BCCD71182F0046BCD2FB054FE52379183FBAD5C1@HQMAILSVR02.voltage.com> OK, so I know the first thing people will ask is "Why are you using CMake 2.8.1?" and the answer to that is that later versions hang silently for us. The consensus is that the hangs seem to be related to out-of-source builds, which we're currently doing because of a series of dependencies that we have not been able to work around (yet?). We're cross-compiling for z/OS on Windows using the Dignus cross-compiler. So that may make us unique right there. Anyway, we've had this all working for years. Recently we had a problem with compiles suddenly taking a long time. After much mucking about, I wound up installing gawk and using it to prefix verbose messages (sure would be nice if CMake prefixed messages with a timestamp-it's hardly going to hurt, and is often useful). That led me to understand the problem I was having, which was that some old stuff in our build scaffolding was putting -I\\ in the command line to our compiler, which was then trying to do a network access, which was timing out. For each module. So I fixed that, and the rest of the team is happily compiling. But at some point in the process-alas, I'm not sure when, because in my testing I was mostly just doing builds without rerunning CMake-I stopped being able to run CMake. It fails on the assemble step (Dignus is a two-step compiler, which is the reason for part of our scaffolding) when it tries to assemble the output of the C compiler, with "Permission denied" on the assembler source: C:\SVN\zFPE6\CMakeFiles\CMakeTmp\testCCompiler.zASM(1) : Assembly aborted, Fatal Error-DASM413C Unable to open INPUT file: testCCompiler.zASM : Permission denied Here's what I really don't get: that assembler source is there, i.e., has a non-zero length. I've trapped the process immediately after the assembler complains, and saved that directory tree by renaming it (CMake tends to delete the CMakeFiles\CMakeTmp contents), and nothing I do will read the file. I can chmod and chown it to my heart's content; I can reboot-still unreadable. I ran sysinternals and could see it being denied, but didn't see anything else around that event that seemed to relate. I've uninstalled and reinstalled Cygwin and CMake. The only changes I can think of that I made along the way were the gawk installation (which I backed off early in the debugging process, and have not reinstalled) and WinMerge, which I've also uninstalled. I've spent a lot of time Googling, and while I feel a kinship with the many folks who have had somewhat similar-sounding "Permission denied" problems, none seem to be at the same level. I'm out of ideas here, hoping someone else has some! TIA. -- ...phsiii -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil at voltage.com Fri Mar 6 12:34:10 2015 From: phil at voltage.com (Phil Smith) Date: Fri, 6 Mar 2015 09:34:10 -0800 Subject: [CMake] CMake "permission denied" problem (Windows 7 64-bit, CMake 2.8.1) In-Reply-To: <496B18DE-0673-458D-9BD0-3F04171B4B85@dignus.com> References: <84BCCD71182F0046BCD2FB054FE52379183FBAD5C1@HQMAILSVR02.voltage.com> <496B18DE-0673-458D-9BD0-3F04171B4B85@dignus.com> Message-ID: <84BCCD71182F0046BCD2FB054FE52379183FBAD61E@HQMAILSVR02.voltage.com> Followup to problem, a colleague asked: >You mentioned that you had adjusted permissions on the file, but the permissions have be correct all along the path - you might want to check the parent directories to ensure their permissions are right. I should have noted originally: I did check the whole path. And I did try a command prompt run as Administrator. All permissions good, no joy as admin. >The compiler must have had permission to write the file ? I?m guessing CMake copied it somewhere?? No idea what CMake did ? that?s part of the problem! The dasm command is: C:\Progra~2\Dignus\dasm.exe "-L\IBMinclude\SYS1.MACLIB\&M" "-L\IBMinclude\SYS1.MODGEN\&M" "-L\IBMinclude\DSNA10.SDSNMACS\&M" "-L\IBMinclude\CEE.SCEEMAC\&M" "-L\IBMinclude\CEE.SCEESAMP\&M" "-L\IBMinclude\CICS.SDFHMAC\&M" "-L\IBMinclude\DBCOLE.XDCZ1D.XDCMACS\&M" "-L\IBMinclude\DSNA10.SDSNMACS\&M" "-L&p\src\zProtect\asm\&M.mac" "-L&p\src\ra\&M.mac" "-LC:\SVN\zFPE6\\asmmacs\&M.mac" "-LC:\Progra~2\Dignus\maclib\&M" -quiet -flisting=testCCompiler.zLST -idr="5694A01 1900" -o CMakeFiles/cmTryCompileExec.dir/testCCompiler.c.o testCCompiler.zASM But since I?m issuing the build command from the directory above CMakeFiles, I can?t tell whether this means that CMake must be copying the file, but I expect it is. So how is it managing to copy it but lock it?! -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.hoffman at kitware.com Fri Mar 6 14:17:42 2015 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Fri, 06 Mar 2015 14:17:42 -0500 Subject: [CMake] CMake "permission denied" problem (Windows 7 64-bit, CMake 2.8.1) In-Reply-To: <84BCCD71182F0046BCD2FB054FE52379183FBAD5C1@HQMAILSVR02.voltage.com> References: <84BCCD71182F0046BCD2FB054FE52379183FBAD5C1@HQMAILSVR02.voltage.com> Message-ID: <54F9FD56.8050004@kitware.com> On 3/6/2015 10:51 AM, Phil Smith wrote: > OK, so I know the first thing people will ask is ?Why are you using > CMake 2.8.1?? and the answer to that is that later versions hang > silently for us. The consensus is that the hangs seem to be related to > out-of-source builds, which we?re currently doing because of a series of > dependencies that we have not been able to work around (yet?). I would be interested in finding out what is wrong with the most recent version. Can you build CMake master from source, then stop it in a debugger when it hangs and send me a stack trace? -Bill From phil at voltage.com Fri Mar 6 14:43:20 2015 From: phil at voltage.com (Phil Smith) Date: Fri, 6 Mar 2015 11:43:20 -0800 Subject: [CMake] CMake "permission denied" problem (Windows 7 64-bit, CMake 2.8.1) References: <84BCCD71182F0046BCD2FB054FE52379183FBAD5C1@HQMAILSVR02.voltage.com> <54F9FD56.8050004@kitware.com> Message-ID: <84BCCD71182F0046BCD2FB054FE52379183FBAD690@HQMAILSVR02.voltage.com> Argh, meant to include the list on this response. I also just downloaded Windows Unlocker, which I've used successfully for similar-seeming problems, and it reports that the file is not locked. So how is it "access denied"?!?! -----Original Message----- From: Phil Smith Sent: Friday, March 06, 2015 2:37 PM To: 'Bill Hoffman' Subject: RE: [CMake] CMake "permission denied" problem (Windows 7 64-bit, CMake 2.8.1) I'm afraid I don't have the tools to build anything for Windows. Nor do I have a debugger for Windows. Nor, to be honest, does it seem like a newer CMake is likely to fix it, since the old version WAS working just fine, and still is for the rest of my team... -----Original Message----- From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Bill Hoffman Sent: Friday, March 06, 2015 2:18 PM To: cmake at cmake.org Subject: Re: [CMake] CMake "permission denied" problem (Windows 7 64-bit, CMake 2.8.1) On 3/6/2015 10:51 AM, Phil Smith wrote: > OK, so I know the first thing people will ask is "Why are you using > CMake 2.8.1?" and the answer to that is that later versions hang > silently for us. The consensus is that the hangs seem to be related to > out-of-source builds, which we're currently doing because of a series of > dependencies that we have not been able to work around (yet?). I would be interested in finding out what is wrong with the most recent version. Can you build CMake master from source, then stop it in a debugger when it hangs and send me a stack trace? -Bill -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake From brad.king at kitware.com Fri Mar 6 15:38:32 2015 From: brad.king at kitware.com (Brad King) Date: Fri, 06 Mar 2015 15:38:32 -0500 Subject: [CMake] Wrong behavior with 3.2.0-rc2 In-Reply-To: <54F99610.7070503@gmail.com> References: <54F99610.7070503@gmail.com> Message-ID: <54FA1048.5070008@kitware.com> On 03/06/2015 06:57 AM, Nils Gladitz wrote: > On 03/06/2015 10:22 AM, Pere Mato Vila wrote: >> [100%] [100%] *Generating A.txt, B.txt* >> *Generating A.txt, B.txt* Thanks for trying the release candidate and reporting this. > This seems to be the case since > [644b4688d71cc52f8499d6103495de0909319557] Makefile: Fix rebuild with > multiple custom command outputs (#15116) Yes. I've re-opened the corresponding issue with a note about this: http://www.cmake.org/Bug/view.php?id=15116#c38168 Please follow that issue for further updates. We've already tagged v3.2.0 but it was not announced yet. It looks like 3.2.0 is DOA and we will have to skip to 3.2.1 to fix this. Thanks, -Brad From phil at voltage.com Fri Mar 6 17:46:28 2015 From: phil at voltage.com (Phil Smith) Date: Fri, 6 Mar 2015 14:46:28 -0800 Subject: [CMake] CMake "permission denied" problem (Windows 7 64-bit, CMake 2.8.1) References: <84BCCD71182F0046BCD2FB054FE52379183FBAD5C1@HQMAILSVR02.voltage.com> <54F9FD56.8050004@kitware.com> Message-ID: <84BCCD71182F0046BCD2FB054FE52379183FBAD710@HQMAILSVR02.voltage.com> More data: I installed LockHunter (http://lockhunter.com/download.htm). It reports that no process has the file locked, but it also offers options to "Unlock and rename" and "Unlock and copy". I can do the first, which fits a vague impression I have that RENAME is easier than other file access. Ah, yes, I just tried RENAME from a command prompt, and it works. But "Unlock and copy" still fails, with a dialog that says: You need permission to perform this action. You require permission from \phsiii to make changes to this file. BUT I am logged in as \phsiii already! I looked at the file and the directories it's in, and it wasn't obvious that I actually had rights to them--but I added Everyone with Full Control, all the way up, and still can't read the file. So this is obviously getting into Windows permissions arcana, not very CMake-ish, but I still figure someone might have an idea...? ...phsiii From phil at voltage.com Fri Mar 6 19:26:26 2015 From: phil at voltage.com (Phil Smith) Date: Fri, 6 Mar 2015 16:26:26 -0800 Subject: [CMake] CMake "permission denied" problem (Windows 7 64-bit, CMake 2.8.1) References: <84BCCD71182F0046BCD2FB054FE52379183FBAD5C1@HQMAILSVR02.voltage.com> <54F9FD56.8050004@kitware.com> Message-ID: <84BCCD71182F0046BCD2FB054FE52379183FBAD72F@HQMAILSVR02.voltage.com> Another approach that I'd like to try: avoiding the CMake "magic" compiles that it uses to determine endianness and bitness. Since those are unlikely to change on our hardware without our noticing, this would work fine. Is it possible? I saw a reference that suggested it was, but haven't found it in the doc yet. It's big endian and 64-bit; ints are 32 bits, doubles are 64 bits. Not sure what else those compiles do? (This also might let us use a current CMake, since IIRC it was the CMake step that hung.) And a note re this: I said before that we were doing out-of-source builds; I meant we're doing in-source builds. It's been years since I had to think about this, sorry. From hobbes1069 at gmail.com Fri Mar 6 21:47:53 2015 From: hobbes1069 at gmail.com (Richard Shaw) Date: Fri, 6 Mar 2015 20:47:53 -0600 Subject: [CMake] Problem with cross-compiling and external projects Message-ID: I've got a cmake based project that can optionally build static versions of most of its dependencies and it works fine on Linux and MSYS2+MinGW. The problem is when I try to cross compile using MinGW on Linux. I would expect cmake would be smart enough to know if the parent project is being built with a particular toolchain that the external projects (also cmake based) would use the same toolchain but that doesn't appear to be what's happening. Is there some setting I'm missing here? I'm currently running 3.0.2 on Fedora linux but this has been happening on 2.8.X as well. Thanks, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From Dave at Yost.com Sat Mar 7 00:21:09 2015 From: Dave at Yost.com (Dave Yost) Date: Fri, 6 Mar 2015 21:21:09 -0800 Subject: [CMake] make output two two streams: concise to stdout and verbose to a file Message-ID: When I do an ordinary make, it would be nice if in addition to the the concise output going to the screen, verbose output would go to a file in the root of the build folder. This way, after the fact I can see exactly what happened with the build I just did. If I have to build again with VERBOSE=1, it?s extra trouble and time, and and the initial condition likelly is different. This feature would be especially convenient in an IDE where setting VERBOSE=1 and then unsetting it again is cumbersome. From DLRdave at aol.com Sat Mar 7 08:29:18 2015 From: DLRdave at aol.com (David Cole) Date: Sat, 7 Mar 2015 08:29:18 -0500 Subject: [CMake] Problem with cross-compiling and external projects In-Reply-To: References: Message-ID: It does not happen automatically, but it is not hard to pass down the tool chain as an additional parameter to the configure step of your external projects. There may be other adjustments necessary, too. I'm not sure, I still haven't done a lot of cross-compiling myself with CMake yet. Cross-compiling came after ExternalProject, took a long time to stabilize into something useful, and only works with certain generators... I guess it makes sense that you'd mostly want to use the toolchain for ExternalProjects. Perhaps it's time for a patch. ;-) The focus with ExternalProject when it was first built was actually to enable building any project, even ones that don't use CMake to drive their builds. The decision was made early on NOT to pass down most CMake settings, so the developer writing the ExternalProject_Add call is the one deciding what needs to be passed down. (Consider, for example, the case of building a set of libraries, both Debug and Release, both Static and Shared, for many architectures, all as part of one overarching superbuild. Passing all those settings down from the parent might make that sort of thing difficult or confusing.) Anyhow, the short answer was, no, CMake doesn't do it automatically. You'll have to do it yourself. I'd recommend having a top level "extra CMake parameters" variable that gets passed to all your ExternalProject_Add calls. HTH, David C. On Friday, March 6, 2015, Richard Shaw wrote: > I've got a cmake based project that can optionally build static versions > of most of its dependencies and it works fine on Linux and MSYS2+MinGW. > > The problem is when I try to cross compile using MinGW on Linux. I would > expect cmake would be smart enough to know if the parent project is being > built with a particular toolchain that the external projects (also cmake > based) would use the same toolchain but that doesn't appear to be what's > happening. > > Is there some setting I'm missing here? > > I'm currently running 3.0.2 on Fedora linux but this has been happening on > 2.8.X as well. > > Thanks, > Richard > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jedwards at ucar.edu Sat Mar 7 10:51:00 2015 From: jedwards at ucar.edu (Jim Edwards) Date: Sat, 7 Mar 2015 08:51:00 -0700 Subject: [CMake] runtime env variables in ctest Message-ID: I'm trying to pass a variable to ctest that will only be evaluated at runtime. If I hand edit the add_test command I can get it to work, the hand edited add test looks like: add_test(piotest "runjob" "--np" "4" "--block" "$ENV{COBALT_PARTITION}" ":" "/gpfs/piotest") ?But I can't get cmake to generate this line for me, it either evaluates $ENV{COBALT_PARTITION} at build time or it escapes the $ so that I have: add_test(piotest "runjob" "--np" "4" "--block" "\$ENV{COBALT_PARTITION}" ":" "/gpfs/piotest")? ?and it never gets evaluated. The statement I am working with is set(REQUIRED_OPTION --block \$ENV{COBALT_PARTITION} ) set(EXE_CMD ${RUNJOB} ${RUNJOB_NPF} ${REQUIRED_OPTION} ${MPIEXEC_PREFLAGS} : ${_testExe} ${_testArgs})? ?Any ideas?? -- Jim Edwards CESM Software Engineer National Center for Atmospheric Research Boulder, CO -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.j.abraham at gmail.com Sat Mar 7 13:44:48 2015 From: mark.j.abraham at gmail.com (Mark Abraham) Date: Sat, 7 Mar 2015 19:44:48 +0100 Subject: [CMake] runtime env variables in ctest In-Reply-To: References: Message-ID: On Sat, Mar 7, 2015 at 4:51 PM, Jim Edwards wrote: > I'm trying to pass a variable to ctest that will only be evaluated at > runtime. > If I hand edit the add_test command I can get it to work, the hand edited > add test looks like: > > add_test(piotest "runjob" "--np" "4" "--block" "$ENV{COBALT_PARTITION}" > ":" "/gpfs/piotest") > > ?But I can't get cmake to generate this line for me, it either evaluates > $ENV{COBALT_PARTITION} at build time or it escapes the $ so that I have: > > add_test(piotest "runjob" "--np" "4" "--block" "\$ENV{COBALT_PARTITION}" > ":" "/gpfs/piotest")? > > ?and it never gets evaluated. The statement I am working with is > > set(REQUIRED_OPTION --block \$ENV{COBALT_PARTITION} ) > Try set(REQUIRED_OPTION "--block \$ENV{COBALT_PARTITION}") That way you inhibit the variable expansion at CMake time, but the output of the expansion has had a level of indirection removed, in the usual shell-script way. Then I expect add_test will look like your hand-edited version. set(EXE_CMD ${RUNJOB} ${RUNJOB_NPF} ${REQUIRED_OPTION} > ${MPIEXEC_PREFLAGS} : ${_testExe} ${_testArgs})? > FindMPI.cmake has a set of somewhat standard variable names that might make sense for you to follow, even though that module probably won't be useful for finding runjob, because it might do so at some future time. Mark > ?Any ideas?? > > > -- > Jim Edwards > > CESM Software Engineer > National Center for Atmospheric Research > Boulder, CO > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 ryan.pavlik at gmail.com Sat Mar 7 14:52:44 2015 From: ryan.pavlik at gmail.com (Ryan Pavlik) Date: Sat, 07 Mar 2015 19:52:44 +0000 Subject: [CMake] Mastering CMake updated to CMake 3.1 In-Reply-To: References: <54f88ec9.4a70e00a.2d8b.7195SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: Will the excerpted CMake tutorial [1] be updated? I find that to be a useful reference to point newcomers to. If nothing else, it looks like the source code didn't handle the move to the updated website well as all angle-bracket includes got eaten as HTML tags presumably. [1] http://www.cmake.org/cmake-tutorial/ Ryan On Thu, Mar 5, 2015 at 12:55 PM Robert Maynard wrote: > Hi, > > We currently have no plans to release the CMake book in an electronic > format. > > On Thu, Mar 5, 2015 at 11:51 AM, Nagy-Egri M??t?? Ferenc < > csiga.biga at aol.com> wrote: > >> Are there any plans on releasing a digital version (e-book) of this >> guide? I very much like reading books on my phablet, as it is always t hand >> and seems a lot more friendly, than a 700+ page book. >> >> *Felad?:* Robert Maynard >> *Elk?ldve:* ?kedd?, ?2015?. ?m?rcius? ?3?. ?22?:?26 >> *C?mzett:* cmake at cmake.org >> > We just wanted to let everyone know that Mastering CMake ( >> http://www.kitware.com/products/books/CMakeBook.html) has been updated >> for version 3.1 and is available on Amazon. >> >> It is also available on Amazon's sites for Spain, the United Kingdom, >> Germany, France, and Italy. Please see >> http://www.kitware.com/products/books.php for the links. >> >> -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 jedwards at ucar.edu Sat Mar 7 20:17:42 2015 From: jedwards at ucar.edu (Jim Edwards) Date: Sat, 7 Mar 2015 18:17:42 -0700 Subject: [CMake] runtime env variables in ctest In-Reply-To: References: Message-ID: That doesn't work, I still end up with the \$ in the CTestTestfile.cmake and the variable unevaluated at runtime. I've been trying all day to get ctest to read a CTestCustom.cmake file but I can't seem to get that working either - how do you use ctest_read_custom_files in a generator command? On Sat, Mar 7, 2015 at 11:44 AM, Mark Abraham wrote: > > > On Sat, Mar 7, 2015 at 4:51 PM, Jim Edwards wrote: > >> I'm trying to pass a variable to ctest that will only be evaluated at >> runtime. >> If I hand edit the add_test command I can get it to work, the hand edited >> add test looks like: >> >> add_test(piotest "runjob" "--np" "4" "--block" "$ENV{COBALT_PARTITION}" >> ":" "/gpfs/piotest") >> >> ?But I can't get cmake to generate this line for me, it either evaluates >> $ENV{COBALT_PARTITION} at build time or it escapes the $ so that I have: >> >> add_test(piotest "runjob" "--np" "4" "--block" "\$ENV{COBALT_PARTITION}" >> ":" "/gpfs/piotest")? >> >> ?and it never gets evaluated. The statement I am working with is >> >> set(REQUIRED_OPTION --block \$ENV{COBALT_PARTITION} ) >> > > Try > > set(REQUIRED_OPTION "--block \$ENV{COBALT_PARTITION}") > > That way you inhibit the variable expansion at CMake time, but the output > of the expansion has had a level of indirection removed, in the usual > shell-script way. Then I expect add_test will look like your hand-edited > version. > > set(EXE_CMD ${RUNJOB} ${RUNJOB_NPF} ${REQUIRED_OPTION} >> ${MPIEXEC_PREFLAGS} : ${_testExe} ${_testArgs})? >> > > FindMPI.cmake has a set of somewhat standard variable names that might > make sense for you to follow, even though that module probably won't be > useful for finding runjob, because it might do so at some future time. > > Mark > > >> ?Any ideas?? >> >> >> -- >> Jim Edwards >> >> CESM Software Engineer >> National Center for Atmospheric Research >> Boulder, CO >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware 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 > -- Jim Edwards CESM Software Engineer National Center for Atmospheric Research Boulder, CO -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.pavlik at gmail.com Sun Mar 8 09:35:50 2015 From: ryan.pavlik at gmail.com (Ryan Pavlik) Date: Sun, 08 Mar 2015 13:35:50 +0000 Subject: [CMake] Multi-platform visual studio projects References: <6FD2E165340D9A429CF831C7A2D4F42E60068FAE@WIN-R92V03RFJ85.onshorecs.local> <6FD2E165340D9A429CF831C7A2D4F42E600691B5@WIN-R92V03RFJ85.onshorecs.local> <6FD2E165340D9A429CF831C7A2D4F42E60069275@WIN-R92V03RFJ85.onshorecs.local> <6FD2E165340D9A429CF831C7A2D4F42E60074FFD@WIN-R92V03RFJ85.onshorecs.local> Message-ID: You are correct: if you're using the visual studio generators it doesn't matter (in general) what your process environment variables are. Note that if you're using find package, some of those scripts use environment variables to help find libraries, but they are not the "standard" variables set by the visual studio command prompt scripts. The command prompt would matter if, for instance, you were using the nmake makefiles generator. Ryan On Wed, Mar 4, 2015, 11:03 AM Scott Aron Bloom wrote: > Another question on this.. > > It appears, that cmake creates the proper solution, for 64 bits even if > the shell is setup for 32 bits, and vice versa. > > Is this correct? Meaning when its checking the C compiler and CXX > compiler ABI info and what not, its not looking for bit width, it uses the > generator "Visual Studio...Win64" vs "Visual Studio" for bit width > > If Im not using a command line based build, does it matter how my command > line is setup for running cmake? > > Scott > > -----Original Message----- > From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Scott Aron Bloom > Sent: Friday, February 27, 2015 8:26 AM > To: John Drescher > Cc: cmake at cmake.org > Subject: Re: [CMake] Multi-platform visual studio projects > > Thanks! > > -----Original Message----- > From: John Drescher [mailto:drescherjm at gmail.com] > Sent: Friday, February 27, 2015 8:26 AM > To: Scott Aron Bloom > Cc: cmake at cmake.org > Subject: Re: [CMake] Multi-platform visual studio projects > > > However, once the solution is created, does the "path" of the shell > matter at all? > > No. > > John > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 scott.bloom at onshorecs.com Sun Mar 8 14:51:54 2015 From: scott.bloom at onshorecs.com (Scott Aron Bloom) Date: Sun, 8 Mar 2015 18:51:54 +0000 Subject: [CMake] Multi-platform visual studio projects In-Reply-To: References: <6FD2E165340D9A429CF831C7A2D4F42E60068FAE@WIN-R92V03RFJ85.onshorecs.local> <6FD2E165340D9A429CF831C7A2D4F42E600691B5@WIN-R92V03RFJ85.onshorecs.local> <6FD2E165340D9A429CF831C7A2D4F42E60069275@WIN-R92V03RFJ85.onshorecs.local> <6FD2E165340D9A429CF831C7A2D4F42E60074FFD@WIN-R92V03RFJ85.onshorecs.local>, Message-ID: That's what I have found as well. Based on that. Why can't call create a 64 and 32 bit solution? It would seem to me, that there is no technical reason. --Scott -------- Original message -------- From: Ryan Pavlik Date:03/08/2015 06:35 (GMT-08:00) To: Scott Aron Bloom , John Drescher Cc: cmake at cmake.org Subject: Re: [CMake] Multi-platform visual studio projects You are correct: if you're using the visual studio generators it doesn't matter (in general) what your process environment variables are. Note that if you're using find package, some of those scripts use environment variables to help find libraries, but they are not the "standard" variables set by the visual studio command prompt scripts. The command prompt would matter if, for instance, you were using the nmake makefiles generator. Ryan On Wed, Mar 4, 2015, 11:03 AM Scott Aron Bloom > wrote: Another question on this.. It appears, that cmake creates the proper solution, for 64 bits even if the shell is setup for 32 bits, and vice versa. Is this correct? Meaning when its checking the C compiler and CXX compiler ABI info and what not, its not looking for bit width, it uses the generator "Visual Studio...Win64" vs "Visual Studio" for bit width If Im not using a command line based build, does it matter how my command line is setup for running cmake? Scott -----Original Message----- From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Scott Aron Bloom Sent: Friday, February 27, 2015 8:26 AM To: John Drescher Cc: cmake at cmake.org Subject: Re: [CMake] Multi-platform visual studio projects Thanks! -----Original Message----- From: John Drescher [mailto:drescherjm at gmail.com] Sent: Friday, February 27, 2015 8:26 AM To: Scott Aron Bloom Cc: cmake at cmake.org Subject: Re: [CMake] Multi-platform visual studio projects > However, once the solution is created, does the "path" of the shell matter at all? No. John -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware 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 DLRdave at aol.com Sun Mar 8 16:57:07 2015 From: DLRdave at aol.com (David Cole) Date: Sun, 8 Mar 2015 16:57:07 -0400 Subject: [CMake] Multi-platform visual studio projects In-Reply-To: References: <6FD2E165340D9A429CF831C7A2D4F42E60068FAE@WIN-R92V03RFJ85.onshorecs.local> <6FD2E165340D9A429CF831C7A2D4F42E600691B5@WIN-R92V03RFJ85.onshorecs.local> <6FD2E165340D9A429CF831C7A2D4F42E60069275@WIN-R92V03RFJ85.onshorecs.local> <6FD2E165340D9A429CF831C7A2D4F42E60074FFD@WIN-R92V03RFJ85.onshorecs.local> Message-ID: There is no technical reason... But it seems to me there is a strong bias toward single-architecture build trees in the minds of non-VS/non-XCode developers. There is rampant code like this in the world: if(CMAKE_SIZEOF_VOID_P EQUAL 8) # do 64-bit stuff at CMake time else() # do 32-bit stuff endif() Code like this assumes the architecture is determined at configure time rather than at build time. Very similar to using CMAKE_BUILD_TYPE in CMake code geared toward a single-config build. A lot of (some would say too much) effort over the years was required to get multi-configuration builds working well for VS. Unfortunately, a similar approach was not followed for the architecture types, and we've ended up with a proliferation of generators, and now the concept of toolsets, but still the restriction that a generated solution and set of project files is only of a single architecture. Hope this helps to explain the situation a bit. I know it's not what you wanted to hear, but, from my perspective, that's the way things are. If you'd like to work on improving the situation...... I'm sure your efforts would be welcomed by many. ;-) Cheers, David C. On Sunday, March 8, 2015, Scott Aron Bloom wrote: > That's what I have found as well. > > Based on that. Why can't call create a 64 and 32 bit solution? > > It would seem to me, that there is no technical reason. > > > --Scott > > > -------- Original message -------- > From: Ryan Pavlik > > Date:03/08/2015 06:35 (GMT-08:00) > To: Scott Aron Bloom >, John > Drescher > > Cc: cmake at cmake.org > Subject: Re: [CMake] Multi-platform visual studio projects > > You are correct: if you're using the visual studio generators it doesn't > matter (in general) what your process environment variables are. Note that > if you're using find package, some of those scripts use environment > variables to help find libraries, but they are not the "standard" variables > set by the visual studio command prompt scripts. > > The command prompt would matter if, for instance, you were using the nmake > makefiles generator. > > Ryan > > On Wed, Mar 4, 2015, 11:03 AM Scott Aron Bloom > wrote: > >> Another question on this.. >> >> It appears, that cmake creates the proper solution, for 64 bits even if >> the shell is setup for 32 bits, and vice versa. >> >> Is this correct? Meaning when its checking the C compiler and CXX >> compiler ABI info and what not, its not looking for bit width, it uses the >> generator "Visual Studio...Win64" vs "Visual Studio" for bit width >> >> If Im not using a command line based build, does it matter how my command >> line is setup for running cmake? >> >> Scott >> >> -----Original Message----- >> From: CMake [mailto:cmake-bounces at cmake.org >> ] On Behalf Of >> Scott Aron Bloom >> Sent: Friday, February 27, 2015 8:26 AM >> To: John Drescher >> Cc: cmake at cmake.org >> Subject: Re: [CMake] Multi-platform visual studio projects >> >> Thanks! >> >> -----Original Message----- >> From: John Drescher [mailto:drescherjm at gmail.com >> ] >> Sent: Friday, February 27, 2015 8:26 AM >> To: Scott Aron Bloom >> Cc: cmake at cmake.org >> Subject: Re: [CMake] Multi-platform visual studio projects >> >> > However, once the solution is created, does the "path" of the shell >> matter at all? >> >> No. >> >> John >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware 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 rjvbertin at gmail.com Sun Mar 8 17:42:09 2015 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Sun, 08 Mar 2015 22:42:09 +0100 Subject: [CMake] repetitive path gives filename too long errors Message-ID: <21626133.El99sX0Fc8@portia.local> Hello, I'm struggling with the py-pykde4 package, which is giving me filename overflows due to constructing a path that contains repetitions of itself. I first ran into this in November, have since updated to CMake 3.1.2, and now see that the issue hasn't been solved: https://mail.kde.org/pipermail/kde-mac/2014-November/002404.html and that I'm not the only one: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=750231 I saw a hint that using Ninja might avoid the issue, and indeed the cmake step works fine with that generator. However: %> (cd py27-pykde4-mp9-work/build/ ; ninja) /Volumes/Debian/MP9/var/macports/build/_Volumes_Debian_MP9_site-ports_python_py-pykde4/py27-pykde4/work/build ninja: error: stat(_Volumes_Debian_MP9_var_macports_build__Volumes_Debian_MP9_site-ports_python_py-pykde4_py27-pykde4_work_build__Volumes_Debian_MP9_var_macports_build__Volumes_Debian_MP9_site-ports_python_py-pykde4_py27-pykde4_work_build__Volumes_Debian_MP9_var_macports_build__Volumes_Debian_MP9_site-ports_python_py-pykde4_py27-pykde4_work_build_pykdeconfig.pyc): File name too long ninja: error: stat(CMakeFiles/_Volumes_Debian_MP9_var_macports_build__Volumes_Debian_MP9_site-ports_python_py-pykde4_py27-pykde4_work_build__Volumes_Debian_MP9_var_macports_build__Volumes_Debian_MP9_site-ports_python_py-pykde4_py27-pykde4_work_build__Volumes_Debian_MP9_var_macports_build__Volumes_Debian_MP9_site-ports_python_py-pykde4_py27-pykde4_work_build_pykdeconfig.pyc.util): File name too long ninja: error: stat(CMakeFiles/_Volumes_Debian_MP9_var_macports_build__Volumes_Debian_MP9_site-ports_python_py-pykde4_py27-pykde4_work_build__Volumes_Debian_MP9_var_macports_build__Volumes_Debian_MP9_site-ports_python_py-pykde4_py27-pykde4_work_build__Volumes_Debian_MP9_var_macports_build__Volumes_Debian_MP9_site-ports_python_py-pykde4_py27-pykde4_work_build_pykdeconfig.pyc.util): File name too long ninja: error: stat(CMakeFiles/_Volumes_Debian_MP9_var_macports_build__Volumes_Debian_MP9_site-ports_python_py-pykde4_py27-pykde4_work_build__Volumes_Debian_MP9_var_macports_build__Volumes_Debian_MP9_site-ports_python_py-pykde4_py27-pykde4_work_build__Volumes_Debian_MP9_var_macports_build__Volumes_Debian_MP9_site-ports_python_py-pykde4_py27-pykde4_work_build_pykdeconfig.pyc.util): File name too long (etc) Is this because of an error in pykde4's CMake files, or is this an unavoidable side-effect of the way CMake works? NB: I tried setting pykde4_SOURCE_DIR and pykde4_BINARY_DIR on the commandline, but that had no effect (other than that the values appeared in CMakeCache.txt). Thanks, Ren? From scott.bloom at onshorecs.com Sun Mar 8 18:17:24 2015 From: scott.bloom at onshorecs.com (Scott Aron Bloom) Date: Sun, 8 Mar 2015 22:17:24 +0000 Subject: [CMake] Multi-platform visual studio projects In-Reply-To: References: <6FD2E165340D9A429CF831C7A2D4F42E60068FAE@WIN-R92V03RFJ85.onshorecs.local> <6FD2E165340D9A429CF831C7A2D4F42E600691B5@WIN-R92V03RFJ85.onshorecs.local> <6FD2E165340D9A429CF831C7A2D4F42E60069275@WIN-R92V03RFJ85.onshorecs.local> <6FD2E165340D9A429CF831C7A2D4F42E60074FFD@WIN-R92V03RFJ85.onshorecs.local> , Message-ID: <9rtreasg9f0ihnd2j49nr2ic.1425853042558@email.android.com> Agreed on all points.. Unfortunately... ;) I remember going through this with qmake, which initially could not create a debug and release vc project file... --Scott -------- Original message -------- From: David Cole Date:03/08/2015 13:57 (GMT-08:00) To: Scott Aron Bloom Cc: Ryan Pavlik , John Drescher , cmake at cmake.org Subject: Re: [CMake] Multi-platform visual studio projects There is no technical reason... But it seems to me there is a strong bias toward single-architecture build trees in the minds of non-VS/non-XCode developers. There is rampant code like this in the world: if(CMAKE_SIZEOF_VOID_P EQUAL 8) # do 64-bit stuff at CMake time else() # do 32-bit stuff endif() Code like this assumes the architecture is determined at configure time rather than at build time. Very similar to using CMAKE_BUILD_TYPE in CMake code geared toward a single-config build. A lot of (some would say too much) effort over the years was required to get multi-configuration builds working well for VS. Unfortunately, a similar approach was not followed for the architecture types, and we've ended up with a proliferation of generators, and now the concept of toolsets, but still the restriction that a generated solution and set of project files is only of a single architecture. Hope this helps to explain the situation a bit. I know it's not what you wanted to hear, but, from my perspective, that's the way things are. If you'd like to work on improving the situation...... I'm sure your efforts would be welcomed by many. ;-) Cheers, David C. On Sunday, March 8, 2015, Scott Aron Bloom > wrote: That's what I have found as well. Based on that. Why can't call create a 64 and 32 bit solution? It would seem to me, that there is no technical reason. --Scott -------- Original message -------- From: Ryan Pavlik Date:03/08/2015 06:35 (GMT-08:00) To: Scott Aron Bloom , John Drescher Cc: cmake at cmake.org Subject: Re: [CMake] Multi-platform visual studio projects You are correct: if you're using the visual studio generators it doesn't matter (in general) what your process environment variables are. Note that if you're using find package, some of those scripts use environment variables to help find libraries, but they are not the "standard" variables set by the visual studio command prompt scripts. The command prompt would matter if, for instance, you were using the nmake makefiles generator. Ryan On Wed, Mar 4, 2015, 11:03 AM Scott Aron Bloom wrote: Another question on this.. It appears, that cmake creates the proper solution, for 64 bits even if the shell is setup for 32 bits, and vice versa. Is this correct? Meaning when its checking the C compiler and CXX compiler ABI info and what not, its not looking for bit width, it uses the generator "Visual Studio...Win64" vs "Visual Studio" for bit width If Im not using a command line based build, does it matter how my command line is setup for running cmake? Scott -----Original Message----- From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Scott Aron Bloom Sent: Friday, February 27, 2015 8:26 AM To: John Drescher Cc: cmake at cmake.org Subject: Re: [CMake] Multi-platform visual studio projects Thanks! -----Original Message----- From: John Drescher [mailto:drescherjm at gmail.com] Sent: Friday, February 27, 2015 8:26 AM To: Scott Aron Bloom Cc: cmake at cmake.org Subject: Re: [CMake] Multi-platform visual studio projects > However, once the solution is created, does the "path" of the shell matter at all? No. John -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware 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 kl222 at 126.com Mon Mar 9 03:19:06 2015 From: kl222 at 126.com (kl222) Date: Mon, 9 Mar 2015 15:19:06 +0800 (CST) Subject: [CMake] How do cmake install shared library? In-Reply-To: <21626133.El99sX0Fc8@portia.local> References: <21626133.El99sX0Fc8@portia.local> Message-ID: <2e582835.352.14bfd66c81a.Coremail.kl222@126.com> Hello all: I have somethird-partydynamic librariesin the lib directory,how can Iinstall it tothe installation directory? lib$ ls -la ??? 1768 drwxrwxr-x 3 l l 4096 3? 9 13:23 . drwxrwxr-x 4 l l 4096 3? 9 13:23 .. lrwxrwxrwx 1 l l 17 3? 9 13:23 libqxmpp.so -> libqxmpp.so.0.8.3 lrwxrwxrwx 1 l l 17 3? 9 13:23 libqxmpp.so.0 -> libqxmpp.so.0.8.3 lrwxrwxrwx 1 l l 17 3? 9 13:23 libqxmpp.so.0.8 -> libqxmpp.so.0.8.3 -rwxr-xr-x 1 l l 1797032 3? 9 13:23 libqxmpp.so.0.8.3 drwxrwxr-x 2 l l 4096 3? 9 13:25 pkgconfig I was write in CMakeLists.txt : INSTALL(DIRECTORY "${CMAKE_SOURCE_DIR}/ThirdLibary/lib/" DESTINATION "." FILES_MATCHING PATTERN "*.so*") OK! It is install file. But the link file is error: lib$ ls -la lrwxrwxrwx 1 l l 18 3? 9 15:04 libqxmpp.so -> /libqxmpp.so.0.8.3 lrwxrwxrwx 1 l l 18 3? 9 15:04 libqxmpp.so.0 -> /libqxmpp.so.0.8.3 lrwxrwxrwx 1 l l 18 3? 9 15:04 libqxmpp.so.0.8 -> /libqxmpp.so.0.8.3 -rw-r--r-- 1 l l 1796920 3? 9 15:04 libqxmpp.so.0.8.3 What should I do? -------------- next part -------------- An HTML attachment was scrubbed... URL: From Gilles.Khouzam at microsoft.com Mon Mar 9 01:38:50 2015 From: Gilles.Khouzam at microsoft.com (Gilles Khouzam) Date: Mon, 9 Mar 2015 05:38:50 +0000 Subject: [CMake] Multi-platform visual studio projects In-Reply-To: <9rtreasg9f0ihnd2j49nr2ic.1425853042558@email.android.com> References: <6FD2E165340D9A429CF831C7A2D4F42E60068FAE@WIN-R92V03RFJ85.onshorecs.local> <6FD2E165340D9A429CF831C7A2D4F42E600691B5@WIN-R92V03RFJ85.onshorecs.local> <6FD2E165340D9A429CF831C7A2D4F42E60069275@WIN-R92V03RFJ85.onshorecs.local> <6FD2E165340D9A429CF831C7A2D4F42E60074FFD@WIN-R92V03RFJ85.onshorecs.local> , <9rtreasg9f0ihnd2j49nr2ic.1425853042558@email.android.com> Message-ID: For those interested, we have a fork with the ability to support MultiPlatform projects in Visual Studio for Windows Phone and Windows Store apps. It is not a big change to remove that restriction and have it for desktop apps, please tell me if there is interest. For those interested the fork is on http://CMakeMS.codeplex.com and the branch is MSMultiPlatform. As David mentions though, this does have limitations. ~Gilles From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Scott Aron Bloom Sent: Sunday, March 8, 2015 15:17 To: David Cole; Scott Aron Bloom Cc: cmake at cmake.org Subject: Re: [CMake] Multi-platform visual studio projects Agreed on all points.. Unfortunately... ;) I remember going through this with qmake, which initially could not create a debug and release vc project file... --Scott -------- Original message -------- From: David Cole > Date:03/08/2015 13:57 (GMT-08:00) To: Scott Aron Bloom > Cc: Ryan Pavlik >, John Drescher >, cmake at cmake.org Subject: Re: [CMake] Multi-platform visual studio projects There is no technical reason... But it seems to me there is a strong bias toward single-architecture build trees in the minds of non-VS/non-XCode developers. There is rampant code like this in the world: if(CMAKE_SIZEOF_VOID_P EQUAL 8) # do 64-bit stuff at CMake time else() # do 32-bit stuff endif() Code like this assumes the architecture is determined at configure time rather than at build time. Very similar to using CMAKE_BUILD_TYPE in CMake code geared toward a single-config build. A lot of (some would say too much) effort over the years was required to get multi-configuration builds working well for VS. Unfortunately, a similar approach was not followed for the architecture types, and we've ended up with a proliferation of generators, and now the concept of toolsets, but still the restriction that a generated solution and set of project files is only of a single architecture. Hope this helps to explain the situation a bit. I know it's not what you wanted to hear, but, from my perspective, that's the way things are. If you'd like to work on improving the situation...... I'm sure your efforts would be welcomed by many. ;-) Cheers, David C. On Sunday, March 8, 2015, Scott Aron Bloom > wrote: That's what I have found as well. Based on that. Why can't call create a 64 and 32 bit solution? It would seem to me, that there is no technical reason. --Scott -------- Original message -------- From: Ryan Pavlik Date:03/08/2015 06:35 (GMT-08:00) To: Scott Aron Bloom , John Drescher Cc: cmake at cmake.org Subject: Re: [CMake] Multi-platform visual studio projects You are correct: if you're using the visual studio generators it doesn't matter (in general) what your process environment variables are. Note that if you're using find package, some of those scripts use environment variables to help find libraries, but they are not the "standard" variables set by the visual studio command prompt scripts. The command prompt would matter if, for instance, you were using the nmake makefiles generator. Ryan On Wed, Mar 4, 2015, 11:03 AM Scott Aron Bloom wrote: Another question on this.. It appears, that cmake creates the proper solution, for 64 bits even if the shell is setup for 32 bits, and vice versa. Is this correct? Meaning when its checking the C compiler and CXX compiler ABI info and what not, its not looking for bit width, it uses the generator "Visual Studio...Win64" vs "Visual Studio" for bit width If Im not using a command line based build, does it matter how my command line is setup for running cmake? Scott -----Original Message----- From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Scott Aron Bloom Sent: Friday, February 27, 2015 8:26 AM To: John Drescher Cc: cmake at cmake.org Subject: Re: [CMake] Multi-platform visual studio projects Thanks! -----Original Message----- From: John Drescher [mailto:drescherjm at gmail.com] Sent: Friday, February 27, 2015 8:26 AM To: Scott Aron Bloom Cc: cmake at cmake.org Subject: Re: [CMake] Multi-platform visual studio projects > However, once the solution is created, does the "path" of the shell matter at all? No. John -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware 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 Pere.Mato at cern.ch Mon Mar 9 07:59:00 2015 From: Pere.Mato at cern.ch (Pere Mato Vila) Date: Mon, 9 Mar 2015 11:59:00 +0000 Subject: [CMake] Xcode generator ignores shared library made of object libraries Message-ID: <10027F6C-F1C3-447C-B991-D26B23E2CAA8@cern.ch> Hi, I am using cmake version 3.1.3 on MacOSX 10.10.2. I want to build a SHARED library made exclusively of OBJECT libraries. This works well with the Makefile generator but fails with the Xcode generator. To reproduce the problem is very simple: cmake_minimum_required(VERSION 2.8.8 FATAL_ERROR) add_library(FooObjs OBJECT foo.cxx) add_library(Foo SHARED $) add_executable(FooMain main.cxx) target_link_libraries(FooMain Foo) The library libFoo.dylib is never build. I can bypass the problem by adding a dummy.cxx file to the SHARED library, but I am not convinced this is the right solution. Cheers, Pere ------------------------------------------------------------- Pere Mato CERN, PH Department, CH 1211 Geneva 23, Switzerland e-mail: pere.mato at cern.ch tel: +41 22 76 78696 fax: +41 22 76 68792 gsm: +41 76 48 70855 -------------- next part -------------- An HTML attachment was scrubbed... URL: From denisacostaq at gmail.com Mon Mar 9 09:05:03 2015 From: denisacostaq at gmail.com (Alvaro Denis) Date: Mon, 9 Mar 2015 09:05:03 -0400 Subject: [CMake] ExternalProject_Add + find_package Message-ID: Hello, I am using cmake(I am a novice) for a big project, this contain multiple independent projects(no use add_subdirectory), so take an example: Project A depend of B, when I run cmake for A this check for B with find_package(), if this fail the user is notified and need install B, I think that manage this automatically is desirable, I propose ExternalProject_Add, so this download, configure, build and install the dependence automatically but my problem is: When I execute cmake for A this say that B not found, so find this and install, but then the "first" make fail because the first time the "imported targets" are empty, so I need rerun cmake, this time find_package() fill the "imported targets" and build ok. How I can avoid this(execute cmake ; make ; cmake ; make). Thanks a lot. -- [image: --] ALvaro Denis Acosta [image: http://]about.me/denisacostaq -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Mon Mar 9 08:44:01 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Mon, 9 Mar 2015 08:44:01 -0400 Subject: [CMake] Avoid re-linking dependency of external shared lib in a new project. In-Reply-To: References: Message-ID: If it is an external library you will need to look at creating import libraries and packaging targets ( http://www.cmake.org/cmake/help/v3.1/manual/cmake-packages.7.html#manual:cmake-packages(7) ). On Tue, Mar 3, 2015 at 8:10 PM, Pablo Hern?ndez < pablo.hernandez.cerdan at outlook.com> wrote: > I want to generate in cmake a header-only library from header.h, that > depends on libboost_system and filesystem. I can compile the library > without problems with: > > find_package(Boost COMPONENTS > system filesystem > REQUIRED) > include_directories(SYSTEM ${Boost_INCLUDE_DIRS}) > add_library(mylib SHARED header.h) > target_link_libraries(mylib PUBLIC ${Boost_LIBRARIES}) > set_target_properties(mylib PROPERTIES LINKER_LANGUAGE CXX) > > But when I link to mylib elsewhere, it fails finding the boost library > with a ld error. > The failure makes sense, but I don't know how to solve it in CMake. How do > I "store" the boost dependency on mylib? So I don't have to worry about > finding the boost library in other external project? > > I am using cmake 3.2 > When I use it in other project, the linker is not able to find the boost > library: > target_link_libraries(newproject.exe ${external_mylib}) > > undefined reference to symbol '_ZN5boost6system15system_categoryEv'/PATH/TO/libboost_system-mt-d.so.1.57.0: error adding symbols: DSO missing from command line > collect2: error: ld returned 1 exit status > > It is solved if I explicitly link again to the Boost_LIBRARIES. > target_link_libraries(newproject.exe ${external_mylib} ${Boost_LIBRARIES)) > > > This doesn't avoid finding again the boost_libraries, maybe the solution > is to put the boost_libraries in the environment variable LD_LIBRARY_PATH? > Can I avoid relinking to boost somehow? > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 Mon Mar 9 08:56:24 2015 From: gjasny at googlemail.com (Gregor Jasny) Date: Mon, 09 Mar 2015 13:56:24 +0100 Subject: [CMake] Xcode generator ignores shared library made of object libraries In-Reply-To: <10027F6C-F1C3-447C-B991-D26B23E2CAA8@cern.ch> References: <10027F6C-F1C3-447C-B991-D26B23E2CAA8@cern.ch> Message-ID: <54FD9878.9010903@googlemail.com> Hello Pere, On 09/03/15 12:59, Pere Mato Vila wrote: > I am using cmake version 3.1.3 on MacOSX 10.10.2. I want to build a > SHARED library made exclusively of OBJECT libraries. This works well > with the Makefile generator but fails with the Xcode generator. > > To reproduce the problem is very simple: > cmake_minimum_required(VERSION 2.8.8 FATAL_ERROR) > > add_library(FooObjs OBJECT foo.cxx) > add_library(Foo SHARED $) > add_executable(FooMain main.cxx) > target_link_libraries(FooMain Foo) > > > The library libFoo.dylib is never build. I can bypass the problem by > adding a dummy.cxx file to the SHARED library, but I am not convinced > this is the right solution. It looks like you did everything right: From http://www.cmake.org/cmake/help/v3.1/command/add_library.html > Some native build systems may not like targets that have only object files, so consider adding at least one real source file to any target that references $. Thanks, Gregor From brad.king at kitware.com Mon Mar 9 09:20:46 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 09 Mar 2015 09:20:46 -0400 Subject: [CMake] Unexpected warnings with 3.2.0-rc2 In-Reply-To: <94A38EA7-D445-4FEE-BCAE-8E6BF222F12F@cern.ch> References: <94A38EA7-D445-4FEE-BCAE-8E6BF222F12F@cern.ch> Message-ID: <54FD9E2E.6000604@kitware.com> On 03/05/2015 12:55 PM, Pere Mato Vila wrote: > CMake Warning (dev) at cmake/modules/RootConfiguration.cmake:485 (configure_file): > configure_file called with unknown argument(s): > > NEWLINE_STYLE > UNIX Fixed, thanks: configure_file: Do not warn about newline style arguments http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3ef776fc Tests: Add more signature tests to RunCMake.configure_file test http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=024e25e4 -Brad From lfdominguez at estudiantes.uci.cu Mon Mar 9 05:22:30 2015 From: lfdominguez at estudiantes.uci.cu (Luis Felipe Dominguez Vega) Date: Mon, 09 Mar 2015 09:22:30 +0000 Subject: [CMake] [MASSMAIL] ExternalProject_Add + find_package In-Reply-To: References: Message-ID: <3163659.mZoqRJjLhb@envy> GG hello bro.... So who i tell you yesterday i was respond throw this mail, naaa is a joke gg, i was investigating but i dont found anything ....-----------------------------------------------------------On Lunes, 9 de marzo de 2015 09:05:03 AM Alvaro Denis wrote: Hello,I am using cmake(I am a novice) for a big project, this contain multipleindependent projects(no use add_subdirectory), so take an example:Project A depend of B, when I run cmake for A this check for B withfind_package(), if this fail the user is notified and need installB, I think that manage this automatically is desirable, I propose ExternalProject_Add, so this download, configure, build and install thedependence automatically but my problem is:When I execute cmake for A this say that B not found, so find thisand install, but then the "first" make fail because the first time the "imported targets"are empty, so I need rerun cmake, this time find_package()fill the "imported targets" and build ok.How I can avoid this(execute cmake ; make ; cmake ; make).Thanks a lot. -- [1] [2] [3] *ALvaro Denis Acosta* [1]about.me/denisacostaq -------------------- *Luis Felipe Dom?nguez Vega* lfdominguez at estudiantes.uci.cu[4] -------- [1] [2] http://about.me/denisacostaq?promo=email_sig [3] http://d13pix9kaak6wt.cloudfront.net/signature/me-badge.png [4] mailto:lfdominguez at estudiantes.uci.cu -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Type: image/png Size: 0 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From d3ck0r at gmail.com Mon Mar 9 04:18:16 2015 From: d3ck0r at gmail.com (J Decker) Date: Mon, 9 Mar 2015 01:18:16 -0700 Subject: [CMake] How do cmake install shared library? In-Reply-To: <2e582835.352.14bfd66c81a.Coremail.kl222@126.com> References: <21626133.El99sX0Fc8@portia.local> <2e582835.352.14bfd66c81a.Coremail.kl222@126.com> Message-ID: try install( PROGRAMS ) or SCRIPTS ... it loses permission on data files... On Mon, Mar 9, 2015 at 12:19 AM, kl222 wrote: > Hello all: > I have some third-party dynamic libraries in the lib directory, how > can I install it to the installation directory? > > > > > > > > > > *lib$ ls -la??? 1768drwxrwxr-x 3 l l 4096 3? 9 13:23 .drwxrwxr-x 4 l > l 4096 3? 9 13:23 ..lrwxrwxrwx 1 l l 17 3? 9 13:23 libqxmpp.so > -> libqxmpp.so.0.8.3lrwxrwxrwx 1 l l 17 3? 9 13:23 libqxmpp.so.0 -> > libqxmpp.so.0.8.3lrwxrwxrwx 1 l l 17 3? 9 13:23 libqxmpp.so.0.8 -> > libqxmpp.so.0.8.3-rwxr-xr-x 1 l l 1797032 3? 9 13:23 > libqxmpp.so.0.8.3drwxrwxr-x 2 l l 4096 3? 9 13:25 pkgconfig* > > > I was write in CMakeLists.txt : > INSTALL(DIRECTORY "${CMAKE_SOURCE_DIR}/ThirdLibary/lib/" > DESTINATION "." > FILES_MATCHING PATTERN "*.so*") > > OK! It is install file. But the link file is error: > > > > > > *lib$ ls -lalrwxrwxrwx 1 l l 18 3? 9 15:04 libqxmpp.so -> > /libqxmpp.so.0.8.3lrwxrwxrwx 1 l l 18 3? 9 15:04 libqxmpp.so.0 -> > /libqxmpp.so.0.8.3lrwxrwxrwx 1 l l 18 3? 9 15:04 libqxmpp.so.0.8 -> > /libqxmpp.so.0.8.3-rw-r--r-- 1 l l 1796920 3? 9 15:04 libqxmpp.so.0.8.3* > > What should I do? > > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 fenjuan at bios.au.dk Mon Mar 9 11:08:17 2015 From: fenjuan at bios.au.dk (Fenjuan Hu) Date: Mon, 9 Mar 2015 15:08:17 +0000 Subject: [CMake] CMake is re-running due to generate.stamp.list is missing still in CMake 3.2.0, gernerated projects for VS2010+ifort xe2013 Message-ID: Hi all I used CMake 3.2.0 to generated CMake files for VS2010 and ifor13.1 version for my project- Everything was working, until everytime I tried to re-build all the projoctes, I saw the message: CMake is re-running due to generate.stamp.list is missing, and then after re-build, I got piles of dialogue box asking for unload all the projects- HOWEVER, the generate.stamp.list is RIGHT THERE! I know somebody has posted this question before on https://public.kitware.com/Bug/view.php?id=10589. And it is said it's solved in 2.8, but it's stll appeared again again on3 of my different machine. Thanks in advance for your help. Mvh Fen -------------- next part -------------- An HTML attachment was scrubbed... URL: From usenet at majchrowski.de Mon Mar 9 11:27:45 2015 From: usenet at majchrowski.de (Tomasz Majchrowski) Date: Mon, 9 Mar 2015 16:27:45 +0100 Subject: [CMake] control dependencies in cmake stage Message-ID: Hi, I'm wondering if there is an easy way to control the dependencies in the cmake stage. Basically I would like skip execution of some script run over execute_process in case some input files didn't change. The regular way will be to use add_custom_command & add_custom_target however those required targets, so the make stage. Please advice how to proceed in case there is need to control this already in cmake stage? Thanks, Tomasz. -- Pozdrawiam/Best regards/Mit freundlichen Gr??en, Tomasz Majchrowski, Information Technology and Services Consultant and Contractor -------------- next part -------------- An HTML attachment was scrubbed... URL: From scott.bloom at onshorecs.com Mon Mar 9 13:54:59 2015 From: scott.bloom at onshorecs.com (Scott Aron Bloom) Date: Mon, 9 Mar 2015 17:54:59 +0000 Subject: [CMake] Custom debug messages Message-ID: <6FD2E165340D9A429CF831C7A2D4F42E602A9BF6@WIN-R92V03RFJ85.onshorecs.local> I have some functions, that when Im working on, I need to debug, but the other developers don't need to see the debug messages. I wind up commenting them out, but I would prefer to put them out as debug level messages, ie when -debug-output is set. Is this possible? Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From bpwallace at gmail.com Mon Mar 9 14:22:13 2015 From: bpwallace at gmail.com (Brian Wallace) Date: Mon, 9 Mar 2015 11:22:13 -0700 Subject: [CMake] CPack: creating an zip archive within a parent archive Message-ID: Hi Folks, I have an exiting CMake project which currently builds a TGZ artifact. I would like to use CPack to create a zip file containing some of the files currently installed and then include that zip file within the parent TGZ archive. What is the best way to approach this problem of using CPack with two separate generation methods within one cmake project? I am not a cmake guru so I am still trying to learn the r I see that CPack has component groups, but is there a way to set a dependency so that the Zip is always built first and then installed so that it can be packaged into the parent TGZ? Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From roman.wueger at gmx.at Mon Mar 9 14:50:05 2015 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Mon, 9 Mar 2015 19:50:05 +0100 Subject: [CMake] Wrong behavior with 3.2.0-rc2 In-Reply-To: <54FA1048.5070008@kitware.com> References: <54F99610.7070503@gmail.com> <54FA1048.5070008@kitware.com> Message-ID: <5607B801-2E43-45AD-A9BD-C85ADD109103@gmx.at> Hello Brad, if CMake 3.2.0 will not be released, when is the expected release date for CMake 3.2.1? Regards Roman > Am 06.03.2015 um 21:38 schrieb Brad King : > >> On 03/06/2015 06:57 AM, Nils Gladitz wrote: >>> On 03/06/2015 10:22 AM, Pere Mato Vila wrote: >>> [100%] [100%] *Generating A.txt, B.txt* >>> *Generating A.txt, B.txt* > > Thanks for trying the release candidate and reporting this. > >> This seems to be the case since >> [644b4688d71cc52f8499d6103495de0909319557] Makefile: Fix rebuild with >> multiple custom command outputs (#15116) > > Yes. I've re-opened the corresponding issue with a note about this: > > http://www.cmake.org/Bug/view.php?id=15116#c38168 > > Please follow that issue for further updates. > > We've already tagged v3.2.0 but it was not announced yet. It looks > like 3.2.0 is DOA and we will have to skip to 3.2.1 to fix this. > > Thanks, > -Brad > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From brad.king at kitware.com Mon Mar 9 15:02:39 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 09 Mar 2015 15:02:39 -0400 Subject: [CMake] Wrong behavior with 3.2.0-rc2 In-Reply-To: <5607B801-2E43-45AD-A9BD-C85ADD109103@gmx.at> References: <54F99610.7070503@gmail.com> <54FA1048.5070008@kitware.com> <5607B801-2E43-45AD-A9BD-C85ADD109103@gmx.at> Message-ID: <54FDEE4F.1010109@kitware.com> On 03/09/2015 02:50 PM, Roman W?ger wrote: > if CMake 3.2.0 will not be released, when is the expected release date for CMake 3.2.1? Technically 3.2.0 has been released (there is a signed tag in the source tree for it, created after a drought in feedback on 3.2.0-rc2). We just never published binaries or announced it because this report came in first and is pretty significant. Now 3.2.1 will be done as soon as possible to replace 3.2.0. We never announce specific dates because another regression could be reported at any time and delay things further. -Brad From markmi at dsl-only.net Mon Mar 9 16:52:52 2015 From: markmi at dsl-only.net (Mark Millard) Date: Mon, 9 Mar 2015 13:52:52 -0700 Subject: [CMake] _stl_next_prime can return garbage leading to std::length_error for vector: debug build that do not inline In-Reply-To: <16142A28-5E1B-4B71-81F8-932018633C58@dsl-only.net> References: <16142A28-5E1B-4B71-81F8-932018633C58@dsl-only.net> Message-ID: <2F2277D5-8FB8-4197-89F8-6E9B910E77BB@dsl-only.net> This is a suggested source code change (add a static) for an observed crash for sometypes of debug builds of cmake's ctest. Debug builds of ctest that do not inline _stl_next_prime (which hastable.hxx does not declare as static) can have crash for Position Independent Code (PIC) using Table Of Contents (TOC) register logic for finding addresses: only one _stl_next_prime routine ends up in /usr/local/bin/test having the only two calls to get_stl_prime_list in /usr/local/bin/ctest but there being 7 or so different get_stl_prime_list routines (each with its own _stl_prime_list), each with a different Table Of Contents (TOC) register offset for a different TOC register value. (%r2 in powerpc64 FreeBSD 10.1-STABLE's ABI.) The net result being that all but one get_stl_prime_list are never called despite the various TOC register values and only that routine's one TOC register offset is used for all the TOC register values. This results in garbage instead of prime numbers being returned form _stl_next_prime. That in turn can lead to, for example, trying to reserve huge vectors and a std::length_error exception that stops ctest from finishing its initialization: terminate called after throwing an instance of 'std::length_error' what(): vector::reserve Abort trap (core dumped) This has been observed on powerpc64 FreeBSD 10.1-STABLE built with WITH_DEBUG (in FreeBSD terms). This environemtn uses TOC's and PIC by default. Of course the garage values could have other consequences that are not as obviously-wrong. Declaring _stl_next_prime in hastable.hxx to also be static like get_stl_prime_list would pair the two routines in each compilation-unit --independent of if inline is being ignored or not. === Mark Millard markmi at dsl-only.net From mark.j.abraham at gmail.com Tue Mar 10 02:05:01 2015 From: mark.j.abraham at gmail.com (Mark Abraham) Date: Tue, 10 Mar 2015 07:05:01 +0100 Subject: [CMake] control dependencies in cmake stage In-Reply-To: References: Message-ID: Hi, What are you generating that must be done at cmake time? Mark On 09/03/2015 5:36 pm, "Tomasz Majchrowski" wrote: > Hi, > > I'm wondering if there is an easy way to control the dependencies in the > cmake stage. Basically I would like skip execution of some script run over > execute_process in case some input files didn't change. > > The regular way will be to use add_custom_command & add_custom_target > however those required targets, so the make stage. > > Please advice how to proceed in case there is need to control this already > in cmake stage? > > Thanks, Tomasz. > > > -- > Pozdrawiam/Best regards/Mit freundlichen Gr??en, Tomasz Majchrowski, > Information Technology and Services Consultant and Contractor > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From petr.kmoch at gmail.com Tue Mar 10 03:40:53 2015 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Tue, 10 Mar 2015 08:40:53 +0100 Subject: [CMake] control dependencies in cmake stage In-Reply-To: References: Message-ID: Hi Tomasz, the if() command also supports this operator: if(file1 IS_NEWER_THAN file2) Perhaps you could use this to make it work for you. Petr Per On Tue, Mar 10, 2015 at 7:05 AM, Mark Abraham wrote: > Hi, > > What are you generating that must be done at cmake time? > > Mark > On 09/03/2015 5:36 pm, "Tomasz Majchrowski" wrote: > >> Hi, >> >> I'm wondering if there is an easy way to control the dependencies in the >> cmake stage. Basically I would like skip execution of some script run over >> execute_process in case some input files didn't change. >> >> The regular way will be to use add_custom_command & add_custom_target >> however those required targets, so the make stage. >> >> Please advice how to proceed in case there is need to control this >> already in cmake stage? >> >> Thanks, Tomasz. >> >> >> -- >> Pozdrawiam/Best regards/Mit freundlichen Gr??en, Tomasz Majchrowski, >> Information Technology and Services Consultant and Contractor >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware 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 victorsv at gmail.com Tue Mar 10 06:02:50 2015 From: victorsv at gmail.com (victor sv) Date: Tue, 10 Mar 2015 11:02:50 +0100 Subject: [CMake] Check_library_exists don't found a function in a static library Message-ID: Hello all, I'm a newbie using CMake and I'm trying to migrate the compilation of a fortran project to CMake. I'm trying to detect the METIS library with find_library(). Inside my FindMETIS.cmake I want to check the existence of some functions to set the library version with: CHECK_LIBRARY_EXISTS(metis METIS_SetDefaultOptions /path/to/metis VARIABLE_NAME) If /path/to/metis contains the METIS shared library (libmetis.so) it works as expected, but if /path/to/metis only contains the static version of the library (libmetis.a) CHECK_LIBRARY_EXISTS cannot found this function... I check that the library contains this function with the following result: $ nm libmetis.a | grep -i setdefaultoptions > 0000000000000210 T metis_setdefaultoptions > 0000000000000220 T metis_setdefaultoptions_ > 0000000000000230 T metis_setdefaultoptions__ > U METIS_SetDefaultOptions > 0000000000000200 T METIS_SETDEFAULTOPTIONS > U METIS_SetDefaultOptions > 0000000000000030 T METIS_SetDefaultOptions > I don't know if this the expected behaviour of this macro, but anyway I need to do this check in both, shared and static library. How can I do this? Any help would be appreciated. Thanks, V?ctor. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Chiara.Maffei at unitn.it Tue Mar 10 11:25:31 2015 From: Chiara.Maffei at unitn.it (Maffei, Chiara) Date: Tue, 10 Mar 2015 16:25:31 +0100 Subject: [CMake] missing bin folder Message-ID: <5A75DDB72F4A3C4297406397CD804C0D1574A428F1@MBX.unitn.it> Dear Cmake experts, I am trying to use cmake to build some source code of neuroimaging softwares. however I am facing a quite dramatic issue: after configuration and generation I do have my build folder, but I miss the bin folder inside it, and all build folders result empty. Could you help me out please? Thanks Chiara From usenet at majchrowski.de Tue Mar 10 13:06:52 2015 From: usenet at majchrowski.de (Tomasz Majchrowski) Date: Tue, 10 Mar 2015 18:06:52 +0100 Subject: [CMake] control dependencies in cmake stage In-Reply-To: References: Message-ID: (sorry if you received this message twice) Hi Mark This is the set of C++ source code files. This set will be compiled during the make stage. Ideally will be to move generation to make stage. Unfortunately I don't know the name of the files that will be generated before generation phase occurs. Therefore I can't use set_source_files_properties( foo.cxx PROPERTIES GENERATED true) in cmake stage. Please drop a line if you know how to bypass this limitation. Thanks, Tomasz. 2015-03-10 7:05 GMT+01:00 Mark Abraham : > Hi, > > What are you generating that must be done at cmake time? > > Mark > On 09/03/2015 5:36 pm, "Tomasz Majchrowski" wrote: > >> Hi, >> >> I'm wondering if there is an easy way to control the dependencies in the >> cmake stage. Basically I would like skip execution of some script run over >> execute_process in case some input files didn't change. >> >> The regular way will be to use add_custom_command & add_custom_target >> however those required targets, so the make stage. >> >> Please advice how to proceed in case there is need to control this >> already in cmake stage? >> >> Thanks, Tomasz. >> >> >> -- >> Pozdrawiam/Best regards/Mit freundlichen Gr??en, Tomasz Majchrowski, >> Information Technology and Services Consultant and Contractor >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake >> >> -- >> Pozdrawiam/Best regards/Mit freundlichen Gr??en, Tomasz Majchrowski, >> Information Technology and Services Consultant and Contractor >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From p77johnson at gmail.com Tue Mar 10 13:28:18 2015 From: p77johnson at gmail.com (paul johnson) Date: Tue, 10 Mar 2015 13:28:18 -0400 Subject: [CMake] Linking to Qt static libraries fails using cmake but not qmake (both OSX and Linux) Message-ID: This has been driving me crazy for a while now. Occurs for both OSX and Linux. OSX Mavericks 10.9.5, openSUSE Linux 12.3 CMake 3.1.1 Qt 5.4.1 (both shared and static builds, compiled from source) Using cmake to compile and link the simple Qt HelloWorld app against Qt shared libraries works just fine. Using the same cmake file and specifying the Qt static libraries instead, it fails in the linking (OSX: Undefined symbols for architecture x86_64, ld: symbol(s) not found for architecture x86_64?; LINUX: undefined reference to ?, collect2 error: ld returned 1 exit status) Message would seem to point towards static libraries not compiled 64 bit. But, if I use qmake to generate the makefile to use with the Qt static libraries, it compiles and links with no problem. No symbol problem here. Seems to indicate the static libraries are fine. Since using qmake seems to work fine I can?t pin down what the problem is with cmake. Can anyone shed some light on this? Source, CMakeLists.txt, and qmake .pro contents below. I?ve also attached failed linking output from OSX and linux cmake/make. main.cpp: #include #include int main(int argc, char **argv) { QApplication app (argc, argv); QPushButton button ("Hello world !"); button.show(); return app.exec(); } CMakeLists.txt: cmake_minimum_required(VERSION 2.8.11) project(helloworld) set(CMAKE_INCLUDE_CURRENT_DIR ON) set(CMAKE_AUTOMOC ON) find_package(Qt5Widgets REQUIRED) add_executable(helloworld main.cpp) target_link_libraries(helloworld Qt5::Widgets) main.pro: SOURCES = main.cpp CONFIG += qt warn_on release QT += core widgets gui Thanks in advance. Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: make_static_osx.log Type: application/octet-stream Size: 71837 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: make_static_linux.log Type: application/octet-stream Size: 43720 bytes Desc: not available URL: From post at hendrik-sattler.de Tue Mar 10 13:40:59 2015 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Tue, 10 Mar 2015 18:40:59 +0100 Subject: [CMake] Linking to Qt static libraries fails using cmake but not qmake (both OSX and Linux) In-Reply-To: References: Message-ID: Hi, that's because qmake uses its some extra files to track the additional libraries that are needed when you link qt statically (.prl IIRC). You are missing these, somehow. Maybe the cmake files from qt5 don't handle this case? HS Am 10. M?rz 2015 18:28:18 MEZ, schrieb paul johnson : >This has been driving me crazy for a while now. Occurs for both OSX and >Linux. > >OSX Mavericks 10.9.5, openSUSE Linux 12.3 >CMake 3.1.1 >Qt 5.4.1 (both shared and static builds, compiled from source) > >Using cmake to compile and link the simple Qt HelloWorld app against Qt >shared libraries works just fine. > >Using the same cmake file and specifying the Qt static libraries >instead, >it fails in the linking (OSX: Undefined symbols for architecture >x86_64, >ld: symbol(s) not found for architecture x86_64?; LINUX: undefined >reference to ?, collect2 error: ld returned 1 exit status) > >Message would seem to point towards static libraries not compiled 64 >bit. > >But, if I use qmake to generate the makefile to use with the Qt static >libraries, it compiles and links with no problem. No symbol problem >here. >Seems to indicate the static libraries are fine. > >Since using qmake seems to work fine I can?t pin down what the problem >is >with cmake. > >Can anyone shed some light on this? > >Source, CMakeLists.txt, and qmake .pro contents below. I?ve also >attached >failed linking output from OSX and linux cmake/make. > >main.cpp: > >#include >#include > >int main(int argc, char **argv) >{ > QApplication app (argc, argv); > > QPushButton button ("Hello world !"); > button.show(); > > return app.exec(); >} > > >CMakeLists.txt: > >cmake_minimum_required(VERSION 2.8.11) > >project(helloworld) >set(CMAKE_INCLUDE_CURRENT_DIR ON) >set(CMAKE_AUTOMOC ON) >find_package(Qt5Widgets REQUIRED) >add_executable(helloworld main.cpp) >target_link_libraries(helloworld Qt5::Widgets) > > >main.pro: > >SOURCES = main.cpp >CONFIG += qt warn_on release >QT += core widgets gui > > >Thanks in advance. > > >Paul > > >------------------------------------------------------------------------ > >-- > >Powered by www.kitware.com > >Please keep messages on-topic and check the CMake FAQ at: >http://www.cmake.org/Wiki/CMake_FAQ > >Kitware offers various services to support the CMake community. For >more information on each offering, please visit: > >CMake Support: http://cmake.org/cmake/help/support.html >CMake Consulting: http://cmake.org/cmake/help/consulting.html >CMake Training Courses: http://cmake.org/cmake/help/training.html > >Visit other Kitware 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 ghleclerc at gmail.com Tue Mar 10 13:42:44 2015 From: ghleclerc at gmail.com (Ghyslain Leclerc) Date: Tue, 10 Mar 2015 13:42:44 -0400 Subject: [CMake] Linking to Qt static libraries fails using cmake but not qmake (both OSX and Linux) In-Reply-To: References: Message-ID: Hi, I have just run into this problem a few weeks ago. ?My explanation might not be perfect, but from what I understand, it is related to the fact that the libraries which Qt depends upon have to be available for static linking to your application. ?Those dependencies are ?magically? brought in by qmake, but the CMake find package for Qt does not bring those in. ?There have been some attempts, from what I gather, but nothing official for static linking of Qt applications with CMake. ?Thus, my approach has been to find the system libraries myself using CMake and add them to the target_link_libraries() command. ?Not much fun or robust (from my perspective), but works. ?I have been able to statically compile and run the application on a colleague?s computer (where Qt was not installed at all). There is also the concern of the plugins, mainly the platform plugins concept of Qt, which have to be compiled into your application. ?If I understand correctly, when you request static linking from qmake (+= static), qmake creates a cpp file and adds it to your project. ?This file simply contains code to insure that the plugins are compiled and can be linked against. ?For CMake, you have to manually add these includes. ?I do it in the main.cpp file or whatever file your main is in. Here are links to the earlier discussion: https://www.mail-archive.com/cmake%40cmake.org/msg51188.html https://www.mail-archive.com/cmake%40cmake.org/msg51170.html Stephen Kelly is much more knowledgable then me on this. ?He usually responds pretty fast to the list (he helped me a lot on that). Hope my explanations are not too confusing and that they help a little. Best of luck. Ghyslain This has been driving me crazy for a while now. Occurs for both OSX and Linux. OSX Mavericks 10.9.5, openSUSE Linux 12.3 CMake 3.1.1 Qt 5.4.1 (both shared and static builds, compiled from source) Using cmake to compile and link the simple Qt HelloWorld app against Qt shared libraries works just fine. Using the same cmake file and specifying the Qt static libraries instead, it fails in the linking (OSX: Undefined symbols for architecture x86_64, ld: symbol(s) not found for architecture x86_64?; LINUX: undefined reference to ?, collect2 error: ld returned 1 exit status) Message would seem to point towards static libraries not compiled 64 bit. But, if I use qmake to generate the makefile to use with the Qt static libraries, it compiles and links with no problem. No symbol problem here. Seems to indicate the static libraries are fine. Since using qmake seems to work fine I can?t pin down what the problem is with cmake. Can anyone shed some light on this? Source, CMakeLists.txt, and qmake .pro contents below. I?ve also attached failed linking output from OSX and linux cmake/make. main.cpp: #include #include int main(int argc, char **argv) { QApplication app (argc, argv); QPushButton button ("Hello world !"); button.show(); return app.exec(); } CMakeLists.txt: cmake_minimum_required(VERSION 2.8.11) project(helloworld) set(CMAKE_INCLUDE_CURRENT_DIR ON) set(CMAKE_AUTOMOC ON) find_package(Qt5Widgets REQUIRED) add_executable(helloworld main.cpp) target_link_libraries(helloworld Qt5::Widgets) main.pro: SOURCES = main.cpp CONFIG += qt warn_on release QT += core widgets gui Thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil at voltage.com Tue Mar 10 13:58:06 2015 From: phil at voltage.com (Phil Smith) Date: Tue, 10 Mar 2015 10:58:06 -0700 Subject: [CMake] CMake "permission denied" problem (Windows 7 64-bit, CMake 2.8.1) References: <84BCCD71182F0046BCD2FB054FE52379183FBAD5C1@HQMAILSVR02.voltage.com> <54F9FD56.8050004@kitware.com> Message-ID: <84BCCD71182F0046BCD2FB054FE52379183FBADA63@HQMAILSVR02.voltage.com> Well, I finally got around this. I narrowed it down to a step in our build "scaffolding"--the stuff that makes a front-end script be the compiler, do both the C and asm steps. It was doing this, from within CMakeFiles\CmakeTmp: cp CMakeFiles/cmTryCompileExec.dir/testCCompiler.c.o testCCompiler.zASM Changing the cp to an mv solves it. But before I got to that, I trapped it before that command and issued the cp manually; the resulting output file was still unreadable. BUT if I changed it to write the output file to another directory, it WAS readable. Which I don't get. Windows shows the same permissions for both directories. COPY had the same results; XCOPY worked (output was readable), but ran into the problem with XCOPY wanting to prompt for whether the target was a file or a directory (and the "append an asterisk" trick didn't quite work, due to different extension lengths; I then thought of copying it as the same name and renaming it, and then said "Doh, use mv", and here I am). Anyway, I figured I'd close the loop here in case anyone else hits something similar. It'll remain somewhat of a mystery... ...phsiii From usenet at majchrowski.de Tue Mar 10 14:09:16 2015 From: usenet at majchrowski.de (Tomasz Majchrowski) Date: Tue, 10 Mar 2015 19:09:16 +0100 Subject: [CMake] control dependencies in cmake stage In-Reply-To: References: Message-ID: Hi Peter, Good point. Then it will be possible to manage workflow with pure cmake. Without of using of external scripts. Thanks, Tomasz. 2015-03-10 8:40 GMT+01:00 Petr Kmoch : > Hi Tomasz, > > the if() command also supports this operator: > > if(file1 IS_NEWER_THAN file2) > > Perhaps you could use this to make it work for you. > > Petr > > Per > > On Tue, Mar 10, 2015 at 7:05 AM, Mark Abraham > wrote: > >> Hi, >> >> What are you generating that must be done at cmake time? >> >> Mark >> On 09/03/2015 5:36 pm, "Tomasz Majchrowski" >> wrote: >> >>> Hi, >>> >>> I'm wondering if there is an easy way to control the dependencies in the >>> cmake stage. Basically I would like skip execution of some script run over >>> execute_process in case some input files didn't change. >>> >>> The regular way will be to use add_custom_command & add_custom_target >>> however those required targets, so the make stage. >>> >>> Please advice how to proceed in case there is need to control this >>> already in cmake stage? >>> >>> Thanks, Tomasz. >>> >>> >>> -- >>> Pozdrawiam/Best regards/Mit freundlichen Gr??en, Tomasz Majchrowski, >>> Information Technology and Services Consultant and Contractor >>> >>> -- >>> >>> Powered by www.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: >>> http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For more >>> information on each offering, please visit: >>> >>> CMake Support: http://cmake.org/cmake/help/support.html >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware 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 >> >> -- >> Pozdrawiam/Best regards/Mit freundlichen Gr??en, Tomasz Majchrowski, >> Information Technology and Services Consultant and Contractor >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Tue Mar 10 18:33:41 2015 From: d3ck0r at gmail.com (J Decker) Date: Tue, 10 Mar 2015 15:33:41 -0700 Subject: [CMake] Inconsistency with INSTALL(TARGETS) destinations... Message-ID: I recently added cmakelists to a library that didn't support cmake. It started with a simple make system, and was easy to create and use simple cmake support. I was building using visual studio, and this was my install command install( TARGETS MatrixSSL LIBRARY DESTINATION bin ARCHIVE DESTINATION lib ) that put the .DLL in bin and .lib in lib. Then I had to change to using watcom to build, and the .DLL went nowhere... so I modified the line to... install( TARGETS MatrixSSL RUNTIME DESTINATION bin LIBRARY DESTINATION bin ARCHIVE DESTINATION lib ) ... then the DLL was installed into bin. I'm not sure which way is intended... or maybe it's something in each of the build environments that requires it to be different? and just commentary... Installing libraries is kind of a pain... (and this is probably incomplete) if( WIN32 ) install( TARGETS MatrixSSL RUNTIME DESTINATION bin LIBRARY DESTINATION bin ARCHIVE DESTINATION lib ) else( WIN32 ) if( ${CMAKE_SIZEOF_VOID_P} EQUAL 8 ) install( TARGETS MatrixSSL DESTINATION lib64 ) else( ${CMAKE_SIZEOF_VOID_P} EQUAL 8 ) install( TARGETS MatrixSSL DESTINATION lib ) endif( ${CMAKE_SIZEOF_VOID_P} EQUAL 8 ) endif( WIN32 ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From post at hendrik-sattler.de Tue Mar 10 19:02:49 2015 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Wed, 11 Mar 2015 00:02:49 +0100 Subject: [CMake] Inconsistency with INSTALL(TARGETS) destinations... In-Reply-To: References: Message-ID: <242F48CE-87B5-4083-8CF7-B6B54EA79B6E@hendrik-sattler.de> Am 10. M?rz 2015 23:33:41 MEZ, schrieb J Decker : >I recently added cmakelists to a library that didn't support cmake. >It started with a simple make system, and was easy to create and use >simple >cmake support. > >I was building using visual studio, and this was my install command > install( TARGETS MatrixSSL > LIBRARY DESTINATION bin > ARCHIVE DESTINATION lib ) > >that put the .DLL in bin and .lib in lib. > >Then I had to change to using watcom to build, and the .DLL went >nowhere... >so I modified the line to... > > install( TARGETS MatrixSSL > RUNTIME DESTINATION bin > LIBRARY DESTINATION bin > ARCHIVE DESTINATION lib ) > >... then the DLL was installed into bin. A bug, then. Dll files should always be installed to the RUNTIME destination. >I'm not sure which way is intended... or maybe it's something in each >of >the build environments that requires it to be different? > > >and just commentary... >Installing libraries is kind of a pain... (and this is probably >incomplete) > > >if( WIN32 ) > install( TARGETS MatrixSSL RUNTIME DESTINATION bin LIBRARY DESTINATION >bin ARCHIVE DESTINATION lib ) >else( WIN32 ) > if( ${CMAKE_SIZEOF_VOID_P} EQUAL 8 ) > install( TARGETS MatrixSSL DESTINATION lib64 ) > else( ${CMAKE_SIZEOF_VOID_P} EQUAL 8 ) > install( TARGETS MatrixSSL DESTINATION lib ) > endif( ${CMAKE_SIZEOF_VOID_P} EQUAL 8 ) >endif( WIN32 ) And it's mostly wrong, e.g. lib64 is not correct for many systems. If you want Unix like subdirectories, use the GnuIntallDirs module. HS From mark.j.abraham at gmail.com Tue Mar 10 19:15:26 2015 From: mark.j.abraham at gmail.com (Mark Abraham) Date: Wed, 11 Mar 2015 00:15:26 +0100 Subject: [CMake] control dependencies in cmake stage In-Reply-To: References: Message-ID: Hi, Sure, this is straightforward to do all at make time, if you're prepared to find out what the names of the generated files are. They must follow some pattern ;-). Solutions with make-time globbing are surely impossible, and Petr's IF idea seems brittle to me. See (for example) https://github.com/gromacs/gromacs/blob/master/src/gromacs/CMakeLists.txt#L154. The idea is that you have some target that does the generation, and you make the eventual library/executable depend on its output files. The target that contains the generation command has its own dependencies, so you don't have to re-generate if those don't go out of date. In that example, gmx_configure_version_file just wraps configure_file(), which sets up that dependency chain. You'd need an add_custom_command(), it seems, whose OUTPUT had the list of generated files. There's no problem to use add_library() with a file generated in the build tree - just mention it in an output. There are several much more complicated examples at https://github.com/gromacs/gromacs/blob/master/docs/CMakeLists.txt. For example, we build a gmx binary that writes the same text we display with "gmx topic -h" instead as topic.rst restructedText, which is then parsed with Sphinx to produce manpages that go in the tarball via CPack, or to produce HTML to go on our webpage. Helper scripts mostly live in https://github.com/gromacs/gromacs/tree/master/cmake Cheers, Mark On Tue, Mar 10, 2015 at 6:06 PM, Tomasz Majchrowski wrote: > (sorry if you received this message twice) > > Hi Mark > > This is the set of C++ source code files. This set will be compiled > during the make stage. Ideally will be to move generation to make stage. > Unfortunately I don't know the name of the files that will be generated > before generation phase occurs. > > Therefore I can't use set_source_files_properties( foo.cxx PROPERTIES > GENERATED true) in cmake stage. Please drop a line if you know how to > bypass this limitation. > > Thanks, Tomasz. > > 2015-03-10 7:05 GMT+01:00 Mark Abraham : > >> Hi, >> >> What are you generating that must be done at cmake time? >> >> Mark >> On 09/03/2015 5:36 pm, "Tomasz Majchrowski" >> wrote: >> >>> Hi, >>> >>> I'm wondering if there is an easy way to control the dependencies in the >>> cmake stage. Basically I would like skip execution of some script run over >>> execute_process in case some input files didn't change. >>> >>> The regular way will be to use add_custom_command & add_custom_target >>> however those required targets, so the make stage. >>> >>> Please advice how to proceed in case there is need to control this >>> already in cmake stage? >>> >>> Thanks, Tomasz. >>> >>> >>> -- >>> Pozdrawiam/Best regards/Mit freundlichen Gr??en, Tomasz Majchrowski, >>> Information Technology and Services Consultant and Contractor >>> >>> -- >>> >>> Powered by www.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: >>> http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For more >>> information on each offering, please visit: >>> >>> CMake Support: http://cmake.org/cmake/help/support.html >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/cmake >>> >>> -- >>> Pozdrawiam/Best regards/Mit freundlichen Gr??en, Tomasz Majchrowski, >>> Information Technology and Services Consultant and Contractor >>> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Tue Mar 10 20:48:48 2015 From: d3ck0r at gmail.com (J Decker) Date: Tue, 10 Mar 2015 17:48:48 -0700 Subject: [CMake] Inconsistency with INSTALL(TARGETS) destinations... In-Reply-To: <242F48CE-87B5-4083-8CF7-B6B54EA79B6E@hendrik-sattler.de> References: <242F48CE-87B5-4083-8CF7-B6B54EA79B6E@hendrik-sattler.de> Message-ID: > > > And it's mostly wrong, e.g. lib64 is not correct for many systems. If you > want Unix like subdirectories, use the GnuIntallDirs module. > > Better? if( WIN32 ) install( TARGETS MatrixSSL RUNTIME DESTINATION bin LIBRARY DESTINATION bin ARCHIVE DESTINATION lib ) else( WIN32 ) include( GNUInstallDirs ) install( TARGETS MatrixSSL DESTINATION ${CMAKE_INSTALL_LIBDIR ) ) endif( WIN32 ) On Linux; .so and .a go into LIBDIR and executable into BINDIR on windows I have executable (BINDIR/RUNTIME) and I have .lib that are (.a) that are static libraries which would be ARCHIVE; but I have interface libraries (.exp, .dll link libraries which on some compilers are optional, since the .dll itself contains enough information) which I wold think would be LIBRARY ( something different than ARCHIVE?) ... It seems some generators treat LIBRARY for add_library(SHARED) output and some need RUNTIME... and all use ARCHIVE for export and static library targets. in the case of add_executable it's possible that also generates a export library; would that be LIBRARY DESTINATION? or ARCHIVE? > HS > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.getchell at gmail.com Tue Mar 10 21:55:09 2015 From: adam.getchell at gmail.com (Adam Getchell) Date: Tue, 10 Mar 2015 18:55:09 -0700 Subject: [CMake] Setting build type In-Reply-To: References: Message-ID: Hello all, You were correct, when CGAL is built it overrides CMAKE_BUILD_TYPE, as documented here: http://doc.cgal.org/latest/Manual/installation.html The solution is to invoke: cmake -DCGAL_DONT_OVERRIDE_CMAKE_FLAGS=True -DCMAKE_BUILD_TYPE=Debug .. Thanks for your help! Adam On Sun, Mar 1, 2015 at 1:41 PM, Mark Abraham wrote: > Hi, > > Looks like one of your find_package calls is setting the build type > variable, which it should not... > > Mark > On 27/02/2015 5:47 pm, "Adam Getchell" wrote: > >> Thanks for the help! >> >> It still runs Release mode: >> >> Here's my project: >> >> https://github.com/acgetchell/CDT-plusplus >> >> ??[*adam*][Hapkido][*?*][master *?*][~/CDT-plusplus] >> >> ??? tree >> >> . >> >> |____.git >> >> | |____config >> >> | |____description >> >> | |____HEAD >> >> | |____hooks >> >> | | |____applypatch-msg.sample >> >> | | |____commit-msg.sample >> >> | | |____post-update.sample >> >> | | |____pre-applypatch.sample >> >> | | |____pre-commit.sample >> >> | | |____pre-push.sample >> >> | | |____pre-rebase.sample >> >> | | |____prepare-commit-msg.sample >> >> | | |____update.sample >> >> | |____index >> >> | |____info >> >> | | |____exclude >> >> | |____logs >> >> | | |____HEAD >> >> | | |____refs >> >> | | | |____heads >> >> | | | | |____master >> >> | | | |____remotes >> >> | | | | |____origin >> >> | | | | | |____HEAD >> >> | |____objects >> >> | | |____info >> >> | | |____pack >> >> | | | |____pack-a9db5eb5c90025a8ca13bddf15822cb0e57cbead.idx >> >> | | | |____pack-a9db5eb5c90025a8ca13bddf15822cb0e57cbead.pack >> >> | |____packed-refs >> >> | |____refs >> >> | | |____heads >> >> | | | |____master >> >> | | |____remotes >> >> | | | |____origin >> >> | | | | |____HEAD >> >> | | |____tags >> >> |____.gitignore >> >> |____.travis-linux.yml >> >> |____.travis-macosx.yml >> >> |____.travis.yml >> >> |____build.sh >> >> |____CMakeLists.txt >> >> |____Doxyfile >> >> |____LICENSE >> >> |____README.md >> >> |____scan-build.sh >> >> |____src >> >> | |____cdt.cpp >> >> | |____Delaunay.h >> >> | |____docopt >> >> | | |____docopt.cpp >> >> | | |____docopt.h >> >> | | |____docopt_private.h >> >> | | |____docopt_util.h >> >> | | |____docopt_value.h >> >> | | |____examples >> >> | | | |____naval_fate.cpp >> >> | | |____LICENSE-Boost-1.0 >> >> | | |____LICENSE-MIT >> >> | | |____main.cpp >> >> | | |____README.rst >> >> | | |____run_testcase.cpp >> >> | | |____run_tests.py >> >> | | |____testcases.docopt >> >> | |____grid_d.cpp >> >> | |____grid_d.h >> >> | |____periodic_3_complex.h >> >> | |____periodic_3_triangulations.h >> >> | |____Point.h >> >> | |____S3Action.h >> >> | |____S3ErgodicMoves.h >> >> | |____S3Triangulation.h >> >> | |____sphere_d.h >> >> | |____utilities.h >> >> |____unittests >> >> | |____.gitignore >> >> | |____main.cpp >> >> | |____PointTest.cpp >> >> | |____S3BulkActionTest.cpp >> >> | |____S3ErgodicMovesTest.cpp >> >> | |____S3TetrahedronTest.cpp >> >> | |____SdTriangulationTest.cpp >> >> | |____SphereTest.cpp >> >> | |____Triangulated2SphereTest.cpp >> >> | |____VertexTest.cpp >> >> ??[*adam*][Hapkido][*?*][master *?*][~/CDT-plusplus] >> >> ??? mkdir build-d >> >> ??[*adam*][Hapkido][*?*][master *?*][~/CDT-plusplus] >> >> ??? cd build-d >> >> ??[*adam*][Hapkido][*?*][master *?*][~/CDT-plusplus/build-d] >> >> ??? cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=out .. >> >> -- The C compiler identification is AppleClang 6.0.0.6000056 >> >> -- The CXX compiler identification is AppleClang 6.0.0.6000056 >> >> -- Check for working C compiler: /usr/bin/cc >> >> -- Check for working C compiler: /usr/bin/cc -- works >> >> -- Detecting C compiler ABI info >> >> -- Detecting C compiler ABI info - done >> >> -- Check for working CXX compiler: /usr/bin/c++ >> >> -- Check for working CXX compiler: /usr/bin/c++ -- works >> >> -- Detecting CXX compiler ABI info >> >> -- Detecting CXX compiler ABI info - done >> >> -- Build type: Release >> >> -- USING CXXFLAGS = ' -O3 -DNDEBUG' >> >> -- USING EXEFLAGS = ' >> -Wl,-dylib_file,/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib:/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib >> ' >> >> -- Targetting Unix Makefiles >> >> -- Using /usr/bin/c++ compiler. >> >> -- DARWIN_VERSION=14 >> >> -- Mac Leopard detected >> >> -- Requested component: Core >> >> -- Requested component: MPFR >> >> -- Requested component: GMP >> >> -- Found Eigen3: /usr/local/include/eigen3 (found suitable version >> "3.2.4", minimum required is "3.1.0") >> >> -- Found Intel TBB >> >> -- Configuring done >> >> -- Generating done >> >> -- Build files have been written to: /Users/adam/CDT-plusplus/build-d >> >> ??[*adam*][Hapkido][*?*][master *?*][~/CDT-plusplus/build-d] >> >> >> On Wed, Feb 25, 2015 at 1:37 AM, J Decker wrote: >> >>> mkdir build-d >>> cd build-d >>> cmake >>> -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=out ../your/source/procject >>> cmake --build . >>> cd .. >>> >>> mkdir build-r >>> cd build-r >>> cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=out >>> ../your/source/procject >>> cmake --build . --target install >>> cd .. >>> >>> >>> On Wed, Feb 25, 2015 at 1:16 AM, Adam Getchell >>> wrote: >>> >>>> Thanks for your reply. >>>> >>>> I'm not sure I follow your answer. I do delete the directory each time >>>> I build, but I'm still not understanding how you're building release or >>>> debug versions to begin with. >>>> >>>> I'm just automatically getting Release, unless I edit CMakeCache.txt >>>> after I've built once. >>>> >>>> I just checked CGAL_CreateSingleSourceCGALProgram.cmake which is >>>> invoked in my CMakeLists.txt, but I do not see it setting the build type to >>>> Release. >>>> >>>> https://github.com/acgetchell/CDT-plusplus/blob/master/CMakeLists.txt >>>> >>>> >>>> >>>> On Tue, Feb 24, 2015 at 12:20 PM, J Decker wrote: >>>> >>>>> I use a different directory to build release and debug versions.... >>>>> >>>>> if you didn't delete, then when it goes to build partial things, the >>>>> .obj files will still be newer than the .c files and will cause mixed >>>>> release-debug builds which generally results in bizarre crashes. >>>>> Once chosen, can't change the build type of a build; although if you >>>>> could it should do a clean also. >>>>> >>>>> >>>>> On Tue, Feb 24, 2015 at 11:42 AM, Adam Getchell < >>>>> adam.getchell at gmail.com> wrote: >>>>> >>>>>> Hello all, >>>>>> >>>>>> I've browsed this thread: >>>>>> >>>>>> http://www.cmake.org/pipermail/cmake/2008-September/023808.html >>>>>> >>>>>> But it doesn't work. My project is set to Release regardless, whether >>>>>> I do: >>>>>> >>>>>> project( CDT-plusplus_ ) >>>>>> set(CMAKE_BUILD_TYPE RelWithDebInfo) >>>>>> >>>>>> Or: >>>>>> >>>>>> # >>>>>> # If the user specifies -DCMAKE_BUILD_TYPE on the command line, take >>>>>> their definition >>>>>> # and dump it in the cache along with proper documentation, otherwise >>>>>> set CMAKE_BUILD_TYPE >>>>>> # to Debug prior to calling PROJECT() >>>>>> # >>>>>> IF(DEFINED CMAKE_BUILD_TYPE) >>>>>> SET(CMAKE_BUILD_TYPE ${CMAKE_BUILD_TYPE} CACHE STRING "Choose the >>>>>> type of >>>>>> build, options are: None(CMAKE_CXX_FLAGS or CMAKE_C_FLAGS used) Debug >>>>>> Release RelWithDebInfo MinSizeRel.") >>>>>> ELSE() >>>>>> SET(CMAKE_BUILD_TYPE Debug CACHE STRING "Choose the type of build, >>>>>> options are: None(CMAKE_CXX_FLAGS or CMAKE_C_FLAGS used) Debug Release >>>>>> RelWithDebInfo MinSizeRel.") >>>>>> ENDIF() >>>>>> >>>>>> project( CDT-plusplus_ ) >>>>>> >>>>>> The only way I can change the build type is by going into my build >>>>>> directory and editing CMakeCache.txt. However, I use an out of source >>>>>> build, so my build directory is generated automatically by scripts such as: >>>>>> >>>>>> https://github.com/acgetchell/CDT-plusplus/blob/master/scan-build.sh >>>>>> >>>>>> What's the correct method for being able to set the type of build via >>>>>> the command line? >>>>>> >>>>>> -- >>>>>> Adam Getchell >>>>>> about.me/adamgetchell >>>>>> "Invincibility is in oneself, vulnerability in the opponent." -- Sun >>>>>> Tzu >>>>>> >>>>>> -- >>>>>> >>>>>> Powered by www.kitware.com >>>>>> >>>>>> Please keep messages on-topic and check the CMake FAQ at: >>>>>> http://www.cmake.org/Wiki/CMake_FAQ >>>>>> >>>>>> Kitware offers various services to support the CMake community. For >>>>>> more information on each offering, please visit: >>>>>> >>>>>> CMake Support: http://cmake.org/cmake/help/support.html >>>>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>>>>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>>>>> >>>>>> Visit other Kitware open-source projects at >>>>>> http://www.kitware.com/opensource/opensource.html >>>>>> >>>>>> Follow this link to subscribe/unsubscribe: >>>>>> http://public.kitware.com/mailman/listinfo/cmake >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Adam Getchell >>>> about.me/adamgetchell >>>> "Invincibility is in oneself, vulnerability in the opponent." -- Sun Tzu >>>> >>> >>> >> >> >> -- >> Adam Getchell >> about.me/adamgetchell >> "Invincibility is in oneself, vulnerability in the opponent." -- Sun Tzu >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake >> > -- Adam Getchell about.me/adamgetchell "Invincibility is in oneself, vulnerability in the opponent." -- Sun Tzu -------------- next part -------------- An HTML attachment was scrubbed... URL: From kl222 at 126.com Wed Mar 11 02:02:19 2015 From: kl222 at 126.com (kl222) Date: Wed, 11 Mar 2015 14:02:19 +0800 (CST) Subject: [CMake] =?gbk?q?cmake_install_qt5_library_to_Specified_directory?= =?gbk?b?o78=?= Message-ID: <4876baac.34d.14c076d3442.Coremail.kl222@126.com> Hello all: I thank to install qt5(>=5.3.0) library to sepcified directory. I write: get_target_property(QtCore_location Qt5::Core LOCATION) install(files ${QtCore_location} DESTINATION .) Ok, it is copy /usr/local/Qt-5.5.0/lib/libQt5Core.so.5.5.0 to destination directory, but it don't create libQt5Core.so.5 link. so the programe don't find the library. What do I? -------------- next part -------------- An HTML attachment was scrubbed... URL: From eike at sf-mail.de Wed Mar 11 03:32:48 2015 From: eike at sf-mail.de (Rolf Eike Beer) Date: Wed, 11 Mar 2015 08:32:48 +0100 Subject: [CMake] Inconsistency with INSTALL(TARGETS) destinations... In-Reply-To: References: <242F48CE-87B5-4083-8CF7-B6B54EA79B6E@hendrik-sattler.de> Message-ID: <1670624.lWhrNmkiFt@caliban.sf-tec.de> Am Dienstag, 10. M?rz 2015, 17:48:48 schrieb J Decker: > > And it's mostly wrong, e.g. lib64 is not correct for many systems. If you > > want Unix like subdirectories, use the GnuIntallDirs module. > > Better? > > if( WIN32 ) > install( TARGETS MatrixSSL RUNTIME DESTINATION bin LIBRARY DESTINATION > bin ARCHIVE DESTINATION lib ) > else( WIN32 ) > include( GNUInstallDirs ) > install( TARGETS MatrixSSL DESTINATION ${CMAKE_INSTALL_LIBDIR ) ) > endif( WIN32 ) You don't even need the if(), the module will handle that alone. Just specify all 3 flavors since they only overlap for the static lib for the different platforms. Greetings, Eike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From domen.vrankar at gmail.com Wed Mar 11 03:35:33 2015 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Wed, 11 Mar 2015 08:35:33 +0100 Subject: [CMake] missing bin folder In-Reply-To: <5A75DDB72F4A3C4297406397CD804C0D1574A428F1@MBX.unitn.it> References: <5A75DDB72F4A3C4297406397CD804C0D1574A428F1@MBX.unitn.it> Message-ID: > however I am facing a quite dramatic issue: after configuration and generation I do have my build folder, but I miss the bin folder inside it, and all build folders result empty. One thing comes to mind... If you accidentally generate build structure inside root source directory and later run generation again from another directory the structure is refreshed in the source tree not on the location where you expect the generated files to be. This can be fixed by deleting CMake generated files in source tree. This was the behavior of CMake 2.8.x - I'm not certain if later versions work the same way in such situations. Another option would be an error during configuration/generation but that would be printed to standard error... Hope this helps, Domen From petr.kmoch at gmail.com Wed Mar 11 03:47:21 2015 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Wed, 11 Mar 2015 08:47:21 +0100 Subject: [CMake] Inconsistency with INSTALL(TARGETS) destinations... In-Reply-To: <1670624.lWhrNmkiFt@caliban.sf-tec.de> References: <242F48CE-87B5-4083-8CF7-B6B54EA79B6E@hendrik-sattler.de> <1670624.lWhrNmkiFt@caliban.sf-tec.de> Message-ID: Do you even *have* any LIBRARY targets on Windows? Quoting the docs ( http://www.cmake.org/cmake/help/v3.2/command/install.html#installing-targets ): "Static libraries are always treated as ARCHIVE targets. Module libraries are always treated as LIBRARY targets. For non-DLL platforms shared libraries are treated as LIBRARY targets, except that those marked with the FRAMEWORK property are treated as FRAMEWORK targets on OS X. For DLL platforms the DLL part of a shared library is treated as a RUNTIME target and the corresponding import library is treated as an ARCHIVE target. All Windows-based systems including Cygwin are DLL platforms." Unless you're building MODULE libraries, you'll normally only have RUNTIME (.dll) and ARCHIVE (.lib) targets on Windows, and LIBRARY (.so) and ARCHIVE (.a) targets on Unixes. Petr On Wed, Mar 11, 2015 at 8:32 AM, Rolf Eike Beer wrote: > Am Dienstag, 10. M?rz 2015, 17:48:48 schrieb J Decker: > > > And it's mostly wrong, e.g. lib64 is not correct for many systems. If > you > > > want Unix like subdirectories, use the GnuIntallDirs module. > > > > Better? > > > > if( WIN32 ) > > install( TARGETS MatrixSSL RUNTIME DESTINATION bin LIBRARY DESTINATION > > bin ARCHIVE DESTINATION lib ) > > else( WIN32 ) > > include( GNUInstallDirs ) > > install( TARGETS MatrixSSL DESTINATION ${CMAKE_INSTALL_LIBDIR ) ) > > endif( WIN32 ) > > You don't even need the if(), the module will handle that alone. Just > specify > all 3 flavors since they only overlap for the static lib for the different > platforms. > > Greetings, > > Eike > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From petr.kmoch at gmail.com Wed Mar 11 03:49:57 2015 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Wed, 11 Mar 2015 08:49:57 +0100 Subject: [CMake] missing bin folder In-Reply-To: References: <5A75DDB72F4A3C4297406397CD804C0D1574A428F1@MBX.unitn.it> Message-ID: Hi Chiara, just a sanity check: have you actually run a build? Or is it that even the buildsystem (Makefiles, VS projects, what have you) is not there? Petr On Wed, Mar 11, 2015 at 8:35 AM, Domen Vrankar wrote: > > however I am facing a quite dramatic issue: after configuration and > generation I do have my build folder, but I miss the bin folder inside it, > and all build folders result empty. > > One thing comes to mind... If you accidentally generate build > structure inside root source directory and later run generation again > from another directory the structure is refreshed in the source tree > not on the location where you expect the generated files to be. This > can be fixed by deleting CMake generated files in source tree. This > was the behavior of CMake 2.8.x - I'm not certain if later versions > work the same way in such situations. > > Another option would be an error during configuration/generation but > that would be printed to standard error... > > Hope this helps, > Domen > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Wed Mar 11 09:19:24 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 11 Mar 2015 09:19:24 -0400 Subject: [CMake] [ANNOUNCE] CMake 3.2.1 Released! Message-ID: I am proud to announce that CMake 3.2.1 is now available for download at: http://www.cmake.org/download/ Documentation is available at: http://www.cmake.org/cmake/help/v3.2 Release notes appear below and are also published at http://www.cmake.org/cmake/help/v3.2/release/3.2.html Some of the more significant features of CMake 3.2 are: * CMake learned to support unicode characters *encoded as UTF-8* on Windows. This was already supported on platforms whose system APIs accept UTF-8 encoded strings. Unicode characters may now be used in CMake code, paths to source files, configured files such as ".h.in" files, and other files read and written by CMake. Note that because CMake interoperates with many other tools, there may still be some limitations when using certain unicode characters. * The "Compile Features" functionality is now aware of features supported by more compilers, including: * Apple Clang ("AppleClang") for Xcode versions 4.4 though 6.1. * GNU compiler versions 4.4 through 5.0 on UNIX and Apple ("GNU"). * Microsoft Visual Studio ("MSVC") for versions 2010 through 2015. * Oracle SolarisStudio ("SunPro") version 12.4. * The "add_custom_command()" and "add_custom_target()" commands learned a new "BYPRODUCTS" option to specify files produced as side effects of the custom commands. These are not outputs because they do not always have to be newer than inputs. * The "file(GENERATE)" command can now generate files which are used as source files for buildsystem targets. Generated files automatically get their "GENERATED" property set to "TRUE". Deprecated and Removed Features: * Files written in the "cmake-language(7)", such as "CMakeLists.txt" or "*.cmake" files, are now expected to be encoded as UTF-8. If files are already ASCII, they will be compatible. If files were in a different encoding, including Latin 1, they will need to be converted. * The "FindOpenGL" module no longer explicitly searches for any dependency on X11 libraries with the "FindX11" module. Such dependencies should not need to be explicit. Applications using X11 APIs themselves should find and link to X11 libraries explicitly. CMake 3.2 Release Notes *********************** Changes made since CMake 3.1 include the following. New Features ============ Syntax ------ * CMake learned to support unicode characters *encoded as UTF-8* on Windows. This was already supported on platforms whose system APIs accept UTF-8 encoded strings. Unicode characters may now be used in CMake code, paths to source files, configured files such as ".h.in" files, and other files read and written by CMake. Note that because CMake interoperates with many other tools, there may still be some limitations when using certain unicode characters. Commands -------- * The "add_custom_command()" and "add_custom_target()" commands learned a new "BYPRODUCTS" option to specify files produced as side effects of the custom commands. These are not outputs because they do not always have to be newer than inputs. * The "add_custom_command()" and "add_custom_target()" commands learned a new "USES_TERMINAL" option to request that the command be given direct access to the terminal if possible. The "Ninja" generator will places such commands in the "console" "pool". Build targets provided by CMake that are meant for individual interactive use, such as "install", are now placed in this pool. * A new "continue()" command was added that can be called inside loop contexts to end the current iteration and start the next one at the top of the loop block. * The "file(LOCK)" subcommand was created to allow CMake processes to synchronize through file and directory locks. * The "file(STRINGS)" now supports UTF-16LE, UTF-16BE, UTF-32LE, UTF- 32BE as "ENCODING" options. * The "install(EXPORT)" command now works with an absolute "DESTINATION" even if targets in the export set are installed with a destination or *usage requirements* specified relative to the install prefix. The value of the "CMAKE_INSTALL_PREFIX" variable is hard-coded into the installed export file as the base for relative references. * The "try_compile()" command source file signature now honors link flags (e.g. "CMAKE_EXE_LINKER_FLAGS") in the generated test project. See policy "CMP0056". * The "try_run()" command learned to honor the "LINK_LIBRARIES" option just as "try_compile()" already does. * The "file(GENERATE)" command now generates the output file with the same permissions as the input file if set. * The "file(GENERATE)" command can now generate files which are used as source files for buildsystem targets. Generated files automatically get their "GENERATED" property set to "TRUE". Variables --------- * The "CMAKE_MATCH_COUNT" variable was introduced to record the number of matches made in the last regular expression matched in an "if()" command or a "string()" command. Properties ---------- * An "ANDROID_API_MIN" target property was introduced to specify the minimum version to be targeted by the toolchain. * A "VS_SHADER_FLAGS" source file property was added to specify additional shader flags to ".hlsl" files, for the Visual Studio generators. Modules ------- * The "ExternalData" module learned to support *Custom Fetch Scripts*. This allows projects to specify custom ".cmake" scripts for fetching data objects during the build. * The "ExternalProject" module learned options to create independent external project step targets that do not depend on the builtin steps. * The "ExternalProject" module "ExternalProject_Add()" command learned a new "CMAKE_CACHE_DEFAULT_ARGS" option to initialize cache values in the external project without setting them on future builds. * The "ExternalProject" module "ExternalProject_Add()" command learned a new "TEST_EXCLUDE_FROM_MAIN" option to exclude tests from the main build. * The "ExternalProject" module "ExternalProject_Add()" command learned a new "UPDATE_DISCONNECTED" option to avoid automatically updating the source tree checkout from version control. * The "FindCUDA" module learned about the "cusolver" library in CUDA 7.0. * The "FindGit" module learned to find the "git" command-line tool that comes with GitHub for Windows installed in user home directories. * A "FindGSL" module was introduced to find the GNU Scientific Library. * A "FindIntl" module was introduced to find the Gettext "libintl" library. * The "FindLATEX" module learned to support components. * The "FindMPI" module learned to find MS-MPI on Windows. * The "FindOpenSSL" module now reports "crypto" and "ssl" libraries separately in "OPENSSL_CRYPTO_LIBRARY" and "OPENSSL_SSL_LIBRARY", respectively, to allow applications to link to one without the other. * The "WriteCompilerDetectionHeader" module learned to create a define for portability of the "cxx_thread_local" feature. The define expands to either the C++11 "thread_local" keyword, or a pre- standardization compiler-specific equivalent, as appropriate. * The "WriteCompilerDetectionHeader" module learned to create multiple output files per compiler and per language, instead of creating one large file. CTest ----- * The "ctest_coverage()" command learned to support Delphi coverage. * The "ctest_coverage()" command learned to support Javascript coverage. * The "CTestCoverageCollectGCOV" module was introduced as an alternative to the "ctest_coverage()" command for collecting "gcov" results for submission to CDash. CPack ----- * The "CPackRPM" module learned options to set per-component descriptions and summaries. See the "CPACK_RPM__PACKAGE_DESCRIPTION" and "CPACK_RPM__PACKAGE_SUMMARY" variables. * The "CPackRPM" module learned options to specify requirements for pre- and post-install scripts. See the "CPACK_RPM_PACKAGE_REQUIRES_PRE" and "CPACK_RPM_PACKAGE_REQUIRES_POST" variables. * The "CPackRPM" module learned options to specify requirements for pre- and post-uninstall scripts. See the "CPACK_RPM_PACKAGE_REQUIRES_PREUN" and "CPACK_RPM_PACKAGE_REQUIRES_POSTUN" variables. * The "CPackRPM" module learned a new "CPACK_RPM__PACKAGE_PREFIX" variable to specify a component-specific value to use instead of "CPACK_PACKAGING_INSTALL_PREFIX". * The "CPackRPM" module learned a new "CPACK_RPM_RELOCATION_PATHS" variable to specify multiple relocation prefixes for a single rpm package. Other ----- * The "cmake(1)" "-E tar" command now supports creating ".xz"-compressed archives with the "J" flag. * The "cmake(1)" "-E tar" command learned a new "--files- from=" option to specify file names using lines in a file to overcome command-line length limits. * The "cmake(1)" "-E tar" command learned a new "--mtime=" option to specify the modification time recorded in tarball entries. * The "Compile Features" functionality is now aware of features supported by more compilers, including: * Apple Clang ("AppleClang") for Xcode versions 4.4 though 6.1. * GNU compiler versions 4.4 through 5.0 on UNIX and Apple ("GNU"). * Microsoft Visual Studio ("MSVC") for versions 2010 through 2015. * Oracle SolarisStudio ("SunPro") version 12.4. * The *AUTORCC* feature now tracks files listed in ".qrc" files as dependencies. If an input file to the "rcc" tool is changed, the tool is automatically re-run. New Diagnostics =============== * The "break()" command now rejects calls outside of a loop context or that pass arguments to the command. See policy "CMP0055". Deprecated and Removed Features =============================== * Files written in the "cmake-language(7)", such as "CMakeLists.txt" or "*.cmake" files, are now expected to be encoded as UTF-8. If files are already ASCII, they will be compatible. If files were in a different encoding, including Latin 1, they will need to be converted. * The "FindOpenGL" module no longer explicitly searches for any dependency on X11 libraries with the "FindX11" module. Such dependencies should not need to be explicit. Applications using X11 APIs themselves should find and link to X11 libraries explicitly. * The implementation of CMake now relies on some C++ compiler features which are not supported by some older compilers. As a result, those old compilers can no longer be used to build CMake itself. CMake continues to be able to generate Makefiles and project files for users of those old compilers however. Compilers known to no longer be capable of building CMake are: * Visual Studio 6 and 7.0 -- superseded by VisualStudio 7.1 and newer. * GCC 2.95 -- superseded by GCC 3 and newer compilers. * Borland compilers -- superseded by other Windows compilers. * Compaq compilers -- superseded by other compilers. * SGI compilers -- IRIX was dropped as a host platform. Other Changes ============= * On Windows and OS X, commands supporting network communication via "https", such as "file(DOWNLOAD)", "file(UPLOAD)", and "ctest_submit()", now support SSL/TLS even when CMake is not built against OpenSSL. The Windows or OS X native SSL/TLS implementation is used by default. OS-configured certificate authorities will be trusted automatically. On other platforms, when CMake is built with OpenSSL, these commands now search for OS-configured certificate authorities in a few "/etc" paths to be trusted automatically. * On OS X with Makefile and Ninja generators, when a compiler is found in "/usr/bin" it is now mapped to the corresponding compiler inside the Xcode application folder, if any. This allows such build trees to continue to work with their original compiler even when "xcode- select" switches to a different Xcode installation. * The Visual Studio generators now write solution and project files in UTF-8 instead of Windows-1252. Windows-1252 supported Latin 1 languages such as those found in North and South America and Western Europe. With UTF-8, additional languages are now supported. * The "Xcode" generator no longer requires a value for the "CMAKE_MAKE_PROGRAM" variable to be located up front. It now locates "xcodebuild" when needed at build time. * When building CMake itself using SolarisStudio 12, the default "libCStd" standard library is not sufficient to build CMake. The SolarisStudio distribution supports compiler options to use "STLPort4" or "libstdc++". An appropriate option to select the standard library is now added automatically when building CMake with SolarisStudio compilers. ----------------------------------------------------------------------------- CMake 3.2.0 was tagged but never announced due to a regression reported in 3.2.0-rc2 just prior to the announcement being sent. Changes in CMake 3.2.1 since 3.2.0 are: Brad King (6): Makefile: Fix multiple custom command outputs regression (#15116) configure_file: Do not warn about newline style arguments Tests: Add more signature tests to RunCMake.configure_file test Ninja: Improve internal check for generating at the top-level (#15436) UseSWIG: Avoid if() auto-dereferene in quoted arguments CMake 3.2.1 Changes in CMake 3.2.0 since 3.2.0-rc2 are: Brad King (3): VS: Do not generate a BOM in .sln files Diagnose invalid _STANDARD value instead of crashing (#15426) CMake 3.2.0 Domen Vrankar (1): CPackRPM: Fix handling of relocation prefix parent directories Paul Martin (1): KWSys SystemTools: Update CopyFileAlways stream library workarounds Robert Goulet (1): install: Write the entire installation manifest at once ----------------------------------------------------------------------------- From Chiara.Maffei at unitn.it Wed Mar 11 10:39:20 2015 From: Chiara.Maffei at unitn.it (Maffei, Chiara) Date: Wed, 11 Mar 2015 15:39:20 +0100 Subject: [CMake] missing bin folder In-Reply-To: References: <5A75DDB72F4A3C4297406397CD804C0D1574A428F1@MBX.unitn.it> , Message-ID: <5A75DDB72F4A3C4297406397CD804C0D1574A428FC@MBX.unitn.it> Dear Petr, thanks for your reply Yes I do have cmakefiles. What I have looks good... Chiara Maffei PhD Student MR Methods Lab CIMeC Center for Mind/Brain Sciences University of Trento ________________________________________ From: Petr Kmoch [petr.kmoch at gmail.com] Sent: Wednesday, March 11, 2015 8:49 AM To: Domen Vrankar Cc: Maffei, Chiara; cmake at cmake.org Subject: Re: [CMake] missing bin folder Hi Chiara, just a sanity check: have you actually run a build? Or is it that even the buildsystem (Makefiles, VS projects, what have you) is not there? Petr On Wed, Mar 11, 2015 at 8:35 AM, Domen Vrankar > wrote: > however I am facing a quite dramatic issue: after configuration and generation I do have my build folder, but I miss the bin folder inside it, and all build folders result empty. One thing comes to mind... If you accidentally generate build structure inside root source directory and later run generation again from another directory the structure is refreshed in the source tree not on the location where you expect the generated files to be. This can be fixed by deleting CMake generated files in source tree. This was the behavior of CMake 2.8.x - I'm not certain if later versions work the same way in such situations. Another option would be an error during configuration/generation but that would be printed to standard error... Hope this helps, Domen -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake From rcdailey.lists at gmail.com Wed Mar 11 12:42:36 2015 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Wed, 11 Mar 2015 11:42:36 -0500 Subject: [CMake] CMake, Android, and Eclipse ADT Integration Message-ID: I am implementing support for Android in my CMake scripts by using custom commands to invoke 'ant' to build the final APK. If I do it this way, and I generate for eclipse, how can I make sure it will integrate with the ADT plugin? Basically I want to be able to right-click my project in Eclipse (generated by CMake) and "Run as Android Application" and have it deploy to the device. What is required to make this happen? Also any idea how debugging will be impacted? Thanks. From robert.maynard at kitware.com Wed Mar 11 13:05:49 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 11 Mar 2015 13:05:49 -0400 Subject: [CMake] Mastering CMake updated to CMake 3.1 In-Reply-To: References: <54f88ec9.4a70e00a.2d8b.7195SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: It is on my todo list. On Sat, Mar 7, 2015 at 2:52 PM, Ryan Pavlik wrote: > Will the excerpted CMake tutorial [1] be updated? I find that to be a useful > reference to point newcomers to. If nothing else, it looks like the source > code didn't handle the move to the updated website well as all angle-bracket > includes got eaten as HTML tags presumably. > > [1] http://www.cmake.org/cmake-tutorial/ > > Ryan > > On Thu, Mar 5, 2015 at 12:55 PM Robert Maynard > wrote: >> >> Hi, >> >> We currently have no plans to release the CMake book in an electronic >> format. >> >> On Thu, Mar 5, 2015 at 11:51 AM, Nagy-Egri M??t?? Ferenc >> wrote: >>> >>> Are there any plans on releasing a digital version (e-book) of this >>> guide? I very much like reading books on my phablet, as it is always t hand >>> and seems a lot more friendly, than a 700+ page book. >>> >>> Felad?: Robert Maynard >>> Elk?ldve: ?kedd?, ?2015?. ?m?rcius? ?3?. ?22?:?26 >>> C?mzett: cmake at cmake.org >>> >>> We just wanted to let everyone know that Mastering CMake ( >>> http://www.kitware.com/products/books/CMakeBook.html) has been updated for >>> version 3.1 and is available on Amazon. >>> >>> It is also available on Amazon's sites for Spain, the United Kingdom, >>> Germany, France, and Italy. Please see >>> http://www.kitware.com/products/books.php for the links. >>> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware 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 tim.gallagher at gatech.edu Wed Mar 11 16:17:52 2015 From: tim.gallagher at gatech.edu (Tim Gallagher) Date: Wed, 11 Mar 2015 16:17:52 -0400 (EDT) Subject: [CMake] Getting empty package with CPack Message-ID: <1489876942.7976664.1426105072649.JavaMail.root@mail.gatech.edu> Hi all, I'm trying to play with CPack to build an installer for our code and I'm pretty confused. I am using the self-extracting TGZ generator on CMake 2.8.8. My CMakeLists.txt is really long, but I included what I think are the important parts under my signature. I configure the build and the package target shows up which is great. I can see in the CPackConfig.cmake file that my variables are set the same as they were in my CMakeLists.txt. When I run 'make package', it generates my .sh file. But then when I run the extractor, it just creates an empty folder. I would have expected it to create `/bin/leslie.x`, `/bin/run_leslie.py` and `/bin/run_leslie.sh`. I also tried it with the CPACK_INSTALL_CMAKE_PROJECTS set to "${PROJECT_BINARY_DIR};LESLIE;leslie;/bin" but to no avail. Does anybody have any suggestions on why my files aren't getting packaged? I know the CMakeLists.txt prior to the CPack commands work, but this is my first go at using CPack. Thanks, Tim ------------------------------------------ cmake_minimum_required(VERSION 2.8.6) project(LESLIE) ... set(LESLIE_MAJOR_VERSION GTR2) set(LESLIE_MINOR_VERSION 0) set(LESLIE_PATCH_VERSION 4) ... install(FILES ${PROJECT_BINARY_DIR}/run_leslie.py DESTINATION ${CMAKE_INSTALL_PREFIX} PERMISSIONS OWNER_READ OWNER_EXECUTE GROUP_READ GROUP_EXECUTE WORLD_READ WORLD_EXECUTE) install(FILES ${PROJECT_BINARY_DIR}/run_leslie.sh DESTINATION ${CMAKE_INSTALL_PREFIX}) install(TARGETS leslie RUNTIME DESTINATION ${CMAKE_INSTALL_PREFIX}) set(CPACK_GENERATOR "STGZ") set(CPACK_INSTALL_CMAKE_PROJECTS "${PROJECT_BINARY_DIR};LESLIE;ALL;/bin") set(CPACK_PACKAGE_VERSION_MAJOR ${LESLIE_MAJOR_VERSION}) set(CPACK_PACKAGE_VERSION_MINOR ${LESLIE_MINOR_VERSION}) set(CPACK_PACKAGE_VERSION_PATCH ${LESLIE_PATCH_VERSION}) set(CPACK_PACKAGE_VENDOR "Computational Combustion Laboratory") include(CPack) From roman.wueger at gmx.at Wed Mar 11 17:22:18 2015 From: roman.wueger at gmx.at (=?iso-8859-1?Q?Roman_W=FCger?=) Date: Wed, 11 Mar 2015 22:22:18 +0100 Subject: [CMake] Problems with WriteCompilerDetectionHeader and cxx_nullptr Message-ID: <034401d05c41$7572ecc0$6058c640$@gmx.at> Hello, i tried to use the generated compiler detection header but get an error if I use the cxx_nullptr feature on a compiler which doesn?t support C++11. void doSomething(int n, bool *ok = 0) { if (ok) *ok = true; if (n != 0) { if (ok) *ok = false; } } This simple example produces the following error on Mac OS: error: cannot initialize a parameter of type 'bool *' with an rvalue of type 'void *' void doSomething(int n = 1, bool *ok = static_cast(0)) { ^ ~~~~~~~~~~~~~~~~~~~~~ However, if C++11 could be used then the ?nullptr? is working fine. Couldn?t ?static_cast(0)? simply be replaced with ?0?? Best Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From felix.schwitzer at gmx.at Wed Mar 11 18:08:37 2015 From: felix.schwitzer at gmx.at (felix) Date: Wed, 11 Mar 2015 15:08:37 -0700 (MST) Subject: [CMake] Avoid re-linking dependency of external shared lib in a new project. In-Reply-To: References: Message-ID: <1426111717142-7590000.post@n2.nabble.com> Not sure if I'm right, but your use case looks to me as an interface-library. For that the docu says "A primary use-case for INTERFACE libraries is header-only libraries." see http://www.cmake.org/cmake/help/v3.2/manual/cmake-buildsystem.7.html#interface-libraries -- View this message in context: http://cmake.3232098.n2.nabble.com/Avoid-re-linking-dependency-of-external-shared-lib-in-a-new-project-tp7589911p7590000.html Sent from the CMake mailing list archive at Nabble.com. From nilsgladitz at gmail.com Wed Mar 11 18:32:24 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Wed, 11 Mar 2015 23:32:24 +0100 Subject: [CMake] Getting empty package with CPack In-Reply-To: <1489876942.7976664.1426105072649.JavaMail.root@mail.gatech.edu> References: <1489876942.7976664.1426105072649.JavaMail.root@mail.gatech.edu> Message-ID: <5500C278.9080509@gmail.com> On 11.03.2015 21:17, Tim Gallagher wrote: > Hi all, > > I'm trying to play with CPack to build an installer for our code and I'm pretty confused. I am using the self-extracting TGZ generator on CMake 2.8.8. My CMakeLists.txt is really long, but I included what I think are the important parts under my signature. > > I configure the build and the package target shows up which is great. I can see in the CPackConfig.cmake file that my variables are set the same as they were in my CMakeLists.txt. When I run 'make package', it generates my .sh file. But then when I run the extractor, it just creates an empty folder. I would have expected it to create `/bin/leslie.x`, `/bin/run_leslie.py` and `/bin/run_leslie.sh`. > > I also tried it with the CPACK_INSTALL_CMAKE_PROJECTS set to "${PROJECT_BINARY_DIR};LESLIE;leslie;/bin" but to no avail. > > Does anybody have any suggestions on why my files aren't getting packaged? I know the CMakeLists.txt prior to the CPack commands work, but this is my first go at using CPack. Try with relative install destinations e.g. "DESTINATION ." instead of "DESTINATION ${CMAKE_INSTALL_PREFIX}". Relative paths are already relative to CMAKE_INSTALL_PREFIX by default where appropriate and many CPack generators can not handle absolute paths. Nils From tim.gallagher at gatech.edu Wed Mar 11 18:54:18 2015 From: tim.gallagher at gatech.edu (Tim Gallagher) Date: Wed, 11 Mar 2015 18:54:18 -0400 (EDT) Subject: [CMake] Getting empty package with CPack In-Reply-To: <5500C278.9080509@gmail.com> Message-ID: <1459967810.8025211.1426114458666.JavaMail.root@mail.gatech.edu> Nils, Thanks! That definitely got my files into the package, I would have never figured that one out! I have another, related question though. Maybe what I'm doing cannot be done, but I would like to have a different file layout when building a package than when using make install. I thought if I did: set(CPACK_INSTALL_CMAKE_PROJECTS "${PROJECT_BINARY_DIR};LESLIE;ALL;/bin") then all of my targets would go in /bin even though when I run `make install` all of my targets just go to $CMAKE_INSTALL_PREFIX. The way users who only have access to our binaries would use our code is very different from the way people who have access to our source tree would use the code and I need to figure out a way to package it that way. Is it at all possible to have an install tree be unique when using CPack vs using the installation in CMake? Is that something that if I want to do, I'd have to use CPack outside of our CMake system? Thanks, Tim ----- Original Message ----- From: "Nils Gladitz" To: "tim gallagher" , cmake at cmake.org Sent: Wednesday, March 11, 2015 6:32:24 PM Subject: Re: [CMake] Getting empty package with CPack On 11.03.2015 21:17, Tim Gallagher wrote: > Hi all, > > I'm trying to play with CPack to build an installer for our code and I'm pretty confused. I am using the self-extracting TGZ generator on CMake 2.8.8. My CMakeLists.txt is really long, but I included what I think are the important parts under my signature. > > I configure the build and the package target shows up which is great. I can see in the CPackConfig.cmake file that my variables are set the same as they were in my CMakeLists.txt. When I run 'make package', it generates my .sh file. But then when I run the extractor, it just creates an empty folder. I would have expected it to create `/bin/leslie.x`, `/bin/run_leslie.py` and `/bin/run_leslie.sh`. > > I also tried it with the CPACK_INSTALL_CMAKE_PROJECTS set to "${PROJECT_BINARY_DIR};LESLIE;leslie;/bin" but to no avail. > > Does anybody have any suggestions on why my files aren't getting packaged? I know the CMakeLists.txt prior to the CPack commands work, but this is my first go at using CPack. Try with relative install destinations e.g. "DESTINATION ." instead of "DESTINATION ${CMAKE_INSTALL_PREFIX}". Relative paths are already relative to CMAKE_INSTALL_PREFIX by default where appropriate and many CPack generators can not handle absolute paths. Nils From lukasz at tasz.eu Thu Mar 12 04:00:09 2015 From: lukasz at tasz.eu (=?UTF-8?B?xYF1a2FzeiBUYXN6?=) Date: Thu, 12 Mar 2015 09:00:09 +0100 Subject: [CMake] control dependencies in cmake stage In-Reply-To: References: Message-ID: Hi, Take a look also at Michael suggestion, http://www.cmake.org/pipermail/cmake/2011-November/047333.html br L. ?ukasz Tasz 2015-03-11 0:15 GMT+01:00 Mark Abraham : > Hi, > > Sure, this is straightforward to do all at make time, if you're prepared to > find out what the names of the generated files are. They must follow some > pattern ;-). Solutions with make-time globbing are surely impossible, and > Petr's IF idea seems brittle to me. > > See (for example) > https://github.com/gromacs/gromacs/blob/master/src/gromacs/CMakeLists.txt#L154. > The idea is that you have some target that does the generation, and you make > the eventual library/executable depend on its output files. The target that > contains the generation command has its own dependencies, so you don't have > to re-generate if those don't go out of date. In that example, > gmx_configure_version_file just wraps configure_file(), which sets up that > dependency chain. You'd need an add_custom_command(), it seems, whose OUTPUT > had the list of generated files. There's no problem to use add_library() > with a file generated in the build tree - just mention it in an output. > > There are several much more complicated examples at > https://github.com/gromacs/gromacs/blob/master/docs/CMakeLists.txt. For > example, we build a gmx binary that writes the same text we display with > "gmx topic -h" instead as topic.rst restructedText, which is then parsed > with Sphinx to produce manpages that go in the tarball via CPack, or to > produce HTML to go on our webpage. Helper scripts mostly live in > https://github.com/gromacs/gromacs/tree/master/cmake > > Cheers, > > Mark > > > On Tue, Mar 10, 2015 at 6:06 PM, Tomasz Majchrowski > wrote: >> >> (sorry if you received this message twice) >> >> Hi Mark >> >> This is the set of C++ source code files. This set will be compiled >> during the make stage. Ideally will be to move generation to make stage. >> Unfortunately I don't know the name of the files that will be generated >> before generation phase occurs. >> >> Therefore I can't use set_source_files_properties( foo.cxx PROPERTIES >> GENERATED true) in cmake stage. Please drop a line if you know how to bypass >> this limitation. >> >> Thanks, Tomasz. >> >> 2015-03-10 7:05 GMT+01:00 Mark Abraham : >>> >>> Hi, >>> >>> What are you generating that must be done at cmake time? >>> >>> Mark >>> >>> On 09/03/2015 5:36 pm, "Tomasz Majchrowski" >>> wrote: >>>> >>>> Hi, >>>> >>>> I'm wondering if there is an easy way to control the dependencies in the >>>> cmake stage. Basically I would like skip execution of some script run over >>>> execute_process in case some input files didn't change. >>>> >>>> The regular way will be to use add_custom_command & add_custom_target >>>> however those required targets, so the make stage. >>>> >>>> Please advice how to proceed in case there is need to control this >>>> already in cmake stage? >>>> >>>> Thanks, Tomasz. >>>> >>>> >>>> -- >>>> Pozdrawiam/Best regards/Mit freundlichen Gr??en, Tomasz Majchrowski, >>>> Information Technology and Services Consultant and Contractor >>>> >>>> -- >>>> >>>> Powered by www.kitware.com >>>> >>>> Please keep messages on-topic and check the CMake FAQ at: >>>> http://www.cmake.org/Wiki/CMake_FAQ >>>> >>>> Kitware offers various services to support the CMake community. For more >>>> information on each offering, please visit: >>>> >>>> CMake Support: http://cmake.org/cmake/help/support.html >>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>>> >>>> Visit other Kitware open-source projects at >>>> http://www.kitware.com/opensource/opensource.html >>>> >>>> Follow this link to subscribe/unsubscribe: >>>> http://public.kitware.com/mailman/listinfo/cmake >>>> >>>> -- >>>> Pozdrawiam/Best regards/Mit freundlichen Gr??en, Tomasz Majchrowski, >>>> Information Technology and Services Consultant and Contractor > > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From roman.wueger at gmx.at Thu Mar 12 06:59:50 2015 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Thu, 12 Mar 2015 11:59:50 +0100 Subject: [CMake] Problems with WriteCompilerDetectionHeader and cxx_nullptr Message-ID: Hello, I've attached a patch for this problem. Best Regards -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-WCDH-Fix-cxx_nullptr-for-compilers-which-doesn-t-sup 01.patch URL: -------------- next part -------------- From mark.j.abraham at gmail.com Thu Mar 12 12:50:31 2015 From: mark.j.abraham at gmail.com (Mark Abraham) Date: Thu, 12 Mar 2015 17:50:31 +0100 Subject: [CMake] control dependencies in cmake stage In-Reply-To: References: Message-ID: Hi, In that case, you could have the generator generate a master source file with a known name that #includes the real generated files. This means that the generation can have clean dependencies, but does lose any benefits from parallel make. It also keeps the intrinsic complexity of the generation close to itself, rather than unduly complicating the build system. Up to you. Mark On 11/03/2015 6:40 pm, "Tomasz Majchrowski" wrote: > Thank you Mark for information. The input for the generator is in-house > developed language. The decision what kind of files will be generated is > made based on the grammar of this language. > > In the current implementation of the generator the extraction of the file > list will take more or less the same time as execution of the generation > phase itself. Otherwise we will definitely use make phase. > > Best regards, Tomasz. > > 2015-03-11 0:15 GMT+01:00 Mark Abraham : > >> Hi, >> >> Sure, this is straightforward to do all at make time, if you're prepared >> to find out what the names of the generated files are. They must follow >> some pattern ;-). Solutions with make-time globbing are surely impossible, >> and Petr's IF idea seems brittle to me. >> >> See (for example) >> https://github.com/gromacs/gromacs/blob/master/src/gromacs/CMakeLists.txt#L154. >> The idea is that you have some target that does the generation, and you >> make the eventual library/executable depend on its output files. The target >> that contains the generation command has its own dependencies, so you don't >> have to re-generate if those don't go out of date. In that example, >> gmx_configure_version_file just wraps configure_file(), which sets up that >> dependency chain. You'd need an add_custom_command(), it seems, whose >> OUTPUT had the list of generated files. There's no problem to use >> add_library() with a file generated in the build tree - just mention it in >> an output. >> >> There are several much more complicated examples at >> https://github.com/gromacs/gromacs/blob/master/docs/CMakeLists.txt. For >> example, we build a gmx binary that writes the same text we display with >> "gmx topic -h" instead as topic.rst restructedText, which is then parsed >> with Sphinx to produce manpages that go in the tarball via CPack, or to >> produce HTML to go on our webpage. Helper scripts mostly live in >> https://github.com/gromacs/gromacs/tree/master/cmake >> >> Cheers, >> >> Mark >> >> >> On Tue, Mar 10, 2015 at 6:06 PM, Tomasz Majchrowski < >> usenet at majchrowski.de> wrote: >> >>> (sorry if you received this message twice) >>> >>> Hi Mark >>> >>> This is the set of C++ source code files. This set will be compiled >>> during the make stage. Ideally will be to move generation to make stage. >>> Unfortunately I don't know the name of the files that will be generated >>> before generation phase occurs. >>> >>> Therefore I can't use set_source_files_properties( foo.cxx PROPERTIES >>> GENERATED true) in cmake stage. Please drop a line if you know how to >>> bypass this limitation. >>> >>> Thanks, Tomasz. >>> >>> 2015-03-10 7:05 GMT+01:00 Mark Abraham : >>> >>>> Hi, >>>> >>>> What are you generating that must be done at cmake time? >>>> >>>> Mark >>>> On 09/03/2015 5:36 pm, "Tomasz Majchrowski" >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> I'm wondering if there is an easy way to control the dependencies in >>>>> the cmake stage. Basically I would like skip execution of some script run >>>>> over execute_process in case some input files didn't change. >>>>> >>>>> The regular way will be to use add_custom_command & add_custom_target >>>>> however those required targets, so the make stage. >>>>> >>>>> Please advice how to proceed in case there is need to control this >>>>> already in cmake stage? >>>>> >>>>> Thanks, Tomasz. >>>>> >>>>> >>>>> -- >>>>> Pozdrawiam/Best regards/Mit freundlichen Gr??en, Tomasz Majchrowski, >>>>> Information Technology and Services Consultant and Contractor >>>>> >>>>> -- >>>>> >>>>> Powered by www.kitware.com >>>>> >>>>> Please keep messages on-topic and check the CMake FAQ at: >>>>> http://www.cmake.org/Wiki/CMake_FAQ >>>>> >>>>> Kitware offers various services to support the CMake community. For >>>>> more information on each offering, please visit: >>>>> >>>>> CMake Support: http://cmake.org/cmake/help/support.html >>>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>>>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>>>> >>>>> Visit other Kitware open-source projects at >>>>> http://www.kitware.com/opensource/opensource.html >>>>> >>>>> Follow this link to subscribe/unsubscribe: >>>>> http://public.kitware.com/mailman/listinfo/cmake >>>>> >>>>> -- >>>>> Pozdrawiam/Best regards/Mit freundlichen Gr??en, Tomasz Majchrowski, >>>>> Information Technology and Services Consultant and Contractor >>>>> >>>> >>>> >> > > > -- > Pozdrawiam/Best regards/Mit freundlichen Gr??en, Tomasz Majchrowski, > Information Technology and Services Consultant and Contractor > -------------- next part -------------- An HTML attachment was scrubbed... URL: From s.zelzer at dkfz-heidelberg.de Thu Mar 12 13:35:14 2015 From: s.zelzer at dkfz-heidelberg.de (Sascha Zelzer) Date: Thu, 12 Mar 2015 18:35:14 +0100 Subject: [CMake] C++11 and try_compile Message-ID: <5501CE52.5090700@dkfz-heidelberg.de> Hi, tldr; In a C++11 enabled CMake project, is try_compile() supposed to *not* use -std=c++11 by default? --- Long(er) version If I use a minimal CMakeLists.txt file like the one below with gcc and try_compile() compiles a source file containing C++11 features, I would naively assume that try_compile() uses the -std=c++11 flag because CMAKE_CXX_STANDARD_REQUIRED is set to ON. However, this is not the case (tested up to CMake 3.2.1). The C++11 language standard and feature support in CMake is awesome, but in order to get correct results for commands like try_compile, check_cxx_compiler_flag, etc. I still need to manually set -std=c++11 to CMAKE_FLAGS or similar command arguments / variables. Is there some policy which could be set or a concrete reason for the described behavior? How do people deal with try_compile checks in C++11 enabled projects? Thanks, Sascha ------------ cmake_minimum_required(VERSION 3.2.1) project(cxx_test) include(CheckCXXSourceCompiles) include(CheckCXXCompilerFlag) set(CMAKE_CXX_STANDARD 11) set(CMAKE_CXX_STANDARD_REQUIRED 1) set(CMAKE_CXX_EXTENSIONS 0) try_compile(TRY_COMPILE_SUCCESS ${CMAKE_CURRENT_BINARY_DIR} ${CMAKE_CURRENT_SOURCE_DIR}/main.cpp) if(NOT TRY_COMPILE_SUCCESS) message(WARNING "try_compile failed") endif() file(READ main.cpp source) check_cxx_source_compiles("${source}" COMPILE_SUCCESS) if(NOT COMPILE_SUCCESS) message(WARNING "check_cxx_source_compiles failed") endif() check_cxx_compiler_flag(-fconstexpr-depth=4 FLAG_SUCCESS) if(NOT FLAG_SUCCESS) message(WARNING "check_cxx_compiler_flag failed") endif() add_executable(cxx_test main.cpp) From brad.king at kitware.com Thu Mar 12 16:19:44 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 12 Mar 2015 16:19:44 -0400 Subject: [CMake] Problems with WriteCompilerDetectionHeader and cxx_nullptr In-Reply-To: References: Message-ID: <5501F4E0.6060901@kitware.com> On 03/11/2015 05:22 PM, Roman W?ger wrote: > This simple example produces the following error on Mac OS: > error: cannot initialize a parameter of type 'bool *' with an rvalue of type 'void *' > void doSomething(int n = 1, bool *ok = static_cast(0)) { > ^ ~~~~~~~~~~~~~~~~~~~~~ Indeed. It looks like it was written that way originally in the module: Add the WriteCompilerDetectionHeader module. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=62a4a67d There is a proposed library-only implementation of nullptr here: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2431.pdf "1.1 Alternative #1: A Library Implementation of nullptr" but that is probably too complicated for this compatibility macro that is just supposed to provide the advantages of C++11 when it is available but otherwise work as normal C++98. On 03/12/2015 06:59 AM, Roman W?ger wrote: > -# define ${def_value} static_cast(0) > +# ifdef NULL > +# define ${def_value} NULL > +# else > +# define ${def_value} 0 > +# endif In C++98, NULL is always just "0" AFAIK so the condition may not be needed. I think it is cleaner to not have the definition depend on the order of includes (whether a standard header provides NULL). Thanks, -Brad From victorsv at gmail.com Fri Mar 13 05:18:06 2015 From: victorsv at gmail.com (victor sv) Date: Fri, 13 Mar 2015 10:18:06 +0100 Subject: [CMake] Check_library_exists don't found a function in a static library In-Reply-To: References: Message-ID: Hello again, the problem was that the static version of the METIS library must be linked with the MATH library (libm). After adding: SET(CMAKE_REQUIRED_LIBRARIES ${CMAKE_REQUIRED_LIBRARIES} /path/to/math/library ) it seems that all works fine. Best regards, V?ctor. 2015-03-10 11:02 GMT+01:00 victor sv : > Hello all, > > I'm a newbie using CMake and I'm trying to migrate the compilation of a > fortran project to CMake. > > I'm trying to detect the METIS library with find_library(). Inside my > FindMETIS.cmake I want to check the existence of some functions to set the > library version with: > > CHECK_LIBRARY_EXISTS(metis METIS_SetDefaultOptions /path/to/metis > VARIABLE_NAME) > > > If /path/to/metis contains the METIS shared library (libmetis.so) it works > as expected, but if /path/to/metis only contains the static version of the > library (libmetis.a) CHECK_LIBRARY_EXISTS cannot found this function... > > I check that the library contains this function with the following result: > > $ nm libmetis.a | grep -i setdefaultoptions >> 0000000000000210 T metis_setdefaultoptions >> 0000000000000220 T metis_setdefaultoptions_ >> 0000000000000230 T metis_setdefaultoptions__ >> U METIS_SetDefaultOptions >> 0000000000000200 T METIS_SETDEFAULTOPTIONS >> U METIS_SetDefaultOptions >> 0000000000000030 T METIS_SetDefaultOptions >> > > I don't know if this the expected behaviour of this macro, but anyway I > need to do this check in both, shared and static library. How can I do this? > > Any help would be appreciated. > > Thanks, > V?ctor. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at classdesign.com Fri Mar 13 10:06:35 2015 From: bill at classdesign.com (Bill Somerville) Date: Fri, 13 Mar 2015 14:06:35 +0000 Subject: [CMake] How to execute an external project target as part of a standard target. Message-ID: <5502EEEB.8090303@classdesign.com> Hi All, I have a superbuild style project consisting of a few external projects. I wish to build the install target of one of them as part of the install target of the parent project. I had it working by adding a step target called install and adding a custom target to the parent project that depends on the child step target. E.g. ExternalProject_Add (xxx SVN_REPOSITORY ${xxx_repo} CMAKE_ARGS -D CMAKE_INSTALL_PATH= INSTALL_DIR ${CMAKE_INSTALL_PREFIX} STEP_TARGETS install) add_custom_target (install DEPENDS xxx-install) This arrangement allowed me to 'cmake --build . --target install' and have the child project install target run. Now CMake complains about policy CMP0037, because I cannot define a reserved target name, so it seems I cannot abuse the 'install' target by adding extra dependencies any more. Is there a better way to link child and parent targets that doesn't invoke this error? Regards Bill Somerville. From tim.gallagher at gatech.edu Fri Mar 13 12:43:15 2015 From: tim.gallagher at gatech.edu (Tim Gallagher) Date: Fri, 13 Mar 2015 12:43:15 -0400 (EDT) Subject: [CMake] Prevent ExternalProject from updating git submodules Message-ID: <742709706.8820193.1426264995227.JavaMail.root@mail.gatech.edu> Hi everybody, I'm plugging away at using the ExternalProject features to package up our code. Looking at the documentation for ExternalProject_Add, it says: ... [GIT_SUBMODULES modules...] # Git submodules that shall be updated, all if empty ... which is cool, but what do I do if I don't want any submodules updated at all? It seems my only choices are: 1. Update them all (leaving GIT_SUBMODULES empty) 2. Update some of them (set GIT_SUBMODULES to a list to update) but there's no 3rd option of not updating them at all. Any advice on how to keep it from updating any submodules? Thanks, Tim From tim.gallagher at gatech.edu Fri Mar 13 13:05:42 2015 From: tim.gallagher at gatech.edu (Tim Gallagher) Date: Fri, 13 Mar 2015 13:05:42 -0400 (EDT) Subject: [CMake] Prevent ExternalProject from updating git submodules In-Reply-To: Message-ID: <22104694.8830451.1426266342257.JavaMail.root@mail.gatech.edu> Hi Nicholas, I tried that and no luck. I've done both: ExternalProject_Add(... GIT_SUBMODULES "") and set(empty_list "") ExternalProject_Add(... GIT_SUBMODULES "${empty_list}") and it still tries to update the submodules. I know it's seeing the option -- if I pass in a name of a submodule that doesn't exist, it will crash when it tries to check out that made up one. But I can't seem to get it to not update any of them. Tim ----- Original Message ----- From: "Nicholas Yue" To: "tim gallagher" Sent: Friday, March 13, 2015 12:52:41 PM Subject: Re: [CMake] Prevent ExternalProject from updating git submodules Hi Tim, I use external project but not the GIT_SUBMODULES but maybe the following might work (1) Create an empty list (2) set GIT_SUBMODULES to that empty list Cheers On 13 March 2015 at 09:43, Tim Gallagher < tim.gallagher at gatech.edu > wrote: Hi everybody, I'm plugging away at using the ExternalProject features to package up our code. Looking at the documentation for ExternalProject_Add, it says: ... [GIT_SUBMODULES modules...] # Git submodules that shall be updated, all if empty ... which is cool, but what do I do if I don't want any submodules updated at all? It seems my only choices are: 1. Update them all (leaving GIT_SUBMODULES empty) 2. Update some of them (set GIT_SUBMODULES to a list to update) but there's no 3rd option of not updating them at all. Any advice on how to keep it from updating any submodules? Thanks, Tim -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake -- Nicholas Yue Graphics - Arnold, Alembic, RenderMan, OpenGL, HDF5 Custom Dev - C++ porting, OSX, Linux, Windows http://au.linkedin.com/in/nicholasyue https://vimeo.com/channels/naiadtools -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim.gallagher at gatech.edu Fri Mar 13 13:32:56 2015 From: tim.gallagher at gatech.edu (Tim Gallagher) Date: Fri, 13 Mar 2015 13:32:56 -0400 (EDT) Subject: [CMake] Prevent ExternalProject from updating git submodules In-Reply-To: <22104694.8830451.1426266342257.JavaMail.root@mail.gatech.edu> Message-ID: <2056520405.8840775.1426267976138.JavaMail.root@mail.gatech.edu> Okay, well, I hacked it so it would work for me: Our code requires a step between cloning and the submodule initalization. All of our code is hosted on a server behind a firewall, so when we are on our network the URL's for the submodules work great. But outside our network, git hardcodes the server names in the submodule URLs so we have a script to see what URL the clone came from and then changes all of the submodule URL's to use that same server. Outside our network, we build an SSH tunnel in and clone through a port forward to our server, so the .gitmodules file needs modified to set that up. Anyway, to make the ExternalProject work for me, I had to delete the submodule init section of the clone script. Then I could add an extra step between "download" and "update" to run our name-mangling script. I also modified the update step in ExternalProject so instead of running "git submodule update --recursive" it now runs "git submodule update --init --recursive" I don't know if anybody else has a similar use case as I do so maybe upstream changes are not needed. However, I will say that all of our codes have submodules in them that are not needed for the code to compile -- they are things like documentation or developer scripts/tools -- and so checking them out should be completely optional. It would be good if there was a way to not run the submodule init/update at all during the download or update steps, my odd use case notwithstanding. Tim ----- Original Message ----- From: "Tim Gallagher" To: "cmake" Sent: Friday, March 13, 2015 1:05:42 PM Subject: Re: [CMake] Prevent ExternalProject from updating git submodules Hi Nicholas, I tried that and no luck. I've done both: ExternalProject_Add(... GIT_SUBMODULES "") and set(empty_list "") ExternalProject_Add(... GIT_SUBMODULES "${empty_list}") and it still tries to update the submodules. I know it's seeing the option -- if I pass in a name of a submodule that doesn't exist, it will crash when it tries to check out that made up one. But I can't seem to get it to not update any of them. Tim ----- Original Message ----- From: "Nicholas Yue" To: "tim gallagher" Sent: Friday, March 13, 2015 12:52:41 PM Subject: Re: [CMake] Prevent ExternalProject from updating git submodules Hi Tim, I use external project but not the GIT_SUBMODULES but maybe the following might work (1) Create an empty list (2) set GIT_SUBMODULES to that empty list Cheers On 13 March 2015 at 09:43, Tim Gallagher < tim.gallagher at gatech.edu > wrote: Hi everybody, I'm plugging away at using the ExternalProject features to package up our code. Looking at the documentation for ExternalProject_Add, it says: ... [GIT_SUBMODULES modules...] # Git submodules that shall be updated, all if empty ... which is cool, but what do I do if I don't want any submodules updated at all? It seems my only choices are: 1. Update them all (leaving GIT_SUBMODULES empty) 2. Update some of them (set GIT_SUBMODULES to a list to update) but there's no 3rd option of not updating them at all. Any advice on how to keep it from updating any submodules? Thanks, Tim -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake -- Nicholas Yue Graphics - Arnold, Alembic, RenderMan, OpenGL, HDF5 Custom Dev - C++ porting, OSX, Linux, Windows http://au.linkedin.com/in/nicholasyue https://vimeo.com/channels/naiadtools -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From fifteenknots505 at gmail.com Fri Mar 13 17:23:50 2015 From: fifteenknots505 at gmail.com (Martin Weber) Date: Fri, 13 Mar 2015 22:23:50 +0100 Subject: [CMake] Is there a cmake variable/property for temp dir? Message-ID: <2109185.u2u0edct7K@linux> ... coding the if(win32) set(cmakepp_tmp_dir "$ENV{TMP}") else it)linux) set(cmakepp_tmp_dir "$ENV{TMPDIR}") becomes tedious. if you have to deal with cross platform builds. TIA, Martin -- Quidquid latine dictum sit, altum viditur. From nilsgladitz at gmail.com Fri Mar 13 17:30:14 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 13 Mar 2015 22:30:14 +0100 Subject: [CMake] Is there a cmake variable/property for temp dir? In-Reply-To: <2109185.u2u0edct7K@linux> References: <2109185.u2u0edct7K@linux> Message-ID: <550356E6.8030608@gmail.com> On 13.03.2015 22:23, Martin Weber wrote: > ... coding the > if(win32) > set(cmakepp_tmp_dir "$ENV{TMP}") > else it)linux) > set(cmakepp_tmp_dir "$ENV{TMPDIR}") > becomes tedious. if you have to deal with cross platform builds. There isn't as far as I know ... why do you need it though? Why not go with somewhere in the build directory? It is already full of temporary build artifacts. Nils From fifteenknots505 at gmail.com Fri Mar 13 18:09:59 2015 From: fifteenknots505 at gmail.com (Martin Weber) Date: Fri, 13 Mar 2015 23:09:59 +0100 Subject: [CMake] Is there a cmake variable/property for temp dir? In-Reply-To: <550356E6.8030608@gmail.com> References: <2109185.u2u0edct7K@linux> <550356E6.8030608@gmail.com> Message-ID: <5384624.gZclbbjdKl@linux> Am Freitag, 13. M?rz 2015, 22:30:14 schrieb Nils Gladitz: > On 13.03.2015 22:23, Martin Weber wrote: ... > There isn't as far as I know ... why do you need it though? To be honest: I don?t know. Just asking on behalf of > > Why not go with somewhere in the build directory? > It is already full of temporary build artifacts. Good idea! Thanks! Martin -- Cd wrttn wtht vwls s mch trsr. From bnewcomb at nvidia.com Fri Mar 13 19:50:12 2015 From: bnewcomb at nvidia.com (Bill Newcomb) Date: Fri, 13 Mar 2015 16:50:12 -0700 Subject: [CMake] ARGV processing in cmake -P Message-ID: <550377B4.7090108@nvidia.com> Any idea what I'm doing wrong here? $ cat foo.cmake foreach(n RANGE ${ARGC}) message(STATUS "${n} ${CMAKE_ARGV${n}}") endforeach() message(STATUS "${CMAKE_ARGV0}") message(STATUS "${CMAKE_ARGV1}") message(STATUS "${CMAKE_ARGV2}") $ cmake -P foo.cmake a b c -- 0 -- -- -- $ cmake a b c -P foo.cmake -- 0 -- -- -- Thanks, B. ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ----------------------------------------------------------------------------------- From mjklaim at gmail.com Fri Mar 13 21:24:16 2015 From: mjklaim at gmail.com (=?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?=) Date: Sat, 14 Mar 2015 02:24:16 +0100 Subject: [CMake] List all binaries associated with a target. Message-ID: I am looking for a (hopefully simple) way to do the following: 1. gather a list of paths of all the binaries associated with a target, that is all the linked dll/so and executable the target link or depend on. 2. copy these somewhere else. 3. take into account the build modes so that the right binaries are copied for each of the target build mode. I can't find a way to do 1 so far without manually specifying the dependencies. It looks like the generators expressions can't gather these info. So is there a way to retrieve this list in current CMake features? Did I miss something? Thanks for your time. -------------- next part -------------- An HTML attachment was scrubbed... URL: From foss at grueninger.de Sat Mar 14 08:19:21 2015 From: foss at grueninger.de (=?UTF-8?B?Q2hyaXN0b3BoIEdyw7xuaW5nZXI=?=) Date: Sat, 14 Mar 2015 13:19:21 +0100 Subject: [CMake] Check whether C++ headers are self-sufficient Message-ID: <55042749.7040106@grueninger.de> Dear CMakers, I want to have all my C++ headers self-sufficient (self-contained), i.e., a header can be included without additional includes. This is not only handy but also part of Google's C++ styleguide [2]. It would be great to have a make target (let's call it headercheck), that can check for this, by compiling a simple test.cc file for each current_header.h: #include #include "current_header.h" #include "current_header.h" Additionally it would be great to have such a target for every folder (checking all headers recursively) and every header that is explicitly passed as an argument. We tried this with CMake: We generate a test.cc file per header and create a library for every cc file. The problem is, that we get hundreds of additional targets, we generate a lot of folders and files which can increase our build directory size by an order of magnitude and it does not work properly on a per file or per directory basis. What do you think, is there a good way to have such a target headercheck with CMake? Or would it be better to include it as a CTest? Or better as an external (bash) script as proposed in [1]? If it can be done in a good way with CMake, would it be of interest to include it as a feature in CMake? Or as an external project similar to UseLATEX.cmake? Bye Christoph [1] http://stackoverflow.com/questions/1892043/self-sufficient-header-files-in-c-c [2] http://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Self_contained_Headers -- When you die, that does not mean that you lose to cancer, you beat cancer by how you live, why you live, and in the manner in which you live. -- Stuart Scott, 1965-2015 From Andreas-Naumann at gmx.net Sat Mar 14 09:55:01 2015 From: Andreas-Naumann at gmx.net (Andreas Naumann) Date: Sat, 14 Mar 2015 14:55:01 +0100 Subject: [CMake] Check whether C++ headers are self-sufficient In-Reply-To: <55042749.7040106@grueninger.de> References: <55042749.7040106@grueninger.de> Message-ID: <55043DB5.2030109@gmx.net> Why do you want to use one library per header? I think, it would be sufficient to have one cc-file per header and one library per folder. The library would simply contain all files. Why do you worry about large build directories? Regards, Andreas Am 14.03.2015 um 13:19 schrieb Christoph Gr?ninger: > Dear CMakers, > I want to have all my C++ headers self-sufficient (self-contained), > i.e., a header can be included without additional includes. This is not > only handy but also part of Google's C++ styleguide [2]. > > It would be great to have a make target (let's call it headercheck), > that can check for this, by compiling a simple test.cc file for each > current_header.h: > #include > #include "current_header.h" > #include "current_header.h" > > Additionally it would be great to have such a target for every folder > (checking all headers recursively) and every header that is explicitly > passed as an argument. > > We tried this with CMake: We generate a test.cc file per header and > create a library for every cc file. The problem is, that we get hundreds > of additional targets, we generate a lot of folders and files which can > increase our build directory size by an order of magnitude and it does > not work properly on a per file or per directory basis. > > What do you think, is there a good way to have such a target headercheck > with CMake? Or would it be better to include it as a CTest? Or better as > an external (bash) script as proposed in [1]? > > If it can be done in a good way with CMake, would it be of interest to > include it as a feature in CMake? Or as an external project similar to > UseLATEX.cmake? > > Bye > Christoph > > [1] > http://stackoverflow.com/questions/1892043/self-sufficient-header-files-in-c-c > [2] > http://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Self_contained_Headers > From robert.maynard at kitware.com Sat Mar 14 09:55:21 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Sat, 14 Mar 2015 09:55:21 -0400 Subject: [CMake] Check whether C++ headers are self-sufficient In-Reply-To: <55042749.7040106@grueninger.de> References: <55042749.7040106@grueninger.de> Message-ID: I have worked on projects where we do something fairly similar. The significant difference is that we create only a single executable per directory. All told is it a fairly simple and looks something like: # Builds a source file and an executable that does nothing other than # compile the given header files. function(add_header_test name) set(hfiles ${ARGN}) set(suffix ".cpp") set(cxxfiles) foreach (header ${ARGN}) string(REPLACE "${CMAKE_CURRENT_BINARY_DIR}" "" header "${header}") get_filename_component(headername ${header} NAME_WE) set(src ${CMAKE_CURRENT_BINARY_DIR}/TestBuild_${name}_${headername}${suffix}) configure_file(${SMTK_SOURCE_DIR}/CMake/TestBuild.cxx.in ${src} @ONLY) set(cxxfiles ${cxxfiles} ${src}) endforeach (header) add_library(TestBuild_${name} ${cxxfiles} ${hfiles}) target_include_directories(TestBuild_${name} ${CMAKE_CURRENT_BINARY_DIR}) set_source_files_properties(${hfiles} PROPERTIES HEADER_FILE_ONLY TRUE) endfunction(add_header_test) On Sat, Mar 14, 2015 at 8:19 AM, Christoph Gr?ninger wrote: > Dear CMakers, > I want to have all my C++ headers self-sufficient (self-contained), > i.e., a header can be included without additional includes. This is not > only handy but also part of Google's C++ styleguide [2]. > > It would be great to have a make target (let's call it headercheck), > that can check for this, by compiling a simple test.cc file for each > current_header.h: > #include > #include "current_header.h" > #include "current_header.h" > > Additionally it would be great to have such a target for every folder > (checking all headers recursively) and every header that is explicitly > passed as an argument. > > We tried this with CMake: We generate a test.cc file per header and > create a library for every cc file. The problem is, that we get hundreds > of additional targets, we generate a lot of folders and files which can > increase our build directory size by an order of magnitude and it does > not work properly on a per file or per directory basis. > > What do you think, is there a good way to have such a target headercheck > with CMake? Or would it be better to include it as a CTest? Or better as > an external (bash) script as proposed in [1]? > > If it can be done in a good way with CMake, would it be of interest to > include it as a feature in CMake? Or as an external project similar to > UseLATEX.cmake? > > Bye > Christoph > > [1] > > http://stackoverflow.com/questions/1892043/self-sufficient-header-files-in-c-c > [2] > > http://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Self_contained_Headers > > -- > When you die, that does not mean that you lose to cancer, > you beat cancer by how you live, why you live, and in the > manner in which you live. -- Stuart Scott, 1965-2015 > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 DLRdave at aol.com Sat Mar 14 13:54:52 2015 From: DLRdave at aol.com (David Cole) Date: Sat, 14 Mar 2015 13:54:52 -0400 Subject: [CMake] ARGV processing in cmake -P In-Reply-To: <550377B4.7090108@nvidia.com> References: <550377B4.7090108@nvidia.com> Message-ID: Works for me with CMake 3.2.1 on Windows. What version of CMake are you using? C:\dev\dcole> type args.cmake foreach(n RANGE ${ARGC}) message(STATUS "${n} ${CMAKE_ARGV${n}}") endforeach() message(STATUS "${CMAKE_ARGV0}") message(STATUS "${CMAKE_ARGV1}") message(STATUS "${CMAKE_ARGV2}") C:\dev\dcole> cmake -P args.cmake -- 0 cmake -- cmake -- -P -- args.cmake C:\dev\dcole> cmake --version cmake version 3.2.1 CMake suite maintained and supported by Kitware (kitware.com/cmake). On Fri, Mar 13, 2015 at 7:50 PM, Bill Newcomb wrote: > Any idea what I'm doing wrong here? > > $ cat foo.cmake > foreach(n RANGE ${ARGC}) > message(STATUS "${n} ${CMAKE_ARGV${n}}") > endforeach() > message(STATUS "${CMAKE_ARGV0}") > message(STATUS "${CMAKE_ARGV1}") > message(STATUS "${CMAKE_ARGV2}") > > $ cmake -P foo.cmake a b c > -- 0 > -- > -- > -- > $ cmake a b c -P foo.cmake > -- 0 > -- > -- > -- > > > Thanks, > B. > > ----------------------------------------------------------------------------------- > This email message is for the sole use of the intended recipient(s) and may > contain > confidential information. Any unauthorized review, use, disclosure or > distribution > is prohibited. If you are not the intended recipient, please contact the > sender by > reply email and destroy all copies of the original message. > ----------------------------------------------------------------------------------- > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 roolebo at gmail.com Sat Mar 14 16:51:15 2015 From: roolebo at gmail.com (Roman Bolshakov) Date: Sat, 14 Mar 2015 23:51:15 +0300 Subject: [CMake] List all binaries associated with a target. In-Reply-To: References: Message-ID: Here's an example function which addresses 1. It creates a string of generator expressions for direct and indirect dependencies of a target recursively. When all recursive invocations are done, it spits -deps file in the CURRENT_BINARY_DIR which contains full paths of the dependencies: function(store_dependencies LIB) if(NOT TARGET ${LIB}) message(FATAL_ERROR "You have to pass valid target") endif() # Do not add location for the top-most invocation if (ARGV1) set(ORIGINAL_LIB ${ARGV1}) set_property(TARGET ${ORIGINAL_LIB} APPEND_STRING PROPERTY DEPENDENCY_LIST "$ ") else() set(ORIGINAL_LIB ${LIB}) endif() # init dependency list with direct dependencies get_property(DEPENDENCIES TARGET ${LIB} PROPERTY LINK_LIBRARIES) # We're not intersted in interface link libraries of the top-most target if (ARGV1) get_property(INTERFACE_LINK_LIBRARIES TARGET ${LIB} PROPERTY INTERFACE_LINK_LIBRARIES) list(APPEND DEPENDENCIES ${INTERFACE_LINK_LIBRARIES}) endif() if (DEPENDENCIES) list(REMOVE_DUPLICATES DEPENDENCIES) # message (STATUS "${LIB} dependens on ${DEPENDENCIES}") endif() foreach(DEPENDENCY ${DEPENDENCIES}) store_dependencies(${DEPENDENCY} "${ORIGINAL_LIB}") endforeach() # Store list of gathered dependencies for the top-most call only if (NOT ARGV1) get_property(DEPENDENCY_LIST TARGET d PROPERTY DEPENDENCY_LIST) file(GENERATE OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/${LIB}-deps CONTENT "${DEPENDENCY_LIST}") endif() endfunction() I'm not sure how to achieve 2. during CMake configuration phase though as all generator expression are expanded later during build generation phase. But you might copy the files during build phase. You can create custom commands which use content of the generated file. I don't get what exactly you're trying to achieve in 3. In general I wouldn't encourage to copy binaries during build phase unless you have a very solid reason. FWIW there's install(TARGET) command for installation and packaging. Roman 2015-03-14 4:24 GMT+03:00 Klaim - Jo?l Lamotte : > I am looking for a (hopefully simple) way to do the following: > 1. gather a list of paths of all the binaries associated with a target, > that is all the linked dll/so and executable the target link or depend > on. > 2. copy these somewhere else. > 3. take into account the build modes so that the right binaries are copied > for > each of the target build mode. > > I can't find a way to do 1 so far without manually specifying the > dependencies. > It looks like the generators expressions can't gather these info. > So is there a way to retrieve this list in current CMake features? > Did I miss something? > > Thanks for your time. > > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 ryan.pavlik at gmail.com Sat Mar 14 21:03:21 2015 From: ryan.pavlik at gmail.com (Ryan Pavlik) Date: Sun, 15 Mar 2015 01:03:21 +0000 Subject: [CMake] Check whether C++ headers are self-sufficient In-Reply-To: References: <55042749.7040106@grueninger.de> Message-ID: I also have this implemented - in my case, the headers are fine to include in a .cpp with just a do-nothing main function and build into an executable, testing linking too. https://github.com/rpavlik/util-headers/blob/master/tests/cleanbuild/CMakeLists.txt Ryan On Sat, Mar 14, 2015 at 8:56 AM Robert Maynard wrote: > I have worked on projects where we do something fairly similar. The > significant difference is that we create only a single executable per > directory. All told is it a fairly simple and looks something like: > > # Builds a source file and an executable that does nothing other than > # compile the given header files. > function(add_header_test name) > set(hfiles ${ARGN}) > set(suffix ".cpp") > set(cxxfiles) > foreach (header ${ARGN}) > string(REPLACE "${CMAKE_CURRENT_BINARY_DIR}" "" header "${header}") > get_filename_component(headername ${header} NAME_WE) > set(src > ${CMAKE_CURRENT_BINARY_DIR}/TestBuild_${name}_${headername}${suffix}) > configure_file(${SMTK_SOURCE_DIR}/CMake/TestBuild.cxx.in ${src} @ONLY) > set(cxxfiles ${cxxfiles} ${src}) > endforeach (header) > > add_library(TestBuild_${name} ${cxxfiles} ${hfiles}) > target_include_directories(TestBuild_${name} ${CMAKE_CURRENT_BINARY_DIR}) > set_source_files_properties(${hfiles} PROPERTIES HEADER_FILE_ONLY TRUE) > endfunction(add_header_test) > > On Sat, Mar 14, 2015 at 8:19 AM, Christoph Gr?ninger > wrote: > >> Dear CMakers, >> I want to have all my C++ headers self-sufficient (self-contained), >> i.e., a header can be included without additional includes. This is not >> only handy but also part of Google's C++ styleguide [2]. >> >> It would be great to have a make target (let's call it headercheck), >> that can check for this, by compiling a simple test.cc file for each >> current_header.h: >> #include >> #include "current_header.h" >> #include "current_header.h" >> >> Additionally it would be great to have such a target for every folder >> (checking all headers recursively) and every header that is explicitly >> passed as an argument. >> >> We tried this with CMake: We generate a test.cc file per header and >> create a library for every cc file. The problem is, that we get hundreds >> of additional targets, we generate a lot of folders and files which can >> increase our build directory size by an order of magnitude and it does >> not work properly on a per file or per directory basis. >> >> What do you think, is there a good way to have such a target headercheck >> with CMake? Or would it be better to include it as a CTest? Or better as >> an external (bash) script as proposed in [1]? >> >> If it can be done in a good way with CMake, would it be of interest to >> include it as a feature in CMake? Or as an external project similar to >> UseLATEX.cmake? >> >> Bye >> Christoph >> >> [1] >> >> http://stackoverflow.com/questions/1892043/self-sufficient-header-files-in-c-c >> [2] >> >> http://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Self_contained_Headers >> >> -- >> When you die, that does not mean that you lose to cancer, >> you beat cancer by how you live, why you live, and in the >> manner in which you live. -- Stuart Scott, 1965-2015 >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware 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 mjklaim at gmail.com Sun Mar 15 10:43:04 2015 From: mjklaim at gmail.com (=?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?=) Date: Sun, 15 Mar 2015 15:43:04 +0100 Subject: [CMake] List all binaries associated with a target. In-Reply-To: References: Message-ID: On Sat, Mar 14, 2015 at 9:51 PM, Roman Bolshakov wrote: > Here's an example function which addresses 1. > It creates a string of generator expressions for direct and indirect > dependencies of a target recursively. > When all recursive invocations are done, it spits -deps > file in the CURRENT_BINARY_DIR which contains full paths of the > dependencies: > > function(store_dependencies LIB) > if(NOT TARGET ${LIB}) > message(FATAL_ERROR "You have to pass valid target") > endif() > # Do not add location for the top-most invocation > if (ARGV1) > set(ORIGINAL_LIB ${ARGV1}) > set_property(TARGET ${ORIGINAL_LIB} APPEND_STRING PROPERTY > DEPENDENCY_LIST "$ ") > else() > set(ORIGINAL_LIB ${LIB}) > endif() > > # init dependency list with direct dependencies > get_property(DEPENDENCIES TARGET ${LIB} PROPERTY LINK_LIBRARIES) > # We're not intersted in interface link libraries of the top-most target > if (ARGV1) > get_property(INTERFACE_LINK_LIBRARIES TARGET ${LIB} PROPERTY > INTERFACE_LINK_LIBRARIES) > list(APPEND DEPENDENCIES ${INTERFACE_LINK_LIBRARIES}) > endif() > > if (DEPENDENCIES) > list(REMOVE_DUPLICATES DEPENDENCIES) > # message (STATUS "${LIB} dependens on ${DEPENDENCIES}") > endif() > > foreach(DEPENDENCY ${DEPENDENCIES}) > store_dependencies(${DEPENDENCY} "${ORIGINAL_LIB}") > endforeach() > > # Store list of gathered dependencies for the top-most call only > if (NOT ARGV1) > get_property(DEPENDENCY_LIST TARGET d PROPERTY DEPENDENCY_LIST) > file(GENERATE OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/${LIB}-deps > CONTENT "${DEPENDENCY_LIST}") > endif() > endfunction() > > Very interesting, thank you very much. I will try that. > I'm not sure how to achieve 2. during CMake configuration phase though > as all generator expression are expanded later during build generation > phase. But you might copy the files during build phase. You can create > custom commands which use content of the generated file. > > Yes I was not clear but I was thinking about build time. I got this part covered. > I don't get what exactly you're trying to achieve in 3. In general I > wouldn't encourage to copy binaries during build phase unless you have > a very solid reason. FWIW there's install(TARGET) command for > installation and packaging. > > I'm not totally sure install() does exactly what I need. My use case is that I need to debug each executable in an installed-like context (with data), which imply that each time it is compiled it should be installed too. Actually 2 and 3 are the same, I just put the files in a specific place in the build directory so that it looks like installed, but I do this when the binary is built so that it's always up to date while debugging. Now, I use post-build command (add_custom_command) to do this indeed but I didn't find a way yet to trigger install() a specific binary on post-build yet, but I suppose I just missed it so far. > Roman > > 2015-03-14 4:24 GMT+03:00 Klaim - Jo?l Lamotte : > > I am looking for a (hopefully simple) way to do the following: > > 1. gather a list of paths of all the binaries associated with a target, > > that is all the linked dll/so and executable the target link or > depend > > on. > > 2. copy these somewhere else. > > 3. take into account the build modes so that the right binaries are > copied > > for > > each of the target build mode. > > > > I can't find a way to do 1 so far without manually specifying the > > dependencies. > > It looks like the generators expressions can't gather these info. > > So is there a way to retrieve this list in current CMake features? > > Did I miss something? > > > > Thanks for your time. > > > > > > > > -- > > > > Powered by www.kitware.com > > > > Please keep messages on-topic and check the CMake FAQ at: > > http://www.cmake.org/Wiki/CMake_FAQ > > > > Kitware offers various services to support the CMake community. For more > > information on each offering, please visit: > > > > CMake Support: http://cmake.org/cmake/help/support.html > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > > Visit other Kitware 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 scott.bloom at onshorecs.com Sun Mar 15 14:19:01 2015 From: scott.bloom at onshorecs.com (Scott Aron Bloom) Date: Sun, 15 Mar 2015 18:19:01 +0000 Subject: [CMake] Globally disable AUTO MOC Message-ID: <6FD2E165340D9A429CF831C7A2D4F42E62B94A51@WIN-R92V03RFJ85.onshorecs.local> I have found I can disable it project by project, but I cant seem to disable it, globally for every project.... Is there a way (or point in the cmake flow) to disable it globally? Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From roman.wueger at gmx.at Mon Mar 16 03:05:09 2015 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Mon, 16 Mar 2015 08:05:09 +0100 Subject: [CMake] Problems with WriteCompilerDetectionHeader and cxx_nullptr Message-ID: <79A8C11B-800E-46C2-B462-AA8156C79B41@gmx.at> Hi Brad, attached is an updated patch. Roman -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-WCDH-Fix-cxx_nullptr-for-compilers-which-doesn-t-sup 02.patch URL: -------------- next part -------------- From foss at grueninger.de Mon Mar 16 03:06:57 2015 From: foss at grueninger.de (=?windows-1252?Q?Christoph_Gr=FCninger?=) Date: Mon, 16 Mar 2015 08:06:57 +0100 Subject: [CMake] Check whether C++ headers are self-sufficient In-Reply-To: <55043DB5.2030109@gmx.net> References: <55042749.7040106@grueninger.de> <55043DB5.2030109@gmx.net> Message-ID: <55068111.4080905@grueninger.de> Hi Andreas, > Why do you want to use one library per header? I think, it would be > sufficient to have one cc-file per header and one library per folder. Then I can test also for single headers. > Why do you worry about large build directories? Because for slow file systems like Windows it takes several minutes just to create all the build folders and files. When we have teaching sessions the computer pool uses some remote file system (NFS?) which almost collapses if several participants configure our software at the same time. Bye Christoph -- When you die, that does not mean that you lose to cancer, you beat cancer by how you live, why you live, and in the manner in which you live. -- Stuart Scott, 1965-2015 From scott.bloom at onshorecs.com Mon Mar 16 04:42:18 2015 From: scott.bloom at onshorecs.com (Scott Aron Bloom) Date: Mon, 16 Mar 2015 08:42:18 +0000 Subject: [CMake] Check whether C++ headers are self-sufficient In-Reply-To: <55068111.4080905@grueninger.de> References: <55042749.7040106@grueninger.de> <55043DB5.2030109@gmx.net> <55068111.4080905@grueninger.de> Message-ID: <6FD2E165340D9A429CF831C7A2D4F42E62B9CFEF@WIN-R92V03RFJ85.onshorecs.local> Based on what was posted.. I was able to get this working without much difficulty. For all of my libraries, I use the technique borrowed from my qmake days, so all headers (and source) are stored as a variable ${project_H} and if it's a qt based header ${qtproject_H} So I added to every CMakeLists.txt for every library the following call add_header_test(libname ${project_H} ${qtproject_H}) Now the function add_header, was pretty much what was posted, except I made some minor tweaks. Howevr, I wanted to be able to make these tests into a CTest based system. Not just a "did it compile" but when I do a make test, it make sure all were compiled. Im not sure how the mailing list handles attachments, so I just cut and pasted it, if anyone wants a copy just email me directly. We do use google test, and the Mock files will not work (and shouldn't be tested in all honesty) and we have some internal .h files, hence the check to see if it should be tested. FUNCTION(add_header_test name) STRING(REPLACE "${CMAKE_SOURCE_DIR}" "" LCL_DIR ${CMAKE_CURRENT_LIST_DIR}) STRING(REPLACE "CoreApp" "CLI" LCL_DIR ${LCL_DIR}) SET(FOLDER_NAME "HeaderTests/${LCL_DIR}") SET(HEADERS ${ARGN}) SET(SUFFIX ".cxx") SET(CXXFILES) FOREACH(currHeader ${HEADERS}) STRING(REPLACE "${CMAKE_CURRENT_BINARY_DIR}" "" currHeader "${currHeader}") GET_FILENAME_COMPONENT(headerbase ${currHeader} NAME_WE) SET(headername ${currHeader} ) IF( NOT ${headername} MATCHES "_int.h" AND NOT ${headername} MATCHES "Mock" ) SET(src ${CMAKE_CURRENT_BINARY_DIR}/TestHeaders_${name}_${headerbase}${SUFFIX}) CONFIGURE_FILE(${CMAKE_SOURCE_DIR}/FileTemplates/TestHeaders.cpp.in ${src}) SET(cxxfiles ${cxxfiles} ${src}) ENDIF() ENDFOREACH() SET(main ${CMAKE_CURRENT_BINARY_DIR}/TestHeaders_${name}${SUFFIX}) CONFIGURE_FILE(${CMAKE_SOURCE_DIR}/FileTemplates/TestHeadersMain.cpp.in ${main}) SET(TEST_NAME TestHeaders_${name}) SET(CMAKE_AUTOMOC OFF) include_directories(${CMAKE_CURRENT_SOURCE_DIR}) ADD_EXECUTABLE(${TEST_NAME} ${main} ${cxxfiles} ${HEADERS}) ADD_TEST( ${TEST_NAME} ${TEST_NAME} ) SET_TARGET_PROPERTIES(${TEST_NAME} PROPERTIES FOLDER ${FOLDER_NAME}) SET_SOURCE_FILES_PROPERTIES(${HEADERS} PROPERTIES HEADER_FILE_ONLY TRUE) ADD_DEPENDENCIES(BUILD_HEADER_CHECKS ${TEST_NAME}) ADD_DEPENDENCIES(ALL_TEST ${TEST_NAME}) ENDFUNCTION(add_header_test) ADD_CUSTOM_TARGET( BUILD_HEADER_CHECKS ) SET_TARGET_PROPERTIES(BUILD_HEADER_CHECKS PROPERTIES FOLDER CMakePredefinedTargets) The TestHeaders.cpp.in // first one makes sure it is self sufficient #include "@headername@" // second include makes sure its guarded properly #include "@headername@" The TestHeadersMain.cpp.in int main( int /* argc */, char ** /*argcv*/ ) { return 0; } Scott -----Original Message----- From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Christoph Gr?ninger Sent: Monday, March 16, 2015 0:07 AM To: cmake at cmake.org Subject: Re: [CMake] Check whether C++ headers are self-sufficient Hi Andreas, > Why do you want to use one library per header? I think, it would be > sufficient to have one cc-file per header and one library per folder. Then I can test also for single headers. > Why do you worry about large build directories? Because for slow file systems like Windows it takes several minutes just to create all the build folders and files. When we have teaching sessions the computer pool uses some remote file system (NFS?) which almost collapses if several participants configure our software at the same time. Bye Christoph -- When you die, that does not mean that you lose to cancer, you beat cancer by how you live, why you live, and in the manner in which you live. -- Stuart Scott, 1965-2015 -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware 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 rsjtaylor.github at gmail.com Mon Mar 16 09:48:13 2015 From: rsjtaylor.github at gmail.com (Richard Taylor) Date: Mon, 16 Mar 2015 13:48:13 +0000 Subject: [CMake] Full paths for transitive dependencies Message-ID: Hello, I'm a CMake newbie trying to build a chain of libraries on windows, let's call them A, B and C A is a standalone shared library B is a shared library that depends on A in its headers & implementation C is a shared library that depends on B (and so implicitly depends on A) All three export themselves as cmake packages - config generation is essentially a copy & paste job from http://www.cmake.org/Wiki/CMake/Tutorials/How_to_create_a_ProjectConfig.cmake_file Each is built and installed in turn. B uses find_package(A) - The installed location of A's .cmake files is provided during configuration by setting the A_DIR var. C is built similarly via find_package(B) and providing the location of the installed .cmake files for B. B builds fine and finds & links to it's dependency A using the full installed path of A. C finds B, and knows it is dependent on A, but the linker is only passed the name of A rather than the full path. No additional library paths get added to the generated project, so the build fails at link time. Is it normal behaviour that you need to manually specify the location of all public transitive dependencies somehow, or am I doing something wrong when exporting targets? I figured that as B was installed using a known location of A, C should be able to find A from B's installed configs. Looking at the installed Targets-.cmake from B, it's own location is specified as a full path (set via IMPORTED_LOCATION_) However, only the names of dependent targets are set (via INTERFACE_LINK_LIBRARIES in Targets.cmake) I guess that's where the problem lies, I'm just not sure how to fix it.. Rich -------------- next part -------------- An HTML attachment was scrubbed... URL: From bnewcomb at nvidia.com Mon Mar 16 12:44:00 2015 From: bnewcomb at nvidia.com (Bill Newcomb) Date: Mon, 16 Mar 2015 09:44:00 -0700 Subject: [CMake] ARGV processing in cmake -P In-Reply-To: References: <550377B4.7090108@nvidia.com> Message-ID: <55070850.3040802@nvidia.com> Oh, shoot, it turns out I was using our ancient 2.6.4 install by accident. It works fine for me in cmake 3.1.3. Sorry for the noise, B. On 03/14/2015 10:54 AM, David Cole wrote: > Works for me with CMake 3.2.1 on Windows. What version of CMake are you using? > > C:\dev\dcole> type args.cmake > foreach(n RANGE ${ARGC}) > message(STATUS "${n} ${CMAKE_ARGV${n}}") > endforeach() > message(STATUS "${CMAKE_ARGV0}") > message(STATUS "${CMAKE_ARGV1}") > message(STATUS "${CMAKE_ARGV2}") > > > C:\dev\dcole> cmake -P args.cmake > -- 0 cmake > -- cmake > -- -P > -- args.cmake > > > C:\dev\dcole> cmake --version > cmake version 3.2.1 > > CMake suite maintained and supported by Kitware (kitware.com/cmake). > > > > On Fri, Mar 13, 2015 at 7:50 PM, Bill Newcomb wrote: >> Any idea what I'm doing wrong here? >> >> $ cat foo.cmake >> foreach(n RANGE ${ARGC}) >> message(STATUS "${n} ${CMAKE_ARGV${n}}") >> endforeach() >> message(STATUS "${CMAKE_ARGV0}") >> message(STATUS "${CMAKE_ARGV1}") >> message(STATUS "${CMAKE_ARGV2}") >> >> $ cmake -P foo.cmake a b c >> -- 0 >> -- >> -- >> -- >> $ cmake a b c -P foo.cmake >> -- 0 >> -- >> -- >> -- >> >> >> Thanks, >> B. >> >> ----------------------------------------------------------------------------------- >> This email message is for the sole use of the intended recipient(s) and may >> contain >> confidential information. Any unauthorized review, use, disclosure or >> distribution >> is prohibited. If you are not the intended recipient, please contact the >> sender by >> reply email and destroy all copies of the original message. >> ----------------------------------------------------------------------------------- >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware 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 roolebo at gmail.com Mon Mar 16 14:11:32 2015 From: roolebo at gmail.com (Roman Bolshakov) Date: Mon, 16 Mar 2015 21:11:32 +0300 Subject: [CMake] List all binaries associated with a target. In-Reply-To: References: Message-ID: > I'm not totally sure install() does exactly what I need. > My use case is that I need to debug each executable in an installed-like > context (with data), which imply that each time it is compiled it should be installed too. > Actually 2 and 3 are the same, I just put the files in a specific place in the > build directory so that it looks like installed, but I do this when the binary is > built so that it's always up to date while debugging. > Now, I use post-build command (add_custom_command) to do this indeed > but I didn't find a way yet to trigger install() a specific binary on post-build yet, > but I suppose I just missed it so far. If one source tree has a few separate binaries, I'd just use install(TARGET) with COMPONENT specified. Even if you have a library which is shared between the set of separate components you can specify its installation for a few components using foreach loop: foreach(COMP A B C) install( TARGET common-lib DESTINATION lib COMPONENT ${COMP} ) endforeach() Then you can invoke top-level cmake_install.cmake to install a subset of your project: DESTDIR=/destination/install/path cmake -DCOMPONENT=A -P cmake_install.cmake Also note, that if your project is shipped as one bundle on a platform which supports RPATH you don't need to do any actions as you can run any executable in build tree without any additional actions using add_test command. ctest can drive test execution in the build tree. From steveire at gmail.com Mon Mar 16 14:36:41 2015 From: steveire at gmail.com (Stephen Kelly) Date: Mon, 16 Mar 2015 19:36:41 +0100 Subject: [CMake] List all binaries associated with a target. References: Message-ID: Klaim - Jo?l Lamotte wrote: > Actually 2 and 3 are the same, I just put the files in a specific place in > the > build directory so that it looks like installed, but I do this when the > binary is > built so that it's always up to date while debugging. > Now, I use post-build command (add_custom_command) to do this indeed > but I didn't find a way yet to trigger install() a specific binary on > post-build yet, > but I suppose I just missed it so far. There might be space for a first class feature in cmake for 'make something that looks like the install tree at build time'. Please file an issue to track it. Thanks, Steve. From steveire at gmail.com Mon Mar 16 14:48:12 2015 From: steveire at gmail.com (Stephen Kelly) Date: Mon, 16 Mar 2015 19:48:12 +0100 Subject: [CMake] List all binaries associated with a target. References: Message-ID: Klaim - Jo?l Lamotte wrote: > I am looking for a (hopefully simple) way to do the following: > 1. gather a list of paths of all the binaries associated with a target, > that is all the linked dll/so and executable the target link or depend > on. Apparently I starting thinking about a genex to do that a year ago, but I didn't complete it. I just filed http://public.kitware.com/Bug/view.php?id=15449 Feel free to pick it up if you wish. Thanks, Steve. From steveire at gmail.com Mon Mar 16 14:50:51 2015 From: steveire at gmail.com (Stephen Kelly) Date: Mon, 16 Mar 2015 19:50:51 +0100 Subject: [CMake] Full paths for transitive dependencies References: Message-ID: Richard Taylor wrote: > http://www.cmake.org/Wiki/CMake/Tutorials/How_to_create_a_ProjectConfig.cmake_file > Prefer the official documentation instead of the wiki wherever official documentation exists (especially if it is well-formatted; that means it's probably recent and maintained). http://www.cmake.org/cmake/help/v3.0/manual/cmake-packages.7.html > However, only the names of dependent targets are set (via > INTERFACE_LINK_LIBRARIES in Targets.cmake) > > I guess that's where the problem lies, I'm just not sure how to fix it.. The above link documents a find_dependency macro, which you might make use of. Thanks, Steve. From steveire at gmail.com Mon Mar 16 14:52:45 2015 From: steveire at gmail.com (Stephen Kelly) Date: Mon, 16 Mar 2015 19:52:45 +0100 Subject: [CMake] Globally disable AUTO MOC References: <6FD2E165340D9A429CF831C7A2D4F42E62B94A51@WIN-R92V03RFJ85.onshorecs.local> Message-ID: Scott Aron Bloom wrote: > I have found I can disable it project by project, but I cant seem to > disable it, globally for every project.... > > Is there a way (or point in the cmake flow) to disable it globally? It is disabled by default. It is defaulted to on for targets following the setting of the CMAKE_AUTOMOC variable to ON (or another truthy value). Maybe you have that in your code. Thanks, Steve. From rmcarlsson at gmail.com Mon Mar 16 15:32:42 2015 From: rmcarlsson at gmail.com (rmcarlsson) Date: Mon, 16 Mar 2015 12:32:42 -0700 (MST) Subject: [CMake] cmake cross compile raspberry pi - cannot find target library Message-ID: <1426534362592-7590041.post@n2.nabble.com> I am working on Raspberry pi B+. I am using the normal Raspbian, Debian Wheezy. I have installed owcapi lib on the Raspberry pi (sudo apt-get install libow-dev). I have read the rootfs bnack to the host machine, Ubuntu 14.04 LTS using rsync. These files are stored under /opt/pi/rootfs. Now my problem is that when a try to cross compile on my host machine for raspberry pi I get a link error stating that a libary, owcapi, can not be found. This library is located on the raspberry pi and in the /opt/pi/rootfs: The link error have the following signature: It is clear that gcc is not provided with any -L flag with valid path (preferably to /opt/pi/rootfs/usr/lib/arm-linux-gnueabihf ). I have read http://www.cmake.org/Wiki/CMake_Cross_Compiling, but I can find the root cause of my problem. Anyone know how to solve this? Please find my CMakeLists.txt and toolchain file included Tooolchain file: Any help is appreciated / Mikael -- View this message in context: http://cmake.3232098.n2.nabble.com/cmake-cross-compile-raspberry-pi-cannot-find-target-library-tp7590041.html Sent from the CMake mailing list archive at Nabble.com. From mjklaim at gmail.com Mon Mar 16 16:22:25 2015 From: mjklaim at gmail.com (=?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?=) Date: Mon, 16 Mar 2015 21:22:25 +0100 Subject: [CMake] List all binaries associated with a target. In-Reply-To: References: Message-ID: On Mon, Mar 16, 2015 at 7:11 PM, Roman Bolshakov wrote: > > I'm not totally sure install() does exactly what I need. > > My use case is that I need to debug each executable in an installed-like > > context (with data), which imply that each time it is compiled it should > be installed too. > > Actually 2 and 3 are the same, I just put the files in a specific place > in the > > build directory so that it looks like installed, but I do this when the > binary is > > built so that it's always up to date while debugging. > > Now, I use post-build command (add_custom_command) to do this indeed > > but I didn't find a way yet to trigger install() a specific binary on > post-build yet, > > but I suppose I just missed it so far. > > > If one source tree has a few separate binaries, I'd just use > install(TARGET) with COMPONENT specified. Even if you have a library > which is shared between the set of separate components you can specify > its installation for a few components using foreach loop: > foreach(COMP A B C) > install( > TARGET common-lib > DESTINATION lib > COMPONENT ${COMP} > ) > endforeach() > Then you can invoke top-level cmake_install.cmake to install a subset > of your project: > DESTDIR=/destination/install/path cmake -DCOMPONENT=A -P > cmake_install.cmake > > It is not clear to me how all this would help installing automatically a library and it's dependencies when I modify then build the library. If my understanding is correct, all this need to be triggered by cmake install command, right? Also, the main issue is gathering binaries so that they can be debugged on windows (as you point later) without having to move files around, in particular dependencies binaries that can and will change through developement. > Also note, that if your project is shipped as one bundle on a platform > which supports RPATH you don't need to do any actions as you can run > any executable in build tree without any additional actions using > add_test command. ctest can drive test execution in the build tree. > My debug setup issue is apparently only on Windows with VS indeed. Someone explained to be about the RPATH and indeed it should prevent the need for moving files around. So far I've been happy with a python script finding all dependencies for each library in my install directory but I want to do it through cmake and I would like to avoid having to specify where are the dependencies binaries exactly, because depending on if you install them in the system or build them from scratch, I don't always know where to find them. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mjklaim at gmail.com Mon Mar 16 16:29:12 2015 From: mjklaim at gmail.com (=?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?=) Date: Mon, 16 Mar 2015 21:29:12 +0100 Subject: [CMake] List all binaries associated with a target. In-Reply-To: References: Message-ID: On Mon, Mar 16, 2015 at 7:36 PM, Stephen Kelly wrote: > There might be space for a first class feature in cmake for 'make something > that looks like the install tree at build time'. Please file an issue to > track it. > > Thanks, > Done: http://public.kitware.com/Bug/view.php?id=15450 So there is no simple way to do this currently? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mjklaim at gmail.com Mon Mar 16 16:34:34 2015 From: mjklaim at gmail.com (=?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?=) Date: Mon, 16 Mar 2015 21:34:34 +0100 Subject: [CMake] List all binaries associated with a target. In-Reply-To: References: Message-ID: On Mon, Mar 16, 2015 at 7:48 PM, Stephen Kelly wrote: > Klaim - Jo?l Lamotte wrote: > > > I am looking for a (hopefully simple) way to do the following: > > 1. gather a list of paths of all the binaries associated with a target, > > that is all the linked dll/so and executable the target link or > depend > > on. > > Apparently I starting thinking about a genex to do that a year ago, but I > didn't complete it. I just filed > > http://public.kitware.com/Bug/view.php?id=15449 > > Feel free to pick it up if you wish. > > Interesting, but I do not see a property for actual binaries paths? I'm not familiar with CMake's code so maybe it's available and I don't know about it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mjklaim at gmail.com Mon Mar 16 16:50:00 2015 From: mjklaim at gmail.com (=?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?=) Date: Mon, 16 Mar 2015 21:50:00 +0100 Subject: [CMake] List all binaries associated with a target. In-Reply-To: References: Message-ID: On Sat, Mar 14, 2015 at 9:51 PM, Roman Bolshakov wrote: > Here's an example function which addresses 1. > It creates a string of generator expressions for direct and indirect > dependencies of a target recursively. > When all recursive invocations are done, it spits -deps > file in the CURRENT_BINARY_DIR which contains full paths of the > dependencies: > Unfortunately, if my understanding is correct, this code cannot work with external dependencies as they are not targets. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cristeab at gmail.com Mon Mar 16 19:25:18 2015 From: cristeab at gmail.com (Bogdan Cristea) Date: Tue, 17 Mar 2015 00:25:18 +0100 Subject: [CMake] DEB package generated with cpack does not pass lintian check on Ubuntu Message-ID: <0AD16B49-65A2-4172-81DB-DCC80FF3E1C1@gmail.com> Hi I have generated a DEB package with cpack, but the analysis with lintian in Ubuntu reveals still some errors: E: at: changelog-file-missing-in-native-package E: at: control-file-has-bad-owner md5sums b/users != root/root E: at: no-copyright-file E: at: extended-description-is-empty E: at: maintainer-name-missing a at gmail.com Use of uninitialized value $name in pattern match (m//) at /usr/share/perl5/Lintian/Check.pm line 203. E: at: wrong-file-owner-uid-or-gid usr/ 1000/100 E: at: wrong-file-owner-uid-or-gid usr/bin/ 1000/100 E: at: wrong-file-owner-uid-or-gid usr/bin/AT 1000/100 W: at: binary-without-manpage usr/bin/AT Could someone tell me how can I solve these ? thanks Bogdan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Dave at Yost.com Tue Mar 17 00:10:14 2015 From: Dave at Yost.com (Dave Yost) Date: Mon, 16 Mar 2015 21:10:14 -0700 Subject: [CMake] nonstandard C++ source filename extension Message-ID: From what I can glean online, I?ve tried this: set_source_files_properties(foo.bar PROPERTIES LANGUAGE CXX) add_executable(foo foo.bar) set_target_properties(foo PROPERTIES LINKER_LANGUAGE CXX) but it doesn?t work. What am I missing? 0 Mon 20:16:15 yost 1181 Z% cat CMakeLists.txt cmake_minimum_required(VERSION 3.0 FATAL_ERROR) project(asm CXX) set_source_files_properties(foo.bar PROPERTIES LANGUAGE CXX) add_executable(foo foo.bar) set_target_properties(foo PROPERTIES LINKER_LANGUAGE CXX) 0 Mon 20:16:43 yost 1182 Z% cat foo.bar #include int main(int argc, char* argv[]) { std::cout << "Hello\"\n"; return 0; } 0 Mon 20:16:46 yost 1183 Z% cd build ; cmake .. -- The CXX compiler identification is GNU 4.9.2 -- Checking whether CXX compiler has -isysroot -- Checking whether CXX compiler has -isysroot - yes -- Checking whether CXX compiler supports OSX deployment target flag -- Checking whether CXX compiler supports OSX deployment target flag - yes -- Check for working CXX compiler: /opt/local/bin/c++ -- Check for working CXX compiler: /opt/local/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Configuring done -- Generating done -- Build files have been written to: /Users/yost/p/c++/cmake/asm/build 0 Mon 20:16:58 yost 1184 Z% make Scanning dependencies of target foo [100%] Building CXX object CMakeFiles/foo.dir/foo.bar.o c++: warning: /Users/yost/p/c++/cmake/asm/foo.bar: linker input file unused because linking not done Linking CXX executable foo c++: error: CMakeFiles/foo.dir/foo.bar.o: No such file or directory CMakeFiles/foo.dir/build.make:85: recipe for target 'foo' failed make[2]: *** [foo] Error 1 CMakeFiles/Makefile2:60: recipe for target 'CMakeFiles/foo.dir/all' failed make[1]: *** [CMakeFiles/foo.dir/all] Error 2 Makefile:75: recipe for target 'all' failed make: *** [all] Error 2 2 Mon 20:17:01 yost 1185 Z% rm -rf * ; cmake .. zsh: sure you want to delete all the files in /Users/yost/p/c++/cmake/asm/build [yn]? y -- The CXX compiler identification is GNU 4.9.2 -- Checking whether CXX compiler has -isysroot -- Checking whether CXX compiler has -isysroot - yes -- Checking whether CXX compiler supports OSX deployment target flag -- Checking whether CXX compiler supports OSX deployment target flag - yes -- Check for working CXX compiler: /opt/local/bin/c++ -- Check for working CXX compiler: /opt/local/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Configuring done -- Generating done -- Build files have been written to: /Users/yost/p/c++/cmake/asm/build 0 Mon 20:23:00 yost 1201 Z% make VERBOSE=1 /Applications/CMake.app/Contents/bin/cmake -H/Users/yost/p/c++/cmake/asm -B/Users/yost/p/c++/cmake/asm/build --check-build-system CMakeFiles/Makefile.cmake 0 /Applications/CMake.app/Contents/bin/cmake -E cmake_progress_start /Users/yost/p/c++/cmake/asm/build/CMakeFiles /Users/yost/p/c++/cmake/asm/build/CMakeFiles/progress.marks make -f CMakeFiles/Makefile2 all make[1]: Entering directory '/Users/yost/p/c++/cmake/asm/build' make -f CMakeFiles/foo.dir/build.make CMakeFiles/foo.dir/depend make[2]: Entering directory '/Users/yost/p/c++/cmake/asm/build' cd /Users/yost/p/c++/cmake/asm/build && /Applications/CMake.app/Contents/bin/cmake -E cmake_depends "Unix Makefiles" /Users/yost/p/c++/cmake/asm /Users/yost/p/c++/cmake/asm /Users/yost/p/c++/cmake/asm/build /Users/yost/p/c++/cmake/asm/build /Users/yost/p/c++/cmake/asm/build/CMakeFiles/foo.dir/DependInfo.cmake --color= Dependee "/Users/yost/p/c++/cmake/asm/build/CMakeFiles/foo.dir/DependInfo.cmake" is newer than depender "/Users/yost/p/c++/cmake/asm/build/CMakeFiles/foo.dir/depend.internal". Dependee "/Users/yost/p/c++/cmake/asm/build/CMakeFiles/CMakeDirectoryInformation.cmake" is newer than depender "/Users/yost/p/c++/cmake/asm/build/CMakeFiles/foo.dir/depend.internal". Scanning dependencies of target foo make[2]: Leaving directory '/Users/yost/p/c++/cmake/asm/build' make -f CMakeFiles/foo.dir/build.make CMakeFiles/foo.dir/build make[2]: Entering directory '/Users/yost/p/c++/cmake/asm/build' /Applications/CMake.app/Contents/bin/cmake -E cmake_progress_report /Users/yost/p/c++/cmake/asm/build/CMakeFiles 1 [100%] Building CXX object CMakeFiles/foo.dir/foo.bar.o /opt/local/bin/c++ -o CMakeFiles/foo.dir/foo.bar.o -c /Users/yost/p/c++/cmake/asm/foo.bar c++: warning: /Users/yost/p/c++/cmake/asm/foo.bar: linker input file unused because linking not done Linking CXX executable foo /Applications/CMake.app/Contents/bin/cmake -E cmake_link_script CMakeFiles/foo.dir/link.txt --verbose=1 /opt/local/bin/c++ -Wl,-search_paths_first -Wl,-headerpad_max_install_names CMakeFiles/foo.dir/foo.bar.o -o foo c++: error: CMakeFiles/foo.dir/foo.bar.o: No such file or directory CMakeFiles/foo.dir/build.make:85: recipe for target 'foo' failed make[2]: *** [foo] Error 1 make[2]: Leaving directory '/Users/yost/p/c++/cmake/asm/build' CMakeFiles/Makefile2:60: recipe for target 'CMakeFiles/foo.dir/all' failed make[1]: *** [CMakeFiles/foo.dir/all] Error 2 make[1]: Leaving directory '/Users/yost/p/c++/cmake/asm/build' Makefile:75: recipe for target 'all' failed make: *** [all] Error 2 2 Mon 20:23:04 yost 1202 Z% (I added the light blue and orange coloring by hand for readability.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From Dave at Yost.com Tue Mar 17 00:11:32 2015 From: Dave at Yost.com (Dave Yost) Date: Mon, 16 Mar 2015 21:11:32 -0700 Subject: [CMake] Examples in the documentation! Message-ID: <730731A4-F965-469F-A2FE-C54793D5CD53@yost.com> IMHO the cmake documentation is about 5x too terse. I wish for lots and lots of short examples and user-texted descriptive text. From post at hendrik-sattler.de Tue Mar 17 02:11:59 2015 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Tue, 17 Mar 2015 07:11:59 +0100 Subject: [CMake] DEB package generated with cpack does not pass lintian check on Ubuntu In-Reply-To: <0AD16B49-65A2-4172-81DB-DCC80FF3E1C1@gmail.com> References: <0AD16B49-65A2-4172-81DB-DCC80FF3E1C1@gmail.com> Message-ID: <8055FA01-E383-4AE8-B3C3-7CDF6025009A@hendrik-sattler.de> Hi, you have to differ here: lintian is for checking packaging policy of distribution packages for Debian and derivatives like Ubuntu. Cpack does not necessarily create packages according to these policies but still valid packages. If dpkg eats it without errors, it's ok for out-of-distribution packages. HS Am 17. M?rz 2015 00:25:18 MEZ, schrieb Bogdan Cristea : >Hi > >I have generated a DEB package with cpack, but the analysis with >lintian in Ubuntu reveals still some errors: > >E: at: changelog-file-missing-in-native-package >E: at: control-file-has-bad-owner md5sums b/users != root/root >E: at: no-copyright-file >E: at: extended-description-is-empty >E: at: maintainer-name-missing a at gmail.com >Use of uninitialized value $name in pattern match (m//) at >/usr/share/perl5/Lintian/Check.pm line 203. >E: at: wrong-file-owner-uid-or-gid usr/ 1000/100 >E: at: wrong-file-owner-uid-or-gid usr/bin/ 1000/100 >E: at: wrong-file-owner-uid-or-gid usr/bin/AT 1000/100 >W: at: binary-without-manpage usr/bin/AT > >Could someone tell me how can I solve these ? > >thanks >Bogdan > > > >------------------------------------------------------------------------ > >-- > >Powered by www.kitware.com > >Please keep messages on-topic and check the CMake FAQ at: >http://www.cmake.org/Wiki/CMake_FAQ > >Kitware offers various services to support the CMake community. For >more information on each offering, please visit: > >CMake Support: http://cmake.org/cmake/help/support.html >CMake Consulting: http://cmake.org/cmake/help/consulting.html >CMake Training Courses: http://cmake.org/cmake/help/training.html > >Visit other Kitware open-source projects at >http://www.kitware.com/opensource/opensource.html > >Follow this link to subscribe/unsubscribe: >http://public.kitware.com/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From petr.kmoch at gmail.com Tue Mar 17 04:28:23 2015 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Tue, 17 Mar 2015 09:28:23 +0100 Subject: [CMake] nonstandard C++ source filename extension In-Reply-To: References: Message-ID: Hi Dave. This looks like a message directly from your compiler. Does it work if you try to compile the file manually (no CMake)? Petr On Tue, Mar 17, 2015 at 5:10 AM, Dave Yost wrote: > From what I can glean online, I?ve tried this: > > set_source_files_properties(foo.bar PROPERTIES LANGUAGE CXX) > add_executable(foo foo.bar) > set_target_properties(foo PROPERTIES LINKER_LANGUAGE CXX) > > > but it doesn?t work. > What am I missing? > > 0 Mon 20:16:15 yost > 1181 Z% cat CMakeLists.txt > cmake_minimum_required(VERSION 3.0 FATAL_ERROR) > project(asm CXX) > > set_source_files_properties(foo.bar PROPERTIES LANGUAGE CXX) > add_executable(foo foo.bar) > set_target_properties(foo PROPERTIES LINKER_LANGUAGE CXX) > 0 Mon 20:16:43 yost > 1182 Z% cat foo.bar > #include > > int main(int argc, char* argv[]) { > std::cout << "Hello\"\n"; > return 0; > } > 0 Mon 20:16:46 yost > 1183 Z% cd build ; cmake .. > -- The CXX compiler identification is GNU 4.9.2 > -- Checking whether CXX compiler has -isysroot > -- Checking whether CXX compiler has -isysroot - yes > -- Checking whether CXX compiler supports OSX deployment target flag > -- Checking whether CXX compiler supports OSX deployment target flag - yes > -- Check for working CXX compiler: /opt/local/bin/c++ > -- Check for working CXX compiler: /opt/local/bin/c++ -- works > -- Detecting CXX compiler ABI info > -- Detecting CXX compiler ABI info - done > -- Detecting CXX compile features > -- Detecting CXX compile features - done > -- Configuring done > -- Generating done > -- Build files have been written to: /Users/yost/p/c++/cmake/asm/build > 0 Mon 20:16:58 yost > 1184 Z% make > Scanning dependencies of target foo > [100%] Building CXX object CMakeFiles/foo.dir/foo.bar.o > c++: warning: /Users/yost/p/c++/cmake/asm/foo.bar: linker input file > unused because linking not done > Linking CXX executable foo > c++: error: CMakeFiles/foo.dir/foo.bar.o: No such file or directory > CMakeFiles/foo.dir/build.make:85: recipe for target 'foo' failed > make[2]: *** [foo] Error 1 > CMakeFiles/Makefile2:60: recipe for target 'CMakeFiles/foo.dir/all' failed > make[1]: *** [CMakeFiles/foo.dir/all] Error 2 > Makefile:75: recipe for target 'all' failed > make: *** [all] Error 2 > 2 Mon 20:17:01 yost > 1185 Z% rm -rf * ; cmake .. > zsh: sure you want to delete all the files in > /Users/yost/p/c++/cmake/asm/build [yn]? y > -- The CXX compiler identification is GNU 4.9.2 > -- Checking whether CXX compiler has -isysroot > -- Checking whether CXX compiler has -isysroot - yes > -- Checking whether CXX compiler supports OSX deployment target flag > -- Checking whether CXX compiler supports OSX deployment target flag - yes > -- Check for working CXX compiler: /opt/local/bin/c++ > -- Check for working CXX compiler: /opt/local/bin/c++ -- works > -- Detecting CXX compiler ABI info > -- Detecting CXX compiler ABI info - done > -- Detecting CXX compile features > -- Detecting CXX compile features - done > -- Configuring done > -- Generating done > -- Build files have been written to: /Users/yost/p/c++/cmake/asm/build > 0 Mon 20:23:00 yost > 1201 Z% make VERBOSE=1 > /Applications/CMake.app/Contents/bin/cmake -H/Users/yost/p/c++/cmake/asm > -B/Users/yost/p/c++/cmake/asm/build --check-build-system > CMakeFiles/Makefile.cmake 0 > /Applications/CMake.app/Contents/bin/cmake -E cmake_progress_start > /Users/yost/p/c++/cmake/asm/build/CMakeFiles > /Users/yost/p/c++/cmake/asm/build/CMakeFiles/progress.marks > make -f CMakeFiles/Makefile2 all > make[1]: Entering directory '/Users/yost/p/c++/cmake/asm/build' > make -f CMakeFiles/foo.dir/build.make CMakeFiles/foo.dir/depend > make[2]: Entering directory '/Users/yost/p/c++/cmake/asm/build' > cd /Users/yost/p/c++/cmake/asm/build && > /Applications/CMake.app/Contents/bin/cmake -E cmake_depends "Unix > Makefiles" /Users/yost/p/c++/cmake/asm /Users/yost/p/c++/cmake/asm > /Users/yost/p/c++/cmake/asm/build /Users/yost/p/c++/cmake/asm/build > /Users/yost/p/c++/cmake/asm/build/CMakeFiles/foo.dir/DependInfo.cmake > --color= > Dependee > "/Users/yost/p/c++/cmake/asm/build/CMakeFiles/foo.dir/DependInfo.cmake" is > newer than depender > "/Users/yost/p/c++/cmake/asm/build/CMakeFiles/foo.dir/depend.internal". > Dependee > "/Users/yost/p/c++/cmake/asm/build/CMakeFiles/CMakeDirectoryInformation.cmake" > is newer than depender > "/Users/yost/p/c++/cmake/asm/build/CMakeFiles/foo.dir/depend.internal". > Scanning dependencies of target foo > make[2]: Leaving directory '/Users/yost/p/c++/cmake/asm/build' > make -f CMakeFiles/foo.dir/build.make CMakeFiles/foo.dir/build > make[2]: Entering directory '/Users/yost/p/c++/cmake/asm/build' > /Applications/CMake.app/Contents/bin/cmake -E cmake_progress_report > /Users/yost/p/c++/cmake/asm/build/CMakeFiles 1 > [100%] Building CXX object CMakeFiles/foo.dir/foo.bar.o > /opt/local/bin/c++ -o CMakeFiles/foo.dir/foo.bar.o -c > /Users/yost/p/c++/cmake/asm/foo.bar > c++: warning: /Users/yost/p/c++/cmake/asm/foo.bar: linker input file > unused because linking not done > Linking CXX executable foo > /Applications/CMake.app/Contents/bin/cmake -E cmake_link_script > CMakeFiles/foo.dir/link.txt --verbose=1 > /opt/local/bin/c++ -Wl,-search_paths_first > -Wl,-headerpad_max_install_names CMakeFiles/foo.dir/foo.bar.o -o foo > c++: error: CMakeFiles/foo.dir/foo.bar.o: No such file or directory > CMakeFiles/foo.dir/build.make:85: recipe for target 'foo' failed > make[2]: *** [foo] Error 1 > make[2]: Leaving directory '/Users/yost/p/c++/cmake/asm/build' > CMakeFiles/Makefile2:60: recipe for target 'CMakeFiles/foo.dir/all' failed > make[1]: *** [CMakeFiles/foo.dir/all] Error 2 > make[1]: Leaving directory '/Users/yost/p/c++/cmake/asm/build' > Makefile:75: recipe for target 'all' failed > make: *** [all] Error 2 > 2 Mon 20:23:04 yost > 1202 Z% > > (I added the light blue and orange coloring by hand for readability.) > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 adam707blue at gmail.com Tue Mar 17 07:38:37 2015 From: adam707blue at gmail.com (Adam) Date: Tue, 17 Mar 2015 21:38:37 +1000 Subject: [CMake] Full paths for transitive dependencies In-Reply-To: References: Message-ID: I happened to stumble acrosss this today. I fixed it by adding another find_package to the last project but this seems to defeat the purpose of transitive dependencies. What am I doing wrong? Here's a more detailed example (https://github.com/toomuchatonce/cmake_transient_issue.git) ------------------------------- app - CMakeLists.txt cmake_minimum_required(VERSION 3.0.2) add_executable(app main.cpp) # uncomment to fix link error #find_package( a NO_MODULE REQUIRED ) find_package( b NO_MODULE REQUIRED ) target_link_libraries(app b) install(TARGETS app RUNTIME DESTINATION bin) ------------------------------- libb - CMakeLists.txt cmake_minimum_required (VERSION 3.0.2) project(b) find_package(a NO_MODULE REQUIRED ) add_library(b lib.cpp) target_link_libraries(b a) target_include_directories(b PUBLIC "$") install(TARGETS b EXPORT bConfig ARCHIVE DESTINATION lib/b ) install(FILES b.h DESTINATION include/b) install(EXPORT bConfig DESTINATION lib/cmake/b ) -------------------------------------- liba - CMakeLists.txt cmake_minimum_required (VERSION 3.0.2) project(a) add_library(a lib.cpp) target_include_directories(a INTERFACE "$") install(TARGETS a EXPORT aConfig ARCHIVE DESTINATION lib/a ) install(FILES a.h DESTINATION include/a) install(EXPORT aConfig DESTINATION lib/cmake/a ) -------------------------------------- superbuild - CMakeLists.txt cmake_minimum_required( VERSION 3.0.2 ) include(ExternalProject) set(DEVROOT ${CMAKE_BINARY_DIR}/devroot) set(CMAKE_ARGS -DCMAKE_INSTALL_PREFIX=${DEVROOT}) ExternalProject_Add( a CMAKE_ARGS ${CMAKE_ARGS} SOURCE_DIR ${CMAKE_SOURCE_DIR}/../liba ) ExternalProject_Add( b DEPENDS a CMAKE_ARGS ${CMAKE_ARGS} SOURCE_DIR ${CMAKE_SOURCE_DIR}/../libb ) ExternalProject_Add( app DEPENDS b CMAKE_ARGS ${CMAKE_ARGS} SOURCE_DIR ${CMAKE_SOURCE_DIR}/../app ) Regards, Adam On Tue, Mar 17, 2015 at 4:50 AM, Stephen Kelly wrote: > Richard Taylor wrote: > > > > > http://www.cmake.org/Wiki/CMake/Tutorials/How_to_create_a_ProjectConfig.cmake_file > > > > Prefer the official documentation instead of the wiki wherever official > documentation exists (especially if it is well-formatted; that means it's > probably recent and maintained). > > http://www.cmake.org/cmake/help/v3.0/manual/cmake-packages.7.html > > > However, only the names of dependent targets are set (via > > INTERFACE_LINK_LIBRARIES in Targets.cmake) > > > > I guess that's where the problem lies, I'm just not sure how to fix it.. > > The above link documents a find_dependency macro, which you might make use > of. > > Thanks, > > Steve. > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 cedric.doucet at inria.fr Tue Mar 17 10:12:29 2015 From: cedric.doucet at inria.fr (Cedric Doucet) Date: Tue, 17 Mar 2015 15:12:29 +0100 (CET) Subject: [CMake] How do one manage external projects in a clean way? In-Reply-To: <797344038.1127726.1426600954442.JavaMail.zimbra@inria.fr> Message-ID: <636456153.1133283.1426601549390.JavaMail.zimbra@inria.fr> Hello! I would like to manage external libraries called in my code. My goal is to let users install these libraries by themselves or let CMake download and install these libraries for them. For the moment, I use External_project_add command to download external libraries. This works good and I am very happy with it. However, I do not understand the meaning of some subdirectories (xxx-build, xxx-stamp, etc.). It is a problem for me because I sometimes need to specify my own configuration, building and installation commands for some specific libraries. Unfortunately, I never know where to put the result of these steps. Thus, my installation directory may be very dirty and I would like to tidy it. Could someone help me? Furhtermore, I would like to let users provide their own installation for all or some of these external libraries called in my code. Could someone explain me how to manage these options? Thnak you very much for your help! Best regards, C?dric Doucet INRIA Paris-Rocquencourt France -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Tue Mar 17 14:10:54 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 17 Mar 2015 14:10:54 -0400 Subject: [CMake] Problems with WriteCompilerDetectionHeader and cxx_nullptr In-Reply-To: <79A8C11B-800E-46C2-B462-AA8156C79B41@gmx.at> References: <79A8C11B-800E-46C2-B462-AA8156C79B41@gmx.at> Message-ID: <55086E2E.9010106@kitware.com> On 03/16/2015 03:05 AM, Roman W?ger wrote: > attached is an updated patch. Applied, thanks: WCDH: Fix cxx_nullptr workaround for pre-C++11 compilers http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f9d09626 -Brad From adam707blue at gmail.com Tue Mar 17 16:11:10 2015 From: adam707blue at gmail.com (Adam) Date: Wed, 18 Mar 2015 06:11:10 +1000 Subject: [CMake] nonstandard C++ source filename extension In-Reply-To: References: Message-ID: Hi Dave, try add_definitions("-x c++") CMakeLists.txt cmake_minimum_required(VERSION 3.0 FATAL_ERROR) project(asm CXX) add_definitions("-x c++") set_source_files_properties(foo.bar PROPERTIES LANGUAGE CXX) add_executable(foo foo.bar) set_target_properties(foo PROPERTIES LINKER_LANGUAGE CXX) Adam On Tue, Mar 17, 2015 at 2:10 PM, Dave Yost wrote: > From what I can glean online, I?ve tried this: > > set_source_files_properties(foo.bar PROPERTIES LANGUAGE CXX) > add_executable(foo foo.bar) > set_target_properties(foo PROPERTIES LINKER_LANGUAGE CXX) > > > but it doesn?t work. > What am I missing? > > 0 Mon 20:16:15 yost > 1181 Z% cat CMakeLists.txt > cmake_minimum_required(VERSION 3.0 FATAL_ERROR) > project(asm CXX) > > set_source_files_properties(foo.bar PROPERTIES LANGUAGE CXX) > add_executable(foo foo.bar) > set_target_properties(foo PROPERTIES LINKER_LANGUAGE CXX) > 0 Mon 20:16:43 yost > 1182 Z% cat foo.bar > #include > > int main(int argc, char* argv[]) { > std::cout << "Hello\"\n"; > return 0; > } > 0 Mon 20:16:46 yost > 1183 Z% cd build ; cmake .. > -- The CXX compiler identification is GNU 4.9.2 > -- Checking whether CXX compiler has -isysroot > -- Checking whether CXX compiler has -isysroot - yes > -- Checking whether CXX compiler supports OSX deployment target flag > -- Checking whether CXX compiler supports OSX deployment target flag - yes > -- Check for working CXX compiler: /opt/local/bin/c++ > -- Check for working CXX compiler: /opt/local/bin/c++ -- works > -- Detecting CXX compiler ABI info > -- Detecting CXX compiler ABI info - done > -- Detecting CXX compile features > -- Detecting CXX compile features - done > -- Configuring done > -- Generating done > -- Build files have been written to: /Users/yost/p/c++/cmake/asm/build > 0 Mon 20:16:58 yost > 1184 Z% make > Scanning dependencies of target foo > [100%] Building CXX object CMakeFiles/foo.dir/foo.bar.o > c++: warning: /Users/yost/p/c++/cmake/asm/foo.bar: linker input file > unused because linking not done > Linking CXX executable foo > c++: error: CMakeFiles/foo.dir/foo.bar.o: No such file or directory > CMakeFiles/foo.dir/build.make:85: recipe for target 'foo' failed > make[2]: *** [foo] Error 1 > CMakeFiles/Makefile2:60: recipe for target 'CMakeFiles/foo.dir/all' failed > make[1]: *** [CMakeFiles/foo.dir/all] Error 2 > Makefile:75: recipe for target 'all' failed > make: *** [all] Error 2 > 2 Mon 20:17:01 yost > 1185 Z% rm -rf * ; cmake .. > zsh: sure you want to delete all the files in > /Users/yost/p/c++/cmake/asm/build [yn]? y > -- The CXX compiler identification is GNU 4.9.2 > -- Checking whether CXX compiler has -isysroot > -- Checking whether CXX compiler has -isysroot - yes > -- Checking whether CXX compiler supports OSX deployment target flag > -- Checking whether CXX compiler supports OSX deployment target flag - yes > -- Check for working CXX compiler: /opt/local/bin/c++ > -- Check for working CXX compiler: /opt/local/bin/c++ -- works > -- Detecting CXX compiler ABI info > -- Detecting CXX compiler ABI info - done > -- Detecting CXX compile features > -- Detecting CXX compile features - done > -- Configuring done > -- Generating done > -- Build files have been written to: /Users/yost/p/c++/cmake/asm/build > 0 Mon 20:23:00 yost > 1201 Z% make VERBOSE=1 > /Applications/CMake.app/Contents/bin/cmake -H/Users/yost/p/c++/cmake/asm > -B/Users/yost/p/c++/cmake/asm/build --check-build-system > CMakeFiles/Makefile.cmake 0 > /Applications/CMake.app/Contents/bin/cmake -E cmake_progress_start > /Users/yost/p/c++/cmake/asm/build/CMakeFiles > /Users/yost/p/c++/cmake/asm/build/CMakeFiles/progress.marks > make -f CMakeFiles/Makefile2 all > make[1]: Entering directory '/Users/yost/p/c++/cmake/asm/build' > make -f CMakeFiles/foo.dir/build.make CMakeFiles/foo.dir/depend > make[2]: Entering directory '/Users/yost/p/c++/cmake/asm/build' > cd /Users/yost/p/c++/cmake/asm/build && > /Applications/CMake.app/Contents/bin/cmake -E cmake_depends "Unix > Makefiles" /Users/yost/p/c++/cmake/asm /Users/yost/p/c++/cmake/asm > /Users/yost/p/c++/cmake/asm/build /Users/yost/p/c++/cmake/asm/build > /Users/yost/p/c++/cmake/asm/build/CMakeFiles/foo.dir/DependInfo.cmake > --color= > Dependee > "/Users/yost/p/c++/cmake/asm/build/CMakeFiles/foo.dir/DependInfo.cmake" is > newer than depender > "/Users/yost/p/c++/cmake/asm/build/CMakeFiles/foo.dir/depend.internal". > Dependee > "/Users/yost/p/c++/cmake/asm/build/CMakeFiles/CMakeDirectoryInformation.cmake" > is newer than depender > "/Users/yost/p/c++/cmake/asm/build/CMakeFiles/foo.dir/depend.internal". > Scanning dependencies of target foo > make[2]: Leaving directory '/Users/yost/p/c++/cmake/asm/build' > make -f CMakeFiles/foo.dir/build.make CMakeFiles/foo.dir/build > make[2]: Entering directory '/Users/yost/p/c++/cmake/asm/build' > /Applications/CMake.app/Contents/bin/cmake -E cmake_progress_report > /Users/yost/p/c++/cmake/asm/build/CMakeFiles 1 > [100%] Building CXX object CMakeFiles/foo.dir/foo.bar.o > /opt/local/bin/c++ -o CMakeFiles/foo.dir/foo.bar.o -c > /Users/yost/p/c++/cmake/asm/foo.bar > c++: warning: /Users/yost/p/c++/cmake/asm/foo.bar: linker input file > unused because linking not done > Linking CXX executable foo > /Applications/CMake.app/Contents/bin/cmake -E cmake_link_script > CMakeFiles/foo.dir/link.txt --verbose=1 > /opt/local/bin/c++ -Wl,-search_paths_first > -Wl,-headerpad_max_install_names CMakeFiles/foo.dir/foo.bar.o -o foo > c++: error: CMakeFiles/foo.dir/foo.bar.o: No such file or directory > CMakeFiles/foo.dir/build.make:85: recipe for target 'foo' failed > make[2]: *** [foo] Error 1 > make[2]: Leaving directory '/Users/yost/p/c++/cmake/asm/build' > CMakeFiles/Makefile2:60: recipe for target 'CMakeFiles/foo.dir/all' failed > make[1]: *** [CMakeFiles/foo.dir/all] Error 2 > make[1]: Leaving directory '/Users/yost/p/c++/cmake/asm/build' > Makefile:75: recipe for target 'all' failed > make: *** [all] Error 2 > 2 Mon 20:23:04 yost > 1202 Z% > > (I added the light blue and orange coloring by hand for readability.) > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.turner at kdab.com Wed Mar 18 01:08:54 2015 From: james.turner at kdab.com (James Turner) Date: Wed, 18 Mar 2015 05:08:54 +0000 Subject: [CMake] Correct way to set machos-min-version in Cmake 3.2.1 Message-ID: <5E4E9EDA-642A-42EA-B20E-77F7FA14D8F4@kdab.com> Hello, I?d imagine this is a FAQ, but I?ve Googled without success. Apologies if the answer is out there. With Cmake 3.2.1, some behaviour seems to have changed, in the handling of CMAKE_OSX_DEPLOYMENT_TARGET. I am trying to build using the 10.9 SDK, but with macosx-min-version set to 10.7 (I need to code-sign on 10.9 for Gatekeeper v2). Previously I was doing: set(CMAKE_OSX_DEPLOYMENT_TARGET 10.7) And this would cause cmake to set: -mmacosx-version-min=10.7 As of 3.2.1, setting CMAKE_OSX_DEPLOYMENT_TARGET to 10.7 fail (with newest Xcode) because there is no 10.7 SDK. So I changed my CMake files to do: SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -mmacosx-version-min=10.7?) This works but unfortunately CMake i.s explicitly setting the flag too, so I end up with both value in my CXXFLAGS: -mmacosx-version-min=10.9 -mmacosx-version-min=10.7 What is the correct way to request this now, such that the flag is only generated once? All of the above with latest Xcode and using Xcode project files. Kind regards, James From damian.philipp at gmx.net Wed Mar 18 02:23:12 2015 From: damian.philipp at gmx.net (Damian Philipp) Date: Wed, 18 Mar 2015 07:23:12 +0100 Subject: [CMake] Unreliable Find*.conf Message-ID: <550919D0.7070000@gmx.net> Hello cmake-experts, I am working on a project that uses a third-party library delivered in binary form (TeamSpeak 3 SDK). My project is supposed to build on Win, Linux, and OSX, so I decided to use cmake as a build tool. I have started work on a Findts3sdk.cmake (find_package() in module mode) to let cmake detect the library in the CMAKE_PREFIX_PATH on any of my machines - file attached at the end of this mail. My (current) problem is that a call to find_path() in my Findts3sdk.cmake will not pick up the bin directory containing the libraries, while another call did work to find the include directory. WORKS (ts3sdk_INCLUDE_DIR == /path/to/ts3_sdk_3.0.3/include): > find_path(ts3sdk_INCLUDE_DIR NAMES clientlib.h HINTS ${CMAKE_PREFIX_PATH}/include) BROKEN (ts3sdk_LIBRARY_DIR == ts3sdk_LIBRARY_DIR-NOTFOUND): > find_path(ts3sdk_LIBRARY_DIR NAMES libts3client_mac.dylib HINTS ${CMAKE_PREFIX_PATH}/bin) I deduce from this that CMAKE_PREFIX_PATH is set correctly. I have tried the broken command with other names of the library file as well (ts3client_mac, libts3client_mac, libts3client_mac.dylib, ts3client_mac.dylib). What do I have to fix to make find_path() pick up the library file? I am currently on a Mac, using cmake 3.1.3 installed from MacPorts. cmake is called with -DCMAKE_PREFIX_PATH="/path/to/ts3_sdk_3.0.3". The layout of the library delivery is as follows: > ts3_sdk_3.0.3 > ??? bin > ? ??? libts3client_linux_amd64.so > ? ??? libts3client_linux_x86.so > ? ??? libts3client_mac.dylib > ? ??? libts3server_freebsd_amd64.so > ? ??? libts3server_freebsd_x86.so > ? ??? libts3server_linux_amd64.so > ? ??? libts3server_linux_x86.so > ? ??? libts3server_mac.dylib > ? ??? soundbackends > ? ??? ts3client_win32.dll > ? ??? ts3client_win64.dll > ? ??? ts3server_win32.dll > ? ??? ts3server_win64.dll > ??? include > ? ??? clientlib.h > ? ??? clientlib_publicdefinitions.h > ? ??? public_definitions.h > ? ??? public_errors.h > ? ??? serverlib.h > ? ??? serverlib_publicdefinitions.h > ??? lib > ??? ts3client_win32.lib > ??? ts3client_win64.lib > ??? ts3server_win32.lib > ??? ts3server_win64.lib My current Findts3sdk.conf looks as follows: > # Find the INCLULDE and LIBRARY path > find_path(ts3sdk_INCLUDE_DIR NAMES clientlib.h HINTS ${CMAKE_PREFIX_PATH}/include) > > if (WIN32) > set(ts3sdk_client_LIBRARIES ts3client_win32 ts3client_amd64) > set(ts3sdk_server_LIBRARIES ts3server_win32 ts3server_amd64) > elseif (APPLE) > set(ts3sdk_client_LIBRARIES ts3client_mac) > set(ts3sdk_server_LIBRARIES ts3server_mac) > elseif (UNIX) > set(ts3sdk_client_LIBRARIES ts3client_linux_x86 ts3client_linux_amd64) > set(ts3sdk_server_LIBRARIES ts3server_linux_x86 ts3server_linux_amd64) > endif() > > #find_path(ts3sdk_LIBRARY_DIR NAMES ${ts3sdk_client_LIBRARIES} HINTS ${CMAKE_PREFIX_PATH}/bin) > find_path(ts3sdk_LIBRARY_DIR NAMES ts3client_mac.dylib HINTS ${CMAKE_PREFIX_PATH}/bin) > #find_path(ts3sdk_LIBRARY_DIR NAMES ${ts3sdk_client_LIBRARIES} ${ts3sdk_server_LIBRARIES} HINTS ${CMAKE_PREFIX_PATH}/bin) > > # Combine into output information > set(ts3sdk_INCLUDE_DIRS ${ts3sdk_INCLUDE_DIR}) > set(ts3sdk_LIBRARY_DIRS ${ts3sdk_LIBRARY_DIR}) > > message(STATUS "ts3sdk headers found in " ${ts3sdk_INCLUDE_DIRS}) > message(STATUS "ts3sdk libraries used: " ${ts3sdk_client_LIBRARIES}) > message(STATUS "ts3sdk libraries found in " ${ts3sdk_LIBRARY_DIR}) Regards, Damian Philipp From eike at sf-mail.de Wed Mar 18 02:59:51 2015 From: eike at sf-mail.de (Rolf Eike Beer) Date: Wed, 18 Mar 2015 07:59:51 +0100 Subject: [CMake] Unreliable Find*.conf In-Reply-To: <550919D0.7070000@gmx.net> References: <550919D0.7070000@gmx.net> Message-ID: <3794191.j7vfQALC86@caliban.sf-tec.de> Am Mittwoch, 18. M?rz 2015, 07:23:12 schrieb Damian Philipp: > Hello cmake-experts, > > I am working on a project that uses a third-party library delivered in > binary form (TeamSpeak 3 SDK). My project is supposed to build on Win, > Linux, and OSX, so I decided to use cmake as a build tool. I have > started work on a Findts3sdk.cmake (find_package() in module mode) to > let cmake detect the library in the CMAKE_PREFIX_PATH on any of my > machines - file attached at the end of this mail. > > My (current) problem is that a call to find_path() in my > Findts3sdk.cmake will not pick up the bin directory containing the > libraries, while another call did work to find the include directory. > > WORKS (ts3sdk_INCLUDE_DIR == /path/to/ts3_sdk_3.0.3/include): > > find_path(ts3sdk_INCLUDE_DIR NAMES clientlib.h HINTS > > ${CMAKE_PREFIX_PATH}/include) > BROKEN (ts3sdk_LIBRARY_DIR == ts3sdk_LIBRARY_DIR-NOTFOUND): > > find_path(ts3sdk_LIBRARY_DIR NAMES libts3client_mac.dylib HINTS > > ${CMAKE_PREFIX_PATH}/bin) Use find_library() to find the library itself. If you really need the library directory (you probably don't) then use get_filename_component() on the library location returned by find_library(). 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 m.espak at ucl.ac.uk Wed Mar 18 08:25:24 2015 From: m.espak at ucl.ac.uk (Miklos Espak) Date: Wed, 18 Mar 2015 12:25:24 +0000 Subject: [CMake] how to create a custom dashboard? Message-ID: ... different then "Nightly", "Continuous" and "Experimental"? I would like to have a dashboard per branch for continuous testing, so that we can track the changes in the individual branches independently. The --track option should be for that, I think, but could not get it working. I tried this: ctest -S CTestContinuous.cmake --track 4009-external-project-dir I also tried to specify the branch name as the parameter of ctest_start(). I attached the ctest script. The result always goes to the Continuous dashboard discarding the command line switch and the argument. Any idea? Cheers, Miklos -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: CTestContinuous.cmake Type: text/x-cmake Size: 1576 bytes Desc: not available URL: From post at hendrik-sattler.de Wed Mar 18 08:28:37 2015 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Wed, 18 Mar 2015 13:28:37 +0100 Subject: [CMake] Unreliable Find*.conf In-Reply-To: <550919D0.7070000@gmx.net> References: <550919D0.7070000@gmx.net> Message-ID: <37AE6A17-D5E4-4BC3-B060-E0DAF441AEA4@hendrik-sattler.de> Am 18. M?rz 2015 07:23:12 MEZ, schrieb Damian Philipp : >Hello cmake-experts, > >I am working on a project that uses a third-party library delivered in >binary form (TeamSpeak 3 SDK). My project is supposed to build on Win, >Linux, and OSX, so I decided to use cmake as a build tool. I have >started work on a Findts3sdk.cmake (find_package() in module mode) to >let cmake detect the library in the CMAKE_PREFIX_PATH on any of my >machines - file attached at the end of this mail. > >My (current) problem is that a call to find_path() in my >Findts3sdk.cmake will not pick up the bin directory containing the >libraries, while another call did work to find the include directory. > >WORKS (ts3sdk_INCLUDE_DIR == /path/to/ts3_sdk_3.0.3/include): >> find_path(ts3sdk_INCLUDE_DIR NAMES clientlib.h HINTS >${CMAKE_PREFIX_PATH}/include) > >BROKEN (ts3sdk_LIBRARY_DIR == ts3sdk_LIBRARY_DIR-NOTFOUND): >> find_path(ts3sdk_LIBRARY_DIR NAMES libts3client_mac.dylib HINTS >${CMAKE_PREFIX_PATH}/bin) CMAKE_PREFIX_PATH is possibly a list so the above does not always work. IIRC Just use PATH_SUFFIXES bin instead. And use find_ library() instead. >I deduce from this that CMAKE_PREFIX_PATH is set correctly. I have >tried >the broken command with other names of the library file as well >(ts3client_mac, libts3client_mac, libts3client_mac.dylib, >ts3client_mac.dylib). > >What do I have to fix to make find_path() pick up the library file? > >I am currently on a Mac, using cmake 3.1.3 installed from MacPorts. >cmake is called with -DCMAKE_PREFIX_PATH="/path/to/ts3_sdk_3.0.3". >The layout of the library delivery is as follows: > >> ts3_sdk_3.0.3 >> ??? bin >> ? ??? libts3client_linux_amd64.so >> ? ??? libts3client_linux_x86.so >> ? ??? libts3client_mac.dylib >> ? ??? libts3server_freebsd_amd64.so >> ? ??? libts3server_freebsd_x86.so >> ? ??? libts3server_linux_amd64.so >> ? ??? libts3server_linux_x86.so >> ? ??? libts3server_mac.dylib >> ? ??? soundbackends >> ? ??? ts3client_win32.dll >> ? ??? ts3client_win64.dll >> ? ??? ts3server_win32.dll >> ? ??? ts3server_win64.dll Maybe you should start telling the makers of the SDK to fix their directory layout as .so and .dylib files do not belong to the bin folder but to the library folder. That would also make find_library() work more easily. And naming the library differently for every case is just...strange. >> ??? include >> ? ??? clientlib.h >> ? ??? clientlib_publicdefinitions.h >> ? ??? public_definitions.h >> ? ??? public_errors.h >> ? ??? serverlib.h >> ? ??? serverlib_publicdefinitions.h >> ??? lib >> ??? ts3client_win32.lib >> ??? ts3client_win64.lib >> ??? ts3server_win32.lib >> ??? ts3server_win64.lib > >My current Findts3sdk.conf looks as follows: > >> # Find the INCLULDE and LIBRARY path >> find_path(ts3sdk_INCLUDE_DIR NAMES clientlib.h HINTS >${CMAKE_PREFIX_PATH}/include) >> >> if (WIN32) >> set(ts3sdk_client_LIBRARIES ts3client_win32 ts3client_amd64) >> set(ts3sdk_server_LIBRARIES ts3server_win32 ts3server_amd64) >> elseif (APPLE) >> set(ts3sdk_client_LIBRARIES ts3client_mac) >> set(ts3sdk_server_LIBRARIES ts3server_mac) >> elseif (UNIX) >> set(ts3sdk_client_LIBRARIES ts3client_linux_x86 >ts3client_linux_amd64) >> set(ts3sdk_server_LIBRARIES ts3server_linux_x86 >ts3server_linux_amd64) >> endif() >> >> #find_path(ts3sdk_LIBRARY_DIR NAMES ${ts3sdk_client_LIBRARIES} HINTS >${CMAKE_PREFIX_PATH}/bin) >> find_path(ts3sdk_LIBRARY_DIR NAMES ts3client_mac.dylib HINTS >${CMAKE_PREFIX_PATH}/bin) >> #find_path(ts3sdk_LIBRARY_DIR NAMES ${ts3sdk_client_LIBRARIES} >${ts3sdk_server_LIBRARIES} HINTS ${CMAKE_PREFIX_PATH}/bin) >> >> # Combine into output information >> set(ts3sdk_INCLUDE_DIRS ${ts3sdk_INCLUDE_DIR}) >> set(ts3sdk_LIBRARY_DIRS ${ts3sdk_LIBRARY_DIR}) >> >> message(STATUS "ts3sdk headers found in " ${ts3sdk_INCLUDE_DIRS}) >> message(STATUS "ts3sdk libraries used: " ${ts3sdk_client_LIBRARIES}) >> message(STATUS "ts3sdk libraries found in " ${ts3sdk_LIBRARY_DIR}) > >Regards, >Damian Philipp >-- > >Powered by www.kitware.com > >Please keep messages on-topic and check the CMake FAQ at: >http://www.cmake.org/Wiki/CMake_FAQ > >Kitware offers various services to support the CMake community. For >more information on each offering, please visit: > >CMake Support: http://cmake.org/cmake/help/support.html >CMake Consulting: http://cmake.org/cmake/help/consulting.html >CMake Training Courses: http://cmake.org/cmake/help/training.html > >Visit other Kitware 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 gjasny at googlemail.com Wed Mar 18 13:02:09 2015 From: gjasny at googlemail.com (Gregor Jasny) Date: Wed, 18 Mar 2015 18:02:09 +0100 Subject: [CMake] Correct way to set machos-min-version in Cmake 3.2.1 In-Reply-To: <5E4E9EDA-642A-42EA-B20E-77F7FA14D8F4@kdab.com> References: <5E4E9EDA-642A-42EA-B20E-77F7FA14D8F4@kdab.com> Message-ID: <5509AF91.4050909@googlemail.com> Hello, On 18/03/15 06:08, James Turner wrote: > I?d imagine this is a FAQ, but I?ve Googled without success. Apologies if the answer is out there. > > With Cmake 3.2.1, some behaviour seems to have changed, in the handling of CMAKE_OSX_DEPLOYMENT_TARGET. > > I am trying to build using the 10.9 SDK, but with macosx-min-version set to 10.7 (I need to code-sign on 10.9 for Gatekeeper v2). > > Previously I was doing: > > set(CMAKE_OSX_DEPLOYMENT_TARGET 10.7) > > And this would cause cmake to set: > > -mmacosx-version-min=10.7 > > As of 3.2.1, setting CMAKE_OSX_DEPLOYMENT_TARGET to 10.7 fail (with newest Xcode) because there is no 10.7 SDK. So I changed my CMake files to do: > > SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -mmacosx-version-min=10.7?) > > This works but unfortunately CMake i.s explicitly setting the flag too, so I end up with both value in my CXXFLAGS: > > -mmacosx-version-min=10.9 > -mmacosx-version-min=10.7 > > What is the correct way to request this now, such that the flag is only generated once? As far as I remember if you don't set a SDK CMake tries to use the min-version as such. So in your case you could try: -DCMAKE_OSX_SYSROOT=macosx -DCMAKE_OSX_DEPLOYMENT_TARGET=10.7 If you set CMAKE_OSX_SYSROOT to macosx it will use the latest one. Otherwise you could also specify a version like macosx10.9. Hope that helps, Gregor From steveire at gmail.com Wed Mar 18 15:13:58 2015 From: steveire at gmail.com (Stephen Kelly) Date: Wed, 18 Mar 2015 20:13:58 +0100 Subject: [CMake] Full paths for transitive dependencies References: Message-ID: Adam wrote: > I happened to stumble acrosss this today. I fixed it by adding another > find_package to the last project but this seems to defeat the purpose of > transitive dependencies. What am I doing wrong? The docs I linked to describe Config files which include() the result of install(EXPORT). Thanks, Steve. From aditya.siram at gmail.com Wed Mar 18 18:59:10 2015 From: aditya.siram at gmail.com (aditya siram) Date: Wed, 18 Mar 2015 17:59:10 -0500 Subject: [CMake] Supress generation of a Makefile Message-ID: Hi all, I have a cross platform project where Linux/Mac users will use the standard "autoheader;autoconf;./configure .." routine, but on Windows users will do "cmake .; make". I am using CMake solely to substitute some variables in some subdirectory Makefile.in's. The problem is that there is an existing Makefile in the root of the project that must not be disturbed but keeps getting overwritten whenever I run "cmake .". How do I stop CMake from generating a Makefile? Thanks! -deech -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.pavlik at gmail.com Wed Mar 18 20:42:20 2015 From: ryan.pavlik at gmail.com (Ryan Pavlik) Date: Thu, 19 Mar 2015 00:42:20 +0000 Subject: [CMake] Supress generation of a Makefile References: Message-ID: If you can't/won't use CMake on all platforms (why? Seems like extra maintenance effort)... You should be OK if you do an out of source build as usually recommended for CMake; that is, generating the build files (by running cmake in) in a different directory than your source code. Ryan On Wed, Mar 18, 2015, 6:00 PM aditya siram wrote: > Hi all, > I have a cross platform project where Linux/Mac users will use the > standard "autoheader;autoconf;./configure .." routine, but on Windows users > will do "cmake .; make". > > I am using CMake solely to substitute some variables in some subdirectory > Makefile.in's. > > The problem is that there is an existing Makefile in the root of the > project that must not be disturbed but keeps getting overwritten whenever I > run "cmake .". > > How do I stop CMake from generating a Makefile? > > Thanks! > -deech > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From post at hendrik-sattler.de Thu Mar 19 02:20:43 2015 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Thu, 19 Mar 2015 07:20:43 +0100 Subject: [CMake] Supress generation of a Makefile In-Reply-To: References: Message-ID: Am 18. M?rz 2015 23:59:10 MEZ, schrieb aditya siram : >Hi all, >I have a cross platform project where Linux/Mac users will use the >standard >"autoheader;autoconf;./configure .." routine, but on Windows users will >do >"cmake .; make". that's the wrong command >I am using CMake solely to substitute some variables in some >subdirectory >Makefile.in's. Strange idea, really. >The problem is that there is an existing Makefile in the root of the >project that must not be disturbed but keeps getting overwritten >whenever I >run "cmake .". >How do I stop CMake from generating a Makefile? 1. Don't have any file named CMakeLists.txt in that directory, give it some other name ending usually with .cmake 2. Use cmake -P HS From shiyong.zhang.cn at gmail.com Thu Mar 19 04:39:40 2015 From: shiyong.zhang.cn at gmail.com (=?gb2312?B?1cXKwNPC?=) Date: Thu, 19 Mar 2015 08:39:40 +0000 Subject: [CMake] How to use pkg-config in CMakeLists.txt Message-ID: Hello All I'm newer for CMake. Now I'm trying to use CMake in current project, but I met following issue CMakeLists.txt : FIND_PACKAGE(PkgConfig)PKG_CHECK_MODULES(GLIB glib-2.0)PKG_CHECK_MODULES(GTHREAD gthread-2.0)PKG_CHECK_MODULES(GOBJECT gobject-2.0) SET(GLIB_LIBS glib-2.0 gthread-2.0 gobject-2.0) EXEC_PROGRAM(pkg-config ARGS --cflags ${GLIB_LIBS} OUTPUT_VARIABLE GLIB2_CFLAGS RETURE_VALUE PKG_CONFIG_RETURE_VALUE)EXEC_PROGRAM(pkg-config ARGS --libs ${GLIB_LIBS} OUTPUT_VARIABLE GLIB2_LIBS RETURN_VALUE PKG_CONFIG_RETURE_VALUE)MESSAGE(${GLIB2_CFLAGS})MESSAGE(${GLIB2_LIBS}) INCLUDE_DIRECTORIES(AFTER GLIB_INCLUDE_DIRS)INCLUDE_DIRECTORIES(AFTER GTHREAD_INCLUDE_DIRS)INCLUDE_DIRECTORIES(AFTER GOBJECT_INCLUDE_DIRS) INCLUDE_DIRECTORIES(AFTER ${PROJECT_SOURCE_DIR}/include ${PROJECT_SOURCE_DIR}/include/message)INCLUDE_DIRECTORIES(AFTER ${GLIB2_CFLAGS}) SET(SRC_LIST main.c nmp_args.c nmp_message.c nmp_sysctl.c)ADD_EXECUTABLE(nmp-cms ${SRC_LIST})TARGET_LINK_LIBRARIES(nmp-cms ${GLIB2_LIBS}) When I execute 'CMake VERBOSE=1', I found its output was the following. How could I remove the quotation marks ? Or it's incorrect to use the pkg-config in CMakelist ? cd /home/compiler/nmp-cms/build/obj/core && /usr/bin/gcc -I/home/compiler/nmp-cms/src/core/GLIB_INCLUDE_DIRS -I/home/compiler/nmp-cms/src/core/GTHREAD_INCLUDE_DIRS -I/home/compiler/nmp-cms/src/core/GOBJECT_INCLUDE_DIRS -I/home/compiler/nmp-cms/include -I/home/compiler/nmp-cms/include/message -I"/home/compiler/nmp-cms/src/core/-pthread -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include" -o CMakeFiles/nmp-cms.dir/main.c.o -c /home/compiler/nmp-cms/src/core/main.c/home/compiler/nmp-cms/src/core/main.c:5:18: fatal error: glib.h: No such file or directory Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: From becker.tobi at gmail.com Thu Mar 19 06:20:14 2015 From: becker.tobi at gmail.com (Tobias Becker) Date: Thu, 19 Mar 2015 11:20:14 +0100 Subject: [CMake] (no subject) Message-ID: I have written a cmake tool which allows you to modify CMakeLists files from the command line. It is written in pure cmake leverages my cmake token parser/ reflection functions which I added to cmakepp (a free, universial, open source, pure cmake function library) http://thetoeb.de/2015/03/19/cmakepp-reflecting-and-manipulating-cmakelists/ If anyone is interested and has suggestion visit me on https://github.com/toeb/cmakepp Cheers Tobi -------------- next part -------------- An HTML attachment was scrubbed... URL: From usenet at majchrowski.de Thu Mar 19 11:26:35 2015 From: usenet at majchrowski.de (Tomasz Majchrowski) Date: Thu, 19 Mar 2015 16:26:35 +0100 Subject: [CMake] control dependencies in cmake stage In-Reply-To: References: Message-ID: Thank you Mark for hint about that solution. I think the losses may be reduced by distributing #includes directives across many well known files (as in example: GenChunk.tar) Those chunks can be already compiled in parallel. Best regards, Tomasz. 2015-03-12 17:50 GMT+01:00 Mark Abraham : > Hi, > > In that case, you could have the generator generate a master source file > with a known name that #includes the real generated files. This means that > the generation can have clean dependencies, but does lose any benefits from > parallel make. It also keeps the intrinsic complexity of the generation > close to itself, rather than unduly complicating the build system. Up to > you. > > Mark > On 11/03/2015 6:40 pm, "Tomasz Majchrowski" > wrote: > >> Thank you Mark for information. The input for the generator is in-house >> developed language. The decision what kind of files will be generated is >> made based on the grammar of this language. >> >> In the current implementation of the generator the extraction of the file >> list will take more or less the same time as execution of the generation >> phase itself. Otherwise we will definitely use make phase. >> >> Best regards, Tomasz. >> >> 2015-03-11 0:15 GMT+01:00 Mark Abraham : >> >>> Hi, >>> >>> Sure, this is straightforward to do all at make time, if you're prepared >>> to find out what the names of the generated files are. They must follow >>> some pattern ;-). Solutions with make-time globbing are surely impossible, >>> and Petr's IF idea seems brittle to me. >>> >>> See (for example) >>> https://github.com/gromacs/gromacs/blob/master/src/gromacs/CMakeLists.txt#L154. >>> The idea is that you have some target that does the generation, and you >>> make the eventual library/executable depend on its output files. The target >>> that contains the generation command has its own dependencies, so you don't >>> have to re-generate if those don't go out of date. In that example, >>> gmx_configure_version_file just wraps configure_file(), which sets up that >>> dependency chain. You'd need an add_custom_command(), it seems, whose >>> OUTPUT had the list of generated files. There's no problem to use >>> add_library() with a file generated in the build tree - just mention it in >>> an output. >>> >>> There are several much more complicated examples at >>> https://github.com/gromacs/gromacs/blob/master/docs/CMakeLists.txt. For >>> example, we build a gmx binary that writes the same text we display with >>> "gmx topic -h" instead as topic.rst restructedText, which is then parsed >>> with Sphinx to produce manpages that go in the tarball via CPack, or to >>> produce HTML to go on our webpage. Helper scripts mostly live in >>> https://github.com/gromacs/gromacs/tree/master/cmake >>> >>> Cheers, >>> >>> Mark >>> >>> >>> On Tue, Mar 10, 2015 at 6:06 PM, Tomasz Majchrowski < >>> usenet at majchrowski.de> wrote: >>> >>>> (sorry if you received this message twice) >>>> >>>> Hi Mark >>>> >>>> This is the set of C++ source code files. This set will be compiled >>>> during the make stage. Ideally will be to move generation to make stage. >>>> Unfortunately I don't know the name of the files that will be generated >>>> before generation phase occurs. >>>> >>>> Therefore I can't use set_source_files_properties( foo.cxx PROPERTIES >>>> GENERATED true) in cmake stage. Please drop a line if you know how to >>>> bypass this limitation. >>>> >>>> Thanks, Tomasz. >>>> >>>> 2015-03-10 7:05 GMT+01:00 Mark Abraham : >>>> >>>>> Hi, >>>>> >>>>> What are you generating that must be done at cmake time? >>>>> >>>>> Mark >>>>> On 09/03/2015 5:36 pm, "Tomasz Majchrowski" >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I'm wondering if there is an easy way to control the dependencies in >>>>>> the cmake stage. Basically I would like skip execution of some script run >>>>>> over execute_process in case some input files didn't change. >>>>>> >>>>>> The regular way will be to use add_custom_command & add_custom_target >>>>>> however those required targets, so the make stage. >>>>>> >>>>>> Please advice how to proceed in case there is need to control this >>>>>> already in cmake stage? >>>>>> >>>>>> Thanks, Tomasz. >>>>>> >>>>>> >>>>>> -- >>>>>> Pozdrawiam/Best regards/Mit freundlichen Gr??en, Tomasz Majchrowski, >>>>>> Information Technology and Services Consultant and Contractor >>>>>> >>>>>> -- >>>>>> >>>>>> Powered by www.kitware.com >>>>>> >>>>>> Please keep messages on-topic and check the CMake FAQ at: >>>>>> http://www.cmake.org/Wiki/CMake_FAQ >>>>>> >>>>>> Kitware offers various services to support the CMake community. For >>>>>> more information on each offering, please visit: >>>>>> >>>>>> CMake Support: http://cmake.org/cmake/help/support.html >>>>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>>>>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>>>>> >>>>>> Visit other Kitware open-source projects at >>>>>> http://www.kitware.com/opensource/opensource.html >>>>>> >>>>>> Follow this link to subscribe/unsubscribe: >>>>>> http://public.kitware.com/mailman/listinfo/cmake >>>>>> >>>>>> -- >>>>>> Pozdrawiam/Best regards/Mit freundlichen Gr??en, Tomasz Majchrowski, >>>>>> Information Technology and Services Consultant and Contractor >>>>>> >>>>> >>>>> >>> >> >> >> -- >> Pozdrawiam/Best regards/Mit freundlichen Gr??en, Tomasz Majchrowski, >> Information Technology and Services Consultant and Contractor >> >> -- >> Pozdrawiam/Best regards/Mit freundlichen Gr??en, Tomasz Majchrowski, >> Information Technology and Services Consultant and Contractor >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: GenChunk.tar Type: application/x-tar Size: 10240 bytes Desc: not available URL: From bill.hoffman at kitware.com Thu Mar 19 11:38:56 2015 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Thu, 19 Mar 2015 11:38:56 -0400 Subject: [CMake] Supress generation of a Makefile In-Reply-To: References: Message-ID: <550AED90.8010901@kitware.com> On 3/19/2015 2:20 AM, Hendrik Sattler wrote: >> >How do I stop CMake from generating a Makefile? Don't do in source builds. mkdir build. cd build cmake .. -Bill From bill.hoffman at kitware.com Thu Mar 19 11:42:49 2015 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Thu, 19 Mar 2015 11:42:49 -0400 Subject: [CMake] nonstandard C++ source filename extension In-Reply-To: References: Message-ID: <550AEE79.60808@kitware.com> This works for me: ---CMakeLists.txt---- cmake_minimum_required(VERSION 3.0 FATAL_ERROR) project(asm CXX) add_executable(foo foo.bar) set_source_files_properties(foo.bar PROPERTIES LANGUAGE CXX) ---foo.bar--- int main() { return 0;} $ /cygdrive/c/Program\ Files\ \(x86\)/CMake/bin/cmake -GNinja .. -- The CXX compiler identification is MSVC 16.0.40219.1 -- Check for working CXX compiler using: Ninja -- Check for working CXX compiler using: Ninja -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Configuring done -- Generating done -- Build files have been written to: C:/Users/hoffman/foo/b hoffman at quasar ~/foo/b $ ninja [1/2] Building CXX object CMakeFiles\foo.dir\foo.bar.obj foo.bar [2/2] Linking CXX executable foo.exe From tom at recursivedream.com Thu Mar 19 16:20:21 2015 From: tom at recursivedream.com (Tom Davis) Date: Thu, 19 Mar 2015 16:20:21 -0400 Subject: [CMake] Understanding dependencies with an external project Message-ID: <87bnjo3fju.fsf@recursivedream.com> Hi there, I only started using CMake a couple days ago so please pardon the newbie questions. I'm having some trouble understanding the relationships between add_dependencies, add_custom_command, and add_custom_target as they relate to forming dependencies on external project targets. I am trying to write plugins for a CMake-enabled project. How one goes about this is by getting the source and adding an optional cmake module that calls what amounts to a custom externalproject_add() with no build/install step; the external sources are just copied into the framework's source tree. That way, when I call `make`, the framework build includes the plugins. (This inflexible "linking" mechanism is necessary due to language constraints that aren't relevant here) The way I've integrated this into my own project is via my own externalproject_add() that grabs the framework and, as a custom step, copies over the module I mentioned: ExternalProject_Add(framework # ... ) ExternalProject_Add_Step(framework copy-plugin-loader # First symlink so the framework will "download" from local fs COMMAND ${CMAKE_COMMAND} -E create_symlink "${CMAKE_CURRENT_SOURCE_DIR}" "${framework_EXTERNALS_DIR}/my-plugins" # Now link the custom module it needs to find in its modules dir COMMAND ${CMAKE_COMMAND} -E create_symlink "${CMAKE_CURRENT_BINARY_DIR}/CMake/plugin_loader.cmake" "${heka_SOURCE_DIR}/cmake/plugin_loader.cmake" DEPENDERS configure DEPENDEES download ) Later on in my CMakeLists I use add_test() and use `ctest` to run my plugin tests (that only work once my source is grafted onto the framework's tree; see weird language design choice mentioned above). My question (finally) is this: how can I tell CMake that, if I change a source or test file in *my* tree, the framework (specifically, a custom target defined in _the framework's_ CMakeLists) needs to be rebuilt before the tests can run? To illustrate, here's my current workflow: # Edit *my* source files, tests, whatever, then... % cd framework/binary_dir % make graft_plugin_sources % cd - % ctest . Ideally, I could just run `ctest` and CMake will handle the rest. I don't know if that's a thing it does, so, I'd settle for calling the top-level `make` again. I just can't figure out the proper add_*() calls to make to tell CMake "My project (and/or custom target/command of my own) depends on this particular target of `framework` so whenever I change a source file in my project, we gotta re-run it." Thanks in advance for any insight, Tom From robert.bielik at dirac.se Fri Mar 20 06:15:01 2015 From: robert.bielik at dirac.se (Robert Bielik) Date: Fri, 20 Mar 2015 11:15:01 +0100 Subject: [CMake] Xcode Runpath problem Message-ID: <550BF325.9030608@dirac.se> Hi, I have: SET_TARGET_PROPERTIES(MyTarget PROPERTIES XCODE_ATTRIBUTE_LD_RUNPATH_SEARCH_PATHS "~/Library/Application Support/MyTarget/Plugins") and it comes through nicely when running the Xcode IDE, but when using cmake build (cmd line), the linker gets this: -Xlinker -rpath -Xlinker ~/Library/Application -Xlinker -rpath -Xlinker Support/MyTarget/Plugins which obviously is totally messed up. I also tried setting the path as "~/Library/Application\\ Support/MyTarget/Plugins", didn't work either. Ideas ? TIA /Rob From robert.bielik at dirac.se Fri Mar 20 06:26:46 2015 From: robert.bielik at dirac.se (Robert Bielik) Date: Fri, 20 Mar 2015 11:26:46 +0100 Subject: [CMake] Xcode Runpath problem In-Reply-To: <550BF325.9030608@dirac.se> References: <550BF325.9030608@dirac.se> Message-ID: <550BF5E6.90407@dirac.se> Ok, I escaped the string as "\"~/Library/Application Support/MyTarget/Plugins\"", and then it comes out OK to the linker. However... it doesn't work. Dylib dependencies are not found, whereas in the Xcode IDE, they are! :( :( :( About to jump from a very high place. Help ? /Rob Robert Bielik skrev den 2015-03-20 11:15: > Hi, > > I have: > > SET_TARGET_PROPERTIES(MyTarget PROPERTIES > XCODE_ATTRIBUTE_LD_RUNPATH_SEARCH_PATHS "~/Library/Application > Support/MyTarget/Plugins") > > and it comes through nicely when running the Xcode IDE, but when using > cmake build (cmd line), the linker gets this: > > -Xlinker -rpath -Xlinker ~/Library/Application -Xlinker -rpath > -Xlinker Support/MyTarget/Plugins > > which obviously is totally messed up. I also tried setting the path as > "~/Library/Application\\ Support/MyTarget/Plugins", didn't work either. > > Ideas ? > > TIA > /Rob > From m.espak at ucl.ac.uk Fri Mar 20 09:43:36 2015 From: m.espak at ucl.ac.uk (Miklos Espak) Date: Fri, 20 Mar 2015 13:43:36 +0000 Subject: [CMake] how to create a custom dashboard? In-Reply-To: References: Message-ID: I found it. You have to create a group on the CDash project admin interface first, with the same name as what's specified after --track. It is not very flexible, though. Is there a way to create groups via the command line? I could set up a git hook to create the group when a new branch is pushed, or eventually removes the group when the remote branch is deleted. Cheers, Miklos On 18 March 2015 at 12:25, Miklos Espak wrote: > ... different then "Nightly", "Continuous" and "Experimental"? > > I would like to have a dashboard per branch for continuous testing, so > that we can track the changes in the individual branches independently. > > The --track option should be for that, I think, but could not get it > working. > > I tried this: > > ctest -S CTestContinuous.cmake --track 4009-external-project-dir > > I also tried to specify the branch name as the parameter of ctest_start(). > > I attached the ctest script. The result always goes to the Continuous > dashboard discarding the command line switch and the argument. > > Any idea? > > Cheers, > Miklos > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.jackson at bluequartz.net Fri Mar 20 09:58:28 2015 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Fri, 20 Mar 2015 09:58:28 -0400 Subject: [CMake] Adding entries to the info.plist file for OS X .app bundles. Message-ID: <45CCDA7E-3BA0-40CF-A610-EAC962B0FE6E@bluequartz.net> Is there anything in the latest CMake version to add additional entries into the plist file for .app packages? I specifically need the following: NSPrincipalClass NSApplication NSHighResolutionCapable True to support Retina displays for our app. Should I just create my own template .plist file and use "configure_file" to add items into the file? Thanks Mike Jackson From finjulhich at gmail.com Fri Mar 20 10:43:37 2015 From: finjulhich at gmail.com (MM) Date: Fri, 20 Mar 2015 14:43:37 +0000 Subject: [CMake] variable substitution for command arguments Message-ID: I have the following code: ADD_CUSTOM_COMMAND(TARGET markets_odb PRE_BUILD COMMAND odb ARGS -d sqlite --sqlite-override-null --std c++11 --profile boost --generate-query -I${CMAKE_SOURCE_DIR} -I${Boost_INCLUDE_DIRS} --include-prefix dir_odb --changelog ${CMAKE_SOURCE_DIR}/odb/file.xml ${CMAKE_CURRENT_SOURCE_DIR}/file1.hpp COMMAND odb ARGS -d sqlite --sqlite-override-null --std c++11 --profile boost --generate-query -I${CMAKE_SOURCE_DIR} -I${Boost_INCLUDE_DIRS} --include-prefix dir_odb --changelog ${CMAKE_SOURCE_DIR}/odb/file.xml ${CMAKE_CURRENT_SOURCE_DIR}/file2.hpp ... ) I have a few more files than the above 2. Can I factorize part the command args to reduce the repeated part? MM -------------- next part -------------- An HTML attachment was scrubbed... URL: From petr.kmoch at gmail.com Fri Mar 20 11:15:00 2015 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Fri, 20 Mar 2015 16:15:00 +0100 Subject: [CMake] variable substitution for command arguments In-Reply-To: References: Message-ID: Hi. You're already (partially) doing it, with the CMAKE_SOURCE_DIR and Boost_INCLUDE_DIRS variables. You can store whatever list of arguments you want in a variable and expand it in the proper place. For example this: set(MyArgs -d sqlite --sqlite-override-null --std c++11 --profile boost --generate-query -I${CMAKE_SOURCE_DIR} -I${Boost_INCLUDE_DIRS} --include-prefix dir_odb --changelog ${CMAKE_SOURCE_DIR}/odb/file.xml) add_custom_command( TARGET markets_odb PRE_BUILD COMMAND odb ARGS ${MyArgs} ${CMAKE_CURRENT_SOURCE_DIR}/file1.hpp COMMAND odb ARGS ${MyArgs} ${CMAKE_CURRENT_SOURCE_DIR}/file2.hpp ) Remember that what CMake actually does is parse some strings and lists. You could even do this (I wouldn't recommend it, but just to show what's possible): set(MyCommand COMMAND odb ARGS -d sqlite --sqlite-override-null --std c++11 --profile boost --generate-query -I${CMAKE_SOURCE_DIR} -I${Boost_INCLUDE_DIRS} --include-prefix dir_odb --changelog ${CMAKE_SOURCE_DIR}/odb/file.xml) add_custom_command( TARGET markets_odb PRE_BUILD ${MyCommand} ${CMAKE_CURRENT_SOURCE_DIR}/file1.hpp ${MyCommand} ${CMAKE_CURRENT_SOURCE_DIR}/file2.hpp ) Petr On Fri, Mar 20, 2015 at 3:43 PM, MM wrote: > I have the following code: > > ADD_CUSTOM_COMMAND(TARGET markets_odb > PRE_BUILD > COMMAND odb ARGS -d sqlite --sqlite-override-null --std c++11 --profile > boost --generate-query > -I${CMAKE_SOURCE_DIR} -I${Boost_INCLUDE_DIRS} > --include-prefix dir_odb > --changelog ${CMAKE_SOURCE_DIR}/odb/file.xml > ${CMAKE_CURRENT_SOURCE_DIR}/file1.hpp > COMMAND odb ARGS -d sqlite --sqlite-override-null --std c++11 --profile > boost --generate-query > -I${CMAKE_SOURCE_DIR} -I${Boost_INCLUDE_DIRS} > --include-prefix dir_odb > --changelog ${CMAKE_SOURCE_DIR}/odb/file.xml > ${CMAKE_CURRENT_SOURCE_DIR}/file2.hpp > ... > ) > > > I have a few more files than the above 2. > > Can I factorize part the command args to reduce the repeated part? > > MM > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From greenc at fnal.gov Fri Mar 20 11:47:49 2015 From: greenc at fnal.gov (Chris Green) Date: Fri, 20 Mar 2015 10:47:49 -0500 Subject: [CMake] COMMENT ignored for POST_BUILD custom command? Message-ID: <550C4125.5060008@fnal.gov> Hi, With CMake 3.1.2, I don't see my specified COMMENT for a POST_BUILD command on a library target, viz: add_custom_command(TARGET ${LIB_TARGET} POST_BUILD COMMAND ln -sf $ ${CMAKE_SHARED_LIBRARY_PREFIX}${alias}${CMAKE_SHARED_LIBRARY_SUFFIX} COMMENT "Generate / refresh courtesy link ${CMAKE_SHARED_LIBRARY_PREFIX}${alias}${CMAKE_SHARED_LIBRARY_SUFFIX} -> $" VERBATIM WORKING_DIRECTORY ${LIBRARY_OUTPUT_PATH}) The documentation doesn't suggest that this is intended behavior. Is this a bug, or am I doing something wrong? The desired action does get carried out during a build as desired, but there is no screen output of COMMENT to herald the generation of the link. Thanks, Chris. From nilsgladitz at gmail.com Fri Mar 20 12:57:16 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 20 Mar 2015 17:57:16 +0100 Subject: [CMake] COMMENT ignored for POST_BUILD custom command? In-Reply-To: <550C4125.5060008@fnal.gov> References: <550C4125.5060008@fnal.gov> Message-ID: <550C516C.3060808@gmail.com> On 20.03.2015 16:47, Chris Green wrote: > > The documentation doesn't suggest that this is intended behavior. Is > this a bug, or am I doing something wrong? The desired action does get > carried out during a build as desired, but there is no screen output > of COMMENT to herald the generation of the link. Assuming you are using one of the Makefile generators this might be fixed by: http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=eeb2831b5f35af1ec8a65be343e754ff1c29550d Which is in 3.2.1. Nils From greenc at fnal.gov Fri Mar 20 13:11:31 2015 From: greenc at fnal.gov (Christopher H Green) Date: Fri, 20 Mar 2015 17:11:31 +0000 Subject: [CMake] COMMENT ignored for POST_BUILD custom command? In-Reply-To: <550C516C.3060808@gmail.com> References: <550C4125.5060008@fnal.gov>,<550C516C.3060808@gmail.com> Message-ID: <1xvn1m4orgwsx8h6ladayly8.1426871488368@email.android.com> Indeed it might, thank you, but I believe I'm seeing the same behavior with ninja also. Thanks, Chris. Sent from my cell. -------- Original message -------- From: Nils Gladitz Date:2015/03/20 11:57 (GMT-06:00) To: Christopher H Green ,cmake at cmake.org Subject: Re: [CMake] COMMENT ignored for POST_BUILD custom command? On 20.03.2015 16:47, Chris Green wrote: > > The documentation doesn't suggest that this is intended behavior. Is > this a bug, or am I doing something wrong? The desired action does get > carried out during a build as desired, but there is no screen output > of COMMENT to herald the generation of the link. Assuming you are using one of the Makefile generators this might be fixed by: http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=eeb2831b5f35af1ec8a65be343e754ff1c29550d Which is in 3.2.1. Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.espak at ucl.ac.uk Fri Mar 20 13:40:56 2015 From: m.espak at ucl.ac.uk (Miklos Espak) Date: Fri, 20 Mar 2015 17:40:56 +0000 Subject: [CMake] how to create a custom dashboard? In-Reply-To: References: Message-ID: Found a solution by adding new functions to the API. See it here: https://github.com/espakm/CDash/commit/c12b2726a5a336b7b3a700ef3490ed4e54f6fd45 Any interest in merging this? Cheers, Miklos On 20 March 2015 at 13:43, Miklos Espak wrote: > I found it. You have to create a group on the CDash project admin > interface first, with the same name as what's specified after --track. It > is not very flexible, though. > > Is there a way to create groups via the command line? I could set up a git > hook to create the group when a new branch is pushed, or eventually removes > the group when the remote branch is deleted. > > Cheers, > Miklos > > > > > On 18 March 2015 at 12:25, Miklos Espak wrote: > >> ... different then "Nightly", "Continuous" and "Experimental"? >> >> I would like to have a dashboard per branch for continuous testing, so >> that we can track the changes in the individual branches independently. >> >> The --track option should be for that, I think, but could not get it >> working. >> >> I tried this: >> >> ctest -S CTestContinuous.cmake --track 4009-external-project-dir >> >> I also tried to specify the branch name as the parameter of ctest_start(). >> >> I attached the ctest script. The result always goes to the Continuous >> dashboard discarding the command line switch and the argument. >> >> Any idea? >> >> Cheers, >> Miklos >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From greenc at fnal.gov Fri Mar 20 14:41:34 2015 From: greenc at fnal.gov (Chris Green) Date: Fri, 20 Mar 2015 13:41:34 -0500 Subject: [CMake] COMMENT ignored for POST_BUILD custom command? In-Reply-To: <1xvn1m4orgwsx8h6ladayly8.1426871488368@email.android.com> References: <550C4125.5060008@fnal.gov>, <550C516C.3060808@gmail.com> <1xvn1m4orgwsx8h6ladayly8.1426871488368@email.android.com> Message-ID: <550C69DE.9000502@fnal.gov> On 3/20/15 12:11 PM, Christopher H Green wrote: > Indeed it might, thank you, but I believe I'm seeing the same behavior > with ninja also. I can confirm that with CMake 3.2.1, the expected COMMENT is printed with the UNIX Makefile generator, but not for the Ninja generator. Any chance of getting this fixed in an upcoming version? Several of our users are trying out Ninja, and liking what they see so far. Thanks, Chris. > Thanks, > Chris. > > > Sent from my cell. > > > -------- Original message -------- > From: Nils Gladitz > Date:2015/03/20 11:57 (GMT-06:00) > To: Christopher H Green ,cmake at cmake.org > Subject: Re: [CMake] COMMENT ignored for POST_BUILD custom command? > > On 20.03.2015 16:47, Chris Green wrote: > > > > The documentation doesn't suggest that this is intended behavior. Is > > this a bug, or am I doing something wrong? The desired action does get > > carried out during a build as desired, but there is no screen output > > of COMMENT to herald the generation of the link. > > Assuming you are using one of the Makefile generators this might be > fixed by: > http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=eeb2831b5f35af1ec8a65be343e754ff1c29550d > > Which is in 3.2.1. > > Nils > > -- Chris Green , FNAL CS/SCD/ADSS/SSI/TAC; 'phone (630) 840-2167; Skype: chris.h.green; IM: greenc at jabber.fnal.gov, chissgreen (AIM), chris.h.green (Google Talk). -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Fri Mar 20 15:10:58 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 20 Mar 2015 20:10:58 +0100 Subject: [CMake] COMMENT ignored for POST_BUILD custom command? In-Reply-To: <550C69DE.9000502@fnal.gov> References: <550C4125.5060008@fnal.gov>, <550C516C.3060808@gmail.com> <1xvn1m4orgwsx8h6ladayly8.1426871488368@email.android.com> <550C69DE.9000502@fnal.gov> Message-ID: <550C70C2.9050706@gmail.com> On 20.03.2015 19:41, Chris Green wrote: > On 3/20/15 12:11 PM, Christopher H Green wrote: >> Indeed it might, thank you, but I believe I'm seeing the same >> behavior with ninja also. > I can confirm that with CMake 3.2.1, the expected COMMENT is printed > with the UNIX Makefile generator, but not for the Ninja generator. Any > chance of getting this fixed in an upcoming version? Several of our > users are trying out Ninja, and liking what they see so far. > In the Makefile generators this was a regression but with the Ninja generator this seems to have never been implemented. CMake Ninja builds are much less verbose than CMake's Makefiles and I am personally quite fond of that fact. In a diagnostic free build (no warnings or errors) this often means a single line of output for the entire build. You could make this a feature request on the issue tracker though. Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: From greenc at fnal.gov Fri Mar 20 15:49:03 2015 From: greenc at fnal.gov (Chris Green) Date: Fri, 20 Mar 2015 14:49:03 -0500 Subject: [CMake] COMMENT ignored for POST_BUILD custom command? In-Reply-To: <550C70C2.9050706@gmail.com> References: <550C4125.5060008@fnal.gov>, <550C516C.3060808@gmail.com> <1xvn1m4orgwsx8h6ladayly8.1426871488368@email.android.com> <550C69DE.9000502@fnal.gov> <550C70C2.9050706@gmail.com> Message-ID: <550C79AF.9000500@fnal.gov> On 3/20/15 2:10 PM, Nils Gladitz wrote: > On 20.03.2015 19:41, Chris Green wrote: >> On 3/20/15 12:11 PM, Christopher H Green wrote: >>> Indeed it might, thank you, but I believe I'm seeing the same >>> behavior with ninja also. >> I can confirm that with CMake 3.2.1, the expected COMMENT is printed >> with the UNIX Makefile generator, but not for the Ninja generator. >> Any chance of getting this fixed in an upcoming version? Several of >> our users are trying out Ninja, and liking what they see so far. >> > > In the Makefile generators this was a regression but with the Ninja > generator this seems to have never been implemented. > > CMake Ninja builds are much less verbose than CMake's Makefiles and I > am personally quite fond of that fact. > In a diagnostic free build (no warnings or errors) this often means a > single line of output for the entire build. > > You could make this a feature request on the issue tracker though. Hi, Thanks for this. I'm in favor of brief myself, but if I've decided I want a message by using the mechanism provided for same, in general I'd like to see it. I'll put the issue in the tracker. Thanks again, Chris. > > Nils -- Chris Green , FNAL CS/SCD/ADSS/SSI/TAC; 'phone (630) 840-2167; Skype: chris.h.green; IM: greenc at jabber.fnal.gov, chissgreen (AIM), chris.h.green (Google Talk). -------------- next part -------------- An HTML attachment was scrubbed... URL: From fifteenknots505 at gmail.com Fri Mar 20 16:53:24 2015 From: fifteenknots505 at gmail.com (Martin Weber) Date: Fri, 20 Mar 2015 21:53:24 +0100 Subject: [CMake] C/C++ projects: Can cmake generate a '-include file' option for the compiler? Message-ID: <1469039.xpomvCFxRb@linux> Hi, is there a way in the cmakelists syntax to generate a build script (make/ninja/...) that will invoke the C/C++ compiler with an '-include file' or '-include macros' option? >From the GNU cpp man page: -include file Process file as if "#include "file"" appeared as the first line of the primary source file. ... -imacros file Exactly like -include, except that ... I do not really believe these options make any sense when using cmake (they seem to be GNU cc specific), but I am the author of an eclipse plugin that integrates cmake with eclipse CDT and have to parse the build output in order to feed the CDT indexer with macro definitions and include paths. I am asking, because I want to avoid writing parsers that detect the above compiler options. Are there any script generators that produce compiler invocation with the above otions? Or tool chains? TIA, Martin -- Quidquid latine dictum sit, altum viditur. From scott at towel42.com Fri Mar 20 19:05:08 2015 From: scott at towel42.com (Scott Aron Bloom) Date: Fri, 20 Mar 2015 23:05:08 +0000 Subject: [CMake] unit tests include in "all" but not install Message-ID: In general, I want unit tests, are build when I do a make all, but I really don't care if they are up to date for a install.. Is that a possibility? Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From scott at towel42.com Fri Mar 20 19:23:34 2015 From: scott at towel42.com (Scott Aron Bloom) Date: Fri, 20 Mar 2015 23:23:34 +0000 Subject: [CMake] unit tests include in "all" but not install In-Reply-To: References: Message-ID: For those who couldn't understand my jibberish.. I apologize, never send email from a phone... Ill restate... In general, I want all my unit tests to be built when I do a make all, but I really don't care if they are up to date for a make install. Is that a possibility? Ie, add the exclude from all attribute, that is really an exclude from install? Scott From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Scott Aron Bloom Sent: Friday, March 20, 2015 16:05 PM To: CMake ML Subject: [CMake] unit tests include in "all" but not install In general, I want unit tests, are build when I do a make all, but I really don't care if they are up to date for a install.. Is that a possibility? Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Sat Mar 21 03:23:25 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Sat, 21 Mar 2015 08:23:25 +0100 Subject: [CMake] unit tests include in "all" but not install In-Reply-To: References: Message-ID: <550D1C6D.6040603@gmail.com> On 21.03.2015 00:23, Scott Aron Bloom wrote: > > For those who couldn?t understand my jibberish.. I apologize, never > send email from a phone? > > Ill restate? > > In general, I want all my unit tests to be built when I do a make all, > but I really don?t care if they are up to date for a make install. > > Is that a possibility? Ie, add the exclude from all attribute, that > is really an exclude from install? > You can remove the "all" dependency from "install" with: http://www.cmake.org/cmake/help/v3.2/variable/CMAKE_SKIP_INSTALL_ALL_DEPENDENCY.html But I don't think there is anything to add dependencies back to the "install" target. Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Sat Mar 21 07:19:44 2015 From: DLRdave at aol.com (David Cole) Date: Sat, 21 Mar 2015 07:19:44 -0400 Subject: [CMake] unit tests include in "all" but not install In-Reply-To: <550D1C6D.6040603@gmail.com> References: <550D1C6D.6040603@gmail.com> Message-ID: "In general, I want all my unit tests to be built when I do a make all, but I really don?t care if they are up to date for a make install." Are you sure you don't care? If your unit tests are out-of-date with respect to what you are installing, and you have not run them against what you are installing .... then how do you have confidence that what you are installing is acceptable? Just sayin'... On Sat, Mar 21, 2015 at 3:23 AM, Nils Gladitz wrote: > On 21.03.2015 00:23, Scott Aron Bloom wrote: > > For those who couldn?t understand my jibberish.. I apologize, never send > email from a phone? > > > > Ill restate? > > > > In general, I want all my unit tests to be built when I do a make all, but I > really don?t care if they are up to date for a make install. > > > > Is that a possibility? Ie, add the exclude from all attribute, that is > really an exclude from install? > > > You can remove the "all" dependency from "install" with: > > http://www.cmake.org/cmake/help/v3.2/variable/CMAKE_SKIP_INSTALL_ALL_DEPENDENCY.html > > But I don't think there is anything to add dependencies back to the > "install" target. > > 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 scott at towel42.com Sat Mar 21 10:07:25 2015 From: scott at towel42.com (Scott Aron Bloom) Date: Sat, 21 Mar 2015 14:07:25 +0000 Subject: [CMake] unit tests include in "all" but not install In-Reply-To: References: <550D1C6D.6040603@gmail.com>, Message-ID: <5jb2wdci6nn821xhr36836dd.1426946834393@email.android.com> I run make test separately .. I just don't want it to go through the dependency check for thr 600 unit tests.. --Scott -------- Original message -------- From: David Cole Date:03/21/2015 04:19 (GMT-08:00) To: Nils Gladitz Cc: Scott Aron Bloom , CMake ML Subject: Re: [CMake] unit tests include in "all" but not install "In general, I want all my unit tests to be built when I do a make all, but I really don?t care if they are up to date for a make install." Are you sure you don't care? If your unit tests are out-of-date with respect to what you are installing, and you have not run them against what you are installing .... then how do you have confidence that what you are installing is acceptable? Just sayin'... On Sat, Mar 21, 2015 at 3:23 AM, Nils Gladitz wrote: > On 21.03.2015 00:23, Scott Aron Bloom wrote: > > For those who couldn?t understand my jibberish.. I apologize, never send > email from a phone? > > > > Ill restate? > > > > In general, I want all my unit tests to be built when I do a make all, but I > really don?t care if they are up to date for a make install. > > > > Is that a possibility? Ie, add the exclude from all attribute, that is > really an exclude from install? > > > You can remove the "all" dependency from "install" with: > > http://www.cmake.org/cmake/help/v3.2/variable/CMAKE_SKIP_INSTALL_ALL_DEPENDENCY.html > > But I don't think there is anything to add dependencies back to the > "install" target. > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From scott at towel42.com Sat Mar 21 10:14:46 2015 From: scott at towel42.com (Scott Aron Bloom) Date: Sat, 21 Mar 2015 14:14:46 +0000 Subject: [CMake] unit tests include in "all" but not install In-Reply-To: <5jb2wdci6nn821xhr36836dd.1426946834393@email.android.com> References: <550D1C6D.6040603@gmail.com>, <5jb2wdci6nn821xhr36836dd.1426946834393@email.android.com> Message-ID: And here is the ironic part.. Make test, does NOT have a dependency to build all the tests... YET, make install does :( Personally, I want it the other way around, where make test, at least has each tests executable as a dependency, and makes sure they are not out of date before run... But make install, should just build the things being installed and THEIR dependencies, NOT the ALL dependency. Scott From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Scott Aron Bloom Sent: Saturday, March 21, 2015 7:07 AM To: David Cole; Nils Gladitz Cc: CMake ML Subject: Re: [CMake] unit tests include in "all" but not install I run make test separately .. I just don't want it to go through the dependency check for thr 600 unit tests.. --Scott -------- Original message -------- From: David Cole > Date:03/21/2015 04:19 (GMT-08:00) To: Nils Gladitz > Cc: Scott Aron Bloom >, CMake ML > Subject: Re: [CMake] unit tests include in "all" but not install "In general, I want all my unit tests to be built when I do a make all, but I really don't care if they are up to date for a make install." Are you sure you don't care? If your unit tests are out-of-date with respect to what you are installing, and you have not run them against what you are installing .... then how do you have confidence that what you are installing is acceptable? Just sayin'... On Sat, Mar 21, 2015 at 3:23 AM, Nils Gladitz > wrote: > On 21.03.2015 00:23, Scott Aron Bloom wrote: > > For those who couldn't understand my jibberish.. I apologize, never send > email from a phone... > > > > Ill restate... > > > > In general, I want all my unit tests to be built when I do a make all, but I > really don't care if they are up to date for a make install. > > > > Is that a possibility? Ie, add the exclude from all attribute, that is > really an exclude from install? > > > You can remove the "all" dependency from "install" with: > > http://www.cmake.org/cmake/help/v3.2/variable/CMAKE_SKIP_INSTALL_ALL_DEPENDENCY.html > > But I don't think there is anything to add dependencies back to the > "install" target. > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From damian.philipp at gmx.net Sun Mar 22 03:48:47 2015 From: damian.philipp at gmx.net (Damian Philipp) Date: Sun, 22 Mar 2015 08:48:47 +0100 Subject: [CMake] Unreliable Find*.conf In-Reply-To: <3794191.j7vfQALC86@caliban.sf-tec.de> References: <550919D0.7070000@gmx.net> <3794191.j7vfQALC86@caliban.sf-tec.de> Message-ID: <550E73DF.506@gmx.net> Hello cmake-experts, Am 18.03.15 um 07:59 schrieb Rolf Eike Beer: > Use find_library() to find the library itself. If you really need the library > directory (you probably don't) then use get_filename_component() on the library > location returned by find_library(). thank you, this helped. I now have the find-module working to create Makefiles on OSX. I have published the intermediate result on github so others can use this find-module. You can find it at https://github.com/deltaphi/Findts3sdk.cmake/ However, all is not well in Findts3sdk-land (apart from the "creative" directory layout already critisized in another mail). As a next step, I want to make the find-module on Windows. I already toyed around with it a bit, but ran into the dll/lib-problem for Visual Studio pretty soon. For those from the future, coming to read this email, this is the file i'm talking about: https://github.com/deltaphi/Findts3sdk.cmake/blob/764580d4e0ad9d73a842838939259734479eff6d/Findts3sdk.cmake What works: find_library() picks up the .lib-file to be used and I can successefully compile and link my project. What doesn't work: To run my project, I need to copy the .dll next to my executable. I made my find-module set ts3sdk_LIBRARY_FILES to a list of the library files and used add_custom_command(...POST_BUILD...) in my main project file to copy the files. However, to copy something, you need it's source path, which I obtain from find_library() on Non-Windows systems. On Windows, find_library() gives me the .lib-file only. I understand that this is the correct behavior for find_library(), but is there another way to find the .dll-file? I gather that find_file() might help, but that doesn't have the same magic of detecting library filenames as find_library() has. Regards, Damian Philipp From damian.philipp at gmx.net Sun Mar 22 04:41:48 2015 From: damian.philipp at gmx.net (Damian Philipp) Date: Sun, 22 Mar 2015 09:41:48 +0100 Subject: [CMake] Unreliable Find*.conf In-Reply-To: <37AE6A17-D5E4-4BC3-B060-E0DAF441AEA4@hendrik-sattler.de> References: <550919D0.7070000@gmx.net> <37AE6A17-D5E4-4BC3-B060-E0DAF441AEA4@hendrik-sattler.de> Message-ID: <550E804C.9030705@gmx.net> Hello, Am 18.03.15 um 13:28 schrieb Hendrik Sattler: > CMAKE_PREFIX_PATH is possibly a list so the above does not always work. > IIRC Just use > PATH_SUFFIXES bin > instead. > And use find_ library() instead. I wanted to test this, but for some reason cmake suddenly finds everything without any hint in the find-module, so long as I set CMAKE_PATH_PREFIX. I erased all cmake-caches I could find from the source tree and switched to out-of-source build - but still, cmake can find the TS3 library on its own. Is there some hidden cache elsewhere that I need to erase? Regards, Damian Philipp From roolebo at gmail.com Sun Mar 22 07:49:20 2015 From: roolebo at gmail.com (Roman Bolshakov) Date: Sun, 22 Mar 2015 14:49:20 +0300 Subject: [CMake] List all binaries associated with a target. In-Reply-To: References: Message-ID: > > Unfortunately, if my understanding is correct, > this code cannot work with external dependencies as they are not targets. It should work with external dependencies which are imported targets. You just need to check IMPORTED property is True and then you can extract precise location from IMPORTED_LOCATION property. It will also work for full paths which are used in target_link_libraries, you will need to check that the file exists and then add it into DEPENDENCY_LIST property. -------------- next part -------------- An HTML attachment was scrubbed... URL: From roolebo at gmail.com Sun Mar 22 08:22:22 2015 From: roolebo at gmail.com (Roman Bolshakov) Date: Sun, 22 Mar 2015 15:22:22 +0300 Subject: [CMake] List all binaries associated with a target. In-Reply-To: References: Message-ID: 2015-03-16 23:22 GMT+03:00 Klaim - Jo?l Lamotte : > Then you can invoke top-level cmake_install.cmake to install a subset >> of your project: >> DESTDIR=/destination/install/path cmake -DCOMPONENT=A -P >> cmake_install.cmake >> >> > It is not clear to me how all this would help installing automatically a > library and it's dependencies > when I modify then build the library. > If my understanding is correct, all this need to be triggered by cmake > install command, right? > Also, the main issue is gathering binaries so that they can be debugged on > windows (as you > point later) without having to move files around, in particular > dependencies binaries that > can and will change through developement. > cmake install is not completely automatic (you need to define install commands for dependencies and all targets explicitly) and is, indeed, a separate step from build. If you're fine with explicit definition of dependencies you might consider to tether build and install by an external script. It would kick off build and if it succeeds it would proceed to the cmake install-based pre-test packaging and start testing after then. -------------- next part -------------- An HTML attachment was scrubbed... URL: From soeren.textor at ditec-gmbh.de Mon Mar 23 08:39:59 2015 From: soeren.textor at ditec-gmbh.de (=?UTF-8?B?IkRyLiBTw7ZyZW4gVGV4dG9yIg==?=) Date: Mon, 23 Mar 2015 13:39:59 +0100 Subject: [CMake] compile flags per configuration in 3.2? Message-ID: <5510099F.3070908@ditec-gmbh.de> Hello Since cmake 2.0 I would like to have the possibilty to add compile flags for certain configurations. For linker flags it runs very well with set_targer_properties and LINK_FLAGS_. But that doesn't wokr for the compile flags. Exits a possibility in 3.2 meanwhile? Best regards, SirAnn -------------- next part -------------- An HTML attachment was scrubbed... URL: From soeren.textor at ditec-gmbh.de Mon Mar 23 09:11:54 2015 From: soeren.textor at ditec-gmbh.de (=?windows-1252?Q?=22Dr=2E_S=F6ren_Textor=22?=) Date: Mon, 23 Mar 2015 14:11:54 +0100 Subject: [CMake] compile flags per configuration in 3.2? In-Reply-To: References: <5510099F.3070908@ditec-gmbh.de> Message-ID: <5510111A.3020400@ditec-gmbh.de> No, you are dealing with the global flag. But that's not the way I want to go, because I have several targets and need serveral compile flags for each target Am 23.03.2015 um 14:03 schrieb Parag Chandra: > Have you looked at CMAKE__FLAGS_, e.g. > > http://www.cmake.org/cmake/help/v3.1/variable/CMAKE_LANG_FLAGS_DEBUG.html > > I?ve been using these for exactly the purpose you describe. > > > > > *Parag Chandra > *Senior Software Engineer, Mobile Team > Mobile: +1.919.824.1410 > > > > Ionic Security Inc. > 1170 Peachtree St. NE STE 400, Atlanta, GA 30309 > > > > > > > > > > > From: "Dr. S?ren Textor" > > Organization: DiTEC GmbH > Date: Monday, March 23, 2015 at 8:39 AM > To: "cmake at cmake.org " > > Subject: [CMake] compile flags per configuration in 3.2? > > Hello > Since cmake 2.0 I would like to have the possibilty to add compile > flags for certain configurations. > > For linker flags it runs very well with set_targer_properties and > LINK_FLAGS_. But that doesn't wokr for the compile flags. > > Exits a possibility in 3.2 meanwhile? > > Best regards, > SirAnn > > -- Dr.-Ing. S?ren Textor Softwareentwicklung phone | +49 6221 31698 225 fax | +49 6221 31698 399 email | s.textor at ditec-gmbh.de web | http://www.ditec-gmbh.de DiTEC Dr. Siegfried Kahlich & Dierk Langer GmbH Im Breitspiel 19 | 69126 Heidelberg | Germany Handelsregister | Mannheim | HRB 341229 Dieses Dokument ist vertraulich zu behandeln. Die Weitergabe, sowie Vervielf?ltigung, Verwertung und Mitteilung seines Inhalts ist nur mit unserer ausdr?cklichen Genehmigung gestattet. Alle Rechte vorbehalten, insbesondere f?r den Fall der Schutzrechtsanmeldung. This document has to be treated confidentially. Its contents are not to be passed on, duplicated, exploited or disclosed without our express permission. All rights reserved, especially the right to apply for protective rights. -------------- next part -------------- An HTML attachment was scrubbed... URL: From parag at ionicsecurity.com Mon Mar 23 09:17:33 2015 From: parag at ionicsecurity.com (Parag Chandra) Date: Mon, 23 Mar 2015 13:17:33 +0000 Subject: [CMake] compile flags per configuration in 3.2? In-Reply-To: <5510111A.3020400@ditec-gmbh.de> References: <5510099F.3070908@ditec-gmbh.de> <5510111A.3020400@ditec-gmbh.de> Message-ID: In that case, you may want to play around with COMPILE_OPTIONS, which is target-specific, and generator expressions: http://www.cmake.org/cmake/help/v3.1/prop_tgt/COMPILE_OPTIONS.html http://www.cmake.org/cmake/help/v3.1/manual/cmake-generator-expressions.7.html#manual:cmake-generator-expressions(7) One of the generator expressions available to you is the current configuration, so you may be able to conditionally add specific flags for each configuration. Parag Chandra Senior Software Engineer, Mobile Team Mobile: +1.919.824.1410 [https://www.ionicsecurity.com/IonicSigHz.png] Ionic Security Inc. 1170 Peachtree St. NE STE 400, Atlanta, GA 30309 From: "Dr. S?ren Textor" > Organization: DiTEC GmbH Date: Monday, March 23, 2015 at 9:11 AM To: "cmake at cmake.org" > Subject: Re: [CMake] compile flags per configuration in 3.2? No, you are dealing with the global flag. But that's not the way I want to go, because I have several targets and need serveral compile flags for each target Am 23.03.2015 um 14:03 schrieb Parag Chandra: Have you looked at CMAKE__FLAGS_, e.g. http://www.cmake.org/cmake/help/v3.1/variable/CMAKE_LANG_FLAGS_DEBUG.html I've been using these for exactly the purpose you describe. Parag Chandra Senior Software Engineer, Mobile Team Mobile: +1.919.824.1410 [https://www.ionicsecurity.com/IonicSigHz.png] Ionic Security Inc. 1170 Peachtree St. NE STE 400, Atlanta, GA 30309 From: "Dr. S?ren Textor" > Organization: DiTEC GmbH Date: Monday, March 23, 2015 at 8:39 AM To: "cmake at cmake.org" > Subject: [CMake] compile flags per configuration in 3.2? Hello Since cmake 2.0 I would like to have the possibilty to add compile flags for certain configurations. For linker flags it runs very well with set_targer_properties and LINK_FLAGS_. But that doesn't wokr for the compile flags. Exits a possibility in 3.2 meanwhile? Best regards, SirAnn -- Dr.-Ing. S?ren Textor Softwareentwicklung phone | +49 6221 31698 225 fax | +49 6221 31698 399 email | s.textor at ditec-gmbh.de web | http://www.ditec-gmbh.de DiTEC Dr. Siegfried Kahlich & Dierk Langer GmbH Im Breitspiel 19 | 69126 Heidelberg | Germany Handelsregister | Mannheim | HRB 341229 Dieses Dokument ist vertraulich zu behandeln. Die Weitergabe, sowie Vervielf?ltigung, Verwertung und Mitteilung seines Inhalts ist nur mit unserer ausdr?cklichen Genehmigung gestattet. Alle Rechte vorbehalten, insbesondere f?r den Fall der Schutzrechtsanmeldung. This document has to be treated confidentially. Its contents are not to be passed on, duplicated, exploited or disclosed without our express permission. All rights reserved, especially the right to apply for protective rights. -------------- next part -------------- An HTML attachment was scrubbed... URL: From parag at ionicsecurity.com Mon Mar 23 09:03:16 2015 From: parag at ionicsecurity.com (Parag Chandra) Date: Mon, 23 Mar 2015 13:03:16 +0000 Subject: [CMake] compile flags per configuration in 3.2? In-Reply-To: <5510099F.3070908@ditec-gmbh.de> References: <5510099F.3070908@ditec-gmbh.de> Message-ID: Have you looked at CMAKE__FLAGS_, e.g. http://www.cmake.org/cmake/help/v3.1/variable/CMAKE_LANG_FLAGS_DEBUG.html I've been using these for exactly the purpose you describe. Parag Chandra Senior Software Engineer, Mobile Team Mobile: +1.919.824.1410 [https://www.ionicsecurity.com/IonicSigHz.png] Ionic Security Inc. 1170 Peachtree St. NE STE 400, Atlanta, GA 30309 From: "Dr. S?ren Textor" > Organization: DiTEC GmbH Date: Monday, March 23, 2015 at 8:39 AM To: "cmake at cmake.org" > Subject: [CMake] compile flags per configuration in 3.2? Hello Since cmake 2.0 I would like to have the possibilty to add compile flags for certain configurations. For linker flags it runs very well with set_targer_properties and LINK_FLAGS_. But that doesn't wokr for the compile flags. Exits a possibility in 3.2 meanwhile? Best regards, SirAnn -------------- next part -------------- An HTML attachment was scrubbed... URL: From MillerHenry at JohnDeere.com Mon Mar 23 09:44:22 2015 From: MillerHenry at JohnDeere.com (Miller Henry) Date: Mon, 23 Mar 2015 13:44:22 +0000 Subject: [CMake] unit tests include in "all" but not install In-Reply-To: References: Message-ID: <35F6921410093E4CA40D524BD5C18D4C268743A8@EDXMB57.jdnet.deere.com> I have setup our unit tests to output a junit report, and the junit report is what is in the all target. Thus my unit tests don't run on a make install if they have run during the original make. If anything was rebuilt during the make install only the affected tests are run. This of course depends on your test framework having the ability to create an output file. (but there are enough useful things to do from a junit output that I suggest you should refuse a framework that doesn't) From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Scott Aron Bloom Sent: Friday, March 20, 2015 6:24 PM To: Scott Aron Bloom; CMake ML Subject: Re: [CMake] unit tests include in "all" but not install For those who couldn't understand my jibberish.. I apologize, never send email from a phone... Ill restate... In general, I want all my unit tests to be built when I do a make all, but I really don't care if they are up to date for a make install. Is that a possibility? Ie, add the exclude from all attribute, that is really an exclude from install? Scott From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Scott Aron Bloom Sent: Friday, March 20, 2015 16:05 PM To: CMake ML Subject: [CMake] unit tests include in "all" but not install In general, I want unit tests, are build when I do a make all, but I really don't care if they are up to date for a install.. Is that a possibility? Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From scott at towel42.com Mon Mar 23 11:11:57 2015 From: scott at towel42.com (Scott Aron Bloom) Date: Mon, 23 Mar 2015 15:11:57 +0000 Subject: [CMake] unit tests include in "all" but not install In-Reply-To: <35F6921410093E4CA40D524BD5C18D4C268743A8@EDXMB57.jdnet.deere.com> References: <35F6921410093E4CA40D524BD5C18D4C268743A8@EDXMB57.jdnet.deere.com> Message-ID: I use google test, which can output XML/Junit style (we have another reporting system, so junit isn't necessary).. However, what "Cmake" rules do you use to have to have the test dependent on the output file, and not the running of the test? Scott From: Miller Henry [mailto:MillerHenry at JohnDeere.com] Sent: Monday, March 23, 2015 6:44 AM To: Scott Aron Bloom; CMake ML Subject: RE: unit tests include in "all" but not install I have setup our unit tests to output a junit report, and the junit report is what is in the all target. Thus my unit tests don't run on a make install if they have run during the original make. If anything was rebuilt during the make install only the affected tests are run. This of course depends on your test framework having the ability to create an output file. (but there are enough useful things to do from a junit output that I suggest you should refuse a framework that doesn't) From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Scott Aron Bloom Sent: Friday, March 20, 2015 6:24 PM To: Scott Aron Bloom; CMake ML Subject: Re: [CMake] unit tests include in "all" but not install For those who couldn't understand my jibberish.. I apologize, never send email from a phone... Ill restate... In general, I want all my unit tests to be built when I do a make all, but I really don't care if they are up to date for a make install. Is that a possibility? Ie, add the exclude from all attribute, that is really an exclude from install? Scott From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Scott Aron Bloom Sent: Friday, March 20, 2015 16:05 PM To: CMake ML Subject: [CMake] unit tests include in "all" but not install In general, I want unit tests, are build when I do a make all, but I really don't care if they are up to date for a install.. Is that a possibility? Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From MillerHenry at JohnDeere.com Mon Mar 23 11:21:22 2015 From: MillerHenry at JohnDeere.com (Miller Henry) Date: Mon, 23 Mar 2015 15:21:22 +0000 Subject: [CMake] unit tests include in "all" but not install In-Reply-To: References: <35F6921410093E4CA40D524BD5C18D4C268743A8@EDXMB57.jdnet.deere.com> Message-ID: <35F6921410093E4CA40D524BD5C18D4C26874505@EDXMB57.jdnet.deere.com> Our tests are in a custom system, but I think you can figure from the snippet. ADD_CUSTOM_COMMAND( OUTPUT : ${testName}.xml DEPENDS ${TEST_EXECUTABLE} ... COMMAND ${TEST_EXECUTABLE} ARGS --gtest_output="xml:${testName}.xml" ) From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Scott Aron Bloom Sent: Monday, March 23, 2015 10:12 AM To: CMake ML Subject: Re: [CMake] unit tests include in "all" but not install I use google test, which can output XML/Junit style (we have another reporting system, so junit isn't necessary).. However, what "Cmake" rules do you use to have to have the test dependent on the output file, and not the running of the test? Scott From: Miller Henry [mailto:MillerHenry at JohnDeere.com] Sent: Monday, March 23, 2015 6:44 AM To: Scott Aron Bloom; CMake ML Subject: RE: unit tests include in "all" but not install I have setup our unit tests to output a junit report, and the junit report is what is in the all target. Thus my unit tests don't run on a make install if they have run during the original make. If anything was rebuilt during the make install only the affected tests are run. This of course depends on your test framework having the ability to create an output file. (but there are enough useful things to do from a junit output that I suggest you should refuse a framework that doesn't) From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Scott Aron Bloom Sent: Friday, March 20, 2015 6:24 PM To: Scott Aron Bloom; CMake ML Subject: Re: [CMake] unit tests include in "all" but not install For those who couldn't understand my jibberish.. I apologize, never send email from a phone... Ill restate... In general, I want all my unit tests to be built when I do a make all, but I really don't care if they are up to date for a make install. Is that a possibility? Ie, add the exclude from all attribute, that is really an exclude from install? Scott From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Scott Aron Bloom Sent: Friday, March 20, 2015 16:05 PM To: CMake ML Subject: [CMake] unit tests include in "all" but not install In general, I want unit tests, are build when I do a make all, but I really don't care if they are up to date for a install.. Is that a possibility? Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.turner at kdab.com Mon Mar 23 13:01:03 2015 From: james.turner at kdab.com (James Turner) Date: Mon, 23 Mar 2015 12:01:03 -0500 Subject: [CMake] Adding entries to the info.plist file for OS X .app bundles. In-Reply-To: <45CCDA7E-3BA0-40CF-A610-EAC962B0FE6E@bluequartz.net> References: <45CCDA7E-3BA0-40CF-A610-EAC962B0FE6E@bluequartz.net> Message-ID: <446BD529-2E85-4CFF-B92D-BB440E79DFCA@kdab.com> > On 20 Mar 2015, at 08:58, Michael Jackson wrote: > > to support Retina displays for our app. Should I just create my own template .plist file and use "configure_file" to add items into the file? You can do something like: # in our local CMakeModules dir add MyBundleInfo.plist.in in CMakeModules/ set_target_properties(myapp PROPERTIES MACOSX_BUNDLE_INFO_PLIST MyBundleInfo.plist.in) And it will be processed instead of the default. Of course you can set all the standard values too: set_target_properties(myapp PROPERTIES MACOSX_BUNDLE_GUI_IDENTIFIER ?com.foo.myapp?) Kind regards, James -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.bielik at dirac.se Tue Mar 24 05:04:31 2015 From: robert.bielik at dirac.se (Robert Bielik) Date: Tue, 24 Mar 2015 10:04:31 +0100 Subject: [CMake] Strip not working ? (Mac + makefiles) Message-ID: <5511289F.40109@dirac.se> Hi, I've a project (.app) where I use makefiles when building from cmd line, and I get a make target called "install/strip", however there's no stripping done. However, doing this manually by invoking strip on MyApp.app/Contents/MacOS/MyApp works just fine. Is strip by chance invoked on MyApp.app/ folder ? Regards /R From robert.bielik at dirac.se Tue Mar 24 05:17:05 2015 From: robert.bielik at dirac.se (Robert Bielik) Date: Tue, 24 Mar 2015 10:17:05 +0100 Subject: [CMake] Strip not working ? (Mac + makefiles) In-Reply-To: <5511289F.40109@dirac.se> References: <5511289F.40109@dirac.se> Message-ID: <55112B91.5050407@dirac.se> Indeed, seems like a bug in CMake. Looking at cmake_install.cmake for my project, there is no option for stripping. cmake_install.cmake is invoked as: /Applications/CMake.app/Contents/bin/cmake -DCMAKE_INSTALL_DO_STRIP=1 -P cmake_install.cmake I use CMake 3.0.1. /R Robert Bielik skrev den 2015-03-24 10:04: > Hi, > > I've a project (.app) where I use makefiles when building from cmd > line, and I get a make target called "install/strip", however there's > no stripping done. > > However, doing this manually by invoking strip on > MyApp.app/Contents/MacOS/MyApp works just fine. Is strip by chance > invoked on MyApp.app/ folder ? > > Regards > /R > From audrey.istace at imavie.fr Tue Mar 24 06:08:59 2015 From: audrey.istace at imavie.fr (Audrey Istace) Date: Tue, 24 Mar 2015 10:08:59 +0000 Subject: [CMake] Problem with shared libraries and python wrapping Message-ID: Hello, I am trying to compile a VTK class (which uses itk), and would like to make a python wrapping for this class too. I face two problems : - First, when I had the option < build_shared_libs > : OPTION(BUILD_SHARED_LIBS "Shared libraries." ON) The Makefile is generated, but when I compile my project, I get the following error that I don't understand : /usr/bin/ld: path/libitksys-4.8.a(SystemTools.cxx.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC Path/lib/libitksys-4.8.a: error adding symbols: Bad value collect2: error: ld returned 1 exit status - My second problem happens with python wrapping. When I try enabling it in my CMakeLists : VTK_WRAP_PYTHON3(${MODULE_NAME} WrapSOURCES ${LIB_SOURCES}) The Makefile is not generated when I run CMake, and I get the following error : Unknown CMake command "VTK_WRAP_PYTHON3". I compiled VTK (version 6.1) with the option PYTHON_WRAPPING ON. Can someone help me with those problems please ? Thank you, Audrey -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.bielik at dirac.se Tue Mar 24 07:35:34 2015 From: robert.bielik at dirac.se (Robert Bielik) Date: Tue, 24 Mar 2015 12:35:34 +0100 Subject: [CMake] Strip not working ? (Mac + makefiles) In-Reply-To: <55112B91.5050407@dirac.se> References: <5511289F.40109@dirac.se> <55112B91.5050407@dirac.se> Message-ID: <55114C06.5040101@dirac.se> Ok, I went with the Xcode generator instead. Then stripping works. /R Robert Bielik skrev den 2015-03-24 10:17: > Indeed, seems like a bug in CMake. Looking at cmake_install.cmake for > my project, there is no option for stripping. cmake_install.cmake is > invoked as: > > /Applications/CMake.app/Contents/bin/cmake -DCMAKE_INSTALL_DO_STRIP=1 > -P cmake_install.cmake > > I use CMake 3.0.1. > > /R > > Robert Bielik skrev den 2015-03-24 10:04: >> Hi, >> >> I've a project (.app) where I use makefiles when building from cmd >> line, and I get a make target called "install/strip", however there's >> no stripping done. >> >> However, doing this manually by invoking strip on >> MyApp.app/Contents/MacOS/MyApp works just fine. Is strip by chance >> invoked on MyApp.app/ folder ? >> >> Regards >> /R >> > From kgt at lanl.gov Tue Mar 24 13:32:05 2015 From: kgt at lanl.gov (Thompson, KT) Date: Tue, 24 Mar 2015 17:32:05 +0000 Subject: [CMake] Any way to append CMAKE_INSTALL_PREFIX with CMAKE_CFG_INTDIR? Message-ID: <0458DF31F610EF42BFC78C497E806C7B40FF2211@ECS-EXG-P-MB03.win.lanl.gov> Hi, For build tools like Visual Studio or Xcode, I would like to have CMAKE_INSTALL_PREFIX end with the build configuration type (Release, Debug, etc.) I tried to append CMAKE_INSTALL_PREFIX with ${CMAKE_CFG_INTDIR} or $ but those approaches didn?t work (The install directory had was a folder that ended with the string literal ?${configuration}?). Can anyone provide a recipe that allows me to run cmake once to generate a project and then toggle between Debug and Release in the build tool to generate separate installations in directories that have names that use the configuration type? Thanks! -kt Kelly (KT) Thompson -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.hoffman at kitware.com Tue Mar 24 14:17:31 2015 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Tue, 24 Mar 2015 14:17:31 -0400 Subject: [CMake] Problem with shared libraries and python wrapping In-Reply-To: References: Message-ID: <5511AA3B.8040605@kitware.com> On 3/24/2015 6:08 AM, Audrey Istace wrote: > Hello, > > I am trying to compile a VTK class (which uses itk), and would like to > make a python wrapping for this class too. > > I face two problems : > > -First, when I had the option ? build_shared_libs ? : > OPTION(BUILD_SHARED_LIBS "Shared libraries." ON) > > The Makefile is generated, but when I compile my project, I get the > following error that I don?t understand : > > /usr/bin/ld: path/libitksys-4.8.a(SystemTools.cxx.o): relocation > R_X86_64_32 against `.rodata.str1.1' can not be used when making a > shared object; recompile with -fPIC > ITK needs to be built shared as well. > Path/lib/libitksys-4.8.a: error adding symbols: Bad value > > collect2: error: ld returned 1 exit status > > -My second problem happens with python wrapping. When I try enabling it > in my CMakeLists : VTK_WRAP_PYTHON3(${MODULE_NAME} WrapSOURCES > ${LIB_SOURCES}) > > The Makefile is not generated when I run CMake, and I get the following > error : Unknown CMake command "VTK_WRAP_PYTHON3". > > I compiled VTK (version 6.1) with the option PYTHON_WRAPPING ON. > > Can someone help me with those problems please ? > This is a question for the VTK mailing list. But, "VTK_WRAP_PYTHON3" is a macro provided by VTK. You would need to include that macro to use it. -Bill From bill at classdesign.com Tue Mar 24 14:21:18 2015 From: bill at classdesign.com (Bill Somerville) Date: Tue, 24 Mar 2015 18:21:18 +0000 Subject: [CMake] How to execute an external project target as part of a standard target. In-Reply-To: <5502EEEB.8090303@classdesign.com> References: <5502EEEB.8090303@classdesign.com> Message-ID: <5511AB1E.2080801@classdesign.com> On 13/03/2015 14:06, Bill Somerville wrote: > Hi All, > > I have a superbuild style project consisting of a few external > projects. I wish to build the install target of one of them as part of > the install target of the parent project. I had it working by adding a > step target called install and adding a custom target to the parent > project that depends on the child step target. E.g. > > ExternalProject_Add (xxx > SVN_REPOSITORY ${xxx_repo} > CMAKE_ARGS > -D CMAKE_INSTALL_PATH= > INSTALL_DIR ${CMAKE_INSTALL_PREFIX} > STEP_TARGETS install) > > add_custom_target (install DEPENDS xxx-install) > > This arrangement allowed me to 'cmake --build . --target install' and > have the child project install target run. > > Now CMake complains about policy CMP0037, because I cannot define a > reserved target name, so it seems I cannot abuse the 'install' target > by adding extra dependencies any more. > > Is there a better way to link child and parent targets that doesn't > invoke this error? No replies on this one. Am I asking something that can't be done or am I missing something obvious? > > Regards > Bill Somerville. From DLRdave at aol.com Tue Mar 24 14:22:47 2015 From: DLRdave at aol.com (David Cole) Date: Tue, 24 Mar 2015 14:22:47 -0400 Subject: [CMake] Any way to append CMAKE_INSTALL_PREFIX with CMAKE_CFG_INTDIR? In-Reply-To: <0458DF31F610EF42BFC78C497E806C7B40FF2211@ECS-EXG-P-MB03.win.lanl.gov> References: <0458DF31F610EF42BFC78C497E806C7B40FF2211@ECS-EXG-P-MB03.win.lanl.gov> Message-ID: An "install" of a CMake based project is invoked something like this from within a generated Visual Studio project: cmake.exe -DBUILD_TYPE=$(Configuration) -P cmake_install.cmake If you dig into the (generated) cmake_install.cmake file, you'll see a chunk like this right near the top of the file: if(NOT DEFINED CMAKE_INSTALL_PREFIX) set(CMAKE_INSTALL_PREFIX "C:/Program Files (x86)/Tutorial") endif() One thing you could do is write your own custom install command that passes in a value of CMAKE_INSTALL_PREFIX with the per-configuration suffix you're looking for. cmake.exe -DBUILD_TYPE=${CMAKE_CFG_INTDIR} -DCMAKE_INSTALL_PREFIX=${CMAKE_INSTALL_PREFIX}${CMAKE_CFG_INTDIR} -P cmake_install.cmake HTH, David C. On Tue, Mar 24, 2015 at 1:32 PM, Thompson, KT wrote: > Hi, > > > > For build tools like Visual Studio or Xcode, I would like to have > CMAKE_INSTALL_PREFIX end with the build configuration type (Release, Debug, > etc.) I tried to append CMAKE_INSTALL_PREFIX with ${CMAKE_CFG_INTDIR} or > $ but those approaches didn?t work (The install directory had was a > folder that ended with the string literal ?${configuration}?). Can anyone > provide a recipe that allows me to run cmake once to generate a project and > then toggle between Debug and Release in the build tool to generate separate > installations in directories that have names that use the configuration > type? > > > > Thanks! > > > > -kt > > Kelly (KT) Thompson > > > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From DLRdave at aol.com Tue Mar 24 14:31:36 2015 From: DLRdave at aol.com (David Cole) Date: Tue, 24 Mar 2015 14:31:36 -0400 Subject: [CMake] How to execute an external project target as part of a standard target. In-Reply-To: <5511AB1E.2080801@classdesign.com> References: <5502EEEB.8090303@classdesign.com> <5511AB1E.2080801@classdesign.com> Message-ID: How about: add_custom_target(custom-install DEPENDS xxx-install) and cmake --build . --target custom-install ?? The problem is that you are adding a custom target with the name "install" which is one that CMake generates for you. (Names to be avoided are all, clean, install, package, help ... (maybe a few others?)) I think this whole process should be unnecessary anyway, because the install step of the ExternalProject runs as part of the overall build, even with just a "cmake --build ." -- doesn't it? HTH, David C. On Tue, Mar 24, 2015 at 2:21 PM, Bill Somerville wrote: > On 13/03/2015 14:06, Bill Somerville wrote: >> >> Hi All, >> >> I have a superbuild style project consisting of a few external projects. I >> wish to build the install target of one of them as part of the install >> target of the parent project. I had it working by adding a step target >> called install and adding a custom target to the parent project that depends >> on the child step target. E.g. >> >> ExternalProject_Add (xxx >> SVN_REPOSITORY ${xxx_repo} >> CMAKE_ARGS >> -D CMAKE_INSTALL_PATH= >> INSTALL_DIR ${CMAKE_INSTALL_PREFIX} >> STEP_TARGETS install) >> >> add_custom_target (install DEPENDS xxx-install) >> >> This arrangement allowed me to 'cmake --build . --target install' and have >> the child project install target run. >> >> Now CMake complains about policy CMP0037, because I cannot define a >> reserved target name, so it seems I cannot abuse the 'install' target by >> adding extra dependencies any more. >> >> Is there a better way to link child and parent targets that doesn't invoke >> this error? > > No replies on this one. Am I asking something that can't be done or am I > missing something obvious? >> >> >> Regards >> Bill Somerville. > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From bill at classdesign.com Tue Mar 24 15:00:12 2015 From: bill at classdesign.com (Bill Somerville) Date: Tue, 24 Mar 2015 19:00:12 +0000 Subject: [CMake] How to execute an external project target as part of a standard target. In-Reply-To: References: <5502EEEB.8090303@classdesign.com> <5511AB1E.2080801@classdesign.com> Message-ID: <5511B43C.4050506@classdesign.com> On 24/03/2015 18:31, David Cole wrote: Hi David, > How about: > > add_custom_target(custom-install DEPENDS xxx-install) > > and > > cmake --build . --target custom-install > > ?? OK that does work but I wanted the project to have a normal set of targets. The issue is that the ExternalProject in question is the actual purpose of the outer project but the outer project has some special targets that do extra stuff. For example it has a 'source' target that transforms the whole lot into a source tarball suitable for running on an isolated build machine like those used for building Linux packages. The same outer project CMakeLists.txt doubles as the CMakeLists.txt for that source package and build servers expect the "usual" targets to build the package contents. I don't want to dump the whole of the real project CMakeLists.txt into this superbuild script and that is a maintenance hazard due to the duplication. The other ExternalProjects that build required components rather neatly fetch from their respective repos unless the source tar ball is there already so they "just work" in this dual phase build process. > > The problem is that you are adding a custom target with the name > "install" which is one that CMake generates for you. (Names to be > avoided are all, clean, install, package, help ... (maybe a few > others?)) I understand that but it works without complaint before recent CMake versions. > > I think this whole process should be unnecessary anyway, because the > install step of the ExternalProject runs as part of the overall build, > even with just a "cmake --build ." -- doesn't it? Maybe, but I need to have the 'install' target run when I am running the custom 'source' target of the outer project. To get this all to hang together I had to set the EXCLUDE_FROM_ALL property to '1' of the ExternalProject in question so it doesn't install when running the default target. This is necessary because we don't want the install phase to run when running our custom targets as CMAKE_INSTALL_PREFIX is set to the outer project CMAKE_INSTALL_PREFIX i.e. we only want this ExternalProject to install when we run the outer 'install' target. Sorry this is a bit complex and I may not have been clear enough. The basic idea works beautifully with a relatively simple low maintenance superbuild project that wraps a cross platform project that cannot make a kit suitable for Linux packaging and cannot have conventional ExternalProjects for the prerequisites on Windows and Mac. All was well until CMake started complaining about something that works. > > > HTH, > David C. Regards Bill Somerville. > > On Tue, Mar 24, 2015 at 2:21 PM, Bill Somerville wrote: >> On 13/03/2015 14:06, Bill Somerville wrote: >>> Hi All, >>> >>> I have a superbuild style project consisting of a few external projects. I >>> wish to build the install target of one of them as part of the install >>> target of the parent project. I had it working by adding a step target >>> called install and adding a custom target to the parent project that depends >>> on the child step target. E.g. >>> >>> ExternalProject_Add (xxx >>> SVN_REPOSITORY ${xxx_repo} >>> CMAKE_ARGS >>> -D CMAKE_INSTALL_PATH= >>> INSTALL_DIR ${CMAKE_INSTALL_PREFIX} >>> STEP_TARGETS install) >>> >>> add_custom_target (install DEPENDS xxx-install) >>> >>> This arrangement allowed me to 'cmake --build . --target install' and have >>> the child project install target run. >>> >>> Now CMake complains about policy CMP0037, because I cannot define a >>> reserved target name, so it seems I cannot abuse the 'install' target by >>> adding extra dependencies any more. >>> >>> Is there a better way to link child and parent targets that doesn't invoke >>> this error? >> No replies on this one. Am I asking something that can't be done or am I >> missing something obvious? >>> >>> Regards >>> Bill Somerville. >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake From bill at classdesign.com Tue Mar 24 15:03:47 2015 From: bill at classdesign.com (Bill Somerville) Date: Tue, 24 Mar 2015 19:03:47 +0000 Subject: [CMake] How to execute an external project target as part of a standard target. In-Reply-To: <5511B43C.4050506@classdesign.com> References: <5502EEEB.8090303@classdesign.com> <5511AB1E.2080801@classdesign.com> <5511B43C.4050506@classdesign.com> Message-ID: <5511B513.3070802@classdesign.com> On 24/03/2015 19:00, Bill Somerville wrote: > Maybe, but I need to have the 'install' target run when I am running > the custom 'source' target of the outer project. Should have read: Maybe, but I need to have the 'install' target NOT run when I am running the custom 'source' target of the outer project. Regards Bill Somerville. From kgt at lanl.gov Tue Mar 24 15:58:41 2015 From: kgt at lanl.gov (Thompson, KT) Date: Tue, 24 Mar 2015 19:58:41 +0000 Subject: [CMake] Any way to append CMAKE_INSTALL_PREFIX with CMAKE_CFG_INTDIR? In-Reply-To: References: <0458DF31F610EF42BFC78C497E806C7B40FF2211@ECS-EXG-P-MB03.win.lanl.gov> Message-ID: <0458DF31F610EF42BFC78C497E806C7B40FF2342@ECS-EXG-P-MB03.win.lanl.gov> That solution works for me. Thanks for your help! -----Original Message----- From: David Cole [mailto:DLRdave at aol.com] Sent: Tuesday, March 24, 2015 12:23 PM To: Thompson, KT Cc: cmake at cmake.org Subject: Re: [CMake] Any way to append CMAKE_INSTALL_PREFIX with CMAKE_CFG_INTDIR? An "install" of a CMake based project is invoked something like this from within a generated Visual Studio project: cmake.exe -DBUILD_TYPE=$(Configuration) -P cmake_install.cmake If you dig into the (generated) cmake_install.cmake file, you'll see a chunk like this right near the top of the file: if(NOT DEFINED CMAKE_INSTALL_PREFIX) set(CMAKE_INSTALL_PREFIX "C:/Program Files (x86)/Tutorial") endif() One thing you could do is write your own custom install command that passes in a value of CMAKE_INSTALL_PREFIX with the per-configuration suffix you're looking for. cmake.exe -DBUILD_TYPE=${CMAKE_CFG_INTDIR} -DCMAKE_INSTALL_PREFIX=${CMAKE_INSTALL_PREFIX}${CMAKE_CFG_INTDIR} -P cmake_install.cmake HTH, David C. On Tue, Mar 24, 2015 at 1:32 PM, Thompson, KT wrote: > Hi, > > > > For build tools like Visual Studio or Xcode, I would like to have > CMAKE_INSTALL_PREFIX end with the build configuration type (Release, Debug, > etc.) I tried to append CMAKE_INSTALL_PREFIX with ${CMAKE_CFG_INTDIR} or > $ but those approaches didn?t work (The install directory had was a > folder that ended with the string literal ?${configuration}?). Can anyone > provide a recipe that allows me to run cmake once to generate a project and > then toggle between Debug and Release in the build tool to generate separate > installations in directories that have names that use the configuration > type? > > > > Thanks! > > > > -kt > > Kelly (KT) Thompson > > > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From j.s4403 at gmail.com Tue Mar 24 16:00:18 2015 From: j.s4403 at gmail.com (j s) Date: Tue, 24 Mar 2015 15:00:18 -0500 Subject: [CMake] Mac OS X : Mixing C++/Fortran Message-ID: What C++/Fortran compiler combinations does cmake support for Mac OS X? My default C++ compiler is the compiler which comes with the mac developer tools. My main application would be a scientific/numerical application. What runtime libraries would need to be distributed with the application? Would static linking be an option? From mjklaim at gmail.com Tue Mar 24 20:00:44 2015 From: mjklaim at gmail.com (=?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?=) Date: Wed, 25 Mar 2015 01:00:44 +0100 Subject: [CMake] List all binaries associated with a target. In-Reply-To: References: Message-ID: On Sun, Mar 22, 2015 at 12:49 PM, Roman Bolshakov wrote: > Unfortunately, if my understanding is correct, >> this code cannot work with external dependencies as they are not targets. > > > It should work with external dependencies which are imported targets. You > just need to check IMPORTED property is True and then you can extract > precise location from IMPORTED_LOCATION property. It will also work for > full paths which are used in target_link_libraries, you will need to check > that the file exists and then add it into DEPENDENCY_LIST property. > Sorry but I don't understand what you mean, I think I'm confused maybe because I don't understand some details. My understanding is that IMPORTED is usable as an option when you defined a target, so that you can use it later as a dependency or command, manually setting it's prorties yourself. Now, in my case I have dependencies that I get using the find_package() function, some modules being provided by CMake, others not. When using find_package(), no target is created. So how should I check the IMPORTED property of dependencies tracked this way? Could you give me an example to clarify? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mjklaim at gmail.com Tue Mar 24 20:09:36 2015 From: mjklaim at gmail.com (=?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?=) Date: Wed, 25 Mar 2015 01:09:36 +0100 Subject: [CMake] List all binaries associated with a target. In-Reply-To: References: Message-ID: On Sun, Mar 22, 2015 at 1:22 PM, Roman Bolshakov wrote: > 2015-03-16 23:22 GMT+03:00 Klaim - Jo?l Lamotte : > >> Then you can invoke top-level cmake_install.cmake to install a subset >>> of your project: >>> DESTDIR=/destination/install/path cmake -DCOMPONENT=A -P >>> cmake_install.cmake >>> >>> >> It is not clear to me how all this would help installing automatically a >> library and it's dependencies >> when I modify then build the library. >> If my understanding is correct, all this need to be triggered by cmake >> install command, right? >> Also, the main issue is gathering binaries so that they can be debugged >> on windows (as you >> point later) without having to move files around, in particular >> dependencies binaries that >> can and will change through developement. >> > cmake install is not completely automatic (you need to define install > commands for dependencies and all targets explicitly) and is, indeed, a > separate step from build. If you're fine with explicit definition of > dependencies you might consider to tether build and install by an external > script. It would kick off build and if it succeeds it would proceed to the > cmake install-based pre-test packaging and start testing after then. > But then it would be an issue with debugging, which is what I am trying to fix here. If I compile only one target I don't need to install everything, just the changed binaries after compilation of the target and linking it's dependencies. It looks to me that at least on windows there is a missing feature in CMake to trigger that and it makes debugging painful without an external script doing the job. That script needs to know things that CMake knows but must be run post-build time, which is what I was doing until recently. The script is non-trivial because it needs to know which paths are the dependencies and the target, depending on the build (tbb.dll vs tbb_debug.dll) and either it have some table somewhere with the paths (unflexible but work if you have a fixed dependencies package) or it needs to guess it (impossible) or it needs to be feed with these paths (from CMake, which is what I am trying to attempt but am failing). After searching a lot online and trying different alternatives I am not satisfied with any solution. I also asked to our build system (using cmake) specialist in the company I work for and there seem to be no good solution. -------------- next part -------------- An HTML attachment was scrubbed... URL: From h.sorby at auckland.ac.nz Tue Mar 24 23:03:47 2015 From: h.sorby at auckland.ac.nz (Hugh Sorby) Date: Wed, 25 Mar 2015 16:03:47 +1300 Subject: [CMake] Fortran project compiling with -isystem causing error Message-ID: <55122593.3010703@auckland.ac.nz> Hi All, I am trying to create a simple Fortran project that relies on a module file that has been built by another project. I have added the directory containing the module file into the include_directories command but the project isn't compiling and raises an error can't find module. The directory that I want to include shows up in the compile command but it is prefixed with -isystem if I change this manually to -I (capital i) then the project compiles successfully. As I understand it the -isystem should be used for includes to be considered as system includes, but I haven't specified this in my include_directories command. I don't understand what is going on I am expecting to see -I /path/to/my/module and not -isystem /path/to/my/module. Any help is appreciated, Cheers, Hugh. From masariello+cmake.org at gmail.com Wed Mar 25 05:56:49 2015 From: masariello+cmake.org at gmail.com (Alessio) Date: Wed, 25 Mar 2015 09:56:49 +0000 Subject: [CMake] CDash and xUnit test reports Message-ID: Hi All Quick question: is there a way to add test detail to the CDash dashboard that comes from xunit XML test report files? The tests we configure in ctest are actually fairly fat containers of Boost Test Framework and Python nose tests, so the vanilla ctest report would not provide the team with enough detail. Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: From vaishakhj at hotmail.com Wed Mar 25 07:37:32 2015 From: vaishakhj at hotmail.com (Vaishakh) Date: Wed, 25 Mar 2015 11:37:32 +0000 (UTC) Subject: [CMake] an easy way to clean cmake generated files? References: <47E76B8F.6050506@tyrell.hu> <47E8F3F3.4040505@bic.mni.mcgill.ca> Message-ID: git clean -d -f -x From rleigh at codelibre.net Wed Mar 25 10:15:30 2015 From: rleigh at codelibre.net (Roger Leigh) Date: Wed, 25 Mar 2015 14:15:30 +0000 Subject: [CMake] Behaviour of CACHE PATH variables Message-ID: <20150325141530.GA14959@codelibre.net> Hi folks, I've come across some odd behaviour when setting CACHE variables of type PATH, which I didn't spot in the documentation. With the following minimal testcase: ----------------------------------------------------------- cmake_minimum_required(VERSION 2.8.12) cmake_policy(VERSION 2.8.12) include(GNUInstallDirs) if (NOT DEFINED TESTDIR1) set(TESTDIR1 "test1" CACHE PATH "Test path 1") endif() set(TESTDIR2 "test2" CACHE PATH "Test path 2") message(STATUS "sbindir: ${CMAKE_INSTALL_SBINDIR}") message(STATUS "testdir1: ${TESTDIR1}") message(STATUS "testdir2: ${TESTDIR2}") ----------------------------------------------------------- % cmake .. -- sbindir: sbin -- testdir1: test1 -- testdir2: test2 % cmake -DTESTDIR1=t1 -DTESTDIR2=t2 -DCMAKE_INSTALL_SBINDIR=priv .. -- sbindir: priv -- testdir1: t1 -- testdir2: /home/rleigh/pathtest/test/t2 % cmake -DTESTDIR1:PATH=t1 -DTESTDIR2:PATH=t2 -DCMAKE_INSTALL_SBINDIR=priv .. -- sbindir: priv -- testdir1: t1 -- testdir2: t2 This is with cmake 2.8.12.2 (Linux); same behaviour with 3.1.3 (FreeBSD). Question: Why is TESTDIR2 transformed from "t2" to "/home/rleigh/pathtest/test/t2" (which is "$PROJECT_BINARY_DIR/$TESTDIR2)? This behaviour seems quite undesirable and also inconsistent: - It's originally set using a relative path with "set(foo CACHE PATH)", and is not canonicalised to an absolute path - If I set it with :PATH using a relative path, it's also not canonicalised to an absolute path - BUT, if I use "set(foo CACHE PATH)" AND I previously set the path *without* a :type specifier (i.e. UNINITIALIZED) then this unwanted conversion takes place. Since the cache variable was already set, I would have expected this to be a no-op. Given the behaviour in the above two points, I can't see why this is happening. Copying the GNUInstallDirs behaviour of wrapping in an "if (NOT DEFINED foo)" test mitigates the problem. For my usage, I'm defining project-specific install dirs derived from the toplevel GNUInstallDirs dirs. I'd quite like to be able to specify a relative (or absolute) path, and then later prepend the install prefix / appropriate GNUInstallDirs toplevel variable. Having the current working directory added by default screws this up quite badly! Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 From rleigh at codelibre.net Wed Mar 25 10:44:44 2015 From: rleigh at codelibre.net (Roger Leigh) Date: Wed, 25 Mar 2015 14:44:44 +0000 Subject: [CMake] Check whether C++ headers are self-sufficient In-Reply-To: <55042749.7040106@grueninger.de> References: <55042749.7040106@grueninger.de> Message-ID: <20150325144444.GB14959@codelibre.net> On Sat, Mar 14, 2015 at 01:19:21PM +0100, Christoph Gr?ninger wrote: > Dear CMakers, > I want to have all my C++ headers self-sufficient (self-contained), > i.e., a header can be included without additional includes. This is not > only handy but also part of Google's C++ styleguide [2]. > > It would be great to have a make target (let's call it headercheck), > that can check for this, by compiling a simple test.cc file for each > current_header.h: > #include > #include "current_header.h" > #include "current_header.h" > > Additionally it would be great to have such a target for every folder > (checking all headers recursively) and every header that is explicitly > passed as an argument. > > We tried this with CMake: We generate a test.cc file per header and > create a library for every cc file. The problem is, that we get hundreds > of additional targets, we generate a lot of folders and files which can > increase our build directory size by an order of magnitude and it does > not work properly on a per file or per directory basis. I've taken exactly your approach. However: - I'm not testing the double include at present - I generate a single target per library, collecting all the object files into a single testcase - I compile each header *twice*, so in addition to catching errors in the include guards, I also catch errors where I might have accidentally defined a global or static member in the header and this will trigger a link error For anyone two wants to reuse it: https://github.com/openmicroscopy/bioformats/blob/develop/cpp/cmake/HeaderTest.cmake (it uses gtest but that's easily excised if not required) To use, in your source directory: https://github.com/openmicroscopy/bioformats/blob/develop/cpp/lib/ome/bioformats/CMakeLists.txt#L182 header_include_list_write(STATIC_HEADERS_VAR GENERATED_HEADERS_VAR header-test-name dest-dir) And in your test directory (if different) https://github.com/openmicroscopy/bioformats/blob/develop/cpp/test/ome-bioformats/CMakeLists.txt#L45 header_test_from_file(bin-name library-name test-name) While these were written for this particular project, if there's interest in having a similar thing in cmake, I'd be happy to clean it up and improve it for general use. Kind regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 From bill.hoffman at kitware.com Wed Mar 25 10:56:57 2015 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Wed, 25 Mar 2015 10:56:57 -0400 Subject: [CMake] an easy way to clean cmake generated files? In-Reply-To: References: <47E76B8F.6050506@tyrell.hu> <47E8F3F3.4040505@bic.mni.mcgill.ca> Message-ID: <5512CCB9.7090303@kitware.com> On 3/25/2015 7:37 AM, Vaishakh wrote: > git clean -d -f -x Build out of source. rm -rf -Bill -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 bill.hoffman at kitware.com http://www.kitware.com 518 881-4905 (Direct) 518 371-3971 x105 Fax (518) 371-4573 From brad.king at kitware.com Wed Mar 25 11:08:57 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 25 Mar 2015 11:08:57 -0400 Subject: [CMake] nonstandard C++ source filename extension In-Reply-To: References: Message-ID: On Tue, Mar 17, 2015 at 12:10 AM, Dave Yost wrote: > set_source_files_properties(foo.bar PROPERTIES LANGUAGE CXX) [snip] > [100%] Building CXX object CMakeFiles/foo.dir/foo.bar.o > c++: warning: /Users/yost/p/c++/cmake/asm/foo.bar: linker input file unused > because linking not done > Linking CXX executable foo > c++: error: CMakeFiles/foo.dir/foo.bar.o: No such file or directory The LANGUAGE property just tells CMake what the language is in case CMake does not know an extension supported by a particular compiler. It does not cause the "-x c++" or similar flag to be added: http://www.cmake.org/Bug/view.php?id=14516 The latter is needed to convince the compiler of the language. -Brad From brad.king at kitware.com Wed Mar 25 11:18:47 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 25 Mar 2015 11:18:47 -0400 Subject: [CMake] Fortran project compiling with -isystem causing error In-Reply-To: <55122593.3010703@auckland.ac.nz> References: <55122593.3010703@auckland.ac.nz> Message-ID: On Tue, Mar 24, 2015 at 11:03 PM, Hugh Sorby wrote: > I am trying to create a simple Fortran project that relies on a module file > that has been built by another project. I have added the directory > containing the module file into the include_directories command but the > project isn't compiling and raises an error can't find module. The > directory that I want to include shows up in the compile command but it is > prefixed with -isystem if I change this manually to -I (capital i) then the > project compiles successfully. As I understand it the -isystem should be > used for includes to be considered as system includes, but I haven't > specified this in my include_directories command. Please post an example CMakeLists.txt file demonstrating the problem and Cc me. Thanks, -Brad From brad.king at kitware.com Wed Mar 25 11:29:28 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 25 Mar 2015 11:29:28 -0400 Subject: [CMake] Behaviour of CACHE PATH variables In-Reply-To: <20150325141530.GA14959@codelibre.net> References: <20150325141530.GA14959@codelibre.net> Message-ID: <5512D458.1080504@kitware.com> On 03/25/2015 10:15 AM, Roger Leigh wrote: > Question: Why is TESTDIR2 transformed from "t2" to > "/home/rleigh/pathtest/test/t2" (which is > "$PROJECT_BINARY_DIR/$TESTDIR2)? It looks like the behavior has been this way since 2003: ENH: When fixing cache value with uninitialized type, collapse full paths for PATH and FILEPATH. Closes Bug #82 - Specifying relative path when entering path can break things http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a6567329 but was added without documentation back in our wild west days. > Copying the GNUInstallDirs behaviour of wrapping in an "if (NOT DEFINED foo)" test > mitigates the problem. > > For my usage, I'm defining project-specific install dirs derived from the > toplevel GNUInstallDirs dirs. I'd quite like to be able to specify a relative > (or absolute) path, and then later prepend the install prefix / appropriate > GNUInstallDirs toplevel variable. Having the current working directory added > by default screws this up quite badly! >From the commit message above I think the intended behavior is exactly to transform relative paths. The behavior has been this way for so long I don't think we can change it now. We can update the documentation to describe the behavior, but I think using the approach in GNUInstallDirs is the solution for you. -Brad From rleigh at codelibre.net Wed Mar 25 12:23:08 2015 From: rleigh at codelibre.net (Roger Leigh) Date: Wed, 25 Mar 2015 16:23:08 +0000 Subject: [CMake] Behaviour of CACHE PATH variables In-Reply-To: <5512D458.1080504@kitware.com> References: <20150325141530.GA14959@codelibre.net> <5512D458.1080504@kitware.com> Message-ID: <20150325162308.GC14959@codelibre.net> On Wed, Mar 25, 2015 at 11:29:28AM -0400, Brad King wrote: > On 03/25/2015 10:15 AM, Roger Leigh wrote: > > Question: Why is TESTDIR2 transformed from "t2" to > > "/home/rleigh/pathtest/test/t2" (which is > > "$PROJECT_BINARY_DIR/$TESTDIR2)? > > It looks like the behavior has been this way since 2003: > > ENH: When fixing cache value with uninitialized type, collapse > full paths for PATH and FILEPATH. Closes Bug #82 - Specifying > relative path when entering path can break things > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a6567329 > > but was added without documentation back in our wild west days. > > > Copying the GNUInstallDirs behaviour of wrapping in an "if (NOT DEFINED foo)" test > > mitigates the problem. > > > > For my usage, I'm defining project-specific install dirs derived from the > > toplevel GNUInstallDirs dirs. I'd quite like to be able to specify a relative > > (or absolute) path, and then later prepend the install prefix / appropriate > > GNUInstallDirs toplevel variable. Having the current working directory added > > by default screws this up quite badly! > > From the commit message above I think the intended behavior is > exactly to transform relative paths. The behavior has been this > way for so long I don't think we can change it now. We can update > the documentation to describe the behavior, but I think using the > approach in GNUInstallDirs is the solution for you. OK. It's a shame this can't be fixed, but entirely understandable. A comment explaining the behaviour would be appreciated; it will certainly save the next person encountering this special case from a good bit of headscratching! Thanks, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 From h.sorby at auckland.ac.nz Wed Mar 25 19:48:01 2015 From: h.sorby at auckland.ac.nz (Hugh Sorby) Date: Thu, 26 Mar 2015 12:48:01 +1300 Subject: [CMake] Fortran project compiling with -isystem causing error In-Reply-To: References: <55122593.3010703@auckland.ac.nz> Message-ID: <55134931.5070007@auckland.ac.nz> My first simple example worked, so I looked at adding an imported target, as this is what my actual script has, to install the dependent modules but this also worked as expected. I am now going to go back to the original CMakeLists.txt file to see if I can make it the same as my second example, hopefully I will inadvertently fix my problem. I'll report back on the outcome. On 03/26/15 04:18, Brad King wrote: > On Tue, Mar 24, 2015 at 11:03 PM, Hugh Sorby wrote: >> I am trying to create a simple Fortran project that relies on a module file >> that has been built by another project. I have added the directory >> containing the module file into the include_directories command but the >> project isn't compiling and raises an error can't find module. The >> directory that I want to include shows up in the compile command but it is >> prefixed with -isystem if I change this manually to -I (capital i) then the >> project compiles successfully. As I understand it the -isystem should be >> used for includes to be considered as system includes, but I haven't >> specified this in my include_directories command. > Please post an example CMakeLists.txt file demonstrating the problem > and Cc me. > > Thanks, > -Brad From h.sorby at auckland.ac.nz Wed Mar 25 20:26:23 2015 From: h.sorby at auckland.ac.nz (Hugh Sorby) Date: Thu, 26 Mar 2015 13:26:23 +1300 Subject: [CMake] Fortran project compiling with -isystem causing error In-Reply-To: <55134931.5070007@auckland.ac.nz> References: <55122593.3010703@auckland.ac.nz> <55134931.5070007@auckland.ac.nz> Message-ID: <5513522F.4030808@auckland.ac.nz> Right got it, the problem occurs when I add the target_link_libraries command to the dependent project. The attached tar.gz contains my not working example source, layout: Konsole output . |-- ex | |-- CMakeLists.txt | `-- use_mod.f90 |-- ex-build |-- install |-- modsrc | |-- CMakeLists.txt | `-- a.f90 `-- modsrc-build commands (from base directory) Konsole output cd modsrc-build/ Konsole output cmake ../modsrc Konsole output make install Konsole output cd ../ex-build/ Konsole output cmake ../ex Konsole output make This will show the error where it is using the -isystem to include the include directories, if you comment out the target_link_libraries command in ex/CMakeLists.txt the build will succeed and -I will be used to include the include directories. I am using: CMake 3.2.1 gfrotran 4.9.2 On 03/26/15 12:48, Hugh Sorby wrote: > > My first simple example worked, so I looked at adding an imported > target, as this is what my actual script has, to install the dependent > modules but this also worked as expected. I am now going to go back > to the original CMakeLists.txt file to see if I can make it the same > as my second example, hopefully I will inadvertently fix my problem. > I'll report back on the outcome. > > On 03/26/15 04:18, Brad King wrote: >> On Tue, Mar 24, 2015 at 11:03 PM, Hugh Sorby wrote: >>> I am trying to create a simple Fortran project that relies on a >>> module file >>> that has been built by another project. I have added the directory >>> containing the module file into the include_directories command but the >>> project isn't compiling and raises an error can't find module. The >>> directory that I want to include shows up in the compile command but >>> it is >>> prefixed with -isystem if I change this manually to -I (capital i) >>> then the >>> project compiles successfully. As I understand it the -isystem >>> should be >>> used for includes to be considered as system includes, but I haven't >>> specified this in my include_directories command. >> Please post an example CMakeLists.txt file demonstrating the problem >> and Cc me. >> >> Thanks, >> -Brad > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: minex.tar.gz Type: application/gzip Size: 1130 bytes Desc: not available URL: From j.kreuzberger at procitec.de Thu Mar 26 05:29:40 2015 From: j.kreuzberger at procitec.de (=?utf-8?Q?J=C3=B6rg_Kreuzberger?=) Date: Thu, 26 Mar 2015 10:29:40 +0100 Subject: [CMake] CMP0054 and CMake Modules Message-ID: Updated to cmake 3.2.1 from 3.0.0 and got several hints due to POLICY CMP0054 (handling of quoted variables) i set the policy to new and changed my local cmake files. But i also got a warning from CMake Modules like FindMFC.cmake (Line 39). do i make something wrong or is this an Error in FindMFC which i have to report? Can i assume that ALL Modules provided with normal cmake install support this policy with NEW? Currently i get no warning from other modules if policy is unset. i also assume i can change the policy during cmake processing? (e.g. set the behaviour to old, include FindMFC.cmake, set the behaviour to new and do the rest of my CMakeLists.txt) Thanks for any support, Joerg From domen.vrankar at gmail.com Thu Mar 26 05:48:57 2015 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Thu, 26 Mar 2015 10:48:57 +0100 Subject: [CMake] CMP0054 and CMake Modules In-Reply-To: References: Message-ID: > do i make something wrong or is this an Error in FindMFC which i have to report? ATM each CMake provided module has to set its own policies otherwise policies from CMakeLists.txt minimum required version setting are used. Please file a bug report. Thanks, Domen From bill.hoffman at kitware.com Thu Mar 26 09:24:24 2015 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Thu, 26 Mar 2015 09:24:24 -0400 Subject: [CMake] CMake Course April 22, 2015 Message-ID: <55140888.6090706@kitware.com> Kitware is hosting a CMake training course, titled ?Project Lifecycle Management with the CMake Family of Tools,? in Clifton Park, NY. The course will be held on April 22, 2015. Through the course, you will learn how to create a build system for your C/C++/Fortran project using CMake, CPack, CTest, and CDash. This course covers in-depth how CMake works and how you can efficiently write CMake scripts for small to large projects. The course also covers unit testing with CTest, packaging with CPack and continuous integration with CDash. Additional details and registration information are available on the Kitware website. -Bill From brad.king at kitware.com Thu Mar 26 09:35:18 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 26 Mar 2015 09:35:18 -0400 Subject: [CMake] Fortran project compiling with -isystem causing error In-Reply-To: <5513522F.4030808@auckland.ac.nz> References: <55122593.3010703@auckland.ac.nz> <55134931.5070007@auckland.ac.nz> <5513522F.4030808@auckland.ac.nz> Message-ID: <55140B16.2080708@kitware.com> On 03/25/2015 08:26 PM, Hugh Sorby wrote: > |-- ex > | |-- CMakeLists.txt > | `-- use_mod.f90 > |-- ex-build > |-- install > |-- modsrc > | |-- CMakeLists.txt > | `-- a.f90 > `-- modsrc-build Thanks for the detailed example. It was trivial to reproduce the issue with that! Since this commit: Always consider includes from IMPORTED targets to be SYSTEM. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a63fcbcb which was first included in CMake 3.0, include directories taken from imported targets are treated as SYSTEM automatically. You can avoid it with a target property on the imported target: http://www.cmake.org/cmake/help/v3.2/prop_tgt/NO_SYSTEM_FROM_IMPORTED.html Doing that will workaround the problem. I think the real issue is that we cannot reliably use -isystem with gfortran at all because it won't look in such paths for module files. I've fixed that here: GNU: Do not use -isystem with gfortran http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a8e7a104 Thanks, -Brad From h.sorby at auckland.ac.nz Thu Mar 26 14:34:47 2015 From: h.sorby at auckland.ac.nz (Hugh Sorby) Date: Fri, 27 Mar 2015 07:34:47 +1300 Subject: [CMake] Fortran project compiling with -isystem causing error In-Reply-To: <55140B16.2080708@kitware.com> References: <55122593.3010703@auckland.ac.nz> <55134931.5070007@auckland.ac.nz> <5513522F.4030808@auckland.ac.nz> <55140B16.2080708@kitware.com> Message-ID: <55145147.40302@auckland.ac.nz> Thanks Brad, I looked at the documentation for gfortran and it says (before asking about my problem, I also read the CMake documentation but failed to comprehend it properly) |-isystem|dir Searchdirfor header files, after all directories specified by-Ibut before the standard system directories. Mark it as a system directory, so that it gets the same special treatment as is applied to the standard system directories. Ifdirbegins with|=|, then the|=|will be replaced by the sysroot prefix; see--sysrootand-isysroot. and |-I|dir These affect interpretation of the|INCLUDE|directive (as well as of the|#include|directive of thecpppreprocessor). Also note that the general behavior of-Iand|INCLUDE|is pretty much the same as of-Iwith|#include|in thecpppreprocessor, with regard to looking forheader.gccfiles and other such things. This path is also used to search for.modfiles when previously compiled modules are required by a|USE|statement. SeeOptions for Directory Search , for information on the-Ioption. I guess their documentation should be more explicit and say that -isystem dirs are not searched for .mod files. The documentation as it stands implies to me that -isystem is the same as -I but for ordering. Again thanks, Hugh. On 03/27/15 02:35, Brad King wrote: > On 03/25/2015 08:26 PM, Hugh Sorby wrote: >> |-- ex >> | |-- CMakeLists.txt >> | `-- use_mod.f90 >> |-- ex-build >> |-- install >> |-- modsrc >> | |-- CMakeLists.txt >> | `-- a.f90 >> `-- modsrc-build > Thanks for the detailed example. It was trivial to reproduce the > issue with that! > > Since this commit: > > Always consider includes from IMPORTED targets to be SYSTEM. > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a63fcbcb > > which was first included in CMake 3.0, include directories taken > from imported targets are treated as SYSTEM automatically. You > can avoid it with a target property on the imported target: > > http://www.cmake.org/cmake/help/v3.2/prop_tgt/NO_SYSTEM_FROM_IMPORTED.html > > Doing that will workaround the problem. I think the real issue > is that we cannot reliably use -isystem with gfortran at all > because it won't look in such paths for module files. I've > fixed that here: > > GNU: Do not use -isystem with gfortran > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a8e7a104 > > Thanks, > -Brad > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom.kacvinsky at vectorcast.com Fri Mar 27 13:17:20 2015 From: tom.kacvinsky at vectorcast.com (Tom Kacvinsky) Date: Fri, 27 Mar 2015 13:17:20 -0400 Subject: [CMake] Windows, export lits (.def files) and automation Message-ID: I have read the material concerning how to make a DLL on Windows with exported symbols and it make sense. However, I would like to avoid use of __declspec(dllexport) if at all possible. I know this is not the recommended cmake way, but I am afrid that introducing __declspec(dllexport) would lead to a maintenance nightmare (broken builds because exports weren't added, merges silently removing the exports, etc...) I found this: http://stackoverflow.com/questions/225432/export-all-symbols-when-creating-a-dll which explains how to automate the creation of a .def file I could use for making a DLL. And I also found documentation on the PRE_LINK option when generating a library. So what I was thinking is I could compile the code via an OBJECT library (vs. STATIC or SHARED), make a custom command to generate the .def file given the correpsonding object files, and then set up a target to generate the DLL that combines the object files and .def file. That's the train of thought, anyway. What I would need to know is the cmake magic to glue all these pieces together. Has any one done this and have tips on how to do so? Thanks, Tom From taylor at braun-jones.org Sat Mar 28 10:38:11 2015 From: taylor at braun-jones.org (Taylor Braun-Jones) Date: Sat, 28 Mar 2015 10:38:11 -0400 Subject: [CMake] ninja command line options not propagated to ninja invocation for superbuild projects Message-ID: See htop screenshot below for an example of what I mean. Note that `ninja` in the original command line invocation is just a bash alias for ninja-build (the name of the ninja binary on Fedora-based systems) [image: Inline image 1] Should I expect to see the -l3 option to be propagated automatically to the sub projects of my superbuild? Or do I need to do some special cmake configuration to make this happen? Or is this just a known issue? Thanks, Taylor -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 24342 bytes Desc: not available URL: From r2d2leboss at voila.fr Sat Mar 28 17:57:49 2015 From: r2d2leboss at voila.fr (r2d2leboss at voila.fr) Date: Sat, 28 Mar 2015 22:57:49 +0100 (CET) Subject: [CMake] "Emulate" a package result (find_package) Message-ID: <1648015514.79201427579869085.JavaMail.www@wwinf7130> Hi, We develop a library that we will call LIBRARY. To compile this library, we use CMake (of course :) ). This library include multiple components, like Boost system, i.e. there are few add_library commands. This library produce LIBRARY_COMPONENTS_1, LIBRARY_COMPONENTS_2, LIBRARY_COMPONENTS_3 (each component is a static or shared library, some both). At the end, user execute "make install" to merge all include dirs in "include/" and all components in "lib/". This project include a FindLIBRARY.cmake file to use this library in another project. We have modules, MODULE_1, MODULE_2, ... MODULE_N. Each module use some components of LIBRARY, maybe LIBRARY_COMPONENTS_1, LIBRARY_COMPONENTS_2 or both... To compile MODULE_1, they need to compile LIBRARY first (separately) then module CMakeLists.txt will use FindLIBRARY.cmake to link to components. This one works well. Now, we would like to make something better. We have a project PROJECT with few modules (not all) and we would like to compile automatically, i.e. we would like a top level CMakeLists.txt which compile LIBRARY and MODULE_1, MODULE_2, MODULE_3... Our idea was to use add_subdirectory but modules will try to search LIBRARY and they will not find the library because it's not still compiled... So, how to "emulate" find_package result for LIBRARY ? Bad idea (I think), is to set LIBRARY-FOUND to true, manually include dirs (a pain because library is not installed) and it will not prevent to library upgrade (maybe that tomorrow it will have a new components, so a new include dir to add). Do you have any idea to build our top level PROJECT CMakeLists.txt ? Thank you, Jean PROJECT/ CMakeLists.txt libs/ LIBRARY/ CMakeLists.txt ... modules/ MODULE_1/ FindLIBRARY.cmake CMakeLists.txt ... MODULE_2 FindLIBRARY.cmake CMakeLists.txt ... MODULE_2 FindLIBRARY.cmake CMakeLists.txt ... ___________________________________________________________ Mode, hifi, maison,? J'ach?te malin. Je compare les prix avec Voila.fr http://shopping.voila.fr/ From r2d2leboss at voila.fr Sat Mar 28 18:00:52 2015 From: r2d2leboss at voila.fr (r2d2leboss at voila.fr) Date: Sat, 28 Mar 2015 23:00:52 +0100 (CET) Subject: [CMake] "Emulate" a package result (find_package) Message-ID: <1685034455.79291427580052912.JavaMail.www@wwinf7130> Hi, We develop a library that we will call LIBRARY. To compile this library, we use CMake (of course :) ). This library include multiple components, like Boost system, i.e. there are few add_library commands. This library produce LIBRARY_COMPONENTS_1, LIBRARY_COMPONENTS_2, LIBRARY_COMPONENTS_3 (each component is a static or shared library, some both). At the end, user execute "make install" to merge all include dirs in "include/" and all components in "lib/". This project include a FindLIBRARY.cmake file to use this library in another project. We have modules, MODULE_1, MODULE_2, ... MODULE_N. Each module use some components of LIBRARY, maybe LIBRARY_COMPONENTS_1, LIBRARY_COMPONENTS_2 or both... To compile MODULE_1, they need to compile LIBRARY first (separately) then module CMakeLists.txt will use FindLIBRARY.cmake to link to components. This one works well. Now, we would like to make something better. We have a project PROJECT with few modules (not all) and we would like to compile automatically, i.e. we would like a top level CMakeLists.txt which compile LIBRARY and MODULE_1, MODULE_2, MODULE_3... Our idea was to use add_subdirectory but modules will try to search LIBRARY and they will not find the library because it's not still compiled... So, how to "emulate" find_package result for LIBRARY ? Bad idea (I think), is to set LIBRARY-FOUND to true, manually include dirs (a pain because library is not installed) and it will not prevent to library upgrade (maybe that tomorrow it will have a new components, so a new include dir to add). Do you have any idea to build our top level PROJECT CMakeLists.txt ? Thank you, Jean PROJECT/ CMakeLists.txt libs/ LIBRARY/ CMakeLists.txt ... modules/ MODULE_1/ FindLIBRARY.cmake CMakeLists.txt ... MODULE_2 FindLIBRARY.cmake CMakeLists.txt ... MODULE_2 FindLIBRARY.cmake CMakeLists.txt ... ___________________________________________________________ Mode, hifi, maison,? J'ach?te malin. Je compare les prix avec Voila.fr http://shopping.voila.fr/ From benapetr at gmail.com Mon Mar 30 09:25:48 2015 From: benapetr at gmail.com (Petr Bena) Date: Mon, 30 Mar 2015 15:25:48 +0200 Subject: [CMake] Change the default output path in Visual Studio Message-ID: I have following problem: I got a project with plugins, each plugin and core is a separate cmake project, however core includes all of them When I configure "core" it also configures all plugins and running "make" also make core, all libraries and plugins. My problem however is the default location of these plugins in Visual Studio, the default folder layout is: CORE/Release/program.exe CORE/extensions/ext1/Release/extension1.dll CORE/extensions/ext2/Release/extension_bla.dll What I need is: CORE/Release/program.exe CORE/Release/extensions/extension1.dll CORE/Release/extensions/extension_bla.dll I can do this by right clicking every single extension -> project config -> output path in Visual Studio. But everytime I rerun cmake which generates solution files I have to do that again and it's quite annoying, is there a way to make the default output path different? From nilsgladitz at gmail.com Mon Mar 30 09:31:08 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Mon, 30 Mar 2015 15:31:08 +0200 Subject: [CMake] Change the default output path in Visual Studio In-Reply-To: References: Message-ID: <5519501C.7080006@gmail.com> On 03/30/2015 03:25 PM, Petr Bena wrote: > I have following problem: > > I got a project with plugins, each plugin and core is a separate cmake > project, however core includes all of them > > When I configure "core" it also configures all plugins and running > "make" also make core, all libraries and plugins. > > My problem however is the default location of these plugins in Visual > Studio, the default folder layout is: > > CORE/Release/program.exe > CORE/extensions/ext1/Release/extension1.dll > CORE/extensions/ext2/Release/extension_bla.dll > > What I need is: > > CORE/Release/program.exe > CORE/Release/extensions/extension1.dll > CORE/Release/extensions/extension_bla.dll > > I can do this by right clicking every single extension -> project > config -> output path in Visual Studio. But everytime I rerun cmake > which generates solution files I have to do that again and it's quite > annoying, is there a way to make the default output path different? > You could set CMAKE_RUNTIME_OUTPUT_DIRECTORY [1] (before you create your targets). Nils [1] http://www.cmake.org/cmake/help/v3.2/variable/CMAKE_RUNTIME_OUTPUT_DIRECTORY.html From benapetr at gmail.com Mon Mar 30 09:36:29 2015 From: benapetr at gmail.com (Petr Bena) Date: Mon, 30 Mar 2015 15:36:29 +0200 Subject: [CMake] Change the default output path in Visual Studio In-Reply-To: <5519501C.7080006@gmail.com> References: <5519501C.7080006@gmail.com> Message-ID: Hi Nils, Great! Could you please give me some mininal example and perhaps add it to documentation page which is now kind of vague? From what is written there, I suppose that this variable changes the runtime output directory, but for all targets since it's set and until it's changed? eg. if I have huge CMakeLists.txt file that includes other CMake files using add_subdirectory I would wrap all add_subdirectory directives with change to this variable? like: RUNTIME_OUTPUT_DIRECTORY("extensions/") add_subdirectory("extension/ext1") # Now I should reset it back to what it was? RUNTIME_OUTPUT_DIRECTORY("WHAT DO I PUT HERE??") On Mon, Mar 30, 2015 at 3:31 PM, Nils Gladitz wrote: > On 03/30/2015 03:25 PM, Petr Bena wrote: >> >> I have following problem: >> >> I got a project with plugins, each plugin and core is a separate cmake >> project, however core includes all of them >> >> When I configure "core" it also configures all plugins and running >> "make" also make core, all libraries and plugins. >> >> My problem however is the default location of these plugins in Visual >> Studio, the default folder layout is: >> >> CORE/Release/program.exe >> CORE/extensions/ext1/Release/extension1.dll >> CORE/extensions/ext2/Release/extension_bla.dll >> >> What I need is: >> >> CORE/Release/program.exe >> CORE/Release/extensions/extension1.dll >> CORE/Release/extensions/extension_bla.dll >> >> I can do this by right clicking every single extension -> project >> config -> output path in Visual Studio. But everytime I rerun cmake >> which generates solution files I have to do that again and it's quite >> annoying, is there a way to make the default output path different? >> > > You could set CMAKE_RUNTIME_OUTPUT_DIRECTORY [1] (before you create your > targets). > > Nils > > [1] > http://www.cmake.org/cmake/help/v3.2/variable/CMAKE_RUNTIME_OUTPUT_DIRECTORY.html From nilsgladitz at gmail.com Mon Mar 30 09:46:30 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Mon, 30 Mar 2015 15:46:30 +0200 Subject: [CMake] Change the default output path in Visual Studio In-Reply-To: References: <5519501C.7080006@gmail.com> Message-ID: <551953B6.20503@gmail.com> On 03/30/2015 03:36 PM, Petr Bena wrote: > Hi Nils, > > Great! Could you please give me some mininal example and perhaps add > it to documentation page which is now kind of vague? From what is > written there, I suppose that this variable changes the runtime output > directory, but for all targets since it's set and until it's changed? > > eg. if I have huge CMakeLists.txt file that includes other CMake files > using add_subdirectory I would wrap all add_subdirectory directives > with change to this variable? like: > > RUNTIME_OUTPUT_DIRECTORY("extensions/") > add_subdirectory("extension/ext1") > # Now I should reset it back to what it was? > RUNTIME_OUTPUT_DIRECTORY("WHAT DO I PUT HERE??") CMAKE_RUNTIME_OUTPUT_DIRECTORY is a variable. You can set it with e.g.: set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}) You could unset it again with e.g. set(CMAKE_RUNTIME_OUTPUT_DIRECTORY) Regular cmake variables are inherited into sub-directories. CMAKE_RUNTIME_OUTPUT_DIRECTORY is read at every add_executable() and add_library() call to initialize the RUNTIME_OUTPUT_DIRECTORY_PROPERTY [1] of the newly created target. So to revise your example the following should work (assuming the sub-directory itself does not override the defaults): set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/extensions) add_subdirectory(extension/ext1) set(CMAKE_RUNTIME_OUTPUT_DIRECTORY) Nils [1] www.cmake.org/cmake/help/v3.2/prop_tgt/RUNTIME_OUTPUT_DIRECTORY.html From MillerHenry at JohnDeere.com Mon Mar 30 16:10:35 2015 From: MillerHenry at JohnDeere.com (Miller Henry) Date: Mon, 30 Mar 2015 20:10:35 +0000 Subject: [CMake] Export a target that must be built in the import environment Message-ID: <35F6921410093E4CA40D524BD5C18D4C2687628A@EDXMB57.jdnet.deere.com> I develop a shared library that gets imported into a number of applications (scattered across a number of different repositories). To aid in testing we provide some mocks and fakes, made available by a cmake export files. This works okay, but it isn't right: google mock doesn't guarantee binary compatibility if compile flags are not exactly the same, and less so if the version is different between our library and the application. There are a couple new features in google mock that I'd like to use, but I cannot upgrade without also upgrading all the users of the library at the same time: this is a difficult task (both technically and politically) I know I'm going to have to face the technical and political issue, but I'd like to solve this problem completely so I don't hit it again. The solution I'd like to install the .cpp files, and have cmake add those files to the build, but only build the ones that are actually used in the project. The actually used is somewhat important as building the library for the mocks is fairly expensive. That is in the main CMakeLists.txt Find_package(MyLibrary) Then in a test someplace Target_link_libraries(SomeTest, MyLibraryMock) I'm stuck though, I can't think of any way to actually implement this. Can anyone offer some suggestions, or a different way to accomplish this? The idea of putting the functions inline in the header will not work: we have benchmark data showing that doing this adds significantly to the compile time of the project when doing an incremental build (the TDD cycle becomes too long). -------------- next part -------------- An HTML attachment was scrubbed... URL: From felix.schwitzer at gmx.at Mon Mar 30 16:38:39 2015 From: felix.schwitzer at gmx.at (felix schwitzer) Date: Mon, 30 Mar 2015 20:38:39 +0000 (UTC) Subject: [CMake] =?utf-8?q?=22Emulate=22_a_package_result_=28find=5Fpackag?= =?utf-8?q?e=29?= References: <1685034455.79291427580052912.JavaMail.www@wwinf7130> Message-ID: writes: > Our idea was to use add_subdirectory but modules will try to search LIBRARY and they will not find the > library because it's not still compiled... So, how to "emulate" > find_package result for LIBRARY ? Bad idea (I think), is to set LIBRARY-FOUND to true, manually include > dirs (a pain because library is not installed) and it will not > prevent to library upgrade (maybe that tomorrow it will have a new components, so a new include dir to add). > > Do you have any idea to build our top level PROJECT CMakeLists.txt ? > Hm... do not understand where your problem is. We do your approach sketched above all the time. The master CMakeLists.txt looks like add_subdirectory(LIBRARY) add_subdirectory(MODULE_1) ... The important thing is, that the order of added subdirectories is right (and your project dependency has such an ordering, no circular dependencies) in MODULE_1/CMakeLists.txt you may have something like add_library(MODULE_1 ...) target_link_libraries(MODULE_1 LIBRARY) This tells cmake that LIBRARY is a prerequisite for MODULE_1 and it will build LIBRARY if MODULE_1 must be built; there is no need that LIBRARY is compiled at configure time. Or I misunderstood your problem totally. Regards Felix From robert.maynard at kitware.com Mon Mar 30 16:57:44 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Mon, 30 Mar 2015 16:57:44 -0400 Subject: [CMake] Export a target that must be built in the import environment In-Reply-To: <35F6921410093E4CA40D524BD5C18D4C2687628A@EDXMB57.jdnet.deere.com> References: <35F6921410093E4CA40D524BD5C18D4C2687628A@EDXMB57.jdnet.deere.com> Message-ID: So what is the reason for delaying the compilation of the .cpp files? Is it due to the possible compiler differences? If so, you could look at generator expressions to attach compiler requirements to your Mock libraries. It might be best to provide a more complete example of what you are trying to do. On Mon, Mar 30, 2015 at 4:10 PM, Miller Henry wrote: > I develop a shared library that gets imported into a number of > applications (scattered across a number of different repositories). To aid > in testing we provide some mocks and fakes, made available by a cmake > export files. > > This works okay, but it isn?t right: google mock doesn?t guarantee binary > compatibility if compile flags are not exactly the same, and less so if the > version is different between our library and the application. There are a > couple new features in google mock that I?d like to use, but I cannot > upgrade without also upgrading all the users of the library at the same > time: this is a difficult task (both technically and politically) > > I know I?m going to have to face the technical and political issue, but > I?d like to solve this problem completely so I don?t hit it again. The > solution I?d like to install the .cpp files, and have cmake add those files > to the build, but only build the ones that are actually used in the > project. The actually used is somewhat important as building the library > for the mocks is fairly expensive. > > That is in the main CMakeLists.txt > Find_package(MyLibrary) > Then in a test someplace > Target_link_libraries(SomeTest, MyLibraryMock) > > I?m stuck though, I can?t think of any way to actually implement this. > Can anyone offer some suggestions, or a different way to accomplish this? > > The idea of putting the functions inline in the header will not work: we > have benchmark data showing that doing this adds significantly to the > compile time of the project when doing an incremental build (the TDD cycle > becomes too long). > > > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 max_linke at gmx.de Tue Mar 31 14:57:20 2015 From: max_linke at gmx.de (Max Linke) Date: Tue, 31 Mar 2015 20:57:20 +0200 Subject: [CMake] include python library in a cmake c++ project Message-ID: <551AEE10.6040101@gmx.de> Hi I have a C++ project that runs some simulations and is build with cmake. With it I want to build/test/ship a python library to help create input files for the C++ project. Is there a recommended way to include C++ and Python in the same cmake projects? Ideally I would like to have a all the python stuff in a separate folder and use python tools (distutils) for installation and testing that are called from cmake. So when I later type `make install` it should run `python setup.up install --prefix=` and ctest call a some python script to run the tests. best Max From bnewcomb at nvidia.com Tue Mar 31 16:28:20 2015 From: bnewcomb at nvidia.com (Bill Newcomb) Date: Tue, 31 Mar 2015 13:28:20 -0700 Subject: [CMake] Build cmake itself statically linked Message-ID: <551B0364.4060203@nvidia.com> Is there a straightforward way to build statically linked cmake and ctest binaries on Linux? Thanks, B. ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -----------------------------------------------------------------------------------