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-willi...@uiowa.edu On 9/16/13 10: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 > ________________________________ 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. ________________________________ -- 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
