Thanks for the clarifications.
So things sped up because now you're getting incremental builds,
whereas before, you would have to force full builds when the tag
changed. That makes sense.
I guess I shouldn't be... but I'm always surprised that people even
attempt incremental rebuilds of larg
Hi David,
I should have specify the context ...
..for example, in the case you change the SHA1 associated with your
external project. If update is disabled, doing a full rebuild will take
longer than simply doing an update + incremental build. Especially if
other projects depend on the fully re
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 al
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 ta
Agreed, but right now ExternalProject is my favorite solution to this
problem. I prefer the ExternalProject approach over the ParaView +
internal VTK / git-submodule approach. So I'm just looking for ways to
alter ExternalProject to be a little nicer to my workflow, which is
incremental builds of
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
It *could* work, depending on the project.
I wouldn't do it.
But it *could* work.
--
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
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 upd
On 2013-09-16 17:24- Williams, Norman K 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
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
Agreed, but right now ExternalProject is my favorite solution to
this problem. I prefer the ExternalProject approach over the
ParaView + internal VTK / git-submodule approach. So I'm
just looking for ways to alter ExternalProject to be a little nicer
to my workflow, which is incremental builds o
... then the project never rebuilds, since reconfigure and rebuild
depend on update.
So if you modify a source file of a project without a download
command, then
superbuild will not rebuild the project.
Ahem. "If you modify a source file of a project" then *you* should
rebuild the project.
There's a related issue, I think, if you skip the update step, then the
project never rebuilds, since reconfigure and rebuild depend on update. So
if you modify a source file of a project without a download command, then
superbuild will not rebuild the project. So my workaround (used in VES,
for
This has to do with a project we've been working on for a couple of
months; it is a 'grand unified build' system for the Image Processing we
(and probably many others) use for our production image analysis.
You can check it out/examine it here:
https://github.com/BRAINSia/NamicExternalProjects
Cu
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
15 matches
Mail list logo
