I see thanks, so install_dir has a different meaning than the eventual install dir of the external project, I thought there would be some ‘magic’ where the ExternalProject functions would override the the prefix of, in this case, project x.
I still have one issue, perhaps I should start a new thread, but here goes: The external project produces a library, how can I make that library a target, so that any executables in the main project who depend on the library from ‘x’ will not link before the library is compiled/available. Because I some instances if I have a parallelized build the following scenario can happen. 1) x is being built 1) an executable which depends on an library, libx, from ‘x’ is being built. 2) the executable proceeds to its linking phase, but needs libx, which is not there; build fails. 3) ‘x’ has now produced libx libx was produced too late. My current setup (which exhibits the above) is simply to deduce the complete path to the library and add it the executable target. Is there any way this can be fixed with custom targets or something related? On 13 Aug 2014, at 15:23, David Cole <dlrd...@aol.com> wrote: > See, for example: > > https://github.com/OpenChemistry/openchemistry/blob/master/CMakeLists.txt#L24 > > A common CMAKE_INSTALL_PREFIX is used for all OpenChemistry ExternalProject > builds that are driven by 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
