From cmake at lakedaemon.net Wed Apr 1 12:58:23 2015 From: cmake at lakedaemon.net (Jason Cooper) Date: Wed, 1 Apr 2015 16:58:23 +0000 Subject: [CMake] iOS multi-arch library target and xcodebuild Message-ID: <20150401165823.GC24598@io.lakedaemon.net> All, I'm in a situation I largely dislike. :-) Executing a project with two large unknowns. The unknowns are cmake and xcode. I'm attempting to automate building the dylib's (and .so once I start on Android) for yajl: https://github.com/lloyd/yajl.git My goal is to run a cron job that pulls the latest git repo, builds the project, runs tests, and makes the binary library available for the devs of the larger projects. My inspiration is this openssl build script: https://gist.github.com/foozmeat/5154962 I've looked at the rather old example, Tests/iOSNavApp/ in the cmake repo. I've also read everything I could find with $SEARCH_ENGINE. Using the attached patch, I can do the following in yajl: $ mkdir build.ios $ cd build.ios $ cmake -GXcode .. $ xcodebuild -target yajl-ios -configuration Debug The build is successful, but: $ file yajl-2.1.1/lib/Debug/libyajl.2.1.1.dylib yajl-2.1.1/lib/Debug/libyajl.2.1.1.dylib: Mach-O 64-bit dynamically linked shared library x86_64 My goal is to have the multi-arch lib for armv7, arm64, and x86_64 (iOS and simulator). Could anyone offer some insight into what I'm doing wrong? thx, Jason. FYI: this is based on a commit I haven't pushed upstream yet. It changes the .gitignore to match /build* instead of /build/. -------------->8-------------------------------------- diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt index 99cf9e955258..340ffa800a98 100644 --- a/src/CMakeLists.txt +++ b/src/CMakeLists.txt @@ -39,6 +39,31 @@ ADD_LIBRARY(yajl_s STATIC ${SRCS} ${HDRS} ${PUB_HDRS}) ADD_LIBRARY(yajl SHARED ${SRCS} ${HDRS} ${PUB_HDRS}) +ADD_CUSTOM_TARGET(yajl_s-ios DEPENDS yajl_s) + +ADD_CUSTOM_TARGET(yajl-ios DEPENDS yajl) + +set_target_properties( + yajl-ios + PROPERTIES + XCODE_ATTRIBUTE_PRODUCT_NAME + "libYaJL" + XCODE_ATTRIBUTE_WRAPPER_EXTENSION + "xctest" + XCODE_ATTRIBUTE_BUNDLE_IDENTIFIER + "com.github.lloyd.yajl" +) +set_target_properties( + yajl-ios + PROPERTIES + XCODE_ATTRIBUTE_PRODUCT_NAME[variant=Debug] + "libYaJL-Dbg" + XCODE_ATTRIBUTE_WRAPPER_EXTENSION[variant=Debug] + "xctest" + XCODE_ATTRIBUTE_BUNDLE_IDENTIFIER[variant=Debug] + "com.github.lloyd.yajl.debug" +) + #### setup shared library version number SET_TARGET_PROPERTIES(yajl PROPERTIES DEFINE_SYMBOL YAJL_SHARED @@ -50,6 +75,9 @@ IF(APPLE) MESSAGE("INSTALL_NAME_DIR: ${CMAKE_INSTALL_PREFIX}/lib") SET_TARGET_PROPERTIES(yajl PROPERTIES INSTALL_NAME_DIR "${CMAKE_INSTALL_PREFIX}/lib") + set(CMAKE_OSX_SYSROOT iphoneos8.1) + set(CMAKE_OSX_ARCHITECTURES "armv7;arm64;x86_64") + set(CMAKE_XCODE_EFFECTIVE_PLATFORMS "-iphoneos;-iphonesimulator") ENDIF(APPLE) #### build up an sdk as a post build step From parag at ionicsecurity.com Wed Apr 1 13:43:25 2015 From: parag at ionicsecurity.com (Parag Chandra) Date: Wed, 1 Apr 2015 17:43:25 +0000 Subject: [CMake] iOS multi-arch library target and xcodebuild In-Reply-To: <20150401165823.GC24598@io.lakedaemon.net> References: <20150401165823.GC24598@io.lakedaemon.net> Message-ID: Hi Jason, You need to cross-compile in order to target iOS, but if I?m reading your command line correctly, you are merely instructing CMake to generate an Xcode build system for the host OS, which is naturally going to produce a project that targets Mac OSX. The normal way to cross-compile with CMake is to feed it a toolchain file, via the CMAKE_TOOLCHAIN_FILE cmd line option. You may want to take a look at the following project to get an iOS toolchain file from which to start: https://code.google.com/p/ios-cmake/source/browse/toolchain/iOS.cmake You can of course do something similar for Android: https://github.com/taka-no-me/android-cmake/blob/master/android.toolchain.c make Parag Chandra Senior Software Engineer, Mobile Team Mobile: +1.919.824.1410 Ionic Security Inc. 1170 Peachtree St. NE STE 400, Atlanta, GA 30309 On 4/1/15, 12:58 PM, "Jason Cooper" wrote: >All, > >I'm in a situation I largely dislike. :-) Executing a project with two >large >unknowns. The unknowns are cmake and xcode. > >I'm attempting to automate building the dylib's (and .so once I start on >Android) for yajl: > > https://github.com/lloyd/yajl.git > >My goal is to run a cron job that pulls the latest git repo, builds the >project, runs tests, and makes the binary library available for the devs >of the larger projects. My inspiration is this openssl build script: > > https://gist.github.com/foozmeat/5154962 > >I've looked at the rather old example, Tests/iOSNavApp/ in the cmake >repo. I've also read everything I could find with $SEARCH_ENGINE. Using >the attached patch, I can do the following in yajl: > >$ mkdir build.ios >$ cd build.ios >$ cmake -GXcode .. >$ xcodebuild -target yajl-ios -configuration Debug > >The build is successful, but: > >$ file yajl-2.1.1/lib/Debug/libyajl.2.1.1.dylib >yajl-2.1.1/lib/Debug/libyajl.2.1.1.dylib: Mach-O 64-bit dynamically >linked shared library x86_64 > >My goal is to have the multi-arch lib for armv7, arm64, and x86_64 (iOS >and simulator). Could anyone offer some insight into what I'm doing >wrong? > >thx, > >Jason. > >FYI: this is based on a commit I haven't pushed upstream yet. It >changes the .gitignore to match /build* instead of /build/. > >-------------->8-------------------------------------- >diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt >index 99cf9e955258..340ffa800a98 100644 >--- a/src/CMakeLists.txt >+++ b/src/CMakeLists.txt >@@ -39,6 +39,31 @@ ADD_LIBRARY(yajl_s STATIC ${SRCS} ${HDRS} ${PUB_HDRS}) > > ADD_LIBRARY(yajl SHARED ${SRCS} ${HDRS} ${PUB_HDRS}) > >+ADD_CUSTOM_TARGET(yajl_s-ios DEPENDS yajl_s) >+ >+ADD_CUSTOM_TARGET(yajl-ios DEPENDS yajl) >+ >+set_target_properties( >+ yajl-ios >+ PROPERTIES >+ XCODE_ATTRIBUTE_PRODUCT_NAME >+ "libYaJL" >+ XCODE_ATTRIBUTE_WRAPPER_EXTENSION >+ "xctest" >+ XCODE_ATTRIBUTE_BUNDLE_IDENTIFIER >+ "com.github.lloyd.yajl" >+) >+set_target_properties( >+ yajl-ios >+ PROPERTIES >+ XCODE_ATTRIBUTE_PRODUCT_NAME[variant=Debug] >+ "libYaJL-Dbg" >+ XCODE_ATTRIBUTE_WRAPPER_EXTENSION[variant=Debug] >+ "xctest" >+ XCODE_ATTRIBUTE_BUNDLE_IDENTIFIER[variant=Debug] >+ "com.github.lloyd.yajl.debug" >+) >+ > #### setup shared library version number > SET_TARGET_PROPERTIES(yajl PROPERTIES > DEFINE_SYMBOL YAJL_SHARED >@@ -50,6 +75,9 @@ IF(APPLE) > MESSAGE("INSTALL_NAME_DIR: ${CMAKE_INSTALL_PREFIX}/lib") > SET_TARGET_PROPERTIES(yajl PROPERTIES > INSTALL_NAME_DIR "${CMAKE_INSTALL_PREFIX}/lib") >+ set(CMAKE_OSX_SYSROOT iphoneos8.1) >+ set(CMAKE_OSX_ARCHITECTURES "armv7;arm64;x86_64") >+ set(CMAKE_XCODE_EFFECTIVE_PLATFORMS "-iphoneos;-iphonesimulator") > ENDIF(APPLE) > > #### build up an sdk as a post build step >-- > >Powered by www.kitware.com > >Please keep messages on-topic and check the CMake FAQ at: >http://www.cmake.org/Wiki/CMake_FAQ > >Kitware offers various services to support the CMake community. For more >information on each offering, please visit: > >CMake Support: http://cmake.org/cmake/help/support.html >CMake Consulting: http://cmake.org/cmake/help/consulting.html >CMake Training Courses: http://cmake.org/cmake/help/training.html > >Visit other Kitware 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 charles.nicholson at gmail.com Thu Apr 2 01:15:07 2015 From: charles.nicholson at gmail.com (Charles Nicholson) Date: Wed, 1 Apr 2015 22:15:07 -0700 Subject: [CMake] ExternalProject_Add, static library, Ninja generator Message-ID: Hi all- I'm using ExternalProject_Add to pull down, configure, build, and install the OSS "hidapi" project. The output of the hidapi build is, among other things, a library called libhidapi.a. I'm creating an imported static library using add_library, and then using add_dependency to indicate that the library depends on the ExternalProject_Add target. I've seen examples of this approach here and here , but can't get it working. The funny part is that this works fine using the Makefile generator but fails with the Ninja generator. I've put up a very small and self-contained repro case here: https://github.com/charlesnicholson/cmake-external-project-test It requires that cmake and ninja are installed (I'm using cmake 3.2.1 and ninja v1.5.3.). Other than that, just clone and run ./b from the root. I'm assuming that I'm not correctly expressing the dependencies. Would anyone mind taking a quick look? I'd really appreciate it! Thanks in advance, Charles -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Thu Apr 2 02:42:13 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 02 Apr 2015 08:42:13 +0200 Subject: [CMake] ExternalProject_Add, static library, Ninja generator In-Reply-To: References: Message-ID: <551CE4C5.20508@gmail.com> On 04/02/2015 07:15 AM, Charles Nicholson wrote: > I'm assuming that I'm not correctly expressing the dependencies. Would > anyone mind taking a quick look? I'd really appreciate it! Try adding the following to your ExternalProject_Add call: BUILD_BYPRODUCTS ${HIDAPI_ROOT}/bin/lib/libhidapi.a This is required so that the ninja generator knows which target produces the named output. Nils From yves.frederix+cmake at gmail.com Thu Apr 2 03:27:23 2015 From: yves.frederix+cmake at gmail.com (Yves Frederix) Date: Thu, 2 Apr 2015 09:27:23 +0200 Subject: [CMake] Change ctest verbosity from inside a script? Message-ID: Hi all, For one of our projects, I have recently started experimenting with a build setup based on a single ctest script that performs configure, build and runs the unit tests. One thing that is slightly bothering me at the moment with this solution, is that I seem to be unable to set the build verbosity separately from the test verbosity. In particular, I would like to have ctest_build() produce output as if ctest were run with the -VV option, while for ctest_test() I would prefer less output, e.g., as with -V. Is there a way I could accomplish such behavior? Many thanks! Best regards, Yves From cmake at lakedaemon.net Thu Apr 2 08:15:39 2015 From: cmake at lakedaemon.net (Jason Cooper) Date: Thu, 2 Apr 2015 12:15:39 +0000 Subject: [CMake] iOS multi-arch library target and xcodebuild In-Reply-To: References: <20150401165823.GC24598@io.lakedaemon.net> Message-ID: <20150402121539.GD24598@io.lakedaemon.net> Parag, On Wed, Apr 01, 2015 at 05:43:25PM +0000, Parag Chandra wrote: > You need to cross-compile in order to target iOS, but if I?m reading your > command line correctly, you are merely instructing CMake to generate an > Xcode build system for the host OS, which is naturally going to produce a > project that targets Mac OSX. I never said I was on the *right* path. ;-) > The normal way to cross-compile with CMake is to feed it a toolchain file, > via the CMAKE_TOOLCHAIN_FILE cmd line option. You may want to take a look at > the following project to get an iOS toolchain file from which to start: > > https://code.google.com/p/ios-cmake/source/browse/toolchain/iOS.cmake Ok, I had run into that before, but reasoned that the presence of Tests/iOSNavApp/ meant there was now a way to accomplish my goal without having to add what essentially looks like a cmake module. Is there a plan to merge the above into cmake as a module? > You can of course do something similar for Android: > > https://github.com/taka-no-me/android-cmake/blob/master/android.toolchain.cmake Ah, thanks for the heads up. I'll need that later. Back to the iOS.cmake. I was able to get it to successfully build the library dylib by adding the following lines to the same file: # don't need code-signing on libs set(CMAKE_MACOSX_BUNDLE YES) set(CMAKE_XCODE_ATTRIBUTE_CODE_SIGNING_REQUIRED "NO") It's only armv7, so not universal. But I can use lipo to work around that. This all seems rather complicated and fragile, though. I wonder if it might be simpler to have cmake generate standard Unix Makefiles and then use a modified version of the openssl build script. thx, Jason. From charles.nicholson at gmail.com Thu Apr 2 10:05:28 2015 From: charles.nicholson at gmail.com (Charles Nicholson) Date: Thu, 2 Apr 2015 07:05:28 -0700 Subject: [CMake] ExternalProject_Add, static library, Ninja generator In-Reply-To: <551CE4C5.20508@gmail.com> References: <551CE4C5.20508@gmail.com> Message-ID: Thanks for the quick response, Nils, that fixed it! I'm curious, though, why wasn't simply marking my lib as depending on the externalproject_add target enough? I like using the byproducts line since it's more exact and descriptive, but shouldn't it work without that? Thanks again, Charles On Wed, Apr 1, 2015 at 11:42 PM, Nils Gladitz wrote: > On 04/02/2015 07:15 AM, Charles Nicholson wrote: > > I'm assuming that I'm not correctly expressing the dependencies. Would >> anyone mind taking a quick look? I'd really appreciate it! >> > > Try adding the following to your ExternalProject_Add call: > BUILD_BYPRODUCTS ${HIDAPI_ROOT}/bin/lib/libhidapi.a > > This is required so that the ninja generator knows which target produces > the named output. > > Nils > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Thu Apr 2 10:17:18 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 02 Apr 2015 16:17:18 +0200 Subject: [CMake] ExternalProject_Add, static library, Ninja generator In-Reply-To: References: <551CE4C5.20508@gmail.com> Message-ID: <551D4F6E.3030502@gmail.com> On 04/02/2015 04:05 PM, Charles Nicholson wrote: > Thanks for the quick response, Nils, that fixed it! > > I'm curious, though, why wasn't simply marking my lib as depending on > the externalproject_add target enough? I like using the byproducts line > since it's more exact and descriptive, but shouldn't it work without that? The target dependency takes care of order which is enough for the other generators. Ninja in particular needs to account for the library file that you depend on in the beginning. Without marking it a byproduct ninja does not know that it is a file that will be created later on by one of your targets and assumes it missing. Nils From charles.nicholson at gmail.com Thu Apr 2 10:20:21 2015 From: charles.nicholson at gmail.com (Charles Nicholson) Date: Thu, 02 Apr 2015 14:20:21 +0000 Subject: [CMake] ExternalProject_Add, static library, Ninja generator In-Reply-To: <551D4F6E.3030502@gmail.com> References: <551CE4C5.20508@gmail.com> <551D4F6E.3030502@gmail.com> Message-ID: I see now; thank you for the explanation. Best, Charles On Thu, Apr 2, 2015, 7:17 AM Nils Gladitz wrote: > On 04/02/2015 04:05 PM, Charles Nicholson wrote: > > Thanks for the quick response, Nils, that fixed it! > > > > I'm curious, though, why wasn't simply marking my lib as depending on > > the externalproject_add target enough? I like using the byproducts line > > since it's more exact and descriptive, but shouldn't it work without > that? > > The target dependency takes care of order which is enough for the other > generators. > > Ninja in particular needs to account for the library file that you > depend on in the beginning. > > Without marking it a byproduct ninja does not know that it is a file > that will be created later on by one of your targets and assumes it > missing. > > Nils > -------------- next part -------------- An HTML attachment was scrubbed... URL: From parag at ionicsecurity.com Thu Apr 2 10:32:13 2015 From: parag at ionicsecurity.com (Parag Chandra) Date: Thu, 2 Apr 2015 14:32:13 +0000 Subject: [CMake] iOS multi-arch library target and xcodebuild In-Reply-To: <20150402121539.GD24598@io.lakedaemon.net> References: <20150401165823.GC24598@io.lakedaemon.net> <20150402121539.GD24598@io.lakedaemon.net> Message-ID: No idea if they have plans to merge any toolchain files directly into CMake. Even if they did, cross-compiling is still a process that requires explicitly overriding your host computer?s native toolchain, so it?s not something that CMake will sort of do for you automatically - you?re still going to have to feed it the toolchain.cmake. With respect to universal binaries, I have setup my CMake-generated Xcode projects to build them conditionally. The route I have taken is: 1) Set ?Build Active Architecture Only? to an Xcode variable that I default to ?Yes? from CMake. This way, when developers are actively working inside Xcode, they don?t waste time unnecessarily building for CPU architectures they?re not going to use. 2) When building from the command line, this Xcode variable is set to ?No?, so that we get a pair of quasi-universal binaries - one containing x86 + x86_64 for the simulator, and another that contains armv7 + armv7s + arm64 for devices. This seems to be a limitation of Xcode, or at least I couldn?t figure out how to force it to generate a single binary with all 5 CPU archs. 3) To work around this, my CMakeLists add custom ?universal-? targets that, when run, lipo together the pair of sort-of-universal binaries into a truly universal binary. Once again, these ?universal-? targets only get executed when building from the command line. I think you?re going to face a much more difficult challenge if you decide to discard Xcode and go with Unix Makefiles for iOS. The toolchain file I pointed you to did not work well with the Makefile generator, at least in my limited experience. Plus, you would be discarding one of the biggest advantages of CMake in my view: the ability to work inside of popular IDEs with intellisense, debuggers, profilers, etc. Parag Chandra Senior Software Engineer, Mobile Team Mobile: +1.919.824.1410 Ionic Security Inc. 1170 Peachtree St. NE STE 400, Atlanta, GA 30309 On 4/2/15, 8:15 AM, "Jason Cooper" wrote: >Parag, > >On Wed, Apr 01, 2015 at 05:43:25PM +0000, Parag Chandra wrote: >> You need to cross-compile in order to target iOS, but if I?m reading >>your >> command line correctly, you are merely instructing CMake to generate an >> Xcode build system for the host OS, which is naturally going to produce >>a >> project that targets Mac OSX. > >I never said I was on the *right* path. ;-) > >> The normal way to cross-compile with CMake is to feed it a toolchain >>file, >> via the CMAKE_TOOLCHAIN_FILE cmd line option. You may want to take a >>look at >> the following project to get an iOS toolchain file from which to start: >> >> https://code.google.com/p/ios-cmake/source/browse/toolchain/iOS.cmake > >Ok, I had run into that before, but reasoned that the presence of >Tests/iOSNavApp/ meant there was now a way to accomplish my goal without >having to add what essentially looks like a cmake module. > >Is there a plan to merge the above into cmake as a module? > >> You can of course do something similar for Android: >> >> >>https://github.com/taka-no-me/android-cmake/blob/master/android.toolchain >>.cmake > >Ah, thanks for the heads up. I'll need that later. > >Back to the iOS.cmake. I was able to get it to successfully build the >library dylib by adding the following lines to the same file: > ># don't need code-signing on libs >set(CMAKE_MACOSX_BUNDLE YES) >set(CMAKE_XCODE_ATTRIBUTE_CODE_SIGNING_REQUIRED "NO") > >It's only armv7, so not universal. But I can use lipo to work around >that. > >This all seems rather complicated and fragile, though. I wonder if it >might be simpler to have cmake generate standard Unix Makefiles and then >use a modified version of the openssl build script. > >thx, > >Jason. From luc_j_bourhis at mac.com Thu Apr 2 11:37:14 2015 From: luc_j_bourhis at mac.com (Luc J. Bourhis) Date: Thu, 2 Apr 2015 08:37:14 -0700 (MST) Subject: [CMake] [ExternalProject] UPDATE_DISCONNECTED Message-ID: <1427989034215-7590166.post@n2.nabble.com> The documentation says: If UPDATE_DISCONNECTED is set, the update step is not executed automatically when building the main target. The update step can still be added as a step target and called manually. This option sounds interesting but I do not understand how this is supposed to be used. What is the difference with in practice? ----- -- Luc J. Bourhis -- View this message in context: http://cmake.3232098.n2.nabble.com/ExternalProject-UPDATE-DISCONNECTED-tp7590166.html Sent from the CMake mailing list archive at Nabble.com. From cmake at lakedaemon.net Thu Apr 2 12:02:33 2015 From: cmake at lakedaemon.net (Jason Cooper) Date: Thu, 2 Apr 2015 16:02:33 +0000 Subject: [CMake] iOS multi-arch library target and xcodebuild In-Reply-To: References: <20150401165823.GC24598@io.lakedaemon.net> <20150402121539.GD24598@io.lakedaemon.net> Message-ID: <20150402160233.GG24598@io.lakedaemon.net> Parag, On Thu, Apr 02, 2015 at 02:32:13PM +0000, Parag Chandra wrote: > No idea if they have plans to merge any toolchain files directly into > CMake. Even if they did, cross-compiling is still a process that requires > explicitly overriding your host computer?s native toolchain, so it?s not > something that CMake will sort of do for you automatically - you?re still > going to have to feed it the toolchain.cmake. Ok, misunderstanding on my part. Thanks for clearing that up. > With respect to universal binaries, I have setup my CMake-generated Xcode > projects to build them conditionally. The route I have taken is: > > 1) Set ?Build Active Architecture Only? to an Xcode variable that I > default to ?Yes? from CMake. This way, when developers are actively > working inside Xcode, they don?t waste time unnecessarily building for CPU > architectures they?re not going to use. > > 2) When building from the command line, this Xcode variable is set to > ?No?, so that we get a pair of quasi-universal binaries - one containing > x86 + x86_64 for the simulator, and another that contains armv7 + armv7s + > arm64 for devices. This seems to be a limitation of Xcode, or at least I > couldn?t figure out how to force it to generate a single binary with all 5 > CPU archs. > > 3) To work around this, my CMakeLists add custom ?universal-? targets > that, when run, lipo together the pair of sort-of-universal binaries into > a truly universal binary. Once again, these ?universal-? targets only get > executed when building from the command line. Would you mind sharing the relevant file(s)? > I think you?re going to face a much more difficult challenge if you decide > to discard Xcode and go with Unix Makefiles for iOS. The toolchain file I > pointed you to did not work well with the Makefile generator, at least in > my limited experience. Plus, you would be discarding one of the biggest > advantages of CMake in my view: the ability to work inside of popular IDEs > with intellisense, debuggers, profilers, etc. Well, from my end, I'm build an automated system, so I won't be using the IDE. I'll be providing binaries (static/shared libs) for the devs to use. Whichever method gets me there reliably that I don't have to fiddle with too often will work. I'm only working with cmake because the upstream project uses cmake and I hope to have my changes incorporated into mainline. Other upstream projects use Makefiles, so I'll not push cmake on them. thx, Jason. From parag at ionicsecurity.com Thu Apr 2 12:57:25 2015 From: parag at ionicsecurity.com (Parag Chandra) Date: Thu, 2 Apr 2015 16:57:25 +0000 Subject: [CMake] iOS multi-arch library target and xcodebuild In-Reply-To: <20150402160233.GG24598@io.lakedaemon.net> References: <20150401165823.GC24598@io.lakedaemon.net> <20150402121539.GD24598@io.lakedaemon.net> <20150402160233.GG24598@io.lakedaemon.net> Message-ID: Jason, I?ll have to get back to you on that. The problem is the snippets I?m referring to are part of a much larger build system I?ve created for Mac, Windows, Linux, iOS, Android, Windows Phone, and Native Client, and so you would likely need a lot of other supporting files to make sense of them. I?ll have to check with management to see if I could share those. In the meantime, here is what I hope is a small block of CMake code that will get you started creating the ?universal-? targets I mentioned previously: add_custom_target("universal-${artifactName}" COMMAND ${CMAKE_COMMAND} -E make_directory "${CMAKE_CURRENT_BINARY_DIR}/$(CONFIGURATION)-universal" COMMAND lipo -create -output "${CMAKE_CURRENT_BINARY_DIR}/$(CONFIGURATION)-universal/${destFile}" "${CMAKE_CURRENT_BINARY_DIR}/$(CONFIGURATION)-iphoneos/${destFile}" "${CMAKE_CURRENT_BINARY_DIR}/$(CONFIGURATION)-iphonesimulator/${destFile}" ) The next line shows you how to set the Xcode variables: set_target_properties (${artifactName} PROPERTIES XCODE_ATTRIBUTE_MY_BUILD_ONLY_ACTIVE_ARCH ?YES?) set_target_properties (${artifactName} PROPERTIES XCODE_ATTRIBUTE_ONLY_ACTIVE_ARCH "\${MY_BUILD_ONLY_ACTIVE_ARCH}?) If you look at the generated Xcode project after executing those two lines, you will notice that the ?Build Active Architecture Only? setting in the Build Settings view will be set to the value ?Yes - ${MY_BUILD_ONLY_ACTIVE_ARCH}?, which tells you that the setting is taking its value from another variable. Now that it is a variable, you can override this behavior simply by passing ?MY_BUILD_ONLY_ACTIVE_ARCH=NO? to xcodebuild when you run it on the command line. Hope this helps. Parag Chandra Senior Software Engineer, Mobile Team Mobile: +1.919.824.1410 Ionic Security Inc. 1170 Peachtree St. NE STE 400, Atlanta, GA 30309 On 4/2/15, 12:02 PM, "Jason Cooper" wrote: >Parag, > >On Thu, Apr 02, 2015 at 02:32:13PM +0000, Parag Chandra wrote: >> No idea if they have plans to merge any toolchain files directly into >> CMake. Even if they did, cross-compiling is still a process that >>requires >> explicitly overriding your host computer?s native toolchain, so it?s not >> something that CMake will sort of do for you automatically - you?re >>still >> going to have to feed it the toolchain.cmake. > >Ok, misunderstanding on my part. Thanks for clearing that up. > >> With respect to universal binaries, I have setup my CMake-generated >>Xcode >> projects to build them conditionally. The route I have taken is: >> >> 1) Set ?Build Active Architecture Only? to an Xcode variable that I >> default to ?Yes? from CMake. This way, when developers are actively >> working inside Xcode, they don?t waste time unnecessarily building for >>CPU >> architectures they?re not going to use. >> >> 2) When building from the command line, this Xcode variable is set to >> ?No?, so that we get a pair of quasi-universal binaries - one containing >> x86 + x86_64 for the simulator, and another that contains armv7 + >>armv7s + >> arm64 for devices. This seems to be a limitation of Xcode, or at least I >> couldn?t figure out how to force it to generate a single binary with >>all 5 >> CPU archs. >> >> 3) To work around this, my CMakeLists add custom ?universal-? targets >> that, when run, lipo together the pair of sort-of-universal binaries >>into >> a truly universal binary. Once again, these ?universal-? targets only >>get >> executed when building from the command line. > >Would you mind sharing the relevant file(s)? > >> I think you?re going to face a much more difficult challenge if you >>decide >> to discard Xcode and go with Unix Makefiles for iOS. The toolchain file >>I >> pointed you to did not work well with the Makefile generator, at least >>in >> my limited experience. Plus, you would be discarding one of the biggest >> advantages of CMake in my view: the ability to work inside of popular >>IDEs >> with intellisense, debuggers, profilers, etc. > >Well, from my end, I'm build an automated system, so I won't be using the >IDE. >I'll be providing binaries (static/shared libs) for the devs to use. > >Whichever method gets me there reliably that I don't have to fiddle with >too >often will work. > >I'm only working with cmake because the upstream project uses cmake and I >hope >to have my changes incorporated into mainline. Other upstream projects >use >Makefiles, so I'll not push cmake on them. > >thx, > >Jason. From steveire at gmail.com Thu Apr 2 13:20:26 2015 From: steveire at gmail.com (Stephen Kelly) Date: Thu, 02 Apr 2015 19:20:26 +0200 Subject: [CMake] iOS multi-arch library target and xcodebuild References: <20150401165823.GC24598@io.lakedaemon.net> <20150402121539.GD24598@io.lakedaemon.net> Message-ID: Jason Cooper wrote: > Is there a plan to merge the above into cmake as a module? > >> You can of course do something similar for Android: >> >> https://github.com/taka-no-me/android-cmake/blob/master/android.toolchain.cmake > > Ah, thanks for the heads up. I'll need that later. There should be no need for anything as complicated as that huge android.toolchain.cmake file. CMake has a Modules/Platform/Android.cmake file, and cross compiling for Android should really be a case of specifying simple things local to you such as your compiler paths etc. http://www.cmake.org/cmake/help/git-next/manual/cmake-toolchains.7.html#cross-compiling I filed http://public.kitware.com/Bug/view.php?id=15492 for better documentation there (and to find out what features are missing in CMake which would make everything easier). If you know what is missing in CMake but required to make cross compiling for android simpler, please add it there. Thanks, Steve. From mike.jackson at bluequartz.net Thu Apr 2 19:25:09 2015 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Thu, 2 Apr 2015 19:25:09 -0400 Subject: [CMake] Running Custom command only on files that have changed Message-ID: <73936123-3BFE-42C4-8724-BA743EE5BC61@bluequartz.net> The basics of what I want to do is the following: Use git to get a list of files that have changed (git status?) Pipe those files into a custom program that does some code cleanup & formatting. What I am not sure how to do is entice git to give me a list of files that is easy for cmake to parse? Has anyone ever done anything like this before? I want to use AStyle to ensure our source files are consistently formatted before they are checked into our git repo. I don't want to just blanket hit every single file either as that may make for some large commits that hide what is really changing. Maybe this is just a really bad idea in general. I'd appreciate any comments either way. Thanks Mike Jackson BlueQuartz Software, LLC From alexander.ra.droste at googlemail.com Fri Apr 3 14:23:48 2015 From: alexander.ra.droste at googlemail.com (Alexander Droste) Date: Fri, 03 Apr 2015 20:23:48 +0200 Subject: [CMake] how to use the FindMPI module correctly? Message-ID: <551EDAB4.8040409@googlemail.com> Hello everyone, based on the documentation here: http://www.cmake.org/cmake/help/v3.0/module/FindMPI.html and posts on SO: http://stackoverflow.com/questions/23163075/how-to-compile-an-mpi-included-c-program-using-cmake I'm still not a 100% sure if I set up my CMake project correctly. This is what I do: #------------------------ #... find_package(MPI REQUIRED) add_executable(core.x main.c) include_directories(SYSTEM ${MPI_C_INCLUDE_PATH}) link_directories(${MPI_C_LINK_FLAGS}) set(CMAKE_COMPILE_FLAGS ${CMAKE_COMPILE_FLAGS} ${MPI_C_COMPILE_FLAGS}) target_link_libraries(core.x ${MPI_C_LIBRARIES}) #------------------------- Is this the correct way? Am I missing s.th.? I am especially unsure about the compile flags variable. At "Usage" (CMake documentation) it said that "To use this module, simply call FindMPI from a CMakeLists.txt file". So can I break down the MPI setup to a single command. How do I call FindMPI? Or is it done by calling find_package like I did? The program build runs fine but I would like to ensure that the cmake project is set up as correct and generic as possible. Greetings, Alex From alexander.ra.droste at googlemail.com Fri Apr 3 17:54:37 2015 From: alexander.ra.droste at googlemail.com (Alexander Droste) Date: Fri, 03 Apr 2015 23:54:37 +0200 Subject: [CMake] how to use the FindMPI module correctly? In-Reply-To: <0458DF31F610EF42BFC78C497E806C7B4100960F@ECS-EXG-P-MB03.win.lanl.gov> References: <551EDAB4.8040409@googlemail.com> <0458DF31F610EF42BFC78C497E806C7B4100960F@ECS-EXG-P-MB03.win.lanl.gov> Message-ID: <551F0C1D.4010907@googlemail.com> Thanks for the validation. But wouldn't the shorter version break in case MPI_C_COMPILE_FLAGS are added in the future? On 03.04.15 23:28, Thompson, KT wrote: > Alex, > > Your setup looks fine. However, depending on your environment, you may be able to use a simplified CMakeLists.txt. This is what I use on Linux with g++ and OpenMPI. > > #-------------------- > cmake_minimum_required(VERSION 2.8) > project(hw CXX) > find_package( MPI ) > include_directories( ${MPI_CXX_INCLUDE_PATH} ) > add_executable( hw hw.cc ) > target_link_libraries( hw ${MPI_CXX_LIBRARIES} ) > #-------------------- > > -kt > > -----Original Message----- > From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Alexander Droste > Sent: Friday, April 03, 2015 12:24 PM > To: cmake at cmake.org > Subject: [CMake] how to use the FindMPI module correctly? > > Hello everyone, > > based on the documentation here: > http://www.cmake.org/cmake/help/v3.0/module/FindMPI.html > > and posts on SO: > http://stackoverflow.com/questions/23163075/how-to-compile-an-mpi-included-c-program-using-cmake > > I'm still not a 100% sure if I set up my CMake project correctly. > This is what I do: > > #------------------------ > #... > find_package(MPI REQUIRED) > add_executable(core.x main.c) > > include_directories(SYSTEM ${MPI_C_INCLUDE_PATH}) > link_directories(${MPI_C_LINK_FLAGS}) > set(CMAKE_COMPILE_FLAGS ${CMAKE_COMPILE_FLAGS} ${MPI_C_COMPILE_FLAGS}) > target_link_libraries(core.x ${MPI_C_LIBRARIES}) > #------------------------- > > Is this the correct way? Am I missing s.th.? I am especially unsure > about the compile flags variable. > > At "Usage" (CMake documentation) it said that "To use this module, > simply call FindMPI from a CMakeLists.txt file". So can I break down the > MPI setup to a single command. How do I call FindMPI? Or is it done by > calling find_package like I did? > > The program build runs fine but I would like to ensure > that the cmake project is set up as correct and generic as possible. > > Greetings, > Alex > From dschepler at scalable-networks.com Fri Apr 3 18:01:50 2015 From: dschepler at scalable-networks.com (Daniel Schepler) Date: Fri, 3 Apr 2015 22:01:50 +0000 Subject: [CMake] how to use the FindMPI module correctly? In-Reply-To: <551F0C1D.4010907@googlemail.com> References: <551EDAB4.8040409@googlemail.com> <0458DF31F610EF42BFC78C497E806C7B4100960F@ECS-EXG-P-MB03.win.lanl.gov>, <551F0C1D.4010907@googlemail.com> Message-ID: Would this work? target_compile_options(core.x PUBLIC ${MPI_C_COMPILE_FLAGS}) -- Daniel ________________________________________ From: CMake [cmake-bounces at cmake.org] on behalf of Alexander Droste [alexander.ra.droste at googlemail.com] Sent: Friday, April 03, 2015 2:54 PM To: Thompson, KT Cc: cmake at cmake.org Subject: Re: [CMake] how to use the FindMPI module correctly? Thanks for the validation. But wouldn't the shorter version break in case MPI_C_COMPILE_FLAGS are added in the future? On 03.04.15 23:28, Thompson, KT wrote: > Alex, > > Your setup looks fine. However, depending on your environment, you may be able to use a simplified CMakeLists.txt. This is what I use on Linux with g++ and OpenMPI. > > #-------------------- > cmake_minimum_required(VERSION 2.8) > project(hw CXX) > find_package( MPI ) > include_directories( ${MPI_CXX_INCLUDE_PATH} ) > add_executable( hw hw.cc ) > target_link_libraries( hw ${MPI_CXX_LIBRARIES} ) > #-------------------- > > -kt > > -----Original Message----- > From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Alexander Droste > Sent: Friday, April 03, 2015 12:24 PM > To: cmake at cmake.org > Subject: [CMake] how to use the FindMPI module correctly? > > Hello everyone, > > based on the documentation here: > http://www.cmake.org/cmake/help/v3.0/module/FindMPI.html > > and posts on SO: > http://stackoverflow.com/questions/23163075/how-to-compile-an-mpi-included-c-program-using-cmake > > I'm still not a 100% sure if I set up my CMake project correctly. > This is what I do: > > #------------------------ > #... > find_package(MPI REQUIRED) > add_executable(core.x main.c) > > include_directories(SYSTEM ${MPI_C_INCLUDE_PATH}) > link_directories(${MPI_C_LINK_FLAGS}) > set(CMAKE_COMPILE_FLAGS ${CMAKE_COMPILE_FLAGS} ${MPI_C_COMPILE_FLAGS}) > target_link_libraries(core.x ${MPI_C_LIBRARIES}) > #------------------------- > > Is this the correct way? Am I missing s.th.? I am especially unsure > about the compile flags variable. > > At "Usage" (CMake documentation) it said that "To use this module, > simply call FindMPI from a CMakeLists.txt file". So can I break down the > MPI setup to a single command. How do I call FindMPI? Or is it done by > calling find_package like I did? > > The program build runs fine but I would like to ensure > that the cmake project is set up as correct and generic as possible. > > Greetings, > Alex > -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware 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 alexander.ra.droste at googlemail.com Fri Apr 3 18:19:09 2015 From: alexander.ra.droste at googlemail.com (Alexander Droste) Date: Sat, 04 Apr 2015 00:19:09 +0200 Subject: [CMake] how to use the FindMPI module correctly? In-Reply-To: References: <551EDAB4.8040409@googlemail.com> <0458DF31F610EF42BFC78C497E806C7B4100960F@ECS-EXG-P-MB03.win.lanl.gov>, <551F0C1D.4010907@googlemail.com> Message-ID: <551F11DD.6070605@googlemail.com> Do you mean just using: target_compile_options(core.x PUBLIC ${MPI_C_COMPILE_FLAGS}) but not: include_directories(SYSTEM ${MPI_C_INCLUDE_PATH}) link_directories(${MPI_C_LINK_FLAGS}) set(CMAKE_COMPILE_FLAGS ${CMAKE_COMPILE_FLAGS} ${MPI_C_COMPILE_FLAGS}) target_link_libraries(core.x ${MPI_C_LIBRARIES}) Simply using your proposed line seems not to be sufficient. The library symbols are not found then. I believe the variable ${MPI_C_COMPILE_FLAGS} does not contain anything in my case. Calling message(${MPI_C_COMPILE_FLAGS}) from cmake gives me an error: "message called with incorrect number of arguments" Does this mean it's empty? Variables containing flags do not produce this error. On 04.04.15 00:01, Daniel Schepler wrote: > Would this work? > > target_compile_options(core.x PUBLIC ${MPI_C_COMPILE_FLAGS}) > From dschepler at scalable-networks.com Fri Apr 3 18:28:38 2015 From: dschepler at scalable-networks.com (Daniel Schepler) Date: Fri, 3 Apr 2015 22:28:38 +0000 Subject: [CMake] how to use the FindMPI module correctly? In-Reply-To: <551F11DD.6070605@googlemail.com> References: <551EDAB4.8040409@googlemail.com> <0458DF31F610EF42BFC78C497E806C7B4100960F@ECS-EXG-P-MB03.win.lanl.gov>, <551F0C1D.4010907@googlemail.com> , <551F11DD.6070605@googlemail.com> Message-ID: I mean replacing the set CMAKE_COMPILE_FLAGS line with my target_compile_options line. As for the message call, I usually use something more like: message(STATUS "MPI_C_COMPILE_FLAGS = ${MPI_C_COMPILE_FLAGS}") for debugging. -- Daniel ________________________________________ From: Alexander Droste [alexander.ra.droste at googlemail.com] Sent: Friday, April 03, 2015 3:19 PM To: Daniel Schepler Cc: cmake at cmake.org Subject: Re: [CMake] how to use the FindMPI module correctly? Do you mean just using: target_compile_options(core.x PUBLIC ${MPI_C_COMPILE_FLAGS}) but not: include_directories(SYSTEM ${MPI_C_INCLUDE_PATH}) link_directories(${MPI_C_LINK_FLAGS}) set(CMAKE_COMPILE_FLAGS ${CMAKE_COMPILE_FLAGS} ${MPI_C_COMPILE_FLAGS}) target_link_libraries(core.x ${MPI_C_LIBRARIES}) Simply using your proposed line seems not to be sufficient. The library symbols are not found then. I believe the variable ${MPI_C_COMPILE_FLAGS} does not contain anything in my case. Calling message(${MPI_C_COMPILE_FLAGS}) from cmake gives me an error: "message called with incorrect number of arguments" Does this mean it's empty? Variables containing flags do not produce this error. On 04.04.15 00:01, Daniel Schepler wrote: > Would this work? > > target_compile_options(core.x PUBLIC ${MPI_C_COMPILE_FLAGS}) > From alexander.ra.droste at googlemail.com Fri Apr 3 18:42:35 2015 From: alexander.ra.droste at googlemail.com (Alexander Droste) Date: Sat, 04 Apr 2015 00:42:35 +0200 Subject: [CMake] how to use the FindMPI module correctly? In-Reply-To: References: <551EDAB4.8040409@googlemail.com> <0458DF31F610EF42BFC78C497E806C7B4100960F@ECS-EXG-P-MB03.win.lanl.gov>, <551F0C1D.4010907@googlemail.com> , <551F11DD.6070605@googlemail.com> Message-ID: <551F175B.5080201@googlemail.com> calling: message(STATUS "MPI_C_COMPILE_FLAGS = ${MPI_C_COMPILE_FLAGS}") gives me: MPI_C_COMPILE_FLAGS = So there are no flags contained. Is it in general preferable to use this: target_compile_options.. instead of: set(CMAKE_COMPILE_FLAGS ${CMA.. ? On 04.04.15 00:28, Daniel Schepler wrote: > I mean replacing the set CMAKE_COMPILE_FLAGS line with my target_compile_options line. > > As for the message call, I usually use something more like: message(STATUS "MPI_C_COMPILE_FLAGS = ${MPI_C_COMPILE_FLAGS}") for debugging. > From alexander.ra.droste at googlemail.com Sat Apr 4 09:45:10 2015 From: alexander.ra.droste at googlemail.com (Alexander Droste) Date: Sat, 04 Apr 2015 15:45:10 +0200 Subject: [CMake] how to use the FindMPI module correctly? In-Reply-To: References: <551EDAB4.8040409@googlemail.com> Message-ID: <551FEAE6.20001@googlemail.com> Thanks, that really clears things up for me! --Alex On 04.04.15 14:39, Mark Abraham wrote: > On 03/04/2015 8:24 pm, "Alexander Droste" < > alexander.ra.droste at googlemail.com> wrote: >> >> Hello everyone, >> >> based on the documentation here: >> http://www.cmake.org/cmake/help/v3.0/module/FindMPI.html >> >> and posts on SO: >> > http://stackoverflow.com/questions/23163075/how-to-compile-an-mpi-included-c-program-using-cmake >> >> I'm still not a 100% sure if I set up my CMake project correctly. >> This is what I do: >> >> #------------------------ >> #... >> find_package(MPI REQUIRED) >> add_executable(core.x main.c) >> >> include_directories(SYSTEM ${MPI_C_INCLUDE_PATH}) >> link_directories(${MPI_C_LINK_FLAGS}) >> set(CMAKE_COMPILE_FLAGS ${CMAKE_COMPILE_FLAGS} ${MPI_C_COMPILE_FLAGS}) >> target_link_libraries(core.x ${MPI_C_LIBRARIES}) >> #------------------------- >> >> Is this the correct way? Am I missing s.th.? I am especially unsure about > the compile flags variable. >> >> At "Usage" (CMake documentation) it said that "To use this module, simply > call FindMPI from a CMakeLists.txt file". So can I break down the MPI setup > to a single command. How do I call FindMPI? Or is it done by calling > find_package like I did? >> >> The program build runs fine but I would like to ensure >> that the cmake project is set up as correct and generic as possible. > > I think that most projects have no need of most of the functionality > provided by FindMPI. Instead, you can tell CMake in the first place that > the MPI wrapper compiler is your compiler, and leave the wrapper compiler > alone to do its job. Otherwise, you have to coordinate that FindMPI is > finding the wrapper compiler that you intend, and that it wraps the same > compiler CMake is using, so that the flags FindMPI gets from the wrapper > compiler can then work with CMake's compiler, because you can't change that > compiler once it is set. > > The main exception would be a project where you want to build both MPI and > non-MPI binaries from the same configuration. But you can still achieve > this by using the wrapper compiler for everything... The non-MPI binary > just won't link things that aren't used. > > Mark > >> Greetings, >> Alex >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more > information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware 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 becker.tobi at gmail.com Sat Apr 4 13:36:29 2015 From: becker.tobi at gmail.com (Tobias Becker) Date: Sat, 4 Apr 2015 19:36:29 +0200 Subject: [CMake] Return Values , Dynamic Calls and Exceptions in CMake Message-ID: Hi All, I wanted to share my blog post on Return Values, Dynamic Calls and Exceptions in CMake with you: http://thetoeb.de/2015/04/04/cmakepp-dynamic-calls-return-values-and-exceptions/ cmakepp is pure cmake, open source (MIT License) project which gives you > 1000 extra functions and utilities. If you have questions or suggestions I'd be happy for any feedback. Cheers Tobi -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob.a.mcdonald at gmail.com Sat Apr 4 15:57:32 2015 From: rob.a.mcdonald at gmail.com (Rob McDonald) Date: Sat, 4 Apr 2015 12:57:32 -0700 Subject: [CMake] ExternalProject_Add contributing to top-level Package Message-ID: All, I have a project that is typically compiled with CLang/LLVM. However, I'm now adding a component that is preferentially built with OpenMP. CLang doesn't support OpenMP, so I'd like to build that component with GCC while still building everything else with CLang. So far, I'm approaching the problem as shown in the below CMakeLists.txt. The program understands -DUSE_OPENMP, so if OpenMP isn't found, it will build a uni-processor version. The user can optionally pass -DC_OMP_COMPILER and -DCXX_OMP_COMPILER when CMake is run. Those will specify alternate OpenMP capable compilers. The EP_BUILD variable prevents infinite recursion. So, in the case where the primary compiler does not support OpenMP, and the user specifies an alternate compiler, this will use ExternalProject_Add to establish a new build environment with the alternate compiler, and build that. So far, so good. The problem I have is that I would like the executable built by ExternalProject to be added to the top-level project's package. So, instead of the recursion protected INSTALL at the bottom, I want a roughly equivalent INSTALL command that specifically works in the ExternalProject case. Best, Rob ##################################### FIND_PACKAGE( OpenMP ) if(OPENMP_FOUND) set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${OpenMP_C_FLAGS} -DUSE_OPENMP") set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${OpenMP_CXX_FLAGS} -DUSE_OPENMP") set(BUILD_IT true) else() if( CXX_OMP_COMPILER AND NOT EP_BUILD ) INCLUDE( ExternalProject ) set(CMAKE_MODULE_PATH ${CMAKE_CURRENT_SOURCE_DIR}/cmake ${CMAKE_MODULE_PATH}) INCLUDE( ExternalProject_ForceBuild ) ExternalProject_Add( ALTBUILD URL ${CMAKE_CURRENT_SOURCE_DIR} CMAKE_ARGS -DCMAKE_C_COMPILER=${C_OMP_COMPILER} -DCMAKE_CXX_COMPILER=${CXX_OMP_COMPILER} -DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE} -DEP_BUILD=TRUE INSTALL_COMMAND "" ) EP_ForceBuild( ALTBUILD ) else() set(BUILD_IT true) endif() endif() if(BUILD_IT) ADD_EXECUTABLE( myprogram main.cpp ) TARGET_LINK_LIBRARIES( myprogram ) if ( NOT EP_BUILD ) INSTALL( TARGETS myprogram RUNTIME DESTINATION . ) endif() endif() From digitalriptide at gmail.com Sat Apr 4 20:30:01 2015 From: digitalriptide at gmail.com (digitalriptide) Date: Sat, 4 Apr 2015 17:30:01 -0700 Subject: [CMake] Intel Compilers and libc++? Message-ID: I have an Ubuntu installation with both libstdc++ and libc++ installed, and I am using Intel's C++ compiler. By default, CMake is picking up and linking against libstdc++. Is there a way to ask CMake to prefer libc++ over libstdc++, when available? Thank you kindly for your advice. From benpope81 at gmail.com Sun Apr 5 00:41:50 2015 From: benpope81 at gmail.com (Ben Pope) Date: Sun, 05 Apr 2015 12:41:50 +0800 Subject: [CMake] Intel Compilers and libc++? In-Reply-To: References: Message-ID: On Sunday, April 05, 2015 08:30 AM, digitalriptide wrote: > I have an Ubuntu installation with both libstdc++ and libc++ > installed, and I am using Intel's C++ compiler. By default, CMake is > picking up and linking against libstdc++. Is there a way to ask CMake > to prefer libc++ over libstdc++, when available? I'm not aware of a way to tell CMake directly, but from what I can gather, you can ask the compiler to prefer libc++ by passing "-stdlib=libc++" to it. CMAKE_CXX_FLAGS is the easiest the place for that. You may need to add it to linker flags as well, if you link as a separate step. Ben From rob.a.mcdonald at gmail.com Sun Apr 5 13:26:36 2015 From: rob.a.mcdonald at gmail.com (Rob McDonald) Date: Sun, 5 Apr 2015 10:26:36 -0700 Subject: [CMake] ExternalProject_Add contributing to top-level Package In-Reply-To: References: Message-ID: Ok, I think I've answered my own question... I added the following after the ExternalProject_Add command... ExternalProject_Get_Property( ALTBUILD BINARY_DIR ) INSTALL( PROGRAMS ${BINARY_DIR}/myprogram DESTINATION . ) Rob On Sat, Apr 4, 2015 at 12:57 PM, Rob McDonald wrote: > All, > > I have a project that is typically compiled with CLang/LLVM. However, > I'm now adding a component that is preferentially built with OpenMP. > CLang doesn't support OpenMP, so I'd like to build that component with > GCC while still building everything else with CLang. > > So far, I'm approaching the problem as shown in the below > CMakeLists.txt. The program understands -DUSE_OPENMP, so if OpenMP > isn't found, it will build a uni-processor version. The user can > optionally pass -DC_OMP_COMPILER and -DCXX_OMP_COMPILER when CMake is > run. Those will specify alternate OpenMP capable compilers. The > EP_BUILD variable prevents infinite recursion. > > So, in the case where the primary compiler does not support OpenMP, > and the user specifies an alternate compiler, this will use > ExternalProject_Add to establish a new build environment with the > alternate compiler, and build that. So far, so good. > > The problem I have is that I would like the executable built by > ExternalProject to be added to the top-level project's package. So, > instead of the recursion protected INSTALL at the bottom, I want a > roughly equivalent INSTALL command that specifically works in the > ExternalProject case. > > Best, > > Rob > > ##################################### > FIND_PACKAGE( OpenMP ) > > if(OPENMP_FOUND) > set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${OpenMP_C_FLAGS} -DUSE_OPENMP") > set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${OpenMP_CXX_FLAGS} -DUSE_OPENMP") > set(BUILD_IT true) > else() > > if( CXX_OMP_COMPILER AND NOT EP_BUILD ) > > INCLUDE( ExternalProject ) > > set(CMAKE_MODULE_PATH ${CMAKE_CURRENT_SOURCE_DIR}/cmake ${CMAKE_MODULE_PATH}) > INCLUDE( ExternalProject_ForceBuild ) > > ExternalProject_Add( ALTBUILD > URL ${CMAKE_CURRENT_SOURCE_DIR} > CMAKE_ARGS -DCMAKE_C_COMPILER=${C_OMP_COMPILER} > -DCMAKE_CXX_COMPILER=${CXX_OMP_COMPILER} > -DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE} > -DEP_BUILD=TRUE > INSTALL_COMMAND "" > ) > EP_ForceBuild( ALTBUILD ) > > else() > set(BUILD_IT true) > endif() > endif() > > if(BUILD_IT) > > ADD_EXECUTABLE( myprogram > main.cpp > ) > > TARGET_LINK_LIBRARIES( myprogram > ) > > if ( NOT EP_BUILD ) > INSTALL( TARGETS myprogram RUNTIME DESTINATION . ) > endif() > > endif() From scott at towel42.com Sun Apr 5 14:46:35 2015 From: scott at towel42.com (Scott Aron Bloom) Date: Sun, 5 Apr 2015 18:46:35 +0000 Subject: [CMake] MSB8029 from VS 2013 Message-ID: When creating a project using cmake, and Visual Studio 2013, I get the following warning: C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppBuild.targets(396,5): warning MSB8029: The Intermediate directory or Output directory cannot reside under the Temporary directory as it could lead to issues with incremental build. [C:\buildScripts\windows32\Build-r29592-Win32-20150405-110810-PDT\build\PACKAGE.vcxproj] On just about every sub-project in the project. Is there a known workaround to get rid of these? I know if we modify the project files to include true however, I would prefer have CMake fix this. Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From diltsman at gmail.com Mon Apr 6 14:47:32 2015 From: diltsman at gmail.com (Daniel Dilts) Date: Mon, 6 Apr 2015 11:47:32 -0700 Subject: [CMake] Running custom executable Message-ID: I have a custom executable that does some codegen to produce an enumeration and a couple of tables. I need this to be run against each source file before actual compilation. It needs include directories and macro definitions from the build system. Is there a way to do this with a CMake build system? add_custom_command seems like it might work, but I need all runs of the custom executable to run before compilation begins. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mjklaim at gmail.com Mon Apr 6 15:19:57 2015 From: mjklaim at gmail.com (=?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?=) Date: Mon, 6 Apr 2015 21:19:57 +0200 Subject: [CMake] Running custom executable In-Reply-To: References: Message-ID: On Mon, Apr 6, 2015 at 8:47 PM, Daniel Dilts wrote: > I have a custom executable that does some codegen to produce an > enumeration and a couple of tables. I need this to be run against each > source file before actual compilation. It needs include directories and > macro definitions from the build system. > > Is there a way to do this with a CMake build system? add_custom_command > seems like it might work, but I need all runs of the custom executable to > run before compilation begins. > > execute_process() might be what you want: http://www.cmake.org/cmake/help/v3.2/command/execute_process.html > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christon at lanl.gov Mon Apr 6 16:04:35 2015 From: christon at lanl.gov (Christon, Mark) Date: Mon, 6 Apr 2015 20:04:35 +0000 Subject: [CMake] CTest for multiple parallel jobs Message-ID: Hi Folks, This is actually a ctest question. It would be nice to be able to run a series of test suites, serial (1-core), parallel (4-core) and long (8-core) with a single execution of ctest using ?j <# of cores> across multiple nodes of a cluster. As a prototype, consider 2 nodes, 24-cores on each node, so a total of 48 cores. It appears that using ctest ?j 48 simply overloads the first node. Now, using ?mca opal_paffinity_alone 0 with openmpi does not really correct the issue. Is there a way to spawn and manage a series of regression tests that range from 1 to 8 cores and have the jobs distributed across all of the available cores with some combination of ctest and mpi options? So far, I have been unable to find a combination that works properly for more than one node. - Mark -- Mark A. Christon Computational Physics Group (CCS-2) Computer, Computational and Statistical Sciences Division Los Alamos National Laboratory MS D413, P.O. Box 1663 Los Alamos, NM 87545 E-mail: christon at lanl.gov Phone : (505) 665-9063 Mobile: (505) 695-5649 (voice mail) International Journal For Numerical Methods in Fluids -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Mon Apr 6 16:25:19 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Mon, 6 Apr 2015 16:25:19 -0400 Subject: [CMake] CTest for multiple parallel jobs In-Reply-To: References: Message-ID: You can specify the PROCESSORS ( http://www.cmake.org/cmake/help/v3.0/prop_test/PROCESSORS.html ) property on a test that will tell ctest how man processors from the pool a test should take. Note that this still requires that you specify the affinity for the MPI processes. On Mon, Apr 6, 2015 at 4:04 PM, Christon, Mark wrote: > Hi Folks, > > This is actually a ctest question. It would be nice to be able to run > a series of test suites, serial (1-core), parallel (4-core) and long > (8-core) with a single execution of ctest using ?j <# of cores> across > multiple nodes of a cluster. As a prototype, consider 2 nodes, 24-cores > on each node, so a total of 48 cores. > > It appears that using ctest ?j 48 simply overloads the first node. > Now, using ?mca opal_paffinity_alone 0 with openmpi does not really > correct the issue. > > Is there a way to spawn and manage a series of regression tests that > range from 1 to 8 cores and have the jobs distributed across all of the > available cores with some combination of ctest and mpi options? So far, I > have been unable to find a combination that works properly for more than > one node. > > > - Mark > > -- > Mark A. Christon > Computational Physics Group (CCS-2) > Computer, Computational and Statistical Sciences Division > Los Alamos National Laboratory > MS D413, P.O. Box 1663 > Los Alamos, NM 87545 > > E-mail: christon at lanl.gov > Phone : (505) 665-9063 > Mobile: (505) 695-5649 (voice mail) > > International Journal For Numerical Methods in Fluids > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 digitalriptide at gmail.com Mon Apr 6 17:08:20 2015 From: digitalriptide at gmail.com (digitalriptide) Date: Mon, 6 Apr 2015 14:08:20 -0700 Subject: [CMake] Enable C++11 for a Target with Intel Message-ID: With the GNU compilers I am able to enable C++11 for a specific target using: set_target_properties( my_target PROPERTIES CXX_STANDARD 11 ) set_target_properties( my_target PROPERTIES CXX_STANDARD_REQUIRED ON ) When I build, this adds the flag -std=gnu++11, which is great. If I compile with Intel's compilers, however, this does not add any C++11 flags, and I have to manually append -std=c++11 to CMAKE_CXX_FLAGS. Is this the intended behavior? Thank you for advice in this situation. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Mon Apr 6 17:27:39 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Mon, 6 Apr 2015 17:27:39 -0400 Subject: [CMake] Enable C++11 for a Target with Intel In-Reply-To: References: Message-ID: Currently the only compilers that support compiler features are: Apple Clang versions 4.4 though 6.1. GNU compiler versions 4.4 through 5.0 on UNIX and Apple. Microsoft Visual Studio versions 2010 through 2015. Oracle SolarisStudio version 12.4. If you are interested in adding support for the intel compilers you can look at: Modules/SunPro-CXX-FeatureTests.cmake and Modules/GNU-CXX-FeatureTests.cmake On Mon, Apr 6, 2015 at 5:08 PM, digitalriptide wrote: > With the GNU compilers I am able to enable C++11 for a specific target > using: > set_target_properties( my_target PROPERTIES CXX_STANDARD 11 ) > set_target_properties( my_target PROPERTIES CXX_STANDARD_REQUIRED ON ) > When I build, this adds the flag -std=gnu++11, which is great. > > If I compile with Intel's compilers, however, this does not add any C++11 > flags, and I have to manually append -std=c++11 to CMAKE_CXX_FLAGS. Is this > the intended behavior? > > Thank you for advice in this situation. > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 Thomas.L.Clune at nasa.gov Mon Apr 6 17:09:16 2015 From: Thomas.L.Clune at nasa.gov (Tom Clune) Date: Mon, 6 Apr 2015 17:09:16 -0400 Subject: [CMake] Fortran dependency problem when two source files produce the same .mod file (with reproducer) Message-ID: <21297CC6-4366-4423-BDFF-054EC2D345A7@nasa.gov> This is a somewhat artificial example, but is being used by a client as an objection for migrating to CMake. In the attached example, there are two source files: file1.F90 and file2.F90. Both define the module ?foo_mod?, but only one is listed in CMakeLists.txt for any given configuration. (The interfaces defined by each are different.) If one does a build, and then toggles file1 and file2 in CMakeLists.txt, the code will _correctly_ report a compilation error: call gamma(x) 1 Error: Type mismatch in argument ?x? at (1); passed REAL(4) to REAL(8) However, if one then switches back to file1.F90, the error remains. Cmake does not correctly identify that file1.F90 needs to be recompiled. Note 1: If both files have the _same_ interface, then CMake _does_ recompile correctly. Otherwise, I?d have provided a cleaner demonstration. Note 2: If I turn down the verbosity, the build ?succeeds? in both cases, but instead causes a segmentation fault. This surprises me, as I would expect a compiler error regardless of verbosity. But this is not an immediate concern. ?????- Now, one can probably argue that this example is not a CMake bug, but a ?fix? would certainly help me in my efforts to convince my client to upgrade. Thanks in advance, - Tom Thomas Clune, Ph. D. Head ASTG,Code 606 NASA GSFC MS 610.8 B33-C128 Greenbelt, MD 20771 301-286-4635 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cmake_ex.tar Type: application/x-tar Size: 10752 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Mon Apr 6 20:26:40 2015 From: d3ck0r at gmail.com (J Decker) Date: Mon, 6 Apr 2015 17:26:40 -0700 Subject: [CMake] Custom target not triggered to build Message-ID: I have a script that builds some package sort of files based on other sources... Basically a simplified version... I would think since the output file of add_custom_command was referenced in a INSTALL that those targets should get build before INSTALL... but using MinGW Makefiles, 'make install' fails to generate either file.... ------ CMakeLists.txt ------------- cmake_minimum_required(VERSION 3.0) project( test ) add_custom_command( OUTPUT ${CMAKE_BINARY_DIR}/resources.kw COMMAND ${CMAKE_COMMAND} -E touch ${CMAKE_BINARY_DIR}/resources.kw ) INSTALL( FILES ${CMAKE_BINARY_DIR}/resources.kw DESTINATION bin ) add_custom_command( OUTPUT ${CMAKE_BINARY_DIR}/application.dat COMMAND ${CMAKE_COMMAND} -E touch ${CMAKE_BINARY_DIR}/application.dat ) INSTALL( FILES ${CMAKE_BINARY_DIR}/application.dat DESTINATION bin ) ------------ end CMakeLists.txt -------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Tue Apr 7 12:48:28 2015 From: d3ck0r at gmail.com (J Decker) Date: Tue, 7 Apr 2015 09:48:28 -0700 Subject: [CMake] Custom target not triggered to build In-Reply-To: References: Message-ID: Am I incorrect in assuming that this should work? I added dependancies to them and that helped... until I leared I had the dependants wrong order, and it wouldn't let me depend the common on both of these... so when I reversed them, then neither built before install.... I recall a similar message not long ago about asking to depend targets on INSTALL... but I can't use install because it's a phony target. On Mon, Apr 6, 2015 at 5:26 PM, J Decker wrote: > I have a script that builds some package sort of files based on other > sources... > > Basically a simplified version... > I would think since the output file of add_custom_command was referenced > in a INSTALL that those targets should get build before INSTALL... but > using MinGW Makefiles, 'make install' fails to generate either file.... > > ------ CMakeLists.txt ------------- > cmake_minimum_required(VERSION 3.0) > > project( test ) > > add_custom_command( OUTPUT ${CMAKE_BINARY_DIR}/resources.kw > COMMAND ${CMAKE_COMMAND} -E touch ${CMAKE_BINARY_DIR}/resources.kw > ) > INSTALL( FILES ${CMAKE_BINARY_DIR}/resources.kw DESTINATION bin ) > > > add_custom_command( OUTPUT ${CMAKE_BINARY_DIR}/application.dat > COMMAND ${CMAKE_COMMAND} -E touch ${CMAKE_BINARY_DIR}/application.dat > ) > INSTALL( FILES ${CMAKE_BINARY_DIR}/application.dat DESTINATION bin ) > ------------ end CMakeLists.txt -------------- > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christon at lanl.gov Tue Apr 7 13:11:26 2015 From: christon at lanl.gov (Christon, Mark) Date: Tue, 7 Apr 2015 17:11:26 +0000 Subject: [CMake] CTest for multiple parallel jobs In-Reply-To: References: Message-ID: Hi Robert, et al., Thanks for the information. I believe that ctest ?j <#-of-cores> is equivalent to specifying the processor count with ctest_test that you pointed me to. This does not correct the issue of distributing multiple jobs across multiple nodes on a cluster via ctest. Again, considering the prototype below, it is possible to get a workable solution to this issue of running multiple parallel jobs with ctest across multiple nodes by using a command line to execute each test that looks like ?mpirun -?mca opal_paffinity_alone 0 ?bynode ?np ? The ?dynode does a sort of round-robin assignment of tasks to cores and keeps the jobs from piling up on the cores associated with the first node. Caveats: This works with openmpi 1.6.5 on our local clusters. Your mileage may vary with other driving conditions. The trade-off is that you pay a bit more in communication, or at least it?s a bit less optimal, but the work load is manageable. - Mark -- Mark A. Christon Computational Physics Group (CCS-2) Computer, Computational and Statistical Sciences Division Los Alamos National Laboratory MS D413, P.O. Box 1663 Los Alamos, NM 87545 E-mail: christon at lanl.gov Phone : (505) 665-9063 Mobile: (505) 695-5649 (voice mail) International Journal For Numerical Methods in Fluids From: Robert Maynard > Date: Monday, April 6, 2015 at 2:25 PM To: Mark Christon > Cc: "cmake at cmake.org" > Subject: Re: [CMake] CTest for multiple parallel jobs You can specify the PROCESSORS ( http://www.cmake.org/cmake/help/v3.0/prop_test/PROCESSORS.html ) property on a test that will tell ctest how man processors from the pool a test should take. Note that this still requires that you specify the affinity for the MPI processes. On Mon, Apr 6, 2015 at 4:04 PM, Christon, Mark > wrote: Hi Folks, This is actually a ctest question. It would be nice to be able to run a series of test suites, serial (1-core), parallel (4-core) and long (8-core) with a single execution of ctest using ?j <# of cores> across multiple nodes of a cluster. As a prototype, consider 2 nodes, 24-cores on each node, so a total of 48 cores. It appears that using ctest ?j 48 simply overloads the first node. Now, using ?mca opal_paffinity_alone 0 with openmpi does not really correct the issue. Is there a way to spawn and manage a series of regression tests that range from 1 to 8 cores and have the jobs distributed across all of the available cores with some combination of ctest and mpi options? So far, I have been unable to find a combination that works properly for more than one node. - Mark -- Mark A. Christon Computational Physics Group (CCS-2) Computer, Computational and Statistical Sciences Division Los Alamos National Laboratory MS D413, P.O. Box 1663 Los Alamos, NM 87545 E-mail: christon at lanl.gov Phone : (505) 665-9063 Mobile: (505) 695-5649 (voice mail) International Journal For Numerical Methods in Fluids -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Tue Apr 7 13:41:14 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 7 Apr 2015 13:41:14 -0400 Subject: [CMake] CTest for multiple parallel jobs In-Reply-To: References: Message-ID: On Tue, Apr 7, 2015 at 1:11 PM, Christon, Mark wrote: > Hi Robert, et al., > > Thanks for the information. I believe that ctest ?j <#-of-cores> is > equivalent to specifying the processor count with ctest_test that you > pointed me to. > The PROCESSORS property states how many of #-of-cores a single test will use, it is meant as a way to make sure you don't use n * n cores. > > This does not correct the issue of distributing multiple jobs across > multiple nodes on a cluster via ctest. > > Again, considering the prototype below, it is possible to get a workable > solution to this issue of running multiple parallel jobs with ctest across > multiple nodes by using a command line to execute each test that looks like > > ?mpirun -?mca opal_paffinity_alone 0 ?bynode ?np ? > > The ?dynode does a sort of round-robin assignment of tasks to cores and > keeps the jobs from piling up on the cores associated with the first node. > > Caveats: This works with openmpi 1.6.5 on our local clusters. Your > mileage may vary with other driving conditions. The trade-off is that you > pay a bit more in communication, or at least it?s a bit less optimal, but > the work load is manageable. > I believe that ctest doesn't have anything out of the box that does this, but instead people generally use a test driver program to marshall the options to mpirun. > > - Mark > > -- > Mark A. Christon > Computational Physics Group (CCS-2) > Computer, Computational and Statistical Sciences Division > Los Alamos National Laboratory > MS D413, P.O. Box 1663 > Los Alamos, NM 87545 > > E-mail: christon at lanl.gov > Phone : (505) 665-9063 > Mobile: (505) 695-5649 (voice mail) > > International Journal For Numerical Methods in Fluids > > > From: Robert Maynard > Date: Monday, April 6, 2015 at 2:25 PM > To: Mark Christon > Cc: "cmake at cmake.org" > Subject: Re: [CMake] CTest for multiple parallel jobs > > You can specify the PROCESSORS ( > http://www.cmake.org/cmake/help/v3.0/prop_test/PROCESSORS.html ) property > on a test that will tell ctest how man processors from the pool a test > should take. Note that this still requires that you specify the affinity > for the MPI processes. > > On Mon, Apr 6, 2015 at 4:04 PM, Christon, Mark wrote: > >> Hi Folks, >> >> This is actually a ctest question. It would be nice to be able to run >> a series of test suites, serial (1-core), parallel (4-core) and long >> (8-core) with a single execution of ctest using ?j <# of cores> across >> multiple nodes of a cluster. As a prototype, consider 2 nodes, 24-cores >> on each node, so a total of 48 cores. >> >> It appears that using ctest ?j 48 simply overloads the first node. >> Now, using ?mca opal_paffinity_alone 0 with openmpi does not really >> correct the issue. >> >> Is there a way to spawn and manage a series of regression tests that >> range from 1 to 8 cores and have the jobs distributed across all of the >> available cores with some combination of ctest and mpi options? So far, I >> have been unable to find a combination that works properly for more than >> one node. >> >> >> - Mark >> >> -- >> Mark A. Christon >> Computational Physics Group (CCS-2) >> Computer, Computational and Statistical Sciences Division >> Los Alamos National Laboratory >> MS D413, P.O. Box 1663 >> Los Alamos, NM 87545 >> >> E-mail: christon at lanl.gov >> Phone : (505) 665-9063 >> Mobile: (505) 695-5649 (voice mail) >> >> International Journal For Numerical Methods in Fluids >> >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Tue Apr 7 14:05:16 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 7 Apr 2015 14:05:16 -0400 Subject: [CMake] Custom target not triggered to build In-Reply-To: References: Message-ID: Add custom command doesn't generate a target. You need to use add_custom_target to create an actual target. I believe what you are missing is a custom target that consume the output of the add custom command, than the install should work. A fully contained example that I could run would make solving this issue easier. On Tue, Apr 7, 2015 at 12:48 PM, J Decker wrote: > Am I incorrect in assuming that this should work? > > I added dependancies to them and that helped... until I leared I had the > dependants wrong order, and it wouldn't let me depend the common on both of > these... so when I reversed them, then neither built before install.... > > I recall a similar message not long ago about asking to depend targets on > INSTALL... but I can't use install because it's a phony target. > > On Mon, Apr 6, 2015 at 5:26 PM, J Decker wrote: > >> I have a script that builds some package sort of files based on other >> sources... >> >> Basically a simplified version... >> I would think since the output file of add_custom_command was referenced >> in a INSTALL that those targets should get build before INSTALL... but >> using MinGW Makefiles, 'make install' fails to generate either file.... >> >> ------ CMakeLists.txt ------------- >> cmake_minimum_required(VERSION 3.0) >> >> project( test ) >> >> add_custom_command( OUTPUT ${CMAKE_BINARY_DIR}/resources.kw >> COMMAND ${CMAKE_COMMAND} -E touch ${CMAKE_BINARY_DIR}/resources.kw >> ) >> INSTALL( FILES ${CMAKE_BINARY_DIR}/resources.kw DESTINATION bin ) >> >> >> add_custom_command( OUTPUT ${CMAKE_BINARY_DIR}/application.dat >> COMMAND ${CMAKE_COMMAND} -E touch ${CMAKE_BINARY_DIR}/application.dat >> ) >> INSTALL( FILES ${CMAKE_BINARY_DIR}/application.dat DESTINATION bin ) >> ------------ end CMakeLists.txt -------------- >> >> >> >> >> >> >> > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Tue Apr 7 14:17:02 2015 From: d3ck0r at gmail.com (J Decker) Date: Tue, 7 Apr 2015 11:17:02 -0700 Subject: [CMake] Custom target not triggered to build In-Reply-To: References: Message-ID: I actually have these in the original script.... ADD_CUSTOM_TARGET( generate_resources DEPENDS ${CMAKE_BINARY_DIR}/ resources.kw ) ADD_CUSTOM_TARGET( generate_application DEPENDS ${CMAKE_BINARY_DIR}/application.dat ) which gives me a target that builds in visual studio; and a target thaat can be called from make... in the tests it didn't complain when not having them.... but still now with these targets instead of just target files; I can't assign the targets as a dependant of package/install (consistantly on all platforms) I'm actually complaining that it's not building in visual studio, but I think maybe MinGW Makefiles it is building first. On Tue, Apr 7, 2015 at 11:05 AM, Robert Maynard wrote: > Add custom command doesn't generate a target. You need to use > add_custom_target to create an actual target. > > I believe what you are missing is a custom target that consume the output > of the add custom command, than the install should work. A fully contained > example that I could run would make solving this issue easier. > > On Tue, Apr 7, 2015 at 12:48 PM, J Decker wrote: > >> Am I incorrect in assuming that this should work? >> >> I added dependancies to them and that helped... until I leared I had the >> dependants wrong order, and it wouldn't let me depend the common on both of >> these... so when I reversed them, then neither built before install.... >> >> I recall a similar message not long ago about asking to depend targets on >> INSTALL... but I can't use install because it's a phony target. >> >> On Mon, Apr 6, 2015 at 5:26 PM, J Decker wrote: >> >>> I have a script that builds some package sort of files based on other >>> sources... >>> >>> Basically a simplified version... >>> I would think since the output file of add_custom_command was referenced >>> in a INSTALL that those targets should get build before INSTALL... but >>> using MinGW Makefiles, 'make install' fails to generate either file.... >>> >>> ------ CMakeLists.txt ------------- >>> cmake_minimum_required(VERSION 3.0) >>> >>> project( test ) >>> >>> add_custom_command( OUTPUT ${CMAKE_BINARY_DIR}/resources.kw >>> COMMAND ${CMAKE_COMMAND} -E touch ${CMAKE_BINARY_DIR}/resources.kw >>> ) >>> INSTALL( FILES ${CMAKE_BINARY_DIR}/resources.kw DESTINATION bin ) >>> >>> >>> add_custom_command( OUTPUT ${CMAKE_BINARY_DIR}/application.dat >>> COMMAND ${CMAKE_COMMAND} -E touch ${CMAKE_BINARY_DIR}/application.dat >>> ) >>> INSTALL( FILES ${CMAKE_BINARY_DIR}/application.dat DESTINATION bin ) >>> ------------ end CMakeLists.txt -------------- >>> >>> >>> >>> >>> >>> >>> >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.neundorf-work at gmx.net Tue Apr 7 15:46:31 2015 From: a.neundorf-work at gmx.net (Alexander Neundorf) Date: Tue, 07 Apr 2015 21:46:31 +0200 Subject: [CMake] Running custom executable In-Reply-To: References: Message-ID: <2874308.L69R2oBmWf@tuxedo.neundorf.net> On Monday, April 06, 2015 21:19:57 Klaim - Jo?l Lamotte wrote: > On Mon, Apr 6, 2015 at 8:47 PM, Daniel Dilts wrote: > > I have a custom executable that does some codegen to produce an > > enumeration and a couple of tables. I need this to be run against each > > source file before actual compilation. It needs include directories and > > macro definitions from the build system. > > > > Is there a way to do this with a CMake build system? add_custom_command > > seems like it might work, but I need all runs of the custom executable to > > run before compilation begins. > > execute_process() might be what you want: > http://www.cmake.org/cmake/help/v3.2/command/execute_process.html Hmmm, probably add_custom_command() or add_custom_target() is what he wants. Why does it have to run before the compilation begins ? Alex From d3ck0r at gmail.com Tue Apr 7 15:51:26 2015 From: d3ck0r at gmail.com (J Decker) Date: Tue, 7 Apr 2015 12:51:26 -0700 Subject: [CMake] Running custom executable In-Reply-To: <2874308.L69R2oBmWf@tuxedo.neundorf.net> References: <2874308.L69R2oBmWf@tuxedo.neundorf.net> Message-ID: On Tue, Apr 7, 2015 at 12:46 PM, Alexander Neundorf wrote: > On Monday, April 06, 2015 21:19:57 Klaim - Jo?l Lamotte wrote: > > On Mon, Apr 6, 2015 at 8:47 PM, Daniel Dilts wrote: > > > I have a custom executable that does some codegen to produce an > > > enumeration and a couple of tables. I need this to be run against each > > > source file before actual compilation. It needs include directories > and > > > macro definitions from the build system. > > > > > > Is there a way to do this with a CMake build system? > add_custom_command > > > seems like it might work, but I need all runs of the custom executable > to > > > run before compilation begins. > > > > execute_process() might be what you want: > > http://www.cmake.org/cmake/help/v3.2/command/execute_process.html > > > Hmmm, probably add_custom_command() or add_custom_target() is what he > wants. > Why does it have to run before the compilation begins ? > > thought-o uhmm... s/compilation/build of install/package targets/ actually needs to run after programs are built and before install... add_custom_command with also add_custom target do not make the targets automatically building install... got far enough in MinGW to find that it's the same and I have to 'make generate_resources generate_app install -j 8' to get it to work > Alex > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 steveire at gmail.com Tue Apr 7 15:55:31 2015 From: steveire at gmail.com (Stephen Kelly) Date: Tue, 07 Apr 2015 21:55:31 +0200 Subject: [CMake] Enable C++11 for a Target with Intel References: Message-ID: Robert Maynard wrote: > Currently the only compilers that support compiler features are: > > Apple Clang versions 4.4 though 6.1. > GNU compiler versions 4.4 through 5.0 on UNIX and Apple. > Microsoft Visual Studio versions 2010 through 2015. > Oracle SolarisStudio version 12.4. > > If you are interested in adding support for the intel compilers you can > look at: > Modules/SunPro-CXX-FeatureTests.cmake and > Modules/GNU-CXX-FeatureTests.cmake > Here's a starting point for someone sufficiently interested: https://github.com/steveire/CMake/commit/3f16f927235ebd91603f8314a8 However, I believe the compiler features vary by operating system, so more conditions would be needed. Thanks, Steve. From sstallion at gmail.com Tue Apr 7 15:59:58 2015 From: sstallion at gmail.com (Steven Stallion) Date: Tue, 7 Apr 2015 12:59:58 -0700 Subject: [CMake] External Packages? Message-ID: All, I'm currently working on a fairly large project that requires a number of external tools be installed. I've been playing with the idea of having CMake download and install these packages prior to building the project. I have something that works using a combination of custom modules and external projects, but I'm not quite satisfied. After trolling through the find_package documentation, I'm tempted to write a module that will download and install a CPack package hosted on an HTTP server. This is somewhat similar to the approach that neovim has taken, however I'd like to use the user package registry rather than CMAKE_CURRENT_BUILD_DIR; having some persistence would make life a bit better with multiple clones. I'm surprised that CMake doesn't have support for something like this already - does this ring a bell to anyone? If not, I'm tempted to put together an ExternalPackage module that would encapsulate this behavior, which should dovetail nicely with find_package and friends. Thoughts? Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From sstallion at gmail.com Tue Apr 7 16:10:32 2015 From: sstallion at gmail.com (Steven Stallion) Date: Tue, 7 Apr 2015 13:10:32 -0700 Subject: [CMake] External Packages? In-Reply-To: References: Message-ID: (Apologies for the self-reply) s/CMAKE_CURRENT_BUILD_DIR/CMAKE_CURRENT_BINARY_DIR/ On Tue, Apr 7, 2015 at 12:59 PM, Steven Stallion wrote: > All, > > I'm currently working on a fairly large project that requires a number of > external tools be installed. I've been playing with the idea of having > CMake download and install these packages prior to building the project. I > have something that works using a combination of custom modules and > external projects, but I'm not quite satisfied. > > After trolling through the find_package documentation, I'm tempted to > write a module that will download and install a CPack package hosted on an > HTTP server. This is somewhat similar to the approach that neovim has > taken, however I'd like to use the user package registry rather than > CMAKE_CURRENT_BUILD_DIR; having some persistence would make life a bit > better with multiple clones. > > I'm surprised that CMake doesn't have support for something like this > already - does this ring a bell to anyone? If not, I'm tempted to put > together an ExternalPackage module that would encapsulate this behavior, > which should dovetail nicely with find_package and friends. > > Thoughts? > > Steve > -------------- next part -------------- An HTML attachment was scrubbed... URL: From diltsman at gmail.com Tue Apr 7 16:22:30 2015 From: diltsman at gmail.com (Daniel Dilts) Date: Tue, 7 Apr 2015 13:22:30 -0700 Subject: [CMake] Running custom executable In-Reply-To: References: <2874308.L69R2oBmWf@tuxedo.neundorf.net> Message-ID: > > > > I have a custom executable that does some codegen to produce an >> > > enumeration and a couple of tables. I need this to be run against >> each >> > > source file before actual compilation. It needs include directories >> and >> > > macro definitions from the build system. >> > > >> > > Is there a way to do this with a CMake build system? >> add_custom_command >> > > seems like it might work, but I need all runs of the custom >> executable to >> > > run before compilation begins. >> > >> > execute_process() might be what you want: >> > http://www.cmake.org/cmake/help/v3.2/command/execute_process.html >> >> >> Hmmm, probably add_custom_command() or add_custom_target() is what he >> wants. >> Why does it have to run before the compilation begins ? >> > The program will run once per source file, scan them, and generate a header file that is necessary for compilation to succeed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.neundorf-work at gmx.net Tue Apr 7 16:37:27 2015 From: a.neundorf-work at gmx.net (Alexander Neundorf) Date: Tue, 07 Apr 2015 22:37:27 +0200 Subject: [CMake] Running custom executable In-Reply-To: References: Message-ID: <16811128.5BuG8mLqm0@tuxedo.neundorf.net> On Tuesday, April 07, 2015 13:22:30 you wrote: > > > > I have a custom executable that does some codegen to produce an > > > > > >> > > enumeration and a couple of tables. I need this to be run against > >> > >> each > >> > >> > > source file before actual compilation. It needs include directories > >> > >> and > >> > >> > > macro definitions from the build system. > >> > > > >> > > Is there a way to do this with a CMake build system? > >> > >> add_custom_command > >> > >> > > seems like it might work, but I need all runs of the custom > >> > >> executable to > >> > >> > > run before compilation begins. > >> > > >> > execute_process() might be what you want: > >> > http://www.cmake.org/cmake/help/v3.2/command/execute_process.html > >> > >> Hmmm, probably add_custom_command() or add_custom_target() is what he > >> wants. > >> Why does it have to run before the compilation begins ? > > The program will run once per source file, scan them, and generate a header > file that is necessary for compilation to succeed. You could create a add_custom_target(foo); make your actual target depend on it, so it is finished before the actual compilation starts using add_dependencies(). Alex From diltsman at gmail.com Tue Apr 7 18:24:18 2015 From: diltsman at gmail.com (Daniel Dilts) Date: Tue, 7 Apr 2015 15:24:18 -0700 Subject: [CMake] Running custom executable In-Reply-To: <16811128.5BuG8mLqm0@tuxedo.neundorf.net> References: <16811128.5BuG8mLqm0@tuxedo.neundorf.net> Message-ID: Looking at the way these things work, it seems to me that the ideal solution to my situation, if it is possible, is to do a add_custom_command() for each source file, and then do a add_custom_target() that has all of the custom commands as PRE_BUILD events. Is there a way to pass the list of files generated with the custom commands to the custom target? As command line arguments would be just fine. On Tue, Apr 7, 2015 at 1:37 PM, Alexander Neundorf wrote: > On Tuesday, April 07, 2015 13:22:30 you wrote: > > > > > I have a custom executable that does some codegen to produce an > > > > > > > >> > > enumeration and a couple of tables. I need this to be run against > > >> > > >> each > > >> > > >> > > source file before actual compilation. It needs include > directories > > >> > > >> and > > >> > > >> > > macro definitions from the build system. > > >> > > > > >> > > Is there a way to do this with a CMake build system? > > >> > > >> add_custom_command > > >> > > >> > > seems like it might work, but I need all runs of the custom > > >> > > >> executable to > > >> > > >> > > run before compilation begins. > > >> > > > >> > execute_process() might be what you want: > > >> > http://www.cmake.org/cmake/help/v3.2/command/execute_process.html > > >> > > >> Hmmm, probably add_custom_command() or add_custom_target() is what he > > >> wants. > > >> Why does it have to run before the compilation begins ? > > > > The program will run once per source file, scan them, and generate a > header > > file that is necessary for compilation to succeed. > > You could create a add_custom_target(foo); make your actual target depend > on > it, so it is finished before the actual compilation starts using > add_dependencies(). > > Alex > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Dave at Yost.com Tue Apr 7 20:37:14 2015 From: Dave at Yost.com (Dave Yost) Date: Tue, 7 Apr 2015 17:37:14 -0700 Subject: [CMake] commands Message-ID: <501CEAE2-FC0B-4469-8182-279D532E216E@yost.com> Learning and understanding cmake would be a lot easier if the cmake-commands page would have two columns. On the left, the alphabetic listing, available now. On the right, commands grouped by category. Here?s a category: if elseif else endif foreach endforeach while endwhile continue break function endfunction macro endmacro -------------- next part -------------- An HTML attachment was scrubbed... URL: From Micha.Renner at t-online.de Wed Apr 8 03:26:17 2015 From: Micha.Renner at t-online.de (Micha Renner) Date: Wed, 08 Apr 2015 09:26:17 +0200 Subject: [CMake] generator expressions Message-ID: <1428477977.5609.18.camel@t-online.de> Hi, I try to understand the concept of generator expressions with little avail. For the current project I thought, I could use them in combination with TARGET_INCLUDE_DIRECTORIES. Instead of writting IF(t1) TARGET_INCLUDE_DIRECTORIES(cTest PRIVATE path/to/h1 PRIVATE path/to/h2) ELSE(t1) TARGET_INCLUDE_DIRECTORIES(cTest PRIVATE path/to/h1) ENDIF(t1) it should be more elegant SET(t1 ON) ADD_EXECUTABLE(cTest CTest.c cTest.h) TARGET_INCLUDE_DIRECTORIES(cTest PRIVATE path/to/h1 $< $:"PRIVATE path/to/h2") Of course this creates a major disaster. -------------------------- CMake Warning (dev) in CMakeLists.txt: Policy CMP0021 is not set: Fatal error on relative paths in INCLUDE_DIRECTORIES target property. Run "cmake --help-policy CMP0021" for policy details. Use the cmake_policy command to set the policy and suppress this warning. Found relative path while evaluating include directories of "cTest": ""PRIVATE path/to/h2"" This warning is for project developers. Use -Wno-dev to suppress it. cmake: /home/gildemeister/Picture/work-c/CMakeSrc/cmake-3.2.1/Source/cmLocalGenerator.cxx:2923: std::string cmLocalGenerator::ConvertToRelativePath(const std::vector >&, const string&, bool): Assertion `in_remote[0] != '\"'' failed. Abgebrochen (Speicherabzug geschrieben) -------------------------- Is there a way to solve this with a generator expression? Michael From robert.maynard at kitware.com Wed Apr 8 11:34:34 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 8 Apr 2015 11:34:34 -0400 Subject: [CMake] generator expressions In-Reply-To: <1428477977.5609.18.camel@t-online.de> References: <1428477977.5609.18.camel@t-online.de> Message-ID: Hi Micha, When using generator expressions inside target_include_directories you must qualify all paths. Either by using absolute paths, or using one of the helper variables that allows CMake to determine where the relative path should be evaluated from. This is all really well documented at: http://www.cmake.org/cmake/help/v3.2/manual/cmake-buildsystem.7.html#include-directories-and-usage-requirements On Wed, Apr 8, 2015 at 3:26 AM, Micha Renner wrote: > Hi, > > I try to understand the concept of generator expressions with little > avail. > > For the current project I thought, I could use them in combination with > TARGET_INCLUDE_DIRECTORIES. > Instead of writting > IF(t1) > TARGET_INCLUDE_DIRECTORIES(cTest PRIVATE path/to/h1 PRIVATE > path/to/h2) > ELSE(t1) > TARGET_INCLUDE_DIRECTORIES(cTest PRIVATE path/to/h1) > ENDIF(t1) > > it should be more elegant > > SET(t1 ON) > ADD_EXECUTABLE(cTest CTest.c cTest.h) > TARGET_INCLUDE_DIRECTORIES(cTest PRIVATE path/to/h1 $< > $:"PRIVATE path/to/h2") > > Of course this creates a major disaster. > > -------------------------- > CMake Warning (dev) in CMakeLists.txt: > Policy CMP0021 is not set: Fatal error on relative paths in > INCLUDE_DIRECTORIES target property. Run "cmake --help-policy > CMP0021" for > policy details. Use the cmake_policy command to set the policy and > suppress this warning. > > Found relative path while evaluating include directories of "cTest": > > ""PRIVATE path/to/h2"" > > This warning is for project developers. Use -Wno-dev to suppress it. > > cmake: > /home/gildemeister/Picture/work-c/CMakeSrc/cmake-3.2.1/Source/cmLocalGenerator.cxx:2923: > std::string cmLocalGenerator::ConvertToRelativePath(const > std::vector >&, const string&, bool): Assertion > `in_remote[0] != '\"'' failed. > Abgebrochen (Speicherabzug geschrieben) > -------------------------- > > Is there a way to solve this with a generator expression? > > Michael > > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.neundorf-work at gmx.net Wed Apr 8 16:12:56 2015 From: a.neundorf-work at gmx.net (Alexander Neundorf) Date: Wed, 08 Apr 2015 22:12:56 +0200 Subject: [CMake] Running custom executable In-Reply-To: References: <16811128.5BuG8mLqm0@tuxedo.neundorf.net> Message-ID: <8878782.7aHBxJ5CKH@tuxedo.neundorf.net> On Tuesday, April 07, 2015 15:24:18 Daniel Dilts wrote: > Looking at the way these things work, it seems to me that the ideal > solution to my situation, if it is possible, is to do a > add_custom_command() for each source file, and then do a > add_custom_target() that has all of the custom commands as PRE_BUILD events. No, PRE_BUILD works only for Visual Studio generators according to the docs. I think you need to give the list of output files generated using add_custom_command() as DEPENDS to add_custom_target(). Alex From ruslan_baratov at yahoo.com Wed Apr 8 16:56:32 2015 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Wed, 08 Apr 2015 22:56:32 +0200 Subject: [CMake] Default INTERFACE_POSITION_INDEPENDENT_CODE value for static library Message-ID: <55259600.8050609@yahoo.com> Hi, I've got next error while trying to link static library to shared one on Linux: /usr/bin/ld: ...: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC This error can be detected on CMake configure step instead of linker stage if I add next code: set_property(TARGET ... PROPERTY INTERFACE_POSITION_INDEPENDENT_CODE YES) in this case error message is: CMake Error: Property POSITION_INDEPENDENT_CODE on target "..." does not match the INTERFACE_POSITION_INDEPENDENT_CODE property requirement of dependency "...". because there is POSITION_INDEPENDENT_CODE=YES default value for shared library. So I wonder why there is no default value INTERFACE_POSITION_INDEPENDENT_CODE=NO for static one? Thanks, Ruslo From diltsman at gmail.com Wed Apr 8 17:06:41 2015 From: diltsman at gmail.com (Daniel Dilts) Date: Wed, 8 Apr 2015 14:06:41 -0700 Subject: [CMake] Running custom executable In-Reply-To: <8878782.7aHBxJ5CKH@tuxedo.neundorf.net> References: <16811128.5BuG8mLqm0@tuxedo.neundorf.net> <8878782.7aHBxJ5CKH@tuxedo.neundorf.net> Message-ID: The issue with the add_custom_command() and DEPENDS is that the custom commands will be in CMakeLists.txt files throughout the solution, and it appears to indicate that that form only works with a target created in the same directory. On Wed, Apr 8, 2015 at 1:12 PM, Alexander Neundorf wrote: > On Tuesday, April 07, 2015 15:24:18 Daniel Dilts wrote: > > Looking at the way these things work, it seems to me that the ideal > > solution to my situation, if it is possible, is to do a > > add_custom_command() for each source file, and then do a > > add_custom_target() that has all of the custom commands as PRE_BUILD > events. > > No, PRE_BUILD works only for Visual Studio generators according to the > docs. > > I think you need to give the list of output files generated using > add_custom_command() as DEPENDS to add_custom_target(). > > Alex > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Dave at Yost.com Wed Apr 8 17:21:16 2015 From: Dave at Yost.com (Dave Yost) Date: Wed, 8 Apr 2015 14:21:16 -0700 Subject: [CMake] no convenience target for generated files? Message-ID: <041437DD-A473-4C32-A97F-28D3C9B74636@yost.com> I?m using add_custom_command to generate a file, ?bar.cc?. It would be convenient if I could say make bar.cc or make bar/bar.cc but neither of these work, and I can?t see a target in the Makefiles that I can use. There is a way to make bar.cc.o, but not bar.cc 0 Wed 14:15:54 yost DaveBook ~/p/c++/cmake/target-for-generate 241 Z% bundle `findf *` [ find CMakeLists.txt bar foo.cc -type f ] #!/usr/bin/env unbundle # See http://yost.com/computers/bundle/ ======== CMakeLists.txt cmake_minimum_required(VERSION 3.2.1) project(yost-cmake-example) add_subdirectory(bar) add_executable (foo foo.cc) target_link_libraries(foo bar) ======== bar/bar.hh extern char* str1; ======== bar/CMakeLists.txt add_executable(genBar genBar.cc) add_custom_command( OUTPUT bar.cc COMMAND genBar > bar.cc DEPENDS genBar) add_library (bar SHARED bar.cc) target_include_directories(bar PUBLIC .) ======== bar/genBar.cc #include int main(int argc, char** argv) { std::cout << "#include \"bar.hh\"\n\n" "char str1array[] = \"Hello!\";\n" "char* str1 = str1array;\n"; return 0; } ======== foo.cc #include #include int main(int argc, char** argv) { std::cout << str1 << std::endl; return 0; } ======== 0 Wed 14:15:57 yost DaveBook ~/p/c++/cmake/target-for-generate 242 Z% mkdir build 0 Wed 14:16:02 yost DaveBook ~/p/c++/cmake/target-for-generate 243 Z% cd build 0 Wed 14:16:03 yost DaveBook ~/p/c++/cmake/target-for-generate/build 244 Z% cmake .. -- The C compiler identification is AppleClang 6.0.0.6000057 -- The CXX compiler identification is AppleClang 6.0.0.6000057 -- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Configuring done -- Generating done -- Build files have been written to: /Users/yost/p/c++/cmake/target-for-generate/build 0 Wed 14:16:07 yost DaveBook ~/p/c++/cmake/target-for-generate/build 245 Z% make Scanning dependencies of target genBar [ 14%] Building CXX object bar/CMakeFiles/genBar.dir/genBar.cc.o [ 28%] Linking CXX executable genBar [ 28%] Built target genBar [ 42%] Generating bar.cc Scanning dependencies of target bar [ 57%] Building CXX object bar/CMakeFiles/bar.dir/bar.cc.o [ 71%] Linking CXX shared library libbar.dylib [ 71%] Built target bar Scanning dependencies of target foo [ 85%] Building CXX object CMakeFiles/foo.dir/foo.cc.o [100%] Linking CXX executable foo [100%] Built target foo 0 Wed 14:16:09 yost DaveBook ~/p/c++/cmake/target-for-generate/build 246 Z% rm bar/bar.cc 0 Wed 14:16:15 yost DaveBook ~/p/c++/cmake/target-for-generate/build 247 Z% make bar/bar.cc make: *** No rule to make target `bar/bar.cc'. Stop. 2 Wed 14:16:24 yost DaveBook ~/p/c++/cmake/target-for-generate/build 248 Z% make bar.cc make: *** No rule to make target `bar.cc'. Stop. 2 Wed 14:16:27 yost DaveBook ~/p/c++/cmake/target-for-generate/build 249 Z% cd bar 0 Wed 14:19:20 yost DaveBook ~/p/c++/cmake/target-for-generate/build/bar 253 Z% make bar.cc make: *** No rule to make target `bar.cc'. Stop. 2 Wed 14:19:22 yost DaveBook ~/p/c++/cmake/target-for-generate/build/bar 254 Z% make bar.cc.o Generating bar.cc Building CXX object bar/CMakeFiles/bar.dir/bar.cc.o 0 Wed 14:19:25 yost DaveBook ~/p/c++/cmake/target-for-generate/build/bar 255 Z% -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob.a.mcdonald at gmail.com Wed Apr 8 18:44:08 2015 From: rob.a.mcdonald at gmail.com (Rob McDonald) Date: Wed, 8 Apr 2015 15:44:08 -0700 Subject: [CMake] FindOpenMP not working on VS2010 Pro Message-ID: For some reason, FindOpenMP succeeds -- but reports failure for me on Visual Studio 2010 Pro. This is with the latest CMake just in case... 1> -- Try OpenMP C flag = [/openmp] 1> -- Performing Test OpenMP_FLAG_DETECTED 1> -- Performing Test OpenMP_FLAG_DETECTED - Success 1> -- Try OpenMP CXX flag = [/openmp] 1> -- Performing Test OpenMP_FLAG_DETECTED 1> -- Performing Test OpenMP_FLAG_DETECTED - Success 1> -- Could NOT find OpenMP (missing: OpenMP_C_FLAGS OpenMP_CXX_FLAGS) Any suggestions? From rob.a.mcdonald at gmail.com Wed Apr 8 19:01:25 2015 From: rob.a.mcdonald at gmail.com (Rob McDonald) Date: Wed, 8 Apr 2015 16:01:25 -0700 Subject: [CMake] FindOpenMP not working on VS2010 Pro In-Reply-To: References: Message-ID: Sorry for the noise. My Cache had variables leftover from VS 2010 Express. Thanks, Rob On Wed, Apr 8, 2015 at 3:44 PM, Rob McDonald wrote: > For some reason, FindOpenMP succeeds -- but reports failure for me on > Visual Studio 2010 Pro. This is with the latest CMake just in case... > > 1> -- Try OpenMP C flag = [/openmp] > 1> -- Performing Test OpenMP_FLAG_DETECTED > 1> -- Performing Test OpenMP_FLAG_DETECTED - Success > 1> -- Try OpenMP CXX flag = [/openmp] > 1> -- Performing Test OpenMP_FLAG_DETECTED > 1> -- Performing Test OpenMP_FLAG_DETECTED - Success > 1> -- Could NOT find OpenMP (missing: OpenMP_C_FLAGS OpenMP_CXX_FLAGS) > > > Any suggestions? From DLRdave at aol.com Wed Apr 8 23:05:48 2015 From: DLRdave at aol.com (David Cole) Date: Wed, 8 Apr 2015 23:05:48 -0400 Subject: [CMake] no convenience target for generated files? In-Reply-To: <041437DD-A473-4C32-A97F-28D3C9B74636@yost.com> References: <041437DD-A473-4C32-A97F-28D3C9B74636@yost.com> Message-ID: Does cd bar make help Tell you anything? On Wednesday, April 8, 2015, Dave Yost wrote: > I?m using add_custom_command to generate a file, ?bar.cc?. > > It would be convenient if I could say > make bar.cc > or > make bar/bar.cc > but neither of these work, and I can?t see a target in the Makefiles that > I can use. > > There is a way to make bar.cc.o, but not bar.cc > > 0 Wed 14:15:54 yost DaveBook ~/p/c++/cmake/target-for-generate > 241 Z% bundle `findf *` > [ find CMakeLists.txt bar foo.cc -type f ] > #!/usr/bin/env unbundle > # See http://yost.com/computers/bundle/ > ======== CMakeLists.txt > cmake_minimum_required(VERSION 3.2.1) > > project(yost-cmake-example) > > add_subdirectory(bar) > > add_executable (foo foo.cc) > target_link_libraries(foo bar) > > ======== bar/bar.hh > extern char* str1; > > ======== bar/CMakeLists.txt > > add_executable(genBar genBar.cc) > > add_custom_command( > OUTPUT bar.cc > COMMAND genBar > bar.cc > DEPENDS genBar) > > add_library (bar SHARED bar.cc) > target_include_directories(bar PUBLIC .) > > ======== bar/genBar.cc > #include > > int main(int argc, char** argv) { > std::cout > << "#include \"bar.hh\"\n\n" > "char str1array[] = \"Hello!\";\n" > "char* str1 = str1array;\n"; > return 0; > } > > ======== foo.cc > #include > #include > > int main(int argc, char** argv) { > std::cout << str1 << std::endl; > return 0; > } > > ======== > 0 Wed 14:15:57 yost DaveBook ~/p/c++/cmake/target-for-generate > 242 Z% mkdir build > 0 Wed 14:16:02 yost DaveBook ~/p/c++/cmake/target-for-generate > 243 Z% cd build > 0 Wed 14:16:03 yost DaveBook ~/p/c++/cmake/target-for-generate/build > 244 Z% cmake .. > -- The C compiler identification is AppleClang 6.0.0.6000057 > -- The CXX compiler identification is AppleClang 6.0.0.6000057 > -- Check for working C compiler: > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc > -- Check for working C compiler: > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc > -- works > -- Detecting C compiler ABI info > -- Detecting C compiler ABI info - done > -- Detecting C compile features > -- Detecting C compile features - done > -- Check for working CXX compiler: > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ > -- Check for working CXX compiler: > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ > -- works > -- Detecting CXX compiler ABI info > -- Detecting CXX compiler ABI info - done > -- Detecting CXX compile features > -- Detecting CXX compile features - done > -- Configuring done > -- Generating done > -- Build files have been written to: > /Users/yost/p/c++/cmake/target-for-generate/build > 0 Wed 14:16:07 yost DaveBook ~/p/c++/cmake/target-for-generate/build > 245 Z% make > Scanning dependencies of target genBar > [ 14%] Building CXX object bar/CMakeFiles/genBar.dir/genBar.cc.o > [ 28%] Linking CXX executable genBar > [ 28%] Built target genBar > [ 42%] Generating bar.cc > Scanning dependencies of target bar > [ 57%] Building CXX object bar/CMakeFiles/bar.dir/bar.cc.o > [ 71%] Linking CXX shared library libbar.dylib > [ 71%] Built target bar > Scanning dependencies of target foo > [ 85%] Building CXX object CMakeFiles/foo.dir/foo.cc.o > [100%] Linking CXX executable foo > [100%] Built target foo > 0 Wed 14:16:09 yost DaveBook ~/p/c++/cmake/target-for-generate/build > 246 Z% rm bar/bar.cc > 0 Wed 14:16:15 yost DaveBook ~/p/c++/cmake/target-for-generate/build > 247 Z% make bar/bar.cc > make: *** No rule to make target `bar/bar.cc'. Stop. > 2 Wed 14:16:24 yost DaveBook ~/p/c++/cmake/target-for-generate/build > 248 Z% make bar.cc > make: *** No rule to make target `bar.cc'. Stop. > 2 Wed 14:16:27 yost DaveBook ~/p/c++/cmake/target-for-generate/build > 249 Z% cd bar > 0 Wed 14:19:20 yost DaveBook ~/p/c++/cmake/target-for-generate/build/bar > 253 Z% make bar.cc > make: *** No rule to make target `bar.cc'. Stop. > 2 Wed 14:19:22 yost DaveBook ~/p/c++/cmake/target-for-generate/build/bar > 254 Z% make bar.cc.o > Generating bar.cc > Building CXX object bar/CMakeFiles/bar.dir/bar.cc.o > 0 Wed 14:19:25 yost DaveBook ~/p/c++/cmake/target-for-generate/build/bar > 255 Z% > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cedric.doucet at inria.fr Thu Apr 9 05:17:32 2015 From: cedric.doucet at inria.fr (Cedric Doucet) Date: Thu, 9 Apr 2015 11:17:32 +0200 (CEST) Subject: [CMake] What is the purpose of INSTALL_DIR in ExternalProject_Add command? In-Reply-To: <1428477977.5609.18.camel@t-online.de> References: <1428477977.5609.18.camel@t-online.de> Message-ID: <1790921270.1066962.1428571052188.JavaMail.zimbra@inria.fr> Hello! I try to download, extract, configure, build and install a library with CMake. My CMakeLists.txt contains the following lines: cmake_minimum_required (VERSION 2.6) project (example CXX) set(CMAKE_VERBOSE_MAKEFILE ON) include(ExternalProject) include(ProcessorCount) ProcessorCount(N) if(NOT N EQUAL 0) set(CMAKE_BUILD_FLAGS -j${N}) endif() ExternalProject_Add(eigen PREFIX third_party DOWNLOAD_DIR third_party/eigen/download SOURCE_DIR third_party/eigen/src BINARY_DIR third_party/eigen/build INSTALL_DIR third_party/eigen/install DOWNLOAD_COMMAND wget http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz && tar xvzf 3.2.4.tar.gz -C ../src --strip-components=1 ) In this example, the installation step fails with the following error message: CMake Error at cmake_install.cmake:38 (FILE): file cannot create directory: /usr/local/include/eigen3. Maybe need administrative privileges. It means that the value of INSTALL_DIR is not taken into account during the configuration process. Why? What am I do wrong? Thank you very much for your help. Best regards, C?dric Doucet From DLRdave at aol.com Thu Apr 9 06:44:34 2015 From: DLRdave at aol.com (David Cole) Date: Thu, 9 Apr 2015 06:44:34 -0400 Subject: [CMake] What is the purpose of INSTALL_DIR in ExternalProject_Add command? In-Reply-To: <1790921270.1066962.1428571052188.JavaMail.zimbra@inria.fr> References: <1428477977.5609.18.camel@t-online.de> <1790921270.1066962.1428571052188.JavaMail.zimbra@inria.fr> Message-ID: You need to tell eigen where to install, probably as an argument to its configure step. If it builds with CMake, you can use: -DCMAKE_INSTALL_PREFIX= as one of the CMake args. If it has a non-CMake configure step, you'll have to call that and pass in as an argument. HTH, David C. On Thursday, April 9, 2015, Cedric Doucet wrote: > > Hello! > > I try to download, extract, configure, build and install a library with > CMake. > My CMakeLists.txt contains the following lines: > > cmake_minimum_required (VERSION 2.6) > project (example CXX) > set(CMAKE_VERBOSE_MAKEFILE ON) > include(ExternalProject) > include(ProcessorCount) > ProcessorCount(N) > if(NOT N EQUAL 0) > set(CMAKE_BUILD_FLAGS -j${N}) > endif() > ExternalProject_Add(eigen > PREFIX third_party > DOWNLOAD_DIR third_party/eigen/download > SOURCE_DIR third_party/eigen/src > BINARY_DIR third_party/eigen/build > INSTALL_DIR third_party/eigen/install > DOWNLOAD_COMMAND wget > http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz && tar xvzf > 3.2.4.tar.gz -C ../src --strip-components=1 > ) > > In this example, the installation step fails with the following error > message: > > CMake Error at cmake_install.cmake:38 (FILE): > file cannot create directory: /usr/local/include/eigen3. Maybe need > administrative privileges. > > It means that the value of INSTALL_DIR is not taken into account during > the configuration process. > > Why? What am I do wrong? > > Thank you very much for your help. > > Best regards, > > C?dric Doucet > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iosif.neitzke+cmake at gmail.com Thu Apr 9 06:54:28 2015 From: iosif.neitzke+cmake at gmail.com (Iosif Neitzke) Date: Thu, 9 Apr 2015 05:54:28 -0500 Subject: [CMake] What is the purpose of INSTALL_DIR in ExternalProject_Add command? In-Reply-To: References: <1428477977.5609.18.camel@t-online.de> <1790921270.1066962.1428571052188.JavaMail.zimbra@inria.fr> Message-ID: Install Step The INSTALL_DIR is underneath the calling project?s binary directory. Use INSTALL_DIR to specify a different location. Note that in addition to setting INSTALL_DIR, you also have to pass -DCMAKE_INSTALL_PREFIX or --prefix to the CMake or configure command. It is not used automatically in the configure step since not all projects follow this convention. >From http://www.kitware.com/media/html/BuildingExternalProjectsWithCMake2.8.html On Thu, Apr 9, 2015 at 5:44 AM, David Cole via CMake wrote: > You need to tell eigen where to install, probably as an argument to its > configure step. If it builds with CMake, you can use: > > -DCMAKE_INSTALL_PREFIX= > > as one of the CMake args. If it has a non-CMake configure step, you'll have > to call that and pass in as an argument. > > > HTH, > David C. > > > On Thursday, April 9, 2015, Cedric Doucet wrote: >> >> >> Hello! >> >> I try to download, extract, configure, build and install a library with >> CMake. >> My CMakeLists.txt contains the following lines: >> >> cmake_minimum_required (VERSION 2.6) >> project (example CXX) >> set(CMAKE_VERBOSE_MAKEFILE ON) >> include(ExternalProject) >> include(ProcessorCount) >> ProcessorCount(N) >> if(NOT N EQUAL 0) >> set(CMAKE_BUILD_FLAGS -j${N}) >> endif() >> ExternalProject_Add(eigen >> PREFIX third_party >> DOWNLOAD_DIR third_party/eigen/download >> SOURCE_DIR third_party/eigen/src >> BINARY_DIR third_party/eigen/build >> INSTALL_DIR third_party/eigen/install >> DOWNLOAD_COMMAND wget >> http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz && tar xvzf 3.2.4.tar.gz >> -C ../src --strip-components=1 >> ) >> >> In this example, the installation step fails with the following error >> message: >> >> CMake Error at cmake_install.cmake:38 (FILE): >> file cannot create directory: /usr/local/include/eigen3. Maybe need >> administrative privileges. >> >> It means that the value of INSTALL_DIR is not taken into account during >> the configuration process. >> >> Why? What am I do wrong? >> >> Thank you very much for your help. >> >> Best regards, >> >> C?dric Doucet >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From cedric.doucet at inria.fr Thu Apr 9 07:07:41 2015 From: cedric.doucet at inria.fr (Cedric Doucet) Date: Thu, 9 Apr 2015 13:07:41 +0200 (CEST) Subject: [CMake] What is the purpose of INSTALL_DIR in ExternalProject_Add command? In-Reply-To: References: <1428477977.5609.18.camel@t-online.de> <1790921270.1066962.1428571052188.JavaMail.zimbra@inria.fr> Message-ID: <771308217.1173749.1428577661399.JavaMail.zimbra@inria.fr> Hello Iosif and David, thank you for your answer. I now understand how it works. But I still don't understand the purpose of INSTALL_DIR. Do you know an example when this variable is useful? C?dric ----- Mail original ----- > De: "Iosif Neitzke" > ?: cmake at cmake.org > Envoy?: Jeudi 9 Avril 2015 12:54:28 > Objet: Re: [CMake] What is the purpose of INSTALL_DIR in ExternalProject_Add command? > > Install Step > The INSTALL_DIR is underneath the calling project?s binary directory. > Use INSTALL_DIR to specify a different location. Note that in addition > to setting INSTALL_DIR, you also have to pass -DCMAKE_INSTALL_PREFIX > or --prefix to the CMake or configure command. It is not used > automatically in the configure step since not all projects follow this > convention. > > From > http://www.kitware.com/media/html/BuildingExternalProjectsWithCMake2.8.html > > On Thu, Apr 9, 2015 at 5:44 AM, David Cole via CMake wrote: > > You need to tell eigen where to install, probably as an argument to its > > configure step. If it builds with CMake, you can use: > > > > -DCMAKE_INSTALL_PREFIX= > > > > as one of the CMake args. If it has a non-CMake configure step, you'll have > > to call that and pass in as an argument. > > > > > > HTH, > > David C. > > > > > > On Thursday, April 9, 2015, Cedric Doucet wrote: > >> > >> > >> Hello! > >> > >> I try to download, extract, configure, build and install a library with > >> CMake. > >> My CMakeLists.txt contains the following lines: > >> > >> cmake_minimum_required (VERSION 2.6) > >> project (example CXX) > >> set(CMAKE_VERBOSE_MAKEFILE ON) > >> include(ExternalProject) > >> include(ProcessorCount) > >> ProcessorCount(N) > >> if(NOT N EQUAL 0) > >> set(CMAKE_BUILD_FLAGS -j${N}) > >> endif() > >> ExternalProject_Add(eigen > >> PREFIX third_party > >> DOWNLOAD_DIR third_party/eigen/download > >> SOURCE_DIR third_party/eigen/src > >> BINARY_DIR third_party/eigen/build > >> INSTALL_DIR third_party/eigen/install > >> DOWNLOAD_COMMAND wget > >> http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz && tar xvzf 3.2.4.tar.gz > >> -C ../src --strip-components=1 > >> ) > >> > >> In this example, the installation step fails with the following error > >> message: > >> > >> CMake Error at cmake_install.cmake:38 (FILE): > >> file cannot create directory: /usr/local/include/eigen3. Maybe need > >> administrative privileges. > >> > >> It means that the value of INSTALL_DIR is not taken into account during > >> the configuration process. > >> > >> Why? What am I do wrong? > >> > >> Thank you very much for your help. > >> > >> Best regards, > >> > >> C?dric Doucet > >> -- > >> > >> Powered by www.kitware.com > >> > >> Please keep messages on-topic and check the CMake FAQ at: > >> http://www.cmake.org/Wiki/CMake_FAQ > >> > >> Kitware offers various services to support the CMake community. For more > >> information on each offering, please visit: > >> > >> CMake Support: http://cmake.org/cmake/help/support.html > >> CMake Consulting: http://cmake.org/cmake/help/consulting.html > >> CMake Training Courses: http://cmake.org/cmake/help/training.html > >> > >> Visit other Kitware open-source projects at > >> http://www.kitware.com/opensource/opensource.html > >> > >> Follow this link to subscribe/unsubscribe: > >> http://public.kitware.com/mailman/listinfo/cmake > > > > > > -- > > > > Powered by www.kitware.com > > > > Please keep messages on-topic and check the CMake FAQ at: > > http://www.cmake.org/Wiki/CMake_FAQ > > > > Kitware offers various services to support the CMake community. For more > > information on each offering, please visit: > > > > CMake Support: http://cmake.org/cmake/help/support.html > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/cmake > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From ryan.pavlik at gmail.com Thu Apr 9 07:26:01 2015 From: ryan.pavlik at gmail.com (Ryan Pavlik) Date: Thu, 09 Apr 2015 11:26:01 +0000 Subject: [CMake] What is the purpose of INSTALL_DIR in ExternalProject_Add command? In-Reply-To: <771308217.1173749.1428577661399.JavaMail.zimbra@inria.fr> References: <1428477977.5609.18.camel@t-online.de> <1790921270.1066962.1428571052188.JavaMail.zimbra@inria.fr> <771308217.1173749.1428577661399.JavaMail.zimbra@inria.fr> Message-ID: It's for if your use case requires the project to be installed in a specific location that's not the automatically generated one. For instance, if you're building multiple external projects you might have them all install to the same subdirectory of the binary directory for convenience. Ryan On Thu, Apr 9, 2015, 6:07 AM Cedric Doucet wrote: > > Hello Iosif and David, > > thank you for your answer. > I now understand how it works. > But I still don't understand the purpose of INSTALL_DIR. > Do you know an example when this variable is useful? > > C?dric > > > > > ----- Mail original ----- > > De: "Iosif Neitzke" > > ?: cmake at cmake.org > > Envoy?: Jeudi 9 Avril 2015 12:54:28 > > Objet: Re: [CMake] What is the purpose of INSTALL_DIR in > ExternalProject_Add command? > > > > Install Step > > The INSTALL_DIR is underneath the calling project?s binary directory. > > Use INSTALL_DIR to specify a different location. Note that in addition > > to setting INSTALL_DIR, you also have to pass -DCMAKE_INSTALL_PREFIX > > or --prefix to the CMake or configure command. It is not used > > automatically in the configure step since not all projects follow this > > convention. > > > > From > > http://www.kitware.com/media/html/BuildingExternalProjectsWithCM > ake2.8.html > > > > On Thu, Apr 9, 2015 at 5:44 AM, David Cole via CMake > wrote: > > > You need to tell eigen where to install, probably as an argument to its > > > configure step. If it builds with CMake, you can use: > > > > > > -DCMAKE_INSTALL_PREFIX= > > > > > > as one of the CMake args. If it has a non-CMake configure step, you'll > have > > > to call that and pass in as an argument. > > > > > > > > > HTH, > > > David C. > > > > > > > > > On Thursday, April 9, 2015, Cedric Doucet > wrote: > > >> > > >> > > >> Hello! > > >> > > >> I try to download, extract, configure, build and install a library > with > > >> CMake. > > >> My CMakeLists.txt contains the following lines: > > >> > > >> cmake_minimum_required (VERSION 2.6) > > >> project (example CXX) > > >> set(CMAKE_VERBOSE_MAKEFILE ON) > > >> include(ExternalProject) > > >> include(ProcessorCount) > > >> ProcessorCount(N) > > >> if(NOT N EQUAL 0) > > >> set(CMAKE_BUILD_FLAGS -j${N}) > > >> endif() > > >> ExternalProject_Add(eigen > > >> PREFIX third_party > > >> DOWNLOAD_DIR third_party/eigen/download > > >> SOURCE_DIR third_party/eigen/src > > >> BINARY_DIR third_party/eigen/build > > >> INSTALL_DIR third_party/eigen/install > > >> DOWNLOAD_COMMAND wget > > >> http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz && tar xvzf > 3.2.4.tar.gz > > >> -C ../src --strip-components=1 > > >> ) > > >> > > >> In this example, the installation step fails with the following error > > >> message: > > >> > > >> CMake Error at cmake_install.cmake:38 (FILE): > > >> file cannot create directory: /usr/local/include/eigen3. Maybe need > > >> administrative privileges. > > >> > > >> It means that the value of INSTALL_DIR is not taken into account > during > > >> the configuration process. > > >> > > >> Why? What am I do wrong? > > >> > > >> Thank you very much for your help. > > >> > > >> Best regards, > > >> > > >> C?dric Doucet > > >> -- > > >> > > >> Powered by www.kitware.com > > >> > > >> Please keep messages on-topic and check the CMake FAQ at: > > >> http://www.cmake.org/Wiki/CMake_FAQ > > >> > > >> Kitware offers various services to support the CMake community. For > more > > >> information on each offering, please visit: > > >> > > >> CMake Support: http://cmake.org/cmake/help/support.html > > >> CMake Consulting: http://cmake.org/cmake/help/consulting.html > > >> CMake Training Courses: http://cmake.org/cmake/help/training.html > > >> > > >> Visit other Kitware open-source projects at > > >> http://www.kitware.com/opensource/opensource.html > > >> > > >> Follow this link to subscribe/unsubscribe: > > >> http://public.kitware.com/mailman/listinfo/cmake > > > > > > > > > -- > > > > > > Powered by www.kitware.com > > > > > > Please keep messages on-topic and check the CMake FAQ at: > > > http://www.cmake.org/Wiki/CMake_FAQ > > > > > > Kitware offers various services to support the CMake community. For > more > > > information on each offering, please visit: > > > > > > CMake Support: http://cmake.org/cmake/help/support.html > > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > > > > Visit other Kitware open-source projects at > > > http://www.kitware.com/opensource/opensource.html > > > > > > Follow this link to subscribe/unsubscribe: > > > http://public.kitware.com/mailman/listinfo/cmake > > -- > > > > Powered by www.kitware.com > > > > Please keep messages on-topic and check the CMake FAQ at: > > http://www.cmake.org/Wiki/CMake_FAQ > > > > Kitware offers various services to support the CMake community. For more > > information on each offering, please visit: > > > > CMake Support: http://cmake.org/cmake/help/support.html > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/cmake > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From cedric.doucet at inria.fr Thu Apr 9 07:35:55 2015 From: cedric.doucet at inria.fr (Cedric Doucet) Date: Thu, 9 Apr 2015 13:35:55 +0200 (CEST) Subject: [CMake] What is the purpose of INSTALL_DIR in ExternalProject_Add command? In-Reply-To: References: <1428477977.5609.18.camel@t-online.de> <1790921270.1066962.1428571052188.JavaMail.zimbra@inria.fr> <771308217.1173749.1428577661399.JavaMail.zimbra@inria.fr> Message-ID: <1790657952.1179125.1428579355752.JavaMail.zimbra@inria.fr> Hello Ryan, thank you for your answer. If I understand it well, this exactly what I want. I want third-party libraries to be installed in a specific location which does not correspond to the automatically generated one. To do that, I can provide my own configuration command to install in MYDIR: - for autoconfig: CONFIGURE_COMMAND ./configure --prefix=${MYDIR} - for cmake: CONFIGURE_COMMAND cmake -D CMAKE_INSTALL_PREFIX=${MYDIR} But, in this case, I don't use, and I do not have to use, the value of INSTALL_DIR. Furhtermore, if I want to use INSTALL_DIR, I still need to provide my own configuration command. So, my question is: what is INSTALL_DIR useful for? Do you have an example where INSTALL_DIR is used without providing its own configuration command? Because, if I need to provide such a command, INSTALL_DIR is useless. C?dric ----- Mail original ----- > De: "Ryan Pavlik" > ?: "Cedric Doucet" , "Iosif Neitzke" > > Cc: cmake at cmake.org > Envoy?: Jeudi 9 Avril 2015 13:26:01 > Objet: Re: [CMake] What is the purpose of INSTALL_DIR in ExternalProject_Add > command? > It's for if your use case requires the project to be installed in a specific > location that's not the automatically generated one. For instance, if you're > building multiple external projects you might have them all install to the > same subdirectory of the binary directory for convenience. > Ryan > On Thu, Apr 9, 2015, 6:07 AM Cedric Doucet < cedric.doucet at inria.fr > wrote: > > Hello Iosif and David, > > > thank you for your answer. > > > I now understand how it works. > > > But I still don't understand the purpose of INSTALL_DIR. > > > Do you know an example when this variable is useful? > > > C?dric > > > ----- Mail original ----- > > > > De: "Iosif Neitzke" < iosif.neitzke+cmake at gmail.com > > > > > ?: cmake at cmake.org > > > > Envoy?: Jeudi 9 Avril 2015 12:54:28 > > > > Objet: Re: [CMake] What is the purpose of INSTALL_DIR in > > > ExternalProject_Add command? > > > > > > > > Install Step > > > > The INSTALL_DIR is underneath the calling project?s binary directory. > > > > Use INSTALL_DIR to specify a different location. Note that in addition > > > > to setting INSTALL_DIR, you also have to pass -DCMAKE_INSTALL_PREFIX > > > > or --prefix to the CMake or configure command. It is not used > > > > automatically in the configure step since not all projects follow this > > > > convention. > > > > > > > > From > > > > http://www.kitware.com/media/ html/ BuildingExternalProjectsWithCM > > > ake2.8.html > > > > > > > > On Thu, Apr 9, 2015 at 5:44 AM, David Cole via CMake < cmake at cmake.org > > > > wrote: > > > > > You need to tell eigen where to install, probably as an argument to its > > > > > configure step. If it builds with CMake, you can use: > > > > > > > > > > -DCMAKE_INSTALL_PREFIX=< INSTALL_DIR> > > > > > > > > > > as one of the CMake args. If it has a non-CMake configure step, you'll > > > > have > > > > > to call that and pass in as an argument. > > > > > > > > > > > > > > > HTH, > > > > > David C. > > > > > > > > > > > > > > > On Thursday, April 9, 2015, Cedric Doucet < cedric.doucet at inria.fr > > > > > wrote: > > > > >> > > > > >> > > > > >> Hello! > > > > >> > > > > >> I try to download, extract, configure, build and install a library > > > >> with > > > > >> CMake. > > > > >> My CMakeLists.txt contains the following lines: > > > > >> > > > > >> cmake_minimum_required (VERSION 2.6) > > > > >> project (example CXX) > > > > >> set(CMAKE_VERBOSE_MAKEFILE ON) > > > > >> include(ExternalProject) > > > > >> include(ProcessorCount) > > > > >> ProcessorCount(N) > > > > >> if(NOT N EQUAL 0) > > > > >> set(CMAKE_BUILD_FLAGS -j${N}) > > > > >> endif() > > > > >> ExternalProject_Add(eigen > > > > >> PREFIX third_party > > > > >> DOWNLOAD_DIR third_party/eigen/download > > > > >> SOURCE_DIR third_party/eigen/src > > > > >> BINARY_DIR third_party/eigen/build > > > > >> INSTALL_DIR third_party/eigen/install > > > > >> DOWNLOAD_COMMAND wget > > > > >> http://bitbucket.org/eigen/ eigen/get/3.2.4.tar.gz && tar xvzf > > > >> 3.2.4.tar.gz > > > > >> -C ../src --strip-components=1 > > > > >> ) > > > > >> > > > > >> In this example, the installation step fails with the following error > > > > >> message: > > > > >> > > > > >> CMake Error at cmake_install.cmake:38 (FILE): > > > > >> file cannot create directory: /usr/local/include/eigen3. Maybe need > > > > >> administrative privileges. > > > > >> > > > > >> It means that the value of INSTALL_DIR is not taken into account > > > >> during > > > > >> the configuration process. > > > > >> > > > > >> Why? What am I do wrong? > > > > >> > > > > >> Thank you very much for your help. > > > > >> > > > > >> Best regards, > > > > >> > > > > >> C?dric Doucet > > > > >> -- > > > > >> > > > > >> Powered by www.kitware.com > > > > >> > > > > >> Please keep messages on-topic and check the CMake FAQ at: > > > > >> http://www.cmake.org/Wiki/ CMake_FAQ > > > > >> > > > > >> Kitware offers various services to support the CMake community. For > > > >> more > > > > >> information on each offering, please visit: > > > > >> > > > > >> CMake Support: http://cmake.org/cmake/help/ support.html > > > > >> CMake Consulting: http://cmake.org/cmake/help/ consulting.html > > > > >> CMake Training Courses: http://cmake.org/cmake/help/ training.html > > > > >> > > > > >> Visit other Kitware open-source projects at > > > > >> http://www.kitware.com/ opensource/opensource.html > > > > >> > > > > >> Follow this link to subscribe/unsubscribe: > > > > >> http://public.kitware.com/ mailman/listinfo/cmake > > > > > > > > > > > > > > > -- > > > > > > > > > > Powered by www.kitware.com > > > > > > > > > > Please keep messages on-topic and check the CMake FAQ at: > > > > > http://www.cmake.org/Wiki/ CMake_FAQ > > > > > > > > > > Kitware offers various services to support the CMake community. For > > > > more > > > > > information on each offering, please visit: > > > > > > > > > > CMake Support: http://cmake.org/cmake/help/ support.html > > > > > CMake Consulting: http://cmake.org/cmake/help/ consulting.html > > > > > CMake Training Courses: http://cmake.org/cmake/help/ training.html > > > > > > > > > > Visit other Kitware open-source projects at > > > > > http://www.kitware.com/ opensource/opensource.html > > > > > > > > > > Follow this link to subscribe/unsubscribe: > > > > > http://public.kitware.com/ mailman/listinfo/cmake > > > > -- > > > > > > > > Powered by www.kitware.com > > > > > > > > Please keep messages on-topic and check the CMake FAQ at: > > > > http://www.cmake.org/Wiki/ CMake_FAQ > > > > > > > > Kitware offers various services to support the CMake community. For more > > > > information on each offering, please visit: > > > > > > > > CMake Support: http://cmake.org/cmake/help/ support.html > > > > CMake Consulting: http://cmake.org/cmake/help/ consulting.html > > > > CMake Training Courses: http://cmake.org/cmake/help/ training.html > > > > > > > > Visit other Kitware open-source projects at > > > > http://www.kitware.com/ opensource/opensource.html > > > > > > > > Follow this link to subscribe/unsubscribe: > > > > http://public.kitware.com/ mailman/listinfo/cmake > > > -- > > > Powered by www.kitware.com > > > Please keep messages on-topic and check the CMake FAQ at: > > http://www.cmake.org/Wiki/ CMake_FAQ > > > Kitware offers various services to support the CMake community. For more > > information on each offering, please visit: > > > CMake Support: http://cmake.org/cmake/help/ support.html > > > CMake Consulting: http://cmake.org/cmake/help/ consulting.html > > > CMake Training Courses: http://cmake.org/cmake/help/ training.html > > > Visit other Kitware open-source projects at http://www.kitware.com/ > > opensource/opensource.html > > > Follow this link to subscribe/unsubscribe: > > > http://public.kitware.com/ mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Theodore.Papadopoulo at inria.fr Thu Apr 9 09:08:13 2015 From: Theodore.Papadopoulo at inria.fr (Theodore Papadopoulo) Date: Thu, 09 Apr 2015 15:08:13 +0200 Subject: [CMake] What is the purpose of INSTALL_DIR in ExternalProject_Add command? In-Reply-To: References: <1428477977.5609.18.camel@t-online.de> <1790921270.1066962.1428571052188.JavaMail.zimbra@inria.fr> <771308217.1173749.1428577661399.JavaMail.zimbra@inria.fr> Message-ID: <552679BD.3070003@inria.fr> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/09/2015 01:26 PM, Ryan Pavlik wrote: > It's for if your use case requires the project to be installed in > a specific location that's not the automatically generated one. > For instance, if you're building multiple external projects you > might have them all install to the same subdirectory of the binary > directory for convenience. > > Ryan I personally believe that you should never use the files constructed in the build directory. This can work for binaries or static libraries but is a point of failure with dynamic libraries (often the relative paths of those are different in the final install). One case where installing is absolutely necessary (at least in my somewhat limited experience); windows, which requires that all the dynamic libraries used by a program to be in the smae install directory. Hope it help a little. Theo. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlUmeb0ACgkQEr8WrU8nPV2U8QCeKO8ldeKUnQHktROVz1uzo0x6 ZDQAoJOL8KciN9pq5H+09tmSRhqSqiQ6 =J+yG -----END PGP SIGNATURE----- From cedric.doucet at inria.fr Thu Apr 9 09:53:56 2015 From: cedric.doucet at inria.fr (Cedric Doucet) Date: Thu, 9 Apr 2015 15:53:56 +0200 (CEST) Subject: [CMake] What is the purpose of INSTALL_DIR in ExternalProject_Add command? In-Reply-To: <552679BD.3070003@inria.fr> References: <1428477977.5609.18.camel@t-online.de> <1790921270.1066962.1428571052188.JavaMail.zimbra@inria.fr> <771308217.1173749.1428577661399.JavaMail.zimbra@inria.fr> <552679BD.3070003@inria.fr> Message-ID: <2087654443.1255066.1428587636303.JavaMail.zimbra@inria.fr> Hello Theodore, thank you for your help. Well, indeed it greatly depends on the system and the user. Neverteless, you can alaways provide your own value of CONFIGURATION_COMMAND to install your libraries in the same directory or in different ones. It does not depend on INSTALL_DIR at all. You don't need INSTALL_DIR to do that. It is more convenient to do it at the command line 'cmake -D MY_INSTALL_PREFIX' and make CONFIGURE_COMMAND depend on the value MY_INSTALL_PREFIX (or CMAKE_INSTALL_PREFIX if you want). But do you understand what INSTALL_DIR do? For example, what are the differences between this call ExternalProject_Add(eigen PREFIX third_party INSTALL_DIR third_party/eigen/install DOWNLOAD_COMMAND wget http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz && tar xvzf 3.2.4.tar.gz -C ../src --strip-components=1 ) and this one ExternalProject_Add(eigen PREFIX third_party DOWNLOAD_COMMAND wget http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz && tar xvzf 3.2.4.tar.gz -C ../src --strip-components=1 ) ? What is the default value of INSTALL_DIR? What does setting INSTALL_DIR to a value do? I am sorry if I miss something, but I really try to understand your answers. I realize that I don't understand what mechanism is behind setting INSTALL_DIR to a value. In the documentation (http://www.cmake.org/cmake/help/v3.2/module/ExternalProject.html?highlight=external#command:externalproject_add), it is written "Installation prefix". But what does it mean? What is actually done with the value of INSTALL_DIR? C?dric ----- Mail original ----- > De: "Theodore Papadopoulo" > ?: cmake at cmake.org > Envoy?: Jeudi 9 Avril 2015 15:08:13 > Objet: Re: [CMake] What is the purpose of INSTALL_DIR in ExternalProject_Add command? > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 04/09/2015 01:26 PM, Ryan Pavlik wrote: > > It's for if your use case requires the project to be installed in > > a specific location that's not the automatically generated one. > > For instance, if you're building multiple external projects you > > might have them all install to the same subdirectory of the binary > > directory for convenience. > > > > Ryan > > I personally believe that you should never use the files constructed > in the build directory. This can work for binaries or static libraries > but is a point of failure with dynamic libraries (often the relative > paths of those are different in the final install). > > One case where installing is absolutely necessary (at least in my > somewhat limited experience); windows, which requires that all the > dynamic libraries used by a program to be in the smae install directory. > > Hope it help a little. > > Theo. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iEYEARECAAYFAlUmeb0ACgkQEr8WrU8nPV2U8QCeKO8ldeKUnQHktROVz1uzo0x6 > ZDQAoJOL8KciN9pq5H+09tmSRhqSqiQ6 > =J+yG > -----END PGP SIGNATURE----- > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 benapetr at gmail.com Fri Apr 10 03:20:40 2015 From: benapetr at gmail.com (Petr Bena) Date: Fri, 10 Apr 2015 09:20:40 +0200 Subject: [CMake] Change the default output path in Visual Studio In-Reply-To: <551953B6.20503@gmail.com> References: <5519501C.7080006@gmail.com> <551953B6.20503@gmail.com> Message-ID: I got to test it now, it doesn't seem to work, it changes the path, but instead of ROOT/Debug/extensions/library_here.dll it puts it to ROOT/extensions/Debug/library_here.dll which is different, but still not what I wanted. On Mon, Mar 30, 2015 at 3:46 PM, Nils Gladitz wrote: > 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 nilsgladitz at gmail.com Fri Apr 10 03:33:59 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 10 Apr 2015 09:33:59 +0200 Subject: [CMake] Change the default output path in Visual Studio In-Reply-To: References: <5519501C.7080006@gmail.com> <551953B6.20503@gmail.com> Message-ID: <55277CE7.9060107@gmail.com> On 04/10/2015 09:20 AM, Petr Bena wrote: > I got to test it now, it doesn't seem to work, it changes the path, > but instead of ROOT/Debug/extensions/library_here.dll it puts it to > ROOT/extensions/Debug/library_here.dll which is different, but still > not what I wanted. For multi-configuration generators (like Visual Studio) the configuration specific sub-directory is appended since the output of all configurations can not occupy the same space at the same time. You can set the CMAKE_RUNTIME_OUTPUT_DIRECTORY_ [1] variables instead (one variable per configuration) which does not append any such directory. You should be able to point all of those variables at the same directory at your own risk. Nils [1] http://www.cmake.org/cmake/help/v3.2/prop_tgt/RUNTIME_OUTPUT_DIRECTORY_CONFIG.html From benapetr at gmail.com Fri Apr 10 03:51:24 2015 From: benapetr at gmail.com (Petr Bena) Date: Fri, 10 Apr 2015 09:51:24 +0200 Subject: [CMake] Change the default output path in Visual Studio In-Reply-To: <55277CE7.9060107@gmail.com> References: <5519501C.7080006@gmail.com> <551953B6.20503@gmail.com> <55277CE7.9060107@gmail.com> Message-ID: Yep This works On Fri, Apr 10, 2015 at 9:33 AM, Nils Gladitz wrote: > On 04/10/2015 09:20 AM, Petr Bena wrote: >> >> I got to test it now, it doesn't seem to work, it changes the path, >> but instead of ROOT/Debug/extensions/library_here.dll it puts it to >> ROOT/extensions/Debug/library_here.dll which is different, but still >> not what I wanted. > > > For multi-configuration generators (like Visual Studio) the configuration > specific sub-directory is appended since the output of all configurations > can not occupy the same space at the same time. > > You can set the CMAKE_RUNTIME_OUTPUT_DIRECTORY_ [1] variables > instead (one variable per configuration) which does not append any such > directory. > > You should be able to point all of those variables at the same directory at > your own risk. > > Nils > > [1] > http://www.cmake.org/cmake/help/v3.2/prop_tgt/RUNTIME_OUTPUT_DIRECTORY_CONFIG.html From cedric.doucet at inria.fr Fri Apr 10 04:51:33 2015 From: cedric.doucet at inria.fr (Cedric Doucet) Date: Fri, 10 Apr 2015 10:51:33 +0200 (CEST) Subject: [CMake] What is the purpose of INSTALL_DIR in ExternalProject_Add command? In-Reply-To: <2087654443.1255066.1428587636303.JavaMail.zimbra@inria.fr> References: <1428477977.5609.18.camel@t-online.de> <1790921270.1066962.1428571052188.JavaMail.zimbra@inria.fr> <771308217.1173749.1428577661399.JavaMail.zimbra@inria.fr> <552679BD.3070003@inria.fr> <2087654443.1255066.1428587636303.JavaMail.zimbra@inria.fr> Message-ID: <381683346.1567883.1428655893657.JavaMail.zimbra@inria.fr> Hello, I have tried to use INSTALL_DIR in the configuration command but I may do something wrong: ExternalProject_Add(${LIBRARY} INSTALL_DIR ${CMAKE_BINARY_DIR}/external/${LIBRARY}/install DOWNLOAD_COMMAND wget http://bitbucket.org/eigen/eigen/get/${EIGEN_VERSION}.tar.gz && tar xvzf ${EIGEN_VERSION}.tar.gz -C ../src --strip-components=1 CONFIGURE_COMMAND cd ../build && cmake -D CMAKE_INSTALL_PREFIX=${INSTALL_DIR} ../src ) I get the following error message : CMake Error at cmake_install.cmake:38 (FILE): file cannot create directory: /include/eigen3. Maybe need administrative privileges. But if I replace INSTALL_DIR by its value in the configuration command, CONFIGURE_COMMAND cd ../build && cmake -D CMAKE_INSTALL_PREFIX=${CMAKE_BINARY_DIR}/external/${LIBRARY}/install ../src everything works fine. Could you explain me how to use INSTALL_DIR? C?dric ----- Mail original ----- > De: "Cedric Doucet" > ?: cmake at cmake.org > Envoy?: Jeudi 9 Avril 2015 15:53:56 > Objet: Re: [CMake] What is the purpose of INSTALL_DIR in ExternalProject_Add command? > > > Hello Theodore, > > thank you for your help. > > Well, indeed it greatly depends on the system and the user. > Neverteless, you can alaways provide your own value of CONFIGURATION_COMMAND > to install your libraries in the same directory or in different ones. > It does not depend on INSTALL_DIR at all. > You don't need INSTALL_DIR to do that. > It is more convenient to do it at the command line 'cmake -D > MY_INSTALL_PREFIX' and make CONFIGURE_COMMAND depend on the value > MY_INSTALL_PREFIX (or CMAKE_INSTALL_PREFIX if you want). > > But do you understand what INSTALL_DIR do? > > For example, what are the differences between this call > > ExternalProject_Add(eigen > PREFIX third_party > INSTALL_DIR third_party/eigen/install > DOWNLOAD_COMMAND wget > http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz && tar > xvzf 3.2.4.tar.gz -C ../src --strip-components=1 > ) > > and this one > > ExternalProject_Add(eigen > PREFIX third_party > DOWNLOAD_COMMAND wget > http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz && tar > xvzf 3.2.4.tar.gz -C ../src --strip-components=1 > ) > ? > > What is the default value of INSTALL_DIR? > What does setting INSTALL_DIR to a value do? > > I am sorry if I miss something, but I really try to understand your answers. > I realize that I don't understand what mechanism is behind setting > INSTALL_DIR to a value. > > In the documentation > (http://www.cmake.org/cmake/help/v3.2/module/ExternalProject.html?highlight=external#command:externalproject_add), > it is written "Installation prefix". > But what does it mean? > What is actually done with the value of INSTALL_DIR? > > C?dric > > > ----- Mail original ----- > > De: "Theodore Papadopoulo" > > ?: cmake at cmake.org > > Envoy?: Jeudi 9 Avril 2015 15:08:13 > > Objet: Re: [CMake] What is the purpose of INSTALL_DIR in > > ExternalProject_Add command? > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On 04/09/2015 01:26 PM, Ryan Pavlik wrote: > > > It's for if your use case requires the project to be installed in > > > a specific location that's not the automatically generated one. > > > For instance, if you're building multiple external projects you > > > might have them all install to the same subdirectory of the binary > > > directory for convenience. > > > > > > Ryan > > > > I personally believe that you should never use the files constructed > > in the build directory. This can work for binaries or static libraries > > but is a point of failure with dynamic libraries (often the relative > > paths of those are different in the final install). > > > > One case where installing is absolutely necessary (at least in my > > somewhat limited experience); windows, which requires that all the > > dynamic libraries used by a program to be in the smae install directory. > > > > Hope it help a little. > > > > Theo. > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v2 > > > > iEYEARECAAYFAlUmeb0ACgkQEr8WrU8nPV2U8QCeKO8ldeKUnQHktROVz1uzo0x6 > > ZDQAoJOL8KciN9pq5H+09tmSRhqSqiQ6 > > =J+yG > > -----END PGP SIGNATURE----- > > -- > > > > Powered by www.kitware.com > > > > Please keep messages on-topic and check the CMake FAQ at: > > http://www.cmake.org/Wiki/CMake_FAQ > > > > Kitware offers various services to support the CMake community. For more > > information on each offering, please visit: > > > > CMake Support: http://cmake.org/cmake/help/support.html > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/cmake > > > From nilsgladitz at gmail.com Fri Apr 10 04:55:11 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 10 Apr 2015 10:55:11 +0200 Subject: [CMake] What is the purpose of INSTALL_DIR in ExternalProject_Add command? In-Reply-To: <381683346.1567883.1428655893657.JavaMail.zimbra@inria.fr> References: <1428477977.5609.18.camel@t-online.de> <1790921270.1066962.1428571052188.JavaMail.zimbra@inria.fr> <771308217.1173749.1428577661399.JavaMail.zimbra@inria.fr> <552679BD.3070003@inria.fr> <2087654443.1255066.1428587636303.JavaMail.zimbra@inria.fr> <381683346.1567883.1428655893657.JavaMail.zimbra@inria.fr> Message-ID: <55278FEF.3030804@gmail.com> On 04/10/2015 10:51 AM, Cedric Doucet wrote: > > Hello, > > I have tried to use INSTALL_DIR in the configuration command but I may do something wrong: > > ExternalProject_Add(${LIBRARY} > INSTALL_DIR ${CMAKE_BINARY_DIR}/external/${LIBRARY}/install > DOWNLOAD_COMMAND wget http://bitbucket.org/eigen/eigen/get/${EIGEN_VERSION}.tar.gz && tar xvzf ${EIGEN_VERSION}.tar.gz -C ../src --strip-components=1 > CONFIGURE_COMMAND cd ../build && cmake -D CMAKE_INSTALL_PREFIX=${INSTALL_DIR} ../src > ) > > I get the following error message : > > CMake Error at cmake_install.cmake:38 (FILE): > file cannot create directory: /include/eigen3. Maybe need administrative > privileges. > > But if I replace INSTALL_DIR by its value in the configuration command, > > CONFIGURE_COMMAND cd ../build && cmake -D CMAKE_INSTALL_PREFIX=${CMAKE_BINARY_DIR}/external/${LIBRARY}/install ../src > > everything works fine. > > Could you explain me how to use INSTALL_DIR? Try "" instead of "${INSTALL_DIR}". is a token that ExternalProject itself should expand rather than a regular variable expansion. Nils From cedric.doucet at inria.fr Fri Apr 10 04:57:23 2015 From: cedric.doucet at inria.fr (Cedric Doucet) Date: Fri, 10 Apr 2015 10:57:23 +0200 (CEST) Subject: [CMake] What is the purpose of INSTALL_DIR in ExternalProject_Add command? In-Reply-To: <55278FEF.3030804@gmail.com> References: <1428477977.5609.18.camel@t-online.de> <771308217.1173749.1428577661399.JavaMail.zimbra@inria.fr> <552679BD.3070003@inria.fr> <2087654443.1255066.1428587636303.JavaMail.zimbra@inria.fr> <381683346.1567883.1428655893657.JavaMail.zimbra@inria.fr> <55278FEF.3030804@gmail.com> Message-ID: <577225892.1570274.1428656243184.JavaMail.zimbra@inria.fr> Hello Nils! Thank you very much for your answer. It works fine now! Best regards, C?dric ----- Mail original ----- > De: "Nils Gladitz" > ?: "Cedric Doucet" , cmake at cmake.org > Envoy?: Vendredi 10 Avril 2015 10:55:11 > Objet: Re: [CMake] What is the purpose of INSTALL_DIR in ExternalProject_Add command? > > On 04/10/2015 10:51 AM, Cedric Doucet wrote: > > > > Hello, > > > > I have tried to use INSTALL_DIR in the configuration command but I may do > > something wrong: > > > > ExternalProject_Add(${LIBRARY} > > INSTALL_DIR > > ${CMAKE_BINARY_DIR}/external/${LIBRARY}/install > > DOWNLOAD_COMMAND wget > > http://bitbucket.org/eigen/eigen/get/${EIGEN_VERSION}.tar.gz > > && tar xvzf ${EIGEN_VERSION}.tar.gz -C ../src > > --strip-components=1 > > CONFIGURE_COMMAND cd ../build && cmake -D > > CMAKE_INSTALL_PREFIX=${INSTALL_DIR} ../src > > ) > > > > I get the following error message : > > > > CMake Error at cmake_install.cmake:38 (FILE): > > file cannot create directory: /include/eigen3. Maybe need > > administrative > > privileges. > > > > But if I replace INSTALL_DIR by its value in the configuration command, > > > > CONFIGURE_COMMAND cd ../build && cmake -D > > CMAKE_INSTALL_PREFIX=${CMAKE_BINARY_DIR}/external/${LIBRARY}/install > > ../src > > > > everything works fine. > > > > Could you explain me how to use INSTALL_DIR? > > Try "" instead of "${INSTALL_DIR}". > is a token that ExternalProject itself should expand > rather than a regular variable expansion. > > Nils > From cedric.doucet at inria.fr Fri Apr 10 05:16:31 2015 From: cedric.doucet at inria.fr (Cedric Doucet) Date: Fri, 10 Apr 2015 11:16:31 +0200 (CEST) Subject: [CMake] What is the purpose of INSTALL_DIR in ExternalProject_Add command? In-Reply-To: <577225892.1570274.1428656243184.JavaMail.zimbra@inria.fr> References: <1428477977.5609.18.camel@t-online.de> <771308217.1173749.1428577661399.JavaMail.zimbra@inria.fr> <552679BD.3070003@inria.fr> <2087654443.1255066.1428587636303.JavaMail.zimbra@inria.fr> <381683346.1567883.1428655893657.JavaMail.zimbra@inria.fr> <55278FEF.3030804@gmail.com> <577225892.1570274.1428656243184.JavaMail.zimbra@inria.fr> Message-ID: <1946035807.1582897.1428657391729.JavaMail.zimbra@inria.fr> Hello, is it possible to make INSTALL_DIR depend on PREFIX? I have tried "INSTALL_DIR /install" but it does not seem to work: 'install' repository is not created. C?dric ----- Mail original ----- > De: "Cedric Doucet" > ?: "Nils Gladitz" > Cc: cmake at cmake.org > Envoy?: Vendredi 10 Avril 2015 10:57:23 > Objet: Re: [CMake] What is the purpose of INSTALL_DIR in ExternalProject_Add command? > > > Hello Nils! > > Thank you very much for your answer. > It works fine now! > > Best regards, > > C?dric > > > > ----- Mail original ----- > > De: "Nils Gladitz" > > ?: "Cedric Doucet" , cmake at cmake.org > > Envoy?: Vendredi 10 Avril 2015 10:55:11 > > Objet: Re: [CMake] What is the purpose of INSTALL_DIR in > > ExternalProject_Add command? > > > > On 04/10/2015 10:51 AM, Cedric Doucet wrote: > > > > > > Hello, > > > > > > I have tried to use INSTALL_DIR in the configuration command but I may do > > > something wrong: > > > > > > ExternalProject_Add(${LIBRARY} > > > INSTALL_DIR > > > ${CMAKE_BINARY_DIR}/external/${LIBRARY}/install > > > DOWNLOAD_COMMAND wget > > > http://bitbucket.org/eigen/eigen/get/${EIGEN_VERSION}.tar.gz > > > && tar xvzf ${EIGEN_VERSION}.tar.gz -C ../src > > > --strip-components=1 > > > CONFIGURE_COMMAND cd ../build && cmake -D > > > CMAKE_INSTALL_PREFIX=${INSTALL_DIR} ../src > > > ) > > > > > > I get the following error message : > > > > > > CMake Error at cmake_install.cmake:38 (FILE): > > > file cannot create directory: /include/eigen3. Maybe need > > > administrative > > > privileges. > > > > > > But if I replace INSTALL_DIR by its value in the configuration command, > > > > > > CONFIGURE_COMMAND cd ../build && cmake -D > > > CMAKE_INSTALL_PREFIX=${CMAKE_BINARY_DIR}/external/${LIBRARY}/install > > > ../src > > > > > > everything works fine. > > > > > > Could you explain me how to use INSTALL_DIR? > > > > Try "" instead of "${INSTALL_DIR}". > > is a token that ExternalProject itself should expand > > rather than a regular variable expansion. > > > > 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 nilsgladitz at gmail.com Fri Apr 10 05:44:39 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 10 Apr 2015 11:44:39 +0200 Subject: [CMake] What is the purpose of INSTALL_DIR in ExternalProject_Add command? In-Reply-To: <1946035807.1582897.1428657391729.JavaMail.zimbra@inria.fr> References: <1428477977.5609.18.camel@t-online.de> <771308217.1173749.1428577661399.JavaMail.zimbra@inria.fr> <552679BD.3070003@inria.fr> <2087654443.1255066.1428587636303.JavaMail.zimbra@inria.fr> <381683346.1567883.1428655893657.JavaMail.zimbra@inria.fr> <55278FEF.3030804@gmail.com> <577225892.1570274.1428656243184.JavaMail.zimbra@inria.fr> <1946035807.1582897.1428657391729.JavaMail.zimbra@inria.fr> Message-ID: <55279B87.60204@gmail.com> On 04/10/2015 11:16 AM, Cedric Doucet wrote: > is it possible to make INSTALL_DIR depend on PREFIX? > I have tried "INSTALL_DIR /install" but it does not seem to work: 'install' repository is not created. I don't think so ... but you could use the same variable to construct both. e.g. set(MY_PREFIX /foo) ExternalProject_Add(foo PREFIX ${MY_PREFIX} INSTALL_DIR ${MY_PREFIX}/install ... ) Nils From rahulsoni at immt.res.in Fri Apr 10 06:52:55 2015 From: rahulsoni at immt.res.in (Rahul Kumar Soni) Date: Fri, 10 Apr 2015 16:22:55 +0530 Subject: [CMake] No FindVTK.cmake in cmake 3.1.2 Message-ID: Hi I am newbie to the cmake. I have installed vtk5.10.1 through cygwin in windows. The vtk is installed in /cygwin/VTK5.10.1 and its libraries are in /usr/local/lib/vtk-5.10. I had earlier did similar things in ubuntu and there I required to set the vtk directory in the FindVTK.cmake file with the following command. *SET (VTK_DIR "/usr/local/lib/vtk-5.10")* However, in cmake3.1.2 I don't find the file FindVTK.cmake. Have searched a lot over internet but no luck. Found that it has something to do with the find_package(VTK REQUIRED). But really helpless, how to do it. Please anyone help or provide a weblink with the proper guidance. -- Sincerely Rahul Kumar Soni Scientist, Institute of Minerals & Materials Technology Council of Scientific & Industrial Research, Govt. of India -------------- next part -------------- An HTML attachment was scrubbed... URL: From cedric.doucet at inria.fr Fri Apr 10 07:15:32 2015 From: cedric.doucet at inria.fr (Cedric Doucet) Date: Fri, 10 Apr 2015 13:15:32 +0200 (CEST) Subject: [CMake] What is the purpose of INSTALL_DIR in ExternalProject_Add command? In-Reply-To: <55279B87.60204@gmail.com> References: <1428477977.5609.18.camel@t-online.de> <552679BD.3070003@inria.fr> <2087654443.1255066.1428587636303.JavaMail.zimbra@inria.fr> <381683346.1567883.1428655893657.JavaMail.zimbra@inria.fr> <55278FEF.3030804@gmail.com> <577225892.1570274.1428656243184.JavaMail.zimbra@inria.fr> <1946035807.1582897.1428657391729.JavaMail.zimbra@inria.fr> <55279B87.60204@gmail.com> Message-ID: <215930332.1626167.1428664532238.JavaMail.zimbra@inria.fr> Thank you Nils! It works! C?dric ----- Mail original ----- > De: "Nils Gladitz" > ?: "Cedric Doucet" , cmake at cmake.org > Envoy?: Vendredi 10 Avril 2015 11:44:39 > Objet: Re: [CMake] What is the purpose of INSTALL_DIR in ExternalProject_Add command? > > On 04/10/2015 11:16 AM, Cedric Doucet wrote: > > > is it possible to make INSTALL_DIR depend on PREFIX? > > I have tried "INSTALL_DIR /install" but it does not seem to work: > > 'install' repository is not created. > > I don't think so ... but you could use the same variable to construct both. > > e.g. > > set(MY_PREFIX /foo) > > ExternalProject_Add(foo > PREFIX ${MY_PREFIX} > INSTALL_DIR ${MY_PREFIX}/install > ... > ) > > Nils > From robert.maynard at kitware.com Fri Apr 10 08:59:54 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 10 Apr 2015 08:59:54 -0400 Subject: [CMake] Default INTERFACE_POSITION_INDEPENDENT_CODE value for static library In-Reply-To: <55259600.8050609@yahoo.com> References: <55259600.8050609@yahoo.com> Message-ID: The default for PIC is no for static libraries, see http://www.cmake.org/cmake/help/v3.2/prop_tgt/POSITION_INDEPENDENT_CODE.html On Wed, Apr 8, 2015 at 4:56 PM, Ruslan Baratov via CMake wrote: > Hi, > > I've got next error while trying to link static library to shared one on > Linux: > /usr/bin/ld: ...: relocation R_X86_64_32 against `.rodata' can not be > used when making a shared object; recompile with -fPIC > > This error can be detected on CMake configure step instead of linker stage > if I add next code: > set_property(TARGET ... PROPERTY INTERFACE_POSITION_INDEPENDENT_CODE YES) > > in this case error message is: > CMake Error: Property POSITION_INDEPENDENT_CODE on target "..." does > not match the INTERFACE_POSITION_INDEPENDENT_CODE property requirement > of dependency "...". > > because there is POSITION_INDEPENDENT_CODE=YES default value for shared > library. So I wonder why there is no default value > INTERFACE_POSITION_INDEPENDENT_CODE=NO for static one? > > Thanks, Ruslo > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From cary.lewis at gmail.com Fri Apr 10 11:15:27 2015 From: cary.lewis at gmail.com (carylewis2015) Date: Fri, 10 Apr 2015 08:15:27 -0700 (MST) Subject: [CMake] Building cmake on SCO OpenServer 5.0.7 with gcc 3.4.3 Message-ID: <1428678927078-7590234.post@n2.nabble.com> I am trying to build cmake on SCO OpenServer 5.0.7 with gcc 3.4.3, and I am receiving numerous errors. For example on cmake v. 2.8.12.2 i receive undefined __throw when performing the gmake command after the boot strap. I tried 2.8.4 and received errors related to __MAX_INT__ not being defined, but it is defined. I know that SCO is old, but the documentation and things I've read online suggest it should work. Has one successfully built a cmake on SCO. I have used gcc successfully to build python, perl, openssl, ssh, etc. so the tool chain essentially works. Thanks. -- View this message in context: http://cmake.3232098.n2.nabble.com/Building-cmake-on-SCO-OpenServer-5-0-7-with-gcc-3-4-3-tp7590234.html Sent from the CMake mailing list archive at Nabble.com. From eike at sf-mail.de Fri Apr 10 11:22:11 2015 From: eike at sf-mail.de (Rolf Eike Beer) Date: Fri, 10 Apr 2015 17:22:11 +0200 Subject: [CMake] Building cmake on SCO OpenServer 5.0.7 with gcc 3.4.3 In-Reply-To: <1428678927078-7590234.post@n2.nabble.com> References: <1428678927078-7590234.post@n2.nabble.com> Message-ID: <12994700.8JaqyHYgJl@caliban.sf-tec.de> Am Freitag, 10. April 2015, 08:15:27 schrieb carylewis2015: > I am trying to build cmake on SCO OpenServer 5.0.7 with gcc 3.4.3, and I am > receiving numerous errors. > > For example on cmake v. 2.8.12.2 i receive undefined __throw when performing > the gmake command after the boot strap. > > I tried 2.8.4 and received errors related to __MAX_INT__ not being defined, > but it is defined. > > I know that SCO is old, but the documentation and things I've read online > suggest it should work. > > Has one successfully built a cmake on SCO. > > I have used gcc successfully to build python, perl, openssl, ssh, etc. so > the tool chain essentially works. Those are all C AFAIK, but CMake is C++. The __throw symbols suggests that you may have a problem with your C++ standard library. 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 rcdailey.lists at gmail.com Fri Apr 10 12:26:04 2015 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Fri, 10 Apr 2015 11:26:04 -0500 Subject: [CMake] Bug in CMake GUI 3.2.1? Message-ID: I am noticing that after installing the official Windows installer for 3.2.1 release, CMake GUI looks different. Menu options have GCC specific options and when I generate through the GUI for Visual Studio 2013, my projects are missing preprocessor definitions like _WINDOWS, WIN32, etc. When I generate from the command line everything is setup just fine. Did a mixture of Linux/Mac get put into the Windows build or am I missing something? From ruslan_baratov at yahoo.com Fri Apr 10 12:26:59 2015 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Fri, 10 Apr 2015 18:26:59 +0200 Subject: [CMake] Default INTERFACE_POSITION_INDEPENDENT_CODE value for static library In-Reply-To: References: <55259600.8050609@yahoo.com> Message-ID: <5527F9D3.7030500@yahoo.com> On 10-Apr-15 14:59, Robert Maynard wrote: > The default for PIC is no for static libraries, see > http://www.cmake.org/cmake/help/v3.2/prop_tgt/POSITION_INDEPENDENT_CODE.html Yes, default for shared library is YES and for static library is NO. That's the problem when you're trying to link them together. GCC on Linux: > cat CMakeLists.txt cmake_minimum_required(VERSION 3.0) project(Foo) add_library(foo STATIC foo.cpp) add_library(boo SHARED boo.cpp) target_link_libraries(boo PUBLIC foo) > cat foo.cpp int foo_var; int foo() { return foo_var; } > cat boo.cpp int foo(); int boo() { return foo(); } > cmake -H. -B_builds -DCMAKE_VERBOSE_MAKEFILE=ON && cmake --build _builds # no fpic for foo.cpp /usr/bin/c++ -o .../foo.cpp.o -c .../foo.cpp # fpic for boo.cpp /usr/bin/c++ -Dboo_EXPORTS -fPIC -o .../boo.cpp.o -c .../boo.cpp /usr/bin/ld: libfoo.a(foo.cpp.o): relocation R_X86_64_PC32 against symbol `foo_var' can not be used when making a shared object; recompile with -fPIC Problem occurs on linking stage. To detect this problem on CMake configure step you can add INTERFACE_POSITION_INDEPENDENT_CODE manually: > cat CMakeLists.txt cmake_minimum_required(VERSION 3.0) project(Foo) add_library(foo STATIC foo.cpp) set_target_properties(foo PROPERTIES INTERFACE_POSITION_INDEPENDENT_CODE NO) add_library(boo SHARED boo.cpp) target_link_libraries(boo PUBLIC foo) > cmake -H. -B_builds -DCMAKE_VERBOSE_MAKEFILE=ON ... -- Configuring done CMake Error: Property POSITION_INDEPENDENT_CODE on target "boo" does not match the INTERFACE_POSITION_INDEPENDENT_CODE property requirement of dependency "foo". So may be CMake can set INTERFACE_POSITION_INDEPENDENT_CODE property automatically for static libraries by default? Ruslo > > On Wed, Apr 8, 2015 at 4:56 PM, Ruslan Baratov via CMake > wrote: >> Hi, >> >> I've got next error while trying to link static library to shared one on >> Linux: >> /usr/bin/ld: ...: relocation R_X86_64_32 against `.rodata' can not be >> used when making a shared object; recompile with -fPIC >> >> This error can be detected on CMake configure step instead of linker stage >> if I add next code: >> set_property(TARGET ... PROPERTY INTERFACE_POSITION_INDEPENDENT_CODE YES) >> >> in this case error message is: >> CMake Error: Property POSITION_INDEPENDENT_CODE on target "..." does >> not match the INTERFACE_POSITION_INDEPENDENT_CODE property requirement >> of dependency "...". >> >> because there is POSITION_INDEPENDENT_CODE=YES default value for shared >> library. So I wonder why there is no default value >> INTERFACE_POSITION_INDEPENDENT_CODE=NO for static one? >> >> Thanks, Ruslo >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake From robert.maynard at kitware.com Fri Apr 10 14:04:06 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 10 Apr 2015 14:04:06 -0400 Subject: [CMake] Default INTERFACE_POSITION_INDEPENDENT_CODE value for static library In-Reply-To: <5527F9D3.7030500@yahoo.com> References: <55259600.8050609@yahoo.com> <5527F9D3.7030500@yahoo.com> Message-ID: (In my own opinion) The current behavior is mainly historical. We have previously never enabled pic'iness for static libraries, so changing that behavior would require a new policy (historical), and second really only x86_64 linux requires pic'iness, 32bit static libraries could be embedded into 32bit dynamic libraries. Now for current projects that want all libraries built with POSITION_INDEPENDENT_CODE enabled, I would use CMAKE_POSITION_INDEPENDENT_CODE to set the default to TRUE. Really the discussion about changing the default CMake behavior is better suited to the CMake Developers list. On Fri, Apr 10, 2015 at 12:26 PM, Ruslan Baratov wrote: > On 10-Apr-15 14:59, Robert Maynard wrote: >> >> The default for PIC is no for static libraries, see >> >> http://www.cmake.org/cmake/help/v3.2/prop_tgt/POSITION_INDEPENDENT_CODE.html > > Yes, default for shared library is YES and for static library is NO. That's > the problem when you're trying to link them together. GCC on Linux: > > > cat CMakeLists.txt > cmake_minimum_required(VERSION 3.0) > project(Foo) > > add_library(foo STATIC foo.cpp) > add_library(boo SHARED boo.cpp) > > target_link_libraries(boo PUBLIC foo) > > > cat foo.cpp > int foo_var; > > int foo() { > return foo_var; > } > > > cat boo.cpp > int foo(); > > int boo() { > return foo(); > } > > > cmake -H. -B_builds -DCMAKE_VERBOSE_MAKEFILE=ON && cmake --build _builds > # no fpic for foo.cpp > /usr/bin/c++ -o .../foo.cpp.o -c .../foo.cpp > # fpic for boo.cpp > /usr/bin/c++ -Dboo_EXPORTS -fPIC -o .../boo.cpp.o -c .../boo.cpp > /usr/bin/ld: libfoo.a(foo.cpp.o): relocation R_X86_64_PC32 against symbol > `foo_var' can not be used when making a shared object; recompile with -fPIC > > Problem occurs on linking stage. To detect this problem on CMake configure > step you can add INTERFACE_POSITION_INDEPENDENT_CODE manually: > > > cat CMakeLists.txt > cmake_minimum_required(VERSION 3.0) > project(Foo) > > add_library(foo STATIC foo.cpp) > set_target_properties(foo PROPERTIES INTERFACE_POSITION_INDEPENDENT_CODE > NO) > add_library(boo SHARED boo.cpp) > > target_link_libraries(boo PUBLIC foo) > > > cmake -H. -B_builds -DCMAKE_VERBOSE_MAKEFILE=ON > ... > -- Configuring done > CMake Error: Property POSITION_INDEPENDENT_CODE on target "boo" does > not match the INTERFACE_POSITION_INDEPENDENT_CODE property requirement > of dependency "foo". > > So may be CMake can set INTERFACE_POSITION_INDEPENDENT_CODE property > automatically for static libraries by default? > > Ruslo > > >> >> On Wed, Apr 8, 2015 at 4:56 PM, Ruslan Baratov via CMake >> wrote: >>> >>> Hi, >>> >>> I've got next error while trying to link static library to shared one on >>> Linux: >>> /usr/bin/ld: ...: relocation R_X86_64_32 against `.rodata' can not >>> be >>> used when making a shared object; recompile with -fPIC >>> >>> This error can be detected on CMake configure step instead of linker >>> stage >>> if I add next code: >>> set_property(TARGET ... PROPERTY INTERFACE_POSITION_INDEPENDENT_CODE >>> YES) >>> >>> in this case error message is: >>> CMake Error: Property POSITION_INDEPENDENT_CODE on target "..." does >>> not match the INTERFACE_POSITION_INDEPENDENT_CODE property requirement >>> of dependency "...". >>> >>> because there is POSITION_INDEPENDENT_CODE=YES default value for shared >>> library. So I wonder why there is no default value >>> INTERFACE_POSITION_INDEPENDENT_CODE=NO for static one? >>> >>> Thanks, Ruslo >>> -- >>> >>> Powered by www.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: >>> http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For more >>> information on each offering, please visit: >>> >>> CMake Support: http://cmake.org/cmake/help/support.html >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/cmake > > From robert.maynard at kitware.com Fri Apr 10 14:50:48 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 10 Apr 2015 14:50:48 -0400 Subject: [CMake] No FindVTK.cmake in cmake 3.1.2 In-Reply-To: References: Message-ID: The VTK find module has been removed as it was a thin wrapper around find_package(VTK NO_MODULE). You can find this documented at http://www.cmake.org/cmake/help/v3.2/module/FindVTK.html VTK should have came with/built a VTKConfig.cmake that you can CMake at. On Fri, Apr 10, 2015 at 6:52 AM, Rahul Kumar Soni wrote: > Hi I am newbie to the cmake. I have installed vtk5.10.1 through cygwin in > windows. The vtk is installed in /cygwin/VTK5.10.1 and its libraries are in > /usr/local/lib/vtk-5.10. > > I had earlier did similar things in ubuntu and there I required to set the > vtk directory in the FindVTK.cmake file with the following command. > SET (VTK_DIR "/usr/local/lib/vtk-5.10") > > However, in cmake3.1.2 I don't find the file FindVTK.cmake. Have searched a > lot over internet but no luck. Found that it has something to do with the > find_package(VTK REQUIRED). But really helpless, how to do it. > > Please anyone help or provide a weblink with the proper guidance. > -- > Sincerely > > Rahul Kumar Soni > > Scientist, Institute of Minerals & Materials Technology > Council of Scientific & Industrial Research, Govt. of India > > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 Dave at Yost.com Sat Apr 11 04:16:07 2015 From: Dave at Yost.com (Dave Yost) Date: Sat, 11 Apr 2015 01:16:07 -0700 Subject: [CMake] avoiding unnecessary rebuilds References: <980BB90C-25AF-4CD9-A688-13263D23BB2D@yost.com> Message-ID: <044604A5-023C-4628-9ACD-944B00FB60D6@yost.com> Seems to me that it would be great if cmake could produce Makefiles that work like the proposal below. This approach can eliminate a lot of unnecessary downstream rebuilds. It is similar to how I imagine ccache works, but unlike ccache which is only for compiling C/C++, the approach should work for any kind of target production. It seems reasonable that cmake could do the work of generating rules to work like this, but it also might be possible that make and ninja could be made to work like this, optionally. Proposal For every target foo there will be a foo-stamp timestamp file. If foo-stamp doesn?t exist or is older than any of foo's dependencies # Build foo without clobbering the old foo. make-foo > tmpdir/foo # See if what we made is different from the existing target. If tmpdir/foo ? foo, then mv -f tmpdir/foo foo # foo is now newer than it was and will cause downstream rebuilds. else rm -f tmpdir/foo # This is no longer needed, and foo is still its old self. # Prevent make-foo from having to run until a dependency is touched. touch foo-stamp -------------- next part -------------- An HTML attachment was scrubbed... URL: From rahulsoni at immt.res.in Sat Apr 11 04:16:31 2015 From: rahulsoni at immt.res.in (Rahul Kumar Soni) Date: Sat, 11 Apr 2015 13:46:31 +0530 Subject: [CMake] No FindVTK.cmake in cmake 3.1.2 In-Reply-To: References: Message-ID: Okay, found 3 vtkconfig.cmake file. One inside /vtk-5.10 another inside /vtk-5.10/utilities and last inside /usr/local/lib/vtk-5.10. Which one is important. Actually, I am trying to compile liggghts an opensource package which requires vtk installation. Moreover, it requires 3 libraries vtkcommon, vtkfiltering and vtkIO. Where can I find them and link tobyhe makefile of liggghts. -- Sincerely Rahul Kumar Soni Scientist, Institute of Minerals & Materials Technology Council of Scientific & Industrial Research, Govt. of India On Sat, Apr 11, 2015 at 12:20 AM, Robert Maynard wrote: > The VTK find module has been removed as it was a thin wrapper around > find_package(VTK NO_MODULE). You can find this documented at > http://www.cmake.org/cmake/help/v3.2/module/FindVTK.html > > VTK should have came with/built a VTKConfig.cmake that you can CMake at. > > On Fri, Apr 10, 2015 at 6:52 AM, Rahul Kumar Soni > wrote: > > Hi I am newbie to the cmake. I have installed vtk5.10.1 through cygwin in > > windows. The vtk is installed in /cygwin/VTK5.10.1 and its libraries are > in > > /usr/local/lib/vtk-5.10. > > > > I had earlier did similar things in ubuntu and there I required to set > the > > vtk directory in the FindVTK.cmake file with the following command. > > SET (VTK_DIR "/usr/local/lib/vtk-5.10") > > > > However, in cmake3.1.2 I don't find the file FindVTK.cmake. Have > searched a > > lot over internet but no luck. Found that it has something to do with the > > find_package(VTK REQUIRED). But really helpless, how to do it. > > > > Please anyone help or provide a weblink with the proper guidance. > > -- > > Sincerely > > > > Rahul Kumar Soni > > > > Scientist, Institute of Minerals & Materials Technology > > Council of Scientific & Industrial Research, Govt. of India > > > > > > > > -- > > > > Powered by www.kitware.com > > > > Please keep messages on-topic and check the CMake FAQ at: > > http://www.cmake.org/Wiki/CMake_FAQ > > > > Kitware offers various services to support the CMake community. For more > > information on each offering, please visit: > > > > CMake Support: http://cmake.org/cmake/help/support.html > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/cmake > ====================================== > This mail has been scanned by IMMT SPAM Protection. > ====================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at smowton.net Sat Apr 11 06:05:30 2015 From: chris at smowton.net (Chris Smowton) Date: Sat, 11 Apr 2015 11:05:30 +0100 Subject: [CMake] CMake ignores out-of-tree build path after having been run in the source directory? Message-ID: <5528F1EA.4060409@smowton.net> Just finished figuring out why CMake was behaving strangely for me: Originally I built out of tree: mkdir build cd build cmake ../src However at some point it appears I screwed up and typed 'cmake' in /src Thereafter cmake was ignoring the build path and writing all Makefiles in /src; I would try to change something using cmake ../src -DMYVAR=MYVALUE, but the change would be mysteriously ignored... because it was ignoring the cwd /build and updating /src/Makefile, whilst I was using /build/Makefile. Is it ever valid to build in-tree and also build out-of-tree from the same source tree? If so then it probably shouldn't ignore the (cwd) build path like that. If not then it should be a fatal error or at least a warning that your out of tree build is not actually being updated. In other words, it is a tricky trap that "cmake ../src" /might/ mean "update the Makefiles in ../src" or /might/ mean "update the Makefiles in the current directory using the CMakeLists.txt in ../src" At the moment you get: Build files have been written to: /src Which does indicate the problem, but because the message is routine and so I ignore it every day, I didn't notice it for quite some time. Chris From ruslan_baratov at yahoo.com Sun Apr 12 09:48:58 2015 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Sun, 12 Apr 2015 15:48:58 +0200 Subject: [CMake] External Packages? In-Reply-To: References: Message-ID: <552A77CA.60904@yahoo.com> Take a look at this project: https://github.com/ruslo/hunter On 07-Apr-15 21:59, Steven Stallion wrote: > All, > > I'm currently working on a fairly large project that requires a number > of external tools be installed. I've been playing with the idea of > having CMake download and install these packages prior to building the > project. I have something that works using a combination of custom > modules and external projects, but I'm not quite satisfied. > > After trolling through the find_package documentation, I'm tempted to > write a module that will download and install a CPack package hosted > on an HTTP server. This is somewhat similar to the approach that > neovim has taken, however I'd like to use the user package registry > rather than CMAKE_CURRENT_BUILD_DIR; having some persistence would > make life a bit better with multiple clones. > > I'm surprised that CMake doesn't have support for something like this > already - does this ring a bell to anyone? If not, I'm tempted to put > together an ExternalPackage module that would encapsulate this > behavior, which should dovetail nicely with find_package and friends. > > Thoughts? > > Steve > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mjklaim at gmail.com Sun Apr 12 14:51:00 2015 From: mjklaim at gmail.com (=?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?=) Date: Sun, 12 Apr 2015 20:51:00 +0200 Subject: [CMake] External Packages? In-Reply-To: <552A77CA.60904@yahoo.com> References: <552A77CA.60904@yahoo.com> Message-ID: On Sun, Apr 12, 2015 at 3:48 PM, Ruslan Baratov via CMake wrote: > Take a look at this project: https://github.com/ruslo/hunter > > Interesting, it have some similarities with CPM: https://github.com/iauns/cpm -------------- next part -------------- An HTML attachment was scrubbed... URL: From golubdr at gmail.com Sun Apr 12 16:56:11 2015 From: golubdr at gmail.com (David Golub) Date: Sun, 12 Apr 2015 16:56:11 -0400 Subject: [CMake] CMake Tools for Visual Studio 1.3 Released! Message-ID: <005701d07563$1b7be1a0$5273a4e0$@gmail.com> I'm pleased to announced that I've announced version 1.3 of CMake Tools for Visual Studio, my extension adding CMake support to Microsoft Visual Studio. This release adds support for CMake 3.1 and IntelliSense for generator expressions. It can be downloaded from the project web site at http://cmaketools.codeplex.com. Enjoy! David Golub -------------- next part -------------- An HTML attachment was scrubbed... URL: From nico.schloemer at gmail.com Mon Apr 13 04:40:47 2015 From: nico.schloemer at gmail.com (=?UTF-8?Q?Nico_Schl=C3=B6mer?=) Date: Mon, 13 Apr 2015 08:40:47 +0000 Subject: [CMake] project(), find_package() Message-ID: Hi everyone, I have a CMake project where I need to find the third-party package ``` FIND_PACKAGE(Trilinos REQUIRED) ``` which sits in the custom folder ``` /path/to/lib/x86_64-linux-gnu/cmake/Trilinos/TrilinosConfig.cmake ``` Unfortunately, simply extending the CMAKE_PREFIX_PATH ``` CMAKE_PREFIX_PATH=/path/to/:$CMAKE_PREFIX_PATH \ cmake ../source/ ``` did not do the trick: ``` CMake Error at CMakeLists.txt:25 (FIND_PACKAGE): By not providing "FindTrilinos.cmake" in CMAKE_MODULE_PATH this project has asked CMake to find a package configuration file provided by "Trilinos", but CMake did not find one. Could not find a package configuration file provided by "Trilinos" with any of the following names: TrilinosConfig.cmake trilinos-config.cmake [...] ``` What *does* help was setting the `project()` *before* `find_package()`. Is this something that documented anywhere? Cheers, Nico -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Mon Apr 13 04:56:04 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Mon, 13 Apr 2015 10:56:04 +0200 Subject: [CMake] project(), find_package() In-Reply-To: References: Message-ID: <552B84A4.4040709@gmail.com> On 04/13/2015 10:40 AM, Nico Schl?mer wrote: > FIND_PACKAGE(Trilinos REQUIRED) > ``` > which sits in the custom folder > ``` > /path/to/lib/x86_64-linux-gnu/cmake/Trilinos/TrilinosConfig.cmake [...] > What *does* help was setting the `project()` *before* `find_package()`. > Is this something that documented anywhere? I don't think it is documented that explicitly but it is implied by the fact that project() [1] performs language initialization (that part is documented). That includes determining that your compiler targets e.g. "x86_64-linux-gnu" so that find_package() knows to look in that target specific directory. Nils [1] http://www.cmake.org/cmake/help/v3.2/command/project.html From cedric.doucet at inria.fr Mon Apr 13 05:04:01 2015 From: cedric.doucet at inria.fr (Cedric Doucet) Date: Mon, 13 Apr 2015 11:04:01 +0200 (CEST) Subject: [CMake] Don't download external projects again after calling "make clean" In-Reply-To: <1351653491.156868.1428915508943.JavaMail.zimbra@inria.fr> Message-ID: <1334535078.171898.1428915841518.JavaMail.zimbra@inria.fr> Hello! I use the ExternalProject_Add function to download third-party libraries of a code. Once a library has been downloaded, I can call "make" as many times as I want without downloading this library again. It seems that CMake detects that the library has already been downloaded. However, calling "make clean" seems to destroy this feature. Even if my library is not uninstalled during cleaning, calling "make" after "make clean" will lead CMake to try download the library again. How could I tell CMake not to download the library again? Thank you very much for your help! C?dric -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Mon Apr 13 06:40:34 2015 From: DLRdave at aol.com (David Cole) Date: Mon, 13 Apr 2015 06:40:34 -0400 Subject: [CMake] Don't download external projects again after calling "make clean" In-Reply-To: <1334535078.171898.1428915841518.JavaMail.zimbra@inria.fr> References: <1351653491.156868.1428915508943.JavaMail.zimbra@inria.fr> <1334535078.171898.1428915841518.JavaMail.zimbra@inria.fr> Message-ID: Use the URL_MD5 and DOWNLOAD_DIR arguments to ExternalProject_Add to put the downloaded files into a location outside the build tree (perhaps ~/Downloads on Mac/Linux or $ENV{USERPROFILE}/Downloads on Windows). With DOWNLOAD_DIR outside the build tree, and the checksums of the downloaded files being the same as you've specified via URL_MD5, the download portion will be avoided once there is a local copy of a file available. HTH, David C. On Mon, Apr 13, 2015 at 5:04 AM, Cedric Doucet wrote: > > Hello! > > I use the ExternalProject_Add function to download third-party libraries of > a code. > > Once a library has been downloaded, I can call "make" as many times as I > want without downloading this library again. > It seems that CMake detects that the library has already been downloaded. > > However, calling "make clean" seems to destroy this feature. > Even if my library is not uninstalled during cleaning, calling "make" after > "make clean" will lead CMake to try download the library again. > > How could I tell CMake not to download the library again? > > Thank you very much for your help! > > C?dric > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 r2d2leboss at voila.fr Mon Apr 13 08:08:40 2015 From: r2d2leboss at voila.fr (r2d2leboss at voila.fr) Date: Mon, 13 Apr 2015 14:08:40 +0200 (CEST) Subject: [CMake] Find Module, add_library shared and static : standard ? Message-ID: <24460336.50221428926920117.JavaMail.www@wwinf7118> Hi, I need to write a FindModule which search static and shared version of my lib. I need both on my project (there is a diff between static and dynamic lib). I would like to import my lib using add_library : add_library(Foo::MyLib STATIC IMPORTED) add_library(Foo::MyLib SHARED IMPORTED) This one will not works (same name) and I will not be able to distinguish static and shared. By default, I would like that MyLib point to shared (what find_library find by default). But If I specify something (what ?), I would like to use static lib during link. target_link_libraries(myProg Foo::MyLib) -> link to shared version do something() target_link_libraries(myProg Foo::MyLib) -> link to static version restore shared ? I would like to know what is the standard name, convention to import library static and shared ? (MyLib.a and MyLib.so) * Two names ? (Foo::MyLib, Foo::MyLibStatic) ? (Foo::MyLib, Foo::Static::MyLib) ? * Two configurations ? How to use it ? Thank you, John ___________________________________________________________ Mode, hifi, maison,? J'ach?te malin. Je compare les prix avec Voila.fr http://shopping.voila.fr/ From brad.king at kitware.com Mon Apr 13 10:20:47 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 13 Apr 2015 10:20:47 -0400 Subject: [CMake] Bug in CMake GUI 3.2.1? In-Reply-To: References: Message-ID: <552BD0BF.2000404@kitware.com> On 04/10/2015 12:26 PM, Robert Dailey wrote: > I am noticing that after installing the official Windows installer for > 3.2.1 release, CMake GUI looks different. Menu options have GCC > specific options and when I generate through the GUI for Visual Studio > 2013, my projects are missing preprocessor definitions like _WINDOWS, > WIN32, etc. I don't see any of that behavior. I would think such major breakage would have been reported pretty quickly, so something may be wrong locally for you. From what environment are you running cmake-gui? -Brad From rcdailey.lists at gmail.com Mon Apr 13 10:28:11 2015 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Mon, 13 Apr 2015 09:28:11 -0500 Subject: [CMake] Bug in CMake GUI 3.2.1? In-Reply-To: <552BD0BF.2000404@kitware.com> References: <552BD0BF.2000404@kitware.com> Message-ID: I am running on Windows 8.1. Screenshots attached. On Mon, Apr 13, 2015 at 9:20 AM, Brad King wrote: > On 04/10/2015 12:26 PM, Robert Dailey wrote: >> I am noticing that after installing the official Windows installer for >> 3.2.1 release, CMake GUI looks different. Menu options have GCC >> specific options and when I generate through the GUI for Visual Studio >> 2013, my projects are missing preprocessor definitions like _WINDOWS, >> WIN32, etc. > > I don't see any of that behavior. I would think such major breakage > would have been reported pretty quickly, so something may be wrong > locally for you. From what environment are you running cmake-gui? > > -Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: cmakegui.png Type: image/png Size: 24619 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cmake-gui-about.png Type: image/png Size: 9517 bytes Desc: not available URL: From nilsgladitz at gmail.com Mon Apr 13 10:30:41 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Mon, 13 Apr 2015 16:30:41 +0200 Subject: [CMake] Bug in CMake GUI 3.2.1? In-Reply-To: References: <552BD0BF.2000404@kitware.com> Message-ID: <552BD311.8010409@gmail.com> On 04/13/2015 04:28 PM, Robert Dailey wrote: > I am running on Windows 8.1. Screenshots attached. Those are options for cmake itself rather than for the compiler: http://www.cmake.org/cmake/help/v3.2/manual/cmake.1.html Nils From steveire at gmail.com Mon Apr 13 13:56:26 2015 From: steveire at gmail.com (Stephen Kelly) Date: Mon, 13 Apr 2015 19:56:26 +0200 Subject: [CMake] Find Module, add_library shared and static : standard ? References: <24460336.50221428926920117.JavaMail.www@wwinf7118> Message-ID: r2d2leboss at voila.fr wrote: > Hi, > > I need to write a FindModule which search static and shared version of my > lib. If it is your library, then you provide a Config.cmake file, not a FindModule: http://www.cmake.org/cmake/help/v3.2/manual/cmake-packages.7.html > I would like to know what is the standard name, convention to import > library static and shared ? (MyLib.a and MyLib.so) > * Two names ? > (Foo::MyLib, Foo::MyLibStatic) ? (Foo::MyLib, Foo::Static::MyLib) ? I think this is the best solution cmake currently offers. The bug http://public.kitware.com/Bug/view.php?id=4222 tracks this. Thanks, Steve. From nico.schloemer at gmail.com Tue Apr 14 08:03:24 2015 From: nico.schloemer at gmail.com (=?UTF-8?Q?Nico_Schl=C3=B6mer?=) Date: Tue, 14 Apr 2015 12:03:24 +0000 Subject: [CMake] *Config.cmake documentation Message-ID: Hi everyone, We're trying to enhance the export functionality of TriBits [1] and are looking for some good pieces of documentation of what export config files should ideally look like. Any pointers? Cheers, Nico [1] github.com/TriBITSPub/TriBITS -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Tue Apr 14 09:13:07 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 14 Apr 2015 15:13:07 +0200 Subject: [CMake] *Config.cmake documentation In-Reply-To: References: Message-ID: <552D1263.1050100@gmail.com> On 04/14/2015 02:03 PM, Nico Schl?mer wrote: > Hi everyone, > > We're trying to enhance the export functionality of TriBits [1] and are > looking for some good pieces of documentation of what export config > files should ideally look like. > > Any pointers? For target exports created by cmake itself there is: http://www.cmake.org/cmake/help/v3.2/manual/cmake-packages.7.html#creating-packages Nils From bartlettra at ornl.gov Tue Apr 14 12:25:12 2015 From: bartlettra at ornl.gov (Bartlett, Roscoe A.) Date: Tue, 14 Apr 2015 16:25:12 +0000 Subject: [CMake] Flushing CMake STDOUT to avoid jumbled output? Message-ID: Hello CMake people, Is there a way to make CMake flush STDOUT (written two with MESSAGE() command) so that we don't get jumbled output? This is a problem since I have tests that grep output generated by CMake and it cases tests to fail like shown at: http://testing.sandia.gov/cdash/testDetails.php?test=29022135&build=2019497 which causes the test to fail because it writes out: -- Configuring incomplete, errors occurred! right in the middle of the line: "to point to the include directories which will bypass any search for" which causes the test criteria to fail: TEST_1: Pass criteria = Match REGEX { to point to the include directories which will bypass any search for} [FAILED] since it prints: to point to the inc-- Configuring incomplete, errors occurred! lude directories which will bypass any search for Thanks, -Ross _______________________________________________________________________________ Dr. Roscoe A. Bartlett, PhD Oak Ridge National Laboratory CASL Physics Integration Software Engineering Lead Trilinos Software Engineering Technologies and Integration Lead http://web.ornl.gov/~8vt/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Tue Apr 14 13:10:03 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 14 Apr 2015 13:10:03 -0400 Subject: [CMake] Flushing CMake STDOUT to avoid jumbled output? In-Reply-To: References: Message-ID: <552D49EB.8000404@kitware.com> On 04/14/2015 12:25 PM, Bartlett, Roscoe A. wrote: > Is there a way to make CMake flush STDOUT Not from the CMake language. However, it shouldn't matter. > This is a problem since I have tests that grep output generated [snip] > to point to the inc-- Configuring incomplete, errors occurred! > lude directories which will bypass any search for The problem is in cmake/tribits/utils/DriveAdvancedTest.cmake where the test is run with: EXECUTE_PROCESS( ${EXEC_CMND} OUTPUT_VARIABLE TEST_CMND_OUT ERROR_VARIABLE TEST_CMND_OUT RESULT_VARIABLE EXEC_RESULT ) This combines the stdout and stderr into one variable in an unspecified way. If you want to match test output reliably then you should capture stdout and stderr in two separate variables: OUTPUT_VARIABLE TEST_CMND_OUT ERROR_VARIABLE TEST_CMND_ERR and perform matching on them separately. This results in more precise tests because it verifies that the processes produce the content expected on each pipe. -Brad From robert.maynard at kitware.com Tue Apr 14 13:49:30 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 14 Apr 2015 13:49:30 -0400 Subject: [CMake] [ANNOUNCE] CMake 3.2.2 Released Message-ID: We are pleased to announce that CMake 3.2.2 is now available for download. Please use the latest release from our download page: http://www.cmake.org/download/ Thanks for your support! ------------------------------------------------------------------------- Changes in 3.2.2 since 3.2.1: Betsy McPhail (1): file(LOCK): Close file descriptor/handle when releasing a lock Brad King (8): FindMFC: Use if(DEFINED) to simplify condition (#15477) curl: Never consider using Windows APIs on Cygwin liblzma: Use unaligned access only on Intel and PowerPC archs liblzma: Disable XL compiler optimizations liblzma: Disable GNU 3.3 compiler optimizations KWSys SystemTools: Teach Touch with !create to succeed on missing file Makefile: Fix multiple custom command outputs with one missing CMake 3.2.2 Tim Kientzle (1): libarchive: Fix string concatentation in Windows mktemp implementation From mike.jackson at bluequartz.net Tue Apr 14 16:44:52 2015 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Tue, 14 Apr 2015 16:44:52 -0400 Subject: [CMake] CMake removes rpath from Linux binaries. How to stop Message-ID: I am trying to create a standalone build of our application on Linux. We are currently building on a mix of Mint 17 and Ubuntu 14.04. I have been doing a lot of reading about rpath, runpath and chrpath. The only way it would seem to get this done is to adjust the rpath via the "chrpath" tool. The issue is that during packaging, cmake is removing the rpath from the binaries which kills the process of using chrpath. I have looked at the various *_RPATH* cmake variables but none of the combinations seem to work correctly. CMake always strips the rpath from the binaries. This is with a Qt5 application which compiles against the Qt 5.4.1 version which is installed from the Qt.io website. Any help would be much appreciated. _________________________________________________________ Mike Jackson mike.jackson at bluequartz.net BlueQuartz Software www.bluequartz.net Principal Software Engineer Dayton, Ohio -------------- next part -------------- An HTML attachment was scrubbed... URL: From clinton at elemtech.com Tue Apr 14 17:54:07 2015 From: clinton at elemtech.com (clinton at elemtech.com) Date: Tue, 14 Apr 2015 15:54:07 -0600 (MDT) Subject: [CMake] CMake removes rpath from Linux binaries. How to stop In-Reply-To: References: Message-ID: <350704071.1504603.1429048447136.JavaMail.zimbra@elemtech.com> ----- Original Message ----- > I am trying to create a standalone build of our application on Linux. We are > currently building on a mix of Mint 17 and Ubuntu 14.04. I have been doing a > lot of reading about rpath, runpath and chrpath. The only way it would seem > to get this done is to adjust the rpath via the "chrpath" tool. The issue is > that during packaging, cmake is removing the rpath from the binaries which > kills the process of using chrpath. I have looked at the various *_RPATH* > cmake variables but none of the combinations seem to work correctly. CMake > always strips the rpath from the binaries. This is with a Qt5 application > which compiles against the Qt 5.4.1 version which is installed from the > Qt.io website. Have you tried only setting the INSTALL_RPATH property on the targets? Or setting the CMAKE_INSTALL_RPATH in your top level CMakeLists.txt file. For example: if (CMAKE_SYSTEM_NAME MATCHES "Linux" ) set (CMAKE_ INSTALL _RPATH "\$ORIGIN" ) endif () That alone should be enough to give you rpaths in the install tree. Clint -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicktasios at gmail.com Wed Apr 15 06:20:40 2015 From: nicktasios at gmail.com (Nick Tasios) Date: Wed, 15 Apr 2015 12:20:40 +0200 Subject: [CMake] install target added with add_subdirectory(EXCLUDE_FROM_ALL) Message-ID: <552E3B78.3080103@gmail.com> Hello everyone, I recently started using cmake and I'm having some trouble setting-up my project. I've searched quite a lot and couldn't find a clear answer. The project has a top level CMakeLists.txt which builds the executable. In my project, I have included external libraries which I add using add_subdirectory. Most of these already came with a CMakeLists.txt file, and some have multiple targets, i.e. to build shared or static libraries, etc. In the project, though, I want to be able to choose only a specific target to build, i.e. I might only want to build the shared libraries. To do this, I add the option EXCLUDE_FROM_ALL when calling add_subdirectory, and just add the target to the target link libraries of the top-level executable. This works fine, only in the install step I would like for the built libraries to move to where the executable is. From my understanding, the install directive of the sub projects is ignored, because install depends on all and these sub projects are excluded from it. So the question is, if there is a clean way to compile only the targets (libraries) that are needed by the executable, and be able to install these in the directory the executable is being installed. The method needs to work cross-platform. Cheers! From ecam at gmx.at Wed Apr 15 08:42:09 2015 From: ecam at gmx.at (Mathias Giacomuzzi) Date: Wed, 15 Apr 2015 14:42:09 +0200 Subject: [CMake] CMake Cross Compiling GCC Message-ID: An HTML attachment was scrubbed... URL: From ecam at gmx.at Wed Apr 15 10:28:45 2015 From: ecam at gmx.at (Mathias Giacomuzzi) Date: Wed, 15 Apr 2015 16:28:45 +0200 Subject: [CMake] Cmake force a specific gnu arm toolchain Message-ID: An HTML attachment was scrubbed... URL: From tom at recursivedream.com Wed Apr 15 12:10:00 2015 From: tom at recursivedream.com (Tom Davis) Date: Wed, 15 Apr 2015 12:10:00 -0400 Subject: [CMake] Updating external source where URL is a directory? Message-ID: <87r3rltlt3.fsf@recursivedream.com> I am using ExternalProject_Add() to add a dependent project. When I'm developing locally, I want to be able to make changes to the dependency and have them pulled in by the parent build without having to commit said changes to a remote repository. To include the dependency, I am using the `URL` parameter and setting it to the absolute path to the other project. This works fine initially, but re-making the parent project never updates the dependency. Even cleaning the dependency doesn't work; the files in $EP_BASE/Source/dep/ aren't updated so I end up re-making whatever outdated source is there. What am I missing here? From bnewcomb at nvidia.com Wed Apr 15 18:07:47 2015 From: bnewcomb at nvidia.com (Bill Newcomb) Date: Wed, 15 Apr 2015 15:07:47 -0700 Subject: [CMake] linking question Message-ID: <552EE133.1070904@nvidia.com> The following is all on Linux (with gcc, gnu binutils, etc). I'm trying to build libfred.so that uses code from libjoe.a, but I want libfred.so to be complete, i.e. I don't want any program that I build that links to libfred.so also need libjoe.a. Then I want to build executable mike that is dynamically linked with libfred.so . However, the link script for mike puts libjoe.a on the command line. add_library(joe STATIC joe.c joe_a.c) add_library(fred SHARED fred.c fred_a.c) target_link_libraries(fred joe) add_executable(mike mike.c) # mike only contains calls to functions in fred target_link_libraries(mike fred) The docs give me the impression that I should set the INTERFACE_LINK_LIBRARIES property on moo to override the inherited transitive dependencies, but setting it to "" has no effect. Same for LINK_INTERFACE_LIBRARIES. Any idea how to make this work? 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 diltsman at gmail.com Wed Apr 15 19:25:29 2015 From: diltsman at gmail.com (Daniel Dilts) Date: Wed, 15 Apr 2015 16:25:29 -0700 Subject: [CMake] add_custom_commmand TARGET is unknown Message-ID: I have a function that does something like this: add_dependencies(${LibraryName} SomeTarget) add_custom_command(TARGET SomeTarget PRE_BUILD COMMAND MyExecutable.exe USES_TERMINAL ) It creates the dependency without any issues, but it gives the following error on the custom command: CMake Error at CMakeLists.txt:37 (add_custom_command): The target name "SomeTarget" is unknown in this context. SomeTarget is created using add_library later in the build system. Is there some way to make this work? SomeTarget is created deeper in the build system (3-5 directories down). -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.j.abraham at gmail.com Wed Apr 15 21:00:10 2015 From: mark.j.abraham at gmail.com (Mark Abraham) Date: Thu, 16 Apr 2015 03:00:10 +0200 Subject: [CMake] add_custom_commmand TARGET is unknown In-Reply-To: References: Message-ID: Hi, CMakeLists.txt files are processed from start to finish, so if you want to refer to a target created in a subdirectory, then you need to have added that subdirectory before using that target. Mark On 16/04/2015 1:25 am, "Daniel Dilts" wrote: > I have a function that does something like this: > > add_dependencies(${LibraryName} SomeTarget) > add_custom_command(TARGET SomeTarget PRE_BUILD > COMMAND MyExecutable.exe > USES_TERMINAL > ) > > It creates the dependency without any issues, but it gives the following > error on the custom command: > > CMake Error at CMakeLists.txt:37 (add_custom_command): > The target name "SomeTarget" is unknown in this context. > > SomeTarget is created using add_library later in the build system. > > Is there some way to make this work? SomeTarget is created deeper in the > build system (3-5 directories down). > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 Thu Apr 16 02:53:34 2015 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Thu, 16 Apr 2015 08:53:34 +0200 Subject: [CMake] linking question In-Reply-To: <552EE133.1070904@nvidia.com> References: <552EE133.1070904@nvidia.com> Message-ID: Hi Bill. Probably the easiest way to set the interface properties to just what you need is to use the PUBLIC (which is the default), PRIVATE and INTERFACE keywords when specifying dependencies. In your case, you'd apply them like this: add_library(joe STATIC joe.c joe_a.c) add_library(fred SHARED fred.c fred_a.c) target_link_libraries(fred PRIVATE joe) # PRIVATE means it will not form part of the transitive linking interface add_executable(mike mike.c) # mike only contains calls to functions in fred target_link_libraries(mike fred) I hope this helps. Petr On Thu, Apr 16, 2015 at 12:07 AM, Bill Newcomb wrote: > The following is all on Linux (with gcc, gnu binutils, etc). > > I'm trying to build libfred.so that uses code from libjoe.a, but I want > libfred.so to be complete, i.e. I don't want any program that I build that > links to libfred.so also need libjoe.a. > > Then I want to build executable mike that is dynamically linked with > libfred.so . However, the link script for mike puts libjoe.a on the > command line. > > add_library(joe STATIC joe.c joe_a.c) > add_library(fred SHARED fred.c fred_a.c) > target_link_libraries(fred joe) > > add_executable(mike mike.c) > # mike only contains calls to functions in fred > target_link_libraries(mike fred) > > > The docs give me the impression that I should set the > INTERFACE_LINK_LIBRARIES property on moo to override the inherited > transitive dependencies, but setting it to "" has no effect. Same for > LINK_INTERFACE_LIBRARIES. > > Any idea how to make this work? > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From diltsman at gmail.com Thu Apr 16 14:47:49 2015 From: diltsman at gmail.com (Daniel Dilts) Date: Thu, 16 Apr 2015 11:47:49 -0700 Subject: [CMake] add_custom_commmand TARGET is unknown In-Reply-To: References: Message-ID: I moved the add_custom_target to the 4th line of my top-level CMakeLists.txt. The only lines before it are cmake_minimum_required, project, and a single set. I also made sure that the name of the target matches the target name in add_custom_command and add_dependencies. I am still getting the same set of errors. On Wed, Apr 15, 2015 at 6:00 PM, Mark Abraham wrote: > Hi, > > CMakeLists.txt files are processed from start to finish, so if you want to > refer to a target created in a subdirectory, then you need to have added > that subdirectory before using that target. > > Mark > On 16/04/2015 1:25 am, "Daniel Dilts" wrote: > >> I have a function that does something like this: >> >> add_dependencies(${LibraryName} SomeTarget) >> add_custom_command(TARGET SomeTarget PRE_BUILD >> COMMAND MyExecutable.exe >> USES_TERMINAL >> ) >> >> It creates the dependency without any issues, but it gives the following >> error on the custom command: >> >> CMake Error at CMakeLists.txt:37 (add_custom_command): >> The target name "SomeTarget" is unknown in this context. >> >> SomeTarget is created using add_library later in the build system. >> >> Is there some way to make this work? SomeTarget is created deeper in the >> build system (3-5 directories down). >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware 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 diltsman at gmail.com Thu Apr 16 16:01:09 2015 From: diltsman at gmail.com (Daniel Dilts) Date: Thu, 16 Apr 2015 13:01:09 -0700 Subject: [CMake] add_custom_commmand TARGET is unknown In-Reply-To: References: Message-ID: I have the following in my lists: if(TARGET CustomTarget) message("TARGET CustomTarget") else() message("NOT TARGET CustomTarget") endif() add_custom_command(TARGET CustomTarget PRE_BUILD COMMAND CustomCommand.exe USES_TERMINAL ) In my output I get: TARGET CustomTarget CMake Error at Some/Path/CMakeLists.txt:52 (add_custom_command ): The target name "CustomTarget" is unknown in this context. It seems like the if() shows that there is a target with the desired name. Am I missing something? On Thu, Apr 16, 2015 at 11:47 AM, Daniel Dilts wrote: > I moved the add_custom_target to the 4th line of my top-level > CMakeLists.txt. The only lines before it are cmake_minimum_required, > project, and a single set. I also made sure that the name of the target > matches the target name in add_custom_command and add_dependencies. I am > still getting the same set of errors. > > On Wed, Apr 15, 2015 at 6:00 PM, Mark Abraham > wrote: > >> Hi, >> >> CMakeLists.txt files are processed from start to finish, so if you want >> to refer to a target created in a subdirectory, then you need to have added >> that subdirectory before using that target. >> >> Mark >> On 16/04/2015 1:25 am, "Daniel Dilts" wrote: >> >>> I have a function that does something like this: >>> >>> add_dependencies(${LibraryName} SomeTarget) >>> add_custom_command(TARGET SomeTarget PRE_BUILD >>> COMMAND MyExecutable.exe >>> USES_TERMINAL >>> ) >>> >>> It creates the dependency without any issues, but it gives the following >>> error on the custom command: >>> >>> CMake Error at CMakeLists.txt:37 (add_custom_command): >>> The target name "SomeTarget" is unknown in this context. >>> >>> SomeTarget is created using add_library later in the build system. >>> >>> Is there some way to make this work? SomeTarget is created deeper in >>> the build system (3-5 directories down). >>> >>> -- >>> >>> Powered by www.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: >>> http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For more >>> information on each offering, please visit: >>> >>> CMake Support: http://cmake.org/cmake/help/support.html >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware 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 nilsgladitz at gmail.com Thu Apr 16 16:08:24 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 16 Apr 2015 22:08:24 +0200 Subject: [CMake] add_custom_commmand TARGET is unknown In-Reply-To: References: Message-ID: <553016B8.5030904@gmail.com> On 16.04.2015 22:01, Daniel Dilts wrote: > I have the following in my lists: > if(TARGET CustomTarget) > message("TARGET CustomTarget") > else() > message("NOT TARGET CustomTarget") > endif() > add_custom_command(TARGET CustomTarget PRE_BUILD > COMMAND CustomCommand.exe > USES_TERMINAL > ) > > In my output I get: > TARGET CustomTarget > CMake Error at Some/Path/CMakeLists.txt:52 (add_custom_command > ): > The target name "CustomTarget" is unknown in this context. > > It seems like the if() shows that there is a target with the desired > name. Am I missing something? You can only modify a target after it has been defined and in the directory (CMakeLists.txt) that defined it. The same goes for appending commands to targets. Nils From diltsman at gmail.com Thu Apr 16 16:25:55 2015 From: diltsman at gmail.com (Daniel Dilts) Date: Thu, 16 Apr 2015 13:25:55 -0700 Subject: [CMake] add_custom_commmand TARGET is unknown In-Reply-To: <553016B8.5030904@gmail.com> References: <553016B8.5030904@gmail.com> Message-ID: You can only add commands to a target that was defined in the current directory? So, I would have to have a new target for each directory and then have a target that depends on all of those targets? On Thu, Apr 16, 2015 at 1:08 PM, Nils Gladitz wrote: > On 16.04.2015 22:01, Daniel Dilts wrote: > >> I have the following in my lists: >> if(TARGET CustomTarget) >> message("TARGET CustomTarget") >> else() >> message("NOT TARGET CustomTarget") >> endif() >> add_custom_command(TARGET CustomTarget PRE_BUILD >> COMMAND CustomCommand.exe >> USES_TERMINAL >> ) >> >> In my output I get: >> TARGET CustomTarget >> CMake Error at Some/Path/CMakeLists.txt:52 (add_custom_command >> ): >> The target name "CustomTarget" is unknown in this context. >> >> It seems like the if() shows that there is a target with the desired >> name. Am I missing something? >> > > You can only modify a target after it has been defined and in the > directory (CMakeLists.txt) that defined it. > The same goes for appending commands to targets. > > Nils > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Thu Apr 16 16:34:19 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 16 Apr 2015 22:34:19 +0200 Subject: [CMake] add_custom_commmand TARGET is unknown In-Reply-To: References: <553016B8.5030904@gmail.com> Message-ID: <55301CCB.4030009@gmail.com> On 16.04.2015 22:25, Daniel Dilts wrote: > You can only add commands to a target that was defined in the current > directory? So, I would have to have a new target for each directory > and then have a target that depends on all of those targets? I don't know your use case so I can not comment on what you have to do or should do. Disregarding your use case ... to make it "work" (to stop cmake from complaining) all you have to do is move creation of the custom commands into the directory where the target is defined. The information required to create these commands may come from different scopes (e.g. you could maintain variables or global properties with the information required to construct the appropriate commands). Nils From irwin at beluga.phys.uvic.ca Thu Apr 16 16:34:21 2015 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Thu, 16 Apr 2015 13:34:21 -0700 (PDT) Subject: [CMake] cmp0026, file(GENERATE...), and configure_file Message-ID: I am trying to change the existing PLplot build system to set CMP0026 to new following the existing advice that file(GENERATE...) should be used to configure target locations in a file using generator expressions. But the issue is configure_file currently (see end question below) does not appear to honor generator expressions, but it is still needed to configure @...@ expressions. So is it recommended that a two-step procedure be used to configure a file? For example: # Deal with @...@ configurable items: configure_file( ${CMAKE_CURRENT_SOURCE_DIR}/pkgIndex.tcl.in ${CMAKE_CURRENT_BINARY_DIR}/pkgIndex.tcl_at_configured @ONLY ) # Deal with items configured with generator expressions: file(GENERATE OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/pkgIndex.tcl INPUT ${CMAKE_CURRENT_BINARY_DIR}/pkgIndex.tcl_at_configured ) The above idea appears to work although it then exposes a config-time versus generate-time issue where ${CMAKE_CURRENT_BINARY_DIR}/pkgIndex.tcl needs to be concatenated with other files in order to install a concatenated result. I think I can work those other issues out by doing that concatenation at make time or install time (as opposed to cmake time), but can someone confirm the above method is the best way (and perhaps the only way right now?) to configure a file with both @...@ configurable items and generator expressions? @Cmake developers: If the above complications for configured files are the only way to deal with a mixture of @...@ items and generator expressions to configure, could a change to configure_file so that it honors generator expressions be implemented to avoid these complications? Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From bnewcomb at nvidia.com Thu Apr 16 17:53:37 2015 From: bnewcomb at nvidia.com (Bill Newcomb) Date: Thu, 16 Apr 2015 14:53:37 -0700 Subject: [CMake] linking question In-Reply-To: References: <552EE133.1070904@nvidia.com> Message-ID: <55302F61.5060307@nvidia.com> This solved the cmake end of this. Thanks! B. On 04/15/2015 11:53 PM, Petr Kmoch wrote: > Hi Bill. > > Probably the easiest way to set the interface properties to just what > you need is to use the PUBLIC (which is the default), PRIVATE and > INTERFACE keywords when specifying dependencies. In your case, you'd > apply them like this: > > add_library(joe STATIC joe.c joe_a.c) > add_library(fred SHARED fred.c fred_a.c) > target_link_libraries(fred PRIVATE joe) # PRIVATE means it will not > form part of the transitive linking interface > > add_executable(mike mike.c) > # mike only contains calls to functions in fred > target_link_libraries(mike fred) > > I hope this helps. > > Petr > > > On Thu, Apr 16, 2015 at 12:07 AM, Bill Newcomb > wrote: > > The following is all on Linux (with gcc, gnu binutils, etc). > > I'm trying to build libfred.so that uses code from libjoe.a, but I > want libfred.so to be complete, i.e. I don't want any program that I > build that links to libfred.so also need libjoe.a. > > Then I want to build executable mike that is dynamically linked with > libfred.so . However, the link script for mike puts libjoe.a on the > command line. > > add_library(joe STATIC joe.c joe_a.c) > add_library(fred SHARED fred.c fred_a.c) > target_link_libraries(fred joe) > > add_executable(mike mike.c) > # mike only contains calls to functions in fred > target_link_libraries(mike fred) > > > The docs give me the impression that I should set the > INTERFACE_LINK_LIBRARIES property on moo to override the inherited > transitive dependencies, but setting it to "" has no effect. Same > for LINK_INTERFACE_LIBRARIES. > > Any idea how to make this work? > > 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 diltsman at gmail.com Thu Apr 16 19:08:45 2015 From: diltsman at gmail.com (Daniel Dilts) Date: Thu, 16 Apr 2015 16:08:45 -0700 Subject: [CMake] JOIN generator expression not working Message-ID: I have this generator expression: -I$, -I> I get this output in my custom command: -I$ This is almost exactly the same as the example in the documentation (other than adding ${LibraryName}). Why doesn't this work? -------------- next part -------------- An HTML attachment was scrubbed... URL: From wonder.mice at gmail.com Thu Apr 16 21:39:39 2015 From: wonder.mice at gmail.com (Andrey Pokrovskiy) Date: Thu, 16 Apr 2015 18:39:39 -0700 Subject: [CMake] ExternalProject can't have interface library as a dependency Message-ID: /* I'm using cmake-3.2.20150331-gb190c. */ I have a following construction: ExternalProject_Add( websockets_ep DEPENDS ev openssl ...) But it so happened, that "openssl" is a INTERFACE library. Because of that I get an obscure error: CMake Error at /usr/share/cmake/share/cmake-3.2/Modules/ExternalProject.cmake:2031 (get_property): INTERFACE_LIBRARY targets may only have whitelisted properties. The property "_EP_IS_EXTERNAL_PROJECT" is not allowed. Call Stack (most recent call first): /usr/share/cmake/share/cmake-3.2/Modules/ExternalProject.cmake:2328 (_ep_add_configure_command) src/libwebsockets/CMakeLists.txt:21 (ExternalProject_Add) Apparently because there is a check inside get_property() that whitelists what properties could be queried. Maybe we don't need a whitelist for get_property()? :) From cedric.doucet at inria.fr Fri Apr 17 01:32:03 2015 From: cedric.doucet at inria.fr (Cedric Doucet) Date: Fri, 17 Apr 2015 07:32:03 +0200 (CEST) Subject: [CMake] Don't download external projects again after calling "make clean" In-Reply-To: References: <1351653491.156868.1428915508943.JavaMail.zimbra@inria.fr> <1334535078.171898.1428915841518.JavaMail.zimbra@inria.fr> Message-ID: <1121188496.1727145.1429248723887.JavaMail.zimbra@inria.fr> Hello David, thank you very much for your help. Unfortunately I may do something wrong because it does not work. After cleaning, the library is downloaded again. I guess my mistake comes from the fact I do not understand the role of URL_MD5. Below is a simple example where downloading and installing is very fast. You just have to replace the value of EXTERNAL_DIR by the path to your own "Downloads" repository. I tried to put URL in my DOWNLOAD_COMMAND but the call "wget " does not seem to be understood by the wget command. Thanks again! C?dric -------------------------------------------------------------------------- cmake_minimum_required (VERSION 2.6) project (example CXX) set(CMAKE_VERBOSE_MAKEFILE ON) include(ProcessorCount) ProcessorCount(N) if(NOT N EQUAL 0) set(CMAKE_BUILD_FLAGS -j${N}) endif() include(ExternalProject) set(EXTERNAL_DIR /home/cdoucet/Downloads) ExternalProject_Add(eigen PREFIX ${EXTERNAL_DIR}/eigen DOWNLOAD_DIR ${EXTERNAL_DIR}/eigen/download SOURCE_DIR ${EXTERNAL_DIR}/eigen/src BINARY_DIR ${EXTERNAL_DIR}/eigen/build INSTALL_DIR ${EXTERNAL_DIR}/eigen/install URL http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz URL_MD5 ccb18a771f678b38a3d33c321a8e7daf DOWNLOAD_COMMAND wget http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz && tar xvzf 3.2.4.tar.gz -C --strip-components=1 CONFIGURE_COMMAND cd && cmake -D CMAKE_INSTALL_PREFIX=$ ) ------------------------------------------------------------------------------ ----- Mail original ----- > De: "David Cole" > ?: "Cedric Doucet" > Cc: cmake at cmake.org > Envoy?: Lundi 13 Avril 2015 12:40:34 > Objet: Re: [CMake] Don't download external projects again after calling "make clean" > > Use the URL_MD5 and DOWNLOAD_DIR arguments to ExternalProject_Add to > put the downloaded files into a location outside the build tree > (perhaps ~/Downloads on Mac/Linux or $ENV{USERPROFILE}/Downloads on > Windows). > > With DOWNLOAD_DIR outside the build tree, and the checksums of the > downloaded files being the same as you've specified via URL_MD5, the > download portion will be avoided once there is a local copy of a file > available. > > > HTH, > David C. > > > On Mon, Apr 13, 2015 at 5:04 AM, Cedric Doucet > wrote: > > > > Hello! > > > > I use the ExternalProject_Add function to download third-party libraries of > > a code. > > > > Once a library has been downloaded, I can call "make" as many times as I > > want without downloading this library again. > > It seems that CMake detects that the library has already been downloaded. > > > > However, calling "make clean" seems to destroy this feature. > > Even if my library is not uninstalled during cleaning, calling "make" after > > "make clean" will lead CMake to try download the library again. > > > > How could I tell CMake not to download the library again? > > > > Thank you very much for your help! > > > > C?dric > > > > -- > > > > Powered by www.kitware.com > > > > Please keep messages on-topic and check the CMake FAQ at: > > http://www.cmake.org/Wiki/CMake_FAQ > > > > Kitware offers various services to support the CMake community. For more > > information on each offering, please visit: > > > > CMake Support: http://cmake.org/cmake/help/support.html > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/cmake > From petr.kmoch at gmail.com Fri Apr 17 05:21:14 2015 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Fri, 17 Apr 2015 11:21:14 +0200 Subject: [CMake] JOIN generator expression not working In-Reply-To: References: Message-ID: Hi Daniel. Your generator expression contains a space (between "," and "-I"). Is it quoted? Generator expressions are just normal strings until generate time, and space normally separates CMake arguments. In other words, like this: target_compile_options(trgt -I$, -I>) the command has *two* arguments. One of them is specified as "-I$," and the other as ", -I>". The TARGET_PROPERTY genex in the first one will be expanded, but the string that's left is no a full genex, so it's left verbatim. In this, on the other hand: target_compile_options(trgt "-I$, -I>") the command has *one* argument. Both the inner and outer genex will then be processed as expected. Petr On Fri, Apr 17, 2015 at 1:08 AM, Daniel Dilts wrote: > I have this generator expression: > > -I$, -I> > > I get this output in my custom command: > > -I$ > > This is almost exactly the same as the example in the documentation (other > than adding ${LibraryName}). Why doesn't this work? > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragonjoker59 at hotmail.com Fri Apr 17 07:09:46 2015 From: dragonjoker59 at hotmail.com (Sylvain Doremus) Date: Fri, 17 Apr 2015 13:09:46 +0200 Subject: [CMake] Strange behaviour of STREQUAL with a variable containing only "type" Message-ID: I have a strange output, related to the minimal CMakeLists.txt that I've provided with this email. My CMake version is 3.2.1, on Windows Seven SP1, the tested generators are Visual Studio 10 2010 and Visual Studio 10 2010 Win64. Here is the output I've got: TestFolder/type TestFolder TestFolder/type Configuring done Is it normal? Or is it a bug?If it is normal, can someone explain me why it is? -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: CMakeLists.txt URL: From DLRdave at aol.com Fri Apr 17 07:21:08 2015 From: DLRdave at aol.com (David Cole) Date: Fri, 17 Apr 2015 07:21:08 -0400 Subject: [CMake] Don't download external projects again after calling "make clean" In-Reply-To: <1121188496.1727145.1429248723887.JavaMail.zimbra@inria.fr> References: <1351653491.156868.1428915508943.JavaMail.zimbra@inria.fr> <1334535078.171898.1428915841518.JavaMail.zimbra@inria.fr> <1121188496.1727145.1429248723887.JavaMail.zimbra@inria.fr> Message-ID: Eliminate your DOWNLOAD_COMMAND. CMake knows how to do it with just the URL_MD5, DOWNLOAD_DIR and SOURCE_DIR information.... HTH, David On Fri, Apr 17, 2015 at 1:32 AM, Cedric Doucet wrote: > > Hello David, > > thank you very much for your help. > > Unfortunately I may do something wrong because it does not work. > After cleaning, the library is downloaded again. > > I guess my mistake comes from the fact I do not understand the role of URL_MD5. > Below is a simple example where downloading and installing is very fast. > You just have to replace the value of EXTERNAL_DIR by the path to your own "Downloads" repository. > I tried to put URL in my DOWNLOAD_COMMAND but the call "wget " does not seem to be understood by the wget command. > > Thanks again! > > C?dric > > -------------------------------------------------------------------------- > cmake_minimum_required (VERSION 2.6) > > project (example CXX) > > set(CMAKE_VERBOSE_MAKEFILE ON) > > include(ProcessorCount) > ProcessorCount(N) > if(NOT N EQUAL 0) > set(CMAKE_BUILD_FLAGS -j${N}) > endif() > > include(ExternalProject) > set(EXTERNAL_DIR /home/cdoucet/Downloads) > ExternalProject_Add(eigen > PREFIX ${EXTERNAL_DIR}/eigen > DOWNLOAD_DIR ${EXTERNAL_DIR}/eigen/download > SOURCE_DIR ${EXTERNAL_DIR}/eigen/src > BINARY_DIR ${EXTERNAL_DIR}/eigen/build > INSTALL_DIR ${EXTERNAL_DIR}/eigen/install > URL http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz > URL_MD5 ccb18a771f678b38a3d33c321a8e7daf > DOWNLOAD_COMMAND wget http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz && tar xvzf 3.2.4.tar.gz -C --strip-components=1 > CONFIGURE_COMMAND cd && cmake -D CMAKE_INSTALL_PREFIX=$ > ) > ------------------------------------------------------------------------------ > > > > ----- Mail original ----- >> De: "David Cole" >> ?: "Cedric Doucet" >> Cc: cmake at cmake.org >> Envoy?: Lundi 13 Avril 2015 12:40:34 >> Objet: Re: [CMake] Don't download external projects again after calling "make clean" >> >> Use the URL_MD5 and DOWNLOAD_DIR arguments to ExternalProject_Add to >> put the downloaded files into a location outside the build tree >> (perhaps ~/Downloads on Mac/Linux or $ENV{USERPROFILE}/Downloads on >> Windows). >> >> With DOWNLOAD_DIR outside the build tree, and the checksums of the >> downloaded files being the same as you've specified via URL_MD5, the >> download portion will be avoided once there is a local copy of a file >> available. >> >> >> HTH, >> David C. >> >> >> On Mon, Apr 13, 2015 at 5:04 AM, Cedric Doucet >> wrote: >> > >> > Hello! >> > >> > I use the ExternalProject_Add function to download third-party libraries of >> > a code. >> > >> > Once a library has been downloaded, I can call "make" as many times as I >> > want without downloading this library again. >> > It seems that CMake detects that the library has already been downloaded. >> > >> > However, calling "make clean" seems to destroy this feature. >> > Even if my library is not uninstalled during cleaning, calling "make" after >> > "make clean" will lead CMake to try download the library again. >> > >> > How could I tell CMake not to download the library again? >> > >> > Thank you very much for your help! >> > >> > C?dric >> > >> > -- >> > >> > Powered by www.kitware.com >> > >> > Please keep messages on-topic and check the CMake FAQ at: >> > http://www.cmake.org/Wiki/CMake_FAQ >> > >> > Kitware offers various services to support the CMake community. For more >> > information on each offering, please visit: >> > >> > CMake Support: http://cmake.org/cmake/help/support.html >> > CMake Consulting: http://cmake.org/cmake/help/consulting.html >> > CMake Training Courses: http://cmake.org/cmake/help/training.html >> > >> > Visit other Kitware open-source projects at >> > http://www.kitware.com/opensource/opensource.html >> > >> > Follow this link to subscribe/unsubscribe: >> > http://public.kitware.com/mailman/listinfo/cmake >> From nilsgladitz at gmail.com Fri Apr 17 07:43:14 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 17 Apr 2015 13:43:14 +0200 Subject: [CMake] Strange behaviour of STREQUAL with a variable containing only "type" In-Reply-To: References: Message-ID: <5530F1D2.20704@gmail.com> On 17.04.2015 13:09, Sylvain Doremus wrote: > I have a strange output, related to the minimal CMakeLists.txt that I've provided with this email. > My CMake version is 3.2.1, on Windows Seven SP1, the tested generators are Visual Studio 10 2010 and Visual Studio 10 2010 Win64. > > Here is the output I've got: > > TestFolder/type > > TestFolder > TestFolder/type > Configuring done > > Is it normal? Or is it a bug?If it is normal, can someone explain me why it is? It is expected if "type" itself is a variable (set by some module evaluated by project()). e.g. given: set(TEST_FOLDER type) The following if(): if(${TEST_FOLDER} STREQUAL "") After expansion: if(test STREQUAL "") If test is a variable set to "" this becomes equivalent to: if("" STREQUAL "") If test is not defined as a variable this is instead equivalent to: if("test" STREQUAL "") Quoting prevents cmake from dereferencing variables like this if CMP0054 [1] is set to NEW. CMP0054 is set to NEW for you since you require a cmake version >= 3.1. Nils [1] http://www.cmake.org/cmake/help/v3.2/policy/CMP0054.html From jonhodgson.devlists at googlemail.com Fri Apr 17 08:44:14 2015 From: jonhodgson.devlists at googlemail.com (Jon Hodgson) Date: Fri, 17 Apr 2015 13:44:14 +0100 Subject: [CMake] No CMAKE_CXX_COMPILER could be found Message-ID: HI, Running OSX Snow Leopard, XCode 5.1.1 Command line tools installed. If I type clang --version at the command line I get version 5.1 CMake 3.2.2 The first lines of outpuit I get are The CXX compiler identification is AppleClang 5.1.0.5030040 The C compiler identification is AppleClang 5.1.0.5030040 But then it bombs out at the line PROJECT(${PROJECT_NAME} CXX C) with the error No CMAKE_CXX_COMPILER could be found CMake 2.8.11 doesn't bomb out at that point (but does later due to the fact hat this CMakelist.txt file uses functionality that has changed). Anybody got any idea what is going on? cheers Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From parag at ionicsecurity.com Fri Apr 17 09:56:32 2015 From: parag at ionicsecurity.com (Parag Chandra) Date: Fri, 17 Apr 2015 13:56:32 +0000 Subject: [CMake] No CMAKE_CXX_COMPILER could be found In-Reply-To: References: Message-ID: Hi Jon, I can't really explain why, but I've seen the same problem on a colleague's Mac as well. On my machine, it works just fine, but to get it working across all of our Macs, I find I need to explicitly define the compilers by passing these arguments to CMake on the command line: -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ Hope this works for you too. 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: Jon Hodgson > Date: Friday, April 17, 2015 at 8:44 AM To: "cmake at cmake.org" > Subject: [CMake] No CMAKE_CXX_COMPILER could be found HI, Running OSX Snow Leopard, XCode 5.1.1 Command line tools installed. If I type clang --version at the command line I get version 5.1 CMake 3.2.2 The first lines of outpuit I get are The CXX compiler identification is AppleClang 5.1.0.5030040 The C compiler identification is AppleClang 5.1.0.5030040 But then it bombs out at the line PROJECT(${PROJECT_NAME} CXX C) with the error No CMAKE_CXX_COMPILER could be found CMake 2.8.11 doesn't bomb out at that point (but does later due to the fact hat this CMakelist.txt file uses functionality that has changed). Anybody got any idea what is going on? cheers Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Fri Apr 17 10:40:07 2015 From: brad.king at kitware.com (Brad King) Date: Fri, 17 Apr 2015 10:40:07 -0400 Subject: [CMake] No CMAKE_CXX_COMPILER could be found In-Reply-To: References: Message-ID: <55311B47.7060400@kitware.com> On 4/17/2015 8:44 AM, Jon Hodgson wrote: > The CXX compiler identification is AppleClang 5.1.0.5030040 > The C compiler identification is AppleClang 5.1.0.5030040 Good. > But then it bombs out at the line > > PROJECT(${PROJECT_NAME} CXX C) > > with the error > > No CMAKE_CXX_COMPILER could be found There may be more information in the CMakeFiles/*.log files. What generator are you using? -Brad From wesley.hoke at gmail.com Fri Apr 17 16:12:59 2015 From: wesley.hoke at gmail.com (Wesley Smith) Date: Fri, 17 Apr 2015 13:12:59 -0700 Subject: [CMake] Cuda7 issues Message-ID: Hi, I'm trying to use Cmake 3.2.2 to build with Cuda7 on Windows 8. I have both Cuda 6.5 and Cuda 7.0 installed in these locations: C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v6.5 C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v7.0 When I try these: find_package(CUDA "7.0" REQUIRED) find_package(CUDA 7.0 REQUIRED) find_package(CUDA 7 REQUIRED) (just shooting in the dark here to see if something will work) I always get the error CMake Error at C:/Program Files (x86)/CMake/share/cmake-3.2/Modules/FindPackageHandleStandardArgs.cmake:138 (message): Could NOT find CUDA: Found unsuitable version "6.5", but required is at least "7.0" (found C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v6.5) Call Stack (most recent call first): C:/Program Files (x86)/CMake/share/cmake-3.2/Modules/FindPackageHandleStandardArgs.cmake:372 (_FPHSA_FAILURE_MESSAGE) C:/Program Files (x86)/CMake/share/cmake-3.2/Modules/FindCUDA.cmake:939 (find_package_handle_standard_args) CMakeLists.txt:122 (find_package) Any ideas? thanks, wes From neil.n.carlson at gmail.com Fri Apr 17 17:00:38 2015 From: neil.n.carlson at gmail.com (Neil Carlson) Date: Fri, 17 Apr 2015 15:00:38 -0600 Subject: [CMake] Alternative to configure_file Message-ID: I'm working within a very large project on a python script. The script gets passed through configure_file to replace some @VAR@ strings with some file paths that are defined when cmake is run; this generates the final script. The side effect is that whenever I modify the file and run make, it re-runs cmake to regenerate the build system, and that cascades into all sorts of other things that are completely orthogonal to the script being rebuilt. Is there some more appropriate alternative to configure_file that should be used instead? Thanks for your expert advice! -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.pavlik at gmail.com Fri Apr 17 18:02:47 2015 From: ryan.pavlik at gmail.com (Ryan Pavlik) Date: Fri, 17 Apr 2015 22:02:47 +0000 Subject: [CMake] Alternative to configure_file In-Reply-To: References: Message-ID: Well, if the file needs to have the substitutions performed, like after an edit, CMake will have to run. What you could do is write a standalone cmake script that just does the configure file step, then add it as a custom command on a custom target, just running that configure script in script mode and passing the needed variables on the command line. Then, a change in your python file won't trigger a full cmake configure: it will just run the small cmake script that essentially exists to apply the variable substitutions. Ryan On Fri, Apr 17, 2015, 4:00 PM Neil Carlson wrote: > I'm working within a very large project on a python script. The script > gets passed through configure_file to replace some @VAR@ strings with > some file paths that are defined when cmake is run; this generates the > final script. The side effect is that whenever I modify the file and run > make, it re-runs cmake to regenerate the build system, and that cascades > into all sorts of other things that are completely orthogonal to the script > being rebuilt. Is there some more appropriate alternative to > configure_file that should be used instead? Thanks for your expert advice! > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 jamesbigler at gmail.com Fri Apr 17 18:36:22 2015 From: jamesbigler at gmail.com (James Bigler) Date: Fri, 17 Apr 2015 16:36:22 -0600 Subject: [CMake] Cuda7 issues In-Reply-To: References: Message-ID: FindCUDA doesn't look for a specific version, but rather checks to see if the version it found is the one you asked for. You can set the CUDA_TOOLKIT_ROOT_DIR to the one you want (and reconfigure - I've set it up to easily change this), or you can change your environment in Windows to point to the default version of CUDA you want (CUDA_PATH). It would be nice if it could search about and find an appropriate version. James On Fri, Apr 17, 2015 at 2:12 PM, Wesley Smith wrote: > Hi, > I'm trying to use Cmake 3.2.2 to build with Cuda7 on Windows 8. I have > both Cuda 6.5 and Cuda 7.0 installed in these locations: > > C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v6.5 > C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v7.0 > > When I try these: > > find_package(CUDA "7.0" REQUIRED) > find_package(CUDA 7.0 REQUIRED) > find_package(CUDA 7 REQUIRED) > > > (just shooting in the dark here to see if something will work) > > I always get the error > > CMake Error at C:/Program Files > (x86)/CMake/share/cmake-3.2/Modules/FindPackageHandleStandardArgs.cmake:138 > (message): > Could NOT find CUDA: Found unsuitable version "6.5", but required is at > least "7.0" (found C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v6.5) > Call Stack (most recent call first): > C:/Program Files > (x86)/CMake/share/cmake-3.2/Modules/FindPackageHandleStandardArgs.cmake:372 > (_FPHSA_FAILURE_MESSAGE) > C:/Program Files > (x86)/CMake/share/cmake-3.2/Modules/FindCUDA.cmake:939 > (find_package_handle_standard_args) > CMakeLists.txt:122 (find_package) > > > Any ideas? > > thanks, > wes > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 wesley.hoke at gmail.com Fri Apr 17 19:15:58 2015 From: wesley.hoke at gmail.com (Wesley Smith) Date: Fri, 17 Apr 2015 16:15:58 -0700 Subject: [CMake] Cuda7 issues In-Reply-To: References: Message-ID: Ah, thanks! On Fri, Apr 17, 2015 at 3:36 PM, James Bigler wrote: > FindCUDA doesn't look for a specific version, but rather checks to see if > the version it found is the one you asked for. You can set the > CUDA_TOOLKIT_ROOT_DIR to the one you want (and reconfigure - I've set it up > to easily change this), or you can change your environment in Windows to > point to the default version of CUDA you want (CUDA_PATH). > > It would be nice if it could search about and find an appropriate version. > > James > > On Fri, Apr 17, 2015 at 2:12 PM, Wesley Smith wrote: >> >> Hi, >> I'm trying to use Cmake 3.2.2 to build with Cuda7 on Windows 8. I have >> both Cuda 6.5 and Cuda 7.0 installed in these locations: >> >> C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v6.5 >> C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v7.0 >> >> When I try these: >> >> find_package(CUDA "7.0" REQUIRED) >> find_package(CUDA 7.0 REQUIRED) >> find_package(CUDA 7 REQUIRED) >> >> >> (just shooting in the dark here to see if something will work) >> >> I always get the error >> >> CMake Error at C:/Program Files >> >> (x86)/CMake/share/cmake-3.2/Modules/FindPackageHandleStandardArgs.cmake:138 >> (message): >> Could NOT find CUDA: Found unsuitable version "6.5", but required is at >> least "7.0" (found C:/Program Files/NVIDIA GPU Computing >> Toolkit/CUDA/v6.5) >> Call Stack (most recent call first): >> C:/Program Files >> >> (x86)/CMake/share/cmake-3.2/Modules/FindPackageHandleStandardArgs.cmake:372 >> (_FPHSA_FAILURE_MESSAGE) >> C:/Program Files >> (x86)/CMake/share/cmake-3.2/Modules/FindCUDA.cmake:939 >> (find_package_handle_standard_args) >> CMakeLists.txt:122 (find_package) >> >> >> Any ideas? >> >> thanks, >> wes >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware 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 wesley.hoke at gmail.com Fri Apr 17 19:20:17 2015 From: wesley.hoke at gmail.com (Wesley Smith) Date: Fri, 17 Apr 2015 16:20:17 -0700 Subject: [CMake] Cuda CUDA_SEPARABLE_COMPILATION errors during linking Message-ID: With CUDA_SEPARABLE_COMPILATION enabled, I'm always getting linking errors when I try to build. Seems it's looking for a directory that doesn't exist: '/build/CMakeFiles/SlicerLib.dir/Debug If I manually create this directory, everything works. Seems that either the directory path isn't being computed properly or that code to create the directory if needed is missing. wes 2>C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v7.0\bin\crt\link.stub : fatal error C1083: Cannot open compiler generated file: '/build/CMakeFiles/SlicerLib.dir/Debug/SlicerLib_intermediate_link.obj': No such file or directory 2>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(127,5): error MSB3073: The command "setlocal 2>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(127,5): error MSB3073: "C:\Program Files (x86)\CMake\bin\cmake.exe" -E echo "Building NVCC intermediate link file CMakeFiles/SlicerLib.dir/Debug/SlicerLib_intermediate_link.obj" 2>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(127,5): error MSB3073: if %errorlevel% neq 0 goto :cmEnd 2>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(127,5): error MSB3073: "C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v7.0\bin\nvcc.exe" -arch=sm_30 -m64 -ccbin "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin" -Xcompiler /MDd -dlink /build/CMakeFiles/SlicerLib.dir/src/bitmap/fragCounter/Debug/SlicerLib_generated_amFragCounterCuda.cu.obj /build/CMakeFiles/SlicerLib.dir/src/bitmap/materialCounter/Debug/SlicerLib_generated_amBitmapMaterialCounterABufferCuda.cu.obj /build/CMakeFiles/SlicerLib.dir/src/bitmap/materialCounter/Debug/SlicerLib_generated_amBitmapMaterialCounterCuda.cu.obj /build/CMakeFiles/SlicerLib.dir/src/cuda/Debug/SlicerLib_generated_amCuda.cu.obj /build/CMakeFiles/SlicerLib.dir/src/cuda/Debug/SlicerLib_generated_amCudaTexture.cu.obj /build/CMakeFiles/SlicerLib.dir/src/vector/Debug/SlicerLib_generated_amVectorBoundaryProcess.cu.obj /build/CMakeFiles/SlicerLib.dir/src/vector/Debug/SlicerLib_generated_amVectorContourDifference.cu.obj /build/CMakeFiles/SlicerLib.dir/src/vector/Debug/SlicerLib_generated_amVectorContourOffset2.cu.obj /build/CMakeFiles/SlicerLib.dir/src/vector/Debug/SlicerLib_generated_amVectorContourProcess.cu.obj /build/CMakeFiles/SlicerLib.dir/src/vector/Debug/SlicerLib_generated_amVectorCudaHood.cu.obj /build/CMakeFiles/SlicerLib.dir/src/vector/Debug/SlicerLib_generated_amVectorCudaIntersections.cu.obj /build/CMakeFiles/SlicerLib.dir/src/vector/Debug/SlicerLib_generated_amVectorCudaLineSegments.cu.obj /build/CMakeFiles/SlicerLib.dir/src/vector/Debug/SlicerLib_generated_amVectorCudaLineSegments2.cu.obj /build/CMakeFiles/SlicerLib.dir/src/vector/Debug/SlicerLib_generated_amVectorCudaParametricIntersections.cu.obj /build/CMakeFiles/SlicerLib.dir/src/vector/Debug/SlicerLib_generated_amVectorInfill45Processor.cu.obj /build/CMakeFiles/SlicerLib.dir/src/vector/Debug/SlicerLib_generated_amVectorOutlineContour.cu.obj /build/CMakeFiles/SlicerLib.dir/src/vector/Debug/SlicerLib_generated_amVectorSlicerProcess.cu.obj -o /build/CMakeFiles/SlicerLib.dir/Debug/SlicerLib_intermediate_link.obj 2>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(127,5): error MSB3073: if %errorlevel% neq 0 goto :cmEnd 2>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(127,5): error MSB3073: :cmEnd 2>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(127,5): error MSB3073: endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone 2>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(127,5): error MSB3073: :cmErrorLevel 2>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(127,5): error MSB3073: exit /b %1 2>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(127,5): error MSB3073: :cmDone 2>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(127,5): error MSB3073: if %errorlevel% neq 0 goto :VCEnd 2>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(127,5): error MSB3073: :VCEnd" exited with code 1. 3>------ Build started: Project: CmbVisualizer, Configuration: Debug x64 ------ From steveire at gmail.com Sat Apr 18 05:30:48 2015 From: steveire at gmail.com (Stephen Kelly) Date: Sat, 18 Apr 2015 11:30:48 +0200 Subject: [CMake] Strange behaviour of STREQUAL with a variable containing only "type" References: <5530F1D2.20704@gmail.com> Message-ID: Nils Gladitz wrote: > It is expected if "type" itself is a variable (set by some module > evaluated by project()). Indeed we should probably clean up after ourselves (in the project() implementation) when using such generic names... Thanks, Steve. From steveire at gmail.com Sat Apr 18 05:32:42 2015 From: steveire at gmail.com (Stephen Kelly) Date: Sat, 18 Apr 2015 11:32:42 +0200 Subject: [CMake] ExternalProject can't have interface library as a dependency References: Message-ID: Andrey Pokrovskiy wrote: > /* I'm using cmake-3.2.20150331-gb190c. */ > > I have a following construction: > > ExternalProject_Add( > websockets_ep > DEPENDS ev openssl > ...) > > But it so happened, that "openssl" is a INTERFACE library. That sounds odd. What provides it as an INTERFACE library? From steveire at gmail.com Sat Apr 18 05:35:40 2015 From: steveire at gmail.com (Stephen Kelly) Date: Sat, 18 Apr 2015 11:35:40 +0200 Subject: [CMake] cmp0026, file(GENERATE...), and configure_file References: Message-ID: Alan W. Irwin wrote: > So is it recommended that a two-step procedure be used to configure > a file? For example: Yes, that seems to be a valid thing to do. > If the above complications for configured files are the only way to > deal with a mixture of @...@ items and generator expressions to > configure, could a change to configure_file so that it honors > generator expressions be implemented to avoid these complications? Nope, generator expressions are only available at generate-time, but configure_file is evaluated before that. Thanks, Steve. From cedric.doucet at inria.fr Sat Apr 18 07:00:28 2015 From: cedric.doucet at inria.fr (Cedric Doucet) Date: Sat, 18 Apr 2015 13:00:28 +0200 (CEST) Subject: [CMake] Don't download external projects again after calling "make clean" In-Reply-To: References: <1351653491.156868.1428915508943.JavaMail.zimbra@inria.fr> <1334535078.171898.1428915841518.JavaMail.zimbra@inria.fr> <1121188496.1727145.1429248723887.JavaMail.zimbra@inria.fr> Message-ID: <1544359461.2146552.1429354828753.JavaMail.zimbra@inria.fr> Hello David, thank you very much. Unfortunately, I get the following error message if I remove my download command: -- downloading... src='http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz' dst='/home/cdoucet/Downloads/eigen/download/3.2.4.tar.gz' timeout='none' -- [download 100% complete] CMake Error at src/eigen-stamp/download-eigen.cmake:27 (message): error: downloading 'http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz' failed status_code: 1 status_string: "Unsupported protocol" log: Hostname was NOT found in DNS cache Trying 131.103.20.167... Connected to bitbucket.org (131.103.20.167) port 80 (#0) GET /eigen/eigen/get/3.2.4.tar.gz HTTP/1.1 User-Agent: curl/7.38.0 Host: bitbucket.org Accept: */* HTTP/1.1 301 Moved Permanently Server nginx/1.6.2 is not blacklisted Server: nginx/1.6.2 Date: Sat, 18 Apr 2015 10:55:20 GMT Content-Type: text/html Content-Length: 184 Location: https://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz Ignoring the response-body 301 Moved Permanently

301 Moved Permanently

nginx/1.6.2
Connection #0 to host bitbucket.org left intact Issue another request to this URL: 'https://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz' Protocol "https" not supported or disabled in libcurl Closing connection -1 ----- Mail original ----- > De: "David Cole" > ?: "Cedric Doucet" > Cc: cmake at cmake.org > Envoy?: Vendredi 17 Avril 2015 13:21:08 > Objet: Re: [CMake] Don't download external projects again after calling "make clean" > > Eliminate your DOWNLOAD_COMMAND. CMake knows how to do it with just > the URL_MD5, DOWNLOAD_DIR and SOURCE_DIR information.... > > HTH, > David > > > On Fri, Apr 17, 2015 at 1:32 AM, Cedric Doucet > wrote: > > > > Hello David, > > > > thank you very much for your help. > > > > Unfortunately I may do something wrong because it does not work. > > After cleaning, the library is downloaded again. > > > > I guess my mistake comes from the fact I do not understand the role of > > URL_MD5. > > Below is a simple example where downloading and installing is very fast. > > You just have to replace the value of EXTERNAL_DIR by the path to your own > > "Downloads" repository. > > I tried to put URL in my DOWNLOAD_COMMAND but the call "wget " does > > not seem to be understood by the wget command. > > > > Thanks again! > > > > C?dric > > > > -------------------------------------------------------------------------- > > cmake_minimum_required (VERSION 2.6) > > > > project (example CXX) > > > > set(CMAKE_VERBOSE_MAKEFILE ON) > > > > include(ProcessorCount) > > ProcessorCount(N) > > if(NOT N EQUAL 0) > > set(CMAKE_BUILD_FLAGS -j${N}) > > endif() > > > > include(ExternalProject) > > set(EXTERNAL_DIR /home/cdoucet/Downloads) > > ExternalProject_Add(eigen > > PREFIX ${EXTERNAL_DIR}/eigen > > DOWNLOAD_DIR ${EXTERNAL_DIR}/eigen/download > > SOURCE_DIR ${EXTERNAL_DIR}/eigen/src > > BINARY_DIR ${EXTERNAL_DIR}/eigen/build > > INSTALL_DIR ${EXTERNAL_DIR}/eigen/install > > URL http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz > > URL_MD5 ccb18a771f678b38a3d33c321a8e7daf > > DOWNLOAD_COMMAND wget > > http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz && > > tar xvzf 3.2.4.tar.gz -C > > --strip-components=1 > > CONFIGURE_COMMAND cd && cmake -D > > CMAKE_INSTALL_PREFIX=$ > > ) > > ------------------------------------------------------------------------------ > > > > > > > > ----- Mail original ----- > >> De: "David Cole" > >> ?: "Cedric Doucet" > >> Cc: cmake at cmake.org > >> Envoy?: Lundi 13 Avril 2015 12:40:34 > >> Objet: Re: [CMake] Don't download external projects again after calling > >> "make clean" > >> > >> Use the URL_MD5 and DOWNLOAD_DIR arguments to ExternalProject_Add to > >> put the downloaded files into a location outside the build tree > >> (perhaps ~/Downloads on Mac/Linux or $ENV{USERPROFILE}/Downloads on > >> Windows). > >> > >> With DOWNLOAD_DIR outside the build tree, and the checksums of the > >> downloaded files being the same as you've specified via URL_MD5, the > >> download portion will be avoided once there is a local copy of a file > >> available. > >> > >> > >> HTH, > >> David C. > >> > >> > >> On Mon, Apr 13, 2015 at 5:04 AM, Cedric Doucet > >> wrote: > >> > > >> > Hello! > >> > > >> > I use the ExternalProject_Add function to download third-party libraries > >> > of > >> > a code. > >> > > >> > Once a library has been downloaded, I can call "make" as many times as I > >> > want without downloading this library again. > >> > It seems that CMake detects that the library has already been > >> > downloaded. > >> > > >> > However, calling "make clean" seems to destroy this feature. > >> > Even if my library is not uninstalled during cleaning, calling "make" > >> > after > >> > "make clean" will lead CMake to try download the library again. > >> > > >> > How could I tell CMake not to download the library again? > >> > > >> > Thank you very much for your help! > >> > > >> > C?dric > >> > > >> > -- > >> > > >> > Powered by www.kitware.com > >> > > >> > Please keep messages on-topic and check the CMake FAQ at: > >> > http://www.cmake.org/Wiki/CMake_FAQ > >> > > >> > Kitware offers various services to support the CMake community. For more > >> > information on each offering, please visit: > >> > > >> > CMake Support: http://cmake.org/cmake/help/support.html > >> > CMake Consulting: http://cmake.org/cmake/help/consulting.html > >> > CMake Training Courses: http://cmake.org/cmake/help/training.html > >> > > >> > Visit other Kitware open-source projects at > >> > http://www.kitware.com/opensource/opensource.html > >> > > >> > Follow this link to subscribe/unsubscribe: > >> > http://public.kitware.com/mailman/listinfo/cmake > >> > From cedric.doucet at inria.fr Sat Apr 18 07:38:31 2015 From: cedric.doucet at inria.fr (Cedric Doucet) Date: Sat, 18 Apr 2015 13:38:31 +0200 (CEST) Subject: [CMake] Don't download external projects again after calling "make clean" In-Reply-To: <1544359461.2146552.1429354828753.JavaMail.zimbra@inria.fr> References: <1351653491.156868.1428915508943.JavaMail.zimbra@inria.fr> <1334535078.171898.1428915841518.JavaMail.zimbra@inria.fr> <1121188496.1727145.1429248723887.JavaMail.zimbra@inria.fr> <1544359461.2146552.1429354828753.JavaMail.zimbra@inria.fr> Message-ID: <871275596.2148003.1429357111569.JavaMail.zimbra@inria.fr> I have just tried to install curl to get https support. To do that, I have followed the steps below: 1. Installation of openssl: 1.a. ./config --prefix=/my/openssl/path 1.b. make 1.c. make test 1.d. make install 2. Installation of curl 2.a. ./configure --prefix=/my/curl/path --with-ssl=/my/openssl/path/lib 2.b. make 2.c. make install I have also prepend PATH with /my/curl/path/bin. However, the error remains. It seems that my version of curl (7.41.0) is not taken into acount because I have still this line in the error message: User-Agent: curl/7.38.0 I tried to remove all previous of curl and libcurl but it does not change anything. Could you help me? C?dric ----- Mail original ----- > De: "Cedric Doucet" > ?: "David Cole" > Cc: cmake at cmake.org > Envoy?: Samedi 18 Avril 2015 13:00:28 > Objet: Re: [CMake] Don't download external projects again after calling "make clean" > > > Hello David, > > thank you very much. > Unfortunately, I get the following error message if I remove my download > command: > > -- downloading... > src='http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz' > dst='/home/cdoucet/Downloads/eigen/download/3.2.4.tar.gz' > timeout='none' > -- [download 100% complete] > CMake Error at src/eigen-stamp/download-eigen.cmake:27 (message): > error: downloading 'http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz' > failed > > status_code: 1 > status_string: "Unsupported protocol" > log: Hostname was NOT found in DNS cache > Trying 131.103.20.167... > > Connected to bitbucket.org (131.103.20.167) port 80 (#0) > > GET /eigen/eigen/get/3.2.4.tar.gz HTTP/1.1 > > User-Agent: curl/7.38.0 > > Host: bitbucket.org > > Accept: */* > > > > HTTP/1.1 301 Moved Permanently > > Server nginx/1.6.2 is not blacklisted > > Server: nginx/1.6.2 > > Date: Sat, 18 Apr 2015 10:55:20 GMT > > Content-Type: text/html > > Content-Length: 184 > > Location: https://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz > > > > Ignoring the response-body > > > > 301 Moved Permanently > > > >

301 Moved Permanently

> >
nginx/1.6.2
> > > > > > Connection #0 to host bitbucket.org left intact > > Issue another request to this URL: > 'https://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz' > > Protocol "https" not supported or disabled in libcurl > > Closing connection -1 > > > > > ----- Mail original ----- > > De: "David Cole" > > ?: "Cedric Doucet" > > Cc: cmake at cmake.org > > Envoy?: Vendredi 17 Avril 2015 13:21:08 > > Objet: Re: [CMake] Don't download external projects again after calling > > "make clean" > > > > Eliminate your DOWNLOAD_COMMAND. CMake knows how to do it with just > > the URL_MD5, DOWNLOAD_DIR and SOURCE_DIR information.... > > > > HTH, > > David > > > > > > On Fri, Apr 17, 2015 at 1:32 AM, Cedric Doucet > > wrote: > > > > > > Hello David, > > > > > > thank you very much for your help. > > > > > > Unfortunately I may do something wrong because it does not work. > > > After cleaning, the library is downloaded again. > > > > > > I guess my mistake comes from the fact I do not understand the role of > > > URL_MD5. > > > Below is a simple example where downloading and installing is very fast. > > > You just have to replace the value of EXTERNAL_DIR by the path to your > > > own > > > "Downloads" repository. > > > I tried to put URL in my DOWNLOAD_COMMAND but the call "wget " does > > > not seem to be understood by the wget command. > > > > > > Thanks again! > > > > > > C?dric > > > > > > -------------------------------------------------------------------------- > > > cmake_minimum_required (VERSION 2.6) > > > > > > project (example CXX) > > > > > > set(CMAKE_VERBOSE_MAKEFILE ON) > > > > > > include(ProcessorCount) > > > ProcessorCount(N) > > > if(NOT N EQUAL 0) > > > set(CMAKE_BUILD_FLAGS -j${N}) > > > endif() > > > > > > include(ExternalProject) > > > set(EXTERNAL_DIR /home/cdoucet/Downloads) > > > ExternalProject_Add(eigen > > > PREFIX ${EXTERNAL_DIR}/eigen > > > DOWNLOAD_DIR ${EXTERNAL_DIR}/eigen/download > > > SOURCE_DIR ${EXTERNAL_DIR}/eigen/src > > > BINARY_DIR ${EXTERNAL_DIR}/eigen/build > > > INSTALL_DIR ${EXTERNAL_DIR}/eigen/install > > > URL http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz > > > URL_MD5 ccb18a771f678b38a3d33c321a8e7daf > > > DOWNLOAD_COMMAND wget > > > http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz && > > > tar xvzf 3.2.4.tar.gz -C > > > --strip-components=1 > > > CONFIGURE_COMMAND cd && cmake -D > > > CMAKE_INSTALL_PREFIX=$ > > > ) > > > ------------------------------------------------------------------------------ > > > > > > > > > > > > ----- Mail original ----- > > >> De: "David Cole" > > >> ?: "Cedric Doucet" > > >> Cc: cmake at cmake.org > > >> Envoy?: Lundi 13 Avril 2015 12:40:34 > > >> Objet: Re: [CMake] Don't download external projects again after calling > > >> "make clean" > > >> > > >> Use the URL_MD5 and DOWNLOAD_DIR arguments to ExternalProject_Add to > > >> put the downloaded files into a location outside the build tree > > >> (perhaps ~/Downloads on Mac/Linux or $ENV{USERPROFILE}/Downloads on > > >> Windows). > > >> > > >> With DOWNLOAD_DIR outside the build tree, and the checksums of the > > >> downloaded files being the same as you've specified via URL_MD5, the > > >> download portion will be avoided once there is a local copy of a file > > >> available. > > >> > > >> > > >> HTH, > > >> David C. > > >> > > >> > > >> On Mon, Apr 13, 2015 at 5:04 AM, Cedric Doucet > > >> wrote: > > >> > > > >> > Hello! > > >> > > > >> > I use the ExternalProject_Add function to download third-party > > >> > libraries > > >> > of > > >> > a code. > > >> > > > >> > Once a library has been downloaded, I can call "make" as many times as > > >> > I > > >> > want without downloading this library again. > > >> > It seems that CMake detects that the library has already been > > >> > downloaded. > > >> > > > >> > However, calling "make clean" seems to destroy this feature. > > >> > Even if my library is not uninstalled during cleaning, calling "make" > > >> > after > > >> > "make clean" will lead CMake to try download the library again. > > >> > > > >> > How could I tell CMake not to download the library again? > > >> > > > >> > Thank you very much for your help! > > >> > > > >> > C?dric > > >> > > > >> > -- > > >> > > > >> > Powered by www.kitware.com > > >> > > > >> > Please keep messages on-topic and check the CMake FAQ at: > > >> > http://www.cmake.org/Wiki/CMake_FAQ > > >> > > > >> > Kitware offers various services to support the CMake community. For > > >> > more > > >> > information on each offering, please visit: > > >> > > > >> > CMake Support: http://cmake.org/cmake/help/support.html > > >> > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > >> > CMake Training Courses: http://cmake.org/cmake/help/training.html > > >> > > > >> > Visit other Kitware open-source projects at > > >> > http://www.kitware.com/opensource/opensource.html > > >> > > > >> > Follow this link to subscribe/unsubscribe: > > >> > http://public.kitware.com/mailman/listinfo/cmake > > >> > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > From cedric.doucet at inria.fr Sat Apr 18 08:15:32 2015 From: cedric.doucet at inria.fr (Cedric Doucet) Date: Sat, 18 Apr 2015 14:15:32 +0200 (CEST) Subject: [CMake] Don't download external projects again after calling "make clean" In-Reply-To: <871275596.2148003.1429357111569.JavaMail.zimbra@inria.fr> References: <1351653491.156868.1428915508943.JavaMail.zimbra@inria.fr> <1334535078.171898.1428915841518.JavaMail.zimbra@inria.fr> <1121188496.1727145.1429248723887.JavaMail.zimbra@inria.fr> <1544359461.2146552.1429354828753.JavaMail.zimbra@inria.fr> <871275596.2148003.1429357111569.JavaMail.zimbra@inria.fr> Message-ID: <1588572917.2149426.1429359332478.JavaMail.zimbra@inria.fr> Ok it seems the answer to my problem is here: http://www.cmake.org/pipermail/cmake/2010-December/041295.html I will try it. ----- Mail original ----- > De: "Cedric Doucet" > ?: cmake at cmake.org > Envoy?: Samedi 18 Avril 2015 13:38:31 > Objet: Re: [CMake] Don't download external projects again after calling "make clean" > > > I have just tried to install curl to get https support. > To do that, I have followed the steps below: > > 1. Installation of openssl: > 1.a. ./config --prefix=/my/openssl/path > 1.b. make > 1.c. make test > 1.d. make install > 2. Installation of curl > 2.a. ./configure --prefix=/my/curl/path --with-ssl=/my/openssl/path/lib > 2.b. make > 2.c. make install > > I have also prepend PATH with /my/curl/path/bin. > However, the error remains. > It seems that my version of curl (7.41.0) is not taken into acount because I > have still this line in the error message: > User-Agent: curl/7.38.0 > I tried to remove all previous of curl and libcurl but it does not change > anything. > > Could you help me? > > C?dric > > > ----- Mail original ----- > > De: "Cedric Doucet" > > ?: "David Cole" > > Cc: cmake at cmake.org > > Envoy?: Samedi 18 Avril 2015 13:00:28 > > Objet: Re: [CMake] Don't download external projects again after calling > > "make clean" > > > > > > Hello David, > > > > thank you very much. > > Unfortunately, I get the following error message if I remove my download > > command: > > > > -- downloading... > > src='http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz' > > dst='/home/cdoucet/Downloads/eigen/download/3.2.4.tar.gz' > > timeout='none' > > -- [download 100% complete] > > CMake Error at src/eigen-stamp/download-eigen.cmake:27 (message): > > error: downloading 'http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz' > > failed > > > > status_code: 1 > > status_string: "Unsupported protocol" > > log: Hostname was NOT found in DNS cache > > Trying 131.103.20.167... > > > > Connected to bitbucket.org (131.103.20.167) port 80 (#0) > > > > GET /eigen/eigen/get/3.2.4.tar.gz HTTP/1.1 > > > > User-Agent: curl/7.38.0 > > > > Host: bitbucket.org > > > > Accept: */* > > > > > > > > HTTP/1.1 301 Moved Permanently > > > > Server nginx/1.6.2 is not blacklisted > > > > Server: nginx/1.6.2 > > > > Date: Sat, 18 Apr 2015 10:55:20 GMT > > > > Content-Type: text/html > > > > Content-Length: 184 > > > > Location: https://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz > > > > > > > > Ignoring the response-body > > > > > > > > 301 Moved Permanently > > > > > > > >

301 Moved Permanently

> > > >
nginx/1.6.2
> > > > > > > > > > > > Connection #0 to host bitbucket.org left intact > > > > Issue another request to this URL: > > 'https://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz' > > > > Protocol "https" not supported or disabled in libcurl > > > > Closing connection -1 > > > > > > > > > > ----- Mail original ----- > > > De: "David Cole" > > > ?: "Cedric Doucet" > > > Cc: cmake at cmake.org > > > Envoy?: Vendredi 17 Avril 2015 13:21:08 > > > Objet: Re: [CMake] Don't download external projects again after calling > > > "make clean" > > > > > > Eliminate your DOWNLOAD_COMMAND. CMake knows how to do it with just > > > the URL_MD5, DOWNLOAD_DIR and SOURCE_DIR information.... > > > > > > HTH, > > > David > > > > > > > > > On Fri, Apr 17, 2015 at 1:32 AM, Cedric Doucet > > > wrote: > > > > > > > > Hello David, > > > > > > > > thank you very much for your help. > > > > > > > > Unfortunately I may do something wrong because it does not work. > > > > After cleaning, the library is downloaded again. > > > > > > > > I guess my mistake comes from the fact I do not understand the role of > > > > URL_MD5. > > > > Below is a simple example where downloading and installing is very > > > > fast. > > > > You just have to replace the value of EXTERNAL_DIR by the path to your > > > > own > > > > "Downloads" repository. > > > > I tried to put URL in my DOWNLOAD_COMMAND but the call "wget " > > > > does > > > > not seem to be understood by the wget command. > > > > > > > > Thanks again! > > > > > > > > C?dric > > > > > > > > -------------------------------------------------------------------------- > > > > cmake_minimum_required (VERSION 2.6) > > > > > > > > project (example CXX) > > > > > > > > set(CMAKE_VERBOSE_MAKEFILE ON) > > > > > > > > include(ProcessorCount) > > > > ProcessorCount(N) > > > > if(NOT N EQUAL 0) > > > > set(CMAKE_BUILD_FLAGS -j${N}) > > > > endif() > > > > > > > > include(ExternalProject) > > > > set(EXTERNAL_DIR /home/cdoucet/Downloads) > > > > ExternalProject_Add(eigen > > > > PREFIX ${EXTERNAL_DIR}/eigen > > > > DOWNLOAD_DIR ${EXTERNAL_DIR}/eigen/download > > > > SOURCE_DIR ${EXTERNAL_DIR}/eigen/src > > > > BINARY_DIR ${EXTERNAL_DIR}/eigen/build > > > > INSTALL_DIR ${EXTERNAL_DIR}/eigen/install > > > > URL > > > > http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz > > > > URL_MD5 ccb18a771f678b38a3d33c321a8e7daf > > > > DOWNLOAD_COMMAND wget > > > > http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz > > > > && > > > > tar xvzf 3.2.4.tar.gz -C > > > > --strip-components=1 > > > > CONFIGURE_COMMAND cd && cmake -D > > > > CMAKE_INSTALL_PREFIX=$ > > > > ) > > > > ------------------------------------------------------------------------------ > > > > > > > > > > > > > > > > ----- Mail original ----- > > > >> De: "David Cole" > > > >> ?: "Cedric Doucet" > > > >> Cc: cmake at cmake.org > > > >> Envoy?: Lundi 13 Avril 2015 12:40:34 > > > >> Objet: Re: [CMake] Don't download external projects again after > > > >> calling > > > >> "make clean" > > > >> > > > >> Use the URL_MD5 and DOWNLOAD_DIR arguments to ExternalProject_Add to > > > >> put the downloaded files into a location outside the build tree > > > >> (perhaps ~/Downloads on Mac/Linux or $ENV{USERPROFILE}/Downloads on > > > >> Windows). > > > >> > > > >> With DOWNLOAD_DIR outside the build tree, and the checksums of the > > > >> downloaded files being the same as you've specified via URL_MD5, the > > > >> download portion will be avoided once there is a local copy of a file > > > >> available. > > > >> > > > >> > > > >> HTH, > > > >> David C. > > > >> > > > >> > > > >> On Mon, Apr 13, 2015 at 5:04 AM, Cedric Doucet > > > >> > > > >> wrote: > > > >> > > > > >> > Hello! > > > >> > > > > >> > I use the ExternalProject_Add function to download third-party > > > >> > libraries > > > >> > of > > > >> > a code. > > > >> > > > > >> > Once a library has been downloaded, I can call "make" as many times > > > >> > as > > > >> > I > > > >> > want without downloading this library again. > > > >> > It seems that CMake detects that the library has already been > > > >> > downloaded. > > > >> > > > > >> > However, calling "make clean" seems to destroy this feature. > > > >> > Even if my library is not uninstalled during cleaning, calling > > > >> > "make" > > > >> > after > > > >> > "make clean" will lead CMake to try download the library again. > > > >> > > > > >> > How could I tell CMake not to download the library again? > > > >> > > > > >> > Thank you very much for your help! > > > >> > > > > >> > C?dric > > > >> > > > > >> > -- > > > >> > > > > >> > Powered by www.kitware.com > > > >> > > > > >> > Please keep messages on-topic and check the CMake FAQ at: > > > >> > http://www.cmake.org/Wiki/CMake_FAQ > > > >> > > > > >> > Kitware offers various services to support the CMake community. For > > > >> > more > > > >> > information on each offering, please visit: > > > >> > > > > >> > CMake Support: http://cmake.org/cmake/help/support.html > > > >> > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > > >> > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > >> > > > > >> > Visit other Kitware open-source projects at > > > >> > http://www.kitware.com/opensource/opensource.html > > > >> > > > > >> > Follow this link to subscribe/unsubscribe: > > > >> > http://public.kitware.com/mailman/listinfo/cmake > > > >> > > > > > -- > > > > Powered by www.kitware.com > > > > Please keep messages on-topic and check the CMake FAQ at: > > http://www.cmake.org/Wiki/CMake_FAQ > > > > Kitware offers various services to support the CMake community. For more > > information on each offering, please visit: > > > > CMake Support: http://cmake.org/cmake/help/support.html > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/cmake > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > From dummdoof-doof at web.de Sat Apr 18 11:04:50 2015 From: dummdoof-doof at web.de (typ1232) Date: Sat, 18 Apr 2015 08:04:50 -0700 (MST) Subject: [CMake] Do build after GIT_TAG changed in ExternalProject_Add Message-ID: <1429369490097-7590299.post@n2.nabble.com> Hello, The command is used as follows: INCLUDE(ExternalProject) ExternalProject_Add(name GIT_REPOSITORY https://bitbucket.org/foo/bar.git GIT_TAG 0fcae6c2c975b309b38b8c84ac681b6bf3ae12e7 CMAKE_ARGS "" INSTALL_COMMAND "" ) This downloads and builds the project successfully, but if I change the GIT_TAG value, cmake only checks out the other commit. The project is not rebuilt. -- View this message in context: http://cmake.3232098.n2.nabble.com/Do-build-after-GIT-TAG-changed-in-ExternalProject-Add-tp7590299.html Sent from the CMake mailing list archive at Nabble.com. From DLRdave at aol.com Sat Apr 18 14:33:15 2015 From: DLRdave at aol.com (David Cole) Date: Sat, 18 Apr 2015 14:33:15 -0400 Subject: [CMake] Do build after GIT_TAG changed in ExternalProject_Add In-Reply-To: <1429369490097-7590299.post@n2.nabble.com> References: <1429369490097-7590299.post@n2.nabble.com> Message-ID: What version of CMake are you using? And what generator? On Saturday, April 18, 2015, typ1232 wrote: > Hello, > > The command is used as follows: > > INCLUDE(ExternalProject) > ExternalProject_Add(name > GIT_REPOSITORY https://bitbucket.org/foo/bar.git > GIT_TAG 0fcae6c2c975b309b38b8c84ac681b6bf3ae12e7 > CMAKE_ARGS "" > INSTALL_COMMAND "" > ) > This downloads and builds the project successfully, but if I change the > GIT_TAG value, cmake only checks out the other commit. The project is not > rebuilt. > > > > -- > View this message in context: > http://cmake.3232098.n2.nabble.com/Do-build-after-GIT-TAG-changed-in-ExternalProject-Add-tp7590299.html > Sent from the CMake mailing list archive at Nabble.com. > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Sat Apr 18 14:39:57 2015 From: DLRdave at aol.com (David Cole) Date: Sat, 18 Apr 2015 14:39:57 -0400 Subject: [CMake] Don't download external projects again after calling "make clean" In-Reply-To: <1588572917.2149426.1429359332478.JavaMail.zimbra@inria.fr> References: <1351653491.156868.1428915508943.JavaMail.zimbra@inria.fr> <1334535078.171898.1428915841518.JavaMail.zimbra@inria.fr> <1121188496.1727145.1429248723887.JavaMail.zimbra@inria.fr> <1544359461.2146552.1429354828753.JavaMail.zimbra@inria.fr> <871275596.2148003.1429357111569.JavaMail.zimbra@inria.fr> <1588572917.2149426.1429359332478.JavaMail.zimbra@inria.fr> Message-ID: What version of CMake are you using? All the modern pre-built CMake installations should support https without extra effort on your part. Are you using a pre-built version from somewhere or are you building CMake yourself? On Saturday, April 18, 2015, Cedric Doucet wrote: > > Ok it seems the answer to my problem is here: > http://www.cmake.org/pipermail/cmake/2010-December/041295.html > I will try it. > > ----- Mail original ----- > > De: "Cedric Doucet" > > > ?: cmake at cmake.org > > Envoy?: Samedi 18 Avril 2015 13:38:31 > > Objet: Re: [CMake] Don't download external projects again after calling > "make clean" > > > > > > I have just tried to install curl to get https support. > > To do that, I have followed the steps below: > > > > 1. Installation of openssl: > > 1.a. ./config --prefix=/my/openssl/path > > 1.b. make > > 1.c. make test > > 1.d. make install > > 2. Installation of curl > > 2.a. ./configure --prefix=/my/curl/path --with-ssl=/my/openssl/path/lib > > 2.b. make > > 2.c. make install > > > > I have also prepend PATH with /my/curl/path/bin. > > However, the error remains. > > It seems that my version of curl (7.41.0) is not taken into acount > because I > > have still this line in the error message: > > User-Agent: curl/7.38.0 > > I tried to remove all previous of curl and libcurl but it does not change > > anything. > > > > Could you help me? > > > > C?dric > > > > > > ----- Mail original ----- > > > De: "Cedric Doucet" > > > > ?: "David Cole" > > > > Cc: cmake at cmake.org > > > Envoy?: Samedi 18 Avril 2015 13:00:28 > > > Objet: Re: [CMake] Don't download external projects again after calling > > > "make clean" > > > > > > > > > Hello David, > > > > > > thank you very much. > > > Unfortunately, I get the following error message if I remove my > download > > > command: > > > > > > -- downloading... > > > src='http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz' > > > dst='/home/cdoucet/Downloads/eigen/download/3.2.4.tar.gz' > > > timeout='none' > > > -- [download 100% complete] > > > CMake Error at src/eigen-stamp/download-eigen.cmake:27 (message): > > > error: downloading ' > http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz' > > > failed > > > > > > status_code: 1 > > > status_string: "Unsupported protocol" > > > log: Hostname was NOT found in DNS cache > > > Trying 131.103.20.167... > > > > > > Connected to bitbucket.org (131.103.20.167) port 80 (#0) > > > > > > GET /eigen/eigen/get/3.2.4.tar.gz HTTP/1.1 > > > > > > User-Agent: curl/7.38.0 > > > > > > Host: bitbucket.org > > > > > > Accept: */* > > > > > > > > > > > > HTTP/1.1 301 Moved Permanently > > > > > > Server nginx/1.6.2 is not blacklisted > > > > > > Server: nginx/1.6.2 > > > > > > Date: Sat, 18 Apr 2015 10:55:20 GMT > > > > > > Content-Type: text/html > > > > > > Content-Length: 184 > > > > > > Location: https://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz > > > > > > > > > > > > Ignoring the response-body > > > > > > > > > > > > 301 Moved Permanently > > > > > > > > > > > >

301 Moved Permanently

> > > > > >
nginx/1.6.2
> > > > > > > > > > > > > > > > > > Connection #0 to host bitbucket.org left intact > > > > > > Issue another request to this URL: > > > 'https://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz' > > > > > > Protocol "https" not supported or disabled in libcurl > > > > > > Closing connection -1 > > > > > > > > > > > > > > > ----- Mail original ----- > > > > De: "David Cole" > > > > > ?: "Cedric Doucet" > > > > > Cc: cmake at cmake.org > > > > Envoy?: Vendredi 17 Avril 2015 13:21:08 > > > > Objet: Re: [CMake] Don't download external projects again after > calling > > > > "make clean" > > > > > > > > Eliminate your DOWNLOAD_COMMAND. CMake knows how to do it with just > > > > the URL_MD5, DOWNLOAD_DIR and SOURCE_DIR information.... > > > > > > > > HTH, > > > > David > > > > > > > > > > > > On Fri, Apr 17, 2015 at 1:32 AM, Cedric Doucet < > cedric.doucet at inria.fr > > > > > wrote: > > > > > > > > > > Hello David, > > > > > > > > > > thank you very much for your help. > > > > > > > > > > Unfortunately I may do something wrong because it does not work. > > > > > After cleaning, the library is downloaded again. > > > > > > > > > > I guess my mistake comes from the fact I do not understand the > role of > > > > > URL_MD5. > > > > > Below is a simple example where downloading and installing is very > > > > > fast. > > > > > You just have to replace the value of EXTERNAL_DIR by the path to > your > > > > > own > > > > > "Downloads" repository. > > > > > I tried to put URL in my DOWNLOAD_COMMAND but the call "wget " > > > > > does > > > > > not seem to be understood by the wget command. > > > > > > > > > > Thanks again! > > > > > > > > > > C?dric > > > > > > > > > > > -------------------------------------------------------------------------- > > > > > cmake_minimum_required (VERSION 2.6) > > > > > > > > > > project (example CXX) > > > > > > > > > > set(CMAKE_VERBOSE_MAKEFILE ON) > > > > > > > > > > include(ProcessorCount) > > > > > ProcessorCount(N) > > > > > if(NOT N EQUAL 0) > > > > > set(CMAKE_BUILD_FLAGS -j${N}) > > > > > endif() > > > > > > > > > > include(ExternalProject) > > > > > set(EXTERNAL_DIR /home/cdoucet/Downloads) > > > > > ExternalProject_Add(eigen > > > > > PREFIX ${EXTERNAL_DIR}/eigen > > > > > DOWNLOAD_DIR ${EXTERNAL_DIR}/eigen/download > > > > > SOURCE_DIR ${EXTERNAL_DIR}/eigen/src > > > > > BINARY_DIR ${EXTERNAL_DIR}/eigen/build > > > > > INSTALL_DIR ${EXTERNAL_DIR}/eigen/install > > > > > URL > > > > > > http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz > > > > > URL_MD5 ccb18a771f678b38a3d33c321a8e7daf > > > > > DOWNLOAD_COMMAND wget > > > > > > http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz > > > > > && > > > > > tar xvzf 3.2.4.tar.gz -C > > > > > --strip-components=1 > > > > > CONFIGURE_COMMAND cd && cmake -D > > > > > CMAKE_INSTALL_PREFIX=$ > > > > > > ) > > > > > > ------------------------------------------------------------------------------ > > > > > > > > > > > > > > > > > > > > ----- Mail original ----- > > > > >> De: "David Cole" > > > > > >> ?: "Cedric Doucet" > > > > > >> Cc: cmake at cmake.org > > > > >> Envoy?: Lundi 13 Avril 2015 12:40:34 > > > > >> Objet: Re: [CMake] Don't download external projects again after > > > > >> calling > > > > >> "make clean" > > > > >> > > > > >> Use the URL_MD5 and DOWNLOAD_DIR arguments to ExternalProject_Add > to > > > > >> put the downloaded files into a location outside the build tree > > > > >> (perhaps ~/Downloads on Mac/Linux or $ENV{USERPROFILE}/Downloads > on > > > > >> Windows). > > > > >> > > > > >> With DOWNLOAD_DIR outside the build tree, and the checksums of the > > > > >> downloaded files being the same as you've specified via URL_MD5, > the > > > > >> download portion will be avoided once there is a local copy of a > file > > > > >> available. > > > > >> > > > > >> > > > > >> HTH, > > > > >> David C. > > > > >> > > > > >> > > > > >> On Mon, Apr 13, 2015 at 5:04 AM, Cedric Doucet > > > > >> > > > > > >> wrote: > > > > >> > > > > > >> > Hello! > > > > >> > > > > > >> > I use the ExternalProject_Add function to download third-party > > > > >> > libraries > > > > >> > of > > > > >> > a code. > > > > >> > > > > > >> > Once a library has been downloaded, I can call "make" as many > times > > > > >> > as > > > > >> > I > > > > >> > want without downloading this library again. > > > > >> > It seems that CMake detects that the library has already been > > > > >> > downloaded. > > > > >> > > > > > >> > However, calling "make clean" seems to destroy this feature. > > > > >> > Even if my library is not uninstalled during cleaning, calling > > > > >> > "make" > > > > >> > after > > > > >> > "make clean" will lead CMake to try download the library again. > > > > >> > > > > > >> > How could I tell CMake not to download the library again? > > > > >> > > > > > >> > Thank you very much for your help! > > > > >> > > > > > >> > C?dric > > > > >> > > > > > >> > -- > > > > >> > > > > > >> > Powered by www.kitware.com > > > > >> > > > > > >> > Please keep messages on-topic and check the CMake FAQ at: > > > > >> > http://www.cmake.org/Wiki/CMake_FAQ > > > > >> > > > > > >> > Kitware offers various services to support the CMake community. > For > > > > >> > more > > > > >> > information on each offering, please visit: > > > > >> > > > > > >> > CMake Support: http://cmake.org/cmake/help/support.html > > > > >> > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > > > >> > CMake Training Courses: > http://cmake.org/cmake/help/training.html > > > > >> > > > > > >> > Visit other Kitware open-source projects at > > > > >> > http://www.kitware.com/opensource/opensource.html > > > > >> > > > > > >> > Follow this link to subscribe/unsubscribe: > > > > >> > http://public.kitware.com/mailman/listinfo/cmake > > > > >> > > > > > > > -- > > > > > > Powered by www.kitware.com > > > > > > Please keep messages on-topic and check the CMake FAQ at: > > > http://www.cmake.org/Wiki/CMake_FAQ > > > > > > Kitware offers various services to support the CMake community. For > more > > > information on each offering, please visit: > > > > > > CMake Support: http://cmake.org/cmake/help/support.html > > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > > > > Visit other Kitware open-source projects at > > > http://www.kitware.com/opensource/opensource.html > > > > > > Follow this link to subscribe/unsubscribe: > > > http://public.kitware.com/mailman/listinfo/cmake > > > > > -- > > > > Powered by www.kitware.com > > > > Please keep messages on-topic and check the CMake FAQ at: > > http://www.cmake.org/Wiki/CMake_FAQ > > > > Kitware offers various services to support the CMake community. For more > > information on each offering, please visit: > > > > CMake Support: http://cmake.org/cmake/help/support.html > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/cmake > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 dummdoof-doof at web.de Sat Apr 18 17:58:50 2015 From: dummdoof-doof at web.de (typ1232) Date: Sat, 18 Apr 2015 14:58:50 -0700 (MST) Subject: [CMake] Do build after GIT_TAG changed in ExternalProject_Add In-Reply-To: References: <1429369490097-7590299.post@n2.nabble.com> Message-ID: <1429394330993-7590302.post@n2.nabble.com> I'm using CMake 3.0.2 with the Visual Studio 2013 generator. -- View this message in context: http://cmake.3232098.n2.nabble.com/Do-build-after-GIT-TAG-changed-in-ExternalProject-Add-tp7590299p7590302.html Sent from the CMake mailing list archive at Nabble.com. From wonder.mice at gmail.com Sat Apr 18 18:29:06 2015 From: wonder.mice at gmail.com (Andrey Pokrovskiy) Date: Sat, 18 Apr 2015 15:29:06 -0700 Subject: [CMake] ExternalProject can't have interface library as a dependency In-Reply-To: References: Message-ID: > That sounds odd. What provides it as an INTERFACE library? Me :) I created that target with add_library(openssl INTERFACE). I think I better ask the same question on dev list, since it's mostly details of get_property() implementation. On Sat, Apr 18, 2015 at 2:32 AM, Stephen Kelly wrote: > Andrey Pokrovskiy wrote: > >> /* I'm using cmake-3.2.20150331-gb190c. */ >> >> I have a following construction: >> >> ExternalProject_Add( >> websockets_ep >> DEPENDS ev openssl >> ...) >> >> But it so happened, that "openssl" is a INTERFACE library. > > That sounds odd. What provides it as an INTERFACE library? > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 john at mysticgd.com Sat Apr 18 20:01:56 2015 From: john at mysticgd.com (John van der Burg) Date: Sun, 19 Apr 2015 02:01:56 +0200 Subject: [CMake] Per target, per configuration compile flags issue Message-ID: I'm having some problem with custom configurations in combination with multiple cmake projects. Basically what I have is some helper function/macro which sets the available configurations, sets the CMAKE_CXX_FLAGS_ etc. I do this with: set(CMAKE_CONFIGURATION_TYPES Debug Release) set(CMAKE_CONFIGURATION_TYPES "${CMAKE_CONFIGURATION_TYPES}" CACHE STRING "The available configuration types." FORCE) Then per target, i set the compiler and linker flags per configuration. Such as: set(CMAKE_CXX_FLAGS_DEBUG "/MP /GS /analyze- /Zc:wchar_t /Zi /Gm- /Od /Ob1 /fp:fast /errorReport:prompt /Zc:forScope /GR- /Gd /Oy- /Oi /EHa /nologo /D \"DEBUG\" /D \"_DEBUG\" ${CUSTOM_CXX_WARNINGFLAGS} ${CUSTOM_CXX_ARCH_FLAGS} ${CUSTOM_CXX_RUNTIMEFLAG} ${CUSTOM_CXX_OPENMP}" CACHE STRING "Flags used by the C++ compiler during this build." FORCE ) set(CMAKE_C_FLAGS_DEBUG "" CACHE STRING "Flags used by the C compiler during this build." FORCE ) set(CMAKE_EXE_LINKER_FLAGS_DEBUG "${CUSTOM_LINKER_FLAGS} /DEBUG" CACHE STRING "Flags used for linking binaries during this build." FORCE ) set(CMAKE_SHARED_LINKER_FLAGS_DEBUG "${CUSTOM_LINKER_FLAGS} /DEBUG" CACHE STRING "Flags used by the shared libraries linker during this build." FORCE ) set(CMAKE_STATIC_LINKER_FLAGS_DEBUG "${CMAKE_STATIC_LINKER_FLAGS_DEBUG} ${CUSTOM_LINKER_FLAGS} /DEBUG" CACHE STRING "Flags used by the static libraries linker during this build." FORCE ) MARK_AS_ADVANCED(CMAKE_CXX_FLAGS_DEBUG CMAKE_C_FLAGS_DEBUG CMAKE_EXE_LINKER_FLAGS_DEBUG CMAKE_SHARED_LINKER_FLAGS_DEBUG CMAKE_STATIC_LINKER_FLAGS_DEBUG) #------------------------------------------------------------------------------------------------------------- set(CMAKE_CXX_FLAGS_RELEASE "/MP /GS /analyze- /Zc:wchar_t /Zi /Gm- /O2 /Ob2 /fp:fast /errorReport:prompt /Zc:forScope /GR- /Gd /Oy- /Oi /EHa /nologo /Ot /D \"NDEBUG\" ${CUSTOM_CXX_WARNINGFLAGS} ${CUSTOM_CXX_ARCH_FLAGS} ${CUSTOM_CXX_RUNTIMEFLAG} ${CUSTOM_CXX_OPENMP}" CACHE STRING "Flags used by the C++ compiler during this build." FORCE ) set(CMAKE_C_FLAGS_RELEASE "" CACHE STRING "Flags used by the C compiler during this build." FORCE ) set(CMAKE_EXE_LINKER_FLAGS_RELEASE "${CUSTOM_LINKER_FLAGS}" CACHE STRING "Flags used for linking binaries during this build." FORCE ) set(CMAKE_SHARED_LINKER_FLAGS_RELEASE "${CUSTOM_LINKER_FLAGS}" CACHE STRING "Flags used by the shared libraries linker during this build." FORCE ) set(CMAKE_STATIC_LINKER_FLAGS_RELEASE "${CUSTOM_LINKER_FLAGS}" CACHE STRING "Flags used by the static libraries linker during this build." FORCE ) MARK_AS_ADVANCED(CMAKE_CXX_FLAGS_RELEASE CMAKE_C_FLAGS_RELEASE CMAKE_EXE_LINKER_FLAGS_RELEASE CMAKE_SHARED_LINKER_FLAGS_RELEASE CMAKE_STATIC_LINKER_FLAGS_RELEASE) Now I'm making some project that uses add_subdirectory(...) to add other cmake projects. But doing that seems to overwrite the settings all the time with flags set by other projects. So if i adjust the warning level in one project then once generated (for visual studio), it has the warning level of another cmake project, as that has overwritten the compiler flags. Am I doing something wrong here? I tried to not cache and force the values, but that didnt work at all. Then CMake uses its default values everywhere. Basically I need unique per project, per configuration compiler and linker flags, but somehow I can't manage to get that working as when i add_subdirectory other projects they overwrite each others settings. If someone has some hints, that would be cool :) Also I noticed there is a COMPILE_FLAGS target property for set_target_properties That can be used to setup additional flags per target. But it has no support for different configurations it seems, while the LINKER_FLAGS option (i think its named like that) has, which seems odd. Cheers, - John -------------- next part -------------- An HTML attachment was scrubbed... URL: From yu at argcv.com Sun Apr 19 06:53:37 2015 From: yu at argcv.com (=?utf-8?B?WXUgSmluZw==?=) Date: Sun, 19 Apr 2015 18:53:37 +0800 Subject: [CMake] No Member Found when use cmake construct protocol-buffers Message-ID: I wish to use proto and managed by cmake. While some error found and it seems A sample project can be shown here(https://github.com/yuikns/cmake-proto) The files are as follow . ??? app1 ? ??? app1.cpp ? ??? app1.proto ??? CMakeLists.txt ??? common ? ??? bar ? ? ??? bar.proto ? ? ??? CMakeLists.txt ? ??? foo ? ??? CMakeLists.txt ? ??? foo.proto ??? README.md In common/bar/bar.proto, it defined as follow : import "common/foo/foo.proto"; message bar_msg { optional foo_msg foo = 1; optional string name = 2; } and I can use command : $ protoc --cpp_out=build common/bar/bar.proto $ protoc --cpp_out=build common/foo/foo.proto in root directory. while , I adjust several times and still can not make it work in cmake. Here is the question in stackoverflow http://stackoverflow.com/questions/29720410/no-member-found-when-use-cmake-construct-proto/29727925 , and someone said there may something wrong of PROTOBUF_GENERATE_CPP. May I know how can I adjust the project? Any help are appreciated . -------------- next part -------------- An HTML attachment was scrubbed... URL: From kjcamann.lists at gmail.com Sun Apr 19 12:13:32 2015 From: kjcamann.lists at gmail.com (Kenneth Camann) Date: Sun, 19 Apr 2015 12:13:32 -0400 Subject: [CMake] Working with dependencies that change Message-ID: Hi everyone! I am trying to get a code generation tool to behave "the same as" a C source file with respect to dependencies. By that I mean, suppose you have a C file "a.c". Because it can #include files, every time the content of `a.c` changes, its dependencies may have changed also. The dependencies get rescanned with -MMD. I would like some way to emulate this for my code generator. First I tried add_custom_command, which takes a fixed DEPENDS list, determined at the time the custom command is defined. Concretely, I mean something like this: function(add_generated_library) figure_out_dependencies(deps ${ARGN}) add_custom_command(... DEPENDS ${deps}) ... endfunction() But that only captures the dependencies at build-system-generation time. Every time the custom command runs, the DEPENDS list may need to change, because the changes may imply new dependencies. How should I go about doing this? Thanks, Ken -------------- next part -------------- An HTML attachment was scrubbed... URL: From yu at argcv.com Sun Apr 19 19:14:55 2015 From: yu at argcv.com (=?utf-8?B?WXUgSmluZw==?=) Date: Mon, 20 Apr 2015 07:14:55 +0800 Subject: [CMake] No Member Found when use cmake construct protocol-buffers In-Reply-To: References: Message-ID: It is really sorry and I sent a html mail and it shows too ugly... I have converted it to plain text and wish someone may give some suggestion. ------------------ Original ------------------ From: "Yu Jing"; Date: Sun, Apr 19, 2015 06:53 PM To: "cmake"; Subject: No Member Found when use cmake construct protocol-buffers I wish to use proto and managed by cmake. While some error found and it seems A sample project can be shown here(https://github.com/yuikns/cmake-proto) The files are as follow . ??? app1 ? ??? app1.cpp ? ??? app1.proto ??? CMakeLists.txt ??? common ? ??? bar ? ? ??? bar.proto ? ? ??? CMakeLists.txt ? ??? foo ? ??? CMakeLists.txt ? ??? foo.proto ??? README.md In common/bar/bar.proto, it defined as follow : import "common/foo/foo.proto"; message bar_msg { optional foo_msg foo = 1; optional string name = 2; } and I can use command : $ protoc --cpp_out=build common/bar/bar.proto $ protoc --cpp_out=build common/foo/foo.proto in root directory. while , I adjust several times and still can not make it work in cmake. Here is the question in stackoverflow http://stackoverflow.com/questions/29720410/no-member-found-when-use-cmake-construct-proto/29727925 , and someone said there may something wrong of PROTOBUF_GENERATE_CPP. May I know how can I adjust the project? Any help are appreciated . From julien.jomier at kitware.com Mon Apr 20 05:24:15 2015 From: julien.jomier at kitware.com (Julien Jomier) Date: Mon, 20 Apr 2015 11:24:15 +0200 Subject: [CMake] ANN: CMake Course - June 1 in Lyon, France In-Reply-To: <53BD4650.6070909@kitware.com> References: <53BD4650.6070909@kitware.com> Message-ID: <5534C5BF.2020605@kitware.com> Kitware will be holding a CMake training course on June 1, 2015 at Kitware's office in Lyon, France. This one-day course will cover CMake, CTest, CPack and CDash. Visit our website for more information and registration details (early registration and student discounts available): http://training.kitware.fr/browse/79 Note that the course will be taught in English. If you have any questions, please contact us at training at kitware.fr. We are looking forward to seeing you in Lyon, Julien -- Kitware SAS 26 rue Louis Gu?rin 69100 Villeurbanne, France http://www.kitware.eu From victorsv at gmail.com Mon Apr 20 05:47:52 2015 From: victorsv at gmail.com (victor sv) Date: Mon, 20 Apr 2015 11:47:52 +0200 Subject: [CMake] CheckLibraryExists behaviour with different compilers Message-ID: Hello all, i'm using CMake 2.8.12.2 and trying to search a symbol inside METIS library with: CHECK_LIBRARY_EXISTS(metis METIS_SetDefaultOptions ${METIS_PATH} HAVE_METIS_SETDEFAULTOPTIONS) If METIS library was compiled with Intel compilers and i build my project with the same compilers CMake says: Looking for METIS_SetDefaultOptions in metis - found But if I build my project with GNU compilers and METIS still compiled with Intel compilers, CMake says: Looking for METIS_SetDefaultOptions in metis - not found Is it the expected behaviour? Someone knows how to do this in a clean/portable way? Any help would be appreciated. Best regards, V?ctor. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Mon Apr 20 05:55:26 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Mon, 20 Apr 2015 11:55:26 +0200 Subject: [CMake] CheckLibraryExists behaviour with different compilers In-Reply-To: References: Message-ID: <5534CD0E.9010409@gmail.com> On 04/20/2015 11:47 AM, victor sv wrote: > CHECK_LIBRARY_EXISTS(metis METIS_SetDefaultOptions ${METIS_PATH} > HAVE_METIS_SETDEFAULTOPTIONS) [...] > > But if I build my project with GNU compilers and METIS still compiled > with Intel compilers, CMake says: > > > Looking for METIS_SetDefaultOptions in metis - not found I'd first check CMakeFiles/CMakeError.log to see why it actually failed. Nils From victorsv at gmail.com Mon Apr 20 06:28:14 2015 From: victorsv at gmail.com (victor sv) Date: Mon, 20 Apr 2015 12:28:14 +0200 Subject: [CMake] CheckLibraryExists behaviour with different compilers In-Reply-To: <5534CD0E.9010409@gmail.com> References: <5534CD0E.9010409@gmail.com> Message-ID: Thanks Nils for que quick response! The error log is as follows (summarized): Determining if the function METIS_SetDefaultOptions exists in the metis failed with the following output: Change Dir: /home/vsande/fempar/build/CMakeFiles/CMakeTmp Run Build Command:/usr/bin/make "cmTryCompileExec4124725466/fast" /usr/bin/make -f CMakeFiles/cmTryCompileExec4124725466.dir/build.make CMakeFiles/cmTryCompileExec4124725466.dir/build make[1]: se ingresa al directorio ?/home/vsande/fempar/build/CMakeFiles/CMakeTmp? /usr/bin/cmake -E cmake_progress_report /home/vsande/fempar/build/CMakeFiles/CMakeTmp/CMakeFiles 1 Building C object CMakeFiles/cmTryCompileExec4124725466.dir/CheckFunctionExists.c.o /usr/bin/cc -DCHECK_FUNCTION_EXISTS=METIS_SetDefaultOptions -o CMakeFiles/cmTryCompileExec4124725466.dir/CheckFunctionExists.c.o -c /usr/share/cmake-2.8/Modules/CheckFunctionExists.c Linking C executable cmTryCompileExec4124725466 /usr/bin/cmake -E cmake_link_script CMakeFiles/cmTryCompileExec4124725466.dir/link.txt --verbose=1 /usr/bin/cc -DCHECK_FUNCTION_EXISTS=METIS_SetDefaultOptions CMakeFiles/cmTryCompileExec4124725466.dir/CheckFunctionExists.c.o -o cmTryCompileExec4124725466 -L/home/vsande/Descargas/metis-5.1.0/build/libmetis -rdynamic -lmetis -lm -Wl,-rpath,/home/vsande/Descargas/metis-5.1.0/build/libmetis /home/vsande/Descargas/metis-5.1.0/build/libmetis/libmetis.a(gklib.c.o): En la funci?n `libmetis__icopy': /home/vsande/Descargas/metis-5.1.0/libmetis/gklib.c:(.text+0x2b1f): referencia a `_intel_fast_memmove' sin definir ... /home/vsande/Descargas/metis-5.1.0/build/libmetis/libmetis.a(memory.c.o): En la funci?n `gk_zcopy': /home/vsande/Descargas/metis-5.1.0/GKlib/memory.c:(.text+0x289f): referencia a `_intel_fast_memmove' sin definir /home/vsande/Descargas/metis-5.1.0/build/libmetis/libmetis.a(memory.c.o):/home/vsande/Descargas/metis-5.1.0/GKlib/memory.c:(.text+0x312f): m?s referencias a `_intel_fast_memmove' sin definir a continuaci?n /home/vsande/Descargas/metis-5.1.0/build/libmetis/libmetis.a(error.c.o): En la funci?n `errexit': /home/vsande/Descargas/metis-5.1.0/GKlib/error.c:(.text+0x45b): referencia a `__intel_sse2_strlen' sin definir collect2: error: ld returned 1 exit status make[1]: *** [cmTryCompileExec4124725466] Error 1 make[1]: se sale del directorio ?/home/vsande/fempar/build/CMakeFiles/CMakeTmp? make: *** [cmTryCompileExec4124725466/fast] Error 2 After googling and reading this: http://www.opal-rt.com/kb-article/undefined-reference-intel-fast-memset-build-error-related-rte-delay I try to link against libirc.a and libimf.a and it works fine. I do other test compiling a shared METIS library with Intel compilers and it works too. There is something that I'm not well understanding ... If I build a static library, even with Intel compilers, shouldn't this library contain all the needed symbols? Thanks again :) V?ctor 2015-04-20 11:55 GMT+02:00 Nils Gladitz : > On 04/20/2015 11:47 AM, victor sv wrote: > > CHECK_LIBRARY_EXISTS(metis METIS_SetDefaultOptions ${METIS_PATH} >> HAVE_METIS_SETDEFAULTOPTIONS) >> > > [...] > > >> But if I build my project with GNU compilers and METIS still compiled >> with Intel compilers, CMake says: >> >> >> Looking for METIS_SetDefaultOptions in metis - not found >> > > I'd first check CMakeFiles/CMakeError.log to see why it actually failed. > > Nils > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Mon Apr 20 06:33:55 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Mon, 20 Apr 2015 12:33:55 +0200 Subject: [CMake] CheckLibraryExists behaviour with different compilers In-Reply-To: References: <5534CD0E.9010409@gmail.com> Message-ID: <5534D613.2070600@gmail.com> On 04/20/2015 12:28 PM, victor sv wrote: > After googling and reading this: > > http://www.opal-rt.com/kb-article/undefined-reference-intel-fast-memset-build-error-related-rte-delay > > I try to link against libirc.a and libimf.a and it works fine. I do > other test compiling a shared METIS library with Intel compilers and it > works too. > > There is something that I'm not well understanding ... If I build a > static library, even with Intel compilers,shouldn't this library contain > all the needed symbols? A static library is basically a container of object files. Library dependencies are normally neither included within that container nor are they recorded. Nils From victorsv at gmail.com Mon Apr 20 06:57:08 2015 From: victorsv at gmail.com (victor sv) Date: Mon, 20 Apr 2015 12:57:08 +0200 Subject: [CMake] CheckLibraryExists behaviour with different compilers In-Reply-To: <5534D613.2070600@gmail.com> References: <5534CD0E.9010409@gmail.com> <5534D613.2070600@gmail.com> Message-ID: Ok Nils, thanks for your help :) Best regards, V?ctor. 2015-04-20 12:33 GMT+02:00 Nils Gladitz : > On 04/20/2015 12:28 PM, victor sv wrote: > >> After googling and reading this: >> >> >> http://www.opal-rt.com/kb-article/undefined-reference-intel-fast-memset-build-error-related-rte-delay >> >> I try to link against libirc.a and libimf.a and it works fine. I do >> other test compiling a shared METIS library with Intel compilers and it >> works too. >> >> There is something that I'm not well understanding ... If I build a >> static library, even with Intel compilers,shouldn't this library contain >> all the needed symbols? >> > > A static library is basically a container of object files. > Library dependencies are normally neither included within that container > nor are they recorded. > > Nils > -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Mon Apr 20 07:26:27 2015 From: DLRdave at aol.com (David Cole) Date: Mon, 20 Apr 2015 07:26:27 -0400 Subject: [CMake] Do build after GIT_TAG changed in ExternalProject_Add In-Reply-To: References: <1429369490097-7590299.post@n2.nabble.com> <1429394330993-7590302.post@n2.nabble.com> Message-ID: By the way, the "if not exist" line in build.cmd should be all on one line of text... the plain text email sending wrapped it for me, where there should be no newline in the actual script... Boo, email bad. On Mon, Apr 20, 2015 at 7:21 AM, David Cole wrote: > I am using Visual Studio 2013 with Update 4 installed, and the very > latest CMake v3.2.2 on my Windows machine. I cannot reproduce your > problem, and include here the complete steps I used while trying. > Anybody should be able to run configure.cmd and build.cmd as follows > and reproduce the correct behavior with CMake 3.2.2 -- let me know if > you try this yourself and something doesn't work... > > I modified your CMakeLists as follows (because I know the SmallAndFast > repo builds quite quickly on many different systems, and is easy to > test with): > > # ---------------------------------------------------------------------- > # CMakeLists.txt > > cmake_minimum_required(VERSION 3.2) > project(repro NONE) > > include(ExternalProject) > > ExternalProject_Add(name > GIT_REPOSITORY https://github.com/dlrdave/SmallAndFast.git > GIT_TAG 68c3cebf842aa8a13d659fec428fd85ca3a24307 > CMAKE_ARGS "" > INSTALL_COMMAND "" > ) > > # Possible commits in this repo (most recent first) > # > # 68c3cebf842aa8a13d659fec428fd85ca3a24307 > # a0acdce3a549796ca4424c591c038eeb19e59a72 > # 5e98e304a464946dd34cb4c53eb3dd1fd348781b > # 8ea36ce26a6b00ab839064a6066a984f6d6647f6 > > # END CMakeLists.txt > > > Then I wrote two wrapper scripts configure.cmd and build.cmd so you > can see exactly how I execute the steps for building the code. Put all > three files in the same initially empty directory to test it yourself. > You can run configure.cmd exactly once, and then just run build.cmd > over and over again. > > @rem ------------------------------------------------------------------- > @rem configure.cmd > @echo off > set cmake_exe=C:\Program Files (x86)\CMake\bin\cmake.exe > > pushd "%~dp0" > > if exist ".\build" rmdir /s /q build > mkdir build > > pushd build > "%cmake_exe%" -G "Visual Studio 12 2013" .. > popd > > popd > > echo Now run build.cmd... > pause > @rem END configure.cmd > > > @rem ------------------------------------------------------------------- > @rem build.cmd > @echo off > set cmake_exe=C:\Program Files (x86)\CMake\bin\cmake.exe > > pushd "%~dp0" > > if not exist ".\build" echo Run configure.cmd before running > build.cmd&& pause&& exit /b 1 > > pushd build > "%cmake_exe%" --build . --config Release > popd > > popd > > pause > @rem END build.cmd > > > Everytime you run configure.cmd, it will wipe out the "build" > directory and start clean, so you should only run it once at the > beginning... > > Now if you run build.cmd after that, you should see the repo cloned > the first time you run it. After that, unless you change the > CMakeLists file, each build should be a "do nothing" build. > > > If I change the commit hash from the first value to the second value > in between runs of build.cmd, I see output like this: > > CustomBuild: > Performing update step for 'name' > Previous HEAD position was 68c3ceb... Add more lines of > intentionally warning code > HEAD is now at a0acdce... Add an intentional memory leak exe and test > > > If I do not change anything in between runs of build.cmd, I only see > this output: > > CustomBuild: > Performing update step for 'name' > > > Is this essentially the same as what you're doing? Or are you doing > something differently than this? > > Does this help you figure out what's going wrong...? > > > Hope it helps somehow, > David C. > > > > > On Sat, Apr 18, 2015 at 5:58 PM, typ1232 wrote: >> I'm using CMake 3.0.2 with the Visual Studio 2013 generator. >> >> >> >> -- >> View this message in context: http://cmake.3232098.n2.nabble.com/Do-build-after-GIT-TAG-changed-in-ExternalProject-Add-tp7590299p7590302.html >> Sent from the CMake mailing list archive at Nabble.com. >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake From DLRdave at aol.com Mon Apr 20 07:21:11 2015 From: DLRdave at aol.com (David Cole) Date: Mon, 20 Apr 2015 07:21:11 -0400 Subject: [CMake] Do build after GIT_TAG changed in ExternalProject_Add In-Reply-To: <1429394330993-7590302.post@n2.nabble.com> References: <1429369490097-7590299.post@n2.nabble.com> <1429394330993-7590302.post@n2.nabble.com> Message-ID: I am using Visual Studio 2013 with Update 4 installed, and the very latest CMake v3.2.2 on my Windows machine. I cannot reproduce your problem, and include here the complete steps I used while trying. Anybody should be able to run configure.cmd and build.cmd as follows and reproduce the correct behavior with CMake 3.2.2 -- let me know if you try this yourself and something doesn't work... I modified your CMakeLists as follows (because I know the SmallAndFast repo builds quite quickly on many different systems, and is easy to test with): # ---------------------------------------------------------------------- # CMakeLists.txt cmake_minimum_required(VERSION 3.2) project(repro NONE) include(ExternalProject) ExternalProject_Add(name GIT_REPOSITORY https://github.com/dlrdave/SmallAndFast.git GIT_TAG 68c3cebf842aa8a13d659fec428fd85ca3a24307 CMAKE_ARGS "" INSTALL_COMMAND "" ) # Possible commits in this repo (most recent first) # # 68c3cebf842aa8a13d659fec428fd85ca3a24307 # a0acdce3a549796ca4424c591c038eeb19e59a72 # 5e98e304a464946dd34cb4c53eb3dd1fd348781b # 8ea36ce26a6b00ab839064a6066a984f6d6647f6 # END CMakeLists.txt Then I wrote two wrapper scripts configure.cmd and build.cmd so you can see exactly how I execute the steps for building the code. Put all three files in the same initially empty directory to test it yourself. You can run configure.cmd exactly once, and then just run build.cmd over and over again. @rem ------------------------------------------------------------------- @rem configure.cmd @echo off set cmake_exe=C:\Program Files (x86)\CMake\bin\cmake.exe pushd "%~dp0" if exist ".\build" rmdir /s /q build mkdir build pushd build "%cmake_exe%" -G "Visual Studio 12 2013" .. popd popd echo Now run build.cmd... pause @rem END configure.cmd @rem ------------------------------------------------------------------- @rem build.cmd @echo off set cmake_exe=C:\Program Files (x86)\CMake\bin\cmake.exe pushd "%~dp0" if not exist ".\build" echo Run configure.cmd before running build.cmd&& pause&& exit /b 1 pushd build "%cmake_exe%" --build . --config Release popd popd pause @rem END build.cmd Everytime you run configure.cmd, it will wipe out the "build" directory and start clean, so you should only run it once at the beginning... Now if you run build.cmd after that, you should see the repo cloned the first time you run it. After that, unless you change the CMakeLists file, each build should be a "do nothing" build. If I change the commit hash from the first value to the second value in between runs of build.cmd, I see output like this: CustomBuild: Performing update step for 'name' Previous HEAD position was 68c3ceb... Add more lines of intentionally warning code HEAD is now at a0acdce... Add an intentional memory leak exe and test If I do not change anything in between runs of build.cmd, I only see this output: CustomBuild: Performing update step for 'name' Is this essentially the same as what you're doing? Or are you doing something differently than this? Does this help you figure out what's going wrong...? Hope it helps somehow, David C. On Sat, Apr 18, 2015 at 5:58 PM, typ1232 wrote: > I'm using CMake 3.0.2 with the Visual Studio 2013 generator. > > > > -- > View this message in context: http://cmake.3232098.n2.nabble.com/Do-build-after-GIT-TAG-changed-in-ExternalProject-Add-tp7590299p7590302.html > Sent from the CMake mailing list archive at Nabble.com. > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From dummdoof-doof at web.de Mon Apr 20 08:31:48 2015 From: dummdoof-doof at web.de (typ1232) Date: Mon, 20 Apr 2015 05:31:48 -0700 (MST) Subject: [CMake] Do build after GIT_TAG changed in ExternalProject_Add In-Reply-To: References: <1429369490097-7590299.post@n2.nabble.com> <1429394330993-7590302.post@n2.nabble.com> Message-ID: <1429533108166-7590316.post@n2.nabble.com> Thank you very much for your detailed response. I updated to CMake version 3.2.2 and I'm also using VS 2013 Update 4. When testing with your project, I noticed the first difference with your description is here: "Now if you run build.cmd after that, you should see the repo cloned the first time you run it. After that, unless you change the CMakeLists file, each build should be a "do nothing" build. " For me the external project is additionally configured and built after it was cloned and it will produce an output file (build\name-prefix\src\name-build\Release\echoargs.exe). Now when changing the GIT_TAG I get exactly what you describe. Only the update step is executed to checkout the other commit. But here I would expect that the project is built again, because the commit has changed an input file (intentional_compile_warning.cxx). See: https://github.com/dlrdave/SmallAndFast/commit/68c3cebf842aa8a13d659fec428fd85ca3a24307 Am I wrong with this intuitive expectation? To me it seems to be the logical thing to do. If I change the GIT_TAG, I want to use the outputs of that exact version and not some outdated one. Our external project is a library to which we link. If it is not rebuilt after GIT_TAG is changed, then there will be build errors. -- View this message in context: http://cmake.3232098.n2.nabble.com/Do-build-after-GIT-TAG-changed-in-ExternalProject-Add-tp7590299p7590316.html Sent from the CMake mailing list archive at Nabble.com. From dummdoof-doof at web.de Mon Apr 20 08:45:36 2015 From: dummdoof-doof at web.de (typ1232) Date: Mon, 20 Apr 2015 05:45:36 -0700 (MST) Subject: [CMake] Do build after GIT_TAG changed in ExternalProject_Add In-Reply-To: <1429533108166-7590316.post@n2.nabble.com> References: <1429369490097-7590299.post@n2.nabble.com> <1429394330993-7590302.post@n2.nabble.com> <1429533108166-7590316.post@n2.nabble.com> Message-ID: <1429533936969-7590317.post@n2.nabble.com> Note that I changed CMAKE_ARGS, so the target is used that contains the file that was changed in the commit. CMAKE_ARGS "-DSAF_INTENTIONAL_COMPILE_WARNING=TRUE" -- View this message in context: http://cmake.3232098.n2.nabble.com/Do-build-after-GIT-TAG-changed-in-ExternalProject-Add-tp7590299p7590317.html Sent from the CMake mailing list archive at Nabble.com. From victorsv at gmail.com Mon Apr 20 08:54:47 2015 From: victorsv at gmail.com (victor sv) Date: Mon, 20 Apr 2015 14:54:47 +0200 Subject: [CMake] CheckLibraryExists behaviour with different compilers In-Reply-To: References: <5534CD0E.9010409@gmail.com> <5534D613.2070600@gmail.com> Message-ID: Hello again, Sometimes we don't have control on external libraries compilation and we don't know which compiler was used to generate external libraries now my questions is, Is there a CMake-standard-way to proceed in these cases? What is the best way to specify dependencies depending on the compiler? Thanks in advance. V?ctor. 2015-04-20 12:57 GMT+02:00 victor sv : > Ok Nils, > > thanks for your help :) > > Best regards, > V?ctor. > > 2015-04-20 12:33 GMT+02:00 Nils Gladitz : > >> On 04/20/2015 12:28 PM, victor sv wrote: >> >>> After googling and reading this: >>> >>> >>> http://www.opal-rt.com/kb-article/undefined-reference-intel-fast-memset-build-error-related-rte-delay >>> >>> I try to link against libirc.a and libimf.a and it works fine. I do >>> other test compiling a shared METIS library with Intel compilers and it >>> works too. >>> >>> There is something that I'm not well understanding ... If I build a >>> static library, even with Intel compilers,shouldn't this library contain >>> all the needed symbols? >>> >> >> A static library is basically a container of object files. >> Library dependencies are normally neither included within that container >> nor are they recorded. >> >> Nils >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Mon Apr 20 09:06:26 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Mon, 20 Apr 2015 15:06:26 +0200 Subject: [CMake] CheckLibraryExists behaviour with different compilers In-Reply-To: References: <5534CD0E.9010409@gmail.com> <5534D613.2070600@gmail.com> Message-ID: <5534F9D2.1020409@gmail.com> On 04/20/2015 02:54 PM, victor sv wrote: > Hello again, > > Sometimes we don't have control on external libraries compilation and we > don't know which compiler was used to generate external libraries > > now my questions is,Is there a CMake-standard-way to proceed in these cases? Proper shared libraries record their own load dependencies but with static libraries there is no generic way to record or retrieve the required link information. The build process of the library might export that information in some form through e.g. pkg-config (.pc) files, custom configuration scripts (e.g. foo-config), libtool library files (.la) or cmake target exports with package configuration files. If the library does not happen to provide a (working) cmake package configuration file the next best thing is probably writing a (or using an existing) cmake find module. The find module could then try to guess static library dependencies based on information provided elsewhere (e.g. by querying pkg-config or parsing configuration files) or by falling back to manual user input. Nils From becker.tobi at gmail.com Mon Apr 20 13:14:13 2015 From: becker.tobi at gmail.com (Tobias Becker) Date: Mon, 20 Apr 2015 19:14:13 +0200 Subject: [CMake] cmakepp: Expression Syntax Message-ID: Hi All, I've update my open source project to offer an alternative CMake syntax which is still a bit Beta. If your interested here is the Blog Post: http://thetoeb.de/2015/04/20/cmakepp-expression-syntax/ It allows you to use nested function calls with return values and is integrable into cmake quite nicely: It can be used as a replacement for cmake_parse_arguments. It is written in pure cmake code, does not require any other dependencies and works from CMake version 2.8.12 upwards Please feel free to use it to your liking :) Cheers Tobi -------------- next part -------------- An HTML attachment was scrubbed... URL: From wesley.hoke at gmail.com Mon Apr 20 13:40:46 2015 From: wesley.hoke at gmail.com (Wesley Smith) Date: Mon, 20 Apr 2015 10:40:46 -0700 Subject: [CMake] Cuda CUDA_SEPARABLE_COMPILATION errors during linking In-Reply-To: References: Message-ID: Apparently there's a bug report and fix for this: http://www.cmake.org/Bug/view.php?id=15016 But the fix hasn't been committed anywhere. It has been lingering in limbo for almost 9 months. Thanks!! wes On Fri, Apr 17, 2015 at 4:20 PM, Wesley Smith wrote: > With CUDA_SEPARABLE_COMPILATION enabled, I'm always getting linking > errors when I try to build. Seems it's looking for a directory that > doesn't exist: > '/build/CMakeFiles/SlicerLib.dir/Debug > > If I manually create this directory, everything works. Seems that > either the directory path isn't being computed properly or that code > to create the directory if needed is missing. > > wes > > > 2>C:\Program Files\NVIDIA GPU Computing > Toolkit\CUDA\v7.0\bin\crt\link.stub : fatal error C1083: Cannot open > compiler generated file: > '/build/CMakeFiles/SlicerLib.dir/Debug/SlicerLib_intermediate_link.obj': > No such file or directory > 2>C:\Program Files > (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(127,5): > error MSB3073: The command "setlocal > 2>C:\Program Files > (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(127,5): > error MSB3073: "C:\Program Files (x86)\CMake\bin\cmake.exe" -E echo > "Building NVCC intermediate link file > CMakeFiles/SlicerLib.dir/Debug/SlicerLib_intermediate_link.obj" > 2>C:\Program Files > (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(127,5): > error MSB3073: if %errorlevel% neq 0 goto :cmEnd > 2>C:\Program Files > (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(127,5): > error MSB3073: "C:\Program Files\NVIDIA GPU Computing > Toolkit\CUDA\v7.0\bin\nvcc.exe" -arch=sm_30 -m64 -ccbin "C:\Program > Files (x86)\Microsoft Visual Studio 12.0\VC\bin" -Xcompiler /MDd > -dlink /build/CMakeFiles/SlicerLib.dir/src/bitmap/fragCounter/Debug/SlicerLib_generated_amFragCounterCuda.cu.obj > /build/CMakeFiles/SlicerLib.dir/src/bitmap/materialCounter/Debug/SlicerLib_generated_amBitmapMaterialCounterABufferCuda.cu.obj > /build/CMakeFiles/SlicerLib.dir/src/bitmap/materialCounter/Debug/SlicerLib_generated_amBitmapMaterialCounterCuda.cu.obj > /build/CMakeFiles/SlicerLib.dir/src/cuda/Debug/SlicerLib_generated_amCuda.cu.obj > /build/CMakeFiles/SlicerLib.dir/src/cuda/Debug/SlicerLib_generated_amCudaTexture.cu.obj > /build/CMakeFiles/SlicerLib.dir/src/vector/Debug/SlicerLib_generated_amVectorBoundaryProcess.cu.obj > /build/CMakeFiles/SlicerLib.dir/src/vector/Debug/SlicerLib_generated_amVectorContourDifference.cu.obj > /build/CMakeFiles/SlicerLib.dir/src/vector/Debug/SlicerLib_generated_amVectorContourOffset2.cu.obj > /build/CMakeFiles/SlicerLib.dir/src/vector/Debug/SlicerLib_generated_amVectorContourProcess.cu.obj > /build/CMakeFiles/SlicerLib.dir/src/vector/Debug/SlicerLib_generated_amVectorCudaHood.cu.obj > /build/CMakeFiles/SlicerLib.dir/src/vector/Debug/SlicerLib_generated_amVectorCudaIntersections.cu.obj > /build/CMakeFiles/SlicerLib.dir/src/vector/Debug/SlicerLib_generated_amVectorCudaLineSegments.cu.obj > /build/CMakeFiles/SlicerLib.dir/src/vector/Debug/SlicerLib_generated_amVectorCudaLineSegments2.cu.obj > /build/CMakeFiles/SlicerLib.dir/src/vector/Debug/SlicerLib_generated_amVectorCudaParametricIntersections.cu.obj > /build/CMakeFiles/SlicerLib.dir/src/vector/Debug/SlicerLib_generated_amVectorInfill45Processor.cu.obj > /build/CMakeFiles/SlicerLib.dir/src/vector/Debug/SlicerLib_generated_amVectorOutlineContour.cu.obj > /build/CMakeFiles/SlicerLib.dir/src/vector/Debug/SlicerLib_generated_amVectorSlicerProcess.cu.obj > -o /build/CMakeFiles/SlicerLib.dir/Debug/SlicerLib_intermediate_link.obj > 2>C:\Program Files > (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(127,5): > error MSB3073: if %errorlevel% neq 0 goto :cmEnd > 2>C:\Program Files > (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(127,5): > error MSB3073: :cmEnd > 2>C:\Program Files > (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(127,5): > error MSB3073: endlocal & call :cmErrorLevel %errorlevel% & goto > :cmDone > 2>C:\Program Files > (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(127,5): > error MSB3073: :cmErrorLevel > 2>C:\Program Files > (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(127,5): > error MSB3073: exit /b %1 > 2>C:\Program Files > (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(127,5): > error MSB3073: :cmDone > 2>C:\Program Files > (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(127,5): > error MSB3073: if %errorlevel% neq 0 goto :VCEnd > 2>C:\Program Files > (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(127,5): > error MSB3073: :VCEnd" exited with code 1. > 3>------ Build started: Project: CmbVisualizer, Configuration: Debug x64 ------ From irwin at beluga.phys.uvic.ca Tue Apr 21 15:26:36 2015 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Tue, 21 Apr 2015 12:26:36 -0700 (PDT) Subject: [CMake] cmp0026, file(GENERATE...), and configure_file In-Reply-To: References: Message-ID: On 2015-04-18 11:35+0200 Stephen Kelly wrote: > Alan W. Irwin wrote: > >> So is it recommended that a two-step procedure be used to configure >> a file? For example: > > Yes, that seems to be a valid thing to do. > >> If the above complications for configured files are the only way to >> deal with a mixture of @...@ items and generator expressions to >> configure, could a change to configure_file so that it honors >> generator expressions be implemented to avoid these complications? > > Nope, generator expressions are only available at generate-time, but > configure_file is evaluated before that. I was well aware of that so I assumed if this was implemented configure_file would be moved to generate-time as well. So there are really two questions here. (1) Could the move to honoring generator expressions by configure_file (as well as moving configure_file to generate time) be straightforwardly implemented, and (2) would that move cause any problems for users (because of the necessary move to generate-time). Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From DLRdave at aol.com Tue Apr 21 15:54:46 2015 From: DLRdave at aol.com (David Cole) Date: Tue, 21 Apr 2015 15:54:46 -0400 Subject: [CMake] cmp0026, file(GENERATE...), and configure_file In-Reply-To: References: Message-ID: I can only imagine that would cause IMMENSE problems. I depend on configure_file being an immediate action in many many many places. (i.e. -- the very next line of code in my CMakeLists.txt file can depend on the result of configure_file being on disk and up to date at the moment of configure processing...) Now, having said that, I could imagine you may want to change *some* configure_file calls to file(GENERATE calls. Or to enable @@ substitution in something like an explicit configure_file(GENERATE signature. I would not think it wise or advisable to defer existing configure_file calls to generate time. Not by a long shot... David C. On Tue, Apr 21, 2015 at 3:26 PM, Alan W. Irwin wrote: > On 2015-04-18 11:35+0200 Stephen Kelly wrote: > >> Alan W. Irwin wrote: >> >>> So is it recommended that a two-step procedure be used to configure >>> a file? For example: >> >> >> Yes, that seems to be a valid thing to do. >> >>> If the above complications for configured files are the only way to >>> deal with a mixture of @...@ items and generator expressions to >>> configure, could a change to configure_file so that it honors >>> generator expressions be implemented to avoid these complications? >> >> >> Nope, generator expressions are only available at generate-time, but >> configure_file is evaluated before that. > > > I was well aware of that so I assumed if this was implemented > configure_file would be moved to generate-time as well. > > So there are really two questions here. (1) Could the move to > honoring generator expressions by configure_file (as well as moving > configure_file to generate time) be straightforwardly implemented, and > (2) would that move cause any problems for users (because of > the necessary move to generate-time). > > Alan > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state > implementation for stellar interiors (freeeos.sf.net); the Time > Ephemerides project (timeephem.sf.net); PLplot scientific plotting > software package (plplot.sf.net); the libLASi project > (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); > and the Linux Brochure Project (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 kvolkov at fastmail.net Tue Apr 21 19:12:58 2015 From: kvolkov at fastmail.net (kvolkov at fastmail.net) Date: Wed, 22 Apr 2015 02:12:58 +0300 Subject: [CMake] add_custom_command: update dependencies over rebuilds Message-ID: <1429657978.1004070.256861449.38C151B1@webmail.messagingengine.com> Hello, Is there a way to to update add_custom_command dependencies over project rebuilds ? Current status - code generator that builds set of sources taking one input file as parameter - codegen input file may include other input files - already solved task of getting list of output files, parsing input codegen files to get full list of codegen inputs. I.e. add_custom_command is provided with correct set of dependencies for the first time: add_custom_command(OUTPUT ${generatedSources} COMMAND ${codegenCommand} ARGS ${codegenArgs} DEPENDS ${codegenInputFiles}) Problem scenario Current system works well until someone modifies one of codegen input files to include new input file or remove include of existing one. This case, it is required to update list of codegen input file provided to add_custom_command as dependencies, but I have no idea how. P.S. From description of IMPLICIT_DEPENDS, it looks that I need hooks to register my language scanner, to have dependencies updated during build time like it is done for C/C++ code Thanks! Konstantin From dank at kegel.com Tue Apr 21 21:00:22 2015 From: dank at kegel.com (Dan Kegel) Date: Tue, 21 Apr 2015 18:00:22 -0700 Subject: [CMake] "sudo make install; DESTDIR=foo make install" fails Message-ID: If "sudo make install" is done in btmp, it leaves a file called "install_manifest.txt" in the btmp directory owned by root. This causes a later non-sudo "make install" (where configuration has changed the destination directory to something that does not require sudo) to fail. Perhaps "make install" should remove install_manifest.txt in that case rather than failing? From d3ck0r at gmail.com Tue Apr 21 22:01:40 2015 From: d3ck0r at gmail.com (J Decker) Date: Tue, 21 Apr 2015 19:01:40 -0700 Subject: [CMake] Install( Targets ) loses executable permission Message-ID: Basically this is the command I use to install some plugins... BINARY_OUTPUT_DIR is ${CMAKE_INSTALL_PREFIX}/bin project_target is a argument to the macro and it's 'plugins' install( TARGETS ${proj} ? RUNTIME DESTINATION ${BINARY_OUTPUT_DIR}/${project_target} ? LIBRARY DESTINATION ${BINARY_OUTPUT_DIR}/${project_target} ? ARCHIVE DESTINATION lib? )? (expanded example) install( TARGETS tasks.isp ? RUNTIME DESTINATION bin/plugins LIBRARY DESTINATION bin/plugins ARCHIVE DESTINATION lib? )? This is basically the target defintiion.... add_library(tasks.isp SHARED ${SOURCES} ) SET_TARGET_PROPERTIES(tasks.isp PROPERTIES SUFFIX "" PREFIX "" ) ----- the library is built 'tasks.isp' with rwxr-xr-x but it's installed with rw-r--r-- (platform is rasberry pi) cmake version is 3.2.2 (custom build, version in apt-get is only 2.8 something) -------------- next part -------------- An HTML attachment was scrubbed... URL: From post at hendrik-sattler.de Wed Apr 22 00:21:23 2015 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Wed, 22 Apr 2015 06:21:23 +0200 Subject: [CMake] Install( Targets ) loses executable permission In-Reply-To: References: Message-ID: <3E8BDE9B-16A0-43EB-849C-8ED432443DDC@hendrik-sattler.de> Am 22. April 2015 04:01:40 MESZ, schrieb J Decker : >the library is built 'tasks.isp' with rwxr-xr-x >but it's installed with rw-r--r-- > >(platform is rasberry pi) Normal libraries on linux don't need any executable bit set. That the linker creates files with that permission has probably other reasons. HS From calebwherry at gmail.com Wed Apr 22 00:59:58 2015 From: calebwherry at gmail.com (J. Caleb Wherry) Date: Wed, 22 Apr 2015 00:59:58 -0400 Subject: [CMake] Install( Targets ) loses executable permission In-Reply-To: References: Message-ID: You can pass in the below variable to CMake (or set it in you CMake file) and you should get what you want: -DCMAKE_INSTALL_SO_NO_EXE=0 -Caleb On Tue, Apr 21, 2015 at 10:01 PM, J Decker wrote: > Basically this is the command I use to install some plugins... > BINARY_OUTPUT_DIR is ${CMAKE_INSTALL_PREFIX}/bin > project_target is a argument to the macro and it's 'plugins' > > > install( TARGETS ${proj} ? > RUNTIME DESTINATION ${BINARY_OUTPUT_DIR}/${project_target} ? > LIBRARY DESTINATION ${BINARY_OUTPUT_DIR}/${project_target} ? > ARCHIVE DESTINATION lib? > )? > > > (expanded example) > install( TARGETS tasks.isp ? > RUNTIME DESTINATION bin/plugins > LIBRARY DESTINATION bin/plugins > ARCHIVE DESTINATION lib? > )? > > This is basically the target defintiion.... > > add_library(tasks.isp SHARED ${SOURCES} ) > SET_TARGET_PROPERTIES(tasks.isp PROPERTIES > SUFFIX "" > PREFIX "" > ) > > > ----- > the library is built 'tasks.isp' with rwxr-xr-x > but it's installed with rw-r--r-- > > (platform is rasberry pi) > cmake version is 3.2.2 (custom build, version in apt-get is only 2.8 > something) > > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -- J. Caleb Wherry *Scientific Software Engineer* http://www.calebwherry.com +1 (615) 708-5651 calebwherry at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Wed Apr 22 01:02:36 2015 From: d3ck0r at gmail.com (J Decker) Date: Tue, 21 Apr 2015 22:02:36 -0700 Subject: [CMake] Install( Targets ) loses executable permission In-Reply-To: <3E8BDE9B-16A0-43EB-849C-8ED432443DDC@hendrik-sattler.de> References: <3E8BDE9B-16A0-43EB-849C-8ED432443DDC@hendrik-sattler.de> Message-ID: On Tue, Apr 21, 2015 at 9:21 PM, Hendrik Sattler wrote: > > > Am 22. April 2015 04:01:40 MESZ, schrieb J Decker : > >the library is built 'tasks.isp' with rwxr-xr-x > >but it's installed with rw-r--r-- > > > >(platform is rasberry pi) > > Normal libraries on linux don't need any executable bit set. That the > linker creates files with that permission has probably other reasons. > > Oh ya... on day I'll remember that :) > HS > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cjgoch+cmake at gmail.com Wed Apr 22 08:07:34 2015 From: cjgoch+cmake at gmail.com (Caspar Jonas Goch) Date: Wed, 22 Apr 2015 14:07:34 +0200 Subject: [CMake] Adding a dependency leads to dependency being build during ALL_BUILD even if neither target is part of it Message-ID: Dear all, in our project we have two sets of documentation, which are each their own custom target: Framework/Doc/CMakeLists.txt: add_custom_target(FrameworkDoc ${DOXYGEN} ${CMAKE_CURRENT_BINARY_DIR}/doxygen.conf WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR} ) Application/Doc/CMakeLists.txt: add_custom_target(doc ${DOXYGEN} ${CMAKE_CURRENT_BINARY_DIR}/doxygen.conf WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR} ) As building the documentation takes quite some time neither is part of the ALL target. With the above configuration building works as expected, each has to be build manually and the build works. However, the doc target needs the .tag file which is generated as part of FrameworkDoc. If I add a dependency: add_custom_target(doc ${DOXYGEN} ${CMAKE_CURRENT_BINARY_DIR}/doxygen.conf WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR} DEPENDS FrameworkDoc ) the FrameworkDoc target is being build every time I build the ALL target, instead of only if I build the doc target. I this behaviour intentional? Am I missing some option I should be using? Any advice is appreciated, Caspar -------------- next part -------------- An HTML attachment was scrubbed... URL: From t.err.a at yandex.ru Thu Apr 23 05:11:59 2015 From: t.err.a at yandex.ru (roman) Date: Thu, 23 Apr 2015 12:11:59 +0300 Subject: [CMake] CMake 3.2.2 generates too many virtual folders for Codeblocks project Message-ID: <5538B75F.3050704@yandex.ru> Hi, i have a project in the path D:\folder1\folder2\prj1, all sources and CMakeLists.txt are in this folder 'prj1'. CMake generates for the Codeblocks project file in which the source files are located in a virtual folders with the path not corresponding to the root folder of the project 'prj1'. For Codelite CMake generates normal path corresponding to the root folder of the project. So generated project tree in Codeblocks: | ||___CMakeFiles|| ||| |__[..]|| ||| | |__[..]|| ||| | |__[programms||]|| ||| | |__[cmake||]|| ||| | |__[share||]|| ||| | |__cmake-3.2|| ||| | |__[Modules||]|| ||| | |__||[Compiler||]|| ||| | | |__GNU-C.cmake|| ||| | | |__GNU-CXX.cmake|| ||| | | |__GNU.cmake|| ||| | | |__GNU.cmake|| ||| | ||| ||| | |_||_[Platform||]|| ||| | | |__Windows-GNU-C-ABI.cmake|| ||| | | |__ ..... cmake files||| || | ||| ||| | |__ ..... cmake files|| ||| |__CMakeList.txt|| ||||| |||||__[Sources]|| ||| |__[||folder1]|| ||| |__[folder2]|| ||| |__[prj1]|| ||| |__ .... '.cpp' files|| ||||| |||__[Headers]|| ||| |__[folder1]|| ||| |__[folder2]|| ||| |__[prj1]|| ||| |__ .... '.h' files|| ||||| |||__[Resources]|| || |__[folder1]|| || |__[folder2]|| || |__[prj1]|| || |__ resource.rc| Generated project tree in Codelite: ||||||||||| |||__[include]|| ||| |_||.... '.h' files|| |||||__[src]|| || |||__ .... '.cpp' files| Why such a difference? Is it possible to get CMake does not create extra virtual folders for Codeblocks project? CMakeLists.txt: |/# ????????? ???? ??? ????????? my_program// // //# ??????????? ?????? CMake, ?????? ??????.// //cmake_minimum_required( VERSION 2.8.4 )// // //# ????????????? ???????? ?????????? BIN// //set( BIN hisview_dev )// //# ??? ??????? ? ??? ????????????? ????? ?????????.// //project( ${BIN} )// // //# ????????? ???? ????? ??????????// //set ( CMAKE_CXX_FLAGS "-m32 -std=gnu++11" )// // //set(CMAKE_INSTALL_PREFIX $ENV{mybin})// //message (STATUS "CMAKE_INSTALL_PREFIX:" ${CMAKE_INSTALL_PREFIX})// // //# ????????? ???? ???????????? ????????? ??????????// //set (EXECUTABLE_OUTPUT_PATH $ENV{mybin})// // //# ???? ?? ?????????? ??? ???? ??? ???// //#set(CMAKE_RUNTIME_OUTPUT_DIRECTORY $ENV{PROJECTS_OUTPUT})// // //# ????????????? ???????? ???? ? ????? ? ??????????? ?????????.// //set( SOURCE_ROOT ${PROJECT_SOURCE_DIR} )// //message (STATUS "PROJECT_SOURCE_DIR:" ${PROJECT_SOURCE_DIR})// // //set(DEBEA_ROOT $ENV{DEBEA})// //file(TO_CMAKE_PATH ${DEBEA_ROOT} DEBEA_ROOT)// //message (STATUS "DEBEA_ROOT" ${DEBEA_ROOT})// //#STRING(REGEX REPLACE '\\' '/' TEST_VAR ${DEBEA_ROOT} )// //set(DEBEA_INCLUDE ${DEBEA_ROOT}/dba)// //message (STATUS "DEBEA_INCLUDE:" ${DEBEA_INCLUDE})// //set(DEBEA_LIB ${DEBEA_ROOT}/lib/gcc_static_mingw-w64-32)// // //# ?? ????????? ????? ?????? ? ??????????? ????? ??????????? ????.// //# ??????? aux_source_directory (??????????) ????????????? ?????????// //#(??????? ?? ????????? ????, ?????????? ????) ? ???????? ????? ????// //# ??????, ??????? ???????????? ??????????, ????? ??? .cpp, .cxx ? ?.?.// //# ? ????? ??????????? ?????? ???? ????????? ?????? ? ??????????? ? ??????????// //# SOURCES// //aux_source_directory( ${SOURCE_ROOT} SOURCES )// //message (STATUS "SOURCES:" ${SOURCES})// // //# ??? Windows ?? ???????? ????? ????????// //#message (STATUS "SRC:" ${SRC})// //if(WIN32)// // set(SRC ${SRC} ${SOURCE_ROOT}/resource.rc)// //endif(WIN32)// // //# ???????? ?????????????? ????? ? ??????// //# MainFrameBase.fbp - ?????? wxFormBlocks// //#set(SRC ${SRC} ${SOURCE_ROOT}/MainFrameBase.fbp ${SOURCE_ROOT}/wxsmith/MainFrameBase.wxs ${SOURCE_ROOT}/wx_pch.h)// // //# ???????? ?????? ?????? ???// //#source_group ("Headers" FILES ${HEADERS})// //#source_group ("Source Files" FILES ${SOURCES})// // //#?????????? wxWidgets// //find_package(wxWidgets COMPONENTS aui adv core base REQUIRED)// //if(wxWidgets_FOUND)// // INCLUDE_DIRECTORIES(${wxWidgets_INCLUDE_DIRS})// // include(${wxWidgets_USE_FILE})// //endif ()// // //include_directories(${DEBEA_ROOT})// //link_directories(${DEBEA_LIB})// // //set (REQUIRED_LIBRARIES ${REQUIRED_LIBRARIES} ${wxWidgets_LIBRARIES})// //message (STATUS lib: ${wxWidgets_LIBRARIES})// //# ???????? ??????????? ???? ? ?????? my_program.// //#add_executable( ${BIN} WIN32 ${SOURCES})// //add_library(dba STATIC IMPORTED)// //set_property(TARGET dba PROPERTY IMPORTED_LOCATION ${DEBEA_LIB}/libdba.a)// //add_executable( ${BIN} WIN32 ${SOURCES} ${SRC})// //# ????????? ????????? ????????? ? ???????????? ????????????? ????????????.// //#target_link_libraries(${BIN} ${wxWidgets_LIBRARIES})// //target_link_libraries( ${BIN} ${REQUIRED_LIBRARIES} dba)/| -------------- next part -------------- An HTML attachment was scrubbed... URL: From irwin at beluga.phys.uvic.ca Thu Apr 23 06:13:02 2015 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Thu, 23 Apr 2015 03:13:02 -0700 (PDT) Subject: [CMake] cmp0026, file(GENERATE...), and configure_file In-Reply-To: References: Message-ID: On 2015-04-21 15:54-0400 David Cole wrote: > I can only imagine that would cause IMMENSE problems. Good point about keeping backwards compatibility, but your shift key got stuck. :-) > > I depend on configure_file being an immediate action in many many many > places. (i.e. -- the very next line of code in my CMakeLists.txt file > can depend on the result of configure_file being on disk and up to > date at the moment of configure processing...) > > Now, having said that, I could imagine you may want to change *some* > configure_file calls to file(GENERATE calls. Or to enable @@ > substitution in something like an explicit configure_file(GENERATE > signature. I think your idea of configure_file(GENERATE...) (where configure_file occurs at configure-time without GENERATE to be backwards compatible, but it occurs at generate-time if the new GENERATE signature is used) is an excellent way to allow users to replace the current clumsiness that is required to configure a file with both @ symbols and generator expressions. And to repeat how bad that clumsiness is, two separate commands currently have to be used to do the job, and the syntax for those commands is very different from each other with one having input file first than output file and the other having those reversed with special labels for each! So having the possibility of replacing all that clumsiness with configure_file(GENERATE...) would be really nice. And no I don't have the C++ skills or knowledge of the internal workings of CMake to create a patch to implement that, but I hope a CMake developer is inspired to do that by this discussion. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From nilsgladitz at gmail.com Thu Apr 23 06:44:15 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 23 Apr 2015 12:44:15 +0200 Subject: [CMake] cmp0026, file(GENERATE...), and configure_file In-Reply-To: References: Message-ID: <5538CCFF.5040008@gmail.com> On 04/23/2015 12:13 PM, Alan W. Irwin wrote: > I think your idea of configure_file(GENERATE...) (where configure_file > occurs at configure-time without GENERATE to be backwards compatible, > but it occurs at generate-time if the new GENERATE signature is used) > is an excellent way to allow users to replace the current clumsiness > that is required to configure a file with both @ symbols and > generator expressions. I suppose for that to work configure_file() would have to either: 1. Store the values of all variables as they were set during the configure_file() call so that they can be expanded during generation. 2. Or perform variable substitution in-memory during the call and store the intermediate content for generator expressions substitution at generation time. 3. Or perform variable substitution during the call and store the intermediate content in a temporary file which then gets generator expression substitution at generation time. None of those sound really optimal. With 1. and 2. memory requirements might get out of hand. With 3. you are basically back to something that acts like a configure_file() + file(GENERATE) wrapper except that cmake now has to come up with temporary filenames. Nils From DLRdave at aol.com Thu Apr 23 06:47:24 2015 From: DLRdave at aol.com (David Cole) Date: Thu, 23 Apr 2015 06:47:24 -0400 Subject: [CMake] cmp0026, file(GENERATE...), and configure_file In-Reply-To: References: Message-ID: Should it be configure_file(GENERATE or file(CONFIGURE_AND_GENERATE ?? In the meantime, while it is certainly clumsy to do the two separate commands everywhere, you could write a CMake language function(configure_file_generate ...) that takes the same args as configure_file, but does the two step in its implementation. Then, at least, your clumsiness is reduced, and you can simply replace configure_file with configure_file_generate everywhere it is necessary. I would volunteer to take this on, but I'd be promising my time falsely. Perhaps another season... Cheers, David C. On Thu, Apr 23, 2015 at 6:13 AM, Alan W. Irwin wrote: > On 2015-04-21 15:54-0400 David Cole wrote: > >> I can only imagine that would cause IMMENSE problems. > > > Good point about keeping backwards compatibility, but your shift key > got stuck. :-) > >> >> I depend on configure_file being an immediate action in many many many >> places. (i.e. -- the very next line of code in my CMakeLists.txt file >> can depend on the result of configure_file being on disk and up to >> date at the moment of configure processing...) >> >> Now, having said that, I could imagine you may want to change *some* >> configure_file calls to file(GENERATE calls. Or to enable @@ >> substitution in something like an explicit configure_file(GENERATE >> signature. > > > I think your idea of configure_file(GENERATE...) (where configure_file > occurs at configure-time without GENERATE to be backwards compatible, > but it occurs at generate-time if the new GENERATE signature is used) > is an excellent way to allow users to replace the current clumsiness > that is required to configure a file with both @ symbols and > generator expressions. > > And to repeat how bad that clumsiness is, two separate commands > currently have to be used to do the job, and the syntax for those > commands is very different from each other with one having input file > first than output file and the other having those reversed with > special labels for each! So having the possibility of replacing all > that clumsiness with configure_file(GENERATE...) would be really nice. > > And no I don't have the C++ skills or knowledge of the internal > workings of CMake to create a patch to implement that, but I hope a > CMake developer is inspired to do that by this discussion. > > > Alan > > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state > implementation for stellar interiors (freeeos.sf.net); the Time > Ephemerides project (timeephem.sf.net); PLplot scientific plotting > software package (plplot.sf.net); the libLASi project > (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); > and the Linux Brochure Project (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ From cedric.doucet at inria.fr Thu Apr 23 06:57:50 2015 From: cedric.doucet at inria.fr (Cedric Doucet) Date: Thu, 23 Apr 2015 12:57:50 +0200 (CEST) Subject: [CMake] Don't download external projects again after calling "make clean" In-Reply-To: References: <1351653491.156868.1428915508943.JavaMail.zimbra@inria.fr> <1121188496.1727145.1429248723887.JavaMail.zimbra@inria.fr> <1544359461.2146552.1429354828753.JavaMail.zimbra@inria.fr> <871275596.2148003.1429357111569.JavaMail.zimbra@inria.fr> <1588572917.2149426.1429359332478.JavaMail.zimbra@inria.fr> Message-ID: <1295666502.746483.1429786670655.JavaMail.zimbra@inria.fr> Hello David, I am using CMake 3.2.2. I installed CMake from the sources because I use "modules" to manage my libraries. But it's ok now: I modified the installation so that to support https. Unfortunately, I still have a problem. :( Maybe you could help me! Here is my CMakeLists.txt: ============= cmake_minimum_required (VERSION 2.6) project (example CXX) set(CMAKE_VERBOSE_MAKEFILE ON) include(ProcessorCount) ProcessorCount(N) if(NOT N EQUAL 0) set(CMAKE_BUILD_FLAGS -j${N}) endif() include(ExternalProject) set(EXTERNAL_DIR /home/cdoucet/Downloads) ExternalProject_Add(eigen PREFIX ${EXTERNAL_DIR}/eigen DOWNLOAD_DIR ${EXTERNAL_DIR}/eigen/download SOURCE_DIR ${EXTERNAL_DIR}/eigen/src BINARY_DIR ${EXTERNAL_DIR}/eigen/build INSTALL_DIR ${EXTERNAL_DIR}/eigen/install URL http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz URL_MD5 4d0d77e06fef87b4fcd2c9b72cc8dc55 CONFIGURE_COMMAND cd && cmake -D CMAKE_INSTALL_PREFIX=$ ) ============= And here is the error message: ===================== /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -H/home/cdoucet/Documents/exemples/cmake/external_project/eigen -B/home/cdoucet/Documents/exemples/cmake/external_project/eigen/build --check-build-system CMakeFiles/Makefile.cmake 0 /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E cmake_progress_start /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/CMakeFiles /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/CMakeFiles/progress.marks make -f CMakeFiles/Makefile2 all make[1]: entrant dans le r?pertoire ? /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? make -f CMakeFiles/eigen.dir/build.make CMakeFiles/eigen.dir/depend make[2]: entrant dans le r?pertoire ? /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? cd /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build && /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E cmake_depends "Unix Makefiles" /home/cdoucet/Documents/exemples/cmake/external_project/eigen /home/cdoucet/Documents/exemples/cmake/external_project/eigen /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/CMakeFiles/eigen.dir/DependInfo.cmake --color= make[2]: quittant le r?pertoire ? /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? make -f CMakeFiles/eigen.dir/build.make CMakeFiles/eigen.dir/build make[2]: entrant dans le r?pertoire ? /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E cmake_progress_report /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/CMakeFiles 3 [ 12%] Creating directories for 'eigen' /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory /home/cdoucet/Downloads/eigen/src /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory /home/cdoucet/Downloads/eigen/build /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory /home/cdoucet/Downloads/eigen/install /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory /home/cdoucet/Downloads/eigen/tmp /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory /home/cdoucet/Downloads/eigen/src/eigen-stamp /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory /home/cdoucet/Downloads/eigen/download /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E touch /home/cdoucet/Downloads/eigen/src/eigen-stamp/eigen-mkdir /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E cmake_progress_report /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/CMakeFiles 4 [ 25%] Performing download step (download, verify and extract) for 'eigen' cd /home/cdoucet/Downloads/eigen && /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -P /home/cdoucet/Downloads/eigen/src/eigen-stamp/download-eigen.cmake -- downloading... src='http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz' dst='/home/cdoucet/Downloads/eigen/download/3.2.4.tar.gz' timeout='none' -- [download 100% complete] -- [download 0% complete] -- [download 1% complete] -- [download 2% complete] -- [download 3% complete] -- [download 4% complete] -- [download 5% complete] -- [download 7% complete] -- [download 8% complete] -- [download 9% complete] -- [download 10% complete] -- [download 11% complete] -- [download 12% complete] -- [download 13% complete] -- [download 14% complete] -- [download 15% complete] -- [download 17% complete] -- [download 18% complete] -- [download 19% complete] -- [download 20% complete] -- [download 21% complete] -- [download 22% complete] -- [download 23% complete] -- [download 24% complete] -- [download 25% complete] -- [download 27% complete] -- [download 28% complete] -- [download 29% complete] -- [download 30% complete] -- [download 31% complete] -- [download 32% complete] -- [download 33% complete] -- [download 34% complete] -- [download 35% complete] -- [download 36% complete] -- [download 38% complete] -- [download 39% complete] -- [download 40% complete] -- [download 41% complete] -- [download 42% complete] -- [download 43% complete] -- [download 44% complete] -- [download 45% complete] -- [download 46% complete] -- [download 48% complete] -- [download 49% complete] -- [download 50% complete] -- [download 51% complete] -- [download 52% complete] -- [download 53% complete] -- [download 54% complete] -- [download 55% complete] -- [download 56% complete] -- [download 57% complete] -- [download 59% complete] -- [download 60% complete] -- [download 61% complete] -- [download 62% complete] -- [download 63% complete] -- [download 64% complete] -- [download 65% complete] -- [download 66% complete] -- [download 67% complete] -- [download 69% complete] -- [download 70% complete] -- [download 71% complete] -- [download 72% complete] -- [download 73% complete] -- [download 74% complete] -- [download 75% complete] -- [download 76% complete] -- [download 77% complete] -- [download 78% complete] -- [download 80% complete] -- [download 81% complete] -- [download 82% complete] -- [download 83% complete] -- [download 84% complete] -- [download 85% complete] -- [download 86% complete] -- [download 87% complete] -- [download 88% complete] -- [download 90% complete] -- [download 91% complete] -- [download 92% complete] -- [download 93% complete] -- [download 94% complete] -- [download 95% complete] -- [download 96% complete] -- [download 97% complete] -- [download 98% complete] -- [download 99% complete] -- [download 100% complete] -- downloading... done cd /home/cdoucet/Downloads/eigen && /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -P /home/cdoucet/Downloads/eigen/src/eigen-stamp/verify-eigen.cmake -- verifying file... file='/home/cdoucet/Downloads/eigen/download/3.2.4.tar.gz' -- verifying file... done cd /home/cdoucet/Downloads/eigen && /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -P /home/cdoucet/Downloads/eigen/src/eigen-stamp/extract-eigen.cmake -- extracting... src='/home/cdoucet/Downloads/eigen/download/3.2.4.tar.gz' dst='/home/cdoucet/Downloads/eigen/src' -- extracting... [tar xfz] -- extracting... [analysis] -- extracting... [rename] -- extracting... [clean up] -- extracting... done cd /home/cdoucet/Downloads/eigen && /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E touch /home/cdoucet/Downloads/eigen/src/eigen-stamp/eigen-download make[2]: *** [/home/cdoucet/Downloads/eigen/src/eigen-stamp/eigen-download] Erreur 1 make[2]: quittant le r?pertoire ? /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? make[1]: *** [CMakeFiles/eigen.dir/all] Erreur 2 make[1]: quittant le r?pertoire ? /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? make: *** [all] Erreur 2 ===================== ----- Mail original ----- > De: "David Cole" > ?: "Cedric Doucet" > Cc: cmake at cmake.org > Envoy?: Samedi 18 Avril 2015 20:39:57 > Objet: Re: [CMake] Don't download external projects again after calling "make > clean" > What version of CMake are you using? All the modern pre-built CMake > installations should support https without extra effort on your part. Are > you using a pre-built version from somewhere or are you building CMake > yourself? > On Saturday, April 18, 2015, Cedric Doucet < cedric.doucet at inria.fr > wrote: > > Ok it seems the answer to my problem is here: > > > http://www.cmake.org/pipermail/cmake/2010-December/041295.html > > > I will try it. > > > ----- Mail original ----- > > > > De: "Cedric Doucet" < cedric.doucet at inria.fr > > > > > ?: cmake at cmake.org > > > > Envoy?: Samedi 18 Avril 2015 13:38:31 > > > > Objet: Re: [CMake] Don't download external projects again after calling > > > "make clean" > > > > > > > > > > > > I have just tried to install curl to get https support. > > > > To do that, I have followed the steps below: > > > > > > > > 1. Installation of openssl: > > > > 1.a. ./config --prefix=/my/openssl/path > > > > 1.b. make > > > > 1.c. make test > > > > 1.d. make install > > > > 2. Installation of curl > > > > 2.a. ./configure --prefix=/my/curl/path --with-ssl=/my/openssl/path/lib > > > > 2.b. make > > > > 2.c. make install > > > > > > > > I have also prepend PATH with /my/curl/path/bin. > > > > However, the error remains. > > > > It seems that my version of curl (7.41.0) is not taken into acount > > > because > > > I > > > > have still this line in the error message: > > > > User-Agent: curl/7.38.0 > > > > I tried to remove all previous of curl and libcurl but it does not change > > > > anything. > > > > > > > > Could you help me? > > > > > > > > C?dric > > > > > > > > > > > > ----- Mail original ----- > > > > > De: "Cedric Doucet" < cedric.doucet at inria.fr > > > > > > ?: "David Cole" < DLRdave at aol.com > > > > > > Cc: cmake at cmake.org > > > > > Envoy?: Samedi 18 Avril 2015 13:00:28 > > > > > Objet: Re: [CMake] Don't download external projects again after calling > > > > > "make clean" > > > > > > > > > > > > > > > Hello David, > > > > > > > > > > thank you very much. > > > > > Unfortunately, I get the following error message if I remove my > > > > download > > > > > command: > > > > > > > > > > -- downloading... > > > > > src=' http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz ' > > > > > dst='/home/cdoucet/Downloads/eigen/download/3.2.4.tar.gz' > > > > > timeout='none' > > > > > -- [download 100% complete] > > > > > CMake Error at src/eigen-stamp/download-eigen.cmake:27 (message): > > > > > error: downloading ' http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz > > > > ' > > > > > failed > > > > > > > > > > status_code: 1 > > > > > status_string: "Unsupported protocol" > > > > > log: Hostname was NOT found in DNS cache > > > > > Trying 131.103.20.167... > > > > > > > > > > Connected to bitbucket.org (131.103.20.167) port 80 (#0) > > > > > > > > > > GET /eigen/eigen/get/3.2.4.tar.gz HTTP/1.1 > > > > > > > > > > User-Agent: curl/7.38.0 > > > > > > > > > > Host: bitbucket.org > > > > > > > > > > Accept: */* > > > > > > > > > > > > > > > > > > > > HTTP/1.1 301 Moved Permanently > > > > > > > > > > Server nginx/1.6.2 is not blacklisted > > > > > > > > > > Server: nginx/1.6.2 > > > > > > > > > > Date: Sat, 18 Apr 2015 10:55:20 GMT > > > > > > > > > > Content-Type: text/html > > > > > > > > > > Content-Length: 184 > > > > > > > > > > Location: https://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz > > > > > > > > > > > > > > > > > > > > Ignoring the response-body > > > > > > > > > > > > > > > > > > > > 301 Moved Permanently > > > > > > > > > > > > > > > > > > > >

301 Moved Permanently

> > > > > > > > > >
nginx/1.6.2
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Connection #0 to host bitbucket.org left intact > > > > > > > > > > Issue another request to this URL: > > > > > ' https://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz ' > > > > > > > > > > Protocol "https" not supported or disabled in libcurl > > > > > > > > > > Closing connection -1 > > > > > > > > > > > > > > > > > > > > > > > > > ----- Mail original ----- > > > > > > De: "David Cole" < DLRdave at aol.com > > > > > > > ?: "Cedric Doucet" < cedric.doucet at inria.fr > > > > > > > Cc: cmake at cmake.org > > > > > > Envoy?: Vendredi 17 Avril 2015 13:21:08 > > > > > > Objet: Re: [CMake] Don't download external projects again after > > > > > calling > > > > > > "make clean" > > > > > > > > > > > > Eliminate your DOWNLOAD_COMMAND. CMake knows how to do it with just > > > > > > the URL_MD5, DOWNLOAD_DIR and SOURCE_DIR information.... > > > > > > > > > > > > HTH, > > > > > > David > > > > > > > > > > > > > > > > > > On Fri, Apr 17, 2015 at 1:32 AM, Cedric Doucet < > > > > > cedric.doucet at inria.fr > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > Hello David, > > > > > > > > > > > > > > thank you very much for your help. > > > > > > > > > > > > > > Unfortunately I may do something wrong because it does not work. > > > > > > > After cleaning, the library is downloaded again. > > > > > > > > > > > > > > I guess my mistake comes from the fact I do not understand the role > > > > > > of > > > > > > > URL_MD5. > > > > > > > Below is a simple example where downloading and installing is very > > > > > > > fast. > > > > > > > You just have to replace the value of EXTERNAL_DIR by the path to > > > > > > your > > > > > > > own > > > > > > > "Downloads" repository. > > > > > > > I tried to put URL in my DOWNLOAD_COMMAND but the call "wget " > > > > > > > does > > > > > > > not seem to be understood by the wget command. > > > > > > > > > > > > > > Thanks again! > > > > > > > > > > > > > > C?dric > > > > > > > > > > > > > > -------------------------------------------------------------------------- > > > > > > > cmake_minimum_required (VERSION 2.6) > > > > > > > > > > > > > > project (example CXX) > > > > > > > > > > > > > > set(CMAKE_VERBOSE_MAKEFILE ON) > > > > > > > > > > > > > > include(ProcessorCount) > > > > > > > ProcessorCount(N) > > > > > > > if(NOT N EQUAL 0) > > > > > > > set(CMAKE_BUILD_FLAGS -j${N}) > > > > > > > endif() > > > > > > > > > > > > > > include(ExternalProject) > > > > > > > set(EXTERNAL_DIR /home/cdoucet/Downloads) > > > > > > > ExternalProject_Add(eigen > > > > > > > PREFIX ${EXTERNAL_DIR}/eigen > > > > > > > DOWNLOAD_DIR ${EXTERNAL_DIR}/eigen/download > > > > > > > SOURCE_DIR ${EXTERNAL_DIR}/eigen/src > > > > > > > BINARY_DIR ${EXTERNAL_DIR}/eigen/build > > > > > > > INSTALL_DIR ${EXTERNAL_DIR}/eigen/install > > > > > > > URL > > > > > > > http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz > > > > > > > URL_MD5 ccb18a771f678b38a3d33c321a8e7daf > > > > > > > DOWNLOAD_COMMAND wget > > > > > > > http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz > > > > > > > && > > > > > > > tar xvzf 3.2.4.tar.gz -C > > > > > > > --strip-components=1 > > > > > > > CONFIGURE_COMMAND cd && cmake -D > > > > > > > CMAKE_INSTALL_PREFIX=$ > > > > > > > ) > > > > > > > ------------------------------------------------------------------------------ > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Mail original ----- > > > > > > >> De: "David Cole" < DLRdave at aol.com > > > > > > > >> ?: "Cedric Doucet" < cedric.doucet at inria.fr > > > > > > > >> Cc: cmake at cmake.org > > > > > > >> Envoy?: Lundi 13 Avril 2015 12:40:34 > > > > > > >> Objet: Re: [CMake] Don't download external projects again after > > > > > > >> calling > > > > > > >> "make clean" > > > > > > >> > > > > > > >> Use the URL_MD5 and DOWNLOAD_DIR arguments to ExternalProject_Add > > > > > >> to > > > > > > >> put the downloaded files into a location outside the build tree > > > > > > >> (perhaps ~/Downloads on Mac/Linux or $ENV{USERPROFILE}/Downloads > > > > > >> on > > > > > > >> Windows). > > > > > > >> > > > > > > >> With DOWNLOAD_DIR outside the build tree, and the checksums of the > > > > > > >> downloaded files being the same as you've specified via URL_MD5, > > > > > >> the > > > > > > >> download portion will be avoided once there is a local copy of a > > > > > >> file > > > > > > >> available. > > > > > > >> > > > > > > >> > > > > > > >> HTH, > > > > > > >> David C. > > > > > > >> > > > > > > >> > > > > > > >> On Mon, Apr 13, 2015 at 5:04 AM, Cedric Doucet > > > > > > >> < cedric.doucet at inria.fr > > > > > > > >> wrote: > > > > > > >> > > > > > > > >> > Hello! > > > > > > >> > > > > > > > >> > I use the ExternalProject_Add function to download third-party > > > > > > >> > libraries > > > > > > >> > of > > > > > > >> > a code. > > > > > > >> > > > > > > > >> > Once a library has been downloaded, I can call "make" as many > > > > > >> > times > > > > > > >> > as > > > > > > >> > I > > > > > > >> > want without downloading this library again. > > > > > > >> > It seems that CMake detects that the library has already been > > > > > > >> > downloaded. > > > > > > >> > > > > > > > >> > However, calling "make clean" seems to destroy this feature. > > > > > > >> > Even if my library is not uninstalled during cleaning, calling > > > > > > >> > "make" > > > > > > >> > after > > > > > > >> > "make clean" will lead CMake to try download the library again. > > > > > > >> > > > > > > > >> > How could I tell CMake not to download the library again? > > > > > > >> > > > > > > > >> > Thank you very much for your help! > > > > > > >> > > > > > > > >> > C?dric > > > > > > >> > > > > > > > >> > -- > > > > > > >> > > > > > > > >> > Powered by www.kitware.com > > > > > > >> > > > > > > > >> > Please keep messages on-topic and check the CMake FAQ at: > > > > > > >> > http://www.cmake.org/Wiki/CMake_FAQ > > > > > > >> > > > > > > > >> > Kitware offers various services to support the CMake community. > > > > > >> > For > > > > > > >> > more > > > > > > >> > information on each offering, please visit: > > > > > > >> > > > > > > > >> > CMake Support: http://cmake.org/cmake/help/support.html > > > > > > >> > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > > > > > >> > CMake Training Courses: > > > > > >> > http://cmake.org/cmake/help/training.html > > > > > > >> > > > > > > > >> > Visit other Kitware open-source projects at > > > > > > >> > http://www.kitware.com/opensource/opensource.html > > > > > > >> > > > > > > > >> > Follow this link to subscribe/unsubscribe: > > > > > > >> > http://public.kitware.com/mailman/listinfo/cmake > > > > > > >> > > > > > > > > > > > -- > > > > > > > > > > Powered by www.kitware.com > > > > > > > > > > Please keep messages on-topic and check the CMake FAQ at: > > > > > http://www.cmake.org/Wiki/CMake_FAQ > > > > > > > > > > Kitware offers various services to support the CMake community. For > > > > more > > > > > information on each offering, please visit: > > > > > > > > > > CMake Support: http://cmake.org/cmake/help/support.html > > > > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > > > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > > > > > > > > Visit other Kitware open-source projects at > > > > > http://www.kitware.com/opensource/opensource.html > > > > > > > > > > Follow this link to subscribe/unsubscribe: > > > > > http://public.kitware.com/mailman/listinfo/cmake > > > > > > > > > -- > > > > > > > > Powered by www.kitware.com > > > > > > > > Please keep messages on-topic and check the CMake FAQ at: > > > > http://www.cmake.org/Wiki/CMake_FAQ > > > > > > > > Kitware offers various services to support the CMake community. For more > > > > information on each offering, please visit: > > > > > > > > CMake Support: http://cmake.org/cmake/help/support.html > > > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > > > > > > Visit other Kitware open-source projects at > > > > http://www.kitware.com/opensource/opensource.html > > > > > > > > Follow this link to subscribe/unsubscribe: > > > > http://public.kitware.com/mailman/listinfo/cmake > > > > > > > -- > > > Powered by www.kitware.com > > > Please keep messages on-topic and check the CMake FAQ at: > > http://www.cmake.org/Wiki/CMake_FAQ > > > Kitware offers various services to support the CMake community. For more > > information on each offering, please visit: > > > CMake Support: http://cmake.org/cmake/help/support.html > > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > Visit other Kitware 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 Thu Apr 23 07:00:14 2015 From: DLRdave at aol.com (David Cole) Date: Thu, 23 Apr 2015 07:00:14 -0400 Subject: [CMake] cmp0026, file(GENERATE...), and configure_file In-Reply-To: <5538CCFF.5040008@gmail.com> References: <5538CCFF.5040008@gmail.com> Message-ID: There's also a fourth possibility: 4. Delay the configure processing for these "configure and generate" files with the final variable values at the END of the configure (*at* generate time). Then there are no memory or temp file issues, but you have a mismatch with the existing (and reasonably expected) behavior of configure_file which does immediate processing. That would be inconvenient, if not impossible, for folks to use predictably from the scope of sub-directories. Seems we have not stumbled upon the win-win idea yet... D On Thu, Apr 23, 2015 at 6:44 AM, Nils Gladitz wrote: > On 04/23/2015 12:13 PM, Alan W. Irwin wrote: >> >> I think your idea of configure_file(GENERATE...) (where configure_file >> occurs at configure-time without GENERATE to be backwards compatible, >> but it occurs at generate-time if the new GENERATE signature is used) >> is an excellent way to allow users to replace the current clumsiness >> that is required to configure a file with both @ symbols and >> generator expressions. > > > I suppose for that to work configure_file() would have to either: > > 1. Store the values of all variables as they were set during the > configure_file() call so that they can be expanded during generation. > > 2. Or perform variable substitution in-memory during the call and store the > intermediate content for generator expressions substitution at generation > time. > > 3. Or perform variable substitution during the call and store the > intermediate content in a temporary file which then gets generator > expression substitution at generation time. > > None of those sound really optimal. > > With 1. and 2. memory requirements might get out of hand. > > With 3. you are basically back to something that acts like a > configure_file() + file(GENERATE) wrapper except that cmake now has to come > up with temporary filenames. > > Nils From DLRdave at aol.com Thu Apr 23 07:14:35 2015 From: DLRdave at aol.com (David Cole) Date: Thu, 23 Apr 2015 07:14:35 -0400 Subject: [CMake] Don't download external projects again after calling "make clean" In-Reply-To: <1295666502.746483.1429786670655.JavaMail.zimbra@inria.fr> References: <1351653491.156868.1428915508943.JavaMail.zimbra@inria.fr> <1121188496.1727145.1429248723887.JavaMail.zimbra@inria.fr> <1544359461.2146552.1429354828753.JavaMail.zimbra@inria.fr> <871275596.2148003.1429357111569.JavaMail.zimbra@inria.fr> <1588572917.2149426.1429359332478.JavaMail.zimbra@inria.fr> <1295666502.746483.1429786670655.JavaMail.zimbra@inria.fr> Message-ID: I don't understand what the error is here, but here are some comments: (1) CMAKE_INSTALL_PREFIX=$ The $ is unnecessary and incorrect in this context. The literal string is the thing that ExternalProject will substitute when it is processed into custom commands... (2) ONLY the DOWNLOAD_DIR parameter should be in an "external" (outside of your build tree) directory, to avoid re-downloading the exact same tar.gz file over and over again. The source tree and the build tree of the project should be in your build tree somewhere. (3) CONFIGURE_COMMAND cd && cmake should be unnecessary... The configure command is run in the binary dir by default. Instead, you should be able to use: CMAKE_ARGS -D CMAKE_INSTALL_PREFIX= The binary dir is the working directory for configure, build and install commands. And the is added automatically when you use CMAKE_ARGS with the default cmake CONFIGURE_COMMAND rather than specifying your own. Make those changes and try again with one more fresh build (i.e. -- blow away the whole /home/cdoucet/Downloads/eigen directory and start clean...) Let us know if you still have an error after making those changes. HTH, David C. On Thu, Apr 23, 2015 at 6:57 AM, Cedric Doucet wrote: > Hello David, > > I am using CMake 3.2.2. > I installed CMake from the sources because I use "modules" to manage my > libraries. > But it's ok now: I modified the installation so that to support https. > > Unfortunately, I still have a problem. :( > Maybe you could help me! > > Here is my CMakeLists.txt: > > ============= > > cmake_minimum_required (VERSION 2.6) > > project (example CXX) > > set(CMAKE_VERBOSE_MAKEFILE ON) > > include(ProcessorCount) > ProcessorCount(N) > if(NOT N EQUAL 0) > set(CMAKE_BUILD_FLAGS -j${N}) > endif() > > include(ExternalProject) > set(EXTERNAL_DIR /home/cdoucet/Downloads) > ExternalProject_Add(eigen > PREFIX ${EXTERNAL_DIR}/eigen > DOWNLOAD_DIR > ${EXTERNAL_DIR}/eigen/download > SOURCE_DIR ${EXTERNAL_DIR}/eigen/src > BINARY_DIR ${EXTERNAL_DIR}/eigen/build > INSTALL_DIR ${EXTERNAL_DIR}/eigen/install > URL > http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz > URL_MD5 4d0d77e06fef87b4fcd2c9b72cc8dc55 > CONFIGURE_COMMAND cd && > cmake -D CMAKE_INSTALL_PREFIX=$ > ) > > ============= > > And here is the error message: > > ===================== > > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake > -H/home/cdoucet/Documents/exemples/cmake/external_project/eigen > -B/home/cdoucet/Documents/exemples/cmake/external_project/eigen/build > --check-build-system CMakeFiles/Makefile.cmake 0 > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E cmake_progress_start > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/CMakeFiles > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/CMakeFiles/progress.marks > make -f CMakeFiles/Makefile2 all > make[1]: entrant dans le r?pertoire ? > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? > make -f CMakeFiles/eigen.dir/build.make CMakeFiles/eigen.dir/depend > make[2]: entrant dans le r?pertoire ? > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? > cd /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build && > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E cmake_depends "Unix > Makefiles" /home/cdoucet/Documents/exemples/cmake/external_project/eigen > /home/cdoucet/Documents/exemples/cmake/external_project/eigen > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/CMakeFiles/eigen.dir/DependInfo.cmake > --color= > make[2]: quittant le r?pertoire ? > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? > make -f CMakeFiles/eigen.dir/build.make CMakeFiles/eigen.dir/build > make[2]: entrant dans le r?pertoire ? > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E cmake_progress_report > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/CMakeFiles > 3 > [ 12%] Creating directories for 'eigen' > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory > /home/cdoucet/Downloads/eigen/src > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory > /home/cdoucet/Downloads/eigen/build > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory > /home/cdoucet/Downloads/eigen/install > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory > /home/cdoucet/Downloads/eigen/tmp > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory > /home/cdoucet/Downloads/eigen/src/eigen-stamp > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory > /home/cdoucet/Downloads/eigen/download > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E touch > /home/cdoucet/Downloads/eigen/src/eigen-stamp/eigen-mkdir > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E cmake_progress_report > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/CMakeFiles > 4 > [ 25%] Performing download step (download, verify and extract) for 'eigen' > cd /home/cdoucet/Downloads/eigen && > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -P > /home/cdoucet/Downloads/eigen/src/eigen-stamp/download-eigen.cmake > -- downloading... > src='http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz' > dst='/home/cdoucet/Downloads/eigen/download/3.2.4.tar.gz' > timeout='none' > -- [download 100% complete] > -- [download 0% complete] > -- [download 1% complete] > -- [download 2% complete] > -- [download 3% complete] > -- [download 4% complete] > -- [download 5% complete] > -- [download 7% complete] > -- [download 8% complete] > -- [download 9% complete] > -- [download 10% complete] > -- [download 11% complete] > -- [download 12% complete] > -- [download 13% complete] > -- [download 14% complete] > -- [download 15% complete] > -- [download 17% complete] > -- [download 18% complete] > -- [download 19% complete] > -- [download 20% complete] > -- [download 21% complete] > -- [download 22% complete] > -- [download 23% complete] > -- [download 24% complete] > -- [download 25% complete] > -- [download 27% complete] > -- [download 28% complete] > -- [download 29% complete] > -- [download 30% complete] > -- [download 31% complete] > -- [download 32% complete] > -- [download 33% complete] > -- [download 34% complete] > -- [download 35% complete] > -- [download 36% complete] > -- [download 38% complete] > -- [download 39% complete] > -- [download 40% complete] > -- [download 41% complete] > -- [download 42% complete] > -- [download 43% complete] > -- [download 44% complete] > -- [download 45% complete] > -- [download 46% complete] > -- [download 48% complete] > -- [download 49% complete] > -- [download 50% complete] > -- [download 51% complete] > -- [download 52% complete] > -- [download 53% complete] > -- [download 54% complete] > -- [download 55% complete] > -- [download 56% complete] > -- [download 57% complete] > -- [download 59% complete] > -- [download 60% complete] > -- [download 61% complete] > -- [download 62% complete] > -- [download 63% complete] > -- [download 64% complete] > -- [download 65% complete] > -- [download 66% complete] > -- [download 67% complete] > -- [download 69% complete] > -- [download 70% complete] > -- [download 71% complete] > -- [download 72% complete] > -- [download 73% complete] > -- [download 74% complete] > -- [download 75% complete] > -- [download 76% complete] > -- [download 77% complete] > -- [download 78% complete] > -- [download 80% complete] > -- [download 81% complete] > -- [download 82% complete] > -- [download 83% complete] > -- [download 84% complete] > -- [download 85% complete] > -- [download 86% complete] > -- [download 87% complete] > -- [download 88% complete] > -- [download 90% complete] > -- [download 91% complete] > -- [download 92% complete] > -- [download 93% complete] > -- [download 94% complete] > -- [download 95% complete] > -- [download 96% complete] > -- [download 97% complete] > -- [download 98% complete] > -- [download 99% complete] > -- [download 100% complete] > -- downloading... done > cd /home/cdoucet/Downloads/eigen && > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -P > /home/cdoucet/Downloads/eigen/src/eigen-stamp/verify-eigen.cmake > -- verifying file... > file='/home/cdoucet/Downloads/eigen/download/3.2.4.tar.gz' > -- verifying file... done > cd /home/cdoucet/Downloads/eigen && > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -P > /home/cdoucet/Downloads/eigen/src/eigen-stamp/extract-eigen.cmake > -- extracting... > src='/home/cdoucet/Downloads/eigen/download/3.2.4.tar.gz' > dst='/home/cdoucet/Downloads/eigen/src' > -- extracting... [tar xfz] > -- extracting... [analysis] > -- extracting... [rename] > -- extracting... [clean up] > -- extracting... done > cd /home/cdoucet/Downloads/eigen && > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E touch > /home/cdoucet/Downloads/eigen/src/eigen-stamp/eigen-download > make[2]: *** [/home/cdoucet/Downloads/eigen/src/eigen-stamp/eigen-download] > Erreur 1 > make[2]: quittant le r?pertoire ? > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? > make[1]: *** [CMakeFiles/eigen.dir/all] Erreur 2 > make[1]: quittant le r?pertoire ? > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? > make: *** [all] Erreur 2 > > ===================== > > > > ________________________________ > > De: "David Cole" > ?: "Cedric Doucet" > Cc: cmake at cmake.org > Envoy?: Samedi 18 Avril 2015 20:39:57 > > Objet: Re: [CMake] Don't download external projects again after calling > "make clean" > > What version of CMake are you using? All the modern pre-built CMake > installations should support https without extra effort on your part. Are > you using a pre-built version from somewhere or are you building CMake > yourself? > > > On Saturday, April 18, 2015, Cedric Doucet wrote: >> >> >> Ok it seems the answer to my problem is here: >> http://www.cmake.org/pipermail/cmake/2010-December/041295.html >> I will try it. >> >> ----- Mail original ----- >> > De: "Cedric Doucet" >> > ?: cmake at cmake.org >> > Envoy?: Samedi 18 Avril 2015 13:38:31 >> > Objet: Re: [CMake] Don't download external projects again after calling >> > "make clean" >> > >> > >> > I have just tried to install curl to get https support. >> > To do that, I have followed the steps below: >> > >> > 1. Installation of openssl: >> > 1.a. ./config --prefix=/my/openssl/path >> > 1.b. make >> > 1.c. make test >> > 1.d. make install >> > 2. Installation of curl >> > 2.a. ./configure --prefix=/my/curl/path >> > --with-ssl=/my/openssl/path/lib >> > 2.b. make >> > 2.c. make install >> > >> > I have also prepend PATH with /my/curl/path/bin. >> > However, the error remains. >> > It seems that my version of curl (7.41.0) is not taken into acount >> > because I >> > have still this line in the error message: >> > User-Agent: curl/7.38.0 >> > I tried to remove all previous of curl and libcurl but it does not >> > change >> > anything. >> > >> > Could you help me? >> > >> > C?dric >> > >> > >> > ----- Mail original ----- >> > > De: "Cedric Doucet" >> > > ?: "David Cole" >> > > Cc: cmake at cmake.org >> > > Envoy?: Samedi 18 Avril 2015 13:00:28 >> > > Objet: Re: [CMake] Don't download external projects again after >> > > calling >> > > "make clean" >> > > >> > > >> > > Hello David, >> > > >> > > thank you very much. >> > > Unfortunately, I get the following error message if I remove my >> > > download >> > > command: >> > > >> > > -- downloading... >> > > src='http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz' >> > > dst='/home/cdoucet/Downloads/eigen/download/3.2.4.tar.gz' >> > > timeout='none' >> > > -- [download 100% complete] >> > > CMake Error at src/eigen-stamp/download-eigen.cmake:27 (message): >> > > error: downloading >> > > 'http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz' >> > > failed >> > > >> > > status_code: 1 >> > > status_string: "Unsupported protocol" >> > > log: Hostname was NOT found in DNS cache >> > > Trying 131.103.20.167... >> > > >> > > Connected to bitbucket.org (131.103.20.167) port 80 (#0) >> > > >> > > GET /eigen/eigen/get/3.2.4.tar.gz HTTP/1.1 >> > > >> > > User-Agent: curl/7.38.0 >> > > >> > > Host: bitbucket.org >> > > >> > > Accept: */* >> > > >> > > >> > > >> > > HTTP/1.1 301 Moved Permanently >> > > >> > > Server nginx/1.6.2 is not blacklisted >> > > >> > > Server: nginx/1.6.2 >> > > >> > > Date: Sat, 18 Apr 2015 10:55:20 GMT >> > > >> > > Content-Type: text/html >> > > >> > > Content-Length: 184 >> > > >> > > Location: https://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz >> > > >> > > >> > > >> > > Ignoring the response-body >> > > >> > > >> > > >> > > 301 Moved Permanently >> > > >> > > >> > > >> > >

301 Moved Permanently

>> > > >> > >
nginx/1.6.2
>> > > >> > > >> > > >> > > >> > > >> > > Connection #0 to host bitbucket.org left intact >> > > >> > > Issue another request to this URL: >> > > 'https://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz' >> > > >> > > Protocol "https" not supported or disabled in libcurl >> > > >> > > Closing connection -1 >> > > >> > > >> > > >> > > >> > > ----- Mail original ----- >> > > > De: "David Cole" >> > > > ?: "Cedric Doucet" >> > > > Cc: cmake at cmake.org >> > > > Envoy?: Vendredi 17 Avril 2015 13:21:08 >> > > > Objet: Re: [CMake] Don't download external projects again after >> > > > calling >> > > > "make clean" >> > > > >> > > > Eliminate your DOWNLOAD_COMMAND. CMake knows how to do it with just >> > > > the URL_MD5, DOWNLOAD_DIR and SOURCE_DIR information.... >> > > > >> > > > HTH, >> > > > David >> > > > >> > > > >> > > > On Fri, Apr 17, 2015 at 1:32 AM, Cedric Doucet >> > > > >> > > > wrote: >> > > > > >> > > > > Hello David, >> > > > > >> > > > > thank you very much for your help. >> > > > > >> > > > > Unfortunately I may do something wrong because it does not work. >> > > > > After cleaning, the library is downloaded again. >> > > > > >> > > > > I guess my mistake comes from the fact I do not understand the >> > > > > role of >> > > > > URL_MD5. >> > > > > Below is a simple example where downloading and installing is very >> > > > > fast. >> > > > > You just have to replace the value of EXTERNAL_DIR by the path to >> > > > > your >> > > > > own >> > > > > "Downloads" repository. >> > > > > I tried to put URL in my DOWNLOAD_COMMAND but the call "wget >> > > > > " >> > > > > does >> > > > > not seem to be understood by the wget command. >> > > > > >> > > > > Thanks again! >> > > > > >> > > > > C?dric >> > > > > >> > > > > >> > > > > -------------------------------------------------------------------------- >> > > > > cmake_minimum_required (VERSION 2.6) >> > > > > >> > > > > project (example CXX) >> > > > > >> > > > > set(CMAKE_VERBOSE_MAKEFILE ON) >> > > > > >> > > > > include(ProcessorCount) >> > > > > ProcessorCount(N) >> > > > > if(NOT N EQUAL 0) >> > > > > set(CMAKE_BUILD_FLAGS -j${N}) >> > > > > endif() >> > > > > >> > > > > include(ExternalProject) >> > > > > set(EXTERNAL_DIR /home/cdoucet/Downloads) >> > > > > ExternalProject_Add(eigen >> > > > > PREFIX ${EXTERNAL_DIR}/eigen >> > > > > DOWNLOAD_DIR ${EXTERNAL_DIR}/eigen/download >> > > > > SOURCE_DIR ${EXTERNAL_DIR}/eigen/src >> > > > > BINARY_DIR ${EXTERNAL_DIR}/eigen/build >> > > > > INSTALL_DIR ${EXTERNAL_DIR}/eigen/install >> > > > > URL >> > > > > >> > > > > http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz >> > > > > URL_MD5 ccb18a771f678b38a3d33c321a8e7daf >> > > > > DOWNLOAD_COMMAND wget >> > > > > >> > > > > http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz >> > > > > && >> > > > > tar xvzf 3.2.4.tar.gz -C >> > > > > --strip-components=1 >> > > > > CONFIGURE_COMMAND cd && cmake -D >> > > > > CMAKE_INSTALL_PREFIX=$ >> > > > > >> > > > > ) >> > > > > >> > > > > ------------------------------------------------------------------------------ >> > > > > >> > > > > >> > > > > >> > > > > ----- Mail original ----- >> > > > >> De: "David Cole" >> > > > >> ?: "Cedric Doucet" >> > > > >> Cc: cmake at cmake.org >> > > > >> Envoy?: Lundi 13 Avril 2015 12:40:34 >> > > > >> Objet: Re: [CMake] Don't download external projects again after >> > > > >> calling >> > > > >> "make clean" >> > > > >> >> > > > >> Use the URL_MD5 and DOWNLOAD_DIR arguments to ExternalProject_Add >> > > > >> to >> > > > >> put the downloaded files into a location outside the build tree >> > > > >> (perhaps ~/Downloads on Mac/Linux or $ENV{USERPROFILE}/Downloads >> > > > >> on >> > > > >> Windows). >> > > > >> >> > > > >> With DOWNLOAD_DIR outside the build tree, and the checksums of >> > > > >> the >> > > > >> downloaded files being the same as you've specified via URL_MD5, >> > > > >> the >> > > > >> download portion will be avoided once there is a local copy of a >> > > > >> file >> > > > >> available. >> > > > >> >> > > > >> >> > > > >> HTH, >> > > > >> David C. >> > > > >> >> > > > >> >> > > > >> On Mon, Apr 13, 2015 at 5:04 AM, Cedric Doucet >> > > > >> >> > > > >> wrote: >> > > > >> > >> > > > >> > Hello! >> > > > >> > >> > > > >> > I use the ExternalProject_Add function to download third-party >> > > > >> > libraries >> > > > >> > of >> > > > >> > a code. >> > > > >> > >> > > > >> > Once a library has been downloaded, I can call "make" as many >> > > > >> > times >> > > > >> > as >> > > > >> > I >> > > > >> > want without downloading this library again. >> > > > >> > It seems that CMake detects that the library has already been >> > > > >> > downloaded. >> > > > >> > >> > > > >> > However, calling "make clean" seems to destroy this feature. >> > > > >> > Even if my library is not uninstalled during cleaning, calling >> > > > >> > "make" >> > > > >> > after >> > > > >> > "make clean" will lead CMake to try download the library again. >> > > > >> > >> > > > >> > How could I tell CMake not to download the library again? >> > > > >> > >> > > > >> > Thank you very much for your help! >> > > > >> > >> > > > >> > C?dric >> > > > >> > >> > > > >> > -- >> > > > >> > >> > > > >> > Powered by www.kitware.com >> > > > >> > >> > > > >> > Please keep messages on-topic and check the CMake FAQ at: >> > > > >> > http://www.cmake.org/Wiki/CMake_FAQ >> > > > >> > >> > > > >> > Kitware offers various services to support the CMake community. >> > > > >> > For >> > > > >> > more >> > > > >> > information on each offering, please visit: >> > > > >> > >> > > > >> > CMake Support: http://cmake.org/cmake/help/support.html >> > > > >> > CMake Consulting: http://cmake.org/cmake/help/consulting.html >> > > > >> > CMake Training Courses: >> > > > >> > http://cmake.org/cmake/help/training.html >> > > > >> > >> > > > >> > Visit other Kitware open-source projects at >> > > > >> > http://www.kitware.com/opensource/opensource.html >> > > > >> > >> > > > >> > Follow this link to subscribe/unsubscribe: >> > > > >> > http://public.kitware.com/mailman/listinfo/cmake >> > > > >> >> > > > >> > > -- >> > > >> > > Powered by www.kitware.com >> > > >> > > Please keep messages on-topic and check the CMake FAQ at: >> > > http://www.cmake.org/Wiki/CMake_FAQ >> > > >> > > Kitware offers various services to support the CMake community. For >> > > more >> > > information on each offering, please visit: >> > > >> > > CMake Support: http://cmake.org/cmake/help/support.html >> > > CMake Consulting: http://cmake.org/cmake/help/consulting.html >> > > CMake Training Courses: http://cmake.org/cmake/help/training.html >> > > >> > > Visit other Kitware open-source projects at >> > > http://www.kitware.com/opensource/opensource.html >> > > >> > > Follow this link to subscribe/unsubscribe: >> > > http://public.kitware.com/mailman/listinfo/cmake >> > > >> > -- >> > >> > Powered by www.kitware.com >> > >> > Please keep messages on-topic and check the CMake FAQ at: >> > http://www.cmake.org/Wiki/CMake_FAQ >> > >> > Kitware offers various services to support the CMake community. For more >> > information on each offering, please visit: >> > >> > CMake Support: http://cmake.org/cmake/help/support.html >> > CMake Consulting: http://cmake.org/cmake/help/consulting.html >> > CMake Training Courses: http://cmake.org/cmake/help/training.html >> > >> > Visit other Kitware open-source projects at >> > http://www.kitware.com/opensource/opensource.html >> > >> > Follow this link to subscribe/unsubscribe: >> > http://public.kitware.com/mailman/listinfo/cmake >> > >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake > > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From irwin at beluga.phys.uvic.ca Thu Apr 23 07:19:40 2015 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Thu, 23 Apr 2015 04:19:40 -0700 (PDT) Subject: [CMake] cmp0026, file(GENERATE...), and configure_file In-Reply-To: References: Message-ID: On 2015-04-23 06:47-0400 David Cole wrote: > Should it be configure_file(GENERATE or file(CONFIGURE_AND_GENERATE ?? The first (or configure_file_generate, see below) would be my preference. > In the meantime, while it is certainly clumsy to do the two separate > commands everywhere, you could write a CMake language > function(configure_file_generate ...) that takes the same args as > configure_file, but does the two step in its implementation. That is a good idea that should be straightforward for me to implement as part of the PLplot build system. Is there a standard way such a function could be used officially as part of CMake? In other words, are there some official CMake functions now that are not written in C++ but are instead written as CMake language functions? Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From petr.kmoch at gmail.com Thu Apr 23 07:21:40 2015 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Thu, 23 Apr 2015 13:21:40 +0200 Subject: [CMake] cmp0026, file(GENERATE...), and configure_file In-Reply-To: References: <5538CCFF.5040008@gmail.com> Message-ID: I hope you don't mind an outsider chipping in with a potential 5th possibility: 5. parse the file to be configured to discover which variables will be necessary for the configuration, and save only *their* values. For any but the most insane configure_file() calls, that should be a tiny subset of all the variables in existence, and should hopefully keep the memory requirements at a manageable level. The value could even be shared by different configure_file() calls if they're the same. Petr On Thu, Apr 23, 2015 at 1:00 PM, David Cole via CMake wrote: > There's also a fourth possibility: > > 4. Delay the configure processing for these "configure and generate" > files with the final variable values at the END of the configure (*at* > generate time). > > Then there are no memory or temp file issues, but you have a mismatch > with the existing (and reasonably expected) behavior of configure_file > which does immediate processing. > > That would be inconvenient, if not impossible, for folks to use > predictably from the scope of sub-directories. > > Seems we have not stumbled upon the win-win idea yet... > > > D > > > On Thu, Apr 23, 2015 at 6:44 AM, Nils Gladitz > wrote: > > On 04/23/2015 12:13 PM, Alan W. Irwin wrote: > >> > >> I think your idea of configure_file(GENERATE...) (where configure_file > >> occurs at configure-time without GENERATE to be backwards compatible, > >> but it occurs at generate-time if the new GENERATE signature is used) > >> is an excellent way to allow users to replace the current clumsiness > >> that is required to configure a file with both @ symbols and > >> generator expressions. > > > > > > I suppose for that to work configure_file() would have to either: > > > > 1. Store the values of all variables as they were set during the > > configure_file() call so that they can be expanded during generation. > > > > 2. Or perform variable substitution in-memory during the call and store > the > > intermediate content for generator expressions substitution at generation > > time. > > > > 3. Or perform variable substitution during the call and store the > > intermediate content in a temporary file which then gets generator > > expression substitution at generation time. > > > > None of those sound really optimal. > > > > With 1. and 2. memory requirements might get out of hand. > > > > With 3. you are basically back to something that acts like a > > configure_file() + file(GENERATE) wrapper except that cmake now has to > come > > up with temporary filenames. > > > > 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 DLRdave at aol.com Thu Apr 23 07:30:39 2015 From: DLRdave at aol.com (David Cole) Date: Thu, 23 Apr 2015 07:30:39 -0400 Subject: [CMake] cmp0026, file(GENERATE...), and configure_file In-Reply-To: References: <5538CCFF.5040008@gmail.com> Message-ID: "5." is more work, but a good idea... And since your recent activity on the mailing list rivals my own, you'd never hear me calling you "an outsider". ;-) I tend to think things like this (problems without an obvious, easy, code-it-right-up solution...) should be slept on for a few nights/weeks before action. Especially since there's an easy way to write a CMake language wrapper function for now. If it still seems like a good idea after some sleep, then we can tackle figuring out the exact details. But, hey, ... if it seems obvious and easy to somebody else here, then by all means, send the patch along for review. :-) Thx, D On Thu, Apr 23, 2015 at 7:21 AM, Petr Kmoch wrote: > I hope you don't mind an outsider chipping in with a potential 5th > possibility: > > 5. parse the file to be configured to discover which variables will be > necessary for the configuration, and save only *their* values. For any but > the most insane configure_file() calls, that should be a tiny subset of all > the variables in existence, and should hopefully keep the memory > requirements at a manageable level. The value could even be shared by > different configure_file() calls if they're the same. > > Petr > > On Thu, Apr 23, 2015 at 1:00 PM, David Cole via CMake > wrote: >> >> There's also a fourth possibility: >> >> 4. Delay the configure processing for these "configure and generate" >> files with the final variable values at the END of the configure (*at* >> generate time). >> >> Then there are no memory or temp file issues, but you have a mismatch >> with the existing (and reasonably expected) behavior of configure_file >> which does immediate processing. >> >> That would be inconvenient, if not impossible, for folks to use >> predictably from the scope of sub-directories. >> >> Seems we have not stumbled upon the win-win idea yet... >> >> >> D >> >> >> On Thu, Apr 23, 2015 at 6:44 AM, Nils Gladitz >> wrote: >> > On 04/23/2015 12:13 PM, Alan W. Irwin wrote: >> >> >> >> I think your idea of configure_file(GENERATE...) (where configure_file >> >> occurs at configure-time without GENERATE to be backwards compatible, >> >> but it occurs at generate-time if the new GENERATE signature is used) >> >> is an excellent way to allow users to replace the current clumsiness >> >> that is required to configure a file with both @ symbols and >> >> generator expressions. >> > >> > >> > I suppose for that to work configure_file() would have to either: >> > >> > 1. Store the values of all variables as they were set during the >> > configure_file() call so that they can be expanded during generation. >> > >> > 2. Or perform variable substitution in-memory during the call and store >> > the >> > intermediate content for generator expressions substitution at >> > generation >> > time. >> > >> > 3. Or perform variable substitution during the call and store the >> > intermediate content in a temporary file which then gets generator >> > expression substitution at generation time. >> > >> > None of those sound really optimal. >> > >> > With 1. and 2. memory requirements might get out of hand. >> > >> > With 3. you are basically back to something that acts like a >> > configure_file() + file(GENERATE) wrapper except that cmake now has to >> > come >> > up with temporary filenames. >> > >> > 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 cedric.doucet at inria.fr Thu Apr 23 07:31:58 2015 From: cedric.doucet at inria.fr (Cedric Doucet) Date: Thu, 23 Apr 2015 13:31:58 +0200 (CEST) Subject: [CMake] Don't download external projects again after calling "make clean" In-Reply-To: References: <1351653491.156868.1428915508943.JavaMail.zimbra@inria.fr> <1544359461.2146552.1429354828753.JavaMail.zimbra@inria.fr> <871275596.2148003.1429357111569.JavaMail.zimbra@inria.fr> <1588572917.2149426.1429359332478.JavaMail.zimbra@inria.fr> <1295666502.746483.1429786670655.JavaMail.zimbra@inria.fr> Message-ID: <2145954676.1560.1429788718967.JavaMail.zimbra@inria.fr> Thank you very much. Your remarks are very helpful to me to understand how it works. I hope the following file is now correct: ================== project (example CXX) set(CMAKE_VERBOSE_MAKEFILE ON) include(ProcessorCount) ProcessorCount(N) if(NOT N EQUAL 0) set(CMAKE_BUILD_FLAGS -j${N}) endif() include(ExternalProject) set(EXTERNAL_DIR ${CMAKE_CURRENT_BINARY_DIR}) ExternalProject_Add(eigen PREFIX ${EXTERNAL_DIR}/eigen DOWNLOAD_DIR /home/cdoucet/Downloads/eigen SOURCE_DIR ${EXTERNAL_DIR}/eigen/src BINARY_DIR ${EXTERNAL_DIR}/eigen/build INSTALL_DIR ${EXTERNAL_DIR}/eigen/install URL http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz URL_MD5 4d0d77e06fef87b4fcd2c9b72cc8dc55 CMAKE_ARGS -D CMAKE_INSTALL_PREFIX= ) =================== After deleting /home/cdoucet/Downloads/eigen and all the content of my build directory (from where I call "cmake .."), I typed: cmake .. make and I still obtain the following error message: ===================== /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -H/home/cdoucet/Documents/exemples/cmake/external_project/eigen -B/home/cdoucet/Documents/exemples/cmake/external_project/eigen/build --check-build-system CMakeFiles/Makefile.cmake 0 /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E cmake_progress_start /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/CMakeFiles /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/CMakeFiles/progress.marks make -f CMakeFiles/Makefile2 all make[1]: entrant dans le r?pertoire ? /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? make -f CMakeFiles/eigen.dir/build.make CMakeFiles/eigen.dir/depend make[2]: entrant dans le r?pertoire ? /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? cd /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build && /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E cmake_depends "Unix Makefiles" /home/cdoucet/Documents/exemples/cmake/external_project/eigen /home/cdoucet/Documents/exemples/cmake/external_project/eigen /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/CMakeFiles/eigen.dir/DependInfo.cmake --color= Scanning dependencies of target eigen make[2]: quittant le r?pertoire ? /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? make -f CMakeFiles/eigen.dir/build.make CMakeFiles/eigen.dir/build make[2]: entrant dans le r?pertoire ? /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E cmake_progress_report /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/CMakeFiles 3 [ 12%] Creating directories for 'eigen' /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen/src /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen/build /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen/install /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen/tmp /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen/src/eigen-stamp /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory /home/cdoucet/Downloads/eigen /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E touch /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen/src/eigen-stamp/eigen-mkdir /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E cmake_progress_report /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/CMakeFiles 4 [ 25%] Performing download step (download, verify and extract) for 'eigen' cd /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen && /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -P /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen/src/eigen-stamp/download-eigen.cmake -- downloading... src='http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz' dst='/home/cdoucet/Downloads/eigen/3.2.4.tar.gz' timeout='none' -- [download 100% complete] -- [download 0% complete] -- [download 1% complete] -- [download 2% complete] -- [download 3% complete] -- [download 4% complete] -- [download 5% complete] -- [download 7% complete] -- [download 8% complete] -- [download 9% complete] -- [download 10% complete] -- [download 11% complete] -- [download 12% complete] -- [download 13% complete] -- [download 14% complete] -- [download 15% complete] -- [download 17% complete] -- [download 18% complete] -- [download 19% complete] -- [download 20% complete] -- [download 21% complete] -- [download 22% complete] -- [download 23% complete] -- [download 24% complete] -- [download 25% complete] -- [download 27% complete] -- [download 28% complete] -- [download 29% complete] -- [download 30% complete] -- [download 31% complete] -- [download 32% complete] -- [download 33% complete] -- [download 34% complete] -- [download 35% complete] -- [download 36% complete] -- [download 38% complete] -- [download 39% complete] -- [download 40% complete] -- [download 41% complete] -- [download 42% complete] -- [download 43% complete] -- [download 44% complete] -- [download 45% complete] -- [download 46% complete] -- [download 48% complete] -- [download 49% complete] -- [download 50% complete] -- [download 51% complete] -- [download 52% complete] -- [download 53% complete] -- [download 54% complete] -- [download 55% complete] -- [download 56% complete] -- [download 57% complete] -- [download 59% complete] -- [download 60% complete] -- [download 61% complete] -- [download 62% complete] -- [download 63% complete] -- [download 64% complete] -- [download 65% complete] -- [download 66% complete] -- [download 67% complete] -- [download 69% complete] -- [download 70% complete] -- [download 71% complete] -- [download 72% complete] -- [download 73% complete] -- [download 74% complete] -- [download 75% complete] -- [download 76% complete] -- [download 77% complete] -- [download 78% complete] -- [download 80% complete] -- [download 81% complete] -- [download 82% complete] -- [download 83% complete] -- [download 84% complete] -- [download 85% complete] -- [download 86% complete] -- [download 87% complete] -- [download 88% complete] -- [download 90% complete] -- [download 91% complete] -- [download 92% complete] -- [download 93% complete] -- [download 94% complete] -- [download 95% complete] -- [download 96% complete] -- [download 97% complete] -- [download 98% complete] -- [download 99% complete] -- [download 100% complete] -- downloading... done cd /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen && /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -P /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen/src/eigen-stamp/verify-eigen.cmake -- verifying file... file='/home/cdoucet/Downloads/eigen/3.2.4.tar.gz' -- verifying file... done cd /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen && /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -P /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen/src/eigen-stamp/extract-eigen.cmake -- extracting... src='/home/cdoucet/Downloads/eigen/3.2.4.tar.gz' dst='/home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen/src' -- extracting... [tar xfz] -- extracting... [analysis] -- extracting... [rename] -- extracting... [clean up] -- extracting... done cd /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen && /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E touch /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen/src/eigen-stamp/eigen-download make[2]: *** [eigen/src/eigen-stamp/eigen-download] Erreur 1 make[2]: quittant le r?pertoire ? /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? make[1]: *** [CMakeFiles/eigen.dir/all] Erreur 2 make[1]: quittant le r?pertoire ? /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? make: *** [all] Erreur 2 ===================== ----- Mail original ----- > De: "David Cole" > ?: "Cedric Doucet" > Cc: cmake at cmake.org > Envoy?: Jeudi 23 Avril 2015 13:14:35 > Objet: Re: [CMake] Don't download external projects again after calling "make clean" > > I don't understand what the error is here, but here are some comments: > > (1) > CMAKE_INSTALL_PREFIX=$ > > The $ is unnecessary and incorrect in this context. The literal string > is the thing that ExternalProject will substitute when > it is processed into custom commands... > > (2) > ONLY the DOWNLOAD_DIR parameter should be in an "external" (outside of > your build tree) directory, to avoid re-downloading the exact same > tar.gz file over and over again. The source tree and the build tree of > the project should be in your build tree somewhere. > > (3) > CONFIGURE_COMMAND cd && cmake should be unnecessary... > The configure command is run in the binary dir by default. Instead, > you should be able to use: > > CMAKE_ARGS -D CMAKE_INSTALL_PREFIX= > > The binary dir is the working directory for configure, build and > install commands. And the is added automatically when you > use CMAKE_ARGS with the default cmake CONFIGURE_COMMAND rather than > specifying your own. > > > Make those changes and try again with one more fresh build (i.e. -- > blow away the whole /home/cdoucet/Downloads/eigen directory and start > clean...) > > Let us know if you still have an error after making those changes. > > > HTH, > David C. > > > > On Thu, Apr 23, 2015 at 6:57 AM, Cedric Doucet > wrote: > > Hello David, > > > > I am using CMake 3.2.2. > > I installed CMake from the sources because I use "modules" to manage my > > libraries. > > But it's ok now: I modified the installation so that to support https. > > > > Unfortunately, I still have a problem. :( > > Maybe you could help me! > > > > Here is my CMakeLists.txt: > > > > ============= > > > > cmake_minimum_required (VERSION 2.6) > > > > project (example CXX) > > > > set(CMAKE_VERBOSE_MAKEFILE ON) > > > > include(ProcessorCount) > > ProcessorCount(N) > > if(NOT N EQUAL 0) > > set(CMAKE_BUILD_FLAGS -j${N}) > > endif() > > > > include(ExternalProject) > > set(EXTERNAL_DIR /home/cdoucet/Downloads) > > ExternalProject_Add(eigen > > PREFIX ${EXTERNAL_DIR}/eigen > > DOWNLOAD_DIR > > ${EXTERNAL_DIR}/eigen/download > > SOURCE_DIR ${EXTERNAL_DIR}/eigen/src > > BINARY_DIR ${EXTERNAL_DIR}/eigen/build > > INSTALL_DIR > > ${EXTERNAL_DIR}/eigen/install > > URL > > http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz > > URL_MD5 4d0d77e06fef87b4fcd2c9b72cc8dc55 > > CONFIGURE_COMMAND cd && > > cmake -D CMAKE_INSTALL_PREFIX=$ > > ) > > > > ============= > > > > And here is the error message: > > > > ===================== > > > > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake > > -H/home/cdoucet/Documents/exemples/cmake/external_project/eigen > > -B/home/cdoucet/Documents/exemples/cmake/external_project/eigen/build > > --check-build-system CMakeFiles/Makefile.cmake 0 > > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E cmake_progress_start > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/CMakeFiles > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/CMakeFiles/progress.marks > > make -f CMakeFiles/Makefile2 all > > make[1]: entrant dans le r?pertoire ? > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? > > make -f CMakeFiles/eigen.dir/build.make CMakeFiles/eigen.dir/depend > > make[2]: entrant dans le r?pertoire ? > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? > > cd /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build && > > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E cmake_depends "Unix > > Makefiles" /home/cdoucet/Documents/exemples/cmake/external_project/eigen > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/CMakeFiles/eigen.dir/DependInfo.cmake > > --color= > > make[2]: quittant le r?pertoire ? > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? > > make -f CMakeFiles/eigen.dir/build.make CMakeFiles/eigen.dir/build > > make[2]: entrant dans le r?pertoire ? > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? > > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E cmake_progress_report > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/CMakeFiles > > 3 > > [ 12%] Creating directories for 'eigen' > > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory > > /home/cdoucet/Downloads/eigen/src > > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory > > /home/cdoucet/Downloads/eigen/build > > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory > > /home/cdoucet/Downloads/eigen/install > > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory > > /home/cdoucet/Downloads/eigen/tmp > > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory > > /home/cdoucet/Downloads/eigen/src/eigen-stamp > > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory > > /home/cdoucet/Downloads/eigen/download > > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E touch > > /home/cdoucet/Downloads/eigen/src/eigen-stamp/eigen-mkdir > > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E cmake_progress_report > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/CMakeFiles > > 4 > > [ 25%] Performing download step (download, verify and extract) for 'eigen' > > cd /home/cdoucet/Downloads/eigen && > > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -P > > /home/cdoucet/Downloads/eigen/src/eigen-stamp/download-eigen.cmake > > -- downloading... > > src='http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz' > > dst='/home/cdoucet/Downloads/eigen/download/3.2.4.tar.gz' > > timeout='none' > > -- [download 100% complete] > > -- [download 0% complete] > > -- [download 1% complete] > > -- [download 2% complete] > > -- [download 3% complete] > > -- [download 4% complete] > > -- [download 5% complete] > > -- [download 7% complete] > > -- [download 8% complete] > > -- [download 9% complete] > > -- [download 10% complete] > > -- [download 11% complete] > > -- [download 12% complete] > > -- [download 13% complete] > > -- [download 14% complete] > > -- [download 15% complete] > > -- [download 17% complete] > > -- [download 18% complete] > > -- [download 19% complete] > > -- [download 20% complete] > > -- [download 21% complete] > > -- [download 22% complete] > > -- [download 23% complete] > > -- [download 24% complete] > > -- [download 25% complete] > > -- [download 27% complete] > > -- [download 28% complete] > > -- [download 29% complete] > > -- [download 30% complete] > > -- [download 31% complete] > > -- [download 32% complete] > > -- [download 33% complete] > > -- [download 34% complete] > > -- [download 35% complete] > > -- [download 36% complete] > > -- [download 38% complete] > > -- [download 39% complete] > > -- [download 40% complete] > > -- [download 41% complete] > > -- [download 42% complete] > > -- [download 43% complete] > > -- [download 44% complete] > > -- [download 45% complete] > > -- [download 46% complete] > > -- [download 48% complete] > > -- [download 49% complete] > > -- [download 50% complete] > > -- [download 51% complete] > > -- [download 52% complete] > > -- [download 53% complete] > > -- [download 54% complete] > > -- [download 55% complete] > > -- [download 56% complete] > > -- [download 57% complete] > > -- [download 59% complete] > > -- [download 60% complete] > > -- [download 61% complete] > > -- [download 62% complete] > > -- [download 63% complete] > > -- [download 64% complete] > > -- [download 65% complete] > > -- [download 66% complete] > > -- [download 67% complete] > > -- [download 69% complete] > > -- [download 70% complete] > > -- [download 71% complete] > > -- [download 72% complete] > > -- [download 73% complete] > > -- [download 74% complete] > > -- [download 75% complete] > > -- [download 76% complete] > > -- [download 77% complete] > > -- [download 78% complete] > > -- [download 80% complete] > > -- [download 81% complete] > > -- [download 82% complete] > > -- [download 83% complete] > > -- [download 84% complete] > > -- [download 85% complete] > > -- [download 86% complete] > > -- [download 87% complete] > > -- [download 88% complete] > > -- [download 90% complete] > > -- [download 91% complete] > > -- [download 92% complete] > > -- [download 93% complete] > > -- [download 94% complete] > > -- [download 95% complete] > > -- [download 96% complete] > > -- [download 97% complete] > > -- [download 98% complete] > > -- [download 99% complete] > > -- [download 100% complete] > > -- downloading... done > > cd /home/cdoucet/Downloads/eigen && > > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -P > > /home/cdoucet/Downloads/eigen/src/eigen-stamp/verify-eigen.cmake > > -- verifying file... > > file='/home/cdoucet/Downloads/eigen/download/3.2.4.tar.gz' > > -- verifying file... done > > cd /home/cdoucet/Downloads/eigen && > > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -P > > /home/cdoucet/Downloads/eigen/src/eigen-stamp/extract-eigen.cmake > > -- extracting... > > src='/home/cdoucet/Downloads/eigen/download/3.2.4.tar.gz' > > dst='/home/cdoucet/Downloads/eigen/src' > > -- extracting... [tar xfz] > > -- extracting... [analysis] > > -- extracting... [rename] > > -- extracting... [clean up] > > -- extracting... done > > cd /home/cdoucet/Downloads/eigen && > > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E touch > > /home/cdoucet/Downloads/eigen/src/eigen-stamp/eigen-download > > make[2]: *** [/home/cdoucet/Downloads/eigen/src/eigen-stamp/eigen-download] > > Erreur 1 > > make[2]: quittant le r?pertoire ? > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? > > make[1]: *** [CMakeFiles/eigen.dir/all] Erreur 2 > > make[1]: quittant le r?pertoire ? > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? > > make: *** [all] Erreur 2 > > > > ===================== > > > > > > > > ________________________________ > > > > De: "David Cole" > > ?: "Cedric Doucet" > > Cc: cmake at cmake.org > > Envoy?: Samedi 18 Avril 2015 20:39:57 > > > > Objet: Re: [CMake] Don't download external projects again after calling > > "make clean" > > > > What version of CMake are you using? All the modern pre-built CMake > > installations should support https without extra effort on your part. Are > > you using a pre-built version from somewhere or are you building CMake > > yourself? > > > > > > On Saturday, April 18, 2015, Cedric Doucet wrote: > >> > >> > >> Ok it seems the answer to my problem is here: > >> http://www.cmake.org/pipermail/cmake/2010-December/041295.html > >> I will try it. > >> > >> ----- Mail original ----- > >> > De: "Cedric Doucet" > >> > ?: cmake at cmake.org > >> > Envoy?: Samedi 18 Avril 2015 13:38:31 > >> > Objet: Re: [CMake] Don't download external projects again after calling > >> > "make clean" > >> > > >> > > >> > I have just tried to install curl to get https support. > >> > To do that, I have followed the steps below: > >> > > >> > 1. Installation of openssl: > >> > 1.a. ./config --prefix=/my/openssl/path > >> > 1.b. make > >> > 1.c. make test > >> > 1.d. make install > >> > 2. Installation of curl > >> > 2.a. ./configure --prefix=/my/curl/path > >> > --with-ssl=/my/openssl/path/lib > >> > 2.b. make > >> > 2.c. make install > >> > > >> > I have also prepend PATH with /my/curl/path/bin. > >> > However, the error remains. > >> > It seems that my version of curl (7.41.0) is not taken into acount > >> > because I > >> > have still this line in the error message: > >> > User-Agent: curl/7.38.0 > >> > I tried to remove all previous of curl and libcurl but it does not > >> > change > >> > anything. > >> > > >> > Could you help me? > >> > > >> > C?dric > >> > > >> > > >> > ----- Mail original ----- > >> > > De: "Cedric Doucet" > >> > > ?: "David Cole" > >> > > Cc: cmake at cmake.org > >> > > Envoy?: Samedi 18 Avril 2015 13:00:28 > >> > > Objet: Re: [CMake] Don't download external projects again after > >> > > calling > >> > > "make clean" > >> > > > >> > > > >> > > Hello David, > >> > > > >> > > thank you very much. > >> > > Unfortunately, I get the following error message if I remove my > >> > > download > >> > > command: > >> > > > >> > > -- downloading... > >> > > src='http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz' > >> > > dst='/home/cdoucet/Downloads/eigen/download/3.2.4.tar.gz' > >> > > timeout='none' > >> > > -- [download 100% complete] > >> > > CMake Error at src/eigen-stamp/download-eigen.cmake:27 (message): > >> > > error: downloading > >> > > 'http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz' > >> > > failed > >> > > > >> > > status_code: 1 > >> > > status_string: "Unsupported protocol" > >> > > log: Hostname was NOT found in DNS cache > >> > > Trying 131.103.20.167... > >> > > > >> > > Connected to bitbucket.org (131.103.20.167) port 80 (#0) > >> > > > >> > > GET /eigen/eigen/get/3.2.4.tar.gz HTTP/1.1 > >> > > > >> > > User-Agent: curl/7.38.0 > >> > > > >> > > Host: bitbucket.org > >> > > > >> > > Accept: */* > >> > > > >> > > > >> > > > >> > > HTTP/1.1 301 Moved Permanently > >> > > > >> > > Server nginx/1.6.2 is not blacklisted > >> > > > >> > > Server: nginx/1.6.2 > >> > > > >> > > Date: Sat, 18 Apr 2015 10:55:20 GMT > >> > > > >> > > Content-Type: text/html > >> > > > >> > > Content-Length: 184 > >> > > > >> > > Location: https://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz > >> > > > >> > > > >> > > > >> > > Ignoring the response-body > >> > > > >> > > > >> > > > >> > > 301 Moved Permanently > >> > > > >> > > > >> > > > >> > >

301 Moved Permanently

> >> > > > >> > >
nginx/1.6.2
> >> > > > >> > > > >> > > > >> > > > >> > > > >> > > Connection #0 to host bitbucket.org left intact > >> > > > >> > > Issue another request to this URL: > >> > > 'https://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz' > >> > > > >> > > Protocol "https" not supported or disabled in libcurl > >> > > > >> > > Closing connection -1 > >> > > > >> > > > >> > > > >> > > > >> > > ----- Mail original ----- > >> > > > De: "David Cole" > >> > > > ?: "Cedric Doucet" > >> > > > Cc: cmake at cmake.org > >> > > > Envoy?: Vendredi 17 Avril 2015 13:21:08 > >> > > > Objet: Re: [CMake] Don't download external projects again after > >> > > > calling > >> > > > "make clean" > >> > > > > >> > > > Eliminate your DOWNLOAD_COMMAND. CMake knows how to do it with just > >> > > > the URL_MD5, DOWNLOAD_DIR and SOURCE_DIR information.... > >> > > > > >> > > > HTH, > >> > > > David > >> > > > > >> > > > > >> > > > On Fri, Apr 17, 2015 at 1:32 AM, Cedric Doucet > >> > > > > >> > > > wrote: > >> > > > > > >> > > > > Hello David, > >> > > > > > >> > > > > thank you very much for your help. > >> > > > > > >> > > > > Unfortunately I may do something wrong because it does not work. > >> > > > > After cleaning, the library is downloaded again. > >> > > > > > >> > > > > I guess my mistake comes from the fact I do not understand the > >> > > > > role of > >> > > > > URL_MD5. > >> > > > > Below is a simple example where downloading and installing is very > >> > > > > fast. > >> > > > > You just have to replace the value of EXTERNAL_DIR by the path to > >> > > > > your > >> > > > > own > >> > > > > "Downloads" repository. > >> > > > > I tried to put URL in my DOWNLOAD_COMMAND but the call "wget > >> > > > > " > >> > > > > does > >> > > > > not seem to be understood by the wget command. > >> > > > > > >> > > > > Thanks again! > >> > > > > > >> > > > > C?dric > >> > > > > > >> > > > > > >> > > > > -------------------------------------------------------------------------- > >> > > > > cmake_minimum_required (VERSION 2.6) > >> > > > > > >> > > > > project (example CXX) > >> > > > > > >> > > > > set(CMAKE_VERBOSE_MAKEFILE ON) > >> > > > > > >> > > > > include(ProcessorCount) > >> > > > > ProcessorCount(N) > >> > > > > if(NOT N EQUAL 0) > >> > > > > set(CMAKE_BUILD_FLAGS -j${N}) > >> > > > > endif() > >> > > > > > >> > > > > include(ExternalProject) > >> > > > > set(EXTERNAL_DIR /home/cdoucet/Downloads) > >> > > > > ExternalProject_Add(eigen > >> > > > > PREFIX ${EXTERNAL_DIR}/eigen > >> > > > > DOWNLOAD_DIR ${EXTERNAL_DIR}/eigen/download > >> > > > > SOURCE_DIR ${EXTERNAL_DIR}/eigen/src > >> > > > > BINARY_DIR ${EXTERNAL_DIR}/eigen/build > >> > > > > INSTALL_DIR ${EXTERNAL_DIR}/eigen/install > >> > > > > URL > >> > > > > > >> > > > > http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz > >> > > > > URL_MD5 ccb18a771f678b38a3d33c321a8e7daf > >> > > > > DOWNLOAD_COMMAND wget > >> > > > > > >> > > > > http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz > >> > > > > && > >> > > > > tar xvzf 3.2.4.tar.gz -C > >> > > > > --strip-components=1 > >> > > > > CONFIGURE_COMMAND cd && cmake -D > >> > > > > CMAKE_INSTALL_PREFIX=$ > >> > > > > > >> > > > > ) > >> > > > > > >> > > > > ------------------------------------------------------------------------------ > >> > > > > > >> > > > > > >> > > > > > >> > > > > ----- Mail original ----- > >> > > > >> De: "David Cole" > >> > > > >> ?: "Cedric Doucet" > >> > > > >> Cc: cmake at cmake.org > >> > > > >> Envoy?: Lundi 13 Avril 2015 12:40:34 > >> > > > >> Objet: Re: [CMake] Don't download external projects again after > >> > > > >> calling > >> > > > >> "make clean" > >> > > > >> > >> > > > >> Use the URL_MD5 and DOWNLOAD_DIR arguments to ExternalProject_Add > >> > > > >> to > >> > > > >> put the downloaded files into a location outside the build tree > >> > > > >> (perhaps ~/Downloads on Mac/Linux or $ENV{USERPROFILE}/Downloads > >> > > > >> on > >> > > > >> Windows). > >> > > > >> > >> > > > >> With DOWNLOAD_DIR outside the build tree, and the checksums of > >> > > > >> the > >> > > > >> downloaded files being the same as you've specified via URL_MD5, > >> > > > >> the > >> > > > >> download portion will be avoided once there is a local copy of a > >> > > > >> file > >> > > > >> available. > >> > > > >> > >> > > > >> > >> > > > >> HTH, > >> > > > >> David C. > >> > > > >> > >> > > > >> > >> > > > >> On Mon, Apr 13, 2015 at 5:04 AM, Cedric Doucet > >> > > > >> > >> > > > >> wrote: > >> > > > >> > > >> > > > >> > Hello! > >> > > > >> > > >> > > > >> > I use the ExternalProject_Add function to download third-party > >> > > > >> > libraries > >> > > > >> > of > >> > > > >> > a code. > >> > > > >> > > >> > > > >> > Once a library has been downloaded, I can call "make" as many > >> > > > >> > times > >> > > > >> > as > >> > > > >> > I > >> > > > >> > want without downloading this library again. > >> > > > >> > It seems that CMake detects that the library has already been > >> > > > >> > downloaded. > >> > > > >> > > >> > > > >> > However, calling "make clean" seems to destroy this feature. > >> > > > >> > Even if my library is not uninstalled during cleaning, calling > >> > > > >> > "make" > >> > > > >> > after > >> > > > >> > "make clean" will lead CMake to try download the library again. > >> > > > >> > > >> > > > >> > How could I tell CMake not to download the library again? > >> > > > >> > > >> > > > >> > Thank you very much for your help! > >> > > > >> > > >> > > > >> > C?dric > >> > > > >> > > >> > > > >> > -- > >> > > > >> > > >> > > > >> > Powered by www.kitware.com > >> > > > >> > > >> > > > >> > Please keep messages on-topic and check the CMake FAQ at: > >> > > > >> > http://www.cmake.org/Wiki/CMake_FAQ > >> > > > >> > > >> > > > >> > Kitware offers various services to support the CMake community. > >> > > > >> > For > >> > > > >> > more > >> > > > >> > information on each offering, please visit: > >> > > > >> > > >> > > > >> > CMake Support: http://cmake.org/cmake/help/support.html > >> > > > >> > CMake Consulting: http://cmake.org/cmake/help/consulting.html > >> > > > >> > CMake Training Courses: > >> > > > >> > http://cmake.org/cmake/help/training.html > >> > > > >> > > >> > > > >> > Visit other Kitware open-source projects at > >> > > > >> > http://www.kitware.com/opensource/opensource.html > >> > > > >> > > >> > > > >> > Follow this link to subscribe/unsubscribe: > >> > > > >> > http://public.kitware.com/mailman/listinfo/cmake > >> > > > >> > >> > > > > >> > > -- > >> > > > >> > > Powered by www.kitware.com > >> > > > >> > > Please keep messages on-topic and check the CMake FAQ at: > >> > > http://www.cmake.org/Wiki/CMake_FAQ > >> > > > >> > > Kitware offers various services to support the CMake community. For > >> > > more > >> > > information on each offering, please visit: > >> > > > >> > > CMake Support: http://cmake.org/cmake/help/support.html > >> > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > >> > > CMake Training Courses: http://cmake.org/cmake/help/training.html > >> > > > >> > > Visit other Kitware open-source projects at > >> > > http://www.kitware.com/opensource/opensource.html > >> > > > >> > > Follow this link to subscribe/unsubscribe: > >> > > http://public.kitware.com/mailman/listinfo/cmake > >> > > > >> > -- > >> > > >> > Powered by www.kitware.com > >> > > >> > Please keep messages on-topic and check the CMake FAQ at: > >> > http://www.cmake.org/Wiki/CMake_FAQ > >> > > >> > Kitware offers various services to support the CMake community. For more > >> > information on each offering, please visit: > >> > > >> > CMake Support: http://cmake.org/cmake/help/support.html > >> > CMake Consulting: http://cmake.org/cmake/help/consulting.html > >> > CMake Training Courses: http://cmake.org/cmake/help/training.html > >> > > >> > Visit other Kitware open-source projects at > >> > http://www.kitware.com/opensource/opensource.html > >> > > >> > Follow this link to subscribe/unsubscribe: > >> > http://public.kitware.com/mailman/listinfo/cmake > >> > > >> -- > >> > >> Powered by www.kitware.com > >> > >> Please keep messages on-topic and check the CMake FAQ at: > >> http://www.cmake.org/Wiki/CMake_FAQ > >> > >> Kitware offers various services to support the CMake community. For more > >> information on each offering, please visit: > >> > >> CMake Support: http://cmake.org/cmake/help/support.html > >> CMake Consulting: http://cmake.org/cmake/help/consulting.html > >> CMake Training Courses: http://cmake.org/cmake/help/training.html > >> > >> Visit other Kitware open-source projects at > >> http://www.kitware.com/opensource/opensource.html > >> > >> Follow this link to subscribe/unsubscribe: > >> http://public.kitware.com/mailman/listinfo/cmake > > > > > > > > -- > > > > Powered by www.kitware.com > > > > Please keep messages on-topic and check the CMake FAQ at: > > http://www.cmake.org/Wiki/CMake_FAQ > > > > Kitware offers various services to support the CMake community. For more > > information on each offering, please visit: > > > > CMake Support: http://cmake.org/cmake/help/support.html > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/cmake > From irwin at beluga.phys.uvic.ca Thu Apr 23 07:32:29 2015 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Thu, 23 Apr 2015 04:32:29 -0700 (PDT) Subject: [CMake] cmp0026, file(GENERATE...), and configure_file In-Reply-To: References: Message-ID: On 2015-04-23 04:19-0700 Alan W. Irwin wrote: > On 2015-04-23 06:47-0400 David Cole wrote: > >> Should it be configure_file(GENERATE or file(CONFIGURE_AND_GENERATE ?? > > The first (or configure_file_generate, see below) would be my preference. > >> In the meantime, while it is certainly clumsy to do the two separate >> commands everywhere, you could write a CMake language >> function(configure_file_generate ...) that takes the same args as >> configure_file, but does the two step in its implementation. > > That is a good idea that should be straightforward for me to implement > as part of the PLplot build system. > > Is there a standard way such a function could be used officially as > part of CMake? In other words, are there some official CMake > functions now that are not written in C++ but are instead written as > CMake language functions? I am still curious about the answer to that question in the general sense, but I have had second thoughts about distributing this particular solution that way because the CMake function approach for dealing with this issue still generates the extra file (which is OK but not ideal). Therefore, I would prefer that official CMake just used the configure_file(GENERATE) approach if/when that is implemented. Of course, for those interested in this interim solution, they will still have access to the configure_file_generate CMake function via the LGPL'd PLplot build system. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From nilsgladitz at gmail.com Thu Apr 23 07:32:17 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 23 Apr 2015 13:32:17 +0200 Subject: [CMake] cmp0026, file(GENERATE...), and configure_file In-Reply-To: References: Message-ID: <5538D841.5050603@gmail.com> On 23.04.2015 13:19, Alan W. Irwin wrote: > > Is there a standard way such a function could be used officially as > part of CMake? In other words, are there some official CMake > functions now that are not written in C++ but are instead written as > CMake language functions Many (mostly those that don't start with "Find") cmake modules provide functions/macros written in cmake language: http://www.cmake.org/cmake/help/v3.2/manual/cmake-modules.7.html Nils From DLRdave at aol.com Thu Apr 23 07:34:46 2015 From: DLRdave at aol.com (David Cole) Date: Thu, 23 Apr 2015 07:34:46 -0400 Subject: [CMake] cmp0026, file(GENERATE...), and configure_file In-Reply-To: References: Message-ID: Of the modules, many of the "non-Find*" modules are exactly that. Of the list here: http://www.cmake.org/cmake/help/v3.2/manual/cmake-modules.7.html The ones that pop out to me as obvious "CMake language function providers" are ExternalProject, GetPrerequisites, BundleUtilities, ProcessorCount. Mostly they're obvious to me because I have history in each of those files. The general convention to follow is, public functions in a module should begin with the module name, followed by an "_", followed by the function name. -- i.e. ExternalProject_Add is the "Add" function in the ExternalProject module. HTH, David C. On Thu, Apr 23, 2015 at 7:19 AM, Alan W. Irwin wrote: > On 2015-04-23 06:47-0400 David Cole wrote: > >> Should it be configure_file(GENERATE or file(CONFIGURE_AND_GENERATE ?? > > > The first (or configure_file_generate, see below) would be my preference. > >> In the meantime, while it is certainly clumsy to do the two separate >> commands everywhere, you could write a CMake language >> function(configure_file_generate ...) that takes the same args as >> configure_file, but does the two step in its implementation. > > > That is a good idea that should be straightforward for me to implement > as part of the PLplot build system. > > Is there a standard way such a function could be used officially as > part of CMake? In other words, are there some official CMake > functions now that are not written in C++ but are instead written as > CMake language functions? > > > Alan > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state > implementation for stellar interiors (freeeos.sf.net); the Time > Ephemerides project (timeephem.sf.net); PLplot scientific plotting > software package (plplot.sf.net); the libLASi project > (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); > and the Linux Brochure Project (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ From irwin at beluga.phys.uvic.ca Thu Apr 23 07:35:24 2015 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Thu, 23 Apr 2015 04:35:24 -0700 (PDT) Subject: [CMake] cmp0026, file(GENERATE...), and configure_file In-Reply-To: <5538D841.5050603@gmail.com> References: <5538D841.5050603@gmail.com> Message-ID: On 2015-04-23 13:32+0200 Nils Gladitz wrote: > On 23.04.2015 13:19, Alan W. Irwin wrote: >> >> Is there a standard way such a function could be used officially as >> part of CMake? In other words, are there some official CMake >> functions now that are not written in C++ but are instead written as >> CMake language functions > > Many (mostly those that don't start with "Find") cmake modules provide > functions/macros written in cmake language: > http://www.cmake.org/cmake/help/v3.2/manual/cmake-modules.7.html Thanks for reminding me of that possibility. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From DLRdave at aol.com Thu Apr 23 07:51:06 2015 From: DLRdave at aol.com (David Cole) Date: Thu, 23 Apr 2015 07:51:06 -0400 Subject: [CMake] Do build after GIT_TAG changed in ExternalProject_Add In-Reply-To: <1429533936969-7590317.post@n2.nabble.com> References: <1429369490097-7590299.post@n2.nabble.com> <1429394330993-7590302.post@n2.nabble.com> <1429533108166-7590316.post@n2.nabble.com> <1429533936969-7590317.post@n2.nabble.com> Message-ID: Hmmmmmm. I am seeing the same behavior you are, even with the older CMake 2.8.12.2 -- the update step does run, but steps after that, which are supposed to depend on update, are not re-running. I think your intuitive expectation is correct, and that configure/build/install should run after changing the GIT_TAG. I cannot see (quickly/yet) where the problem is in the chain of ExternalProject custom commands... There's a nagging thought bouncing around in my brain telling me there's something awfully familiar about this problem, and that I've seen it and solved it before, but I can't quite put my finger on it. I must be forgetting something. And unfortunately, with the complexity of ExternalProject, it takes quite some time to dig into something deeply. Is anybody else listening on this thread? Shouldn't changing the GIT_TAG value cause a re-configure+build+install of the ExternalProject....? David C. On Mon, Apr 20, 2015 at 8:45 AM, typ1232 wrote: > Note that I changed CMAKE_ARGS, so the target is used that contains the file > that was changed in the commit. > > CMAKE_ARGS "-DSAF_INTENTIONAL_COMPILE_WARNING=TRUE" > > > > -- > View this message in context: http://cmake.3232098.n2.nabble.com/Do-build-after-GIT-TAG-changed-in-ExternalProject-Add-tp7590299p7590317.html > Sent from the CMake mailing list archive at Nabble.com. > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From cedric.doucet at inria.fr Thu Apr 23 07:55:52 2015 From: cedric.doucet at inria.fr (Cedric Doucet) Date: Thu, 23 Apr 2015 13:55:52 +0200 (CEST) Subject: [CMake] Do build after GIT_TAG changed in ExternalProject_Add In-Reply-To: References: <1429369490097-7590299.post@n2.nabble.com> <1429394330993-7590302.post@n2.nabble.com> <1429533108166-7590316.post@n2.nabble.com> <1429533936969-7590317.post@n2.nabble.com> Message-ID: <739506198.10018.1429790152911.JavaMail.zimbra@inria.fr> I don't know why but providing my own STAMP_DIR seems to solve the problem: STAMP_DIR ${EXTERNAL_DIR}/eigen/stamp Hope it helps! C?dric ----- Mail original ----- > De: "David Cole via CMake" > ?: "typ1232" > Cc: cmake at cmake.org > Envoy?: Jeudi 23 Avril 2015 13:51:06 > Objet: Re: [CMake] Do build after GIT_TAG changed in ExternalProject_Add > > Hmmmmmm. I am seeing the same behavior you are, even with the older > CMake 2.8.12.2 -- the update step does run, but steps after that, > which are supposed to depend on update, are not re-running. > > I think your intuitive expectation is correct, and that > configure/build/install should run after changing the GIT_TAG. I > cannot see (quickly/yet) where the problem is in the chain of > ExternalProject custom commands... > > There's a nagging thought bouncing around in my brain telling me > there's something awfully familiar about this problem, and that I've > seen it and solved it before, but I can't quite put my finger on it. > > I must be forgetting something. And unfortunately, with the complexity > of ExternalProject, it takes quite some time to dig into something > deeply. > > Is anybody else listening on this thread? Shouldn't changing the > GIT_TAG value cause a re-configure+build+install of the > ExternalProject....? > > > David C. > > > > > > On Mon, Apr 20, 2015 at 8:45 AM, typ1232 wrote: > > Note that I changed CMAKE_ARGS, so the target is used that contains the > > file > > that was changed in the commit. > > > > CMAKE_ARGS "-DSAF_INTENTIONAL_COMPILE_WARNING=TRUE" > > > > > > > > -- > > View this message in context: > > http://cmake.3232098.n2.nabble.com/Do-build-after-GIT-TAG-changed-in-ExternalProject-Add-tp7590299p7590317.html > > Sent from the CMake mailing list archive at Nabble.com. > > -- > > > > Powered by www.kitware.com > > > > Please keep messages on-topic and check the CMake FAQ at: > > http://www.cmake.org/Wiki/CMake_FAQ > > > > Kitware offers various services to support the CMake community. For more > > information on each offering, please visit: > > > > CMake Support: http://cmake.org/cmake/help/support.html > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/cmake > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > From DLRdave at aol.com Thu Apr 23 07:56:36 2015 From: DLRdave at aol.com (David Cole) Date: Thu, 23 Apr 2015 07:56:36 -0400 Subject: [CMake] Don't download external projects again after calling "make clean" In-Reply-To: <2145954676.1560.1429788718967.JavaMail.zimbra@inria.fr> References: <1351653491.156868.1428915508943.JavaMail.zimbra@inria.fr> <1544359461.2146552.1429354828753.JavaMail.zimbra@inria.fr> <871275596.2148003.1429357111569.JavaMail.zimbra@inria.fr> <1588572917.2149426.1429359332478.JavaMail.zimbra@inria.fr> <1295666502.746483.1429786670655.JavaMail.zimbra@inria.fr> <2145954676.1560.1429788718967.JavaMail.zimbra@inria.fr> Message-ID: It looks correct. I don't understand what the error is. It looks like the download and extract succeeds, but then it simply doesn't move on to the next step of trying to configure with CMake... Does the extracted eigen source tree look like it's a proper un-tarred eigen source directory? Does this simple example work for you? (copied/pasted from another recent CMake mailing list discussion...) # ---------------------------------------------------------------------- # CMakeLists.txt cmake_minimum_required(VERSION 3.2) project(repro NONE) include(ExternalProject) ExternalProject_Add(name GIT_REPOSITORY https://github.com/dlrdave/SmallAndFast.git GIT_TAG 68c3cebf842aa8a13d659fec428fd85ca3a24307 CMAKE_ARGS "" INSTALL_COMMAND "" ) # Possible commits in this repo (most recent first) # # 68c3cebf842aa8a13d659fec428fd85ca3a24307 # a0acdce3a549796ca4424c591c038eeb19e59a72 # 5e98e304a464946dd34cb4c53eb3dd1fd348781b # 8ea36ce26a6b00ab839064a6066a984f6d6647f6 # END CMakeLists.txt Silly question, but do you need to build eigen, or are you using it as a header only library? And... if you do need to build it, does v3.2.4 of eigen build with CMake or does it require some other configure command? (I've been assuming you've actually built eigen manually, and you're just trying to automate it with ExternalProject... but now I'm back-tracking and trying not to assume anything...) HTH, David C. On Thu, Apr 23, 2015 at 7:31 AM, Cedric Doucet wrote: > > Thank you very much. > Your remarks are very helpful to me to understand how it works. > > I hope the following file is now correct: > > ================== > project (example CXX) > > set(CMAKE_VERBOSE_MAKEFILE ON) > > include(ProcessorCount) > ProcessorCount(N) > if(NOT N EQUAL 0) > set(CMAKE_BUILD_FLAGS -j${N}) > endif() > > include(ExternalProject) > set(EXTERNAL_DIR ${CMAKE_CURRENT_BINARY_DIR}) > ExternalProject_Add(eigen > PREFIX ${EXTERNAL_DIR}/eigen > DOWNLOAD_DIR /home/cdoucet/Downloads/eigen > SOURCE_DIR ${EXTERNAL_DIR}/eigen/src > BINARY_DIR ${EXTERNAL_DIR}/eigen/build > INSTALL_DIR ${EXTERNAL_DIR}/eigen/install > URL http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz > URL_MD5 4d0d77e06fef87b4fcd2c9b72cc8dc55 > CMAKE_ARGS -D CMAKE_INSTALL_PREFIX= > ) > =================== > > After deleting /home/cdoucet/Downloads/eigen and all the content of my build directory (from where I call "cmake .."), I typed: > cmake .. > make > > and I still obtain the following error message: > > ===================== > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -H/home/cdoucet/Documents/exemples/cmake/external_project/eigen -B/home/cdoucet/Documents/exemples/cmake/external_project/eigen/build --check-build-system CMakeFiles/Makefile.cmake 0 > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E cmake_progress_start /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/CMakeFiles /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/CMakeFiles/progress.marks > make -f CMakeFiles/Makefile2 all > make[1]: entrant dans le r?pertoire ? /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? > make -f CMakeFiles/eigen.dir/build.make CMakeFiles/eigen.dir/depend > make[2]: entrant dans le r?pertoire ? /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? > cd /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build && /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E cmake_depends "Unix Makefiles" /home/cdoucet/Documents/exemples/cmake/external_project/eigen /home/cdoucet/Documents/exemples/cmake/external_project/eigen /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/CMakeFiles/eigen.dir/DependInfo.cmake --color= > Scanning dependencies of target eigen > make[2]: quittant le r?pertoire ? /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? > make -f CMakeFiles/eigen.dir/build.make CMakeFiles/eigen.dir/build > make[2]: entrant dans le r?pertoire ? /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E cmake_progress_report /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/CMakeFiles 3 > [ 12%] Creating directories for 'eigen' > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen/src > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen/build > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen/install > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen/tmp > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen/src/eigen-stamp > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory /home/cdoucet/Downloads/eigen > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E touch /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen/src/eigen-stamp/eigen-mkdir > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E cmake_progress_report /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/CMakeFiles 4 > [ 25%] Performing download step (download, verify and extract) for 'eigen' > cd /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen && /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -P /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen/src/eigen-stamp/download-eigen.cmake > -- downloading... > src='http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz' > dst='/home/cdoucet/Downloads/eigen/3.2.4.tar.gz' > timeout='none' > -- [download 100% complete] > -- [download 0% complete] > -- [download 1% complete] > -- [download 2% complete] > -- [download 3% complete] > -- [download 4% complete] > -- [download 5% complete] > -- [download 7% complete] > -- [download 8% complete] > -- [download 9% complete] > -- [download 10% complete] > -- [download 11% complete] > -- [download 12% complete] > -- [download 13% complete] > -- [download 14% complete] > -- [download 15% complete] > -- [download 17% complete] > -- [download 18% complete] > -- [download 19% complete] > -- [download 20% complete] > -- [download 21% complete] > -- [download 22% complete] > -- [download 23% complete] > -- [download 24% complete] > -- [download 25% complete] > -- [download 27% complete] > -- [download 28% complete] > -- [download 29% complete] > -- [download 30% complete] > -- [download 31% complete] > -- [download 32% complete] > -- [download 33% complete] > -- [download 34% complete] > -- [download 35% complete] > -- [download 36% complete] > -- [download 38% complete] > -- [download 39% complete] > -- [download 40% complete] > -- [download 41% complete] > -- [download 42% complete] > -- [download 43% complete] > -- [download 44% complete] > -- [download 45% complete] > -- [download 46% complete] > -- [download 48% complete] > -- [download 49% complete] > -- [download 50% complete] > -- [download 51% complete] > -- [download 52% complete] > -- [download 53% complete] > -- [download 54% complete] > -- [download 55% complete] > -- [download 56% complete] > -- [download 57% complete] > -- [download 59% complete] > -- [download 60% complete] > -- [download 61% complete] > -- [download 62% complete] > -- [download 63% complete] > -- [download 64% complete] > -- [download 65% complete] > -- [download 66% complete] > -- [download 67% complete] > -- [download 69% complete] > -- [download 70% complete] > -- [download 71% complete] > -- [download 72% complete] > -- [download 73% complete] > -- [download 74% complete] > -- [download 75% complete] > -- [download 76% complete] > -- [download 77% complete] > -- [download 78% complete] > -- [download 80% complete] > -- [download 81% complete] > -- [download 82% complete] > -- [download 83% complete] > -- [download 84% complete] > -- [download 85% complete] > -- [download 86% complete] > -- [download 87% complete] > -- [download 88% complete] > -- [download 90% complete] > -- [download 91% complete] > -- [download 92% complete] > -- [download 93% complete] > -- [download 94% complete] > -- [download 95% complete] > -- [download 96% complete] > -- [download 97% complete] > -- [download 98% complete] > -- [download 99% complete] > -- [download 100% complete] > -- downloading... done > cd /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen && /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -P /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen/src/eigen-stamp/verify-eigen.cmake > -- verifying file... > file='/home/cdoucet/Downloads/eigen/3.2.4.tar.gz' > -- verifying file... done > cd /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen && /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -P /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen/src/eigen-stamp/extract-eigen.cmake > -- extracting... > src='/home/cdoucet/Downloads/eigen/3.2.4.tar.gz' > dst='/home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen/src' > -- extracting... [tar xfz] > -- extracting... [analysis] > -- extracting... [rename] > -- extracting... [clean up] > -- extracting... done > cd /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen && /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E touch /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen/src/eigen-stamp/eigen-download > make[2]: *** [eigen/src/eigen-stamp/eigen-download] Erreur 1 > make[2]: quittant le r?pertoire ? /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? > make[1]: *** [CMakeFiles/eigen.dir/all] Erreur 2 > make[1]: quittant le r?pertoire ? /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? > make: *** [all] Erreur 2 > > ===================== > > > > ----- Mail original ----- >> De: "David Cole" >> ?: "Cedric Doucet" >> Cc: cmake at cmake.org >> Envoy?: Jeudi 23 Avril 2015 13:14:35 >> Objet: Re: [CMake] Don't download external projects again after calling "make clean" >> >> I don't understand what the error is here, but here are some comments: >> >> (1) >> CMAKE_INSTALL_PREFIX=$ >> >> The $ is unnecessary and incorrect in this context. The literal string >> is the thing that ExternalProject will substitute when >> it is processed into custom commands... >> >> (2) >> ONLY the DOWNLOAD_DIR parameter should be in an "external" (outside of >> your build tree) directory, to avoid re-downloading the exact same >> tar.gz file over and over again. The source tree and the build tree of >> the project should be in your build tree somewhere. >> >> (3) >> CONFIGURE_COMMAND cd && cmake should be unnecessary... >> The configure command is run in the binary dir by default. Instead, >> you should be able to use: >> >> CMAKE_ARGS -D CMAKE_INSTALL_PREFIX= >> >> The binary dir is the working directory for configure, build and >> install commands. And the is added automatically when you >> use CMAKE_ARGS with the default cmake CONFIGURE_COMMAND rather than >> specifying your own. >> >> >> Make those changes and try again with one more fresh build (i.e. -- >> blow away the whole /home/cdoucet/Downloads/eigen directory and start >> clean...) >> >> Let us know if you still have an error after making those changes. >> >> >> HTH, >> David C. >> >> >> >> On Thu, Apr 23, 2015 at 6:57 AM, Cedric Doucet >> wrote: >> > Hello David, >> > >> > I am using CMake 3.2.2. >> > I installed CMake from the sources because I use "modules" to manage my >> > libraries. >> > But it's ok now: I modified the installation so that to support https. >> > >> > Unfortunately, I still have a problem. :( >> > Maybe you could help me! >> > >> > Here is my CMakeLists.txt: >> > >> > ============= >> > >> > cmake_minimum_required (VERSION 2.6) >> > >> > project (example CXX) >> > >> > set(CMAKE_VERBOSE_MAKEFILE ON) >> > >> > include(ProcessorCount) >> > ProcessorCount(N) >> > if(NOT N EQUAL 0) >> > set(CMAKE_BUILD_FLAGS -j${N}) >> > endif() >> > >> > include(ExternalProject) >> > set(EXTERNAL_DIR /home/cdoucet/Downloads) >> > ExternalProject_Add(eigen >> > PREFIX ${EXTERNAL_DIR}/eigen >> > DOWNLOAD_DIR >> > ${EXTERNAL_DIR}/eigen/download >> > SOURCE_DIR ${EXTERNAL_DIR}/eigen/src >> > BINARY_DIR ${EXTERNAL_DIR}/eigen/build >> > INSTALL_DIR >> > ${EXTERNAL_DIR}/eigen/install >> > URL >> > http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz >> > URL_MD5 4d0d77e06fef87b4fcd2c9b72cc8dc55 >> > CONFIGURE_COMMAND cd && >> > cmake -D CMAKE_INSTALL_PREFIX=$ >> > ) >> > >> > ============= >> > >> > And here is the error message: >> > >> > ===================== >> > >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake >> > -H/home/cdoucet/Documents/exemples/cmake/external_project/eigen >> > -B/home/cdoucet/Documents/exemples/cmake/external_project/eigen/build >> > --check-build-system CMakeFiles/Makefile.cmake 0 >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E cmake_progress_start >> > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/CMakeFiles >> > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/CMakeFiles/progress.marks >> > make -f CMakeFiles/Makefile2 all >> > make[1]: entrant dans le r?pertoire ? >> > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? >> > make -f CMakeFiles/eigen.dir/build.make CMakeFiles/eigen.dir/depend >> > make[2]: entrant dans le r?pertoire ? >> > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? >> > cd /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build && >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E cmake_depends "Unix >> > Makefiles" /home/cdoucet/Documents/exemples/cmake/external_project/eigen >> > /home/cdoucet/Documents/exemples/cmake/external_project/eigen >> > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build >> > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build >> > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/CMakeFiles/eigen.dir/DependInfo.cmake >> > --color= >> > make[2]: quittant le r?pertoire ? >> > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? >> > make -f CMakeFiles/eigen.dir/build.make CMakeFiles/eigen.dir/build >> > make[2]: entrant dans le r?pertoire ? >> > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E cmake_progress_report >> > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/CMakeFiles >> > 3 >> > [ 12%] Creating directories for 'eigen' >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory >> > /home/cdoucet/Downloads/eigen/src >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory >> > /home/cdoucet/Downloads/eigen/build >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory >> > /home/cdoucet/Downloads/eigen/install >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory >> > /home/cdoucet/Downloads/eigen/tmp >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory >> > /home/cdoucet/Downloads/eigen/src/eigen-stamp >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory >> > /home/cdoucet/Downloads/eigen/download >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E touch >> > /home/cdoucet/Downloads/eigen/src/eigen-stamp/eigen-mkdir >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E cmake_progress_report >> > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/CMakeFiles >> > 4 >> > [ 25%] Performing download step (download, verify and extract) for 'eigen' >> > cd /home/cdoucet/Downloads/eigen && >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -P >> > /home/cdoucet/Downloads/eigen/src/eigen-stamp/download-eigen.cmake >> > -- downloading... >> > src='http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz' >> > dst='/home/cdoucet/Downloads/eigen/download/3.2.4.tar.gz' >> > timeout='none' >> > -- [download 100% complete] >> > -- [download 0% complete] >> > -- [download 1% complete] >> > -- [download 2% complete] >> > -- [download 3% complete] >> > -- [download 4% complete] >> > -- [download 5% complete] >> > -- [download 7% complete] >> > -- [download 8% complete] >> > -- [download 9% complete] >> > -- [download 10% complete] >> > -- [download 11% complete] >> > -- [download 12% complete] >> > -- [download 13% complete] >> > -- [download 14% complete] >> > -- [download 15% complete] >> > -- [download 17% complete] >> > -- [download 18% complete] >> > -- [download 19% complete] >> > -- [download 20% complete] >> > -- [download 21% complete] >> > -- [download 22% complete] >> > -- [download 23% complete] >> > -- [download 24% complete] >> > -- [download 25% complete] >> > -- [download 27% complete] >> > -- [download 28% complete] >> > -- [download 29% complete] >> > -- [download 30% complete] >> > -- [download 31% complete] >> > -- [download 32% complete] >> > -- [download 33% complete] >> > -- [download 34% complete] >> > -- [download 35% complete] >> > -- [download 36% complete] >> > -- [download 38% complete] >> > -- [download 39% complete] >> > -- [download 40% complete] >> > -- [download 41% complete] >> > -- [download 42% complete] >> > -- [download 43% complete] >> > -- [download 44% complete] >> > -- [download 45% complete] >> > -- [download 46% complete] >> > -- [download 48% complete] >> > -- [download 49% complete] >> > -- [download 50% complete] >> > -- [download 51% complete] >> > -- [download 52% complete] >> > -- [download 53% complete] >> > -- [download 54% complete] >> > -- [download 55% complete] >> > -- [download 56% complete] >> > -- [download 57% complete] >> > -- [download 59% complete] >> > -- [download 60% complete] >> > -- [download 61% complete] >> > -- [download 62% complete] >> > -- [download 63% complete] >> > -- [download 64% complete] >> > -- [download 65% complete] >> > -- [download 66% complete] >> > -- [download 67% complete] >> > -- [download 69% complete] >> > -- [download 70% complete] >> > -- [download 71% complete] >> > -- [download 72% complete] >> > -- [download 73% complete] >> > -- [download 74% complete] >> > -- [download 75% complete] >> > -- [download 76% complete] >> > -- [download 77% complete] >> > -- [download 78% complete] >> > -- [download 80% complete] >> > -- [download 81% complete] >> > -- [download 82% complete] >> > -- [download 83% complete] >> > -- [download 84% complete] >> > -- [download 85% complete] >> > -- [download 86% complete] >> > -- [download 87% complete] >> > -- [download 88% complete] >> > -- [download 90% complete] >> > -- [download 91% complete] >> > -- [download 92% complete] >> > -- [download 93% complete] >> > -- [download 94% complete] >> > -- [download 95% complete] >> > -- [download 96% complete] >> > -- [download 97% complete] >> > -- [download 98% complete] >> > -- [download 99% complete] >> > -- [download 100% complete] >> > -- downloading... done >> > cd /home/cdoucet/Downloads/eigen && >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -P >> > /home/cdoucet/Downloads/eigen/src/eigen-stamp/verify-eigen.cmake >> > -- verifying file... >> > file='/home/cdoucet/Downloads/eigen/download/3.2.4.tar.gz' >> > -- verifying file... done >> > cd /home/cdoucet/Downloads/eigen && >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -P >> > /home/cdoucet/Downloads/eigen/src/eigen-stamp/extract-eigen.cmake >> > -- extracting... >> > src='/home/cdoucet/Downloads/eigen/download/3.2.4.tar.gz' >> > dst='/home/cdoucet/Downloads/eigen/src' >> > -- extracting... [tar xfz] >> > -- extracting... [analysis] >> > -- extracting... [rename] >> > -- extracting... [clean up] >> > -- extracting... done >> > cd /home/cdoucet/Downloads/eigen && >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E touch >> > /home/cdoucet/Downloads/eigen/src/eigen-stamp/eigen-download >> > make[2]: *** [/home/cdoucet/Downloads/eigen/src/eigen-stamp/eigen-download] >> > Erreur 1 >> > make[2]: quittant le r?pertoire ? >> > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? >> > make[1]: *** [CMakeFiles/eigen.dir/all] Erreur 2 >> > make[1]: quittant le r?pertoire ? >> > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? >> > make: *** [all] Erreur 2 >> > >> > ===================== >> > >> > >> > >> > ________________________________ >> > >> > De: "David Cole" >> > ?: "Cedric Doucet" >> > Cc: cmake at cmake.org >> > Envoy?: Samedi 18 Avril 2015 20:39:57 >> > >> > Objet: Re: [CMake] Don't download external projects again after calling >> > "make clean" >> > >> > What version of CMake are you using? All the modern pre-built CMake >> > installations should support https without extra effort on your part. Are >> > you using a pre-built version from somewhere or are you building CMake >> > yourself? >> > >> > >> > On Saturday, April 18, 2015, Cedric Doucet wrote: >> >> >> >> >> >> Ok it seems the answer to my problem is here: >> >> http://www.cmake.org/pipermail/cmake/2010-December/041295.html >> >> I will try it. >> >> >> >> ----- Mail original ----- >> >> > De: "Cedric Doucet" >> >> > ?: cmake at cmake.org >> >> > Envoy?: Samedi 18 Avril 2015 13:38:31 >> >> > Objet: Re: [CMake] Don't download external projects again after calling >> >> > "make clean" >> >> > >> >> > >> >> > I have just tried to install curl to get https support. >> >> > To do that, I have followed the steps below: >> >> > >> >> > 1. Installation of openssl: >> >> > 1.a. ./config --prefix=/my/openssl/path >> >> > 1.b. make >> >> > 1.c. make test >> >> > 1.d. make install >> >> > 2. Installation of curl >> >> > 2.a. ./configure --prefix=/my/curl/path >> >> > --with-ssl=/my/openssl/path/lib >> >> > 2.b. make >> >> > 2.c. make install >> >> > >> >> > I have also prepend PATH with /my/curl/path/bin. >> >> > However, the error remains. >> >> > It seems that my version of curl (7.41.0) is not taken into acount >> >> > because I >> >> > have still this line in the error message: >> >> > User-Agent: curl/7.38.0 >> >> > I tried to remove all previous of curl and libcurl but it does not >> >> > change >> >> > anything. >> >> > >> >> > Could you help me? >> >> > >> >> > C?dric >> >> > >> >> > >> >> > ----- Mail original ----- >> >> > > De: "Cedric Doucet" >> >> > > ?: "David Cole" >> >> > > Cc: cmake at cmake.org >> >> > > Envoy?: Samedi 18 Avril 2015 13:00:28 >> >> > > Objet: Re: [CMake] Don't download external projects again after >> >> > > calling >> >> > > "make clean" >> >> > > >> >> > > >> >> > > Hello David, >> >> > > >> >> > > thank you very much. >> >> > > Unfortunately, I get the following error message if I remove my >> >> > > download >> >> > > command: >> >> > > >> >> > > -- downloading... >> >> > > src='http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz' >> >> > > dst='/home/cdoucet/Downloads/eigen/download/3.2.4.tar.gz' >> >> > > timeout='none' >> >> > > -- [download 100% complete] >> >> > > CMake Error at src/eigen-stamp/download-eigen.cmake:27 (message): >> >> > > error: downloading >> >> > > 'http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz' >> >> > > failed >> >> > > >> >> > > status_code: 1 >> >> > > status_string: "Unsupported protocol" >> >> > > log: Hostname was NOT found in DNS cache >> >> > > Trying 131.103.20.167... >> >> > > >> >> > > Connected to bitbucket.org (131.103.20.167) port 80 (#0) >> >> > > >> >> > > GET /eigen/eigen/get/3.2.4.tar.gz HTTP/1.1 >> >> > > >> >> > > User-Agent: curl/7.38.0 >> >> > > >> >> > > Host: bitbucket.org >> >> > > >> >> > > Accept: */* >> >> > > >> >> > > >> >> > > >> >> > > HTTP/1.1 301 Moved Permanently >> >> > > >> >> > > Server nginx/1.6.2 is not blacklisted >> >> > > >> >> > > Server: nginx/1.6.2 >> >> > > >> >> > > Date: Sat, 18 Apr 2015 10:55:20 GMT >> >> > > >> >> > > Content-Type: text/html >> >> > > >> >> > > Content-Length: 184 >> >> > > >> >> > > Location: https://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz >> >> > > >> >> > > >> >> > > >> >> > > Ignoring the response-body >> >> > > >> >> > > >> >> > > >> >> > > 301 Moved Permanently >> >> > > >> >> > > >> >> > > >> >> > >

301 Moved Permanently

>> >> > > >> >> > >
nginx/1.6.2
>> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > Connection #0 to host bitbucket.org left intact >> >> > > >> >> > > Issue another request to this URL: >> >> > > 'https://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz' >> >> > > >> >> > > Protocol "https" not supported or disabled in libcurl >> >> > > >> >> > > Closing connection -1 >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > ----- Mail original ----- >> >> > > > De: "David Cole" >> >> > > > ?: "Cedric Doucet" >> >> > > > Cc: cmake at cmake.org >> >> > > > Envoy?: Vendredi 17 Avril 2015 13:21:08 >> >> > > > Objet: Re: [CMake] Don't download external projects again after >> >> > > > calling >> >> > > > "make clean" >> >> > > > >> >> > > > Eliminate your DOWNLOAD_COMMAND. CMake knows how to do it with just >> >> > > > the URL_MD5, DOWNLOAD_DIR and SOURCE_DIR information.... >> >> > > > >> >> > > > HTH, >> >> > > > David >> >> > > > >> >> > > > >> >> > > > On Fri, Apr 17, 2015 at 1:32 AM, Cedric Doucet >> >> > > > >> >> > > > wrote: >> >> > > > > >> >> > > > > Hello David, >> >> > > > > >> >> > > > > thank you very much for your help. >> >> > > > > >> >> > > > > Unfortunately I may do something wrong because it does not work. >> >> > > > > After cleaning, the library is downloaded again. >> >> > > > > >> >> > > > > I guess my mistake comes from the fact I do not understand the >> >> > > > > role of >> >> > > > > URL_MD5. >> >> > > > > Below is a simple example where downloading and installing is very >> >> > > > > fast. >> >> > > > > You just have to replace the value of EXTERNAL_DIR by the path to >> >> > > > > your >> >> > > > > own >> >> > > > > "Downloads" repository. >> >> > > > > I tried to put URL in my DOWNLOAD_COMMAND but the call "wget >> >> > > > > " >> >> > > > > does >> >> > > > > not seem to be understood by the wget command. >> >> > > > > >> >> > > > > Thanks again! >> >> > > > > >> >> > > > > C?dric >> >> > > > > >> >> > > > > >> >> > > > > -------------------------------------------------------------------------- >> >> > > > > cmake_minimum_required (VERSION 2.6) >> >> > > > > >> >> > > > > project (example CXX) >> >> > > > > >> >> > > > > set(CMAKE_VERBOSE_MAKEFILE ON) >> >> > > > > >> >> > > > > include(ProcessorCount) >> >> > > > > ProcessorCount(N) >> >> > > > > if(NOT N EQUAL 0) >> >> > > > > set(CMAKE_BUILD_FLAGS -j${N}) >> >> > > > > endif() >> >> > > > > >> >> > > > > include(ExternalProject) >> >> > > > > set(EXTERNAL_DIR /home/cdoucet/Downloads) >> >> > > > > ExternalProject_Add(eigen >> >> > > > > PREFIX ${EXTERNAL_DIR}/eigen >> >> > > > > DOWNLOAD_DIR ${EXTERNAL_DIR}/eigen/download >> >> > > > > SOURCE_DIR ${EXTERNAL_DIR}/eigen/src >> >> > > > > BINARY_DIR ${EXTERNAL_DIR}/eigen/build >> >> > > > > INSTALL_DIR ${EXTERNAL_DIR}/eigen/install >> >> > > > > URL >> >> > > > > >> >> > > > > http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz >> >> > > > > URL_MD5 ccb18a771f678b38a3d33c321a8e7daf >> >> > > > > DOWNLOAD_COMMAND wget >> >> > > > > >> >> > > > > http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz >> >> > > > > && >> >> > > > > tar xvzf 3.2.4.tar.gz -C >> >> > > > > --strip-components=1 >> >> > > > > CONFIGURE_COMMAND cd && cmake -D >> >> > > > > CMAKE_INSTALL_PREFIX=$ >> >> > > > > >> >> > > > > ) >> >> > > > > >> >> > > > > ------------------------------------------------------------------------------ >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > ----- Mail original ----- >> >> > > > >> De: "David Cole" >> >> > > > >> ?: "Cedric Doucet" >> >> > > > >> Cc: cmake at cmake.org >> >> > > > >> Envoy?: Lundi 13 Avril 2015 12:40:34 >> >> > > > >> Objet: Re: [CMake] Don't download external projects again after >> >> > > > >> calling >> >> > > > >> "make clean" >> >> > > > >> >> >> > > > >> Use the URL_MD5 and DOWNLOAD_DIR arguments to ExternalProject_Add >> >> > > > >> to >> >> > > > >> put the downloaded files into a location outside the build tree >> >> > > > >> (perhaps ~/Downloads on Mac/Linux or $ENV{USERPROFILE}/Downloads >> >> > > > >> on >> >> > > > >> Windows). >> >> > > > >> >> >> > > > >> With DOWNLOAD_DIR outside the build tree, and the checksums of >> >> > > > >> the >> >> > > > >> downloaded files being the same as you've specified via URL_MD5, >> >> > > > >> the >> >> > > > >> download portion will be avoided once there is a local copy of a >> >> > > > >> file >> >> > > > >> available. >> >> > > > >> >> >> > > > >> >> >> > > > >> HTH, >> >> > > > >> David C. >> >> > > > >> >> >> > > > >> >> >> > > > >> On Mon, Apr 13, 2015 at 5:04 AM, Cedric Doucet >> >> > > > >> >> >> > > > >> wrote: >> >> > > > >> > >> >> > > > >> > Hello! >> >> > > > >> > >> >> > > > >> > I use the ExternalProject_Add function to download third-party >> >> > > > >> > libraries >> >> > > > >> > of >> >> > > > >> > a code. >> >> > > > >> > >> >> > > > >> > Once a library has been downloaded, I can call "make" as many >> >> > > > >> > times >> >> > > > >> > as >> >> > > > >> > I >> >> > > > >> > want without downloading this library again. >> >> > > > >> > It seems that CMake detects that the library has already been >> >> > > > >> > downloaded. >> >> > > > >> > >> >> > > > >> > However, calling "make clean" seems to destroy this feature. >> >> > > > >> > Even if my library is not uninstalled during cleaning, calling >> >> > > > >> > "make" >> >> > > > >> > after >> >> > > > >> > "make clean" will lead CMake to try download the library again. >> >> > > > >> > >> >> > > > >> > How could I tell CMake not to download the library again? >> >> > > > >> > >> >> > > > >> > Thank you very much for your help! >> >> > > > >> > >> >> > > > >> > C?dric >> >> > > > >> > >> >> > > > >> > -- >> >> > > > >> > >> >> > > > >> > Powered by www.kitware.com >> >> > > > >> > >> >> > > > >> > Please keep messages on-topic and check the CMake FAQ at: >> >> > > > >> > http://www.cmake.org/Wiki/CMake_FAQ >> >> > > > >> > >> >> > > > >> > Kitware offers various services to support the CMake community. >> >> > > > >> > For >> >> > > > >> > more >> >> > > > >> > information on each offering, please visit: >> >> > > > >> > >> >> > > > >> > CMake Support: http://cmake.org/cmake/help/support.html >> >> > > > >> > CMake Consulting: http://cmake.org/cmake/help/consulting.html >> >> > > > >> > CMake Training Courses: >> >> > > > >> > http://cmake.org/cmake/help/training.html >> >> > > > >> > >> >> > > > >> > Visit other Kitware open-source projects at >> >> > > > >> > http://www.kitware.com/opensource/opensource.html >> >> > > > >> > >> >> > > > >> > Follow this link to subscribe/unsubscribe: >> >> > > > >> > http://public.kitware.com/mailman/listinfo/cmake >> >> > > > >> >> >> > > > >> >> > > -- >> >> > > >> >> > > Powered by www.kitware.com >> >> > > >> >> > > Please keep messages on-topic and check the CMake FAQ at: >> >> > > http://www.cmake.org/Wiki/CMake_FAQ >> >> > > >> >> > > Kitware offers various services to support the CMake community. For >> >> > > more >> >> > > information on each offering, please visit: >> >> > > >> >> > > CMake Support: http://cmake.org/cmake/help/support.html >> >> > > CMake Consulting: http://cmake.org/cmake/help/consulting.html >> >> > > CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> > > >> >> > > Visit other Kitware open-source projects at >> >> > > http://www.kitware.com/opensource/opensource.html >> >> > > >> >> > > Follow this link to subscribe/unsubscribe: >> >> > > http://public.kitware.com/mailman/listinfo/cmake >> >> > > >> >> > -- >> >> > >> >> > Powered by www.kitware.com >> >> > >> >> > Please keep messages on-topic and check the CMake FAQ at: >> >> > http://www.cmake.org/Wiki/CMake_FAQ >> >> > >> >> > Kitware offers various services to support the CMake community. For more >> >> > information on each offering, please visit: >> >> > >> >> > CMake Support: http://cmake.org/cmake/help/support.html >> >> > CMake Consulting: http://cmake.org/cmake/help/consulting.html >> >> > CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> > >> >> > Visit other Kitware open-source projects at >> >> > http://www.kitware.com/opensource/opensource.html >> >> > >> >> > Follow this link to subscribe/unsubscribe: >> >> > http://public.kitware.com/mailman/listinfo/cmake >> >> > >> >> -- >> >> >> >> Powered by www.kitware.com >> >> >> >> Please keep messages on-topic and check the CMake FAQ at: >> >> http://www.cmake.org/Wiki/CMake_FAQ >> >> >> >> Kitware offers various services to support the CMake community. For more >> >> information on each offering, please visit: >> >> >> >> CMake Support: http://cmake.org/cmake/help/support.html >> >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> >> >> Visit other Kitware open-source projects at >> >> http://www.kitware.com/opensource/opensource.html >> >> >> >> Follow this link to subscribe/unsubscribe: >> >> http://public.kitware.com/mailman/listinfo/cmake >> > >> > >> > >> > -- >> > >> > Powered by www.kitware.com >> > >> > Please keep messages on-topic and check the CMake FAQ at: >> > http://www.cmake.org/Wiki/CMake_FAQ >> > >> > Kitware offers various services to support the CMake community. For more >> > information on each offering, please visit: >> > >> > CMake Support: http://cmake.org/cmake/help/support.html >> > CMake Consulting: http://cmake.org/cmake/help/consulting.html >> > CMake Training Courses: http://cmake.org/cmake/help/training.html >> > >> > Visit other Kitware open-source projects at >> > http://www.kitware.com/opensource/opensource.html >> > >> > Follow this link to subscribe/unsubscribe: >> > http://public.kitware.com/mailman/listinfo/cmake >> From DLRdave at aol.com Thu Apr 23 07:58:27 2015 From: DLRdave at aol.com (David Cole) Date: Thu, 23 Apr 2015 07:58:27 -0400 Subject: [CMake] Do build after GIT_TAG changed in ExternalProject_Add In-Reply-To: <739506198.10018.1429790152911.JavaMail.zimbra@inria.fr> References: <1429369490097-7590299.post@n2.nabble.com> <1429394330993-7590302.post@n2.nabble.com> <1429533108166-7590316.post@n2.nabble.com> <1429533936969-7590317.post@n2.nabble.com> <739506198.10018.1429790152911.JavaMail.zimbra@inria.fr> Message-ID: I think you meant to reply on the other thread with this one... :-) D On Thu, Apr 23, 2015 at 7:55 AM, Cedric Doucet wrote: > > I don't know why but providing my own STAMP_DIR seems to solve the problem: > > STAMP_DIR ${EXTERNAL_DIR}/eigen/stamp > > Hope it helps! > > C?dric > > > ----- Mail original ----- >> De: "David Cole via CMake" >> ?: "typ1232" >> Cc: cmake at cmake.org >> Envoy?: Jeudi 23 Avril 2015 13:51:06 >> Objet: Re: [CMake] Do build after GIT_TAG changed in ExternalProject_Add >> >> Hmmmmmm. I am seeing the same behavior you are, even with the older >> CMake 2.8.12.2 -- the update step does run, but steps after that, >> which are supposed to depend on update, are not re-running. >> >> I think your intuitive expectation is correct, and that >> configure/build/install should run after changing the GIT_TAG. I >> cannot see (quickly/yet) where the problem is in the chain of >> ExternalProject custom commands... >> >> There's a nagging thought bouncing around in my brain telling me >> there's something awfully familiar about this problem, and that I've >> seen it and solved it before, but I can't quite put my finger on it. >> >> I must be forgetting something. And unfortunately, with the complexity >> of ExternalProject, it takes quite some time to dig into something >> deeply. >> >> Is anybody else listening on this thread? Shouldn't changing the >> GIT_TAG value cause a re-configure+build+install of the >> ExternalProject....? >> >> >> David C. >> >> >> >> >> >> On Mon, Apr 20, 2015 at 8:45 AM, typ1232 wrote: >> > Note that I changed CMAKE_ARGS, so the target is used that contains the >> > file >> > that was changed in the commit. >> > >> > CMAKE_ARGS "-DSAF_INTENTIONAL_COMPILE_WARNING=TRUE" >> > >> > >> > >> > -- >> > View this message in context: >> > http://cmake.3232098.n2.nabble.com/Do-build-after-GIT-TAG-changed-in-ExternalProject-Add-tp7590299p7590317.html >> > Sent from the CMake mailing list archive at Nabble.com. >> > -- >> > >> > Powered by www.kitware.com >> > >> > Please keep messages on-topic and check the CMake FAQ at: >> > http://www.cmake.org/Wiki/CMake_FAQ >> > >> > Kitware offers various services to support the CMake community. For more >> > information on each offering, please visit: >> > >> > CMake Support: http://cmake.org/cmake/help/support.html >> > CMake Consulting: http://cmake.org/cmake/help/consulting.html >> > CMake Training Courses: http://cmake.org/cmake/help/training.html >> > >> > Visit other Kitware open-source projects at >> > http://www.kitware.com/opensource/opensource.html >> > >> > Follow this link to subscribe/unsubscribe: >> > http://public.kitware.com/mailman/listinfo/cmake >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake >> From cedric.doucet at inria.fr Thu Apr 23 07:59:27 2015 From: cedric.doucet at inria.fr (Cedric Doucet) Date: Thu, 23 Apr 2015 13:59:27 +0200 (CEST) Subject: [CMake] Do build after GIT_TAG changed in ExternalProject_Add In-Reply-To: References: <1429369490097-7590299.post@n2.nabble.com> <1429394330993-7590302.post@n2.nabble.com> <1429533108166-7590316.post@n2.nabble.com> <1429533936969-7590317.post@n2.nabble.com> <739506198.10018.1429790152911.JavaMail.zimbra@inria.fr> Message-ID: <342836700.11873.1429790367760.JavaMail.zimbra@inria.fr> Yes, I am really sorry for the noise! :-/ ----- Mail original ----- > De: "David Cole" > ?: "Cedric Doucet" > Cc: "typ1232" , cmake at cmake.org > Envoy?: Jeudi 23 Avril 2015 13:58:27 > Objet: Re: [CMake] Do build after GIT_TAG changed in ExternalProject_Add > > I think you meant to reply on the other thread with this one... > > :-) > D > > > On Thu, Apr 23, 2015 at 7:55 AM, Cedric Doucet > wrote: > > > > I don't know why but providing my own STAMP_DIR seems to solve the problem: > > > > STAMP_DIR ${EXTERNAL_DIR}/eigen/stamp > > > > Hope it helps! > > > > C?dric > > > > > > ----- Mail original ----- > >> De: "David Cole via CMake" > >> ?: "typ1232" > >> Cc: cmake at cmake.org > >> Envoy?: Jeudi 23 Avril 2015 13:51:06 > >> Objet: Re: [CMake] Do build after GIT_TAG changed in ExternalProject_Add > >> > >> Hmmmmmm. I am seeing the same behavior you are, even with the older > >> CMake 2.8.12.2 -- the update step does run, but steps after that, > >> which are supposed to depend on update, are not re-running. > >> > >> I think your intuitive expectation is correct, and that > >> configure/build/install should run after changing the GIT_TAG. I > >> cannot see (quickly/yet) where the problem is in the chain of > >> ExternalProject custom commands... > >> > >> There's a nagging thought bouncing around in my brain telling me > >> there's something awfully familiar about this problem, and that I've > >> seen it and solved it before, but I can't quite put my finger on it. > >> > >> I must be forgetting something. And unfortunately, with the complexity > >> of ExternalProject, it takes quite some time to dig into something > >> deeply. > >> > >> Is anybody else listening on this thread? Shouldn't changing the > >> GIT_TAG value cause a re-configure+build+install of the > >> ExternalProject....? > >> > >> > >> David C. > >> > >> > >> > >> > >> > >> On Mon, Apr 20, 2015 at 8:45 AM, typ1232 wrote: > >> > Note that I changed CMAKE_ARGS, so the target is used that contains the > >> > file > >> > that was changed in the commit. > >> > > >> > CMAKE_ARGS "-DSAF_INTENTIONAL_COMPILE_WARNING=TRUE" > >> > > >> > > >> > > >> > -- > >> > View this message in context: > >> > http://cmake.3232098.n2.nabble.com/Do-build-after-GIT-TAG-changed-in-ExternalProject-Add-tp7590299p7590317.html > >> > Sent from the CMake mailing list archive at Nabble.com. > >> > -- > >> > > >> > Powered by www.kitware.com > >> > > >> > Please keep messages on-topic and check the CMake FAQ at: > >> > http://www.cmake.org/Wiki/CMake_FAQ > >> > > >> > Kitware offers various services to support the CMake community. For more > >> > information on each offering, please visit: > >> > > >> > CMake Support: http://cmake.org/cmake/help/support.html > >> > CMake Consulting: http://cmake.org/cmake/help/consulting.html > >> > CMake Training Courses: http://cmake.org/cmake/help/training.html > >> > > >> > Visit other Kitware open-source projects at > >> > http://www.kitware.com/opensource/opensource.html > >> > > >> > Follow this link to subscribe/unsubscribe: > >> > http://public.kitware.com/mailman/listinfo/cmake > >> -- > >> > >> Powered by www.kitware.com > >> > >> Please keep messages on-topic and check the CMake FAQ at: > >> http://www.cmake.org/Wiki/CMake_FAQ > >> > >> Kitware offers various services to support the CMake community. For more > >> information on each offering, please visit: > >> > >> CMake Support: http://cmake.org/cmake/help/support.html > >> CMake Consulting: http://cmake.org/cmake/help/consulting.html > >> CMake Training Courses: http://cmake.org/cmake/help/training.html > >> > >> Visit other Kitware open-source projects at > >> http://www.kitware.com/opensource/opensource.html > >> > >> Follow this link to subscribe/unsubscribe: > >> http://public.kitware.com/mailman/listinfo/cmake > >> > From cedric.doucet at inria.fr Thu Apr 23 08:01:54 2015 From: cedric.doucet at inria.fr (Cedric Doucet) Date: Thu, 23 Apr 2015 14:01:54 +0200 (CEST) Subject: [CMake] Don't download external projects again after calling "make clean" In-Reply-To: References: <1351653491.156868.1428915508943.JavaMail.zimbra@inria.fr> <871275596.2148003.1429357111569.JavaMail.zimbra@inria.fr> <1588572917.2149426.1429359332478.JavaMail.zimbra@inria.fr> <1295666502.746483.1429786670655.JavaMail.zimbra@inria.fr> <2145954676.1560.1429788718967.JavaMail.zimbra@inria.fr> Message-ID: <1437570424.13752.1429790514799.JavaMail.zimbra@inria.fr> I don't know why but providing my own STAMP_DIR seems to solve the problem: STAMP_DIR ${EXTERNAL_DIR}/eigen/stamp Hope it helps! C?dric ----- Mail original ----- > De: "David Cole" > ?: "Cedric Doucet" > Cc: cmake at cmake.org > Envoy?: Jeudi 23 Avril 2015 13:56:36 > Objet: Re: [CMake] Don't download external projects again after calling "make clean" > > It looks correct. I don't understand what the error is. It looks like > the download and extract succeeds, but then it simply doesn't move on > to the next step of trying to configure with CMake... > > Does the extracted eigen source tree look like it's a proper un-tarred > eigen source directory? > > Does this simple example work for you? (copied/pasted from another > recent CMake mailing list discussion...) > > # ---------------------------------------------------------------------- > # CMakeLists.txt > > cmake_minimum_required(VERSION 3.2) > project(repro NONE) > > include(ExternalProject) > > ExternalProject_Add(name > GIT_REPOSITORY https://github.com/dlrdave/SmallAndFast.git > GIT_TAG 68c3cebf842aa8a13d659fec428fd85ca3a24307 > CMAKE_ARGS "" > INSTALL_COMMAND "" > ) > > # Possible commits in this repo (most recent first) > # > # 68c3cebf842aa8a13d659fec428fd85ca3a24307 > # a0acdce3a549796ca4424c591c038eeb19e59a72 > # 5e98e304a464946dd34cb4c53eb3dd1fd348781b > # 8ea36ce26a6b00ab839064a6066a984f6d6647f6 > > # END CMakeLists.txt > > > Silly question, but do you need to build eigen, or are you using it as > a header only library? > > And... if you do need to build it, does v3.2.4 of eigen build with > CMake or does it require some other configure command? > > (I've been assuming you've actually built eigen manually, and you're > just trying to automate it with ExternalProject... but now I'm > back-tracking and trying not to assume anything...) > > > HTH, > David C. > > > > > On Thu, Apr 23, 2015 at 7:31 AM, Cedric Doucet > wrote: > > > > Thank you very much. > > Your remarks are very helpful to me to understand how it works. > > > > I hope the following file is now correct: > > > > ================== > > project (example CXX) > > > > set(CMAKE_VERBOSE_MAKEFILE ON) > > > > include(ProcessorCount) > > ProcessorCount(N) > > if(NOT N EQUAL 0) > > set(CMAKE_BUILD_FLAGS -j${N}) > > endif() > > > > include(ExternalProject) > > set(EXTERNAL_DIR ${CMAKE_CURRENT_BINARY_DIR}) > > ExternalProject_Add(eigen > > PREFIX ${EXTERNAL_DIR}/eigen > > DOWNLOAD_DIR /home/cdoucet/Downloads/eigen > > SOURCE_DIR ${EXTERNAL_DIR}/eigen/src > > BINARY_DIR ${EXTERNAL_DIR}/eigen/build > > INSTALL_DIR ${EXTERNAL_DIR}/eigen/install > > URL http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz > > URL_MD5 4d0d77e06fef87b4fcd2c9b72cc8dc55 > > CMAKE_ARGS -D CMAKE_INSTALL_PREFIX= > > ) > > =================== > > > > After deleting /home/cdoucet/Downloads/eigen and all the content of my > > build directory (from where I call "cmake .."), I typed: > > cmake .. > > make > > > > and I still obtain the following error message: > > > > ===================== > > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake > > -H/home/cdoucet/Documents/exemples/cmake/external_project/eigen > > -B/home/cdoucet/Documents/exemples/cmake/external_project/eigen/build > > --check-build-system CMakeFiles/Makefile.cmake 0 > > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E cmake_progress_start > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/CMakeFiles > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/CMakeFiles/progress.marks > > make -f CMakeFiles/Makefile2 all > > make[1]: entrant dans le r?pertoire ? > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? > > make -f CMakeFiles/eigen.dir/build.make CMakeFiles/eigen.dir/depend > > make[2]: entrant dans le r?pertoire ? > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? > > cd /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build && > > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E cmake_depends "Unix > > Makefiles" /home/cdoucet/Documents/exemples/cmake/external_project/eigen > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/CMakeFiles/eigen.dir/DependInfo.cmake > > --color= > > Scanning dependencies of target eigen > > make[2]: quittant le r?pertoire ? > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? > > make -f CMakeFiles/eigen.dir/build.make CMakeFiles/eigen.dir/build > > make[2]: entrant dans le r?pertoire ? > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? > > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E cmake_progress_report > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/CMakeFiles > > 3 > > [ 12%] Creating directories for 'eigen' > > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen/src > > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen/build > > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen/install > > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen/tmp > > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen/src/eigen-stamp > > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory > > /home/cdoucet/Downloads/eigen > > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E touch > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen/src/eigen-stamp/eigen-mkdir > > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E cmake_progress_report > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/CMakeFiles > > 4 > > [ 25%] Performing download step (download, verify and extract) for 'eigen' > > cd > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen > > && /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -P > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen/src/eigen-stamp/download-eigen.cmake > > -- downloading... > > src='http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz' > > dst='/home/cdoucet/Downloads/eigen/3.2.4.tar.gz' > > timeout='none' > > -- [download 100% complete] > > -- [download 0% complete] > > -- [download 1% complete] > > -- [download 2% complete] > > -- [download 3% complete] > > -- [download 4% complete] > > -- [download 5% complete] > > -- [download 7% complete] > > -- [download 8% complete] > > -- [download 9% complete] > > -- [download 10% complete] > > -- [download 11% complete] > > -- [download 12% complete] > > -- [download 13% complete] > > -- [download 14% complete] > > -- [download 15% complete] > > -- [download 17% complete] > > -- [download 18% complete] > > -- [download 19% complete] > > -- [download 20% complete] > > -- [download 21% complete] > > -- [download 22% complete] > > -- [download 23% complete] > > -- [download 24% complete] > > -- [download 25% complete] > > -- [download 27% complete] > > -- [download 28% complete] > > -- [download 29% complete] > > -- [download 30% complete] > > -- [download 31% complete] > > -- [download 32% complete] > > -- [download 33% complete] > > -- [download 34% complete] > > -- [download 35% complete] > > -- [download 36% complete] > > -- [download 38% complete] > > -- [download 39% complete] > > -- [download 40% complete] > > -- [download 41% complete] > > -- [download 42% complete] > > -- [download 43% complete] > > -- [download 44% complete] > > -- [download 45% complete] > > -- [download 46% complete] > > -- [download 48% complete] > > -- [download 49% complete] > > -- [download 50% complete] > > -- [download 51% complete] > > -- [download 52% complete] > > -- [download 53% complete] > > -- [download 54% complete] > > -- [download 55% complete] > > -- [download 56% complete] > > -- [download 57% complete] > > -- [download 59% complete] > > -- [download 60% complete] > > -- [download 61% complete] > > -- [download 62% complete] > > -- [download 63% complete] > > -- [download 64% complete] > > -- [download 65% complete] > > -- [download 66% complete] > > -- [download 67% complete] > > -- [download 69% complete] > > -- [download 70% complete] > > -- [download 71% complete] > > -- [download 72% complete] > > -- [download 73% complete] > > -- [download 74% complete] > > -- [download 75% complete] > > -- [download 76% complete] > > -- [download 77% complete] > > -- [download 78% complete] > > -- [download 80% complete] > > -- [download 81% complete] > > -- [download 82% complete] > > -- [download 83% complete] > > -- [download 84% complete] > > -- [download 85% complete] > > -- [download 86% complete] > > -- [download 87% complete] > > -- [download 88% complete] > > -- [download 90% complete] > > -- [download 91% complete] > > -- [download 92% complete] > > -- [download 93% complete] > > -- [download 94% complete] > > -- [download 95% complete] > > -- [download 96% complete] > > -- [download 97% complete] > > -- [download 98% complete] > > -- [download 99% complete] > > -- [download 100% complete] > > -- downloading... done > > cd > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen > > && /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -P > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen/src/eigen-stamp/verify-eigen.cmake > > -- verifying file... > > file='/home/cdoucet/Downloads/eigen/3.2.4.tar.gz' > > -- verifying file... done > > cd > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen > > && /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -P > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen/src/eigen-stamp/extract-eigen.cmake > > -- extracting... > > src='/home/cdoucet/Downloads/eigen/3.2.4.tar.gz' > > dst='/home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen/src' > > -- extracting... [tar xfz] > > -- extracting... [analysis] > > -- extracting... [rename] > > -- extracting... [clean up] > > -- extracting... done > > cd > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen > > && /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E touch > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen/src/eigen-stamp/eigen-download > > make[2]: *** [eigen/src/eigen-stamp/eigen-download] Erreur 1 > > make[2]: quittant le r?pertoire ? > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? > > make[1]: *** [CMakeFiles/eigen.dir/all] Erreur 2 > > make[1]: quittant le r?pertoire ? > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? > > make: *** [all] Erreur 2 > > > > ===================== > > > > > > > > ----- Mail original ----- > >> De: "David Cole" > >> ?: "Cedric Doucet" > >> Cc: cmake at cmake.org > >> Envoy?: Jeudi 23 Avril 2015 13:14:35 > >> Objet: Re: [CMake] Don't download external projects again after calling > >> "make clean" > >> > >> I don't understand what the error is here, but here are some comments: > >> > >> (1) > >> CMAKE_INSTALL_PREFIX=$ > >> > >> The $ is unnecessary and incorrect in this context. The literal string > >> is the thing that ExternalProject will substitute when > >> it is processed into custom commands... > >> > >> (2) > >> ONLY the DOWNLOAD_DIR parameter should be in an "external" (outside of > >> your build tree) directory, to avoid re-downloading the exact same > >> tar.gz file over and over again. The source tree and the build tree of > >> the project should be in your build tree somewhere. > >> > >> (3) > >> CONFIGURE_COMMAND cd && cmake should be unnecessary... > >> The configure command is run in the binary dir by default. Instead, > >> you should be able to use: > >> > >> CMAKE_ARGS -D CMAKE_INSTALL_PREFIX= > >> > >> The binary dir is the working directory for configure, build and > >> install commands. And the is added automatically when you > >> use CMAKE_ARGS with the default cmake CONFIGURE_COMMAND rather than > >> specifying your own. > >> > >> > >> Make those changes and try again with one more fresh build (i.e. -- > >> blow away the whole /home/cdoucet/Downloads/eigen directory and start > >> clean...) > >> > >> Let us know if you still have an error after making those changes. > >> > >> > >> HTH, > >> David C. > >> > >> > >> > >> On Thu, Apr 23, 2015 at 6:57 AM, Cedric Doucet > >> wrote: > >> > Hello David, > >> > > >> > I am using CMake 3.2.2. > >> > I installed CMake from the sources because I use "modules" to manage my > >> > libraries. > >> > But it's ok now: I modified the installation so that to support https. > >> > > >> > Unfortunately, I still have a problem. :( > >> > Maybe you could help me! > >> > > >> > Here is my CMakeLists.txt: > >> > > >> > ============= > >> > > >> > cmake_minimum_required (VERSION 2.6) > >> > > >> > project (example CXX) > >> > > >> > set(CMAKE_VERBOSE_MAKEFILE ON) > >> > > >> > include(ProcessorCount) > >> > ProcessorCount(N) > >> > if(NOT N EQUAL 0) > >> > set(CMAKE_BUILD_FLAGS -j${N}) > >> > endif() > >> > > >> > include(ExternalProject) > >> > set(EXTERNAL_DIR /home/cdoucet/Downloads) > >> > ExternalProject_Add(eigen > >> > PREFIX ${EXTERNAL_DIR}/eigen > >> > DOWNLOAD_DIR > >> > ${EXTERNAL_DIR}/eigen/download > >> > SOURCE_DIR ${EXTERNAL_DIR}/eigen/src > >> > BINARY_DIR > >> > ${EXTERNAL_DIR}/eigen/build > >> > INSTALL_DIR > >> > ${EXTERNAL_DIR}/eigen/install > >> > URL > >> > http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz > >> > URL_MD5 > >> > 4d0d77e06fef87b4fcd2c9b72cc8dc55 > >> > CONFIGURE_COMMAND cd && > >> > cmake -D CMAKE_INSTALL_PREFIX=$ > >> > ) > >> > > >> > ============= > >> > > >> > And here is the error message: > >> > > >> > ===================== > >> > > >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake > >> > -H/home/cdoucet/Documents/exemples/cmake/external_project/eigen > >> > -B/home/cdoucet/Documents/exemples/cmake/external_project/eigen/build > >> > --check-build-system CMakeFiles/Makefile.cmake 0 > >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E cmake_progress_start > >> > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/CMakeFiles > >> > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/CMakeFiles/progress.marks > >> > make -f CMakeFiles/Makefile2 all > >> > make[1]: entrant dans le r?pertoire ? > >> > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? > >> > make -f CMakeFiles/eigen.dir/build.make CMakeFiles/eigen.dir/depend > >> > make[2]: entrant dans le r?pertoire ? > >> > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? > >> > cd /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build > >> > && > >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E cmake_depends "Unix > >> > Makefiles" /home/cdoucet/Documents/exemples/cmake/external_project/eigen > >> > /home/cdoucet/Documents/exemples/cmake/external_project/eigen > >> > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build > >> > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build > >> > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/CMakeFiles/eigen.dir/DependInfo.cmake > >> > --color= > >> > make[2]: quittant le r?pertoire ? > >> > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? > >> > make -f CMakeFiles/eigen.dir/build.make CMakeFiles/eigen.dir/build > >> > make[2]: entrant dans le r?pertoire ? > >> > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? > >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E cmake_progress_report > >> > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/CMakeFiles > >> > 3 > >> > [ 12%] Creating directories for 'eigen' > >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory > >> > /home/cdoucet/Downloads/eigen/src > >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory > >> > /home/cdoucet/Downloads/eigen/build > >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory > >> > /home/cdoucet/Downloads/eigen/install > >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory > >> > /home/cdoucet/Downloads/eigen/tmp > >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory > >> > /home/cdoucet/Downloads/eigen/src/eigen-stamp > >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory > >> > /home/cdoucet/Downloads/eigen/download > >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E touch > >> > /home/cdoucet/Downloads/eigen/src/eigen-stamp/eigen-mkdir > >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E cmake_progress_report > >> > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/CMakeFiles > >> > 4 > >> > [ 25%] Performing download step (download, verify and extract) for > >> > 'eigen' > >> > cd /home/cdoucet/Downloads/eigen && > >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -P > >> > /home/cdoucet/Downloads/eigen/src/eigen-stamp/download-eigen.cmake > >> > -- downloading... > >> > src='http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz' > >> > dst='/home/cdoucet/Downloads/eigen/download/3.2.4.tar.gz' > >> > timeout='none' > >> > -- [download 100% complete] > >> > -- [download 0% complete] > >> > -- [download 1% complete] > >> > -- [download 2% complete] > >> > -- [download 3% complete] > >> > -- [download 4% complete] > >> > -- [download 5% complete] > >> > -- [download 7% complete] > >> > -- [download 8% complete] > >> > -- [download 9% complete] > >> > -- [download 10% complete] > >> > -- [download 11% complete] > >> > -- [download 12% complete] > >> > -- [download 13% complete] > >> > -- [download 14% complete] > >> > -- [download 15% complete] > >> > -- [download 17% complete] > >> > -- [download 18% complete] > >> > -- [download 19% complete] > >> > -- [download 20% complete] > >> > -- [download 21% complete] > >> > -- [download 22% complete] > >> > -- [download 23% complete] > >> > -- [download 24% complete] > >> > -- [download 25% complete] > >> > -- [download 27% complete] > >> > -- [download 28% complete] > >> > -- [download 29% complete] > >> > -- [download 30% complete] > >> > -- [download 31% complete] > >> > -- [download 32% complete] > >> > -- [download 33% complete] > >> > -- [download 34% complete] > >> > -- [download 35% complete] > >> > -- [download 36% complete] > >> > -- [download 38% complete] > >> > -- [download 39% complete] > >> > -- [download 40% complete] > >> > -- [download 41% complete] > >> > -- [download 42% complete] > >> > -- [download 43% complete] > >> > -- [download 44% complete] > >> > -- [download 45% complete] > >> > -- [download 46% complete] > >> > -- [download 48% complete] > >> > -- [download 49% complete] > >> > -- [download 50% complete] > >> > -- [download 51% complete] > >> > -- [download 52% complete] > >> > -- [download 53% complete] > >> > -- [download 54% complete] > >> > -- [download 55% complete] > >> > -- [download 56% complete] > >> > -- [download 57% complete] > >> > -- [download 59% complete] > >> > -- [download 60% complete] > >> > -- [download 61% complete] > >> > -- [download 62% complete] > >> > -- [download 63% complete] > >> > -- [download 64% complete] > >> > -- [download 65% complete] > >> > -- [download 66% complete] > >> > -- [download 67% complete] > >> > -- [download 69% complete] > >> > -- [download 70% complete] > >> > -- [download 71% complete] > >> > -- [download 72% complete] > >> > -- [download 73% complete] > >> > -- [download 74% complete] > >> > -- [download 75% complete] > >> > -- [download 76% complete] > >> > -- [download 77% complete] > >> > -- [download 78% complete] > >> > -- [download 80% complete] > >> > -- [download 81% complete] > >> > -- [download 82% complete] > >> > -- [download 83% complete] > >> > -- [download 84% complete] > >> > -- [download 85% complete] > >> > -- [download 86% complete] > >> > -- [download 87% complete] > >> > -- [download 88% complete] > >> > -- [download 90% complete] > >> > -- [download 91% complete] > >> > -- [download 92% complete] > >> > -- [download 93% complete] > >> > -- [download 94% complete] > >> > -- [download 95% complete] > >> > -- [download 96% complete] > >> > -- [download 97% complete] > >> > -- [download 98% complete] > >> > -- [download 99% complete] > >> > -- [download 100% complete] > >> > -- downloading... done > >> > cd /home/cdoucet/Downloads/eigen && > >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -P > >> > /home/cdoucet/Downloads/eigen/src/eigen-stamp/verify-eigen.cmake > >> > -- verifying file... > >> > file='/home/cdoucet/Downloads/eigen/download/3.2.4.tar.gz' > >> > -- verifying file... done > >> > cd /home/cdoucet/Downloads/eigen && > >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -P > >> > /home/cdoucet/Downloads/eigen/src/eigen-stamp/extract-eigen.cmake > >> > -- extracting... > >> > src='/home/cdoucet/Downloads/eigen/download/3.2.4.tar.gz' > >> > dst='/home/cdoucet/Downloads/eigen/src' > >> > -- extracting... [tar xfz] > >> > -- extracting... [analysis] > >> > -- extracting... [rename] > >> > -- extracting... [clean up] > >> > -- extracting... done > >> > cd /home/cdoucet/Downloads/eigen && > >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E touch > >> > /home/cdoucet/Downloads/eigen/src/eigen-stamp/eigen-download > >> > make[2]: *** > >> > [/home/cdoucet/Downloads/eigen/src/eigen-stamp/eigen-download] > >> > Erreur 1 > >> > make[2]: quittant le r?pertoire ? > >> > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? > >> > make[1]: *** [CMakeFiles/eigen.dir/all] Erreur 2 > >> > make[1]: quittant le r?pertoire ? > >> > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? > >> > make: *** [all] Erreur 2 > >> > > >> > ===================== > >> > > >> > > >> > > >> > ________________________________ > >> > > >> > De: "David Cole" > >> > ?: "Cedric Doucet" > >> > Cc: cmake at cmake.org > >> > Envoy?: Samedi 18 Avril 2015 20:39:57 > >> > > >> > Objet: Re: [CMake] Don't download external projects again after calling > >> > "make clean" > >> > > >> > What version of CMake are you using? All the modern pre-built CMake > >> > installations should support https without extra effort on your part. > >> > Are > >> > you using a pre-built version from somewhere or are you building CMake > >> > yourself? > >> > > >> > > >> > On Saturday, April 18, 2015, Cedric Doucet > >> > wrote: > >> >> > >> >> > >> >> Ok it seems the answer to my problem is here: > >> >> http://www.cmake.org/pipermail/cmake/2010-December/041295.html > >> >> I will try it. > >> >> > >> >> ----- Mail original ----- > >> >> > De: "Cedric Doucet" > >> >> > ?: cmake at cmake.org > >> >> > Envoy?: Samedi 18 Avril 2015 13:38:31 > >> >> > Objet: Re: [CMake] Don't download external projects again after > >> >> > calling > >> >> > "make clean" > >> >> > > >> >> > > >> >> > I have just tried to install curl to get https support. > >> >> > To do that, I have followed the steps below: > >> >> > > >> >> > 1. Installation of openssl: > >> >> > 1.a. ./config --prefix=/my/openssl/path > >> >> > 1.b. make > >> >> > 1.c. make test > >> >> > 1.d. make install > >> >> > 2. Installation of curl > >> >> > 2.a. ./configure --prefix=/my/curl/path > >> >> > --with-ssl=/my/openssl/path/lib > >> >> > 2.b. make > >> >> > 2.c. make install > >> >> > > >> >> > I have also prepend PATH with /my/curl/path/bin. > >> >> > However, the error remains. > >> >> > It seems that my version of curl (7.41.0) is not taken into acount > >> >> > because I > >> >> > have still this line in the error message: > >> >> > User-Agent: curl/7.38.0 > >> >> > I tried to remove all previous of curl and libcurl but it does not > >> >> > change > >> >> > anything. > >> >> > > >> >> > Could you help me? > >> >> > > >> >> > C?dric > >> >> > > >> >> > > >> >> > ----- Mail original ----- > >> >> > > De: "Cedric Doucet" > >> >> > > ?: "David Cole" > >> >> > > Cc: cmake at cmake.org > >> >> > > Envoy?: Samedi 18 Avril 2015 13:00:28 > >> >> > > Objet: Re: [CMake] Don't download external projects again after > >> >> > > calling > >> >> > > "make clean" > >> >> > > > >> >> > > > >> >> > > Hello David, > >> >> > > > >> >> > > thank you very much. > >> >> > > Unfortunately, I get the following error message if I remove my > >> >> > > download > >> >> > > command: > >> >> > > > >> >> > > -- downloading... > >> >> > > src='http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz' > >> >> > > dst='/home/cdoucet/Downloads/eigen/download/3.2.4.tar.gz' > >> >> > > timeout='none' > >> >> > > -- [download 100% complete] > >> >> > > CMake Error at src/eigen-stamp/download-eigen.cmake:27 (message): > >> >> > > error: downloading > >> >> > > 'http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz' > >> >> > > failed > >> >> > > > >> >> > > status_code: 1 > >> >> > > status_string: "Unsupported protocol" > >> >> > > log: Hostname was NOT found in DNS cache > >> >> > > Trying 131.103.20.167... > >> >> > > > >> >> > > Connected to bitbucket.org (131.103.20.167) port 80 (#0) > >> >> > > > >> >> > > GET /eigen/eigen/get/3.2.4.tar.gz HTTP/1.1 > >> >> > > > >> >> > > User-Agent: curl/7.38.0 > >> >> > > > >> >> > > Host: bitbucket.org > >> >> > > > >> >> > > Accept: */* > >> >> > > > >> >> > > > >> >> > > > >> >> > > HTTP/1.1 301 Moved Permanently > >> >> > > > >> >> > > Server nginx/1.6.2 is not blacklisted > >> >> > > > >> >> > > Server: nginx/1.6.2 > >> >> > > > >> >> > > Date: Sat, 18 Apr 2015 10:55:20 GMT > >> >> > > > >> >> > > Content-Type: text/html > >> >> > > > >> >> > > Content-Length: 184 > >> >> > > > >> >> > > Location: https://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz > >> >> > > > >> >> > > > >> >> > > > >> >> > > Ignoring the response-body > >> >> > > > >> >> > > > >> >> > > > >> >> > > 301 Moved Permanently > >> >> > > > >> >> > > > >> >> > > > >> >> > >

301 Moved Permanently

> >> >> > > > >> >> > >
nginx/1.6.2
> >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > Connection #0 to host bitbucket.org left intact > >> >> > > > >> >> > > Issue another request to this URL: > >> >> > > 'https://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz' > >> >> > > > >> >> > > Protocol "https" not supported or disabled in libcurl > >> >> > > > >> >> > > Closing connection -1 > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > ----- Mail original ----- > >> >> > > > De: "David Cole" > >> >> > > > ?: "Cedric Doucet" > >> >> > > > Cc: cmake at cmake.org > >> >> > > > Envoy?: Vendredi 17 Avril 2015 13:21:08 > >> >> > > > Objet: Re: [CMake] Don't download external projects again after > >> >> > > > calling > >> >> > > > "make clean" > >> >> > > > > >> >> > > > Eliminate your DOWNLOAD_COMMAND. CMake knows how to do it with > >> >> > > > just > >> >> > > > the URL_MD5, DOWNLOAD_DIR and SOURCE_DIR information.... > >> >> > > > > >> >> > > > HTH, > >> >> > > > David > >> >> > > > > >> >> > > > > >> >> > > > On Fri, Apr 17, 2015 at 1:32 AM, Cedric Doucet > >> >> > > > > >> >> > > > wrote: > >> >> > > > > > >> >> > > > > Hello David, > >> >> > > > > > >> >> > > > > thank you very much for your help. > >> >> > > > > > >> >> > > > > Unfortunately I may do something wrong because it does not > >> >> > > > > work. > >> >> > > > > After cleaning, the library is downloaded again. > >> >> > > > > > >> >> > > > > I guess my mistake comes from the fact I do not understand the > >> >> > > > > role of > >> >> > > > > URL_MD5. > >> >> > > > > Below is a simple example where downloading and installing is > >> >> > > > > very > >> >> > > > > fast. > >> >> > > > > You just have to replace the value of EXTERNAL_DIR by the path > >> >> > > > > to > >> >> > > > > your > >> >> > > > > own > >> >> > > > > "Downloads" repository. > >> >> > > > > I tried to put URL in my DOWNLOAD_COMMAND but the call "wget > >> >> > > > > " > >> >> > > > > does > >> >> > > > > not seem to be understood by the wget command. > >> >> > > > > > >> >> > > > > Thanks again! > >> >> > > > > > >> >> > > > > C?dric > >> >> > > > > > >> >> > > > > > >> >> > > > > -------------------------------------------------------------------------- > >> >> > > > > cmake_minimum_required (VERSION 2.6) > >> >> > > > > > >> >> > > > > project (example CXX) > >> >> > > > > > >> >> > > > > set(CMAKE_VERBOSE_MAKEFILE ON) > >> >> > > > > > >> >> > > > > include(ProcessorCount) > >> >> > > > > ProcessorCount(N) > >> >> > > > > if(NOT N EQUAL 0) > >> >> > > > > set(CMAKE_BUILD_FLAGS -j${N}) > >> >> > > > > endif() > >> >> > > > > > >> >> > > > > include(ExternalProject) > >> >> > > > > set(EXTERNAL_DIR /home/cdoucet/Downloads) > >> >> > > > > ExternalProject_Add(eigen > >> >> > > > > PREFIX ${EXTERNAL_DIR}/eigen > >> >> > > > > DOWNLOAD_DIR ${EXTERNAL_DIR}/eigen/download > >> >> > > > > SOURCE_DIR ${EXTERNAL_DIR}/eigen/src > >> >> > > > > BINARY_DIR ${EXTERNAL_DIR}/eigen/build > >> >> > > > > INSTALL_DIR ${EXTERNAL_DIR}/eigen/install > >> >> > > > > URL > >> >> > > > > > >> >> > > > > http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz > >> >> > > > > URL_MD5 ccb18a771f678b38a3d33c321a8e7daf > >> >> > > > > DOWNLOAD_COMMAND wget > >> >> > > > > > >> >> > > > > http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz > >> >> > > > > && > >> >> > > > > tar xvzf 3.2.4.tar.gz -C > >> >> > > > > --strip-components=1 > >> >> > > > > CONFIGURE_COMMAND cd && cmake > >> >> > > > > -D > >> >> > > > > CMAKE_INSTALL_PREFIX=$ > >> >> > > > > > >> >> > > > > ) > >> >> > > > > > >> >> > > > > ------------------------------------------------------------------------------ > >> >> > > > > > >> >> > > > > > >> >> > > > > > >> >> > > > > ----- Mail original ----- > >> >> > > > >> De: "David Cole" > >> >> > > > >> ?: "Cedric Doucet" > >> >> > > > >> Cc: cmake at cmake.org > >> >> > > > >> Envoy?: Lundi 13 Avril 2015 12:40:34 > >> >> > > > >> Objet: Re: [CMake] Don't download external projects again > >> >> > > > >> after > >> >> > > > >> calling > >> >> > > > >> "make clean" > >> >> > > > >> > >> >> > > > >> Use the URL_MD5 and DOWNLOAD_DIR arguments to > >> >> > > > >> ExternalProject_Add > >> >> > > > >> to > >> >> > > > >> put the downloaded files into a location outside the build > >> >> > > > >> tree > >> >> > > > >> (perhaps ~/Downloads on Mac/Linux or > >> >> > > > >> $ENV{USERPROFILE}/Downloads > >> >> > > > >> on > >> >> > > > >> Windows). > >> >> > > > >> > >> >> > > > >> With DOWNLOAD_DIR outside the build tree, and the checksums of > >> >> > > > >> the > >> >> > > > >> downloaded files being the same as you've specified via > >> >> > > > >> URL_MD5, > >> >> > > > >> the > >> >> > > > >> download portion will be avoided once there is a local copy of > >> >> > > > >> a > >> >> > > > >> file > >> >> > > > >> available. > >> >> > > > >> > >> >> > > > >> > >> >> > > > >> HTH, > >> >> > > > >> David C. > >> >> > > > >> > >> >> > > > >> > >> >> > > > >> On Mon, Apr 13, 2015 at 5:04 AM, Cedric Doucet > >> >> > > > >> > >> >> > > > >> wrote: > >> >> > > > >> > > >> >> > > > >> > Hello! > >> >> > > > >> > > >> >> > > > >> > I use the ExternalProject_Add function to download > >> >> > > > >> > third-party > >> >> > > > >> > libraries > >> >> > > > >> > of > >> >> > > > >> > a code. > >> >> > > > >> > > >> >> > > > >> > Once a library has been downloaded, I can call "make" as > >> >> > > > >> > many > >> >> > > > >> > times > >> >> > > > >> > as > >> >> > > > >> > I > >> >> > > > >> > want without downloading this library again. > >> >> > > > >> > It seems that CMake detects that the library has already > >> >> > > > >> > been > >> >> > > > >> > downloaded. > >> >> > > > >> > > >> >> > > > >> > However, calling "make clean" seems to destroy this feature. > >> >> > > > >> > Even if my library is not uninstalled during cleaning, > >> >> > > > >> > calling > >> >> > > > >> > "make" > >> >> > > > >> > after > >> >> > > > >> > "make clean" will lead CMake to try download the library > >> >> > > > >> > again. > >> >> > > > >> > > >> >> > > > >> > How could I tell CMake not to download the library again? > >> >> > > > >> > > >> >> > > > >> > Thank you very much for your help! > >> >> > > > >> > > >> >> > > > >> > C?dric > >> >> > > > >> > > >> >> > > > >> > -- > >> >> > > > >> > > >> >> > > > >> > Powered by www.kitware.com > >> >> > > > >> > > >> >> > > > >> > Please keep messages on-topic and check the CMake FAQ at: > >> >> > > > >> > http://www.cmake.org/Wiki/CMake_FAQ > >> >> > > > >> > > >> >> > > > >> > Kitware offers various services to support the CMake > >> >> > > > >> > community. > >> >> > > > >> > For > >> >> > > > >> > more > >> >> > > > >> > information on each offering, please visit: > >> >> > > > >> > > >> >> > > > >> > CMake Support: http://cmake.org/cmake/help/support.html > >> >> > > > >> > CMake Consulting: > >> >> > > > >> > http://cmake.org/cmake/help/consulting.html > >> >> > > > >> > CMake Training Courses: > >> >> > > > >> > http://cmake.org/cmake/help/training.html > >> >> > > > >> > > >> >> > > > >> > Visit other Kitware open-source projects at > >> >> > > > >> > http://www.kitware.com/opensource/opensource.html > >> >> > > > >> > > >> >> > > > >> > Follow this link to subscribe/unsubscribe: > >> >> > > > >> > http://public.kitware.com/mailman/listinfo/cmake > >> >> > > > >> > >> >> > > > > >> >> > > -- > >> >> > > > >> >> > > Powered by www.kitware.com > >> >> > > > >> >> > > Please keep messages on-topic and check the CMake FAQ at: > >> >> > > http://www.cmake.org/Wiki/CMake_FAQ > >> >> > > > >> >> > > Kitware offers various services to support the CMake community. For > >> >> > > more > >> >> > > information on each offering, please visit: > >> >> > > > >> >> > > CMake Support: http://cmake.org/cmake/help/support.html > >> >> > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > >> >> > > CMake Training Courses: http://cmake.org/cmake/help/training.html > >> >> > > > >> >> > > Visit other Kitware open-source projects at > >> >> > > http://www.kitware.com/opensource/opensource.html > >> >> > > > >> >> > > Follow this link to subscribe/unsubscribe: > >> >> > > http://public.kitware.com/mailman/listinfo/cmake > >> >> > > > >> >> > -- > >> >> > > >> >> > Powered by www.kitware.com > >> >> > > >> >> > Please keep messages on-topic and check the CMake FAQ at: > >> >> > http://www.cmake.org/Wiki/CMake_FAQ > >> >> > > >> >> > Kitware offers various services to support the CMake community. For > >> >> > more > >> >> > information on each offering, please visit: > >> >> > > >> >> > CMake Support: http://cmake.org/cmake/help/support.html > >> >> > CMake Consulting: http://cmake.org/cmake/help/consulting.html > >> >> > CMake Training Courses: http://cmake.org/cmake/help/training.html > >> >> > > >> >> > Visit other Kitware open-source projects at > >> >> > http://www.kitware.com/opensource/opensource.html > >> >> > > >> >> > Follow this link to subscribe/unsubscribe: > >> >> > http://public.kitware.com/mailman/listinfo/cmake > >> >> > > >> >> -- > >> >> > >> >> Powered by www.kitware.com > >> >> > >> >> Please keep messages on-topic and check the CMake FAQ at: > >> >> http://www.cmake.org/Wiki/CMake_FAQ > >> >> > >> >> Kitware offers various services to support the CMake community. For > >> >> more > >> >> information on each offering, please visit: > >> >> > >> >> CMake Support: http://cmake.org/cmake/help/support.html > >> >> CMake Consulting: http://cmake.org/cmake/help/consulting.html > >> >> CMake Training Courses: http://cmake.org/cmake/help/training.html > >> >> > >> >> Visit other Kitware open-source projects at > >> >> http://www.kitware.com/opensource/opensource.html > >> >> > >> >> Follow this link to subscribe/unsubscribe: > >> >> http://public.kitware.com/mailman/listinfo/cmake > >> > > >> > > >> > > >> > -- > >> > > >> > Powered by www.kitware.com > >> > > >> > Please keep messages on-topic and check the CMake FAQ at: > >> > http://www.cmake.org/Wiki/CMake_FAQ > >> > > >> > Kitware offers various services to support the CMake community. For more > >> > information on each offering, please visit: > >> > > >> > CMake Support: http://cmake.org/cmake/help/support.html > >> > CMake Consulting: http://cmake.org/cmake/help/consulting.html > >> > CMake Training Courses: http://cmake.org/cmake/help/training.html > >> > > >> > Visit other Kitware open-source projects at > >> > http://www.kitware.com/opensource/opensource.html > >> > > >> > Follow this link to subscribe/unsubscribe: > >> > http://public.kitware.com/mailman/listinfo/cmake > >> > > From cedric.doucet at inria.fr Thu Apr 23 08:14:59 2015 From: cedric.doucet at inria.fr (Cedric Doucet) Date: Thu, 23 Apr 2015 14:14:59 +0200 (CEST) Subject: [CMake] Don't download external projects again after calling "make clean" In-Reply-To: <1437570424.13752.1429790514799.JavaMail.zimbra@inria.fr> References: <1351653491.156868.1428915508943.JavaMail.zimbra@inria.fr> <1588572917.2149426.1429359332478.JavaMail.zimbra@inria.fr> <1295666502.746483.1429786670655.JavaMail.zimbra@inria.fr> <2145954676.1560.1429788718967.JavaMail.zimbra@inria.fr> <1437570424.13752.1429790514799.JavaMail.zimbra@inria.fr> Message-ID: <1807473365.18169.1429791299749.JavaMail.zimbra@inria.fr> > > Does the extracted eigen source tree look like it's a proper un-tarred > > eigen source directory? Yes, everything seems ok. > > Does this simple example work for you? (copied/pasted from another > > recent CMake mailing list discussion...) Yes, it works! > > Silly question, but do you need to build eigen, or are you using it as > > a header only library? Your question is not silly! Indeed, eigen is a header only library. So, you can copy and paste these header files wherever you want to install eigen. However, my goal is to provide a simple way to install a code which depends on external libraries. By 'simple', I mean users/developpers may just have to type the classical combo 'cmake/make/make install' to use the code. They are not expected to download and install anything by themselves. C?dric ----- Mail original ----- > De: "Cedric Doucet" > ?: cmake at cmake.org > Envoy?: Jeudi 23 Avril 2015 14:01:54 > Objet: Re: [CMake] Don't download external projects again after calling "make clean" > > > I don't know why but providing my own STAMP_DIR seems to solve the problem: > > STAMP_DIR ${EXTERNAL_DIR}/eigen/stamp > > Hope it helps! > > C?dric > > ----- Mail original ----- > > De: "David Cole" > > ?: "Cedric Doucet" > > Cc: cmake at cmake.org > > Envoy?: Jeudi 23 Avril 2015 13:56:36 > > Objet: Re: [CMake] Don't download external projects again after calling > > "make clean" > > > > It looks correct. I don't understand what the error is. It looks like > > the download and extract succeeds, but then it simply doesn't move on > > to the next step of trying to configure with CMake... > > > > Does the extracted eigen source tree look like it's a proper un-tarred > > eigen source directory? > > > > Does this simple example work for you? (copied/pasted from another > > recent CMake mailing list discussion...) > > > > # ---------------------------------------------------------------------- > > # CMakeLists.txt > > > > cmake_minimum_required(VERSION 3.2) > > project(repro NONE) > > > > include(ExternalProject) > > > > ExternalProject_Add(name > > GIT_REPOSITORY https://github.com/dlrdave/SmallAndFast.git > > GIT_TAG 68c3cebf842aa8a13d659fec428fd85ca3a24307 > > CMAKE_ARGS "" > > INSTALL_COMMAND "" > > ) > > > > # Possible commits in this repo (most recent first) > > # > > # 68c3cebf842aa8a13d659fec428fd85ca3a24307 > > # a0acdce3a549796ca4424c591c038eeb19e59a72 > > # 5e98e304a464946dd34cb4c53eb3dd1fd348781b > > # 8ea36ce26a6b00ab839064a6066a984f6d6647f6 > > > > # END CMakeLists.txt > > > > > > Silly question, but do you need to build eigen, or are you using it as > > a header only library? > > > > And... if you do need to build it, does v3.2.4 of eigen build with > > CMake or does it require some other configure command? > > > > (I've been assuming you've actually built eigen manually, and you're > > just trying to automate it with ExternalProject... but now I'm > > back-tracking and trying not to assume anything...) > > > > > > HTH, > > David C. > > > > > > > > > > On Thu, Apr 23, 2015 at 7:31 AM, Cedric Doucet > > wrote: > > > > > > Thank you very much. > > > Your remarks are very helpful to me to understand how it works. > > > > > > I hope the following file is now correct: > > > > > > ================== > > > project (example CXX) > > > > > > set(CMAKE_VERBOSE_MAKEFILE ON) > > > > > > include(ProcessorCount) > > > ProcessorCount(N) > > > if(NOT N EQUAL 0) > > > set(CMAKE_BUILD_FLAGS -j${N}) > > > endif() > > > > > > include(ExternalProject) > > > set(EXTERNAL_DIR ${CMAKE_CURRENT_BINARY_DIR}) > > > ExternalProject_Add(eigen > > > PREFIX ${EXTERNAL_DIR}/eigen > > > DOWNLOAD_DIR /home/cdoucet/Downloads/eigen > > > SOURCE_DIR ${EXTERNAL_DIR}/eigen/src > > > BINARY_DIR ${EXTERNAL_DIR}/eigen/build > > > INSTALL_DIR ${EXTERNAL_DIR}/eigen/install > > > URL http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz > > > URL_MD5 4d0d77e06fef87b4fcd2c9b72cc8dc55 > > > CMAKE_ARGS -D CMAKE_INSTALL_PREFIX= > > > ) > > > =================== > > > > > > After deleting /home/cdoucet/Downloads/eigen and all the content of my > > > build directory (from where I call "cmake .."), I typed: > > > cmake .. > > > make > > > > > > and I still obtain the following error message: > > > > > > ===================== > > > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake > > > -H/home/cdoucet/Documents/exemples/cmake/external_project/eigen > > > -B/home/cdoucet/Documents/exemples/cmake/external_project/eigen/build > > > --check-build-system CMakeFiles/Makefile.cmake 0 > > > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E cmake_progress_start > > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/CMakeFiles > > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/CMakeFiles/progress.marks > > > make -f CMakeFiles/Makefile2 all > > > make[1]: entrant dans le r?pertoire ? > > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? > > > make -f CMakeFiles/eigen.dir/build.make CMakeFiles/eigen.dir/depend > > > make[2]: entrant dans le r?pertoire ? > > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? > > > cd /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build && > > > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E cmake_depends "Unix > > > Makefiles" /home/cdoucet/Documents/exemples/cmake/external_project/eigen > > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen > > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build > > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build > > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/CMakeFiles/eigen.dir/DependInfo.cmake > > > --color= > > > Scanning dependencies of target eigen > > > make[2]: quittant le r?pertoire ? > > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? > > > make -f CMakeFiles/eigen.dir/build.make CMakeFiles/eigen.dir/build > > > make[2]: entrant dans le r?pertoire ? > > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? > > > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E cmake_progress_report > > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/CMakeFiles > > > 3 > > > [ 12%] Creating directories for 'eigen' > > > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory > > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen/src > > > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory > > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen/build > > > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory > > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen/install > > > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory > > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen/tmp > > > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory > > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen/src/eigen-stamp > > > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory > > > /home/cdoucet/Downloads/eigen > > > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E touch > > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen/src/eigen-stamp/eigen-mkdir > > > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E cmake_progress_report > > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/CMakeFiles > > > 4 > > > [ 25%] Performing download step (download, verify and extract) for > > > 'eigen' > > > cd > > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen > > > && /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -P > > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen/src/eigen-stamp/download-eigen.cmake > > > -- downloading... > > > src='http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz' > > > dst='/home/cdoucet/Downloads/eigen/3.2.4.tar.gz' > > > timeout='none' > > > -- [download 100% complete] > > > -- [download 0% complete] > > > -- [download 1% complete] > > > -- [download 2% complete] > > > -- [download 3% complete] > > > -- [download 4% complete] > > > -- [download 5% complete] > > > -- [download 7% complete] > > > -- [download 8% complete] > > > -- [download 9% complete] > > > -- [download 10% complete] > > > -- [download 11% complete] > > > -- [download 12% complete] > > > -- [download 13% complete] > > > -- [download 14% complete] > > > -- [download 15% complete] > > > -- [download 17% complete] > > > -- [download 18% complete] > > > -- [download 19% complete] > > > -- [download 20% complete] > > > -- [download 21% complete] > > > -- [download 22% complete] > > > -- [download 23% complete] > > > -- [download 24% complete] > > > -- [download 25% complete] > > > -- [download 27% complete] > > > -- [download 28% complete] > > > -- [download 29% complete] > > > -- [download 30% complete] > > > -- [download 31% complete] > > > -- [download 32% complete] > > > -- [download 33% complete] > > > -- [download 34% complete] > > > -- [download 35% complete] > > > -- [download 36% complete] > > > -- [download 38% complete] > > > -- [download 39% complete] > > > -- [download 40% complete] > > > -- [download 41% complete] > > > -- [download 42% complete] > > > -- [download 43% complete] > > > -- [download 44% complete] > > > -- [download 45% complete] > > > -- [download 46% complete] > > > -- [download 48% complete] > > > -- [download 49% complete] > > > -- [download 50% complete] > > > -- [download 51% complete] > > > -- [download 52% complete] > > > -- [download 53% complete] > > > -- [download 54% complete] > > > -- [download 55% complete] > > > -- [download 56% complete] > > > -- [download 57% complete] > > > -- [download 59% complete] > > > -- [download 60% complete] > > > -- [download 61% complete] > > > -- [download 62% complete] > > > -- [download 63% complete] > > > -- [download 64% complete] > > > -- [download 65% complete] > > > -- [download 66% complete] > > > -- [download 67% complete] > > > -- [download 69% complete] > > > -- [download 70% complete] > > > -- [download 71% complete] > > > -- [download 72% complete] > > > -- [download 73% complete] > > > -- [download 74% complete] > > > -- [download 75% complete] > > > -- [download 76% complete] > > > -- [download 77% complete] > > > -- [download 78% complete] > > > -- [download 80% complete] > > > -- [download 81% complete] > > > -- [download 82% complete] > > > -- [download 83% complete] > > > -- [download 84% complete] > > > -- [download 85% complete] > > > -- [download 86% complete] > > > -- [download 87% complete] > > > -- [download 88% complete] > > > -- [download 90% complete] > > > -- [download 91% complete] > > > -- [download 92% complete] > > > -- [download 93% complete] > > > -- [download 94% complete] > > > -- [download 95% complete] > > > -- [download 96% complete] > > > -- [download 97% complete] > > > -- [download 98% complete] > > > -- [download 99% complete] > > > -- [download 100% complete] > > > -- downloading... done > > > cd > > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen > > > && /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -P > > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen/src/eigen-stamp/verify-eigen.cmake > > > -- verifying file... > > > file='/home/cdoucet/Downloads/eigen/3.2.4.tar.gz' > > > -- verifying file... done > > > cd > > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen > > > && /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -P > > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen/src/eigen-stamp/extract-eigen.cmake > > > -- extracting... > > > src='/home/cdoucet/Downloads/eigen/3.2.4.tar.gz' > > > dst='/home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen/src' > > > -- extracting... [tar xfz] > > > -- extracting... [analysis] > > > -- extracting... [rename] > > > -- extracting... [clean up] > > > -- extracting... done > > > cd > > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen > > > && /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E touch > > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen/src/eigen-stamp/eigen-download > > > make[2]: *** [eigen/src/eigen-stamp/eigen-download] Erreur 1 > > > make[2]: quittant le r?pertoire ? > > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? > > > make[1]: *** [CMakeFiles/eigen.dir/all] Erreur 2 > > > make[1]: quittant le r?pertoire ? > > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? > > > make: *** [all] Erreur 2 > > > > > > ===================== > > > > > > > > > > > > ----- Mail original ----- > > >> De: "David Cole" > > >> ?: "Cedric Doucet" > > >> Cc: cmake at cmake.org > > >> Envoy?: Jeudi 23 Avril 2015 13:14:35 > > >> Objet: Re: [CMake] Don't download external projects again after calling > > >> "make clean" > > >> > > >> I don't understand what the error is here, but here are some comments: > > >> > > >> (1) > > >> CMAKE_INSTALL_PREFIX=$ > > >> > > >> The $ is unnecessary and incorrect in this context. The literal string > > >> is the thing that ExternalProject will substitute when > > >> it is processed into custom commands... > > >> > > >> (2) > > >> ONLY the DOWNLOAD_DIR parameter should be in an "external" (outside of > > >> your build tree) directory, to avoid re-downloading the exact same > > >> tar.gz file over and over again. The source tree and the build tree of > > >> the project should be in your build tree somewhere. > > >> > > >> (3) > > >> CONFIGURE_COMMAND cd && cmake should be unnecessary... > > >> The configure command is run in the binary dir by default. Instead, > > >> you should be able to use: > > >> > > >> CMAKE_ARGS -D CMAKE_INSTALL_PREFIX= > > >> > > >> The binary dir is the working directory for configure, build and > > >> install commands. And the is added automatically when you > > >> use CMAKE_ARGS with the default cmake CONFIGURE_COMMAND rather than > > >> specifying your own. > > >> > > >> > > >> Make those changes and try again with one more fresh build (i.e. -- > > >> blow away the whole /home/cdoucet/Downloads/eigen directory and start > > >> clean...) > > >> > > >> Let us know if you still have an error after making those changes. > > >> > > >> > > >> HTH, > > >> David C. > > >> > > >> > > >> > > >> On Thu, Apr 23, 2015 at 6:57 AM, Cedric Doucet > > >> wrote: > > >> > Hello David, > > >> > > > >> > I am using CMake 3.2.2. > > >> > I installed CMake from the sources because I use "modules" to manage > > >> > my > > >> > libraries. > > >> > But it's ok now: I modified the installation so that to support https. > > >> > > > >> > Unfortunately, I still have a problem. :( > > >> > Maybe you could help me! > > >> > > > >> > Here is my CMakeLists.txt: > > >> > > > >> > ============= > > >> > > > >> > cmake_minimum_required (VERSION 2.6) > > >> > > > >> > project (example CXX) > > >> > > > >> > set(CMAKE_VERBOSE_MAKEFILE ON) > > >> > > > >> > include(ProcessorCount) > > >> > ProcessorCount(N) > > >> > if(NOT N EQUAL 0) > > >> > set(CMAKE_BUILD_FLAGS -j${N}) > > >> > endif() > > >> > > > >> > include(ExternalProject) > > >> > set(EXTERNAL_DIR /home/cdoucet/Downloads) > > >> > ExternalProject_Add(eigen > > >> > PREFIX ${EXTERNAL_DIR}/eigen > > >> > DOWNLOAD_DIR > > >> > ${EXTERNAL_DIR}/eigen/download > > >> > SOURCE_DIR > > >> > ${EXTERNAL_DIR}/eigen/src > > >> > BINARY_DIR > > >> > ${EXTERNAL_DIR}/eigen/build > > >> > INSTALL_DIR > > >> > ${EXTERNAL_DIR}/eigen/install > > >> > URL > > >> > http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz > > >> > URL_MD5 > > >> > 4d0d77e06fef87b4fcd2c9b72cc8dc55 > > >> > CONFIGURE_COMMAND cd > > >> > && > > >> > cmake -D CMAKE_INSTALL_PREFIX=$ > > >> > ) > > >> > > > >> > ============= > > >> > > > >> > And here is the error message: > > >> > > > >> > ===================== > > >> > > > >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake > > >> > -H/home/cdoucet/Documents/exemples/cmake/external_project/eigen > > >> > -B/home/cdoucet/Documents/exemples/cmake/external_project/eigen/build > > >> > --check-build-system CMakeFiles/Makefile.cmake 0 > > >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E cmake_progress_start > > >> > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/CMakeFiles > > >> > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/CMakeFiles/progress.marks > > >> > make -f CMakeFiles/Makefile2 all > > >> > make[1]: entrant dans le r?pertoire ? > > >> > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? > > >> > make -f CMakeFiles/eigen.dir/build.make CMakeFiles/eigen.dir/depend > > >> > make[2]: entrant dans le r?pertoire ? > > >> > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? > > >> > cd /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build > > >> > && > > >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E cmake_depends "Unix > > >> > Makefiles" > > >> > /home/cdoucet/Documents/exemples/cmake/external_project/eigen > > >> > /home/cdoucet/Documents/exemples/cmake/external_project/eigen > > >> > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build > > >> > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build > > >> > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/CMakeFiles/eigen.dir/DependInfo.cmake > > >> > --color= > > >> > make[2]: quittant le r?pertoire ? > > >> > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? > > >> > make -f CMakeFiles/eigen.dir/build.make CMakeFiles/eigen.dir/build > > >> > make[2]: entrant dans le r?pertoire ? > > >> > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? > > >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E > > >> > cmake_progress_report > > >> > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/CMakeFiles > > >> > 3 > > >> > [ 12%] Creating directories for 'eigen' > > >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory > > >> > /home/cdoucet/Downloads/eigen/src > > >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory > > >> > /home/cdoucet/Downloads/eigen/build > > >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory > > >> > /home/cdoucet/Downloads/eigen/install > > >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory > > >> > /home/cdoucet/Downloads/eigen/tmp > > >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory > > >> > /home/cdoucet/Downloads/eigen/src/eigen-stamp > > >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory > > >> > /home/cdoucet/Downloads/eigen/download > > >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E touch > > >> > /home/cdoucet/Downloads/eigen/src/eigen-stamp/eigen-mkdir > > >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E > > >> > cmake_progress_report > > >> > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/CMakeFiles > > >> > 4 > > >> > [ 25%] Performing download step (download, verify and extract) for > > >> > 'eigen' > > >> > cd /home/cdoucet/Downloads/eigen && > > >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -P > > >> > /home/cdoucet/Downloads/eigen/src/eigen-stamp/download-eigen.cmake > > >> > -- downloading... > > >> > src='http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz' > > >> > dst='/home/cdoucet/Downloads/eigen/download/3.2.4.tar.gz' > > >> > timeout='none' > > >> > -- [download 100% complete] > > >> > -- [download 0% complete] > > >> > -- [download 1% complete] > > >> > -- [download 2% complete] > > >> > -- [download 3% complete] > > >> > -- [download 4% complete] > > >> > -- [download 5% complete] > > >> > -- [download 7% complete] > > >> > -- [download 8% complete] > > >> > -- [download 9% complete] > > >> > -- [download 10% complete] > > >> > -- [download 11% complete] > > >> > -- [download 12% complete] > > >> > -- [download 13% complete] > > >> > -- [download 14% complete] > > >> > -- [download 15% complete] > > >> > -- [download 17% complete] > > >> > -- [download 18% complete] > > >> > -- [download 19% complete] > > >> > -- [download 20% complete] > > >> > -- [download 21% complete] > > >> > -- [download 22% complete] > > >> > -- [download 23% complete] > > >> > -- [download 24% complete] > > >> > -- [download 25% complete] > > >> > -- [download 27% complete] > > >> > -- [download 28% complete] > > >> > -- [download 29% complete] > > >> > -- [download 30% complete] > > >> > -- [download 31% complete] > > >> > -- [download 32% complete] > > >> > -- [download 33% complete] > > >> > -- [download 34% complete] > > >> > -- [download 35% complete] > > >> > -- [download 36% complete] > > >> > -- [download 38% complete] > > >> > -- [download 39% complete] > > >> > -- [download 40% complete] > > >> > -- [download 41% complete] > > >> > -- [download 42% complete] > > >> > -- [download 43% complete] > > >> > -- [download 44% complete] > > >> > -- [download 45% complete] > > >> > -- [download 46% complete] > > >> > -- [download 48% complete] > > >> > -- [download 49% complete] > > >> > -- [download 50% complete] > > >> > -- [download 51% complete] > > >> > -- [download 52% complete] > > >> > -- [download 53% complete] > > >> > -- [download 54% complete] > > >> > -- [download 55% complete] > > >> > -- [download 56% complete] > > >> > -- [download 57% complete] > > >> > -- [download 59% complete] > > >> > -- [download 60% complete] > > >> > -- [download 61% complete] > > >> > -- [download 62% complete] > > >> > -- [download 63% complete] > > >> > -- [download 64% complete] > > >> > -- [download 65% complete] > > >> > -- [download 66% complete] > > >> > -- [download 67% complete] > > >> > -- [download 69% complete] > > >> > -- [download 70% complete] > > >> > -- [download 71% complete] > > >> > -- [download 72% complete] > > >> > -- [download 73% complete] > > >> > -- [download 74% complete] > > >> > -- [download 75% complete] > > >> > -- [download 76% complete] > > >> > -- [download 77% complete] > > >> > -- [download 78% complete] > > >> > -- [download 80% complete] > > >> > -- [download 81% complete] > > >> > -- [download 82% complete] > > >> > -- [download 83% complete] > > >> > -- [download 84% complete] > > >> > -- [download 85% complete] > > >> > -- [download 86% complete] > > >> > -- [download 87% complete] > > >> > -- [download 88% complete] > > >> > -- [download 90% complete] > > >> > -- [download 91% complete] > > >> > -- [download 92% complete] > > >> > -- [download 93% complete] > > >> > -- [download 94% complete] > > >> > -- [download 95% complete] > > >> > -- [download 96% complete] > > >> > -- [download 97% complete] > > >> > -- [download 98% complete] > > >> > -- [download 99% complete] > > >> > -- [download 100% complete] > > >> > -- downloading... done > > >> > cd /home/cdoucet/Downloads/eigen && > > >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -P > > >> > /home/cdoucet/Downloads/eigen/src/eigen-stamp/verify-eigen.cmake > > >> > -- verifying file... > > >> > file='/home/cdoucet/Downloads/eigen/download/3.2.4.tar.gz' > > >> > -- verifying file... done > > >> > cd /home/cdoucet/Downloads/eigen && > > >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -P > > >> > /home/cdoucet/Downloads/eigen/src/eigen-stamp/extract-eigen.cmake > > >> > -- extracting... > > >> > src='/home/cdoucet/Downloads/eigen/download/3.2.4.tar.gz' > > >> > dst='/home/cdoucet/Downloads/eigen/src' > > >> > -- extracting... [tar xfz] > > >> > -- extracting... [analysis] > > >> > -- extracting... [rename] > > >> > -- extracting... [clean up] > > >> > -- extracting... done > > >> > cd /home/cdoucet/Downloads/eigen && > > >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E touch > > >> > /home/cdoucet/Downloads/eigen/src/eigen-stamp/eigen-download > > >> > make[2]: *** > > >> > [/home/cdoucet/Downloads/eigen/src/eigen-stamp/eigen-download] > > >> > Erreur 1 > > >> > make[2]: quittant le r?pertoire ? > > >> > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? > > >> > make[1]: *** [CMakeFiles/eigen.dir/all] Erreur 2 > > >> > make[1]: quittant le r?pertoire ? > > >> > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? > > >> > make: *** [all] Erreur 2 > > >> > > > >> > ===================== > > >> > > > >> > > > >> > > > >> > ________________________________ > > >> > > > >> > De: "David Cole" > > >> > ?: "Cedric Doucet" > > >> > Cc: cmake at cmake.org > > >> > Envoy?: Samedi 18 Avril 2015 20:39:57 > > >> > > > >> > Objet: Re: [CMake] Don't download external projects again after > > >> > calling > > >> > "make clean" > > >> > > > >> > What version of CMake are you using? All the modern pre-built CMake > > >> > installations should support https without extra effort on your part. > > >> > Are > > >> > you using a pre-built version from somewhere or are you building CMake > > >> > yourself? > > >> > > > >> > > > >> > On Saturday, April 18, 2015, Cedric Doucet > > >> > wrote: > > >> >> > > >> >> > > >> >> Ok it seems the answer to my problem is here: > > >> >> http://www.cmake.org/pipermail/cmake/2010-December/041295.html > > >> >> I will try it. > > >> >> > > >> >> ----- Mail original ----- > > >> >> > De: "Cedric Doucet" > > >> >> > ?: cmake at cmake.org > > >> >> > Envoy?: Samedi 18 Avril 2015 13:38:31 > > >> >> > Objet: Re: [CMake] Don't download external projects again after > > >> >> > calling > > >> >> > "make clean" > > >> >> > > > >> >> > > > >> >> > I have just tried to install curl to get https support. > > >> >> > To do that, I have followed the steps below: > > >> >> > > > >> >> > 1. Installation of openssl: > > >> >> > 1.a. ./config --prefix=/my/openssl/path > > >> >> > 1.b. make > > >> >> > 1.c. make test > > >> >> > 1.d. make install > > >> >> > 2. Installation of curl > > >> >> > 2.a. ./configure --prefix=/my/curl/path > > >> >> > --with-ssl=/my/openssl/path/lib > > >> >> > 2.b. make > > >> >> > 2.c. make install > > >> >> > > > >> >> > I have also prepend PATH with /my/curl/path/bin. > > >> >> > However, the error remains. > > >> >> > It seems that my version of curl (7.41.0) is not taken into acount > > >> >> > because I > > >> >> > have still this line in the error message: > > >> >> > User-Agent: curl/7.38.0 > > >> >> > I tried to remove all previous of curl and libcurl but it does not > > >> >> > change > > >> >> > anything. > > >> >> > > > >> >> > Could you help me? > > >> >> > > > >> >> > C?dric > > >> >> > > > >> >> > > > >> >> > ----- Mail original ----- > > >> >> > > De: "Cedric Doucet" > > >> >> > > ?: "David Cole" > > >> >> > > Cc: cmake at cmake.org > > >> >> > > Envoy?: Samedi 18 Avril 2015 13:00:28 > > >> >> > > Objet: Re: [CMake] Don't download external projects again after > > >> >> > > calling > > >> >> > > "make clean" > > >> >> > > > > >> >> > > > > >> >> > > Hello David, > > >> >> > > > > >> >> > > thank you very much. > > >> >> > > Unfortunately, I get the following error message if I remove my > > >> >> > > download > > >> >> > > command: > > >> >> > > > > >> >> > > -- downloading... > > >> >> > > src='http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz' > > >> >> > > dst='/home/cdoucet/Downloads/eigen/download/3.2.4.tar.gz' > > >> >> > > timeout='none' > > >> >> > > -- [download 100% complete] > > >> >> > > CMake Error at src/eigen-stamp/download-eigen.cmake:27 (message): > > >> >> > > error: downloading > > >> >> > > 'http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz' > > >> >> > > failed > > >> >> > > > > >> >> > > status_code: 1 > > >> >> > > status_string: "Unsupported protocol" > > >> >> > > log: Hostname was NOT found in DNS cache > > >> >> > > Trying 131.103.20.167... > > >> >> > > > > >> >> > > Connected to bitbucket.org (131.103.20.167) port 80 (#0) > > >> >> > > > > >> >> > > GET /eigen/eigen/get/3.2.4.tar.gz HTTP/1.1 > > >> >> > > > > >> >> > > User-Agent: curl/7.38.0 > > >> >> > > > > >> >> > > Host: bitbucket.org > > >> >> > > > > >> >> > > Accept: */* > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > HTTP/1.1 301 Moved Permanently > > >> >> > > > > >> >> > > Server nginx/1.6.2 is not blacklisted > > >> >> > > > > >> >> > > Server: nginx/1.6.2 > > >> >> > > > > >> >> > > Date: Sat, 18 Apr 2015 10:55:20 GMT > > >> >> > > > > >> >> > > Content-Type: text/html > > >> >> > > > > >> >> > > Content-Length: 184 > > >> >> > > > > >> >> > > Location: https://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > Ignoring the response-body > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > 301 Moved Permanently > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > >

301 Moved Permanently

> > >> >> > > > > >> >> > >
nginx/1.6.2
> > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > Connection #0 to host bitbucket.org left intact > > >> >> > > > > >> >> > > Issue another request to this URL: > > >> >> > > 'https://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz' > > >> >> > > > > >> >> > > Protocol "https" not supported or disabled in libcurl > > >> >> > > > > >> >> > > Closing connection -1 > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > ----- Mail original ----- > > >> >> > > > De: "David Cole" > > >> >> > > > ?: "Cedric Doucet" > > >> >> > > > Cc: cmake at cmake.org > > >> >> > > > Envoy?: Vendredi 17 Avril 2015 13:21:08 > > >> >> > > > Objet: Re: [CMake] Don't download external projects again after > > >> >> > > > calling > > >> >> > > > "make clean" > > >> >> > > > > > >> >> > > > Eliminate your DOWNLOAD_COMMAND. CMake knows how to do it with > > >> >> > > > just > > >> >> > > > the URL_MD5, DOWNLOAD_DIR and SOURCE_DIR information.... > > >> >> > > > > > >> >> > > > HTH, > > >> >> > > > David > > >> >> > > > > > >> >> > > > > > >> >> > > > On Fri, Apr 17, 2015 at 1:32 AM, Cedric Doucet > > >> >> > > > > > >> >> > > > wrote: > > >> >> > > > > > > >> >> > > > > Hello David, > > >> >> > > > > > > >> >> > > > > thank you very much for your help. > > >> >> > > > > > > >> >> > > > > Unfortunately I may do something wrong because it does not > > >> >> > > > > work. > > >> >> > > > > After cleaning, the library is downloaded again. > > >> >> > > > > > > >> >> > > > > I guess my mistake comes from the fact I do not understand > > >> >> > > > > the > > >> >> > > > > role of > > >> >> > > > > URL_MD5. > > >> >> > > > > Below is a simple example where downloading and installing is > > >> >> > > > > very > > >> >> > > > > fast. > > >> >> > > > > You just have to replace the value of EXTERNAL_DIR by the > > >> >> > > > > path > > >> >> > > > > to > > >> >> > > > > your > > >> >> > > > > own > > >> >> > > > > "Downloads" repository. > > >> >> > > > > I tried to put URL in my DOWNLOAD_COMMAND but the call "wget > > >> >> > > > > " > > >> >> > > > > does > > >> >> > > > > not seem to be understood by the wget command. > > >> >> > > > > > > >> >> > > > > Thanks again! > > >> >> > > > > > > >> >> > > > > C?dric > > >> >> > > > > > > >> >> > > > > > > >> >> > > > > -------------------------------------------------------------------------- > > >> >> > > > > cmake_minimum_required (VERSION 2.6) > > >> >> > > > > > > >> >> > > > > project (example CXX) > > >> >> > > > > > > >> >> > > > > set(CMAKE_VERBOSE_MAKEFILE ON) > > >> >> > > > > > > >> >> > > > > include(ProcessorCount) > > >> >> > > > > ProcessorCount(N) > > >> >> > > > > if(NOT N EQUAL 0) > > >> >> > > > > set(CMAKE_BUILD_FLAGS -j${N}) > > >> >> > > > > endif() > > >> >> > > > > > > >> >> > > > > include(ExternalProject) > > >> >> > > > > set(EXTERNAL_DIR /home/cdoucet/Downloads) > > >> >> > > > > ExternalProject_Add(eigen > > >> >> > > > > PREFIX ${EXTERNAL_DIR}/eigen > > >> >> > > > > DOWNLOAD_DIR > > >> >> > > > > ${EXTERNAL_DIR}/eigen/download > > >> >> > > > > SOURCE_DIR ${EXTERNAL_DIR}/eigen/src > > >> >> > > > > BINARY_DIR ${EXTERNAL_DIR}/eigen/build > > >> >> > > > > INSTALL_DIR ${EXTERNAL_DIR}/eigen/install > > >> >> > > > > URL > > >> >> > > > > > > >> >> > > > > http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz > > >> >> > > > > URL_MD5 ccb18a771f678b38a3d33c321a8e7daf > > >> >> > > > > DOWNLOAD_COMMAND wget > > >> >> > > > > > > >> >> > > > > http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz > > >> >> > > > > && > > >> >> > > > > tar xvzf 3.2.4.tar.gz -C > > >> >> > > > > --strip-components=1 > > >> >> > > > > CONFIGURE_COMMAND cd && > > >> >> > > > > cmake > > >> >> > > > > -D > > >> >> > > > > CMAKE_INSTALL_PREFIX=$ > > >> >> > > > > > > >> >> > > > > ) > > >> >> > > > > > > >> >> > > > > ------------------------------------------------------------------------------ > > >> >> > > > > > > >> >> > > > > > > >> >> > > > > > > >> >> > > > > ----- Mail original ----- > > >> >> > > > >> De: "David Cole" > > >> >> > > > >> ?: "Cedric Doucet" > > >> >> > > > >> Cc: cmake at cmake.org > > >> >> > > > >> Envoy?: Lundi 13 Avril 2015 12:40:34 > > >> >> > > > >> Objet: Re: [CMake] Don't download external projects again > > >> >> > > > >> after > > >> >> > > > >> calling > > >> >> > > > >> "make clean" > > >> >> > > > >> > > >> >> > > > >> Use the URL_MD5 and DOWNLOAD_DIR arguments to > > >> >> > > > >> ExternalProject_Add > > >> >> > > > >> to > > >> >> > > > >> put the downloaded files into a location outside the build > > >> >> > > > >> tree > > >> >> > > > >> (perhaps ~/Downloads on Mac/Linux or > > >> >> > > > >> $ENV{USERPROFILE}/Downloads > > >> >> > > > >> on > > >> >> > > > >> Windows). > > >> >> > > > >> > > >> >> > > > >> With DOWNLOAD_DIR outside the build tree, and the checksums > > >> >> > > > >> of > > >> >> > > > >> the > > >> >> > > > >> downloaded files being the same as you've specified via > > >> >> > > > >> URL_MD5, > > >> >> > > > >> the > > >> >> > > > >> download portion will be avoided once there is a local copy > > >> >> > > > >> of > > >> >> > > > >> a > > >> >> > > > >> file > > >> >> > > > >> available. > > >> >> > > > >> > > >> >> > > > >> > > >> >> > > > >> HTH, > > >> >> > > > >> David C. > > >> >> > > > >> > > >> >> > > > >> > > >> >> > > > >> On Mon, Apr 13, 2015 at 5:04 AM, Cedric Doucet > > >> >> > > > >> > > >> >> > > > >> wrote: > > >> >> > > > >> > > > >> >> > > > >> > Hello! > > >> >> > > > >> > > > >> >> > > > >> > I use the ExternalProject_Add function to download > > >> >> > > > >> > third-party > > >> >> > > > >> > libraries > > >> >> > > > >> > of > > >> >> > > > >> > a code. > > >> >> > > > >> > > > >> >> > > > >> > Once a library has been downloaded, I can call "make" as > > >> >> > > > >> > many > > >> >> > > > >> > times > > >> >> > > > >> > as > > >> >> > > > >> > I > > >> >> > > > >> > want without downloading this library again. > > >> >> > > > >> > It seems that CMake detects that the library has already > > >> >> > > > >> > been > > >> >> > > > >> > downloaded. > > >> >> > > > >> > > > >> >> > > > >> > However, calling "make clean" seems to destroy this > > >> >> > > > >> > feature. > > >> >> > > > >> > Even if my library is not uninstalled during cleaning, > > >> >> > > > >> > calling > > >> >> > > > >> > "make" > > >> >> > > > >> > after > > >> >> > > > >> > "make clean" will lead CMake to try download the library > > >> >> > > > >> > again. > > >> >> > > > >> > > > >> >> > > > >> > How could I tell CMake not to download the library again? > > >> >> > > > >> > > > >> >> > > > >> > Thank you very much for your help! > > >> >> > > > >> > > > >> >> > > > >> > C?dric > > >> >> > > > >> > > > >> >> > > > >> > -- > > >> >> > > > >> > > > >> >> > > > >> > Powered by www.kitware.com > > >> >> > > > >> > > > >> >> > > > >> > Please keep messages on-topic and check the CMake FAQ at: > > >> >> > > > >> > http://www.cmake.org/Wiki/CMake_FAQ > > >> >> > > > >> > > > >> >> > > > >> > Kitware offers various services to support the CMake > > >> >> > > > >> > community. > > >> >> > > > >> > For > > >> >> > > > >> > more > > >> >> > > > >> > information on each offering, please visit: > > >> >> > > > >> > > > >> >> > > > >> > CMake Support: http://cmake.org/cmake/help/support.html > > >> >> > > > >> > CMake Consulting: > > >> >> > > > >> > http://cmake.org/cmake/help/consulting.html > > >> >> > > > >> > CMake Training Courses: > > >> >> > > > >> > http://cmake.org/cmake/help/training.html > > >> >> > > > >> > > > >> >> > > > >> > Visit other Kitware open-source projects at > > >> >> > > > >> > http://www.kitware.com/opensource/opensource.html > > >> >> > > > >> > > > >> >> > > > >> > Follow this link to subscribe/unsubscribe: > > >> >> > > > >> > http://public.kitware.com/mailman/listinfo/cmake > > >> >> > > > >> > > >> >> > > > > > >> >> > > -- > > >> >> > > > > >> >> > > Powered by www.kitware.com > > >> >> > > > > >> >> > > Please keep messages on-topic and check the CMake FAQ at: > > >> >> > > http://www.cmake.org/Wiki/CMake_FAQ > > >> >> > > > > >> >> > > Kitware offers various services to support the CMake community. > > >> >> > > For > > >> >> > > more > > >> >> > > information on each offering, please visit: > > >> >> > > > > >> >> > > CMake Support: http://cmake.org/cmake/help/support.html > > >> >> > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > >> >> > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > >> >> > > > > >> >> > > Visit other Kitware open-source projects at > > >> >> > > http://www.kitware.com/opensource/opensource.html > > >> >> > > > > >> >> > > Follow this link to subscribe/unsubscribe: > > >> >> > > http://public.kitware.com/mailman/listinfo/cmake > > >> >> > > > > >> >> > -- > > >> >> > > > >> >> > Powered by www.kitware.com > > >> >> > > > >> >> > Please keep messages on-topic and check the CMake FAQ at: > > >> >> > http://www.cmake.org/Wiki/CMake_FAQ > > >> >> > > > >> >> > Kitware offers various services to support the CMake community. For > > >> >> > more > > >> >> > information on each offering, please visit: > > >> >> > > > >> >> > CMake Support: http://cmake.org/cmake/help/support.html > > >> >> > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > >> >> > CMake Training Courses: http://cmake.org/cmake/help/training.html > > >> >> > > > >> >> > Visit other Kitware open-source projects at > > >> >> > http://www.kitware.com/opensource/opensource.html > > >> >> > > > >> >> > Follow this link to subscribe/unsubscribe: > > >> >> > http://public.kitware.com/mailman/listinfo/cmake > > >> >> > > > >> >> -- > > >> >> > > >> >> Powered by www.kitware.com > > >> >> > > >> >> Please keep messages on-topic and check the CMake FAQ at: > > >> >> http://www.cmake.org/Wiki/CMake_FAQ > > >> >> > > >> >> Kitware offers various services to support the CMake community. For > > >> >> more > > >> >> information on each offering, please visit: > > >> >> > > >> >> CMake Support: http://cmake.org/cmake/help/support.html > > >> >> CMake Consulting: http://cmake.org/cmake/help/consulting.html > > >> >> CMake Training Courses: http://cmake.org/cmake/help/training.html > > >> >> > > >> >> Visit other Kitware open-source projects at > > >> >> http://www.kitware.com/opensource/opensource.html > > >> >> > > >> >> Follow this link to subscribe/unsubscribe: > > >> >> http://public.kitware.com/mailman/listinfo/cmake > > >> > > > >> > > > >> > > > >> > -- > > >> > > > >> > Powered by www.kitware.com > > >> > > > >> > Please keep messages on-topic and check the CMake FAQ at: > > >> > http://www.cmake.org/Wiki/CMake_FAQ > > >> > > > >> > Kitware offers various services to support the CMake community. For > > >> > more > > >> > information on each offering, please visit: > > >> > > > >> > CMake Support: http://cmake.org/cmake/help/support.html > > >> > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > >> > CMake Training Courses: http://cmake.org/cmake/help/training.html > > >> > > > >> > Visit other Kitware open-source projects at > > >> > http://www.kitware.com/opensource/opensource.html > > >> > > > >> > Follow this link to subscribe/unsubscribe: > > >> > http://public.kitware.com/mailman/listinfo/cmake > > >> > > > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > > From cedric.doucet at inria.fr Thu Apr 23 08:18:35 2015 From: cedric.doucet at inria.fr (Cedric Doucet) Date: Thu, 23 Apr 2015 14:18:35 +0200 (CEST) Subject: [CMake] Don't download external projects again after calling "make clean" In-Reply-To: <1807473365.18169.1429791299749.JavaMail.zimbra@inria.fr> References: <1351653491.156868.1428915508943.JavaMail.zimbra@inria.fr> <1295666502.746483.1429786670655.JavaMail.zimbra@inria.fr> <2145954676.1560.1429788718967.JavaMail.zimbra@inria.fr> <1437570424.13752.1429790514799.JavaMail.zimbra@inria.fr> <1807473365.18169.1429791299749.JavaMail.zimbra@inria.fr> Message-ID: <1796176861.19324.1429791515366.JavaMail.zimbra@inria.fr> Eigen is just an example of an external library which is very fast to download and install with ExternalProject_Add. It is convenient here to let you check that you have the same problem as mine on your machine. However, I have other external libraries which have to be compiled. ----- Mail original ----- > De: "Cedric Doucet" > ?: cmake at cmake.org > Envoy?: Jeudi 23 Avril 2015 14:14:59 > Objet: Re: [CMake] Don't download external projects again after calling "make clean" > > > > > > Does the extracted eigen source tree look like it's a proper un-tarred > > > eigen source directory? > > Yes, everything seems ok. > > > > Does this simple example work for you? (copied/pasted from another > > > recent CMake mailing list discussion...) > > Yes, it works! > > > > Silly question, but do you need to build eigen, or are you using it as > > > a header only library? > > Your question is not silly! > Indeed, eigen is a header only library. > So, you can copy and paste these header files wherever you want to install > eigen. > However, my goal is to provide a simple way to install a code which depends > on external libraries. > By 'simple', I mean users/developpers may just have to type the classical > combo 'cmake/make/make install' to use the code. > They are not expected to download and install anything by themselves. > > C?dric > > > > ----- Mail original ----- > > De: "Cedric Doucet" > > ?: cmake at cmake.org > > Envoy?: Jeudi 23 Avril 2015 14:01:54 > > Objet: Re: [CMake] Don't download external projects again after calling > > "make clean" > > > > > > I don't know why but providing my own STAMP_DIR seems to solve the problem: > > > > STAMP_DIR ${EXTERNAL_DIR}/eigen/stamp > > > > Hope it helps! > > > > C?dric > > > > ----- Mail original ----- > > > De: "David Cole" > > > ?: "Cedric Doucet" > > > Cc: cmake at cmake.org > > > Envoy?: Jeudi 23 Avril 2015 13:56:36 > > > Objet: Re: [CMake] Don't download external projects again after calling > > > "make clean" > > > > > > It looks correct. I don't understand what the error is. It looks like > > > the download and extract succeeds, but then it simply doesn't move on > > > to the next step of trying to configure with CMake... > > > > > > Does the extracted eigen source tree look like it's a proper un-tarred > > > eigen source directory? > > > > > > Does this simple example work for you? (copied/pasted from another > > > recent CMake mailing list discussion...) > > > > > > # ---------------------------------------------------------------------- > > > # CMakeLists.txt > > > > > > cmake_minimum_required(VERSION 3.2) > > > project(repro NONE) > > > > > > include(ExternalProject) > > > > > > ExternalProject_Add(name > > > GIT_REPOSITORY https://github.com/dlrdave/SmallAndFast.git > > > GIT_TAG 68c3cebf842aa8a13d659fec428fd85ca3a24307 > > > CMAKE_ARGS "" > > > INSTALL_COMMAND "" > > > ) > > > > > > # Possible commits in this repo (most recent first) > > > # > > > # 68c3cebf842aa8a13d659fec428fd85ca3a24307 > > > # a0acdce3a549796ca4424c591c038eeb19e59a72 > > > # 5e98e304a464946dd34cb4c53eb3dd1fd348781b > > > # 8ea36ce26a6b00ab839064a6066a984f6d6647f6 > > > > > > # END CMakeLists.txt > > > > > > > > > Silly question, but do you need to build eigen, or are you using it as > > > a header only library? > > > > > > And... if you do need to build it, does v3.2.4 of eigen build with > > > CMake or does it require some other configure command? > > > > > > (I've been assuming you've actually built eigen manually, and you're > > > just trying to automate it with ExternalProject... but now I'm > > > back-tracking and trying not to assume anything...) > > > > > > > > > HTH, > > > David C. > > > > > > > > > > > > > > > On Thu, Apr 23, 2015 at 7:31 AM, Cedric Doucet > > > wrote: > > > > > > > > Thank you very much. > > > > Your remarks are very helpful to me to understand how it works. > > > > > > > > I hope the following file is now correct: > > > > > > > > ================== > > > > project (example CXX) > > > > > > > > set(CMAKE_VERBOSE_MAKEFILE ON) > > > > > > > > include(ProcessorCount) > > > > ProcessorCount(N) > > > > if(NOT N EQUAL 0) > > > > set(CMAKE_BUILD_FLAGS -j${N}) > > > > endif() > > > > > > > > include(ExternalProject) > > > > set(EXTERNAL_DIR ${CMAKE_CURRENT_BINARY_DIR}) > > > > ExternalProject_Add(eigen > > > > PREFIX ${EXTERNAL_DIR}/eigen > > > > DOWNLOAD_DIR /home/cdoucet/Downloads/eigen > > > > SOURCE_DIR ${EXTERNAL_DIR}/eigen/src > > > > BINARY_DIR ${EXTERNAL_DIR}/eigen/build > > > > INSTALL_DIR ${EXTERNAL_DIR}/eigen/install > > > > URL > > > > http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz > > > > URL_MD5 4d0d77e06fef87b4fcd2c9b72cc8dc55 > > > > CMAKE_ARGS -D CMAKE_INSTALL_PREFIX= > > > > ) > > > > =================== > > > > > > > > After deleting /home/cdoucet/Downloads/eigen and all the content of my > > > > build directory (from where I call "cmake .."), I typed: > > > > cmake .. > > > > make > > > > > > > > and I still obtain the following error message: > > > > > > > > ===================== > > > > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake > > > > -H/home/cdoucet/Documents/exemples/cmake/external_project/eigen > > > > -B/home/cdoucet/Documents/exemples/cmake/external_project/eigen/build > > > > --check-build-system CMakeFiles/Makefile.cmake 0 > > > > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E cmake_progress_start > > > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/CMakeFiles > > > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/CMakeFiles/progress.marks > > > > make -f CMakeFiles/Makefile2 all > > > > make[1]: entrant dans le r?pertoire ? > > > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? > > > > make -f CMakeFiles/eigen.dir/build.make CMakeFiles/eigen.dir/depend > > > > make[2]: entrant dans le r?pertoire ? > > > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? > > > > cd /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build > > > > && > > > > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E cmake_depends "Unix > > > > Makefiles" > > > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen > > > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen > > > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build > > > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build > > > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/CMakeFiles/eigen.dir/DependInfo.cmake > > > > --color= > > > > Scanning dependencies of target eigen > > > > make[2]: quittant le r?pertoire ? > > > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? > > > > make -f CMakeFiles/eigen.dir/build.make CMakeFiles/eigen.dir/build > > > > make[2]: entrant dans le r?pertoire ? > > > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? > > > > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E cmake_progress_report > > > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/CMakeFiles > > > > 3 > > > > [ 12%] Creating directories for 'eigen' > > > > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory > > > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen/src > > > > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory > > > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen/build > > > > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory > > > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen/install > > > > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory > > > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen/tmp > > > > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory > > > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen/src/eigen-stamp > > > > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory > > > > /home/cdoucet/Downloads/eigen > > > > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E touch > > > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen/src/eigen-stamp/eigen-mkdir > > > > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E cmake_progress_report > > > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/CMakeFiles > > > > 4 > > > > [ 25%] Performing download step (download, verify and extract) for > > > > 'eigen' > > > > cd > > > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen > > > > && /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -P > > > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen/src/eigen-stamp/download-eigen.cmake > > > > -- downloading... > > > > src='http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz' > > > > dst='/home/cdoucet/Downloads/eigen/3.2.4.tar.gz' > > > > timeout='none' > > > > -- [download 100% complete] > > > > -- [download 0% complete] > > > > -- [download 1% complete] > > > > -- [download 2% complete] > > > > -- [download 3% complete] > > > > -- [download 4% complete] > > > > -- [download 5% complete] > > > > -- [download 7% complete] > > > > -- [download 8% complete] > > > > -- [download 9% complete] > > > > -- [download 10% complete] > > > > -- [download 11% complete] > > > > -- [download 12% complete] > > > > -- [download 13% complete] > > > > -- [download 14% complete] > > > > -- [download 15% complete] > > > > -- [download 17% complete] > > > > -- [download 18% complete] > > > > -- [download 19% complete] > > > > -- [download 20% complete] > > > > -- [download 21% complete] > > > > -- [download 22% complete] > > > > -- [download 23% complete] > > > > -- [download 24% complete] > > > > -- [download 25% complete] > > > > -- [download 27% complete] > > > > -- [download 28% complete] > > > > -- [download 29% complete] > > > > -- [download 30% complete] > > > > -- [download 31% complete] > > > > -- [download 32% complete] > > > > -- [download 33% complete] > > > > -- [download 34% complete] > > > > -- [download 35% complete] > > > > -- [download 36% complete] > > > > -- [download 38% complete] > > > > -- [download 39% complete] > > > > -- [download 40% complete] > > > > -- [download 41% complete] > > > > -- [download 42% complete] > > > > -- [download 43% complete] > > > > -- [download 44% complete] > > > > -- [download 45% complete] > > > > -- [download 46% complete] > > > > -- [download 48% complete] > > > > -- [download 49% complete] > > > > -- [download 50% complete] > > > > -- [download 51% complete] > > > > -- [download 52% complete] > > > > -- [download 53% complete] > > > > -- [download 54% complete] > > > > -- [download 55% complete] > > > > -- [download 56% complete] > > > > -- [download 57% complete] > > > > -- [download 59% complete] > > > > -- [download 60% complete] > > > > -- [download 61% complete] > > > > -- [download 62% complete] > > > > -- [download 63% complete] > > > > -- [download 64% complete] > > > > -- [download 65% complete] > > > > -- [download 66% complete] > > > > -- [download 67% complete] > > > > -- [download 69% complete] > > > > -- [download 70% complete] > > > > -- [download 71% complete] > > > > -- [download 72% complete] > > > > -- [download 73% complete] > > > > -- [download 74% complete] > > > > -- [download 75% complete] > > > > -- [download 76% complete] > > > > -- [download 77% complete] > > > > -- [download 78% complete] > > > > -- [download 80% complete] > > > > -- [download 81% complete] > > > > -- [download 82% complete] > > > > -- [download 83% complete] > > > > -- [download 84% complete] > > > > -- [download 85% complete] > > > > -- [download 86% complete] > > > > -- [download 87% complete] > > > > -- [download 88% complete] > > > > -- [download 90% complete] > > > > -- [download 91% complete] > > > > -- [download 92% complete] > > > > -- [download 93% complete] > > > > -- [download 94% complete] > > > > -- [download 95% complete] > > > > -- [download 96% complete] > > > > -- [download 97% complete] > > > > -- [download 98% complete] > > > > -- [download 99% complete] > > > > -- [download 100% complete] > > > > -- downloading... done > > > > cd > > > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen > > > > && /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -P > > > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen/src/eigen-stamp/verify-eigen.cmake > > > > -- verifying file... > > > > file='/home/cdoucet/Downloads/eigen/3.2.4.tar.gz' > > > > -- verifying file... done > > > > cd > > > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen > > > > && /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -P > > > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen/src/eigen-stamp/extract-eigen.cmake > > > > -- extracting... > > > > src='/home/cdoucet/Downloads/eigen/3.2.4.tar.gz' > > > > dst='/home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen/src' > > > > -- extracting... [tar xfz] > > > > -- extracting... [analysis] > > > > -- extracting... [rename] > > > > -- extracting... [clean up] > > > > -- extracting... done > > > > cd > > > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen > > > > && /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E touch > > > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/eigen/src/eigen-stamp/eigen-download > > > > make[2]: *** [eigen/src/eigen-stamp/eigen-download] Erreur 1 > > > > make[2]: quittant le r?pertoire ? > > > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? > > > > make[1]: *** [CMakeFiles/eigen.dir/all] Erreur 2 > > > > make[1]: quittant le r?pertoire ? > > > > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build ? > > > > make: *** [all] Erreur 2 > > > > > > > > ===================== > > > > > > > > > > > > > > > > ----- Mail original ----- > > > >> De: "David Cole" > > > >> ?: "Cedric Doucet" > > > >> Cc: cmake at cmake.org > > > >> Envoy?: Jeudi 23 Avril 2015 13:14:35 > > > >> Objet: Re: [CMake] Don't download external projects again after > > > >> calling > > > >> "make clean" > > > >> > > > >> I don't understand what the error is here, but here are some comments: > > > >> > > > >> (1) > > > >> CMAKE_INSTALL_PREFIX=$ > > > >> > > > >> The $ is unnecessary and incorrect in this context. The literal string > > > >> is the thing that ExternalProject will substitute when > > > >> it is processed into custom commands... > > > >> > > > >> (2) > > > >> ONLY the DOWNLOAD_DIR parameter should be in an "external" (outside of > > > >> your build tree) directory, to avoid re-downloading the exact same > > > >> tar.gz file over and over again. The source tree and the build tree of > > > >> the project should be in your build tree somewhere. > > > >> > > > >> (3) > > > >> CONFIGURE_COMMAND cd && cmake should be unnecessary... > > > >> The configure command is run in the binary dir by default. Instead, > > > >> you should be able to use: > > > >> > > > >> CMAKE_ARGS -D CMAKE_INSTALL_PREFIX= > > > >> > > > >> The binary dir is the working directory for configure, build and > > > >> install commands. And the is added automatically when you > > > >> use CMAKE_ARGS with the default cmake CONFIGURE_COMMAND rather than > > > >> specifying your own. > > > >> > > > >> > > > >> Make those changes and try again with one more fresh build (i.e. -- > > > >> blow away the whole /home/cdoucet/Downloads/eigen directory and start > > > >> clean...) > > > >> > > > >> Let us know if you still have an error after making those changes. > > > >> > > > >> > > > >> HTH, > > > >> David C. > > > >> > > > >> > > > >> > > > >> On Thu, Apr 23, 2015 at 6:57 AM, Cedric Doucet > > > >> > > > >> wrote: > > > >> > Hello David, > > > >> > > > > >> > I am using CMake 3.2.2. > > > >> > I installed CMake from the sources because I use "modules" to manage > > > >> > my > > > >> > libraries. > > > >> > But it's ok now: I modified the installation so that to support > > > >> > https. > > > >> > > > > >> > Unfortunately, I still have a problem. :( > > > >> > Maybe you could help me! > > > >> > > > > >> > Here is my CMakeLists.txt: > > > >> > > > > >> > ============= > > > >> > > > > >> > cmake_minimum_required (VERSION 2.6) > > > >> > > > > >> > project (example CXX) > > > >> > > > > >> > set(CMAKE_VERBOSE_MAKEFILE ON) > > > >> > > > > >> > include(ProcessorCount) > > > >> > ProcessorCount(N) > > > >> > if(NOT N EQUAL 0) > > > >> > set(CMAKE_BUILD_FLAGS -j${N}) > > > >> > endif() > > > >> > > > > >> > include(ExternalProject) > > > >> > set(EXTERNAL_DIR /home/cdoucet/Downloads) > > > >> > ExternalProject_Add(eigen > > > >> > PREFIX ${EXTERNAL_DIR}/eigen > > > >> > DOWNLOAD_DIR > > > >> > ${EXTERNAL_DIR}/eigen/download > > > >> > SOURCE_DIR > > > >> > ${EXTERNAL_DIR}/eigen/src > > > >> > BINARY_DIR > > > >> > ${EXTERNAL_DIR}/eigen/build > > > >> > INSTALL_DIR > > > >> > ${EXTERNAL_DIR}/eigen/install > > > >> > URL > > > >> > http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz > > > >> > URL_MD5 > > > >> > 4d0d77e06fef87b4fcd2c9b72cc8dc55 > > > >> > CONFIGURE_COMMAND cd > > > >> > && > > > >> > cmake -D CMAKE_INSTALL_PREFIX=$ > > > >> > ) > > > >> > > > > >> > ============= > > > >> > > > > >> > And here is the error message: > > > >> > > > > >> > ===================== > > > >> > > > > >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake > > > >> > -H/home/cdoucet/Documents/exemples/cmake/external_project/eigen > > > >> > -B/home/cdoucet/Documents/exemples/cmake/external_project/eigen/build > > > >> > --check-build-system CMakeFiles/Makefile.cmake 0 > > > >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E > > > >> > cmake_progress_start > > > >> > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/CMakeFiles > > > >> > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/CMakeFiles/progress.marks > > > >> > make -f CMakeFiles/Makefile2 all > > > >> > make[1]: entrant dans le r?pertoire ? > > > >> > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build > > > >> > ? > > > >> > make -f CMakeFiles/eigen.dir/build.make CMakeFiles/eigen.dir/depend > > > >> > make[2]: entrant dans le r?pertoire ? > > > >> > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build > > > >> > ? > > > >> > cd > > > >> > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build > > > >> > && > > > >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E cmake_depends > > > >> > "Unix > > > >> > Makefiles" > > > >> > /home/cdoucet/Documents/exemples/cmake/external_project/eigen > > > >> > /home/cdoucet/Documents/exemples/cmake/external_project/eigen > > > >> > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build > > > >> > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build > > > >> > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/CMakeFiles/eigen.dir/DependInfo.cmake > > > >> > --color= > > > >> > make[2]: quittant le r?pertoire ? > > > >> > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build > > > >> > ? > > > >> > make -f CMakeFiles/eigen.dir/build.make CMakeFiles/eigen.dir/build > > > >> > make[2]: entrant dans le r?pertoire ? > > > >> > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build > > > >> > ? > > > >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E > > > >> > cmake_progress_report > > > >> > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/CMakeFiles > > > >> > 3 > > > >> > [ 12%] Creating directories for 'eigen' > > > >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory > > > >> > /home/cdoucet/Downloads/eigen/src > > > >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory > > > >> > /home/cdoucet/Downloads/eigen/build > > > >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory > > > >> > /home/cdoucet/Downloads/eigen/install > > > >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory > > > >> > /home/cdoucet/Downloads/eigen/tmp > > > >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory > > > >> > /home/cdoucet/Downloads/eigen/src/eigen-stamp > > > >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E make_directory > > > >> > /home/cdoucet/Downloads/eigen/download > > > >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E touch > > > >> > /home/cdoucet/Downloads/eigen/src/eigen-stamp/eigen-mkdir > > > >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E > > > >> > cmake_progress_report > > > >> > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build/CMakeFiles > > > >> > 4 > > > >> > [ 25%] Performing download step (download, verify and extract) for > > > >> > 'eigen' > > > >> > cd /home/cdoucet/Downloads/eigen && > > > >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -P > > > >> > /home/cdoucet/Downloads/eigen/src/eigen-stamp/download-eigen.cmake > > > >> > -- downloading... > > > >> > src='http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz' > > > >> > dst='/home/cdoucet/Downloads/eigen/download/3.2.4.tar.gz' > > > >> > timeout='none' > > > >> > -- [download 100% complete] > > > >> > -- [download 0% complete] > > > >> > -- [download 1% complete] > > > >> > -- [download 2% complete] > > > >> > -- [download 3% complete] > > > >> > -- [download 4% complete] > > > >> > -- [download 5% complete] > > > >> > -- [download 7% complete] > > > >> > -- [download 8% complete] > > > >> > -- [download 9% complete] > > > >> > -- [download 10% complete] > > > >> > -- [download 11% complete] > > > >> > -- [download 12% complete] > > > >> > -- [download 13% complete] > > > >> > -- [download 14% complete] > > > >> > -- [download 15% complete] > > > >> > -- [download 17% complete] > > > >> > -- [download 18% complete] > > > >> > -- [download 19% complete] > > > >> > -- [download 20% complete] > > > >> > -- [download 21% complete] > > > >> > -- [download 22% complete] > > > >> > -- [download 23% complete] > > > >> > -- [download 24% complete] > > > >> > -- [download 25% complete] > > > >> > -- [download 27% complete] > > > >> > -- [download 28% complete] > > > >> > -- [download 29% complete] > > > >> > -- [download 30% complete] > > > >> > -- [download 31% complete] > > > >> > -- [download 32% complete] > > > >> > -- [download 33% complete] > > > >> > -- [download 34% complete] > > > >> > -- [download 35% complete] > > > >> > -- [download 36% complete] > > > >> > -- [download 38% complete] > > > >> > -- [download 39% complete] > > > >> > -- [download 40% complete] > > > >> > -- [download 41% complete] > > > >> > -- [download 42% complete] > > > >> > -- [download 43% complete] > > > >> > -- [download 44% complete] > > > >> > -- [download 45% complete] > > > >> > -- [download 46% complete] > > > >> > -- [download 48% complete] > > > >> > -- [download 49% complete] > > > >> > -- [download 50% complete] > > > >> > -- [download 51% complete] > > > >> > -- [download 52% complete] > > > >> > -- [download 53% complete] > > > >> > -- [download 54% complete] > > > >> > -- [download 55% complete] > > > >> > -- [download 56% complete] > > > >> > -- [download 57% complete] > > > >> > -- [download 59% complete] > > > >> > -- [download 60% complete] > > > >> > -- [download 61% complete] > > > >> > -- [download 62% complete] > > > >> > -- [download 63% complete] > > > >> > -- [download 64% complete] > > > >> > -- [download 65% complete] > > > >> > -- [download 66% complete] > > > >> > -- [download 67% complete] > > > >> > -- [download 69% complete] > > > >> > -- [download 70% complete] > > > >> > -- [download 71% complete] > > > >> > -- [download 72% complete] > > > >> > -- [download 73% complete] > > > >> > -- [download 74% complete] > > > >> > -- [download 75% complete] > > > >> > -- [download 76% complete] > > > >> > -- [download 77% complete] > > > >> > -- [download 78% complete] > > > >> > -- [download 80% complete] > > > >> > -- [download 81% complete] > > > >> > -- [download 82% complete] > > > >> > -- [download 83% complete] > > > >> > -- [download 84% complete] > > > >> > -- [download 85% complete] > > > >> > -- [download 86% complete] > > > >> > -- [download 87% complete] > > > >> > -- [download 88% complete] > > > >> > -- [download 90% complete] > > > >> > -- [download 91% complete] > > > >> > -- [download 92% complete] > > > >> > -- [download 93% complete] > > > >> > -- [download 94% complete] > > > >> > -- [download 95% complete] > > > >> > -- [download 96% complete] > > > >> > -- [download 97% complete] > > > >> > -- [download 98% complete] > > > >> > -- [download 99% complete] > > > >> > -- [download 100% complete] > > > >> > -- downloading... done > > > >> > cd /home/cdoucet/Downloads/eigen && > > > >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -P > > > >> > /home/cdoucet/Downloads/eigen/src/eigen-stamp/verify-eigen.cmake > > > >> > -- verifying file... > > > >> > file='/home/cdoucet/Downloads/eigen/download/3.2.4.tar.gz' > > > >> > -- verifying file... done > > > >> > cd /home/cdoucet/Downloads/eigen && > > > >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -P > > > >> > /home/cdoucet/Downloads/eigen/src/eigen-stamp/extract-eigen.cmake > > > >> > -- extracting... > > > >> > src='/home/cdoucet/Downloads/eigen/download/3.2.4.tar.gz' > > > >> > dst='/home/cdoucet/Downloads/eigen/src' > > > >> > -- extracting... [tar xfz] > > > >> > -- extracting... [analysis] > > > >> > -- extracting... [rename] > > > >> > -- extracting... [clean up] > > > >> > -- extracting... done > > > >> > cd /home/cdoucet/Downloads/eigen && > > > >> > /usr/local/bibliotheques/cmake/3.2.2/bin/cmake -E touch > > > >> > /home/cdoucet/Downloads/eigen/src/eigen-stamp/eigen-download > > > >> > make[2]: *** > > > >> > [/home/cdoucet/Downloads/eigen/src/eigen-stamp/eigen-download] > > > >> > Erreur 1 > > > >> > make[2]: quittant le r?pertoire ? > > > >> > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build > > > >> > ? > > > >> > make[1]: *** [CMakeFiles/eigen.dir/all] Erreur 2 > > > >> > make[1]: quittant le r?pertoire ? > > > >> > /home/cdoucet/Documents/exemples/cmake/external_project/eigen/build > > > >> > ? > > > >> > make: *** [all] Erreur 2 > > > >> > > > > >> > ===================== > > > >> > > > > >> > > > > >> > > > > >> > ________________________________ > > > >> > > > > >> > De: "David Cole" > > > >> > ?: "Cedric Doucet" > > > >> > Cc: cmake at cmake.org > > > >> > Envoy?: Samedi 18 Avril 2015 20:39:57 > > > >> > > > > >> > Objet: Re: [CMake] Don't download external projects again after > > > >> > calling > > > >> > "make clean" > > > >> > > > > >> > What version of CMake are you using? All the modern pre-built CMake > > > >> > installations should support https without extra effort on your > > > >> > part. > > > >> > Are > > > >> > you using a pre-built version from somewhere or are you building > > > >> > CMake > > > >> > yourself? > > > >> > > > > >> > > > > >> > On Saturday, April 18, 2015, Cedric Doucet > > > >> > wrote: > > > >> >> > > > >> >> > > > >> >> Ok it seems the answer to my problem is here: > > > >> >> http://www.cmake.org/pipermail/cmake/2010-December/041295.html > > > >> >> I will try it. > > > >> >> > > > >> >> ----- Mail original ----- > > > >> >> > De: "Cedric Doucet" > > > >> >> > ?: cmake at cmake.org > > > >> >> > Envoy?: Samedi 18 Avril 2015 13:38:31 > > > >> >> > Objet: Re: [CMake] Don't download external projects again after > > > >> >> > calling > > > >> >> > "make clean" > > > >> >> > > > > >> >> > > > > >> >> > I have just tried to install curl to get https support. > > > >> >> > To do that, I have followed the steps below: > > > >> >> > > > > >> >> > 1. Installation of openssl: > > > >> >> > 1.a. ./config --prefix=/my/openssl/path > > > >> >> > 1.b. make > > > >> >> > 1.c. make test > > > >> >> > 1.d. make install > > > >> >> > 2. Installation of curl > > > >> >> > 2.a. ./configure --prefix=/my/curl/path > > > >> >> > --with-ssl=/my/openssl/path/lib > > > >> >> > 2.b. make > > > >> >> > 2.c. make install > > > >> >> > > > > >> >> > I have also prepend PATH with /my/curl/path/bin. > > > >> >> > However, the error remains. > > > >> >> > It seems that my version of curl (7.41.0) is not taken into > > > >> >> > acount > > > >> >> > because I > > > >> >> > have still this line in the error message: > > > >> >> > User-Agent: curl/7.38.0 > > > >> >> > I tried to remove all previous of curl and libcurl but it does > > > >> >> > not > > > >> >> > change > > > >> >> > anything. > > > >> >> > > > > >> >> > Could you help me? > > > >> >> > > > > >> >> > C?dric > > > >> >> > > > > >> >> > > > > >> >> > ----- Mail original ----- > > > >> >> > > De: "Cedric Doucet" > > > >> >> > > ?: "David Cole" > > > >> >> > > Cc: cmake at cmake.org > > > >> >> > > Envoy?: Samedi 18 Avril 2015 13:00:28 > > > >> >> > > Objet: Re: [CMake] Don't download external projects again after > > > >> >> > > calling > > > >> >> > > "make clean" > > > >> >> > > > > > >> >> > > > > > >> >> > > Hello David, > > > >> >> > > > > > >> >> > > thank you very much. > > > >> >> > > Unfortunately, I get the following error message if I remove my > > > >> >> > > download > > > >> >> > > command: > > > >> >> > > > > > >> >> > > -- downloading... > > > >> >> > > src='http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz' > > > >> >> > > dst='/home/cdoucet/Downloads/eigen/download/3.2.4.tar.gz' > > > >> >> > > timeout='none' > > > >> >> > > -- [download 100% complete] > > > >> >> > > CMake Error at src/eigen-stamp/download-eigen.cmake:27 > > > >> >> > > (message): > > > >> >> > > error: downloading > > > >> >> > > 'http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz' > > > >> >> > > failed > > > >> >> > > > > > >> >> > > status_code: 1 > > > >> >> > > status_string: "Unsupported protocol" > > > >> >> > > log: Hostname was NOT found in DNS cache > > > >> >> > > Trying 131.103.20.167... > > > >> >> > > > > > >> >> > > Connected to bitbucket.org (131.103.20.167) port 80 (#0) > > > >> >> > > > > > >> >> > > GET /eigen/eigen/get/3.2.4.tar.gz HTTP/1.1 > > > >> >> > > > > > >> >> > > User-Agent: curl/7.38.0 > > > >> >> > > > > > >> >> > > Host: bitbucket.org > > > >> >> > > > > > >> >> > > Accept: */* > > > >> >> > > > > > >> >> > > > > > >> >> > > > > > >> >> > > HTTP/1.1 301 Moved Permanently > > > >> >> > > > > > >> >> > > Server nginx/1.6.2 is not blacklisted > > > >> >> > > > > > >> >> > > Server: nginx/1.6.2 > > > >> >> > > > > > >> >> > > Date: Sat, 18 Apr 2015 10:55:20 GMT > > > >> >> > > > > > >> >> > > Content-Type: text/html > > > >> >> > > > > > >> >> > > Content-Length: 184 > > > >> >> > > > > > >> >> > > Location: https://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz > > > >> >> > > > > > >> >> > > > > > >> >> > > > > > >> >> > > Ignoring the response-body > > > >> >> > > > > > >> >> > > > > > >> >> > > > > > >> >> > > 301 Moved Permanently > > > >> >> > > > > > >> >> > > > > > >> >> > > > > > >> >> > >

301 Moved Permanently

> > > >> >> > > > > > >> >> > >
nginx/1.6.2
> > > >> >> > > > > > >> >> > > > > > >> >> > > > > > >> >> > > > > > >> >> > > > > > >> >> > > Connection #0 to host bitbucket.org left intact > > > >> >> > > > > > >> >> > > Issue another request to this URL: > > > >> >> > > 'https://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz' > > > >> >> > > > > > >> >> > > Protocol "https" not supported or disabled in libcurl > > > >> >> > > > > > >> >> > > Closing connection -1 > > > >> >> > > > > > >> >> > > > > > >> >> > > > > > >> >> > > > > > >> >> > > ----- Mail original ----- > > > >> >> > > > De: "David Cole" > > > >> >> > > > ?: "Cedric Doucet" > > > >> >> > > > Cc: cmake at cmake.org > > > >> >> > > > Envoy?: Vendredi 17 Avril 2015 13:21:08 > > > >> >> > > > Objet: Re: [CMake] Don't download external projects again > > > >> >> > > > after > > > >> >> > > > calling > > > >> >> > > > "make clean" > > > >> >> > > > > > > >> >> > > > Eliminate your DOWNLOAD_COMMAND. CMake knows how to do it > > > >> >> > > > with > > > >> >> > > > just > > > >> >> > > > the URL_MD5, DOWNLOAD_DIR and SOURCE_DIR information.... > > > >> >> > > > > > > >> >> > > > HTH, > > > >> >> > > > David > > > >> >> > > > > > > >> >> > > > > > > >> >> > > > On Fri, Apr 17, 2015 at 1:32 AM, Cedric Doucet > > > >> >> > > > > > > >> >> > > > wrote: > > > >> >> > > > > > > > >> >> > > > > Hello David, > > > >> >> > > > > > > > >> >> > > > > thank you very much for your help. > > > >> >> > > > > > > > >> >> > > > > Unfortunately I may do something wrong because it does not > > > >> >> > > > > work. > > > >> >> > > > > After cleaning, the library is downloaded again. > > > >> >> > > > > > > > >> >> > > > > I guess my mistake comes from the fact I do not understand > > > >> >> > > > > the > > > >> >> > > > > role of > > > >> >> > > > > URL_MD5. > > > >> >> > > > > Below is a simple example where downloading and installing > > > >> >> > > > > is > > > >> >> > > > > very > > > >> >> > > > > fast. > > > >> >> > > > > You just have to replace the value of EXTERNAL_DIR by the > > > >> >> > > > > path > > > >> >> > > > > to > > > >> >> > > > > your > > > >> >> > > > > own > > > >> >> > > > > "Downloads" repository. > > > >> >> > > > > I tried to put URL in my DOWNLOAD_COMMAND but the call > > > >> >> > > > > "wget > > > >> >> > > > > " > > > >> >> > > > > does > > > >> >> > > > > not seem to be understood by the wget command. > > > >> >> > > > > > > > >> >> > > > > Thanks again! > > > >> >> > > > > > > > >> >> > > > > C?dric > > > >> >> > > > > > > > >> >> > > > > > > > >> >> > > > > -------------------------------------------------------------------------- > > > >> >> > > > > cmake_minimum_required (VERSION 2.6) > > > >> >> > > > > > > > >> >> > > > > project (example CXX) > > > >> >> > > > > > > > >> >> > > > > set(CMAKE_VERBOSE_MAKEFILE ON) > > > >> >> > > > > > > > >> >> > > > > include(ProcessorCount) > > > >> >> > > > > ProcessorCount(N) > > > >> >> > > > > if(NOT N EQUAL 0) > > > >> >> > > > > set(CMAKE_BUILD_FLAGS -j${N}) > > > >> >> > > > > endif() > > > >> >> > > > > > > > >> >> > > > > include(ExternalProject) > > > >> >> > > > > set(EXTERNAL_DIR /home/cdoucet/Downloads) > > > >> >> > > > > ExternalProject_Add(eigen > > > >> >> > > > > PREFIX ${EXTERNAL_DIR}/eigen > > > >> >> > > > > DOWNLOAD_DIR > > > >> >> > > > > ${EXTERNAL_DIR}/eigen/download > > > >> >> > > > > SOURCE_DIR ${EXTERNAL_DIR}/eigen/src > > > >> >> > > > > BINARY_DIR ${EXTERNAL_DIR}/eigen/build > > > >> >> > > > > INSTALL_DIR > > > >> >> > > > > ${EXTERNAL_DIR}/eigen/install > > > >> >> > > > > URL > > > >> >> > > > > > > > >> >> > > > > http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz > > > >> >> > > > > URL_MD5 > > > >> >> > > > > ccb18a771f678b38a3d33c321a8e7daf > > > >> >> > > > > DOWNLOAD_COMMAND wget > > > >> >> > > > > > > > >> >> > > > > http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz > > > >> >> > > > > && > > > >> >> > > > > tar xvzf 3.2.4.tar.gz -C > > > >> >> > > > > --strip-components=1 > > > >> >> > > > > CONFIGURE_COMMAND cd && > > > >> >> > > > > cmake > > > >> >> > > > > -D > > > >> >> > > > > CMAKE_INSTALL_PREFIX=$ > > > >> >> > > > > > > > >> >> > > > > ) > > > >> >> > > > > > > > >> >> > > > > ------------------------------------------------------------------------------ > > > >> >> > > > > > > > >> >> > > > > > > > >> >> > > > > > > > >> >> > > > > ----- Mail original ----- > > > >> >> > > > >> De: "David Cole" > > > >> >> > > > >> ?: "Cedric Doucet" > > > >> >> > > > >> Cc: cmake at cmake.org > > > >> >> > > > >> Envoy?: Lundi 13 Avril 2015 12:40:34 > > > >> >> > > > >> Objet: Re: [CMake] Don't download external projects again > > > >> >> > > > >> after > > > >> >> > > > >> calling > > > >> >> > > > >> "make clean" > > > >> >> > > > >> > > > >> >> > > > >> Use the URL_MD5 and DOWNLOAD_DIR arguments to > > > >> >> > > > >> ExternalProject_Add > > > >> >> > > > >> to > > > >> >> > > > >> put the downloaded files into a location outside the build > > > >> >> > > > >> tree > > > >> >> > > > >> (perhaps ~/Downloads on Mac/Linux or > > > >> >> > > > >> $ENV{USERPROFILE}/Downloads > > > >> >> > > > >> on > > > >> >> > > > >> Windows). > > > >> >> > > > >> > > > >> >> > > > >> With DOWNLOAD_DIR outside the build tree, and the > > > >> >> > > > >> checksums > > > >> >> > > > >> of > > > >> >> > > > >> the > > > >> >> > > > >> downloaded files being the same as you've specified via > > > >> >> > > > >> URL_MD5, > > > >> >> > > > >> the > > > >> >> > > > >> download portion will be avoided once there is a local > > > >> >> > > > >> copy > > > >> >> > > > >> of > > > >> >> > > > >> a > > > >> >> > > > >> file > > > >> >> > > > >> available. > > > >> >> > > > >> > > > >> >> > > > >> > > > >> >> > > > >> HTH, > > > >> >> > > > >> David C. > > > >> >> > > > >> > > > >> >> > > > >> > > > >> >> > > > >> On Mon, Apr 13, 2015 at 5:04 AM, Cedric Doucet > > > >> >> > > > >> > > > >> >> > > > >> wrote: > > > >> >> > > > >> > > > > >> >> > > > >> > Hello! > > > >> >> > > > >> > > > > >> >> > > > >> > I use the ExternalProject_Add function to download > > > >> >> > > > >> > third-party > > > >> >> > > > >> > libraries > > > >> >> > > > >> > of > > > >> >> > > > >> > a code. > > > >> >> > > > >> > > > > >> >> > > > >> > Once a library has been downloaded, I can call "make" as > > > >> >> > > > >> > many > > > >> >> > > > >> > times > > > >> >> > > > >> > as > > > >> >> > > > >> > I > > > >> >> > > > >> > want without downloading this library again. > > > >> >> > > > >> > It seems that CMake detects that the library has already > > > >> >> > > > >> > been > > > >> >> > > > >> > downloaded. > > > >> >> > > > >> > > > > >> >> > > > >> > However, calling "make clean" seems to destroy this > > > >> >> > > > >> > feature. > > > >> >> > > > >> > Even if my library is not uninstalled during cleaning, > > > >> >> > > > >> > calling > > > >> >> > > > >> > "make" > > > >> >> > > > >> > after > > > >> >> > > > >> > "make clean" will lead CMake to try download the library > > > >> >> > > > >> > again. > > > >> >> > > > >> > > > > >> >> > > > >> > How could I tell CMake not to download the library > > > >> >> > > > >> > again? > > > >> >> > > > >> > > > > >> >> > > > >> > Thank you very much for your help! > > > >> >> > > > >> > > > > >> >> > > > >> > C?dric > > > >> >> > > > >> > > > > >> >> > > > >> > -- > > > >> >> > > > >> > > > > >> >> > > > >> > Powered by www.kitware.com > > > >> >> > > > >> > > > > >> >> > > > >> > Please keep messages on-topic and check the CMake FAQ > > > >> >> > > > >> > at: > > > >> >> > > > >> > http://www.cmake.org/Wiki/CMake_FAQ > > > >> >> > > > >> > > > > >> >> > > > >> > Kitware offers various services to support the CMake > > > >> >> > > > >> > community. > > > >> >> > > > >> > For > > > >> >> > > > >> > more > > > >> >> > > > >> > information on each offering, please visit: > > > >> >> > > > >> > > > > >> >> > > > >> > CMake Support: http://cmake.org/cmake/help/support.html > > > >> >> > > > >> > CMake Consulting: > > > >> >> > > > >> > http://cmake.org/cmake/help/consulting.html > > > >> >> > > > >> > CMake Training Courses: > > > >> >> > > > >> > http://cmake.org/cmake/help/training.html > > > >> >> > > > >> > > > > >> >> > > > >> > Visit other Kitware open-source projects at > > > >> >> > > > >> > http://www.kitware.com/opensource/opensource.html > > > >> >> > > > >> > > > > >> >> > > > >> > Follow this link to subscribe/unsubscribe: > > > >> >> > > > >> > http://public.kitware.com/mailman/listinfo/cmake > > > >> >> > > > >> > > > >> >> > > > > > > >> >> > > -- > > > >> >> > > > > > >> >> > > Powered by www.kitware.com > > > >> >> > > > > > >> >> > > Please keep messages on-topic and check the CMake FAQ at: > > > >> >> > > http://www.cmake.org/Wiki/CMake_FAQ > > > >> >> > > > > > >> >> > > Kitware offers various services to support the CMake community. > > > >> >> > > For > > > >> >> > > more > > > >> >> > > information on each offering, please visit: > > > >> >> > > > > > >> >> > > CMake Support: http://cmake.org/cmake/help/support.html > > > >> >> > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > > >> >> > > CMake Training Courses: > > > >> >> > > http://cmake.org/cmake/help/training.html > > > >> >> > > > > > >> >> > > Visit other Kitware open-source projects at > > > >> >> > > http://www.kitware.com/opensource/opensource.html > > > >> >> > > > > > >> >> > > Follow this link to subscribe/unsubscribe: > > > >> >> > > http://public.kitware.com/mailman/listinfo/cmake > > > >> >> > > > > > >> >> > -- > > > >> >> > > > > >> >> > Powered by www.kitware.com > > > >> >> > > > > >> >> > Please keep messages on-topic and check the CMake FAQ at: > > > >> >> > http://www.cmake.org/Wiki/CMake_FAQ > > > >> >> > > > > >> >> > Kitware offers various services to support the CMake community. > > > >> >> > For > > > >> >> > more > > > >> >> > information on each offering, please visit: > > > >> >> > > > > >> >> > CMake Support: http://cmake.org/cmake/help/support.html > > > >> >> > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > > >> >> > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > >> >> > > > > >> >> > Visit other Kitware open-source projects at > > > >> >> > http://www.kitware.com/opensource/opensource.html > > > >> >> > > > > >> >> > Follow this link to subscribe/unsubscribe: > > > >> >> > http://public.kitware.com/mailman/listinfo/cmake > > > >> >> > > > > >> >> -- > > > >> >> > > > >> >> Powered by www.kitware.com > > > >> >> > > > >> >> Please keep messages on-topic and check the CMake FAQ at: > > > >> >> http://www.cmake.org/Wiki/CMake_FAQ > > > >> >> > > > >> >> Kitware offers various services to support the CMake community. For > > > >> >> more > > > >> >> information on each offering, please visit: > > > >> >> > > > >> >> CMake Support: http://cmake.org/cmake/help/support.html > > > >> >> CMake Consulting: http://cmake.org/cmake/help/consulting.html > > > >> >> CMake Training Courses: http://cmake.org/cmake/help/training.html > > > >> >> > > > >> >> Visit other Kitware open-source projects at > > > >> >> http://www.kitware.com/opensource/opensource.html > > > >> >> > > > >> >> Follow this link to subscribe/unsubscribe: > > > >> >> http://public.kitware.com/mailman/listinfo/cmake > > > >> > > > > >> > > > > >> > > > > >> > -- > > > >> > > > > >> > Powered by www.kitware.com > > > >> > > > > >> > Please keep messages on-topic and check the CMake FAQ at: > > > >> > http://www.cmake.org/Wiki/CMake_FAQ > > > >> > > > > >> > Kitware offers various services to support the CMake community. For > > > >> > more > > > >> > information on each offering, please visit: > > > >> > > > > >> > CMake Support: http://cmake.org/cmake/help/support.html > > > >> > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > > >> > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > >> > > > > >> > Visit other Kitware open-source projects at > > > >> > http://www.kitware.com/opensource/opensource.html > > > >> > > > > >> > Follow this link to subscribe/unsubscribe: > > > >> > http://public.kitware.com/mailman/listinfo/cmake > > > >> > > > > > > > > -- > > > > Powered by www.kitware.com > > > > Please keep messages on-topic and check the CMake FAQ at: > > http://www.cmake.org/Wiki/CMake_FAQ > > > > Kitware offers various services to support the CMake community. For more > > information on each offering, please visit: > > > > CMake Support: http://cmake.org/cmake/help/support.html > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/cmake > > > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 mateusz at loskot.net Thu Apr 23 08:27:53 2015 From: mateusz at loskot.net (Mateusz Loskot) Date: Thu, 23 Apr 2015 14:27:53 +0200 Subject: [CMake] FindBoost.cmake issue while targeting 32-bit build on Linux 64-bit Message-ID: Hi, Here is the situation outlined: - project has Boost as optional dependency - running CMake on Linux 64-bit to build 32-bit binaries - CXXFLAGS=-m32 is specified - Boost 64-bit binaries are installed - Boost 32-bit binaries are *not* installed Expected result: - Boost 32 is not found, Boost is *not* enabled - 32-bit build is configured without Boost at all - success Actual result: - Boost 64 is found, Boost is enabled - 32-bit build is configured to link against Boost 64-bit libraries - failure Am I missing anything in the build configuration or FindBoost.cmake is unable to do what I expect it to do, by design or by a bug? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net From mateusz at loskot.net Thu Apr 23 10:54:49 2015 From: mateusz at loskot.net (Mateusz Loskot) Date: Thu, 23 Apr 2015 16:54:49 +0200 Subject: [CMake] Detecting -m32 build target on 64-bit host Message-ID: Hi, Surprisingly, I'm having trouble to figure out how to determine, that in Linux 64-bit OS, I'm building a project with -m32 specified. IOW, any CMake variable or macro to tell me target architecture of a build that is being configured is 32 or 64 bit? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net From nilsgladitz at gmail.com Thu Apr 23 10:57:19 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 23 Apr 2015 16:57:19 +0200 Subject: [CMake] Detecting -m32 build target on 64-bit host In-Reply-To: References: Message-ID: <5539084F.1080500@gmail.com> On 04/23/2015 04:54 PM, Mateusz Loskot wrote: > Hi, > > Surprisingly, I'm having trouble to figure out how to determine, > that in Linux 64-bit OS, I'm building a project with -m32 specified. > IOW, any CMake variable or macro to tell me target architecture > of a build that is being configured is 32 or 64 bit? CMAKE_SIZEOF_VOID_P [1] should be: - 4 for 32-bit builds - 8 for 64-bit builds Nils [1] http://www.cmake.org/cmake/help/v3.2/variable/CMAKE_SIZEOF_VOID_P.html From mateusz at loskot.net Thu Apr 23 11:08:08 2015 From: mateusz at loskot.net (Mateusz Loskot) Date: Thu, 23 Apr 2015 17:08:08 +0200 Subject: [CMake] Detecting -m32 build target on 64-bit host In-Reply-To: <5539084F.1080500@gmail.com> References: <5539084F.1080500@gmail.com> Message-ID: On 23 April 2015 at 16:57, Nils Gladitz wrote: > On 04/23/2015 04:54 PM, Mateusz Loskot wrote: >> >> Hi, >> >> Surprisingly, I'm having trouble to figure out how to determine, >> that in Linux 64-bit OS, I'm building a project with -m32 specified. >> IOW, any CMake variable or macro to tell me target architecture >> of a build that is being configured is 32 or 64 bit? > > > CMAKE_SIZEOF_VOID_P [1] should be: > - 4 for 32-bit builds > - 8 for 64-bit builds Nils, I know this trick, but this is not what I'm looking for, unless I misread the documentation. The doc says: "This is set to the size of a pointer on the machine" but not size of pointer on *target* architecture of a build. I believe I formulated my question clear. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net From nilsgladitz at gmail.com Thu Apr 23 11:20:33 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 23 Apr 2015 17:20:33 +0200 Subject: [CMake] Detecting -m32 build target on 64-bit host In-Reply-To: References: <5539084F.1080500@gmail.com> Message-ID: <55390DC1.7040906@gmail.com> On 23.04.2015 17:08, Mateusz Loskot wrote: > I know this trick, but this is not what I'm looking for, unless I > misread the documentation. > > The doc says: > > "This is set to the size of a pointer on the machine" > > but not size of pointer on *target* architecture of a build. > > I believe I formulated my question clear. Yes, all try_compile()s and CMAKE_SIZEOF_VOID_P in particular are specific to the target. Nils From mateusz at loskot.net Thu Apr 23 11:32:53 2015 From: mateusz at loskot.net (Mateusz Loskot) Date: Thu, 23 Apr 2015 17:32:53 +0200 Subject: [CMake] Detecting -m32 build target on 64-bit host In-Reply-To: <55390DC1.7040906@gmail.com> References: <5539084F.1080500@gmail.com> <55390DC1.7040906@gmail.com> Message-ID: On 23 April 2015 at 17:20, Nils Gladitz wrote: > On 23.04.2015 17:08, Mateusz Loskot wrote: >> >> I know this trick, but this is not what I'm looking for, unless I >> misread the documentation. >> >> The doc says: >> >> "This is set to the size of a pointer on the machine" >> >> but not size of pointer on *target* architecture of a build. >> >> I believe I formulated my question clear. > > > Yes, all try_compile()s and CMAKE_SIZEOF_VOID_P in particular are specific > to the target. So, the documentation is imprecise in this regard, isn't it? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net From nilsgladitz at gmail.com Thu Apr 23 11:50:14 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 23 Apr 2015 17:50:14 +0200 Subject: [CMake] Detecting -m32 build target on 64-bit host In-Reply-To: References: <5539084F.1080500@gmail.com> <55390DC1.7040906@gmail.com> Message-ID: <553914B6.9000009@gmail.com> On 23.04.2015 17:32, Mateusz Loskot wrote: > So, the documentation is imprecise in this regard, isn't it? > > Best regards, Is this better? http://www.cmake.org/cmake/help/git-next/variable/CMAKE_SIZEOF_VOID_P.html Nils From mateusz at loskot.net Thu Apr 23 12:00:28 2015 From: mateusz at loskot.net (Mateusz Loskot) Date: Thu, 23 Apr 2015 18:00:28 +0200 Subject: [CMake] Detecting -m32 build target on 64-bit host In-Reply-To: <553914B6.9000009@gmail.com> References: <5539084F.1080500@gmail.com> <55390DC1.7040906@gmail.com> <553914B6.9000009@gmail.com> Message-ID: On 23 April 2015 at 17:50, Nils Gladitz wrote: > On 23.04.2015 17:32, Mateusz Loskot wrote: >> >> So, the documentation is imprecise in this regard, isn't it? >> >> Best regards, > > > Is this better? > http://www.cmake.org/cmake/help/git-next/variable/CMAKE_SIZEOF_VOID_P.html It's better, indeed, but what about "This is set to the size of a pointer on the target machine for which the (machine) code is generated." Thanks! Best regards, -- Mateusz Loskot, http://mateusz.loskot.net From nilsgladitz at gmail.com Thu Apr 23 12:04:20 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 23 Apr 2015 18:04:20 +0200 Subject: [CMake] Detecting -m32 build target on 64-bit host In-Reply-To: References: <5539084F.1080500@gmail.com> <55390DC1.7040906@gmail.com> <553914B6.9000009@gmail.com> Message-ID: <55391804.2000602@gmail.com> On 23.04.2015 18:00, Mateusz Loskot wrote: > It's better, indeed, but what about > > "This is set to the size of a pointer on the target machine for which > the (machine) code is generated." Hm that is in my opinion too redundant. There is only one target machine as far as cmake is concerned and there is no need to further disambiguate. Nils From mateusz at loskot.net Thu Apr 23 12:28:00 2015 From: mateusz at loskot.net (Mateusz Loskot) Date: Thu, 23 Apr 2015 18:28:00 +0200 Subject: [CMake] Detecting -m32 build target on 64-bit host In-Reply-To: <55391804.2000602@gmail.com> References: <5539084F.1080500@gmail.com> <55390DC1.7040906@gmail.com> <553914B6.9000009@gmail.com> <55391804.2000602@gmail.com> Message-ID: On 23 April 2015 at 18:04, Nils Gladitz wrote: > On 23.04.2015 18:00, Mateusz Loskot wrote: >> >> It's better, indeed, but what about >> >> "This is set to the size of a pointer on the target machine for which >> the (machine) code is generated." > > > Hm that is in my opinion too redundant. > There is only one target machine as far as cmake is concerned and there is > no need to further disambiguate. Right. Thanks again. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net From mjklaim at gmail.com Thu Apr 23 14:58:49 2015 From: mjklaim at gmail.com (=?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?=) Date: Thu, 23 Apr 2015 20:58:49 +0200 Subject: [CMake] FindBoost.cmake issue while targeting 32-bit build on Linux 64-bit In-Reply-To: References: Message-ID: I believe that this issue is with Boost not having a way to specify which target architecture is the build, which prevent any CMake script to be able to identify which build is installed. Assuming that the build arch is the same than the OS is not useful on Windows where most applications still need to support 32 bit even if a majority of people are using 64bit verisons of the OS. I pointed the issue several time in the past: https://svn.boost.org/trac/boost/ticket/10141 There was a recent discussion on this subject too, not sure if something changed but there are some solutions possible: http://boost.2283326.n4.nabble.com/1-58-0-Release-candidates-available-tp4674168p4674196.html http://boost.2283326.n4.nabble.com/boost-config-context-log-1-58-address-model-and-architecture-detection-td4674125.html On Thu, Apr 23, 2015 at 2:27 PM, Mateusz Loskot wrote: > Hi, > > Here is the situation outlined: > - project has Boost as optional dependency > - running CMake on Linux 64-bit to build 32-bit binaries > - CXXFLAGS=-m32 is specified > - Boost 64-bit binaries are installed > - Boost 32-bit binaries are *not* installed > > Expected result: > - Boost 32 is not found, Boost is *not* enabled > - 32-bit build is configured without Boost at all > - success > > Actual result: > - Boost 64 is found, Boost is enabled > - 32-bit build is configured to link against Boost 64-bit libraries > - failure > > Am I missing anything in the build configuration > or FindBoost.cmake is unable to do what I expect it to do, > by design or by a bug? > > Best regards, > -- > Mateusz Loskot, http://mateusz.loskot.net > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mateusz at loskot.net Thu Apr 23 15:22:32 2015 From: mateusz at loskot.net (Mateusz Loskot) Date: Thu, 23 Apr 2015 21:22:32 +0200 Subject: [CMake] FindBoost.cmake issue while targeting 32-bit build on Linux 64-bit In-Reply-To: References: Message-ID: On 23 April 2015 at 20:58, Klaim - Jo?l Lamotte wrote: > I believe that this issue is with Boost not having a way to specify which > target architecture is the build, > which prevent any CMake script to be able to identify which build is > installed. Joel, Thanks for confirming what's the issue. I'm surprised it hasn't been addressed yet, seems folks apply some workarounds external to FindBoost, but what they are... Thanks for the pointers too, somehow I missed that issue was discussed in those Boost threads. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net From rob.a.mcdonald at gmail.com Thu Apr 23 19:54:00 2015 From: rob.a.mcdonald at gmail.com (Rob McDonald) Date: Thu, 23 Apr 2015 16:54:00 -0700 Subject: [CMake] ExternalProject_Add not re-building when source changes Message-ID: I've used ExternalProject_Add to trick CMake into supporting two compilers to build my project. Part of my project needs OpenMP, but other parts do not. So, on MacOS, I would prefer to build most of the project with CLang, but the OpenMP requiring part with gcc. I have CMake set up to detect whether the compiler supports OpenMP. If it does not, it checks for a user-supplied alternate compiler. If the user has supplied an alternate compiler, CMake treats the current directory as an ExternalProject , but passes the alternate OpenMP capable compiler. In general, this works well. However, this arrangement does not notice when the source files have changed and cause the External Project to rebuild. I'm using ExternalProject_ForceBuild to try to make the EP build every time -- that works, but once inside the EP, make doesn't recognize that the source files have been updated. The meat of the situation is something like this.... ExternalProject_Add( MYPROJECT URL ${CMAKE_CURRENT_SOURCE_DIR} CMAKE_ARGS -DCMAKE_C_COMPILER=${C_ALTERNATE_COMPILER} -DCMAKE_CXX_COMPILER=${CXX_ALTERNATE_COMPILER} -DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE} -DEP_BUILD=TRUE INSTALL_COMMAND "" ) EP_ForceBuild( MYPROJECT ) I use the -DEP_BUILD=TRUE as an extra safety to prevent infinite recursion -- if the user supplied a non OpenMP capable compiler as the ALTERNATE_COMPILER. So, I think the problem is with my use of 'URL ${CMAKE_CURRENT_SOURCE_DIR}'. Is there a better way to achieve the same thing? Thanks in advance, Rob From davidshen84 at gmail.com Fri Apr 24 02:27:54 2015 From: davidshen84 at gmail.com (Xi Shen) Date: Fri, 24 Apr 2015 06:27:54 +0000 Subject: [CMake] cmake 3.1.1 does not generate x64 profile for visual studio Message-ID: Hi, I am using cmake 3.1.1 on my Windows 7 64bit system. I have Visual Studio 2013 installed. The project I created with cmake works and can build with msbuild. But it only build the x86 version. If I try: msbuild /property:Platform=x64 myproj.vcproj I got error says that the x64 profile does not exist. I have to open the project file and create the x64 profile by myself. Is there any way to let cmake generate the x64 profile? Thanks, David -------------- next part -------------- An HTML attachment was scrubbed... URL: From scott at towel42.com Fri Apr 24 02:37:22 2015 From: scott at towel42.com (Scott Aron Bloom) Date: Fri, 24 Apr 2015 06:37:22 +0000 Subject: [CMake] cmake 3.1.1 does not generate x64 profile for visual studio In-Reply-To: References: Message-ID: What is your cmake generator being used? For Visual Studio 2013, you will need to use cmake ?G ?Visual Studio 12 2013 Win64? Scott From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Xi Shen Sent: Thursday, April 23, 2015 11:28 PM To: cmake at cmake.org Subject: [CMake] cmake 3.1.1 does not generate x64 profile for visual studio Hi, I am using cmake 3.1.1 on my Windows 7 64bit system. I have Visual Studio 2013 installed. The project I created with cmake works and can build with msbuild. But it only build the x86 version. If I try: msbuild /property:Platform=x64 myproj.vcproj I got error says that the x64 profile does not exist. I have to open the project file and create the x64 profile by myself. Is there any way to let cmake generate the x64 profile? Thanks, David -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Fri Apr 24 02:38:50 2015 From: d3ck0r at gmail.com (J Decker) Date: Thu, 23 Apr 2015 23:38:50 -0700 Subject: [CMake] cmake 3.1.1 does not generate x64 profile for visual studio In-Reply-To: References: Message-ID: there's a 64 bit generator... used to be a separate generator "visual studio 12 2013 Win64" but it doesn't show in the list of generators now... On Thu, Apr 23, 2015 at 11:27 PM, Xi Shen wrote: > Hi, > > I am using cmake 3.1.1 on my Windows 7 64bit system. I have Visual Studio > 2013 installed. > > The project I created with cmake works and can build with msbuild. But it > only build the x86 version. If I try: > > msbuild /property:Platform=x64 myproj.vcproj > > I got error says that the x64 profile does not exist. > > I have to open the project file and create the x64 profile by myself. Is > there any way to let cmake generate the x64 profile? > > > Thanks, > David > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidshen84 at gmail.com Fri Apr 24 05:29:54 2015 From: davidshen84 at gmail.com (Xi Shen) Date: Fri, 24 Apr 2015 09:29:54 +0000 Subject: [CMake] cmake 3.1.1 does not generate x64 profile for visual studio In-Reply-To: References: Message-ID: Ah~, so it's a hidden feature? OK, I will give a try. Thanks, David On Fri, 24 Apr 2015 16:38 J Decker wrote: > there's a 64 bit generator... > used to be a separate generator "visual studio 12 2013 Win64" but it > doesn't show in the list of generators now... > > On Thu, Apr 23, 2015 at 11:27 PM, Xi Shen wrote: > >> Hi, >> >> I am using cmake 3.1.1 on my Windows 7 64bit system. I have Visual Studio >> 2013 installed. >> >> The project I created with cmake works and can build with msbuild. But it >> only build the x86 version. If I try: >> >> msbuild /property:Platform=x64 myproj.vcproj >> >> I got error says that the x64 profile does not exist. >> >> I have to open the project file and create the x64 profile by myself. Is >> there any way to let cmake generate the x64 profile? >> >> >> Thanks, >> David >> >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware 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 Fri Apr 24 05:35:54 2015 From: cedric.doucet at inria.fr (Cedric Doucet) Date: Fri, 24 Apr 2015 11:35:54 +0200 (CEST) Subject: [CMake] ExternalProject: how to avoid reinstalling after 'make clean'? In-Reply-To: <718234579.271396.1429867759402.JavaMail.zimbra@inria.fr> Message-ID: <88244780.274548.1429868154334.JavaMail.zimbra@inria.fr> Hello, I use the ExternalProjet_Add function to download and install third-party libraries. Here is an example of a CMakeLists file containing such a call: ===================================== cmake_minimum_required (VERSION 2.6) project (example CXX) set(CMAKE_VERBOSE_MAKEFILE ON) include(ProcessorCount) ProcessorCount(N) if(NOT N EQUAL 0) set(CMAKE_BUILD_FLAGS -j${N}) endif() include(ExternalProject) set(EXTERNAL_DIR ${CMAKE_CURRENT_BINARY_DIR}) ExternalProject_Add(eigen PREFIX ${EXTERNAL_DIR}/eigen DOWNLOAD_DIR ${EXTERNAL_DIR}/eigen/download SOURCE_DIR ${EXTERNAL_DIR}/eigen/src BINARY_DIR ${EXTERNAL_DIR}/eigen/build STAMP_DIR ${EXTERNAL_DIR}/eigen/stamp INSTALL_DIR ${EXTERNAL_DIR}/eigen/install URL http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz URL_MD5 4d0d77e06fef87b4fcd2c9b72cc8dc55 CMAKE_ARGS -D CMAKE_INSTALL_PREFIX= ) ===================================== Everything works fine, except after calling "make clean". Thanks to URL_MD5, the third-party library is not downloaded again. However, configuration, build and install steps are performed again whereas the library has not been uninstalled during cleaning. How could I tell to ExternalProject_Add not to configure/build/install my library unless this library has been removed from my computer? Thank you very much for your help! C?dric -------------- next part -------------- An HTML attachment was scrubbed... URL: From matze999 at gmail.com Fri Apr 24 09:36:51 2015 From: matze999 at gmail.com (matzeNOTAVAILABLE .) Date: Fri, 24 Apr 2015 15:36:51 +0200 Subject: [CMake] find_package Message-ID: Hi, i am struggling somewhat with find_package. I looked at the documentation and googled quite a bit, but i am still stuck. I alos tried stackoverflow to no avail. What i am trying to accomplish is the following: 1) See if my custom boost installation exists (using find_package) (version 1.57) 2) If it does not -> build it 3) Use find_package again to find the newly built boost libs. This works up until but not including step 3. Something that it might be complicating matters (i am not sure) is that i have a system boost installation (1.54). 1) (... set boost_root ...) 2) FIND_PACKAGE(Boost 1.57 COMPONENTS log thread filesystem system) 3) (... build boost if it Boost_FOUND is 0) 4) FIND_PACKAGE(Boost 1.57 REQUIRED COMPONENTS log thread filesystem system) The second call to find_package does not find the boost installation and thus does not set include dirs etc... properly. I wonder why not? Any hints are greatly appreciated, Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Fri Apr 24 10:09:06 2015 From: DLRdave at aol.com (David Cole) Date: Fri, 24 Apr 2015 10:09:06 -0400 Subject: [CMake] find_package In-Reply-To: References: Message-ID: How do you do step 3) -- build boost? Unless the build is done and installed and ready to find before the end of step 3, there is still nothing (yet) there for the find_package in step 4 to find... David C. On Fri, Apr 24, 2015 at 9:36 AM, matzeNOTAVAILABLE . wrote: > Hi, > i am struggling somewhat with find_package. I looked at the documentation > and googled quite a bit, but i am still stuck. I alos tried stackoverflow to > no avail. > > What i am trying to accomplish is the following: > 1) See if my custom boost installation exists (using find_package) (version > 1.57) > 2) If it does not -> build it > 3) Use find_package again to find the newly built boost libs. > > This works up until but not including step 3. > > Something that it might be complicating matters (i am not sure) is that i > have a system boost installation (1.54). > > 1) (... set boost_root ...) > 2) FIND_PACKAGE(Boost 1.57 COMPONENTS log thread filesystem system) > 3) (... build boost if it Boost_FOUND is 0) > 4) FIND_PACKAGE(Boost 1.57 REQUIRED COMPONENTS log thread filesystem system) > > The second call to find_package does not find the boost installation and > thus does not set include dirs etc... properly. > > I wonder why not? > > Any hints are greatly appreciated, > Matt > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 Fri Apr 24 11:33:09 2015 From: DLRdave at aol.com (David Cole) Date: Fri, 24 Apr 2015 11:33:09 -0400 Subject: [CMake] find_package In-Reply-To: References: Message-ID: You should keep replies on the mailing list so others can see it, and pitch in and help. If you are actually building boost using execute_process during a CMake run, then it should be able to find it with your find_package call. Perhaps you need to give the find_package in step 4 a hint to find it where you're building/installing it...? HTH, David C. On Fri, Apr 24, 2015 at 11:16 AM, matzeNOTAVAILABLE . wrote: > The script to trigger the boost build from within cmake is bascially from: > http://stackoverflow.com/questions/18354398/what-is-the-best-way-to-build-boost-with-cmake > > ... > function(install_boost) > > set(APT_BOOST_SRC "../external/boost_1_57_0") > set(APT_BOOST_COMPONENTS "log" "thread" "filesystem" "system") > set(BOOTSTRAP_CMD "./bootstrap.sh") > set(BOOTSTRAP_ARGS "--prefix=${APT_BOOST_BIN}") > message("Executing command: ${BOOTSTRAP_CMD} ${BOOTSTRAP_ARGS}") > execute_process(COMMAND "${BOOTSTRAP_CMD}" ${BOOTSTRAP_ARGS} > WORKING_DIRECTORY ${APT_BOOST_SRC} > RESULT_VARIABLE BS_RESULT OUTPUT_VARIABLE BS_OUTPUT ERROR_VARIABLE > BS_ERROR) > if(NOT BS_RESULT EQUAL 0) > message(FATAL_ERROR "Failed running ${BOOTSTRAP_CMD} ${BOOTSTRAP_ARGS} > in ${APT_BOOST_SRC}:\n${BS_OUTPUT}\n${BS_ERROR}\n") > endif() > > # > # run b2 > # > set(B2_ARGS "link=static" "threading=multi" "runtime-link=static" > "variant=release") > foreach(COMP IN LISTS APT_BOOST_COMPONENTS) > set(B2_ARGS "--with-${COMP}" ${B2_ARGS}) > endforeach(COMP IN LISTS APT_BOOST_COMPONENTS) > > set(B2_ARGS ${B2_ARGS} install) > set(B2_CMD "./b2") > message("Executing command: ${B2_CMD} ${B2_ARGS}") > execute_process(COMMAND ${B2_CMD} ${B2_ARGS} WORKING_DIRECTORY > ${APT_BOOST_SRC} > RESULT_VARIABLE B2_RESULT OUTPUT_VARIABLE B2_OUTPUT ERROR_VARIABLE > B2_ERROR) > if(NOT B2_RESULT EQUAL 0) > message(FATAL_ERROR "Failed running ${B2_CMD} in > ${APT_BOOST_SRC}:\n${B2_OUTPUT}\n${B2_ERROR}\n") > endif() > > endfunction() > > > set(APT_BOOST_BIN "${CMAKE_CURRENT_SOURCE_DIR}/boost_requirements") > SET(BOOST_ROOT "${APT_BOOST_BIN}") > FIND_PACKAGE( Boost 1.57 REQUIRED COMPONENTS log thread filesystem system) > > if(NOT Boost_FOUND) > MESSAGE (STATUS "Installing boost") > install_boost() > else(NOT Boost_FOUND) > MESSAGE (STATUS "Boost install already exists") > endif(NOT Boost_FOUND) > > MESSAGE (STATUS "Find package again") > FIND_PACKAGE( Boost 1.57 REQUIRED COMPONENTS log thread filesystem system ) > > > My output is: > > Executing command: ./b2 > --with-system;--with-filesystem;--with-thread;--with-log;link=static;threading=multi;runtime-link=static;variant=release;install > -- Find package again > CMake Error at /usr/share/cmake-2.8/Modules/FindBoost.cmake:1131 (message): > Unable to find the requested Boost libraries. > > Boost version: 1.54.0 > > Boost include path: /usr/include > > Detected version of Boost is too old. Requested version was 1.57 (or > newer). > Call Stack (most recent call first): > CMakeLists.txt:123 (FIND_PACKAGE) > > > -- Configuring incomplete, errors occurred! > > > After the script completes the boost install exists. > Interestingly, after running the script for the first time, deleting the > generated CMakeCache.txt and rerunning the script, it does find the boost > install. > > Thanks, > Matt > > On Fri, Apr 24, 2015 at 4:09 PM, David Cole wrote: >> >> How do you do step 3) -- build boost? >> >> Unless the build is done and installed and ready to find before the >> end of step 3, there is still nothing (yet) there for the find_package >> in step 4 to find... >> >> >> David C. >> >> >> On Fri, Apr 24, 2015 at 9:36 AM, matzeNOTAVAILABLE . >> wrote: >> > Hi, >> > i am struggling somewhat with find_package. I looked at the >> > documentation >> > and googled quite a bit, but i am still stuck. I alos tried >> > stackoverflow to >> > no avail. >> > >> > What i am trying to accomplish is the following: >> > 1) See if my custom boost installation exists (using find_package) >> > (version >> > 1.57) >> > 2) If it does not -> build it >> > 3) Use find_package again to find the newly built boost libs. >> > >> > This works up until but not including step 3. >> > >> > Something that it might be complicating matters (i am not sure) is that >> > i >> > have a system boost installation (1.54). >> > >> > 1) (... set boost_root ...) >> > 2) FIND_PACKAGE(Boost 1.57 COMPONENTS log thread filesystem system) >> > 3) (... build boost if it Boost_FOUND is 0) >> > 4) FIND_PACKAGE(Boost 1.57 REQUIRED COMPONENTS log thread filesystem >> > system) >> > >> > The second call to find_package does not find the boost installation and >> > thus does not set include dirs etc... properly. >> > >> > I wonder why not? >> > >> > Any hints are greatly appreciated, >> > Matt >> > >> > >> > -- >> > >> > Powered by www.kitware.com >> > >> > Please keep messages on-topic and check the CMake FAQ at: >> > http://www.cmake.org/Wiki/CMake_FAQ >> > >> > Kitware offers various services to support the CMake community. For more >> > information on each offering, please visit: >> > >> > CMake Support: http://cmake.org/cmake/help/support.html >> > CMake Consulting: http://cmake.org/cmake/help/consulting.html >> > CMake Training Courses: http://cmake.org/cmake/help/training.html >> > >> > Visit other Kitware open-source projects at >> > http://www.kitware.com/opensource/opensource.html >> > >> > Follow this link to subscribe/unsubscribe: >> > http://public.kitware.com/mailman/listinfo/cmake > > From chuck.atkins at kitware.com Fri Apr 24 14:44:06 2015 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Fri, 24 Apr 2015 14:44:06 -0400 Subject: [CMake] find_package In-Reply-To: References: Message-ID: Hi Matt, 1) (... set boost_root ...) > 2) FIND_PACKAGE(Boost 1.57 COMPONENTS log thread filesystem system) > If you're using CMake >= 3.0, then there's a Boost_NAMESPACE variable you can set that will cause the find module look for mangled library names line myboostnamespace_datetime instead of boost_datetime. You can generate a source tree with an alternate namespace using the boost bcp tool. I know that doesn't seem to be your issue at the moment but it could help in making sure your system boost doesn't get found. > 3) (... build boost if it Boost_FOUND is 0) > Unrelated to your issue, but in general, when testing boolean variables in CMake, it's best to treat them as a true/false value instead of integers or strings. So instead of "if(Boost_FOUND EQUAL 0)", use "if(NOT Boost_FOUND)". The reasoning is that there are many different ways to create true/false boolean values in cmake. For example, a false boolean value can be represented as NO, 0, FALSE, OFF, "", etc. By just letting the variable act as a boolean, it streamlines the code needing to deal with it. > 4) FIND_PACKAGE(Boost 1.57 REQUIRED COMPONENTS log thread filesystem > system) > >From what I can tell, it doesn't look like you set an updated BOOST_ROOT to the install prefix of the newly built boost, i.e. ${APT_BOOST_BIN}. Without that, it's just going to look in the same places as before. Also try setting Boost_DEBUG=ON before the find package calls. This will output some additional debugging information for the find module regarding what and where it's actually searching for. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gjasny at googlemail.com Fri Apr 24 15:00:22 2015 From: gjasny at googlemail.com (Gregor Jasny) Date: Fri, 24 Apr 2015 21:00:22 +0200 Subject: [CMake] Detecting -m32 build target on 64-bit host In-Reply-To: References: Message-ID: <553A92C6.6040602@googlemail.com> Hi, On 23/04/15 16:54, Mateusz Loskot wrote: > Surprisingly, I'm having trouble to figure out how to determine, > that in Linux 64-bit OS, I'm building a project with -m32 specified. > IOW, any CMake variable or macro to tell me target architecture > of a build that is being configured is 32 or 64 bit? Does this help? include(CheckSymbolExists) if(WIN32) check_symbol_exists("_M_AMD64" "" RTC_ARCH_X64) if(NOT RTC_ARCH_X64) check_symbol_exists("_M_IX86" "" RTC_ARCH_X86) endif(NOT RTC_ARCH_X64) # add check for arm here # see http://msdn.microsoft.com/en-us/library/b0084kay.aspx else(WIN32) check_symbol_exists("__i386__" "" RTC_ARCH_X86) check_symbol_exists("__x86_64__" "" RTC_ARCH_X64) check_symbol_exists("__arm__" "" RTC_ARCH_ARM) endif(WIN32) -Gregor From irwin at beluga.phys.uvic.ca Fri Apr 24 15:33:50 2015 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Fri, 24 Apr 2015 12:33:50 -0700 (PDT) Subject: [CMake] What is the proper way to export targets that will be split into separate binary packages? Message-ID: The Fedora packager of PLplot is having trouble splitting installed results into separate binary packages because of the way that PLplot currently exports its targets. What steps do we have to do to make life easier for him? Here is the typical code we use now to export our targets. # Done only once install(EXPORT export_plplot DESTINATION ${LIB_DIR}/cmake/plplot) # Done for each different PLplot library target we want to export install(TARGETS EXPORT export_plplot ARCHIVE DESTINATION ${LIB_DIR} LIBRARY DESTINATION ${LIB_DIR} RUNTIME DESTINATION ${BIN_DIR} ) # Done for each different PLplot executable target we want to export install(TARGETS EXPORT export_plplot DESTINATION ${BIN_DIR} ) As a result of these commands, $prefix/lib/cmake/plplot contains three files: export_plplot-noconfig.cmake, export_plplot.cmake, and plplotConfig.cmake I can find no reference to the noconfig variant, but from the documentation, find_package(plplot) in Config mode will find plplotConfig.cmake which in turn includes export_plplot.cmake which has CMake logic that loops over _every_ exported target. For a completely separate build system (for our installed examples) we import all these targets using find_package(plplot) and that works well for individual use of PLplot where nothing is split out from the installation. However, that command does not work well for binary packagers of PLplot since those packagers generally split the installed files into a bunch of different binary packages (typically a core package and optional additional packages to add extra features to the core package). So if the Fedora packager, for example, splits out the octave component of PLplot into a separate binary package, then when that package is not installed, find_package(plplot) errors out (as a result of that loop over all exported targets) with CMake Error at /usr/lib64/cmake/plplot/export_plplot.cmake:163 (message): The imported target "plplot_octave" references the file "/usr/lib64/octave/site/oct/x86_64-redhat-linux-gnu/plplot_octave.oct" but this file does not exist. [...] What changes to the above export procedure and/or find_package(plplot ... ) command are recommended so that find_package(plplot ....) just works when some split PLplot binary packages are not installed? Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From orion at cora.nwra.com Fri Apr 24 16:13:26 2015 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 24 Apr 2015 14:13:26 -0600 Subject: [CMake] Documenting when cmake functions were added Message-ID: <553AA3E6.1080005@cora.nwra.com> It would be really nice if the docs like: http://www.cmake.org/cmake/help/v3.2/module/CheckCXXSourceCompiles.html would indicate what version of cmake it was added in. Is this recorded anywhere? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com From wonder.mice at gmail.com Fri Apr 24 18:05:52 2015 From: wonder.mice at gmail.com (Andrey Pokrovskiy) Date: Fri, 24 Apr 2015 15:05:52 -0700 Subject: [CMake] ExternalProject_Add not re-building when source changes In-Reply-To: References: Message-ID: I don't like my current solution for such problem, but it works for me well. Note "file(GLOB_RECURSE ..." and custom "copy" step in the end. Also you can try to google "cmake super build" which probably will provide you more ideas. ---- include(ExternalProject) set(WEBSOCKETS_PATCH_DIR "${CMAKE_CURRENT_SOURCE_DIR}/patch") set(WEBSOCKETS_SOURCE_DIR "${CMAKE_CURRENT_SOURCE_DIR}/libwebsockets-1.4") set(WEBSOCKETS_BUILD_SOURCE_DIR "${CMAKE_CURRENT_BINARY_DIR}/libwebsockets-1.4.source") set(WEBSOCKETS_BUILD_DIR "${CMAKE_CURRENT_BINARY_DIR}/libwebsockets-1.4.build") set(WEBSOCKETS_INSTALL_PREFIX "${CMAKE_CURRENT_BINARY_DIR}/libwebsockets-1.4.install") ExternalProject_Add(websockets_ep EXCLUDE_FROM_ALL 1 SOURCE_DIR ${WEBSOCKETS_BUILD_SOURCE_DIR} BINARY_DIR ${WEBSOCKETS_BUILD_DIR} DOWNLOAD_COMMAND "" PATCH_COMMAND find ${WEBSOCKETS_PATCH_DIR} -name "*.patch" -exec patch -d ${WEBSOCKETS_BUILD_SOURCE_DIR} -p1 -i {} $ INSTALL_DIR ${WEBSOCKETS_INSTALL_PREFIX} CMAKE_ARGS -DCMAKE_TOOLCHAIN_FILE:string=${CMAKE_TOOLCHAIN_FILE} CMAKE_CACHE_ARGS -DCMAKE_BUILD_TYPE:string=${CMAKE_BUILD_TYPE} -DCMAKE_INSTALL_PREFIX:string= -DCMAKE_PREFIX_PATH:string=${CMAKE_PREFIX_PATH}) file(GLOB_RECURSE WEBSOCKETS_SOURCES RELATIVE "${CMAKE_CURRENT_SOURCE_DIR}" "${CMAKE_CURRENT_SOURCE_DIR}/*") ExternalProject_Add_Step(websockets_ep copy COMMAND ${CMAKE_COMMAND} -E copy_directory ${WEBSOCKETS_SOURCE_DIR} ${WEBSOCKETS_BUILD_SOURCE_DIR} DEPENDS ${WEBSOCKETS_SOURCES} DEPENDEES download DEPENDERS patch) add_library(websockets INTERFACE) target_include_directories(websockets INTERFACE ${WEBSOCKETS_INSTALL_PREFIX}/include) target_link_libraries(websockets INTERFACE ${WEBSOCKETS_INSTALL_PREFIX}/lib/libwebsockets.a) add_dependencies(websockets websockets_ep) On Thu, Apr 23, 2015 at 4:54 PM, Rob McDonald wrote: > I've used ExternalProject_Add to trick CMake into supporting two > compilers to build my project. > > Part of my project needs OpenMP, but other parts do not. So, on > MacOS, I would prefer to build most of the project with CLang, but the > OpenMP requiring part with gcc. > > I have CMake set up to detect whether the compiler supports OpenMP. > If it does not, it checks for a user-supplied alternate compiler. > > If the user has supplied an alternate compiler, CMake treats the > current directory as an ExternalProject , but passes the alternate > OpenMP capable compiler. > > In general, this works well. However, this arrangement does not > notice when the source files have changed and cause the External > Project to rebuild. > > I'm using ExternalProject_ForceBuild to try to make the EP build every > time -- that works, but once inside the EP, make doesn't recognize > that the source files have been updated. > > The meat of the situation is something like this.... > > ExternalProject_Add( MYPROJECT > URL ${CMAKE_CURRENT_SOURCE_DIR} > CMAKE_ARGS -DCMAKE_C_COMPILER=${C_ALTERNATE_COMPILER} > -DCMAKE_CXX_COMPILER=${CXX_ALTERNATE_COMPILER} > -DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE} > -DEP_BUILD=TRUE > INSTALL_COMMAND "" > ) > EP_ForceBuild( MYPROJECT ) > > I use the -DEP_BUILD=TRUE as an extra safety to prevent infinite > recursion -- if the user supplied a non OpenMP capable compiler as the > ALTERNATE_COMPILER. > > So, I think the problem is with my use of 'URL > ${CMAKE_CURRENT_SOURCE_DIR}'. Is there a better way to achieve the > same thing? > > Thanks in advance, > > Rob > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 markus456 at gmail.com Sat Apr 25 05:01:43 2015 From: markus456 at gmail.com (Markus =?ISO-8859-1?Q?M=E4kel=E4?=) Date: Sat, 25 Apr 2015 12:01:43 +0300 Subject: [CMake] Problems with CPack RPM Message-ID: <1429952503.19026.7.camel@gmail.com> Hi, I'm working on a project that uses CMake for build configuration and CPack for packaging. We're running on Linux and seem to run into some issues with CPack when INSTALL commands have absolute paths. When we use Makefiles as the build tool, have absolute paths in the DESTINATION of the INSTALL command and we are building RPM or DEB packages, the make package commands seems to install these files to those absolute paths on the system we are doing the packaging on. This makes it so that we need to use root to build packages and I'd like to avoid this. Is this a bug with how CPack handles RPM and DEB packaging or am I doing something wrong? I've managed to somewhat bypass this by doing a lot of the absolute path installations in the post-install script but in the long run I would like to avoud this. Markus From a.neundorf-work at gmx.net Sat Apr 25 16:14:14 2015 From: a.neundorf-work at gmx.net (Alexander Neundorf) Date: Sat, 25 Apr 2015 22:14:14 +0200 Subject: [CMake] What is the proper way to export targets that will be split into separate binary packages? In-Reply-To: References: Message-ID: <59585387.TrfW6G8uhX@tuxedo.neundorf.net> On Friday, April 24, 2015 12:33:50 Alan W. Irwin wrote: > The Fedora packager of PLplot is having trouble splitting installed > results into separate binary packages because of the way that PLplot > currently exports its targets. What steps do we have to do to make > life easier for him? > > Here is the typical code we use now to export our targets. > > # Done only once > install(EXPORT export_plplot DESTINATION ${LIB_DIR}/cmake/plplot) > > # Done for each different PLplot library target we want to export > install(TARGETS > EXPORT export_plplot > ARCHIVE DESTINATION ${LIB_DIR} > LIBRARY DESTINATION ${LIB_DIR} > RUNTIME DESTINATION ${BIN_DIR} > ) > > # Done for each different PLplot executable target we want to export > install(TARGETS > EXPORT export_plplot > DESTINATION ${BIN_DIR} > ) > > As a result of these commands, $prefix/lib/cmake/plplot contains > three files: > > export_plplot-noconfig.cmake, export_plplot.cmake, and plplotConfig.cmake > > I can find no reference to the noconfig variant, but from the > documentation, find_package(plplot) in Config mode will find > plplotConfig.cmake which in turn includes export_plplot.cmake which > has CMake logic that loops over _every_ exported target. > > For a completely separate build system (for our installed examples) > we import all these targets using > > find_package(plplot) > > and that works well for individual use of PLplot where nothing is > split out from the installation. > > However, that command does not work well for binary packagers of > PLplot since those packagers generally split the installed files into > a bunch of different binary packages (typically a core package and > optional additional packages to add extra features to the core > package). So if the Fedora packager, for example, splits out the > octave component of PLplot into a separate binary package, then when > that package is not installed, find_package(plplot) errors out (as a > result of that loop over all exported targets) with > > CMake Error at /usr/lib64/cmake/plplot/export_plplot.cmake:163 (message): > The imported target "plplot_octave" references the file > > "/usr/lib64/octave/site/oct/x86_64-redhat-linux-gnu/plplot_octave.oct" > > but this file does not exist. [...] > > What changes to the above export procedure and/or > find_package(plplot ... ) command are recommended so that > find_package(plplot ....) just works when some split PLplot > binary packages are not installed? IIRC putting the targets which will end up in separate packages should be put into separate exports. To use everything later on using one find_package() call, you probably need one "umbrella" config file. Alex From dhirvonen at elucideye.com Sun Apr 26 00:09:41 2015 From: dhirvonen at elucideye.com (David Hirvonen) Date: Sun, 26 Apr 2015 00:09:41 -0400 Subject: [CMake] cmake iOS application + framework link error Message-ID: I'm hitting a link error when linking an iOS application with an internally created framework/library using the the CMake Xcode generator and an iOS toolchain. I've put together a minimal CMakeLists.txt example here: https://github.com/headupinclouds/cmake_framework_test/ The problem is described in detail in the the README, and reproduced here in the email for completeness. The repository is intended as a simple unit test to illustrate an apparent link and build location mismatch when linking a framework to an iOS application using the "standard" iOS toolchain (I realize this toolchain isn't provided with CMake). I've included the ios toolchain in this repository to make it easy to reproduce the issue. I've include both the iOS application that reproduces the link error, and an OS X application, which links to the library in correct framework location. I'm looking for a CMakeLists.txt fix or possible workaround. There are two top level convenience bash scripts for building the applications with cmake using an xcode generator. The CMake version is 3.2.1. cmake --version cmake version 3.2.1 iOS framework and application error: bash -fx ./test-ios.sh + NAME=_builds/ios + cmake -GXcode -H. -B_builds/ios -DCMAKE_TOOLCHAIN_FILE=iOS.cmake clang: error: no such file or directory: '/Users/dhirvonen/devel/cmake_framework_test/_builds/ios/Debug-iphoneos/TF.framework/Versions/A/TF' ** BUILD FAILED ** The following build commands failed: Ld _builds/ios/Debug-iphoneos/testa.app/testa normal armv7 (1 failure) library path: _builds/ios/Debug-iphoneos/TF.framework/TF This produces a flat framework layout (ignoring the FRAMEWORK_VERSION property (which is fine with me if I can get it to work)). It looks like this: tree _builds/ios/Debug-iphoneos/TF.framework _builds/ios/Debug-iphoneos/TF.framework ??? Info.plist ??? TF ??? _CodeSignature ??? CodeResources But when it reaches the link command for the ios application: target_link_libraries(testa TF) it fails, since it seems to expect the library to be two directories down within a versioned framework layout: TF.framework/Versions/A/TF instead the directory is here: TF.framework/TF I'm looking for a solution to either: - correct the TF link path to use the actual (non versioned) framework layout that is currently generated, or - correct the framework so that it uses the versioned layout to make that consistent with the link path OS X framework and application success: When I build this for OS X it seems to work fine. bash -fx ./test-osx.sh + NAME=_builds/osx + cmake -GXcode -H. -B_builds/osx ** BUILD SUCCEEDED ** library path: _builds/osx/Debug/TF.framework/Versions/A/TF This produces a framework with the following layout: tree _builds/osx/Debug/ _builds/osx/Debug/ ??? TF.framework ? ??? Resources -> Versions/Current/Resources ? ??? TF -> Versions/Current/TF ? ??? Versions ? ??? A ? ? ??? Resources ? ? ? ??? Info.plist ? ? ??? TF ? ? ??? _CodeSignature ? ? ??? CodeResources ? ??? Current -> A ??? testb and the call to target_link_libraries(testb TF) picks up the TF library in the correct location. I'm curious if there is a variable or property that needs to be set for the iOS example to give the same framework layout. -------------- next part -------------- An HTML attachment was scrubbed... URL: From domen.vrankar at gmail.com Sun Apr 26 08:16:29 2015 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Sun, 26 Apr 2015 14:16:29 +0200 Subject: [CMake] Problems with CPack RPM In-Reply-To: <1429952503.19026.7.camel@gmail.com> References: <1429952503.19026.7.camel@gmail.com> Message-ID: 2015-04-25 11:01 GMT+02:00 Markus M?kel? : > Hi, > > I'm working on a project that uses CMake for build configuration and > CPack for packaging. We're running on Linux and seem to run into some > issues with CPack when INSTALL commands have absolute paths. > > When we use Makefiles as the build tool, have absolute paths in the > DESTINATION of the INSTALL command and we are building RPM or DEB > packages, the make package commands seems to install these files to > those absolute paths on the system we are doing the packaging on. This > makes it so that we need to use root to build packages and I'd like to > avoid this. > > Is this a bug with how CPack handles RPM and DEB packaging or am I doing > something wrong? I've managed to somewhat bypass this by doing a lot of > the absolute path installations in the post-install script but in the > long run I would like to avoud this. Hi, It's probably a bug. I've noticed this a while ago on Redhat Linux (worked fine on Ubuntu though) but haven't got arround to investigate why that happens - for me it's lower priority as not all package generators even support absolute paths. As a workarround you could use relative paths and choose for INSTALL and PACKAGING prefix / and manage other relocation subpaths with relative paths from http://www.cmake.org/cmake/help/v3.2/module/GNUInstallDirs.html (with CPack 3.2 and above you can use multiple relocation prefixes). Regards, Domen From markus456 at gmail.com Sun Apr 26 10:41:23 2015 From: markus456 at gmail.com (=?UTF-8?B?TWFya3VzIE3DpGtlbMOk?=) Date: Sun, 26 Apr 2015 17:41:23 +0300 Subject: [CMake] Problems with CPack RPM In-Reply-To: References: <1429952503.19026.7.camel@gmail.com> Message-ID: Hi, Thanks for your response. I think I'll try using / as the install prefix. This would seem like a good solution for my situation. The GNUinstallDIRS module seems like a good way to manage installation directories across all distributions. I haven't come across it before so thank you for that also. Markus On Apr 26, 2015 3:16 PM, "Domen Vrankar" wrote: > 2015-04-25 11:01 GMT+02:00 Markus M?kel? : > > Hi, > > > > I'm working on a project that uses CMake for build configuration and > > CPack for packaging. We're running on Linux and seem to run into some > > issues with CPack when INSTALL commands have absolute paths. > > > > When we use Makefiles as the build tool, have absolute paths in the > > DESTINATION of the INSTALL command and we are building RPM or DEB > > packages, the make package commands seems to install these files to > > those absolute paths on the system we are doing the packaging on. This > > makes it so that we need to use root to build packages and I'd like to > > avoid this. > > > > Is this a bug with how CPack handles RPM and DEB packaging or am I doing > > something wrong? I've managed to somewhat bypass this by doing a lot of > > the absolute path installations in the post-install script but in the > > long run I would like to avoud this. > > Hi, > > It's probably a bug. > I've noticed this a while ago on Redhat Linux (worked fine on Ubuntu > though) but haven't got arround to investigate why that happens - for > me it's lower priority as not all package generators even support > absolute paths. > > As a workarround you could use relative paths and choose for INSTALL > and PACKAGING prefix / and manage other relocation subpaths with > relative paths from > http://www.cmake.org/cmake/help/v3.2/module/GNUInstallDirs.html (with > CPack 3.2 and above you can use multiple relocation prefixes). > > Regards, > Domen > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dummdoof-doof at web.de Sun Apr 26 14:46:07 2015 From: dummdoof-doof at web.de (typ1232) Date: Sun, 26 Apr 2015 11:46:07 -0700 (MST) Subject: [CMake] Do build after GIT_TAG changed in ExternalProject_Add In-Reply-To: References: <1429369490097-7590299.post@n2.nabble.com> <1429394330993-7590302.post@n2.nabble.com> <1429533108166-7590316.post@n2.nabble.com> <1429533936969-7590317.post@n2.nabble.com> Message-ID: <1430073967557-7590385.post@n2.nabble.com> Does anyone know a workaround for my issue or an alternative approach? Using ExternalProject would be more convenient than using git submodules. Instead of specifying the commit in .gitmodules, I would like to do it with GIT_TAG. -- View this message in context: http://cmake.3232098.n2.nabble.com/Do-build-after-GIT-TAG-changed-in-ExternalProject-Add-tp7590299p7590385.html Sent from the CMake mailing list archive at Nabble.com. From eric.noulard at gmail.com Sun Apr 26 17:00:23 2015 From: eric.noulard at gmail.com (Eric Noulard) Date: Sun, 26 Apr 2015 23:00:23 +0200 Subject: [CMake] Problems with CPack RPM In-Reply-To: <1429952503.19026.7.camel@gmail.com> References: <1429952503.19026.7.camel@gmail.com> Message-ID: 2015-04-25 11:01 GMT+02:00 Markus M?kel? : > Hi, > > I'm working on a project that uses CMake for build configuration and > CPack for packaging. We're running on Linux and seem to run into some > issues with CPack when INSTALL commands have absolute paths. > > When we use Makefiles as the build tool, have absolute paths in the > DESTINATION of the INSTALL command and we are building RPM or DEB > packages, the make package commands seems to install these files to > those absolute paths on the system we are doing the packaging on. This > makes it so that we need to use root to build packages and I'd like to > avoid this. > Installing to absolute destination is always a difficult issue. When doing this CPack must do some trick to avoid what you observe, i.e. install the file on the real system. This issue is independent of the generator (ZIP, RPM, DEB etc...) The "install" part must set DESTDIR (internally to CPack). (See CPACK_SET_DESTDIR) Then depending of each generator some more trick are necessary. For example CPackRPM tries to monitor those "absoluterly installed files" in order to flag them as "config files" using %config in order to try to keep the building of a relocatable RPM. > > Is this a bug with how CPack handles RPM and DEB packaging or am I doing > something wrong? I've managed to somewhat bypass this by doing a lot of > the absolute path installations in the post-install script but in the > long run I would like to avoud this. > Usually you should ALWAYS use relative install path but for seldom cases like /etc/whatever-file or the like. Concering RPM, absolute installed file should work: try to run cpack -D CPACK_WARN_ON_ABSOLUTE_INSTALL_DESTINATION=1 and check whether if the log correspond to your absolute installed files additionnally CPack RPM may spit more verbose output using: -D CPACK_RPM_PACKAGE_DEBUG=1 Eric > > Markus > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From matze999 at gmail.com Mon Apr 27 07:11:46 2015 From: matze999 at gmail.com (matzeNOTAVAILABLE .) Date: Mon, 27 Apr 2015 13:11:46 +0200 Subject: [CMake] find_package In-Reply-To: References: Message-ID: Hi, thanks for the replies. I am still facing the same issue. For those interested, here is how to reproduce the issue: - mkdir test; cd test - mkdir build; mkdir src; mkdir external - wget -O external/boost_1_57_0.tar.bz2 http://sourceforge.net/projects/boost/files/boost/1.57.0/boost_1_57_0.tar.bz2/download - put the cmake script contained in this email into the src directory as CMakeLists.txt - cd build - cmake ../src After this fails, if i delete CMakeCache.txt and rerun the script, it works. In fact it seems to be related to the line: Boost_INCLUDE_DIR:PATH=/usr/include which is in CMakeCache.txt. The cmake script is that needs to go in the src directory is as follows: cmake_minimum_required (VERSION 2.8) function(install_boost) set(APT_BOOST_SRC "../external/boost_1_57_0") MESSAGE(STATUS "APT_BOOST_SRC: " ${APT_BOOST_SRC}) set(APT_BOOST_COMPONENTS "log" "thread" "filesystem" "system") set(BOOTSTRAP_CMD "./bootstrap.sh") set(BOOTSTRAP_ARGS "--prefix=${APT_BOOST_BIN}") message("Executing command: ${BOOTSTRAP_CMD} ${BOOTSTRAP_ARGS}") execute_process(COMMAND "${BOOTSTRAP_CMD}" ${BOOTSTRAP_ARGS} WORKING_DIRECTORY ${APT_BOOST_SRC} RESULT_VARIABLE BS_RESULT OUTPUT_VARIABLE BS_OUTPUT ERROR_VARIABLE BS_ERROR) if(NOT BS_RESULT EQUAL 0) message(FATAL_ERROR "Failed running ${BOOTSTRAP_CMD} ${BOOTSTRAP_ARGS} in ${APT_BOOST_SRC}:\n${BS_OUTPUT}\n${BS_ERROR}\n") endif() # # run b2 # set(B2_ARGS "link=static" "threading=multi" "runtime-link=static" "variant=release") foreach(COMP IN LISTS APT_BOOST_COMPONENTS) set(B2_ARGS "--with-${COMP}" ${B2_ARGS}) endforeach(COMP IN LISTS APT_BOOST_COMPONENTS) if(WIN32) if(MSVC11) set(B2_ARGS "--toolset=msvc-11.0" ${B2_ARGS}) elseif(MSVC12) set(B2_ARGS "--toolset=msvc-12.0" ${B2_ARGS}) endif(MSVC11) file(TO_NATIVE_PATH ${APT_BOOST_BIN} APT_BOOST_BIN_WIN) set(B2_ARGS "--prefix=${APT_BOOST_BIN_WIN}" ${B2_ARGS} "architecture=x86" "address-model=64") endif(WIN32) set(B2_ARGS ${B2_ARGS} install) set(B2_CMD "./b2") message("Executing command: ${B2_CMD} ${B2_ARGS}") execute_process(COMMAND ${B2_CMD} ${B2_ARGS} WORKING_DIRECTORY ${APT_BOOST_SRC} RESULT_VARIABLE B2_RESULT OUTPUT_VARIABLE B2_OUTPUT ERROR_VARIABLE B2_ERROR) if(NOT B2_RESULT EQUAL 0) message(FATAL_ERROR "Failed running ${B2_CMD} in ${APT_BOOST_SRC}:\n${B2_OUTPUT}\n${B2_ERROR}\n") endif() endfunction() set(Boost_DEBUG "ON") set(APT_BOOST_BIN "${CMAKE_CURRENT_SOURCE_DIR}/boost_requirements") SET(BOOST_ROOT "${APT_BOOST_BIN}") MESSAGE (STATUS "1) BOOST_ROOT: ${BOOST_ROOT}") FIND_PACKAGE( Boost 1.57 REQUIRED COMPONENTS log thread filesystem system) if(NOT Boost_FOUND) MESSAGE (STATUS "Extracting boost ...") execute_process( COMMAND ${CMAKE_COMMAND} -E tar xjzf ../external/boost_1_57_0.tar.bz2 WORKING_DIRECTORY "../external") MESSAGE (STATUS "Installing boost") install_boost() else(NOT Boost_FOUND) MESSAGE (STATUS "Boost install already exists") endif(NOT Boost_FOUND) MESSAGE (STATUS "2) BOOST_ROOT: ${BOOST_ROOT}") FIND_PACKAGE( Boost 1.57 REQUIRED COMPONENTS log thread filesystem system ) Boost_root as given when setting Boost_Debug=ON appears to be correct. Many thanks, Matt On Fri, Apr 24, 2015 at 4:09 PM, David Cole wrote: > How do you do step 3) -- build boost? > > Unless the build is done and installed and ready to find before the > end of step 3, there is still nothing (yet) there for the find_package > in step 4 to find... > > > David C. > > > On Fri, Apr 24, 2015 at 9:36 AM, matzeNOTAVAILABLE . > wrote: > > Hi, > > i am struggling somewhat with find_package. I looked at the documentation > > and googled quite a bit, but i am still stuck. I alos tried > stackoverflow to > > no avail. > > > > What i am trying to accomplish is the following: > > 1) See if my custom boost installation exists (using find_package) > (version > > 1.57) > > 2) If it does not -> build it > > 3) Use find_package again to find the newly built boost libs. > > > > This works up until but not including step 3. > > > > Something that it might be complicating matters (i am not sure) is that i > > have a system boost installation (1.54). > > > > 1) (... set boost_root ...) > > 2) FIND_PACKAGE(Boost 1.57 COMPONENTS log thread filesystem system) > > 3) (... build boost if it Boost_FOUND is 0) > > 4) FIND_PACKAGE(Boost 1.57 REQUIRED COMPONENTS log thread filesystem > system) > > > > The second call to find_package does not find the boost installation and > > thus does not set include dirs etc... properly. > > > > I wonder why not? > > > > Any hints are greatly appreciated, > > Matt > > > > > > -- > > > > Powered by www.kitware.com > > > > Please keep messages on-topic and check the CMake FAQ at: > > http://www.cmake.org/Wiki/CMake_FAQ > > > > Kitware offers various services to support the CMake community. For more > > information on each offering, please visit: > > > > CMake Support: http://cmake.org/cmake/help/support.html > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > > Visit other Kitware 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 nagger at gmx.de Mon Apr 27 15:45:34 2015 From: nagger at gmx.de (Nagger) Date: Mon, 27 Apr 2015 21:45:34 +0200 Subject: [CMake] find_package In-Reply-To: References: Message-ID: <553E91DE.4090003@gmx.de> Hi, > After this fails, if i delete CMakeCache.txt and rerun the script, it > works. In fact it seems to be related to the line: > Boost_INCLUDE_DIR:PATH=/usr/include > which is in CMakeCache.txt. Than just delete that cache variable (before the second call of find_package): unset(Boost_INCLUDE_DIR CACHE) http://www.cmake.org/cmake/help/v3.1/command/unset.html Greetings, Marc From irwin at beluga.phys.uvic.ca Mon Apr 27 19:13:14 2015 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Mon, 27 Apr 2015 16:13:14 -0700 (PDT) Subject: [CMake] cmp0026, file(GENERATE...), and configure_file In-Reply-To: References: Message-ID: On 2015-04-23 04:19-0700 Alan W. Irwin wrote: > On 2015-04-23 06:47-0400 David Cole wrote: >> In the meantime, while it is certainly clumsy to do the two separate >> commands everywhere, you could write a CMake language >> function(configure_file_generate ...) that takes the same args as >> configure_file, but does the two step in its implementation. > > That is a good idea that should be straightforward for me to implement > as part of the PLplot build system. And here is that function (no guarantees except "it works for me") in case someone who reads this thread later would like to try this interim solution before the preferred GENERATE signature of configure_file is implemented for CMake. function(configure_file_generate) # Configure files that contain both normal items # to configure (referenced as ${VAR} or @VAR@) as well as # generator expressions (referenced as $<...>). # The arguments of this function have exactly the # same syntax and meaning as configure_file. set(intermediate_file_suffix "_cf_only") list(GET ARGV 0 input_file) list(GET ARGV 1 output_file) set(intermediate_file ${output_file}${intermediate_file_suffix}) # Locally modify ARGV so that output file for configure file is # redirected to intermediate_file. list(REMOVE_AT ARGV 1) list(INSERT ARGV 1 ${intermediate_file}) # Configure all but generator expressions. configure_file(${ARGV}) # Configure generator expressions. # N.B. these ${output_file} results will only be available # at generate time. file(GENERATE OUTPUT ${output_file} INPUT ${intermediate_file} ) endfunction(configure_file_generate) Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From irwin at beluga.phys.uvic.ca Mon Apr 27 19:20:45 2015 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Mon, 27 Apr 2015 16:20:45 -0700 (PDT) Subject: [CMake] What is the proper way to export targets that will be split into separate binary packages? In-Reply-To: References: Message-ID: On 2015-04-24 12:33-0700 Alan W. Irwin wrote: This should be a pretty common issue on Linux since it is quite typical there that downstream packaging splits up binary results into different packages. Therefore, I assume there is a CMake solution to this issue, and I would appreciate those who know that solution to speak up. > The Fedora packager of PLplot is having trouble splitting installed > results into separate binary packages because of the way that PLplot > currently exports its targets. What steps do we have to do to make > life easier for him? > > Here is the typical code we use now to export our targets. > > # Done only once > install(EXPORT export_plplot DESTINATION ${LIB_DIR}/cmake/plplot) > > # Done for each different PLplot library target we want to export > install(TARGETS > EXPORT export_plplot > ARCHIVE DESTINATION ${LIB_DIR} > LIBRARY DESTINATION ${LIB_DIR} > RUNTIME DESTINATION ${BIN_DIR} > ) > > # Done for each different PLplot executable target we want to export > install(TARGETS > EXPORT export_plplot > DESTINATION ${BIN_DIR} > ) > > As a result of these commands, $prefix/lib/cmake/plplot contains > three files: > > export_plplot-noconfig.cmake, export_plplot.cmake, and plplotConfig.cmake > > I can find no reference to the noconfig variant, but from the > documentation, find_package(plplot) in Config mode will find > plplotConfig.cmake which in turn includes export_plplot.cmake which > has CMake logic that loops over _every_ exported target. > > For a completely separate build system (for our installed examples) > we import all these targets using > > find_package(plplot) > > and that works well for individual use of PLplot where nothing is > split out from the installation. > > However, that command does not work well for binary packagers of > PLplot since those packagers generally split the installed files into > a bunch of different binary packages (typically a core package and > optional additional packages to add extra features to the core > package). So if the Fedora packager, for example, splits out the > octave component of PLplot into a separate binary package, then when > that package is not installed, find_package(plplot) errors out (as a > result of that loop over all exported targets) with > > CMake Error at /usr/lib64/cmake/plplot/export_plplot.cmake:163 (message): > The imported target "plplot_octave" references the file > > "/usr/lib64/octave/site/oct/x86_64-redhat-linux-gnu/plplot_octave.oct" > > but this file does not exist. [...] > > What changes to the above export procedure and/or find_package(plplot ... ) > command are recommended so that find_package(plplot ....) just works when > some split PLplot binary packages are not installed? > > Alan > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state > implementation for stellar interiors (freeeos.sf.net); the Time > Ephemerides project (timeephem.sf.net); PLplot scientific plotting > software package (plplot.sf.net); the libLASi project > (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); > and the Linux Brochure Project (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From roman.wueger at gmx.at Tue Apr 28 01:00:25 2015 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Tue, 28 Apr 2015 07:00:25 +0200 Subject: [CMake] Identify used source files Message-ID: Hello, is there a proper solution to get all used source files for all defined librarys and executables? My first idea was to overload the main functions such as add_executable() and add_library() temporarily in the main CMakeLists.txt and write a text file or whatever, but I thought there were a better way. Did anybody know a better way? Maybe CMake has a way to get a list of used files? The reason is to clean a big old source tree. Thanks in advance Best regards Roman From nilsgladitz at gmail.com Tue Apr 28 02:56:26 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 28 Apr 2015 08:56:26 +0200 Subject: [CMake] What is the proper way to export targets that will be split into separate binary packages? In-Reply-To: References: Message-ID: <553F2F1A.2080505@gmail.com> On 04/28/2015 01:20 AM, Alan W. Irwin wrote: > On 2015-04-24 12:33-0700 Alan W. Irwin wrote: > > This should be a pretty common issue on Linux since it is quite > typical there that downstream packaging splits up binary results into > different packages. Therefore, I assume there is a CMake solution to > this issue, and I would appreciate those who know that solution to > speak up. I'd go with what Alex suggested in his reply. In effect it is what e.g. Qt5 does (though they don't use cmake to generate the exports obviously and they provide additional package configuration files which you can omit). The umbrella configuration file can use the component specification given to find_package() to iterate over the required target export files. There is an example of this here (scroll down to "If COMPONENTS are specified when the downstream uses[...]"): http://www.cmake.org/cmake/help/v3.2/manual/cmake-packages.7.html#creating-packages Nils From roman.wueger at gmx.at Tue Apr 28 04:30:53 2015 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Tue, 28 Apr 2015 10:30:53 +0200 Subject: [CMake] [cmake-developers] Identify used source files In-Reply-To: References: Message-ID: If someone is interessted in this solution: set(FilenameUsedFiles ${CMAKE_BINARY_DIR}/UsedFiles.lst) file(WRITE ${FilenameUsedFiles} "") function (parseArguments) set(options) set(oneValueArgs) set(multiValueArgs) cmake_parse_arguments(CFG "${options}""${oneValueArgs}" "${multiValueArgs}"${ARGN} ) foreach(file ${ARGN}) get_filename_component(tempPath ${file} DIRECTORY) string(FIND ${file} "${CMAKE_BINARY_DIR}"buildPathFoundPos) string(FIND ${file} "${CMAKE_SOURCE_DIR}"sourcePathFoundPos) if ((NOT "${file}" STREQUAL"IMPORTED") AND (NOT "${file}" STREQUAL "MODULE")AND (NOT "${file}" STREQUAL "STATIC")AND (NOT "${file}" STREQUAL "SHARED")AND (NOT "${file}" STREQUAL "WIN32")AND ${buildPathFoundPos} EQUAL -1) if (${sourcePathFoundPos} EQUAL -1) file(APPEND ${FilenameUsedFiles} "${CMAKE_CURRENT_SOURCE_DIR}/${file}\n") else() file(APPEND ${FilenameUsedFiles} "${file}\n") endif() endif() endforeach() endfunction(parseArguments) function(add_library name) parseArguments(${ARGN}) _add_library(${name} ${ARGN}) endfunction() function(add_executable name) parseArguments(${ARGN}) _add_executable(${name} ${ARGN}) endfunction() Best Regards Roman > Am 28.04.2015 um 07:00 schrieb Roman W?ger : > > Hello, > > is there a proper solution to get all used source files for all defined librarys and executables? > > My first idea was to overload the main functions such as add_executable() and add_library() temporarily in the main CMakeLists.txt and write a text file or whatever, but I thought there were a better way. > > Did anybody know a better way? > > Maybe CMake has a way to get a list of used files? > > The reason is to clean a big old source tree. > > Thanks in advance > > Best regards > Roman > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake-developers From marc.chevrier at sap.com Tue Apr 28 04:48:23 2015 From: marc.chevrier at sap.com (CHEVRIER, Marc) Date: Tue, 28 Apr 2015 08:48:23 +0000 Subject: [CMake] [cmake-developers] Identify used source files In-Reply-To: References: Message-ID: <09E6CFCF-96BB-4D9B-A6F3-F3FC096F890C@sap.com> May be more clean and efficient to use CMake property SOURCES: For example: add_library (MY_LIB src1.cpp src2.cpp) get_target_property (lib_sources MY_LIB SOURCES) And variable lib_sources now contains list of sources associated with target. On 28/04/15 10:30, "Roman W?ger" wrote: >If someone is interessted in this solution: > > >set(FilenameUsedFiles ${CMAKE_BINARY_DIR}/UsedFiles.lst) >file(WRITE ${FilenameUsedFiles} "") > >function (parseArguments) > set(options) > set(oneValueArgs) > set(multiValueArgs) > cmake_parse_arguments(CFG "${options}""${oneValueArgs}" "${multiValueArgs}"${ARGN} ) > > foreach(file ${ARGN}) > get_filename_component(tempPath ${file} DIRECTORY) > string(FIND ${file} "${CMAKE_BINARY_DIR}"buildPathFoundPos) > string(FIND ${file} "${CMAKE_SOURCE_DIR}"sourcePathFoundPos) > > if ((NOT "${file}" STREQUAL"IMPORTED") AND > (NOT "${file}" STREQUAL "MODULE")AND > (NOT "${file}" STREQUAL "STATIC")AND > (NOT "${file}" STREQUAL "SHARED")AND > (NOT "${file}" STREQUAL "WIN32")AND > ${buildPathFoundPos} EQUAL -1) > if (${sourcePathFoundPos} EQUAL -1) > file(APPEND ${FilenameUsedFiles} "${CMAKE_CURRENT_SOURCE_DIR}/${file}\n") > else() > file(APPEND ${FilenameUsedFiles} "${file}\n") > endif() > endif() > endforeach() >endfunction(parseArguments) > >function(add_library name) > parseArguments(${ARGN}) > _add_library(${name} ${ARGN}) >endfunction() > >function(add_executable name) > parseArguments(${ARGN}) > _add_executable(${name} ${ARGN}) >endfunction() > >Best Regards >Roman > >> Am 28.04.2015 um 07:00 schrieb Roman W?ger : >> >> Hello, >> >> is there a proper solution to get all used source files for all defined librarys and executables? >> >> My first idea was to overload the main functions such as add_executable() and add_library() temporarily in the main CMakeLists.txt and write a text file or whatever, but I thought there were a better way. >> >> Did anybody know a better way? >> >> Maybe CMake has a way to get a list of used files? >> >> The reason is to clean a big old source tree. >> >> Thanks in advance >> >> Best regards >> Roman >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake-developers >-- > >Powered by www.kitware.com > >Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > >Kitware offers various services to support the CMake community. For more information on each offering, please visit: > >CMake Support: http://cmake.org/cmake/help/support.html >CMake Consulting: http://cmake.org/cmake/help/consulting.html >CMake Training Courses: http://cmake.org/cmake/help/training.html > >Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > >Follow this link to subscribe/unsubscribe: >http://public.kitware.com/mailman/listinfo/cmake From lukast.dev at gmail.com Tue Apr 28 04:56:06 2015 From: lukast.dev at gmail.com (Lukast dev) Date: Tue, 28 Apr 2015 10:56:06 +0200 Subject: [CMake] (no subject) Message-ID: Hello guys, I use multi-configuration generator (MSVC 2008) and I need to create one solution containing two configurations for one library target N: For build type Debug target N is compiled as static library For build type Release target N is compiled as shared library Something like this, but I know that I can't use CMAKE_BUILD_TYPE variable when I use multi-configuration generator: cmake_minimum_required (VERSION 2.8.11) project (hello) if("${CMAKE_BUILD_TYPE}" STREQUAL "Debug") add_library(hello STATIC main.cpp) elseif("${CMAKE_BUILD_TYPE}" STREQUAL "Release") add_library(hello SHARED main.cpp) endif() I already used CMAKE_CXX_FLAGS_DEBUG and CMAKE_CXX_FLAGS_RELEASE to distinguish some attributes between Debug and Release, but I can't figure it out in case of the library type (SHARED vs STATIC). Any ideas how to achieve it? Thanks Lukas From irwin at beluga.phys.uvic.ca Tue Apr 28 05:43:06 2015 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Tue, 28 Apr 2015 02:43:06 -0700 (PDT) Subject: [CMake] What is the proper way to export targets that will be split into separate binary packages? In-Reply-To: <553F2F1A.2080505@gmail.com> References: <553F2F1A.2080505@gmail.com> Message-ID: On 2015-04-28 08:56+0200 Nils Gladitz wrote: > On 04/28/2015 01:20 AM, Alan W. Irwin wrote: >> On 2015-04-24 12:33-0700 Alan W. Irwin wrote: >> >> This should be a pretty common issue on Linux since it is quite >> typical there that downstream packaging splits up binary results into >> different packages. Therefore, I assume there is a CMake solution to >> this issue, and I would appreciate those who know that solution to >> speak up. > > I'd go with what Alex suggested in his reply. > > In effect it is what e.g. Qt5 does (though they don't use cmake to generate > the exports obviously and they provide additional package configuration files > which you can omit). > > The umbrella configuration file can use the component specification given to > find_package() to iterate over the required target export files. > > There is an example of this here (scroll down to "If COMPONENTS are specified > when the downstream uses[...]"): @Nils: the origin of the code right below "If COMPONENTS..." is not clear. Is that code that should be supplied by a package creator or code that should be implemented by every find_package user? And if it should be supplied by a package creator, does the install(EXPORT...) signature generate that code automatically, does one of the helper functions that are available generate that code, or do I (as package creator) have to supply that code some other way? > > http://www.cmake.org/cmake/help/v3.2/manual/cmake-packages.7.html#creating-packages @Alex: Sorry I missed your reply until now. @Alex or Nils: The problem with the URL provided by Nils is only one library is used in the example so I don't understand exactly what you guys are suggesting for the multiple library/component case. For example, are you recommending install(TARGETS plplot1 EXPORT export_plplot ...) [...] install(TARGETS plplotN EXPORT export_plplot ...) for N installed libraries followed by install(EXPORT export_plplot DESTINATION ${LIB_DIR}/cmake/plplot) ? That is the current pattern I am using with one overall export name called "export_plplot". Or would you recommend this different pattern install(TARGETS plplot1 EXPORT export_plplot1 ...) install(EXPORT export_plplot1 DESTINATION ${LIB_DIR}/cmake/plplot) [...] install(TARGETS plplotN EXPORT export_plplotN ...) install(EXPORT export_plplotN DESTINATION ${LIB_DIR}/cmake/plplot) (i.e., N pairs of install(TARGETS...) install(EXPORT...) signatures with each pair having a unique export name)? Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From nilsgladitz at gmail.com Tue Apr 28 05:57:08 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 28 Apr 2015 11:57:08 +0200 Subject: [CMake] What is the proper way to export targets that will be split into separate binary packages? In-Reply-To: References: <553F2F1A.2080505@gmail.com> Message-ID: <553F5974.6040908@gmail.com> On 04/28/2015 11:43 AM, Alan W. Irwin wrote: > @Nils: the origin of the code right below "If COMPONENTS..." is not > clear. Is that code that should be supplied by a package creator or > code that > should be implemented by every find_package user? And if it should be > supplied by a package creator, does the install(EXPORT...) signature > generate that code automatically, does one of the helper functions > that are available generate that code, or do I (as package creator) > have to supply that code some other way? The package configuration file is normally handwritten (or handgenerated) by the package creator. I assume you already have one? e.g. plplotConfig.cmake. >> http://www.cmake.org/cmake/help/v3.2/manual/cmake-packages.7.html#creating-packages >> > > @Alex: Sorry I missed your reply until now. > > @Alex or Nils: > > The problem with the URL provided by Nils is only one library is used > in the example so I don't understand exactly what you guys are > suggesting for the multiple library/component case. > > For example, are you recommending > > install(TARGETS plplot1 EXPORT export_plplot ...) > [...] > install(TARGETS plplotN EXPORT export_plplot ...) > > for N installed libraries followed by > > install(EXPORT export_plplot DESTINATION ${LIB_DIR}/cmake/plplot) > > ? That is the current pattern I am using with one overall export name > called "export_plplot". Or would you recommend this different pattern > > install(TARGETS plplot1 EXPORT export_plplot1 ...) > install(EXPORT export_plplot1 DESTINATION ${LIB_DIR}/cmake/plplot) > [...] > install(TARGETS plplotN EXPORT export_plplotN ...) > install(EXPORT export_plplotN DESTINATION ${LIB_DIR}/cmake/plplot) > > (i.e., N pairs of install(TARGETS...) install(EXPORT...) signatures > with each pair having a unique export name)? Yes, unique/distinct export names and export files. That way the target export files can go into the respective distribution package that they represent. The "umbrella" package configuration file would be installed by your "core" package and would then be able to pick up the currently available target export files. Nils From cedric.doucet at inria.fr Tue Apr 28 06:04:50 2015 From: cedric.doucet at inria.fr (Cedric Doucet) Date: Tue, 28 Apr 2015 12:04:50 +0200 (CEST) Subject: [CMake] ExternalProject: how to avoid reinstalling after 'make clean'? In-Reply-To: <88244780.274548.1429868154334.JavaMail.zimbra@inria.fr> References: <88244780.274548.1429868154334.JavaMail.zimbra@inria.fr> Message-ID: <27278605.1093426.1430215490587.JavaMail.zimbra@inria.fr> Hello! No one knows how to avoid spurious installations with external projects? Thank you, C?dric ----- Mail original ----- > De: "Cedric Doucet" > ?: cmake at cmake.org > Envoy?: Vendredi 24 Avril 2015 11:35:54 > Objet: ExternalProject: how to avoid reinstalling after 'make clean'? > Hello, > I use the ExternalProjet_Add function to download and install third-party > libraries. > Here is an example of a CMakeLists file containing such a call: > ===================================== > cmake_minimum_required (VERSION 2.6) > project (example CXX) > set(CMAKE_VERBOSE_MAKEFILE ON) > include(ProcessorCount) > ProcessorCount(N) > if(NOT N EQUAL 0) > set(CMAKE_BUILD_FLAGS -j${N}) > endif() > include(ExternalProject) > set(EXTERNAL_DIR ${CMAKE_CURRENT_BINARY_DIR}) > ExternalProject_Add(eigen > PREFIX ${EXTERNAL_DIR}/eigen > DOWNLOAD_DIR ${EXTERNAL_DIR}/eigen/download > SOURCE_DIR ${EXTERNAL_DIR}/eigen/src > BINARY_DIR ${EXTERNAL_DIR}/eigen/build > STAMP_DIR ${EXTERNAL_DIR}/eigen/stamp > INSTALL_DIR ${EXTERNAL_DIR}/eigen/install > URL http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz > URL_MD5 4d0d77e06fef87b4fcd2c9b72cc8dc55 > CMAKE_ARGS -D CMAKE_INSTALL_PREFIX= > ) > ===================================== > Everything works fine, except after calling "make clean". > Thanks to URL_MD5, the third-party library is not downloaded again. > However, configuration, build and install steps are performed again whereas > the library has not been uninstalled during cleaning. > How could I tell to ExternalProject_Add not to configure/build/install my > library unless this library has been removed from my computer? > Thank you very much for your help! > C?dric -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Tue Apr 28 06:21:37 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 28 Apr 2015 12:21:37 +0200 Subject: [CMake] What is the proper way to export targets that will be split into separate binary packages? In-Reply-To: <553F5974.6040908@gmail.com> References: <553F2F1A.2080505@gmail.com> <553F5974.6040908@gmail.com> Message-ID: <553F5F31.3040609@gmail.com> On 04/28/2015 11:57 AM, Nils Gladitz wrote: >> install(TARGETS plplot1 EXPORT export_plplot1 ...) >> install(EXPORT export_plplot1 DESTINATION ${LIB_DIR}/cmake/plplot) >> [...] >> install(TARGETS plplotN EXPORT export_plplotN ...) >> install(EXPORT export_plplotN DESTINATION ${LIB_DIR}/cmake/plplot) >> >> (i.e., N pairs of install(TARGETS...) install(EXPORT...) signatures >> with each pair having a unique export name)? > > Yes, unique/distinct export names and export files. Perhaps to clarify unique/distinct export files at the granularity you actually require which doesn't necessarily mean one per target unless you intend to package each target independently. Nils From johannes.zarl at jku.at Tue Apr 28 06:36:01 2015 From: johannes.zarl at jku.at (Johannes Zarl) Date: Tue, 28 Apr 2015 12:36:01 +0200 Subject: [CMake] ExternalProject: how to avoid reinstalling after 'make clean'? In-Reply-To: <27278605.1093426.1430215490587.JavaMail.zimbra@inria.fr> References: <88244780.274548.1429868154334.JavaMail.zimbra@inria.fr> <27278605.1093426.1430215490587.JavaMail.zimbra@inria.fr> Message-ID: <6036632.oTdTop7kWM@ersa> Hi Cedric, This is something that ExternalProject cannot really do for you in an automatic/safe way. When you do a make clean, you wipe out all knowledge about the installed package. However, you can implement this yourself: Before you do the ExternalProject_Add(eigen ...) call, you can call find_package(eigen) and if you find the package, you just skip the ExternalProject_Add. Cheers, Johannes On Tuesday 28 April 2015 12:04:50 Cedric Doucet wrote: > Hello! > > No one knows how to avoid spurious installations with external projects? > > Thank you, > > C?dric > > ----- Mail original ----- > > > De: "Cedric Doucet" > > ?: cmake at cmake.org > > Envoy?: Vendredi 24 Avril 2015 11:35:54 > > Objet: ExternalProject: how to avoid reinstalling after 'make clean'? > > > > Hello, > > > > I use the ExternalProjet_Add function to download and install third-party > > libraries. > > Here is an example of a CMakeLists file containing such a call: > > > > ===================================== > > cmake_minimum_required (VERSION 2.6) > > > > project (example CXX) > > > > set(CMAKE_VERBOSE_MAKEFILE ON) > > > > include(ProcessorCount) > > ProcessorCount(N) > > if(NOT N EQUAL 0) > > set(CMAKE_BUILD_FLAGS -j${N}) > > endif() > > > > include(ExternalProject) > > set(EXTERNAL_DIR ${CMAKE_CURRENT_BINARY_DIR}) > > ExternalProject_Add(eigen > > PREFIX ${EXTERNAL_DIR}/eigen > > DOWNLOAD_DIR ${EXTERNAL_DIR}/eigen/download > > SOURCE_DIR ${EXTERNAL_DIR}/eigen/src > > BINARY_DIR ${EXTERNAL_DIR}/eigen/build > > STAMP_DIR ${EXTERNAL_DIR}/eigen/stamp > > INSTALL_DIR ${EXTERNAL_DIR}/eigen/install > > URL http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz > > URL_MD5 4d0d77e06fef87b4fcd2c9b72cc8dc55 > > CMAKE_ARGS -D CMAKE_INSTALL_PREFIX= > > ) > > > > ===================================== > > > > Everything works fine, except after calling "make clean". > > Thanks to URL_MD5, the third-party library is not downloaded again. > > However, configuration, build and install steps are performed again > > whereas > > the library has not been uninstalled during cleaning. > > > > How could I tell to ExternalProject_Add not to configure/build/install my > > library unless this library has been removed from my computer? > > > > Thank you very much for your help! > > > > C?dric From ramey at rrsd.com Tue Apr 28 08:47:36 2015 From: ramey at rrsd.com (Robert Ramey) Date: Tue, 28 Apr 2015 05:47:36 -0700 (MST) Subject: [CMake] C++Now / BoostCon / Boost 2.0 Message-ID: <1430225256313-7590405.post@n2.nabble.com> I will be giving a presentation at C++Now http://cppnow.org https://cppnow2015.sched.org all things boost - which will touch upon CMake/CTest/CDash. I have recommended CMake... for boost - like projects and would like to see it more widely accepted. http://rrsd.com/blincubator.com/tools_cmak/ I'm aware that in the past there was a large effort to switch boost to CMake from Boost Build which ended in failure. For Boost 2.0 https://cppnow2015.sched.org/event/d66a14e9cc28cffbf446b1fd2c3f4696#.VT-AV87_Suc I will promote the idea of boost libraries being less tightly coupled. Part of will be to propose that library authors be permitted to select their own build/test system. Testing of Boost would be just the union of the testing of all the individual libraries. Here are a few observations regarding CMake as it might relate to Boost. a) In the CMake section of the incubator page, I've advocated creating a library subdirectory named CMake which includes the cake scripts. The source files or not in this directory. The scripts contain relative path names to source files in the directory. This permits the CMake scripts to not be sprinkled all over the directory structure but rather in one place. I've used this and found it to work very well. b) I would like to see testing of boost libraries distributed to library users/testers and others, and have their test results posted on a library dashboard. This would provide a number of advantages. So I would like to be able to recommend CTest/CDash. I have made this setup work - but it doesn't "just work". I would like to see: The CTest/CDash system has a sort of elaborate setup of experimental, nightly, etc. which ties certain test names to different test frequencies. This is too complex. Basically all we need is "experimental" which I would more likely call "on demand". This is what users need. Download a library, build it, run test suite and post results. It's great that you guys run the public dashboard and I would like to encourage boost libraries developers to use it. I would like to see a few cosmetic changes but the idea is close to what I would like to see for Boost. I did meet a couple of you at CPPCon last september. If any of you expect go to C++Now please contact me with any information and/or advice you think might be useful to me. Robert Ramey -- View this message in context: http://cmake.3232098.n2.nabble.com/C-Now-BoostCon-Boost-2-0-tp7590405.html Sent from the CMake mailing list archive at Nabble.com. From irwin at beluga.phys.uvic.ca Tue Apr 28 14:27:52 2015 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Tue, 28 Apr 2015 11:27:52 -0700 (PDT) Subject: [CMake] What is the proper way to export targets that will be split into separate binary packages? In-Reply-To: <553F5974.6040908@gmail.com> References: <553F2F1A.2080505@gmail.com> <553F5974.6040908@gmail.com> Message-ID: On 2015-04-28 11:57+0200 Nils Gladitz wrote: > On 04/28/2015 11:43 AM, Alan W. Irwin wrote: >> @Nils: the origin of the code right below "If COMPONENTS..." is not >> clear. Is that code that should be supplied by a package creator or >> code that >> should be implemented by every find_package user? And if it should be >> supplied by a package creator, does the install(EXPORT...) signature >> generate that code automatically, does one of the helper functions >> that are available generate that code, or do I (as package creator) >> have to supply that code some other way? > > The package configuration file is normally handwritten (or handgenerated) by > the package creator. I assume you already have one? e.g. plplotConfig.cmake. Yes, I did implement such a file a while back to bring the previous crude export stuff (implemented years ago before the idea of cmake packages were even thought of) into compliance with the idea of cmake packages. However, now that you have reminded me of that file, it turns out it is only slightly more than a placeholder. So clearly some work is required to fully modernize this part of the PLplot build system. > > >>> http://www.cmake.org/cmake/help/v3.2/manual/cmake-packages.7.html#creating-packages >>> >> >> @Alex: Sorry I missed your reply until now. >> >> @Alex or Nils: >> >> The problem with the URL provided by Nils is only one library is used >> in the example so I don't understand exactly what you guys are >> suggesting for the multiple library/component case. >> >> For example, are you recommending >> >> install(TARGETS plplot1 EXPORT export_plplot ...) >> [...] >> install(TARGETS plplotN EXPORT export_plplot ...) >> >> for N installed libraries followed by >> >> install(EXPORT export_plplot DESTINATION ${LIB_DIR}/cmake/plplot) >> >> ? That is the current pattern I am using with one overall export name >> called "export_plplot". Or would you recommend this different pattern >> >> install(TARGETS plplot1 EXPORT export_plplot1 ...) >> install(EXPORT export_plplot1 DESTINATION ${LIB_DIR}/cmake/plplot) >> [...] >> install(TARGETS plplotN EXPORT export_plplotN ...) >> install(EXPORT export_plplotN DESTINATION ${LIB_DIR}/cmake/plplot) >> >> (i.e., N pairs of install(TARGETS...) install(EXPORT...) signatures >> with each pair having a unique export name)? > > Yes, unique/distinct export names and export files. > > That way the target export files can go into the respective distribution > package that they represent. > > The "umbrella" package configuration file would be installed by your "core" > package and would then be able to pick up the currently available target > export files. Thanks for that clarification. You referred in a later post to the granularity required. To give you some idea of the scope of the problem, there are currently ~30 PLplot targets which are EXPORTed. I obviously do not want to set up 30 different package components to correspond to those individual targets since that implies maintenance issues (for users to keep track of all those possible components). On the other hand, the current granularity requirements of the Linux packagers vary quite a lot between distros (e.g., Debian packagers tend to split PLplot binary packages differently than Fedora packagers) probably because upstream PLplot has not given them any splitting guidance until now. So I will have to think carefully about what component granularity we should supply. Anyhow, you have given me lots of food for thought here, and I appreciate that! Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From orion at cora.nwra.com Tue Apr 28 16:15:36 2015 From: orion at cora.nwra.com (Orion Poplawski) Date: Tue, 28 Apr 2015 14:15:36 -0600 Subject: [CMake] How to specify compiler only flags Message-ID: <553FEA68.1020504@cora.nwra.com> I'm trying to patch the CMakeLists.txt for openjpeg. Currently it does: # Do not use ffast-math for all build, it would produce incorrect results, only set for release: SET(CMAKE_C_FLAGS_RELEASE "-ffast-math ${CMAKE_C_FLAGS_RELEASE}") Unfortunately, CMAKE_C_FLAGS are also used in link step, which for -ffast-math causes problems for users of the shared library. I'm unable to find an equivalent flag that is for compiling only. I see I can set the COMPILE_FLAGS property for the library, but there does not appear to be a COMPILE_FLAGS_RELEASE property that would only set it for the Release build type. Suggestions? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com From dschepler at scalable-networks.com Tue Apr 28 16:22:51 2015 From: dschepler at scalable-networks.com (Daniel Schepler) Date: Tue, 28 Apr 2015 20:22:51 +0000 Subject: [CMake] How to specify compiler only flags In-Reply-To: <553FEA68.1020504@cora.nwra.com> References: <553FEA68.1020504@cora.nwra.com> Message-ID: As I understand it, configuration-specific properties are deprecated in favor of generator expressions. For example: target_compile_options(openjpeg PRIVATE $<$:-ffast-math>) -- Daniel Schepler ________________________________________ From: CMake [cmake-bounces at cmake.org] on behalf of Orion Poplawski [orion at cora.nwra.com] Sent: Tuesday, April 28, 2015 1:15 PM To: CMake Mailing List Subject: [CMake] How to specify compiler only flags I'm trying to patch the CMakeLists.txt for openjpeg. Currently it does: # Do not use ffast-math for all build, it would produce incorrect results, only set for release: SET(CMAKE_C_FLAGS_RELEASE "-ffast-math ${CMAKE_C_FLAGS_RELEASE}") Unfortunately, CMAKE_C_FLAGS are also used in link step, which for -ffast-math causes problems for users of the shared library. I'm unable to find an equivalent flag that is for compiling only. I see I can set the COMPILE_FLAGS property for the library, but there does not appear to be a COMPILE_FLAGS_RELEASE property that would only set it for the Release build type. Suggestions? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake From orion at cora.nwra.com Tue Apr 28 17:59:25 2015 From: orion at cora.nwra.com (Orion Poplawski) Date: Tue, 28 Apr 2015 15:59:25 -0600 Subject: [CMake] How to specify compiler only flags In-Reply-To: References: <553FEA68.1020504@cora.nwra.com> Message-ID: <554002BD.6060400@cora.nwra.com> On 04/28/2015 02:22 PM, Daniel Schepler wrote: > As I understand it, configuration-specific properties are deprecated in favor of generator expressions. For example: > > target_compile_options(openjpeg PRIVATE > $<$:-ffast-math>) > Thanks, that helps. Perhaps not as simple as a global variable, but perhaps cleaner then too. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com From Marek.Vojtko at firaxis.com Tue Apr 28 19:25:04 2015 From: Marek.Vojtko at firaxis.com (Marek Vojtko (Firaxis)) Date: Tue, 28 Apr 2015 23:25:04 +0000 Subject: [CMake] Apple Metal Support in Xcode? Message-ID: Hi, I'm trying to get Apple's new shading language, Metal, to work with my CMake project, but I am not having any luck. Xcode will automagically compile .metal files that are part of the project, but their Type (in the File Inspector in the right-hand Utilities pane) has to be set to "Default - Metal Shader Source File." When I add .metal files via CMake they are a) not listed in the project's Compile Sources list (in the Target's Build Phases tab), and b) their Type is set to "Source File". A) can be solved by adding source file properties (e.g. compile flags) to the .metal file in CMake, but I haven't been able to change the Type of the .metal files through CMake. I have seen a commit log [0] about "Add[ing] file type for Metal shader files," but that change doesn't seem to have made it to the released CMake version yet. My questions: 1) Is there anything I can do right now (with CMake 3.2.2.) that would make Xcode handle .metal files correctly? 2) Are there plans to support .metal files via CMake and if so, how far along are they? Thanks, [0] http://www.cmake.org/pipermail/cmake-commits/2015-April/022952.html -- Marek Vojtko mail: marek.vojtko at firaxis.com phone: (+1) 410-229-2519 From gjasny at googlemail.com Wed Apr 29 03:49:55 2015 From: gjasny at googlemail.com (Gregor Jasny) Date: Wed, 29 Apr 2015 09:49:55 +0200 Subject: [CMake] Apple Metal Support in Xcode? In-Reply-To: References: Message-ID: <55408D23.4070703@googlemail.com> Hello, On 29/04/15 01:25, Marek Vojtko (Firaxis) wrote: > My questions: > 1) Is there anything I can do right now (with CMake 3.2.2.) that would make Xcode handle .metal files correctly? > 2) Are there plans to support .metal files via CMake and if so, how far along are they? Does the XCODE_EXPLICIT_FILE_TYPE attribute help you? http://www.cmake.org/cmake/help/v3.2/prop_sf/XCODE_EXPLICIT_FILE_TYPE.html Maybe you could create a minimal example project and file a wishlist bug? Thanks, Gregor From forderud at gmail.com Wed Apr 29 05:15:04 2015 From: forderud at gmail.com (Fredrik Orderud) Date: Wed, 29 Apr 2015 11:15:04 +0200 Subject: [CMake] Request for NuGet support Message-ID: NuGet have recently emerged as a "de facto" standard for managing 3rd party dependencies when building C++ applications with Visual Studio on Windows. NuGet is nicely integrated into Visual Studio, downloads & unpacks dependencies automatically, and configures include, lib & binary paths to streamline the build process. It would be great if CMake could add some form of minimal support for NuGet when generating Visual Studio project files, so that CMake can be used together with existing NuGet infrastructure on Windows. I think it would be sufficient to add a mechanism for specifying NuGet dependencies with version numbers. Example: set(NUGET_DEPS "boost/1.57 zlib/1.2.8"). CMake can then incorporate this information when generating Visual Studio project files. This typically involves adding a few XML tags in the vcxproj-file, as well as adding a "packages.config" file together with the project. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ewmailing at gmail.com Wed Apr 29 05:22:45 2015 From: ewmailing at gmail.com (Eric Wing) Date: Wed, 29 Apr 2015 02:22:45 -0700 Subject: [CMake] cmake iOS application + framework link error In-Reply-To: References: Message-ID: On 4/25/15, David Hirvonen wrote: > I'm hitting a link error when linking an iOS application with an internally > created framework/library using the the CMake Xcode generator and an iOS > toolchain. I've put together a minimal CMakeLists.txt example here: > > https://github.com/headupinclouds/cmake_framework_test/ > > The problem is described in detail in the the README, and reproduced here > in the email for completeness. > > The repository is intended as a simple unit test to illustrate an apparent > link and build location mismatch when linking a framework to an iOS > application using the "standard" iOS toolchain > (I realize this toolchain isn't > provided with CMake). I've included the ios toolchain in this repository to > make it easy to reproduce the issue. I've include both the iOS application > that reproduces the link error, and an OS X application, which links to the > library in correct framework location. I'm looking for a CMakeLists.txt fix > or possible workaround. There are two top level convenience bash scripts > for building the applications with cmake using an xcode generator. The > CMake version is 3.2.1. > > cmake --version > cmake version 3.2.1 > > iOS > framework and application error: > > bash -fx ./test-ios.sh > + NAME=_builds/ios > + cmake -GXcode -H. -B_builds/ios -DCMAKE_TOOLCHAIN_FILE=iOS.cmake > > > clang: error: no such file or directory: > '/Users/dhirvonen/devel/cmake_framework_test/_builds/ios/Debug-iphoneos/TF.framework/Versions/A/TF' > ** BUILD FAILED ** > The following build commands failed: > Ld _builds/ios/Debug-iphoneos/testa.app/testa normal armv7 > (1 failure) > library path: _builds/ios/Debug-iphoneos/TF.framework/TF > > This produces a flat framework layout (ignoring the FRAMEWORK_VERSION > property (which is fine with me if I can get it to work)). It looks like > this: > > tree _builds/ios/Debug-iphoneos/TF.framework > _builds/ios/Debug-iphoneos/TF.framework > ??? Info.plist > ??? TF > ??? _CodeSignature > ??? CodeResources > > But when it reaches the link command for the ios application: > > target_link_libraries(testa TF) > > it fails, since it seems to expect the library to be two directories down > within a versioned framework layout: > > TF.framework/Versions/A/TF > > instead the directory is here: > > TF.framework/TF > > I'm looking for a solution to either: > > - correct the TF link path to use the actual (non versioned) framework > layout that is currently generated, or > - correct the framework so that it uses the versioned layout to make > that consistent with the link path > > OS > X framework and application success: > > When I build this for OS X it seems to work fine. > > bash -fx ./test-osx.sh > + NAME=_builds/osx > + cmake -GXcode -H. -B_builds/osx > > ** BUILD SUCCEEDED ** > library path: _builds/osx/Debug/TF.framework/Versions/A/TF > > This produces a framework with the following layout: > > tree _builds/osx/Debug/ > _builds/osx/Debug/ > ??? TF.framework > ? ??? Resources -> Versions/Current/Resources > ? ??? TF -> Versions/Current/TF > ? ??? Versions > ? ??? A > ? ? ??? Resources > ? ? ? ??? Info.plist > ? ? ??? TF > ? ? ??? _CodeSignature > ? ? ??? CodeResources > ? ??? Current -> A > ??? testb > > and the call to > > target_link_libraries(testb TF) > > picks up the TF library in the correct location. > > I'm curious if there is a variable or property that needs to be set for the > iOS example to give the same framework layout. > I have not tried this (yet), but my guess is that CMake needs to be patched to understand iOS frameworks. iOS frameworks are new as of iOS 8. 3rd parties were not allowed to make frameworks before that. Additionally, CMake's framework support was implemented for Mac like a decade ago. Because the iOS framework structure (and .app structure for another matter) is different, CMake will likely need to be taught how to make a proper structure for iOS. If you do any work on this, I am interested in your results. Eventually, I would like to support iOS frameworks, though I'm probably at least 6 months from that since I need iOS 7 to drop off the face of the earth, which means after iOS 9 is released. (Note to non-iOS developers reading this: iOS does not allow flat .dylib files for shared libraries. You must build a framework.) -Eric -- Beginning iPhone Games Development http://playcontrol.net/iphonegamebook/ From plucinski.mariusz at gmail.com Wed Apr 29 06:41:48 2015 From: plucinski.mariusz at gmail.com (=?UTF-8?Q?Mariusz_Pluci=C5=84ski?=) Date: Wed, 29 Apr 2015 12:41:48 +0200 Subject: [CMake] CMake itself - build fails with GCC 5.1 Message-ID: I have recently built newest GCC - 5.1.0 - on CentOS 7. Now, I am trying to build CMake with it. Unfortunately, it stops on "./configure" step with following message: In file included from /root/cmake-3.2.2/Source/kwsys/SystemTools.cxx:36:0: /root/cmake-3.2.2/Bootstrap.cmk/cmsys/ios/sstream: In member function ?void cmsys_ios::istringstream::clear(int)?: /root/cmake-3.2.2/Bootstrap.cmk/cmsys/ios/sstream:176:34: error: invalid conversion from ?int? to ?std::ios_base::iostate {aka std::_Ios_Iostate}? [-fpermissive] this->IStrStream::clear(flags); ^ Am I doing something wrong, or CMake is not yet adjusted to latest GCC? -- Best Regards Mariusz Plucinski -------------- next part -------------- An HTML attachment was scrubbed... URL: From plucinski.mariusz at gmail.com Wed Apr 29 08:14:17 2015 From: plucinski.mariusz at gmail.com (=?UTF-8?Q?Mariusz_Pluci=C5=84ski?=) Date: Wed, 29 Apr 2015 14:14:17 +0200 Subject: [CMake] CMake itself - build fails with GCC 5.1 In-Reply-To: References: Message-ID: Ok, I have found out what is the issue. In case anyone meets this issue, here is explanation: cmsys/ios/sstream has own implementation of sstream, which is used when normal one could not be found (or is known as buggy). So it should not be even used in my build. Eventually, it shows up that the problem was with the test that is done during bootstrap to decide if valid sstream is available. However, in my case test has failed not because sstream was not there, but because there was general issue with libstdc++ - it tried to run compiled code with one builtin into system, instead of new one compiled together with GCC. Replacing old libstdc++ with a new one, and restarting CMake build from scratch fixed the issue. Sorry for spamming the list :) 2015-04-29 12:41 GMT+02:00 Mariusz Pluci?ski : > I have recently built newest GCC - 5.1.0 - on CentOS 7. Now, I am trying > to build CMake with it. Unfortunately, it stops on "./configure" step with > following message: > > In file included from /root/cmake-3.2.2/Source/kwsys/SystemTools.cxx:36:0: > /root/cmake-3.2.2/Bootstrap.cmk/cmsys/ios/sstream: In member function > ?void cmsys_ios::istringstream::clear(int)?: > /root/cmake-3.2.2/Bootstrap.cmk/cmsys/ios/sstream:176:34: error: invalid > conversion from ?int? to ?std::ios_base::iostate {aka std::_Ios_Iostate}? > [-fpermissive] > this->IStrStream::clear(flags); > ^ > > Am I doing something wrong, or CMake is not yet adjusted to latest GCC? > > -- > Best Regards > Mariusz Plucinski > -- Best Regards Mariusz Plucinski -------------- next part -------------- An HTML attachment was scrubbed... URL: From mpercossi at zenaud.io Wed Apr 29 11:24:30 2015 From: mpercossi at zenaud.io (Martin Percossi) Date: Wed, 29 Apr 2015 17:24:30 +0200 Subject: [CMake] Automatic compilation of .xib's for _macosx_ target Message-ID: Hello, I came across the following link: http://stackoverflow.com.80bola.com/questions/7462129/cmake-xib-to-nib-compilation-for-ios-target?s=1|0.8637 Described is how to set up a CMakeLists.txt in order to have .xib files automatically compiled to .nib files and placed in the Resources folder within the app bundle for iOS targets. Nice and simple. Unfortunately, I've tried grafting the relevant parts onto a project that targets Mac OSX, and while the .xib is copied to the Resources directory, it is not compiled. Do I need to do it manually, as pointed out elsewhere, if I target OSX? By the way, I've attached my version of the CMakeLists.txt file. Note that if I invoke: cmake -GXcode .. from a "build" subdirectory, a foo.xcodeproj file is created, as expected, which "does the right thing". My problem is that I'd like to elide Xcode and build from the command line. (I'm aware of xcodebuild but I'm curious if I can do it just using make, because I'd like to build in Clion.) Many thanks in advance, Martin Percossi -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- cmake_minimum_required(VERSION 2.8.8) project(foo) set(CMAKE_OSX_SYSROOT /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk) set(CMAKE_OSX_ARCHITECTURES "i386;x86_64") set(CMAKE_XCODE_EFFECTIVE_PLATFORMS "macosx") set(CMAKE_OSX_DEPLOYMENT_TARGET 10.10) set(RESOURCES MainMenu.xib) add_executable( foo MACOSX_BUNDLE AppDelegate.h AppDelegate.mm main.mm ${RESOURCES} ) set_target_properties(foo PROPERTIES MACOSX_BUNDLE_INFO_PLIST ${CMAKE_CURRENT_LIST_DIR}/plist.in RESOURCE "${RESOURCES}" ) set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -framework AppKit") From max.savenkov at gmail.com Wed Apr 29 12:00:54 2015 From: max.savenkov at gmail.com (Max Savenkov) Date: Wed, 29 Apr 2015 19:00:54 +0300 Subject: [CMake] Tegra NSight shared libraries not copied into apk Message-ID: When I specify a shared library via target_link_libraries, it gets added to Linker options and is linked. But when the final APK is assembled, specified shared library does not get copied into it (into lib\armeabi-v7a directory), and therefore I get an error after launch, because loadLibrary cannot find it. To mark a shared library file to be copied into APK, it should be specified in Ant Build -> Additional Dependendies -> Native Library Dependencies. As far as I can see, the current implementation of generator has no way of doing it. Could such an option to be added? It would probably be right just to add all .so files added with target_link_libraries to this property (and their directories into Native Library Directories). Or am I missing something? Is there any way to solve this in other way? From dschepler at scalable-networks.com Wed Apr 29 14:20:50 2015 From: dschepler at scalable-networks.com (Daniel Schepler) Date: Wed, 29 Apr 2015 18:20:50 +0000 Subject: [CMake] Issues with adding -flto in CMAKE_C[XX]_FLAGS_RELEASE Message-ID: I just tried an experiment on our code base, adding -flto to the default values of CMAKE_C_FLAGS_RELEASE and CMAKE_CXX_FLAGS_RELEASE, and setting CMAKE_AR to /usr/bin/gcc-ar-5, CMAKE_RANLIB to /usr/bin/gcc-ranlib-5. However, make VERBOSE=1 shows that the intermediate static libraries are still being created using /usr/bin/ar; and I can't find any other instances of /usr/bin/ar in CMakeCache.txt. That results in lots of BFD warnings showing up, and linker errors at the end. Is there something I'm missing that would make this able to work; or is this configuration not supported (yet)? -- Daniel Schepler -------------- next part -------------- An HTML attachment was scrubbed... URL: From mateusz at loskot.net Wed Apr 29 16:04:20 2015 From: mateusz at loskot.net (Mateusz Loskot) Date: Wed, 29 Apr 2015 22:04:20 +0200 Subject: [CMake] Detecting -m32 build target on 64-bit host In-Reply-To: <553A92C6.6040602@googlemail.com> References: <553A92C6.6040602@googlemail.com> Message-ID: On 24 April 2015 at 21:00, Gregor Jasny wrote: > On 23/04/15 16:54, Mateusz Loskot wrote: >> Surprisingly, I'm having trouble to figure out how to determine, >> that in Linux 64-bit OS, I'm building a project with -m32 specified. >> IOW, any CMake variable or macro to tell me target architecture >> of a build that is being configured is 32 or 64 bit? > > Does this help? > > include(CheckSymbolExists) > > if(WIN32) > check_symbol_exists("_M_AMD64" "" RTC_ARCH_X64) > if(NOT RTC_ARCH_X64) > check_symbol_exists("_M_IX86" "" RTC_ARCH_X86) > endif(NOT RTC_ARCH_X64) > # add check for arm here > # see http://msdn.microsoft.com/en-us/library/b0084kay.aspx > else(WIN32) > check_symbol_exists("__i386__" "" RTC_ARCH_X86) > check_symbol_exists("__x86_64__" "" RTC_ARCH_X64) > check_symbol_exists("__arm__" "" RTC_ARCH_ARM) > endif(WIN32) Gregor, yes, indeed. Thanks! -- Mateusz Loskot, http://mateusz.loskot.net From mateusz at loskot.net Wed Apr 29 16:50:50 2015 From: mateusz at loskot.net (Mateusz Loskot) Date: Wed, 29 Apr 2015 22:50:50 +0200 Subject: [CMake] CXXFLAGS and CMAKE_REQUIRED_FLAGS correspondance Message-ID: Hi, Let's consider 32-bit build target on 64-bit host, is this canonical way of setting the flags? CXXFLAGS="-m32" cmake ../src # in my CMakeLists.txt CMAKE_REQUIRED_FLAGS=${CXXFLAGS} If I don't set CMAKE_REQUIRED_FLAGS with -m32, then obviously CheckSymbolExists (and others) may give unexpected results. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net From graham.bloice at trihedral.com Wed Apr 29 17:27:29 2015 From: graham.bloice at trihedral.com (Graham Bloice) Date: Wed, 29 Apr 2015 22:27:29 +0100 Subject: [CMake] CheckTypeSize policy warning Message-ID: In CMake 3.1.3 and later invoking check_type_size from the module CheckTypeSize.cmake causes a policy CMP0054 warning. For example, when building zlib-1.28 (on Windows): CMake Warning (dev) at C:/ProgramData/chocolatey/lib/cmake/content/cmake-3.1.3-win32-x86/share/cmake-3.1/Modules/CheckTypeSize.cmake:232 (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 "C" 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): E:/Wireshark/wireshark-win32-libs/zlib-1.2.8/CMakeLists.txt:43 (check_type_size) As the function has a cmake_policy_push(), followed by a cmake_policy(VERSION 3.0) at the start we can't pass down a policy setting. I can fix this locally by changing the policy set to 3.1 There might be other similarly afflicted modules. I looked but couldn't see anything on the bug tracker, shall I raise an issue? -- Graham Bloice -------------- next part -------------- An HTML attachment was scrubbed... URL: From pelegs at gmail.com Wed Apr 29 17:56:41 2015 From: pelegs at gmail.com (Peleg Bar-Sapir) Date: Wed, 29 Apr 2015 23:56:41 +0200 Subject: [CMake] Linking to MySQL C++ Connector libraries using extra flags, Ubuntu 14.04 LTS, gcc Message-ID: Hello, First, I would like to point out that I'm new to CMake, and I'm not a professional programer by any means - just a Physics research student. I looked for answers to my issue online, but couldn't find anything that helped me. I also asked my peers and friends, but unfortunately none of them could find an answer as well. I want to use MySQL connector for C++ in a program. Usually I do this by using the 'mysql' and 'my_global' libraries, and then run gcc with this added flag: `mysql_config --cflags --libs`. Typing this command into my console results in: $mysql_config --cflags --libs -I/usr/include/mysql -DBIG_JOINS=1 -fno-strict-aliasing -g -DNDEBUG -L/usr/lib/x86_64-linux-gnu -lmysqlclient -lpthread -lz -lm -ldl meaning there are some linking flags that must be given so gcc would compile my code, apart from just "-lmysql" or "-l/usr/include/mysql". My question is how do I ensure this works also with CMake? I understand how to use the CMakeLists.txt file to configure additional external libraries, but none of them require special flags as above, at least in my basic use of them. Since there's no module for MySQL connector, I'm a bit lost here. Could anyone please give me a some advices, or point me to what should be done? Thanks, Peleg Bar Sapir From dschepler at scalable-networks.com Wed Apr 29 18:52:16 2015 From: dschepler at scalable-networks.com (Daniel Schepler) Date: Wed, 29 Apr 2015 22:52:16 +0000 Subject: [CMake] Linking to MySQL C++ Connector libraries using extra flags, Ubuntu 14.04 LTS, gcc In-Reply-To: References: Message-ID: I'd say that most of the output of mysql_config --cflags and mysql_config --libs is a bug - for the shared library, there's no need to explicitly include the pthread etc. libraries (unless, of course, your program also uses them directly). In CMake terms, they should have been PRIVATE dependencies of the shared library, rather than PUBLIC. (I don't seem to have been able to convince the MariaDB Connector/C developers of that, though...) I'm attaching a file I wrote for our project to enable: find_package(MariaDB REQUIRED) include_directories(${MARIADB_INCLUDE_DIR}) target_link_libraries(mainexe ${MARIADB_LIBRARY}) -- Daniel Schepler ________________________________________ From: CMake [cmake-bounces at cmake.org] on behalf of Peleg Bar-Sapir [pelegs at gmail.com] Sent: Wednesday, April 29, 2015 2:56 PM To: cmake at cmake.org Subject: [CMake] Linking to MySQL C++ Connector libraries using extra flags, Ubuntu 14.04 LTS, gcc Hello, First, I would like to point out that I'm new to CMake, and I'm not a professional programer by any means - just a Physics research student. I looked for answers to my issue online, but couldn't find anything that helped me. I also asked my peers and friends, but unfortunately none of them could find an answer as well. I want to use MySQL connector for C++ in a program. Usually I do this by using the 'mysql' and 'my_global' libraries, and then run gcc with this added flag: `mysql_config --cflags --libs`. Typing this command into my console results in: $mysql_config --cflags --libs -I/usr/include/mysql -DBIG_JOINS=1 -fno-strict-aliasing -g -DNDEBUG -L/usr/lib/x86_64-linux-gnu -lmysqlclient -lpthread -lz -lm -ldl meaning there are some linking flags that must be given so gcc would compile my code, apart from just "-lmysql" or "-l/usr/include/mysql". My question is how do I ensure this works also with CMake? I understand how to use the CMakeLists.txt file to configure additional external libraries, but none of them require special flags as above, at least in my basic use of them. Since there's no module for MySQL connector, I'm a bit lost here. Could anyone please give me a some advices, or point me to what should be done? Thanks, Peleg Bar Sapir -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware 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 -------------- A non-text attachment was scrubbed... Name: FindMariaDB.cmake Type: text/x-cmake Size: 1434 bytes Desc: FindMariaDB.cmake URL: From irwin at beluga.phys.uvic.ca Wed Apr 29 19:18:24 2015 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Wed, 29 Apr 2015 16:18:24 -0700 (PDT) Subject: [CMake] How to work around permission deficiencies of file(GENERATE...)? (was cmp0026, file(GENERATE...), and configure_file) In-Reply-To: References: Message-ID: While attempting to use the configure_file_generate function discussed in a recent thread here, I discovered a permission deficiency of the file(GENERATE ...) command which was that permissions are not copied from input file to output file like they are with configure_file. @CMake developers: was this treatment of permissions by design or is this a bug in the implementation of the file(GENERATE...) command that you are willing to fix? Here is my initial (non-working) attempt to work around this issue in my configure_file_generate function. [...] # Configure generator expressions. # N.B. these ${output_file} results will only be available # at generate time. file(GENERATE OUTPUT ${output_file} INPUT ${intermediate_file} ) if(UNIX OR MSYS) # This covers all platforms which have permissions, # i.e., Unix, Cygwin, and MSYS platforms. # Work around bad permission semantics of file(GENERATE...) which # does not copy permissions from input file. Note this --reference # syntax is probably a non-posix extension of the GNU version of chmod. # So this will silently fail to change permissions # on platforms without access to the GNU version of chmod. execute_process( COMMAND chmod --reference=${intermediate_file} ${output_file} ) endif(UNIX OR MSYS) Obviously this workaround does not currently work since execute_process occurs at configure time rather than generate time as can be seen from these results: software at raven> ls -l examples/tk/tk01* -rw-r--r-- 1 software software 3692 Apr 29 15:45 examples/tk/tk01 -rwxr-xr-x 1 software software 3658 Apr 29 15:45 examples/tk/tk01_cf_only* where the first file (with bad permissions) is the ${output_file} and the second file the ${intermediate_file} used in the configure_file_generate function. Is there any method I can use at generate time to change permissions on the OUTPUT file generated by file(GENERATE...), e.g., is there any way I can force execute_process to work at generate time? Of course, I could fix permissions at build time, but that is a big maintenance issue trying to keep track of every file processed by configure_file_generate so I would far prefer to change the permissions at generate time within the configure_file_generate function. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From pelegs at gmail.com Wed Apr 29 19:46:24 2015 From: pelegs at gmail.com (Peleg Bar-Sapir) Date: Thu, 30 Apr 2015 01:46:24 +0200 Subject: [CMake] Linking to MySQL C++ Connector libraries using extra flags, Ubuntu 14.04 LTS, gcc In-Reply-To: References: Message-ID: Hello Daniel, Thanks for your help. I took your file and plagiarized it, replacing "MariaDB"/MARIADB"/"mariadb" with "MySQL"/"MYSQL"/"mysql" accordinly - and did the same for the CMakeLists.txt (I put FindMySQL.cmake in /CMake/Modules). Running 'cmake .' now gives no error, but running make gives me still the linking error: $ make [100%] Building CXX object CMakeFiles/entity_find_visual.dir/entity_find_visual.cpp.o /home/[...]/find_visual/entity_find_visual.cpp:17:19: fatal error: mysql.h: No such file or directory #include ^ compilation terminated. make[2]: *** [CMakeFiles/entity_find_visual.dir/entity_find_visual.cpp.o] Error 1 make[1]: *** [CMakeFiles/entity_find_visual.dir/all] Error 2 make: *** [all] Error 2 This is almost exactly what happens when I run a Makefile without the flag: $make foo g++ foo.cpp foolib.cpp -o foo `pkg-config --cflags --libs gsl` -std=c++11 In file included from foo.cpp:5:0: foolib.h:16:23: fatal error: my_global.h: No such file or directory #include ^ compilation terminated. Am I missing something? Peleg On Thu, Apr 30, 2015 at 12:52 AM, Daniel Schepler wrote: > I'd say that most of the output of mysql_config --cflags and mysql_config --libs is a bug - for the shared library, there's no need to explicitly include the pthread etc. libraries (unless, of course, your program also uses them directly). In CMake terms, they should have been PRIVATE dependencies of the shared library, rather than PUBLIC. (I don't seem to have been able to convince the MariaDB Connector/C developers of that, though...) > > I'm attaching a file I wrote for our project to enable: > find_package(MariaDB REQUIRED) > include_directories(${MARIADB_INCLUDE_DIR}) > target_link_libraries(mainexe ${MARIADB_LIBRARY}) > -- > Daniel Schepler > ________________________________________ > From: CMake [cmake-bounces at cmake.org] on behalf of Peleg Bar-Sapir [pelegs at gmail.com] > Sent: Wednesday, April 29, 2015 2:56 PM > To: cmake at cmake.org > Subject: [CMake] Linking to MySQL C++ Connector libraries using extra flags, Ubuntu 14.04 LTS, gcc > > Hello, > > First, I would like to point out that I'm new to CMake, and I'm not a > professional programer by any means - just a Physics research student. > I looked for answers to my issue online, but couldn't find anything > that helped me. I also asked my peers and friends, but unfortunately > none of them could find an answer as well. > > I want to use MySQL connector for C++ in a program. Usually I do this > by using the 'mysql' and 'my_global' libraries, and then run gcc with > this added flag: `mysql_config --cflags --libs`. > Typing this command into my console results in: > > $mysql_config --cflags --libs > -I/usr/include/mysql -DBIG_JOINS=1 -fno-strict-aliasing -g -DNDEBUG > -L/usr/lib/x86_64-linux-gnu -lmysqlclient -lpthread -lz -lm -ldl > > meaning there are some linking flags that must be given so gcc would > compile my code, apart from just "-lmysql" or "-l/usr/include/mysql". > > My question is how do I ensure this works also with CMake? I > understand how to use the CMakeLists.txt file to configure additional > external libraries, but none of them require special flags as above, > at least in my basic use of them. Since there's no module for MySQL > connector, I'm a bit lost here. > > Could anyone please give me a some advices, or point me to what should be done? > > > Thanks, > > Peleg Bar Sapir > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 dschepler at scalable-networks.com Wed Apr 29 19:50:12 2015 From: dschepler at scalable-networks.com (Daniel Schepler) Date: Wed, 29 Apr 2015 23:50:12 +0000 Subject: [CMake] Linking to MySQL C++ Connector libraries using extra flags, Ubuntu 14.04 LTS, gcc In-Reply-To: References: , Message-ID: I'd put debugging statements in to see what is being returned as MYSQL_INCLUDE_DIR and MYSQL_LIBRARY; and if those look correct, I'd run "make VERBOSE=1" to check exactly what's on the compilation command line. -- Daniel ________________________________________ From: Peleg Bar-Sapir [pelegs at gmail.com] Sent: Wednesday, April 29, 2015 4:46 PM To: Daniel Schepler Cc: cmake at cmake.org Subject: Re: [CMake] Linking to MySQL C++ Connector libraries using extra flags, Ubuntu 14.04 LTS, gcc Hello Daniel, Thanks for your help. I took your file and plagiarized it, replacing "MariaDB"/MARIADB"/"mariadb" with "MySQL"/"MYSQL"/"mysql" accordinly - and did the same for the CMakeLists.txt (I put FindMySQL.cmake in /CMake/Modules). Running 'cmake .' now gives no error, but running make gives me still the linking error: $ make [100%] Building CXX object CMakeFiles/entity_find_visual.dir/entity_find_visual.cpp.o /home/[...]/find_visual/entity_find_visual.cpp:17:19: fatal error: mysql.h: No such file or directory #include ^ compilation terminated. make[2]: *** [CMakeFiles/entity_find_visual.dir/entity_find_visual.cpp.o] Error 1 make[1]: *** [CMakeFiles/entity_find_visual.dir/all] Error 2 make: *** [all] Error 2 This is almost exactly what happens when I run a Makefile without the flag: $make foo g++ foo.cpp foolib.cpp -o foo `pkg-config --cflags --libs gsl` -std=c++11 In file included from foo.cpp:5:0: foolib.h:16:23: fatal error: my_global.h: No such file or directory #include ^ compilation terminated. Am I missing something? Peleg On Thu, Apr 30, 2015 at 12:52 AM, Daniel Schepler wrote: > I'd say that most of the output of mysql_config --cflags and mysql_config --libs is a bug - for the shared library, there's no need to explicitly include the pthread etc. libraries (unless, of course, your program also uses them directly). In CMake terms, they should have been PRIVATE dependencies of the shared library, rather than PUBLIC. (I don't seem to have been able to convince the MariaDB Connector/C developers of that, though...) > > I'm attaching a file I wrote for our project to enable: > find_package(MariaDB REQUIRED) > include_directories(${MARIADB_INCLUDE_DIR}) > target_link_libraries(mainexe ${MARIADB_LIBRARY}) > -- > Daniel Schepler > ________________________________________ > From: CMake [cmake-bounces at cmake.org] on behalf of Peleg Bar-Sapir [pelegs at gmail.com] > Sent: Wednesday, April 29, 2015 2:56 PM > To: cmake at cmake.org > Subject: [CMake] Linking to MySQL C++ Connector libraries using extra flags, Ubuntu 14.04 LTS, gcc > > Hello, > > First, I would like to point out that I'm new to CMake, and I'm not a > professional programer by any means - just a Physics research student. > I looked for answers to my issue online, but couldn't find anything > that helped me. I also asked my peers and friends, but unfortunately > none of them could find an answer as well. > > I want to use MySQL connector for C++ in a program. Usually I do this > by using the 'mysql' and 'my_global' libraries, and then run gcc with > this added flag: `mysql_config --cflags --libs`. > Typing this command into my console results in: > > $mysql_config --cflags --libs > -I/usr/include/mysql -DBIG_JOINS=1 -fno-strict-aliasing -g -DNDEBUG > -L/usr/lib/x86_64-linux-gnu -lmysqlclient -lpthread -lz -lm -ldl > > meaning there are some linking flags that must be given so gcc would > compile my code, apart from just "-lmysql" or "-l/usr/include/mysql". > > My question is how do I ensure this works also with CMake? I > understand how to use the CMakeLists.txt file to configure additional > external libraries, but none of them require special flags as above, > at least in my basic use of them. Since there's no module for MySQL > connector, I'm a bit lost here. > > Could anyone please give me a some advices, or point me to what should be done? > > > Thanks, > > Peleg Bar Sapir > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 dschepler at scalable-networks.com Wed Apr 29 19:52:36 2015 From: dschepler at scalable-networks.com (Daniel Schepler) Date: Wed, 29 Apr 2015 23:52:36 +0000 Subject: [CMake] Issues with adding -flto in CMAKE_C[XX]_FLAGS_RELEASE In-Reply-To: References: Message-ID: I've managed to create a small test case that reproduces the issue, and posted a bug report: http://www.cmake.org/Bug/view.php?id=15547 . It would seem that the issue occurs if you try to update CMAKE_AR and CMAKE_RANLIB after a previous run of CMake - though not if you include those settings on the first CMake run. -- Daniel Schepler ________________________________ From: CMake [cmake-bounces at cmake.org] on behalf of Daniel Schepler [dschepler at scalable-networks.com] Sent: Wednesday, April 29, 2015 11:20 AM To: cmake at cmake.org Subject: [CMake] Issues with adding -flto in CMAKE_C[XX]_FLAGS_RELEASE I just tried an experiment on our code base, adding -flto to the default values of CMAKE_C_FLAGS_RELEASE and CMAKE_CXX_FLAGS_RELEASE, and setting CMAKE_AR to /usr/bin/gcc-ar-5, CMAKE_RANLIB to /usr/bin/gcc-ranlib-5. However, make VERBOSE=1 shows that the intermediate static libraries are still being created using /usr/bin/ar; and I can't find any other instances of /usr/bin/ar in CMakeCache.txt. That results in lots of BFD warnings showing up, and linker errors at the end. Is there something I'm missing that would make this able to work; or is this configuration not supported (yet)? -- Daniel Schepler -------------- next part -------------- An HTML attachment was scrubbed... URL: From pelegs at gmail.com Wed Apr 29 20:29:40 2015 From: pelegs at gmail.com (Peleg Bar-Sapir) Date: Thu, 30 Apr 2015 02:29:40 +0200 Subject: [CMake] Linking to MySQL C++ Connector libraries using extra flags, Ubuntu 14.04 LTS, gcc In-Reply-To: References: Message-ID: For some reasons, now the "cmake ." command doesn't work either. I haven't yet begun debugging, but I played a bit with the CMakeLists.txt file, and then returned it to it's original state, with your added lines (replacing mariadb with mysqldb, of course). Now I get this error: $ cmake . CMake Error at CMakeLists.txt:9 (target_link_libraries): Cannot specify link libraries for target "mainexe" which is not built by this project. The CMakeLists.txt looks like this: cmake_minimum_required(VERSION 2.8) project( entity_find_visual ) find_package( OpenCV REQUIRED ) add_executable( entity_find_visual entity_find_visual.cpp) target_link_libraries( entity_find_visual ${OpenCV_LIBS} ) set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} "${CMAKE_SOURCE_DIR}/cmake/Modules/") find_package(MySQL REQUIRED) include_directories(${MYSQL_INCLUDE_DIR}) target_link_libraries(mainexe ${MYSQL_LIBRARY}) (a bit ugly, I know, but it worked before). I'm quite puzzled now, I must admit. On Thu, Apr 30, 2015 at 1:50 AM, Daniel Schepler wrote: > I'd put debugging statements in to see what is being returned as MYSQL_INCLUDE_DIR and MYSQL_LIBRARY; and if those look correct, I'd run "make VERBOSE=1" to check exactly what's on the compilation command line. > -- > Daniel > ________________________________________ > From: Peleg Bar-Sapir [pelegs at gmail.com] > Sent: Wednesday, April 29, 2015 4:46 PM > To: Daniel Schepler > Cc: cmake at cmake.org > Subject: Re: [CMake] Linking to MySQL C++ Connector libraries using extra flags, Ubuntu 14.04 LTS, gcc > > Hello Daniel, > > Thanks for your help. > I took your file and plagiarized it, replacing > "MariaDB"/MARIADB"/"mariadb" with "MySQL"/"MYSQL"/"mysql" accordinly - > and did the same for the CMakeLists.txt (I put FindMySQL.cmake in > /CMake/Modules). Running 'cmake .' now gives no error, but running > make gives me still the linking error: > > $ make > [100%] Building CXX object > CMakeFiles/entity_find_visual.dir/entity_find_visual.cpp.o > /home/[...]/find_visual/entity_find_visual.cpp:17:19: fatal error: > mysql.h: No such file or directory > #include > ^ > compilation terminated. > make[2]: *** [CMakeFiles/entity_find_visual.dir/entity_find_visual.cpp.o] > Error 1 > make[1]: *** [CMakeFiles/entity_find_visual.dir/all] Error 2 > make: *** [all] Error 2 > > This is almost exactly what happens when I run a Makefile without the flag: > > $make foo > g++ foo.cpp foolib.cpp -o foo `pkg-config --cflags --libs gsl` -std=c++11 > In file included from foo.cpp:5:0: > foolib.h:16:23: fatal error: my_global.h: No such file or directory > #include > ^ > compilation terminated. > > Am I missing something? > > Peleg > > On Thu, Apr 30, 2015 at 12:52 AM, Daniel Schepler > wrote: >> I'd say that most of the output of mysql_config --cflags and mysql_config --libs is a bug - for the shared library, there's no need to explicitly include the pthread etc. libraries (unless, of course, your program also uses them directly). In CMake terms, they should have been PRIVATE dependencies of the shared library, rather than PUBLIC. (I don't seem to have been able to convince the MariaDB Connector/C developers of that, though...) >> >> I'm attaching a file I wrote for our project to enable: >> find_package(MariaDB REQUIRED) >> include_directories(${MARIADB_INCLUDE_DIR}) >> target_link_libraries(mainexe ${MARIADB_LIBRARY}) >> -- >> Daniel Schepler >> ________________________________________ >> From: CMake [cmake-bounces at cmake.org] on behalf of Peleg Bar-Sapir [pelegs at gmail.com] >> Sent: Wednesday, April 29, 2015 2:56 PM >> To: cmake at cmake.org >> Subject: [CMake] Linking to MySQL C++ Connector libraries using extra flags, Ubuntu 14.04 LTS, gcc >> >> Hello, >> >> First, I would like to point out that I'm new to CMake, and I'm not a >> professional programer by any means - just a Physics research student. >> I looked for answers to my issue online, but couldn't find anything >> that helped me. I also asked my peers and friends, but unfortunately >> none of them could find an answer as well. >> >> I want to use MySQL connector for C++ in a program. Usually I do this >> by using the 'mysql' and 'my_global' libraries, and then run gcc with >> this added flag: `mysql_config --cflags --libs`. >> Typing this command into my console results in: >> >> $mysql_config --cflags --libs >> -I/usr/include/mysql -DBIG_JOINS=1 -fno-strict-aliasing -g -DNDEBUG >> -L/usr/lib/x86_64-linux-gnu -lmysqlclient -lpthread -lz -lm -ldl >> >> meaning there are some linking flags that must be given so gcc would >> compile my code, apart from just "-lmysql" or "-l/usr/include/mysql". >> >> My question is how do I ensure this works also with CMake? I >> understand how to use the CMakeLists.txt file to configure additional >> external libraries, but none of them require special flags as above, >> at least in my basic use of them. Since there's no module for MySQL >> connector, I'm a bit lost here. >> >> Could anyone please give me a some advices, or point me to what should be done? >> >> >> Thanks, >> >> Peleg Bar Sapir >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake >> > From DLRdave at aol.com Wed Apr 29 20:36:49 2015 From: DLRdave at aol.com (David Cole) Date: Wed, 29 Apr 2015 20:36:49 -0400 Subject: [CMake] How to work around permission deficiencies of file(GENERATE...)? (was cmp0026, file(GENERATE...), and configure_file) In-Reply-To: References: Message-ID: It seems like a reasonable feature request to me to ask for file(GENERATE to support a similar or sub-set of permissions related options which other file subcommands already provide: [FILE_PERMISSIONS ...] [NO_SOURCE_PERMISSIONS] [USE_SOURCE_PERMISSIONS] Doesn't seem like it should be that hard to add support incrementally for that feature... D On Wed, Apr 29, 2015 at 7:18 PM, Alan W. Irwin wrote: > While attempting to use the configure_file_generate function discussed > in a recent thread here, I discovered a permission deficiency of the > file(GENERATE ...) command which was that permissions are not copied > from input file to output file like they are with configure_file. > > @CMake developers: was this treatment of permissions by design or is > this a bug in the implementation of the file(GENERATE...) command that > you are willing to fix? > > Here is my initial (non-working) attempt to work around this issue > in my configure_file_generate function. > > [...] > # Configure generator expressions. > # N.B. these ${output_file} results will only be available > # at generate time. > file(GENERATE > OUTPUT ${output_file} > INPUT ${intermediate_file} > ) > > if(UNIX OR MSYS) > # This covers all platforms which have permissions, > # i.e., Unix, Cygwin, and MSYS platforms. > > # Work around bad permission semantics of file(GENERATE...) which > # does not copy permissions from input file. Note this --reference > # syntax is probably a non-posix extension of the GNU version of chmod. > # So this will silently fail to change permissions > # on platforms without access to the GNU version of chmod. > execute_process( > COMMAND chmod --reference=${intermediate_file} ${output_file} > ) > endif(UNIX OR MSYS) > > Obviously this workaround does not currently work since > execute_process occurs at configure time rather than generate time as > can be seen from these results: > > software at raven> ls -l examples/tk/tk01* > -rw-r--r-- 1 software software 3692 Apr 29 15:45 examples/tk/tk01 > -rwxr-xr-x 1 software software 3658 Apr 29 15:45 examples/tk/tk01_cf_only* > > where the first file (with bad permissions) is the ${output_file} and > the second file the ${intermediate_file} used in the > configure_file_generate function. > > Is there any method I can use at generate time to change permissions > on the OUTPUT file generated by file(GENERATE...), e.g., is there any > way I can force execute_process to work at generate time? > > Of course, I could fix permissions at build time, but that is a big > maintenance issue trying to keep track of every file processed by > configure_file_generate so I would far prefer to change the > permissions at generate time within the configure_file_generate > function. > > Alan > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state > implementation for stellar interiors (freeeos.sf.net); the Time > Ephemerides project (timeephem.sf.net); PLplot scientific plotting > software package (plplot.sf.net); the libLASi project > (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); > and the Linux Brochure Project (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 dschepler at scalable-networks.com Wed Apr 29 20:50:55 2015 From: dschepler at scalable-networks.com (Daniel Schepler) Date: Thu, 30 Apr 2015 00:50:55 +0000 Subject: [CMake] Linking to MySQL C++ Connector libraries using extra flags, Ubuntu 14.04 LTS, gcc In-Reply-To: References: , Message-ID: OK, my target_link_libraries() line was just an example not knowing your executable name - you'd want to update it to target_link_libraries(entity_find_visual ${MYSQL_LIBRARY}) . (And personally, I'd group the find_package calls together, then combine the target_link_libraries lines into one - target_link_libraries(entity_find_visual ${OpenCV_LIBS} ${MYSQL_LIBRARY}).) -- Daniel ________________________________________ From: Peleg Bar-Sapir [pelegs at gmail.com] Sent: Wednesday, April 29, 2015 5:29 PM To: Daniel Schepler Cc: cmake at cmake.org Subject: Re: [CMake] Linking to MySQL C++ Connector libraries using extra flags, Ubuntu 14.04 LTS, gcc For some reasons, now the "cmake ." command doesn't work either. I haven't yet begun debugging, but I played a bit with the CMakeLists.txt file, and then returned it to it's original state, with your added lines (replacing mariadb with mysqldb, of course). Now I get this error: $ cmake . CMake Error at CMakeLists.txt:9 (target_link_libraries): Cannot specify link libraries for target "mainexe" which is not built by this project. The CMakeLists.txt looks like this: cmake_minimum_required(VERSION 2.8) project( entity_find_visual ) find_package( OpenCV REQUIRED ) add_executable( entity_find_visual entity_find_visual.cpp) target_link_libraries( entity_find_visual ${OpenCV_LIBS} ) set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} "${CMAKE_SOURCE_DIR}/cmake/Modules/") find_package(MySQL REQUIRED) include_directories(${MYSQL_INCLUDE_DIR}) target_link_libraries(mainexe ${MYSQL_LIBRARY}) (a bit ugly, I know, but it worked before). I'm quite puzzled now, I must admit. On Thu, Apr 30, 2015 at 1:50 AM, Daniel Schepler wrote: > I'd put debugging statements in to see what is being returned as MYSQL_INCLUDE_DIR and MYSQL_LIBRARY; and if those look correct, I'd run "make VERBOSE=1" to check exactly what's on the compilation command line. > -- > Daniel > ________________________________________ > From: Peleg Bar-Sapir [pelegs at gmail.com] > Sent: Wednesday, April 29, 2015 4:46 PM > To: Daniel Schepler > Cc: cmake at cmake.org > Subject: Re: [CMake] Linking to MySQL C++ Connector libraries using extra flags, Ubuntu 14.04 LTS, gcc > > Hello Daniel, > > Thanks for your help. > I took your file and plagiarized it, replacing > "MariaDB"/MARIADB"/"mariadb" with "MySQL"/"MYSQL"/"mysql" accordinly - > and did the same for the CMakeLists.txt (I put FindMySQL.cmake in > /CMake/Modules). Running 'cmake .' now gives no error, but running > make gives me still the linking error: > > $ make > [100%] Building CXX object > CMakeFiles/entity_find_visual.dir/entity_find_visual.cpp.o > /home/[...]/find_visual/entity_find_visual.cpp:17:19: fatal error: > mysql.h: No such file or directory > #include > ^ > compilation terminated. > make[2]: *** [CMakeFiles/entity_find_visual.dir/entity_find_visual.cpp.o] > Error 1 > make[1]: *** [CMakeFiles/entity_find_visual.dir/all] Error 2 > make: *** [all] Error 2 > > This is almost exactly what happens when I run a Makefile without the flag: > > $make foo > g++ foo.cpp foolib.cpp -o foo `pkg-config --cflags --libs gsl` -std=c++11 > In file included from foo.cpp:5:0: > foolib.h:16:23: fatal error: my_global.h: No such file or directory > #include > ^ > compilation terminated. > > Am I missing something? > > Peleg > > On Thu, Apr 30, 2015 at 12:52 AM, Daniel Schepler > wrote: >> I'd say that most of the output of mysql_config --cflags and mysql_config --libs is a bug - for the shared library, there's no need to explicitly include the pthread etc. libraries (unless, of course, your program also uses them directly). In CMake terms, they should have been PRIVATE dependencies of the shared library, rather than PUBLIC. (I don't seem to have been able to convince the MariaDB Connector/C developers of that, though...) >> >> I'm attaching a file I wrote for our project to enable: >> find_package(MariaDB REQUIRED) >> include_directories(${MARIADB_INCLUDE_DIR}) >> target_link_libraries(mainexe ${MARIADB_LIBRARY}) >> -- >> Daniel Schepler >> ________________________________________ >> From: CMake [cmake-bounces at cmake.org] on behalf of Peleg Bar-Sapir [pelegs at gmail.com] >> Sent: Wednesday, April 29, 2015 2:56 PM >> To: cmake at cmake.org >> Subject: [CMake] Linking to MySQL C++ Connector libraries using extra flags, Ubuntu 14.04 LTS, gcc >> >> Hello, >> >> First, I would like to point out that I'm new to CMake, and I'm not a >> professional programer by any means - just a Physics research student. >> I looked for answers to my issue online, but couldn't find anything >> that helped me. I also asked my peers and friends, but unfortunately >> none of them could find an answer as well. >> >> I want to use MySQL connector for C++ in a program. Usually I do this >> by using the 'mysql' and 'my_global' libraries, and then run gcc with >> this added flag: `mysql_config --cflags --libs`. >> Typing this command into my console results in: >> >> $mysql_config --cflags --libs >> -I/usr/include/mysql -DBIG_JOINS=1 -fno-strict-aliasing -g -DNDEBUG >> -L/usr/lib/x86_64-linux-gnu -lmysqlclient -lpthread -lz -lm -ldl >> >> meaning there are some linking flags that must be given so gcc would >> compile my code, apart from just "-lmysql" or "-l/usr/include/mysql". >> >> My question is how do I ensure this works also with CMake? I >> understand how to use the CMakeLists.txt file to configure additional >> external libraries, but none of them require special flags as above, >> at least in my basic use of them. Since there's no module for MySQL >> connector, I'm a bit lost here. >> >> Could anyone please give me a some advices, or point me to what should be done? >> >> >> Thanks, >> >> Peleg Bar Sapir >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware 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 pelegs at gmail.com Wed Apr 29 21:18:29 2015 From: pelegs at gmail.com (Peleg Bar-Sapir) Date: Thu, 30 Apr 2015 03:18:29 +0200 Subject: [CMake] Linking to MySQL C++ Connector libraries using extra flags, Ubuntu 14.04 LTS, gcc In-Reply-To: References: Message-ID: Oh, ok. It works (had to solve some conflicting definitions between OpenCV and MySQL libraries, but I managed that). Thanks a lot! I would excuse the the obvious issue with mainexe by stating it's late (3AM here), but I'm a night-owl, so that's not really an excuse... should be more sharp next time ;) Peleg On Thu, Apr 30, 2015 at 2:50 AM, Daniel Schepler wrote: > OK, my target_link_libraries() line was just an example not knowing your executable name - you'd want to update it to target_link_libraries(entity_find_visual ${MYSQL_LIBRARY}) . (And personally, I'd group the find_package calls together, then combine the target_link_libraries lines into one - target_link_libraries(entity_find_visual ${OpenCV_LIBS} ${MYSQL_LIBRARY}).) > -- > Daniel > ________________________________________ > From: Peleg Bar-Sapir [pelegs at gmail.com] > Sent: Wednesday, April 29, 2015 5:29 PM > To: Daniel Schepler > Cc: cmake at cmake.org > Subject: Re: [CMake] Linking to MySQL C++ Connector libraries using extra flags, Ubuntu 14.04 LTS, gcc > > For some reasons, now the "cmake ." command doesn't work either. I > haven't yet begun debugging, but I played a bit with the > CMakeLists.txt file, and then returned it to it's original state, with > your added lines (replacing mariadb with mysqldb, of course). > Now I get this error: > > $ cmake . > CMake Error at CMakeLists.txt:9 (target_link_libraries): > Cannot specify link libraries for target "mainexe" which is not built by > this project. > > The CMakeLists.txt looks like this: > > cmake_minimum_required(VERSION 2.8) > project( entity_find_visual ) > find_package( OpenCV REQUIRED ) > add_executable( entity_find_visual entity_find_visual.cpp) > target_link_libraries( entity_find_visual ${OpenCV_LIBS} ) > set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} "${CMAKE_SOURCE_DIR}/cmake/Modules/") > find_package(MySQL REQUIRED) > include_directories(${MYSQL_INCLUDE_DIR}) > target_link_libraries(mainexe ${MYSQL_LIBRARY}) > > (a bit ugly, I know, but it worked before). > > I'm quite puzzled now, I must admit. > > On Thu, Apr 30, 2015 at 1:50 AM, Daniel Schepler > wrote: >> I'd put debugging statements in to see what is being returned as MYSQL_INCLUDE_DIR and MYSQL_LIBRARY; and if those look correct, I'd run "make VERBOSE=1" to check exactly what's on the compilation command line. >> -- >> Daniel >> ________________________________________ >> From: Peleg Bar-Sapir [pelegs at gmail.com] >> Sent: Wednesday, April 29, 2015 4:46 PM >> To: Daniel Schepler >> Cc: cmake at cmake.org >> Subject: Re: [CMake] Linking to MySQL C++ Connector libraries using extra flags, Ubuntu 14.04 LTS, gcc >> >> Hello Daniel, >> >> Thanks for your help. >> I took your file and plagiarized it, replacing >> "MariaDB"/MARIADB"/"mariadb" with "MySQL"/"MYSQL"/"mysql" accordinly - >> and did the same for the CMakeLists.txt (I put FindMySQL.cmake in >> /CMake/Modules). Running 'cmake .' now gives no error, but running >> make gives me still the linking error: >> >> $ make >> [100%] Building CXX object >> CMakeFiles/entity_find_visual.dir/entity_find_visual.cpp.o >> /home/[...]/find_visual/entity_find_visual.cpp:17:19: fatal error: >> mysql.h: No such file or directory >> #include >> ^ >> compilation terminated. >> make[2]: *** [CMakeFiles/entity_find_visual.dir/entity_find_visual.cpp.o] >> Error 1 >> make[1]: *** [CMakeFiles/entity_find_visual.dir/all] Error 2 >> make: *** [all] Error 2 >> >> This is almost exactly what happens when I run a Makefile without the flag: >> >> $make foo >> g++ foo.cpp foolib.cpp -o foo `pkg-config --cflags --libs gsl` -std=c++11 >> In file included from foo.cpp:5:0: >> foolib.h:16:23: fatal error: my_global.h: No such file or directory >> #include >> ^ >> compilation terminated. >> >> Am I missing something? >> >> Peleg >> >> On Thu, Apr 30, 2015 at 12:52 AM, Daniel Schepler >> wrote: >>> I'd say that most of the output of mysql_config --cflags and mysql_config --libs is a bug - for the shared library, there's no need to explicitly include the pthread etc. libraries (unless, of course, your program also uses them directly). In CMake terms, they should have been PRIVATE dependencies of the shared library, rather than PUBLIC. (I don't seem to have been able to convince the MariaDB Connector/C developers of that, though...) >>> >>> I'm attaching a file I wrote for our project to enable: >>> find_package(MariaDB REQUIRED) >>> include_directories(${MARIADB_INCLUDE_DIR}) >>> target_link_libraries(mainexe ${MARIADB_LIBRARY}) >>> -- >>> Daniel Schepler >>> ________________________________________ >>> From: CMake [cmake-bounces at cmake.org] on behalf of Peleg Bar-Sapir [pelegs at gmail.com] >>> Sent: Wednesday, April 29, 2015 2:56 PM >>> To: cmake at cmake.org >>> Subject: [CMake] Linking to MySQL C++ Connector libraries using extra flags, Ubuntu 14.04 LTS, gcc >>> >>> Hello, >>> >>> First, I would like to point out that I'm new to CMake, and I'm not a >>> professional programer by any means - just a Physics research student. >>> I looked for answers to my issue online, but couldn't find anything >>> that helped me. I also asked my peers and friends, but unfortunately >>> none of them could find an answer as well. >>> >>> I want to use MySQL connector for C++ in a program. Usually I do this >>> by using the 'mysql' and 'my_global' libraries, and then run gcc with >>> this added flag: `mysql_config --cflags --libs`. >>> Typing this command into my console results in: >>> >>> $mysql_config --cflags --libs >>> -I/usr/include/mysql -DBIG_JOINS=1 -fno-strict-aliasing -g -DNDEBUG >>> -L/usr/lib/x86_64-linux-gnu -lmysqlclient -lpthread -lz -lm -ldl >>> >>> meaning there are some linking flags that must be given so gcc would >>> compile my code, apart from just "-lmysql" or "-l/usr/include/mysql". >>> >>> My question is how do I ensure this works also with CMake? I >>> understand how to use the CMakeLists.txt file to configure additional >>> external libraries, but none of them require special flags as above, >>> at least in my basic use of them. Since there's no module for MySQL >>> connector, I'm a bit lost here. >>> >>> Could anyone please give me a some advices, or point me to what should be done? >>> >>> >>> Thanks, >>> >>> Peleg Bar Sapir >>> -- >>> >>> Powered by www.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >>> >>> CMake Support: http://cmake.org/cmake/help/support.html >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware 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 irwin at beluga.phys.uvic.ca Wed Apr 29 22:17:06 2015 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Wed, 29 Apr 2015 19:17:06 -0700 (PDT) Subject: [CMake] How to work around permission deficiencies of file(GENERATE...)? (was cmp0026, file(GENERATE...), and configure_file) In-Reply-To: References: Message-ID: On 2015-04-29 20:36-0400 David Cole wrote: > It seems like a reasonable feature request to me to ask for > file(GENERATE to support a similar or sub-set of permissions related > options which other file subcommands already provide: > > [FILE_PERMISSIONS ...] > [NO_SOURCE_PERMISSIONS] [USE_SOURCE_PERMISSIONS] > > Doesn't seem like it should be that hard to add support incrementally > for that feature... I did notice those options for file(COPY...) and making those available for file(GENERATE...) as well sounds like a good idea in general. However, until that is implemented (or configure_file(GENERATE ...) is implemented with the usual configure_file permission semantics which just copies the permissions of the source file) I need a method of setting file permissions at generate time. Is there currently _any_ way to do that under CMake? If the answer is "no", then for now I am going to have to use some ugly permission fixups at build time for a use case (configured executable script that needs to know the location of a different executable in the build tree) that is likely not that uncommon. So either I am missing some obvious method of setting permissions at generate-time or other projects with that use case have likely been sticking with CMP0026 OLD. I don't plan to go back to CMP0026 OLD myself since the argument for possible location bugs for that case make sense to me. At the same time though, I think it is fair to say CMP0026 NEW has certainly not been a smooth experience for me. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From lmalchus at web.de Thu Apr 30 05:19:01 2015 From: lmalchus at web.de (Lutz Malchus) Date: Thu, 30 Apr 2015 11:19:01 +0200 Subject: [CMake] NMake VC13 Release generates Debug Message-ID: Hi CMaker, when i start cmake ?DCMAKE_BUILD_TYPE=Release -G "NMake Makefiles" .. in a Visual Studio 13 - x64 Command Line Client (with clear build-dir) nmake generates an debug-application instead of an release. Generating NMake-Makefiles with cmake-gui (out of the same Client) works. Generating NMake-Makefiles on a differnt machine in a Visual Studio 10 - x64 Command Line Client works. " cmake_minimum_required(VERSION 2.8.9) project(myapp) add_executable(myapp main.cpp) set_target_properties(myapp PROPERTIES LINK_FLAGS_RELEASE "/SUBSYSTEM:CONSOLE") " CMake-Version 3.2.2 Is there anything i'm doing wrong? Lutz -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Thu Apr 30 05:36:52 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 30 Apr 2015 11:36:52 +0200 Subject: [CMake] NMake VC13 Release generates Debug In-Reply-To: References: Message-ID: <5541F7B4.7020906@gmail.com> On 04/30/2015 11:19 AM, Lutz Malchus wrote: > Hi CMaker, > > when i start > > cmake ?DCMAKE_BUILD_TYPE=Release -G "NMake Makefiles" .. > > in a Visual Studio 13 - x64 Command Line Client (with clear build-dir) I assume you mean Visual Studio 12 - 2013? "?DCMAKE_BUILD_TYPE=Release" is wrong. "-DCMAKE_BUILD_TYPE=Release" is correct. You are using ? (U+2013 EN DASH) where you should be using - (U+002D HYPHEN-MINUS). Nils From lmalchus at web.de Thu Apr 30 05:58:22 2015 From: lmalchus at web.de (Lutz Malchus) Date: Thu, 30 Apr 2015 11:58:22 +0200 Subject: [CMake] NMake VC13 Release generates Debug In-Reply-To: <5541F7B4.7020906@gmail.com> References: <5541F7B4.7020906@gmail.com> Message-ID: unbelievable ... Thanks! 2015-04-30 11:36 GMT+02:00 Nils Gladitz : > On 04/30/2015 11:19 AM, Lutz Malchus wrote: > >> Hi CMaker, >> >> when i start >> >> cmake ?DCMAKE_BUILD_TYPE=Release -G "NMake Makefiles" .. >> >> in a Visual Studio 13 - x64 Command Line Client (with clear build-dir) >> > > I assume you mean Visual Studio 12 - 2013? > > "?DCMAKE_BUILD_TYPE=Release" is wrong. > "-DCMAKE_BUILD_TYPE=Release" is correct. > > You are using ? (U+2013 EN DASH) where you should be using - (U+002D > HYPHEN-MINUS). > > 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 > -- Gru? Lutz -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Thu Apr 30 07:11:26 2015 From: DLRdave at aol.com (David Cole) Date: Thu, 30 Apr 2015 07:11:26 -0400 Subject: [CMake] NMake VC13 Release generates Debug In-Reply-To: References: <5541F7B4.7020906@gmail.com> Message-ID: Wow! How do you even type an en dash on the command line? Must be copy/paste... ;-) Great catch, Nils. I just assumed it was the way it was rendered in email..... On Thursday, April 30, 2015, Lutz Malchus wrote: > unbelievable ... > > Thanks! > > > 2015-04-30 11:36 GMT+02:00 Nils Gladitz >: > >> On 04/30/2015 11:19 AM, Lutz Malchus wrote: >> >>> Hi CMaker, >>> >>> when i start >>> >>> cmake ?DCMAKE_BUILD_TYPE=Release -G "NMake Makefiles" .. >>> >>> in a Visual Studio 13 - x64 Command Line Client (with clear build-dir) >>> >> >> I assume you mean Visual Studio 12 - 2013? >> >> "?DCMAKE_BUILD_TYPE=Release" is wrong. >> "-DCMAKE_BUILD_TYPE=Release" is correct. >> >> You are using ? (U+2013 EN DASH) where you should be using - (U+002D >> HYPHEN-MINUS). >> >> 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 >> > > > > -- > Gru? Lutz > -------------- next part -------------- An HTML attachment was scrubbed... URL: From coordz at megaroms.co.uk Thu Apr 30 08:04:08 2015 From: coordz at megaroms.co.uk (coordz at megaroms.co.uk) Date: Thu, 30 Apr 2015 13:04:08 +0100 Subject: [CMake] Adding files to project that don't exist In-Reply-To: References: <5541F7B4.7020906@gmail.com> Message-ID: <35d9157978bd1902b8bc5f33b561303c.squirrel@webmail.plus.net> Hi, I'm using Doxygen to generate my project documentation and have a custom target to do it. Like this: find_package( Doxygen ) if( DOXYGEN_FOUND ) configure_file( ${CMAKE_CURRENT_SOURCE_DIR}/Doxyfile.in ${CMAKE_CURRENT_BINARY_DIR}/Doxyfile @ONLY ) add_custom_target( doc ${DOXYGEN_EXECUTABLE} ${CMAKE_CURRENT_BINARY_DIR}/Doxyfile WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR} COMMENT "Generating API documentation with Doxygen" VERBATIM SOURCES Doxyfile.in ) endif( DOXYGEN_FOUND ) which works fine. However, I'd like to extend this so the generated index.html file is shown as part of the "doc" project when I use the Visual Studio generator. Is there a way to do this? If the file already exist I can coax CMake to include the file by adding it to SOURCES but when the file doesn't exist (most of the time) CMake gives an error. Any help is much appreciated. Thanks. From post at hendrik-sattler.de Thu Apr 30 11:33:18 2015 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Thu, 30 Apr 2015 17:33:18 +0200 Subject: [CMake] Adding files to project that don't exist In-Reply-To: <35d9157978bd1902b8bc5f33b561303c.squirrel@webmail.plus.net> References: <5541F7B4.7020906@gmail.com> <35d9157978bd1902b8bc5f33b561303c.squirrel@webmail.plus.net> Message-ID: <63315D2B-6140-4612-BCB8-41D35717FE83@hendrik-sattler.de> Am 30. April 2015 14:04:08 MESZ, schrieb coordz at megaroms.co.uk: >Hi, > >I'm using Doxygen to generate my project documentation and have a >custom >target to do it. Like this: > >find_package( Doxygen ) > >if( DOXYGEN_FOUND ) > configure_file( ${CMAKE_CURRENT_SOURCE_DIR}/Doxyfile.in >${CMAKE_CURRENT_BINARY_DIR}/Doxyfile @ONLY ) > > add_custom_target( doc > ${DOXYGEN_EXECUTABLE} >${CMAKE_CURRENT_BINARY_DIR}/Doxyfile > WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR} > COMMENT "Generating API documentation with Doxygen" >VERBATIM > SOURCES Doxyfile.in > ) >endif( DOXYGEN_FOUND ) > >which works fine. However, I'd like to extend this so the generated >index.html file is shown as part of the "doc" project when I use the >Visual Studio generator. Is there a way to do this? If the file already >exist I can coax CMake to include the file by adding it to SOURCES but >when the file doesn't exist (most of the time) CMake gives an error. Maybe the following works: Make your doc custom target depend on the output file index.html and run doxygen in that custom command. HS From csiga.biga at aol.com Thu Apr 30 11:20:56 2015 From: csiga.biga at aol.com (=?utf-8?Q?Nagy-Egri_M=C3=A1t=C3=A9_Ferenc?=) Date: Thu, 30 Apr 2015 15:20:56 +0000 Subject: [CMake] =?utf-8?q?C++Now_/_BoostCon_/_Boost_2=2E0?= In-Reply-To: <1430225256313-7590405.post@n2.nabble.com> References: <1430225256313-7590405.post@n2.nabble.com> Message-ID: I wish you good luck on promoting CMake for Boost. Generally, I find the Boost libraries to be of good quality. However, the reason I fear depending on Boost in any of my projects is the aggravation to get various versions to build. Applications that depend on Boost and are shipped as a binary, usually depend a waaaaay outdated version, and getting Boost to build? I gave it 2 tries, sufficiently remote in time for me to forget the pain it caused me in my previous attempts. Configuring and building Boost on Windows is a nightmare. I was relieved when I found that there is a project about converting Boost to CMake, but as you have said (and as the author explained to me) the project was not welcomed. I do not wish to cause the same pain for my users (and myself). Boost Build is just too different from anything out there, it depends on software that is not used by anything other than Boost. It makes no sense in sticking to it, when from all I?ve seen CMake is superior in all regards. Taking into account that there is CTest/CDash/CPack accompanying it, it seems outright crazy to stik to Boost Build. Cheers, M?t? Felad?: Robert Ramey Elk?ldve: ?kedd?, ?2015?. ??prilis? ?28?. ?14?:?47 C?mzett: cmake at cmake.org I will be giving a presentation at C++Now http://cppnow.org https://cppnow2015.sched.org all things boost - which will touch upon CMake/CTest/CDash. I have recommended CMake... for boost - like projects and would like to see it more widely accepted. http://rrsd.com/blincubator.com/tools_cmak/ I'm aware that in the past there was a large effort to switch boost to CMake from Boost Build which ended in failure. For Boost 2.0 https://cppnow2015.sched.org/event/d66a14e9cc28cffbf446b1fd2c3f4696#.VT-AV87_Suc I will promote the idea of boost libraries being less tightly coupled. Part of will be to propose that library authors be permitted to select their own build/test system. Testing of Boost would be just the union of the testing of all the individual libraries. Here are a few observations regarding CMake as it might relate to Boost. a) In the CMake section of the incubator page, I've advocated creating a library subdirectory named CMake which includes the cake scripts. The source files or not in this directory. The scripts contain relative path names to source files in the directory. This permits the CMake scripts to not be sprinkled all over the directory structure but rather in one place. I've used this and found it to work very well. b) I would like to see testing of boost libraries distributed to library users/testers and others, and have their test results posted on a library dashboard. This would provide a number of advantages. So I would like to be able to recommend CTest/CDash. I have made this setup work - but it doesn't "just work". I would like to see: The CTest/CDash system has a sort of elaborate setup of experimental, nightly, etc. which ties certain test names to different test frequencies. This is too complex. Basically all we need is "experimental" which I would more likely call "on demand". This is what users need. Download a library, build it, run test suite and post results. It's great that you guys run the public dashboard and I would like to encourage boost libraries developers to use it. I would like to see a few cosmetic changes but the idea is close to what I would like to see for Boost. I did meet a couple of you at CPPCon last september. If any of you expect go to C++Now please contact me with any information and/or advice you think might be useful to me. Robert Ramey -- View this message in context: http://cmake.3232098.n2.nabble.com/C-Now-BoostCon-Boost-2-0-tp7590405.html Sent from the CMake mailing list archive at Nabble.com. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From nrath at trialphaenergy.com Thu Apr 30 12:52:32 2015 From: nrath at trialphaenergy.com (Nikolaus Rath) Date: Thu, 30 Apr 2015 09:52:32 -0700 Subject: [CMake] Set Fortran compiler in CMakeLists.txt? Message-ID: <55425DD0.2020806@trialphaenergy.com> Hello, Is there a way to set the Fortran compiler from CMakeLists.txt (instead of setting the FC environment when calling cmake)? Thanks, -Nikolaus From cedric.doucet at inria.fr Thu Apr 30 13:52:49 2015 From: cedric.doucet at inria.fr (Cedric Doucet) Date: Thu, 30 Apr 2015 19:52:49 +0200 (CEST) Subject: [CMake] Set Fortran compiler in CMakeLists.txt? In-Reply-To: <55425DD0.2020806@trialphaenergy.com> References: <55425DD0.2020806@trialphaenergy.com> Message-ID: <120635876.1929144.1430416369160.JavaMail.zimbra@inria.fr> Hello, you should try to put set(FC /my/path/to/binaries/of/my/fortran/compiler/gfortran) in your CMakeLists.txt. Of course, you may replace gfortran by the compiler you want to use. C?dric ----- Mail original ----- > De: "Nikolaus Rath" > ?: cmake at cmake.org > Envoy?: Jeudi 30 Avril 2015 18:52:32 > Objet: [CMake] Set Fortran compiler in CMakeLists.txt? > > Hello, > > Is there a way to set the Fortran compiler from CMakeLists.txt (instead > of setting the FC environment when calling cmake)? > > Thanks, > -Nikolaus > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 steveire at gmail.com Thu Apr 30 13:54:19 2015 From: steveire at gmail.com (Stephen Kelly) Date: Thu, 30 Apr 2015 19:54:19 +0200 Subject: [CMake] How to work around permission deficiencies of file(GENERATE...)? References: Message-ID: Alan W. Irwin wrote: > However, until that is implemented (or configure_file(GENERATE ...) is > implemented with the usual configure_file permission semantics which > just copies the permissions of the source file) I need a method of > setting file permissions at generate time. Is there currently _any_ > way to do that under CMake? Yes, CMake 3.2 uses the permissions of the input file if present: http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=81afbbc0 I recommend trying that for your use, and if it works, I think setting CMP0026 to OLD for CMake >= 3.0 && < 3.2 would be ok. Thanks, Steve. From bill.hoffman at kitware.com Thu Apr 30 13:59:41 2015 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Thu, 30 Apr 2015 13:59:41 -0400 Subject: [CMake] Set Fortran compiler in CMakeLists.txt? In-Reply-To: <55425DD0.2020806@trialphaenergy.com> References: <55425DD0.2020806@trialphaenergy.com> Message-ID: <55426D8D.6060005@kitware.com> On 4/30/2015 12:52 PM, Nikolaus Rath wrote: > Hello, > > Is there a way to set the Fortran compiler from CMakeLists.txt (instead > of setting the FC environment when calling cmake)? No, not really. That is not the way CMake works. You want to avoid users of your project to ever have to edit a CMakeLists.txt file. The compiler used is not something you want hard coded into a CMakeLists.txt file. -Bill From nrath at trialphaenergy.com Thu Apr 30 14:50:54 2015 From: nrath at trialphaenergy.com (Nikolaus Rath) Date: Thu, 30 Apr 2015 11:50:54 -0700 Subject: [CMake] Set Fortran compiler in CMakeLists.txt? In-Reply-To: <55426D8D.6060005@kitware.com> References: <55425DD0.2020806@trialphaenergy.com> <55426D8D.6060005@kitware.com> Message-ID: <5542798E.5090005@trialphaenergy.com> On 04/30/2015 10:59 AM, Bill Hoffman wrote: > On 4/30/2015 12:52 PM, Nikolaus Rath wrote: >> Is there a way to set the Fortran compiler from CMakeLists.txt (instead >> of setting the FC environment when calling cmake)? > > No, not really. That is not the way CMake works. You want to avoid > users of your project to ever have to edit a CMakeLists.txt file. The > compiler used is not something you want hard coded into a CMakeLists.txt > file. Hmm. My situation is a bit different. We have different Fortran compilers installed, but this specific one needs to be compiled using the intel compiler. But by default, CMake selects gfortran. At the moment I abort the build if FC != ifort, but this is not exactly a good user experience. Imagine: $ cmake .. Unsupported! Please set FC=ifort $ FC=ifort cmake .. For the user, this raises the question: if the build system knows what compiler it needs, why doesn't it just use it instead of telling me to tell it to use it? :-) Best, -Nikolaus From irwin at beluga.phys.uvic.ca Thu Apr 30 15:16:20 2015 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Thu, 30 Apr 2015 12:16:20 -0700 (PDT) Subject: [CMake] How to work around permission deficiencies of file(GENERATE...)? In-Reply-To: References: Message-ID: On 2015-04-30 19:54+0200 Stephen Kelly wrote: > Alan W. Irwin wrote: > >> However, until that is implemented (or configure_file(GENERATE ...) is >> implemented with the usual configure_file permission semantics which >> just copies the permissions of the source file) I need a method of >> setting file permissions at generate time. Is there currently _any_ >> way to do that under CMake? > > Yes, CMake 3.2 uses the permissions of the input file if present: > > http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=81afbbc0 > > I recommend trying that for your use, and if it works, I think setting > CMP0026 to OLD for CMake >= 3.0 && < 3.2 would be ok. Hi Steve: I tried 3.2 (actually 3.2.1) and indeed permissions problems for my configure_file_generate function were solved for that case. So thanks for anticipating that change was needed, and it appears I finally have a way forward with CMP0026 NEW for CMake 3.2 and above which is a big relief to me! In the meanwhile our CMake minimum version is going to be 3.0.2 probably for the next two years or so. (Our rule of thumb is we update the minimum version of CMake to whatever Debian stable [= the just-released Debian Jessie] supplies so that most of our Linux users will not have to build a CMake version for themselves.) But instead of reverting all of the CMP0026 changes I have made, I plan to temporarily add a custom target in my configure_file_generate function called WORKAROUND_CMP0026_NEW_ to make the necessary permission changes for the CMake >= 3.0 && < 3.2 case, and then add a dependency on that target where needed in the rest of our build system. This approach makes all this cruft easy to remove once we eventually bump our minimum version of CMake to 3.2. I am philosophical about all these complications with CMP0026 NEW. It is just the nature of the software beast that changes like CMP0026 NEW take a while to get right, and I am pleased you are moving in the right direction with changes like your commit above. But please keep in mind that the configure_file_generate function approach is itself a temporary workaround, and for CMake users who need to configure files that include generator expressions, a much cleaner approach will be possible if CMake developers implement a configure_file(... GENERATE ...) signature which configures generator expression items (and also configures all other items at generate time that configure_file without the GENERATE option configures at configure time). And if you do decide to implement something like that, I would be happy to test it for you. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From steveire at gmail.com Thu Apr 30 15:21:38 2015 From: steveire at gmail.com (Stephen Kelly) Date: Thu, 30 Apr 2015 21:21:38 +0200 Subject: [CMake] How to work around permission deficiencies of file(GENERATE...)? References: Message-ID: Alan W. Irwin wrote: > But please keep > in mind that the configure_file_generate function approach is itself a > temporary workaround, and for CMake users who need to configure files > that include generator expressions, a much cleaner approach will be > possible if CMake developers implement a configure_file(... GENERATE > ...) signature which configures generator expression items (and also > configures all other items at generate time that configure_file > without the GENERATE option configures at configure time). > And if you do decide to implement something like that, I would be > happy to test it for you. Yes, something like that might make sense, but it's not on my radar currently to design/implement it. If someone else has the bandwidth for it, I can review it. Thanks, Steve. From rcdailey.lists at gmail.com Thu Apr 30 16:34:54 2015 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Thu, 30 Apr 2015 15:34:54 -0500 Subject: [CMake] find_library while cross compiling? Message-ID: I'm on Windows and I am cross compiling for Android NDK. I use find_library() with PATHS to hunt down some libssl.a files, plus a few others. However, find_library() says it can't find them. I'm assuming this is because I'm on Windows and it doesn't recognize *.a files as a valid library on that platform. Is there a way to make CMake search libraries based on the platform the target is being compiled for? From tom at recursivedream.com Thu Apr 30 16:45:01 2015 From: tom at recursivedream.com (Tom Davis) Date: Thu, 30 Apr 2015 16:45:01 -0400 Subject: [CMake] CMAKE_INSTALL_PREFIX not being used? Message-ID: <87bni52vn6.fsf@recursivedream.com> I'm trying to install a project to /home/tom/usr/local instead of the standard /usr/local. I have tried the following: $ mkdir build && cd build $ cmake -DCMAKE_INSTALL_PREFIX:PATH=/home/tom .. At this point, I have a CMakeCache.txt file that contains the correct path. I have a cmake_install.cmake with the lines: if(NOT DEFINED CMAKE_INSTALL_PREFIX) set(CMAKE_INSTALL_PREFIX "foo") endif() Where "foo" is found in the project's CMakeLists.txt as a default install prefix via `set(CMAKE_INSTALL_PREFIX ${CMAKE_PROJECT_NAME})`. Unfortunately, when I run `make install`, the project is still being installed to `build/foo/`. My apparently incorrect understanding is that passing the value on the command line initially would override whatever was set() in the project's CMakeLists.txt, but that isn't the case. Since I'm actually installing this project using ExternalProject_Add(), how can I override the set() in the project's CMakeLists.txt, if not by using the extra argument during the CONFIGURE step? From rcdailey.lists at gmail.com Thu Apr 30 16:46:35 2015 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Thu, 30 Apr 2015 15:46:35 -0500 Subject: [CMake] CMake, Android, and Eclipse ADT Integration In-Reply-To: References: Message-ID: On Wed, Mar 11, 2015 at 11:42 AM, Robert Dailey wrote: > 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. No help or advice on this? From rob.a.mcdonald at gmail.com Thu Apr 30 17:19:31 2015 From: rob.a.mcdonald at gmail.com (Rob McDonald) Date: Thu, 30 Apr 2015 14:19:31 -0700 Subject: [CMake] Statically link OpenMP on Mac gcc Message-ID: I'm using MacPorts GCC 4.8 and CMake 3.2. I use 'FIND_PACKAGE( OpenMP )', and then use OpenMP_C_FLAGS and OpenMP_CXX_FLAGS appropriately. My application works on the machine that I build on. However, users without MacPorts GCC installed can't find libgomp.1.dylib on their machine. I'd like to tell GCC to statically link libgomp. I think the global -static flag may do this, but it seems like a fairly brutish way of getting the job done. Is there a way to get CMake to tell GCC to statically link libgomp? Or to have more fine grained control over which libraries are static vs. dynamic? Is there any reason to not want to use the global -static? FindOpenMP.cmake isn't like most other Find*.cmake scripts -- instead of searching for a *.h, *.a, *.so, or *.dylib file, it checks various flags to the compiler -fopenmp, /openmp, etc. From that, it determines the appropriate flags, but there isn't any ${OPENMP_LIBRARIES} to use in a later TARGET_LINK_LIBRARIES later on. Thanks, Rob From bm_witness at yahoo.com Thu Apr 30 17:53:26 2015 From: bm_witness at yahoo.com (BRM) Date: Thu, 30 Apr 2015 21:53:26 +0000 (UTC) Subject: [CMake] CMake finding custom packages... Message-ID: <1820304052.21841.1430430806090.JavaMail.yahoo@mail.yahoo.com> I'm trying to convert a project over to using CMake. We have a series of dependency libraries that we custom compile and link against.For a number of them there is no issue since CMake either has no module for them or there is nothing to link with.However, I am having trouble with a few of them. This is all with CMake 2.8.9 as that is what is available under Debian Wheezy (my build system). I'm not opposed to using a newer version (we already build a number of things ourselves); but I want to ensure that things would be fixed before doing so if that was truly the path to resolving the issues. 1. OpenSSL: SET ( ENV{OPENSSL_ROOT_DIR} /path/to/my/libraries )FIND_PACKAGE(OpenSSL REQUIRED) This find OpenSSL, but not the one under /path/to/my/libraries. Are the bug fixes related to honoring OPENSSL_ROOT_DIR after Cmake 2.8.9? 2. Curl I've tried a number of methods. Our version of Curl is also built against our version of OpenSSL; and they are installed under the same path.Further we have tended to needing to use PkgConfig to get it to work correctly in our previous build system. I have tried a number of things, however, I can't seem to get it to reliably find Curl. (I had it, then I cleaned up the environment and it won't find it again.)My biggest challenge here is that there is no equivalent of OPENSSL_ROOT_DIR or any other kinds of hints.I've tried using FindPackage(CURL...), FindPackage(PkgConfig,...)/PKG_CHECK_MODULES(CURL..).A co-worker suggested using CMAKE_FIND_ROOT_PATH, but that hasn't helped either. Any suggestions would be welcome. I'd really like to move us from the old system to cmake and unify our platforms on a single build system generator so we don't have to maintain two build environments. TIA, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From nrath at trialphaenergy.com Thu Apr 30 18:04:48 2015 From: nrath at trialphaenergy.com (Nikolaus Rath) Date: Thu, 30 Apr 2015 15:04:48 -0700 Subject: [CMake] Problem with Fortran conditionals Message-ID: <5542A700.3000308@trialphaenergy.com> Hello, I am in the process of converting a bigger project from pure GNU Make to CMake - mostly because managing dependencies for the Fortran sources has become too painful. Things seem to be mostly working, but I'm hitting one problem. When trying to run the (CMake-generated) Makefile, it fails with: $ make VERBOSE=1 [...] make[2]: Entering directory `/home/nrath/Q2D/LamyRidge/src/model/build' /home/nrath/.local/stow/cmake/bin/cmake -E cmake_copy_f90_mod dagmg_allroutines CMakeFiles/LR_model.dir/dagmg_allroutines.mod.stamp Intel /home/nrath/.local/stow/cmake/bin/cmake -E cmake_copy_f90_mod dagmg_mem CMakeFiles/LR_model.dir/dagmg_mem.mod.stamp Intel /home/nrath/.local/stow/cmake/bin/cmake -E cmake_copy_f90_mod dagmg_pardiso CMakeFiles/LR_model.dir/dagmg_pardiso.mod.stamp Intel Error copying Fortran module "dagmg_pardiso". Tried "DAGMG_PARDISO.mod" and "dagmg_pardiso.mod". make[2]: *** [CMakeFiles/LR_model.dir/home/nrath/Q2D/LamyRidge/src/comm/agmg-seq/dagmg.f90.o.provides.build] Error 1 make[2]: Leaving directory `/home/nrath/Q2D/LamyRidge/src/model/build' make[1]: *** [CMakeFiles/LR_model.dir/all] Error 2 make[1]: Leaving directory `/home/nrath/Q2D/LamyRidge/src/model/build' make: *** [all] Error 2 I am not sure why CMake is trying to copy module files around, but when I looked at the file that provides the "dagmg_pardiso" module, I found this code: !DEC$ IF DEFINED(_MKL_) MODULE dagmg_PARDISO USE dagmg_PARDISSO INTERFACE [...] END INTERFACE END MODULE dagmg_PARDISO !DEC$ ENDIF !----------------------------------------------------------------------- !DEC$ IF .NOT. DEFINED(_MKL_) SUBROUTINE PARDISO( PT, MAXFCT, MNUM, MTYPE, PHASE, N, A, IA, JA & , PERM, NRHS, IPARM, MSGLVL, B, X, ERROR ) [...] END SUBROUTINE PARDISO !DEC$ ENDIF I do not define __MKL__. Is it possible that the CMake dependency parser doesn't understand this way of defining conditionals, and thus looks for a module that does not exist? If so, what would be the best way to work around this? (The code is from a third-party library, so unfortunately I cannot easily change it). Best, -Nikolaus From bill.hoffman at kitware.com Thu Apr 30 18:27:38 2015 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Thu, 30 Apr 2015 18:27:38 -0400 Subject: [CMake] Set Fortran compiler in CMakeLists.txt? In-Reply-To: <5542798E.5090005@trialphaenergy.com> References: <55425DD0.2020806@trialphaenergy.com> <55426D8D.6060005@kitware.com> <5542798E.5090005@trialphaenergy.com> Message-ID: <5542AC5A.6040801@kitware.com> On 4/30/2015 2:50 PM, Nikolaus Rath wrote: > Hmm. My situation is a bit different. We have different Fortran > compilers installed, but this specific one needs to be compiled using > the intel compiler. But by default, CMake selects gfortran. > > At the moment I abort the build if FC != ifort, but this is not exactly > a good user experience. Imagine: > > $ cmake .. > Unsupported! Please set FC=ifort > $ FC=ifort cmake .. > > For the user, this raises the question: if the build system knows what > compiler it needs, why doesn't it just use it instead of telling me to > tell it to use it?:-) I suppose the CMake way to do this would be to test for the "feature" that you need from the compiler. Then complain that the compiler picked does not support "feature N". This would be done with a try_compile. That way if the user has a compiler that supports what you need intel or gfortran it will work. -Bill From nrath at trialphaenergy.com Thu Apr 30 18:40:04 2015 From: nrath at trialphaenergy.com (Nikolaus Rath) Date: Thu, 30 Apr 2015 15:40:04 -0700 Subject: [CMake] Set Fortran compiler in CMakeLists.txt? In-Reply-To: <5542AC5A.6040801@kitware.com> References: <55425DD0.2020806@trialphaenergy.com> <55426D8D.6060005@kitware.com> <5542798E.5090005@trialphaenergy.com> <5542AC5A.6040801@kitware.com> Message-ID: <5542AF44.5000606@trialphaenergy.com> On 04/30/2015 03:27 PM, Bill Hoffman wrote: > On 4/30/2015 2:50 PM, Nikolaus Rath wrote: >> Hmm. My situation is a bit different. We have different Fortran >> compilers installed, but this specific one needs to be compiled using >> the intel compiler. But by default, CMake selects gfortran. >> >> At the moment I abort the build if FC != ifort, but this is not exactly >> a good user experience. Imagine: >> >> $ cmake .. >> Unsupported! Please set FC=ifort >> $ FC=ifort cmake .. >> >> For the user, this raises the question: if the build system knows what >> compiler it needs, why doesn't it just use it instead of telling me to >> tell it to use it?:-) > > I suppose the CMake way to do this would be to test for the "feature" > that you need from the compiler. Then complain that the compiler picked > does not support "feature N". This would be done with a try_compile. > That way if the user has a compiler that supports what you need intel or > gfortran it will work. In practice this still means that the user still has to manually choose ifort, and that the error message is now almost deliberately obfuscated ("please use ifort" is much easier to understand than "your compiler does not support x, y, z and a. Please switch to a different compiler"). I know what compilers we have installed, what features they have, and which one's are compatible with the code. Is there really no way to encode that knowledge in the build system? Best, -Nikolaus From parag at ionicsecurity.com Thu Apr 30 22:43:26 2015 From: parag at ionicsecurity.com (Parag Chandra) Date: Fri, 1 May 2015 02:43:26 +0000 Subject: [CMake] find_library while cross compiling? In-Reply-To: References: Message-ID: Hi Robert, I encountered a similar problem when I was cross-compiling for NaCl on Windows. You need to set various CMake variables that explicitly override things like the library suffix/prefix. For example, in my case I needed to set the following: set (CMAKE_STATIC_LIBRARY_PREFIX "lib") set (CMAKE_STATIC_LIBRARY_SUFFIX ".a") set (CMAKE_EXECUTABLE_SUFFIX ".pexe" CACHE STRING "" FORCE) set (CMAKE_SHARED_LIBRARY_PREFIX "lib") set (CMAKE_SHARED_LIBRARY_SUFFIX ".so") Hope this helps. Parag Chandra Senior Software Engineer, Mobile Team Mobile: +1.919.824.1410 Ionic Security Inc. 1170 Peachtree St. NE STE 400, Atlanta, GA 30309 On 4/30/15, 4:34 PM, "Robert Dailey" wrote: >I'm on Windows and I am cross compiling for Android NDK. I use >find_library() with PATHS to hunt down some libssl.a files, plus a few >others. > >However, find_library() says it can't find them. I'm assuming this is >because I'm on Windows and it doesn't recognize *.a files as a valid >library on that platform. Is there a way to make CMake search >libraries based on the platform the target is being compiled for? >-- > >Powered by www.kitware.com > >Please keep messages on-topic and check the CMake FAQ at: >http://www.cmake.org/Wiki/CMake_FAQ > >Kitware offers various services to support the CMake community. For more >information on each offering, please visit: > >CMake Support: http://cmake.org/cmake/help/support.html >CMake Consulting: http://cmake.org/cmake/help/consulting.html >CMake Training Courses: http://cmake.org/cmake/help/training.html > >Visit other Kitware 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 jchris.fillionr at kitware.com Thu Apr 30 23:06:01 2015 From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin) Date: Thu, 30 Apr 2015 23:06:01 -0400 Subject: [CMake] Set Fortran compiler in CMakeLists.txt? In-Reply-To: <5542AF44.5000606@trialphaenergy.com> References: <55425DD0.2020806@trialphaenergy.com> <55426D8D.6060005@kitware.com> <5542798E.5090005@trialphaenergy.com> <5542AC5A.6040801@kitware.com> <5542AF44.5000606@trialphaenergy.com> Message-ID: Hi Nikolaus, May you could ask your user to invoke cmake with the -C argument allowing to specify an initial cache file with value specific to the environment ? It would for example contain: set(FC "ifort" CACHE PATH "Intel Fortran compiler") See http://www.cmake.org/cmake/help/v3.1/manual/cmake.1.html Hth Jc On Thu, Apr 30, 2015 at 6:40 PM, Nikolaus Rath wrote: > On 04/30/2015 03:27 PM, Bill Hoffman wrote: > > On 4/30/2015 2:50 PM, Nikolaus Rath wrote: > >> Hmm. My situation is a bit different. We have different Fortran > >> compilers installed, but this specific one needs to be compiled using > >> the intel compiler. But by default, CMake selects gfortran. > >> > >> At the moment I abort the build if FC != ifort, but this is not exactly > >> a good user experience. Imagine: > >> > >> $ cmake .. > >> Unsupported! Please set FC=ifort > >> $ FC=ifort cmake .. > >> > >> For the user, this raises the question: if the build system knows what > >> compiler it needs, why doesn't it just use it instead of telling me to > >> tell it to use it?:-) > > > > I suppose the CMake way to do this would be to test for the "feature" > > that you need from the compiler. Then complain that the compiler picked > > does not support "feature N". This would be done with a try_compile. > > That way if the user has a compiler that supports what you need intel or > > gfortran it will work. > > > In practice this still means that the user still has to manually choose > ifort, and that the error message is now almost deliberately obfuscated > ("please use ifort" is much easier to understand than "your compiler > does not support x, y, z and a. Please switch to a different compiler"). > > I know what compilers we have installed, what features they have, and > which one's are compatible with the code. Is there really no way to > encode that knowledge in the build system? > > Best, > -Nikolaus > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -- +1 919 869 8849 -------------- next part -------------- An HTML attachment was scrubbed... URL: From parag at ionicsecurity.com Thu Apr 30 23:11:37 2015 From: parag at ionicsecurity.com (Parag Chandra) Date: Fri, 1 May 2015 03:11:37 +0000 Subject: [CMake] CMake, Android, and Eclipse ADT Integration In-Reply-To: References: Message-ID: Hi Robert, This will be a bit long-winded, so bear with me. I?m also cross-compiling for Android with CMake, and am currently using Eclipse ADT for much of my development. I have tried hard to make Eclipse work for both the Java and the C++ portions of my libraries and applications, but gave up after a few months when it became apparent that Eclipse?s support for Android?s C++ toolchain is horribly broken. Essentially, I got it to work for brief periods of time, with concurrent Java/C++ debugging, but then Eclipse would inexplicably forget all of the library/include paths, display thousands of red squiggles all over my code, and then refuse to launch my application. The only ?solution? was to completely strip the project of its C++ nature, add it back in, and then reconfigure all the library/include paths, at which point everything would work again for a few hours or a couple of days. Add to this the fact that Google has officially deprecated Ant+Eclipse in favor of IntelliJ+Gradle, and it?s become clear that my time will be better spent migrating to Android Studio. Of course, Android Studio has absolutely no support for C/C++ at the moment, but at least it won?t get in the way like Eclipse did. So I think a near-term solution is to use Android Studio for all of the Java code, in conjunction with one of several different Visual Studio-based offerings for all the C++ code: Visual Studio 2015 WinGDB VisualGDB Android++ Somewhere around the CMake 3.1 timeframe, they introduced a small feature that enables the Visual Studio generator to support any arbitrary cross-toolchain, instead of just a few hardcoded ones. I?ve been using this to generate VS solutions that target Native Client as well as Windows Phone. Although I haven?t yet had a chance to play around with any of the offerings I mentioned previously, I believe you will be able to use this same feature to target Android, after you have installed one of these plug-ins in Visual Studio. Probably not the answer you wanted to hear, but I thought I would share my experience and hopefully save you some trouble. Parag Chandra Senior Software Engineer, Mobile Team Mobile: +1.919.824.1410 Ionic Security Inc. 1170 Peachtree St. NE STE 400, Atlanta, GA 30309 On 4/30/15, 4:46 PM, "Robert Dailey" wrote: >On Wed, Mar 11, 2015 at 11:42 AM, Robert Dailey > wrote: >> 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. > >No help or advice on this? >-- > >Powered by www.kitware.com > >Please keep messages on-topic and check the CMake FAQ at: >http://www.cmake.org/Wiki/CMake_FAQ > >Kitware offers various services to support the CMake community. For more >information on each offering, please visit: > >CMake Support: http://cmake.org/cmake/help/support.html >CMake Consulting: http://cmake.org/cmake/help/consulting.html >CMake Training Courses: http://cmake.org/cmake/help/training.html > >Visit other Kitware open-source projects at >http://www.kitware.com/opensource/opensource.html > >Follow this link to subscribe/unsubscribe: >http://public.kitware.com/mailman/listinfo/cmake