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