[CMake] Parent component options passed to ExternalProject

Craig Scott craig.scott at crascit.com
Tue Mar 26 17:39:11 EDT 2019


On Tue, Mar 26, 2019 at 4:02 AM Dustyn Blasig <dustyn at blasig.us> wrote:

> Hi All,
>
> I'm really struggling to use ExternalProject_Add() in our CMake project.
>
> Based on the documentation, I was expecting the simplest Git-based
> external project with all defaults to act just like using a Git submodule
> locked at a specific commit.
>
> include(ExternalProject)ExternalProject_Add(foobar  GIT_REPOSITORY    git at github.com:FooCo/FooBar.git  GIT_TAG           origin/release/1.2.3)
>
> The documentation states "The default configure command runs CMake with
> options based on the main project.", so I was expecting any options we pass
> to the owning project such as CMAKE_INSTALL_PREFIX and other variables
> would get propagated to the ExternalProject. However, that doesn't seem to
> be the case. Do I need to explicitly apply every variable through the
> "CMAKE_ARGS" options? If so,
>

Some basic details are passed down to the external project, but I don't
recall exactly which variables. I don't think there are a lot of them and I
do tend to find that I need to pass down some vars in my own projects. You
may have to dig into the ExternalProject module's source to get
confirmation for yourself, possibly also look into what the
external_process() command's implementation does as well.



> Also, unless I specify a custom CONFIGURE_COMMAND, I can't figure out how
> to make the configure step happen during the parent projects configure
> step. Should that be happening? If not, is there a simple way to force it
> to happen without having to duplicate everything the default options do?
> I'm seeing mixed results with online resources, along with many older
> examples that just don't work anymore.
>

The external project's configure step happens during the main project's
build stage, just like every other step of ExternalProject_Add(). This will
be the case whether you override the CONFIGURE_COMMAND or not. If you
really need the configure step to occur during the main project's configure
stage, then you have at least a couple of options:

   - Consider using the FetchContent module instead and bring the external
   project into your main build directly. If this suits your scenario, then
   I'd recommend this method. I use this a lot and it seems to be growing in
   popularity. It requires CMake 3.11 or later.
   - Go for a pure superbuild approach where your main project does nothing
   more than call various ExternalProject functions to tie together different
   external projects (i.e. your main project doesn't add any targets, etc. of
   its own). This will mean that even though the configure steps all occur
   during the main project's build step, you can control the dependencies
   between the different external projects' steps so that they can find what
   they need from each other (I'm guessing here that you want the external
   project's configure stage to run during your main project's build stage so
   that something later in your main project's configure stage can make use of
   something the external project's configure stage does). You will still have
   to explicitly specify a number of variables to be passed through to each
   external project's configure stage though, so maybe this doesn't solve the
   problem you are facing.


-- 
Craig Scott
Melbourne, Australia
https://crascit.com

Get the hand-book for every CMake user: Professional CMake: A Practical
Guide <https://crascit.com/professional-cmake/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190327/90b381c5/attachment.html>


More information about the CMake mailing list