Parent component options passed to ExternalProject

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Parent component options passed to ExternalProject

Dustyn Blasig
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    [hidden email]: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, 

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.

Thanks!


--

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
Reply | Threaded
Open this post in threaded view
|

Re: Parent component options passed to ExternalProject

Craig Scott-3


On Tue, Mar 26, 2019 at 4:02 AM Dustyn Blasig <[hidden email]> 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    [hidden email]: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

Get the hand-book for every CMake user: Professional CMake: A Practical Guide

--

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
Reply | Threaded
Open this post in threaded view
|

Re: Parent component options passed to ExternalProject

Dustyn Blasig
Thanks for the help, I will give the FetchContent approach a shot and see how things go. I was actually in the process of trying to do a custom command using the built-in "cmake -E tar xvf" approach to roll a custom FetchContent that doesn't need such a new CMake, but I can't get it to work with zip files even though it seems like it should at this point. I'm hoping the fetch and include as subdirectory will be a more stable approach.

On Tue, Mar 26, 2019 at 4:39 PM Craig Scott <[hidden email]> wrote:


On Tue, Mar 26, 2019 at 4:02 AM Dustyn Blasig <[hidden email]> 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    [hidden email]: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

Get the hand-book for every CMake user: Professional CMake: A Practical Guide

--

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