<div dir="ltr"><div>I think one issue is this:<br><br>> 2. If the configure is re-run, it regenerates configuration files.<br><br></div>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?<br>
<br>Pat<br><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Sep 16, 2013 at 11:03 AM, David Cole <span dir="ltr"><<a href="mailto:dlrdave@aol.com" target="_blank">dlrdave@aol.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If you don't want the update step to pull changes from the repository, then use:<br>
<br>
UPDATE_COMMAND ""<br>
<br>
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.<br>
<br>
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...")<br>
<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
Hope this helps,<br>
David<div class="HOEnZb"><div class="h5"><br>
<br>
--<br>
<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Please keep messages on-topic and check the CMake FAQ at: <a href="http://www.cmake.org/Wiki/CMake_FAQ" target="_blank">http://www.cmake.org/Wiki/<u></u>CMake_FAQ</a><br>
<br>
Kitware offers various services to support the CMake community. For more information on each offering, please visit:<br>
<br>
CMake Support: <a href="http://cmake.org/cmake/help/support.html" target="_blank">http://cmake.org/cmake/help/<u></u>support.html</a><br>
CMake Consulting: <a href="http://cmake.org/cmake/help/consulting.html" target="_blank">http://cmake.org/cmake/help/<u></u>consulting.html</a><br>
CMake Training Courses: <a href="http://cmake.org/cmake/help/training.html" target="_blank">http://cmake.org/cmake/help/<u></u>training.html</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/<u></u>opensource/opensource.html</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://www.cmake.org/mailman/listinfo/cmake" target="_blank">http://www.cmake.org/mailman/<u></u>listinfo/cmake</a><br>
</div></div></blockquote></div><br></div>