[CMake] ExternalProject vs add_subdirectory (was Re: SubProject configuration in same build as host)
kent williams
nkwmailinglists at gmail.com
Thu Apr 15 10:08:22 EDT 2010
There's a 'chicken-and-egg' problem with using ExternalProject in this
context: When you configure a project that uses ExternalProject_add,
that project won't be available to be found by FindPackage until AFTER
the project is built. But CMake will want to find it at Configuration
Time, and it will not yet exist.
The only way I know out of this 'chicken and egg' problem is to make
ParaView itself an ExternalProject that depends on HDF5.
ExternalProject is great and all, but this is rather an annoying
problem, because the most natural thing to do would be to add
ExternalProjects into the CMakeLists.txt for the projects upon which
they depend. To do this, ExternalProject would probably have to be
more than a Module.
You can probably finesse this by defining the variables defined by
e.g. UseHDF5.cmake based on where the ExternalProject will drop its
files when it's done building and installs.
Or maybe this would be a good thing to add to the ExternalProject
macro itself -- have it define the variables a project would need to
use the ExternalProject once it's built. Then at configure time, the
build system should be generated so that anything depending on an
ExternalProject should be built after it.
On Thu, Apr 15, 2010 at 5:57 AM, Dave Partyka <dave.partyka at kitware.com> wrote:
> Just thinking out loud but we could make an "external_project" call instead.
> This would sync, configure, build and install it easily without needing to
> override anything. And then ParaView would just FindPackage(HDF5) with the
> internal build directory as a hint.
>
More information about the CMake
mailing list