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

[Williams, Norman K]

OK, yeah, I know about disabling updates.  I don't remember who or when I
got the advice NOT to disable updates.

And all of the projects in our Super-Duper-build do get set to specific
SVN/GIT/CVS tags.  This is the only way
to get predictable behavior.

And my reasoning was 'if you always request a specific tag, you never need
to have an update command.' But then I was told to leave that be.

The only rationale for always updating is that if you change the tag to
download, it will re-download the source, and rebuild with the new source.
If you disable update then you'll have to delete the files down in
<PRJ>-prefix/src/<PRJ>-stamp to retrigger a download.

Or do what I generally do and delete the source, build, AND prefix
directories.

All of this starts out as 'expert-level CMAKE hacking' and gets
progressively more abstruse as I go along. I keep trying to think of how
to simplify it for people who want to build and use applications using the
SuperBuild. Not sure who they are, or if I really should try and bend over
backwards to make things easy for them.

--
Kent Williams norman-k-williams at uiowa.edu






On 9/16/13 10: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
>



________________________________
Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged.  If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited.  Please reply to the sender that you have received the message in error, then delete it.  Thank you.
________________________________