[CMake] ExternalProject and redundant update/configure/compile actions.

[Pat Marion]

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 <dlrdave at 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>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20130916/c4ab733a/attachment.htm>