Hi Alex, the standard solution to this is to use a Superbuild approach, in which the top-level CMakeList contains *only* ExternalProject calls. That means your actual project becomes just another "external" project in this superbuild, which allows you set up all build dependencies etc. as necessary. Then, you proceed like this:
* First generate and build the Superbuild * Then switch to your real project within the superbuild infrastructure, and do all further development there. You're guaranteed all your dependencies are already available by them having been built as part of the Superbuild step above. Googling for "CMake ExternalProject superbuild" should give you more info. Petr On Fri, 24 Aug 2018 at 12:06, Alexander Dahl <p...@lespocky.de> wrote: > Hei hei, > > for a standalone build without system libraries I was experimenting > with the ExternalProject module today. My goal is to have some top > level build project which includes several CMake projects and some > external projects without relying on dev libraries installed on the > system (reason are basically incompatible library versions). However > those CMake projects should not be altered and should also be capable > of building against dev libs from the system or in a cross compile > environment like ptxdist. I created a simple example project to build > OpenSSL with the ExternalProject module, and link either that or the > OpenSSL lib from the system: > > https://github.com/LeSpocky/effective-succotash > > (Note: using MD5 inside this example program is really just a very > simple example, the real application will use more of OpenSSL, so that > one is really needed, please no suggestions for alternatives. ;-) ) > > (Also note: some things were inspired by the FindOpenSSL.cmake coming > with CMake 3.9). > > This works in general with one minor flaw. When building OpenSSL as > external project, I have to run the build twice, because find_library > and find_path obviously fail to find OpenSSL in the build tree before > it is built. I could set those paths by hand with a priori knowledge > were the OpenSSL build will put its output, but that seems like an > unelegant solution to me. > > Any hints on that topic? What I found on the web was basically things > from several years ago, I would appreciate a more modern CMake > approach with imported targets. ;-) > > Greets > Alex > > -- > /"\ ASCII RIBBON | »With the first link, the chain is forged. The first > \ / CAMPAIGN | speech censured, the first thought forbidden, the > X AGAINST | first freedom denied, chains us all irrevocably.« > / \ HTML MAIL | (Jean-Luc Picard, quoting Judge Aaron Satie) > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/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
