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

[Jean-Christophe Fillion-Robin]

Some background about the Slicer build system that inspired the
NamicExternalProjects system discussed by Kent  ...

Before CMake 2.8.8, we disabled the UPDATE of external project because it
was not working well with Visual Studio. While this was working as
expected, the overall build time was also increased because it wasn't doing
an incremental rebuild.

As of today, we re-enabled the UPDATE part of external project and also
require CMake >= 2.8.9 and it works quite well. The overall build time is
largely decreased.




On Mon, Sep 16, 2013 at 1:24 PM, Williams, Norman K <
norman-k-williams at uiowa.edu> wrote:

> 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.
> ________________________________
> --
>
> 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
>



-- 
+1 919 869 8849
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20130916/81468d36/attachment-0001.htm>