[CMake] ExternalProject and redundant update/configure/compile actions.
David Cole
dlrdave at aol.com
Tue Sep 17 18:02:45 EDT 2013
> OK, yeah, I know about disabling updates. ....
Good.
> 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.
Also good. I agree wholeheartedly.
> And my reasoning was 'if you always request a specific tag, you never
need
> to have an update command.' ....
Sounds like sound reasoning to me.
> ... But then I was told to leave that be.
By somebody who shouldn't have interrupted your sound reasoning. ;-)
> 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.
Blowing everything away and starting from scratch is reasonable if you
are changing tags. I wouldn't trust an incremental rebuild of VTK from
5.10 to 6.0, or CMake from 2.8.8 to 2.8.11... Start from scratch if
that sort of thing happens.
> 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.
The super build is most useful for starting from nothing, and building
all the dependencies you need in one shot. To expect people to do more
than that with it is asking them to learn the abstruse, and to become
CMake experts themselves. A price that most people do not want to pay
just for using your super build.
If you can simplify, do so. If not, then it's as simple as it can be
already, and people who need to learn it, will. I wouldn't bend over
backwards to make things easy for them unless I knew who they were...
;-)
D
More information about the CMake
mailing list