[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