Oh good point on OpenSSL, their official build steps are awkard enough, let alone trying to emulate them in CMake!
For what it's worth, we've upgraded boost-cmake to Boost 1.65 so far with no changes required to any of the modules we use. The other 3rd party module manager we're looking into is Conan (conan.io), which can create CMake import libraries / targets. It's a complex tool to understand, though. I see in your mail that you're using a file to write SHA tags of your current 3rd party modules. Boost-cmake does a similar thing, but it stores it in the cmake cache, perhaps slightly easier to work with? Do I understand correctly that you're using this external file as a dependency from which to trigger a 3rd party module build? But cmake isn't detecting changes / running the custom commands that are dependent on that file? Might it help to add the file to one of your own projects, eg one of the projects that depends on boost / openssl? From memory, I believe cmake only cares about files if they're actually part of a target (unsure if custom targets count)? Mark -----Original Message----- From: Cameron Palmer [mailto:came...@promon.no] Sent: 02 March 2018 13:21 To: Mark De Wit <mark.de...@iesve.com> Cc: cmake@cmake.org Subject: Re: add_custom_target Interesting project, so thanks for the link! The problem we have is that changing the build system for external projects isn’t really acceptable. In this boost-cmake build they ripped out jam and replaced it with cmake, which is kind of cool, but such action is not a good plan for OpenSSL. If I recall they state (somewhere) in the documentation, don’t do this and even if it did work, I wouldn’t want to support it. Furthermore, it looks like you’d also be stuck using 1.63.0 of Boost. In summary, there is a lot of compromise involved in trying to replace a build-system, better to wrap it. Cameron. > On 2 Mar 2018, at 13:02, Mark De Wit <mark.de...@iesve.com> wrote: > > Hi Cameron, > > For boost integration into our cmake project, we're using this (slightly > customised for our use): > https://github.com/Orphis/boost-cmake > > It unzips boost into your build folder, and builds the required packages on > demand (not all of boost, just the boost modules you use). > > It works well for incremental builds (doesn't rebuild unless you clear your > build folder), and for clean builds the individual boost modules build fast > enough to be insignificant. I'd also point out that the build time increase > is somewhat balanced out by not fetching tens of thousands files from source > control... > > This may help shape your thinking? > > Mark > > -----Original Message----- > From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Cameron Palmer > Sent: 02 March 2018 11:22 > To: cmake@cmake.org > Subject: [CMake] add_custom_target > > I’m using ExternalProject_Add to download a Git project that is a > pre-requisite of my project. For the sake of the discussion I’ve wrapped > OpenSSL and Boost in this manner placing tagged version of the source in my > repo. > > Building them isn’t really a problem, they run, take a long time compiling. > The thing is, they should only compile once unless the tag changes. From the > source it seems once you’ve used git you’ll always trigger the whole External > Build sequence which is a pain since it is slow. So… I’ve been trying to > create an external build just for the Git checkout and a second for the > compilation. Which goes well enough, but I still need the glue to signal that > he source is ‘dirty’ and it should recompile the project. > > The glue I’m trying to use is add_custom_command and add_custom_target, but > add_custom_target seems… broken if only in concept. I’ve been trying to write > a file to the system with the SHA tag and only touch it when it changes, but > I cannot convince the ExternalProject that builds the library to not run. > > Any tips that might make this work? > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/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: https://cmake.org/mailman/listinfo/cmake
