[CMake] ExternalProject_Add - Automatic Incremental Rebuilds + Add Sources to IDE
David Cole
dlrdave at aol.com
Wed Sep 18 11:51:34 EDT 2013
> Ideally, for these rapid co-development phases I would like to
> a) Be able to rebuild a project using ExternalProject_Add
> whenever any source file changes.
ExternalProject is not well suited for handling source level changes.
> b) Provide the mechanism for an IDE project to include all
> the sources from another project specified by
> ExternalProject_Add.
Because of my answer for "(a)", I still don't think it's a good idea.
> For b) there was a bug open and closed here,
> http://www.cmake.org/Bug/view.php?id=12322
>
> I understand David's point about making bad assumptions, but I would
> find it extremely useful if I was able to include the sources and
force a
> rebuild as I'm describing.
I understand, and many others would also find it useful, but I doubt it
can be done reliably. If somebody would like to prove me wrong, (on
Windows with all supported versions of Visual Studio, and on the Mac
with all versions of Xcode, and with Eclipse, and ...), I will gladly
reverse my opinion.
> Does anyone have any ideas? We're currently doing a lot of
refactoring on
> both repositories so removing as much development overhead will really
> help. When things get stable we will be using ExternalProject_Add on
> tagged revisions.
The best solution for rapid co-development of multiple repositories is
NOT to use ExternalProject. ExternalProject, as recently discussed in
another mailing list thread here, is best suited for building static
snapshots of repositories that do not change frequently.
Does everything build with CMake? Good. Then you can make something
like this work:
# CMakeLists.txt
cmake_minimum_required(VERSION 2.8.11)
project(GlueLibsAndApp)
add_subdirectory(libs)
add_subdirectory(app)
# Then, checkout the two separate repositories in "libs" and "app"
and boom: all your sources for everything are all in the generated IDE
project
You can structure the app CMakeLists such that it can reference the
libs as part of a big "build everything" tree like this, or as
something that has to be found with find_package, or as something you
just point to with CMake variables.
Then later on, you can create a super build that builds both libs and
app separately using ExternalProject, and have that app refer to the
libs built in that manner, rather than as targets in the same
CMakeLists directory structure.
The best approach I've seen for this sort of thing so far is being used
in the Open Cheimstry projects. They build and install everything as
part of a "super build" into a known installation prefix in the "super
build" build tree. Then, they use CMAKE_PREFIX_PATH and find_package to
find *previously* built/installed sub-projects in subsequent
sub-projects. Everything is built via ExternalProject there, but none
of the individual projects build anything with ExternalProject -- they
find everything with find_package. ( See their repos here:
https://github.com/OpenChemistry -- the super build is in:
https://github.com/OpenChemistry/openchemistry )
HTH,
David
More information about the CMake
mailing list