I think one issue is this: > 2. If the configure is re-run, it regenerates configuration files.
For some projects, if you just update and run make, then nothing rebuilds and nothing reinstalls. But if you run cmake && make, then things rebuild and reinstall. So, maybe you *do* want to do an update, but then skip the re-configure. That is, configure once, the first time, then don't explicitly re-run cmake to unless the arguments to the configure step have changed. Would something like that work, Dave? Pat On Mon, Sep 16, 2013 at 11:03 AM, David Cole <dlrd...@aol.com> wrote: > If you don't want the update step to pull changes from the repository, > then use: > > UPDATE_COMMAND "" > > Otherwise, if you are building from a live repo, then the update step witl > ALWAYS run in case something has changed upstream. Then, all the subsequent > steps after update must also run just in case update pulled down some new > changes. > > That's the best ExternalProject can do in its present form. (Don't know > who you talked to that told you "things are better now," but maybe what he > meant was "there are other ways to do it that avoid that particular > problem...") > > > I can imagine that you might add a "there were 0 things pulled down during > update, please don't re-run subsequent steps", ... but still, if any single > file was added/modified/deleted, then we have no choice but to run > incremental configure/build/install steps after that. > > It's nice to have grand unified super builds, but dependency analysis for > ExternalProject is at the project level. For that reason, super builds are > really best suited to building static tarball snapshots, or "snapped to a > tag or date" repo snapshots that do not require an update step. > > I can't imagine you would possible want all 35 or so of your sub-projects > to be snapped to the live repos. Otherwise, you are depending on all of > them remaining stable in order for your developers to get a good build of > the whole system. Snapping to a known commit for most of them would seem to > me to be appropriate here. > > > Hope this helps, > David > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/**CMake_FAQ<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<http://cmake.org/cmake/help/support.html> > CMake Consulting: > http://cmake.org/cmake/help/**consulting.html<http://cmake.org/cmake/help/consulting.html> > CMake Training Courses: > http://cmake.org/cmake/help/**training.html<http://cmake.org/cmake/help/training.html> > > Visit other Kitware open-source projects at http://www.kitware.com/** > opensource/opensource.html<http://www.kitware.com/opensource/opensource.html> > > Follow this link to subscribe/unsubscribe: > http://www.cmake.org/mailman/**listinfo/cmake<http://www.cmake.org/mailman/listinfo/cmake> >
-- 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: http://www.cmake.org/mailman/listinfo/cmake
