[Insight-users] ITK building twice?

[Steve M. Robbins]

Thanks, Brad!

On Mon, Aug 16, 2010 at 08:44:39AM -0400, Brad King wrote:
> On 07/31/2010 02:51 PM, Steve M. Robbins wrote:
> > I find that the sequence "cmake, make, make install" rebuilds ITK at
> > the "make install" step for some reason.  This doubles the build time
> > of an already-huge build.
> 
> FYI, you can bypass the second build with "make install/fast".
> This skips the install->all dependency.

OK, but ...

> > Has anyone else noticed this and/or found a cure?
> > 
> > I'm building on linux systems -- it's the Debian package builds which
> > occur on a dozen platforms.  The build is perhaps unusual in that I
> > use cswig wrapping for tcl, python, AND java.
> 
> Due to complex dependencies introduced by the cswig wrapping process,
> the build rules actually tell CMake to regenerate the build tree
> after the first build.  The second time around adds a bunch of
> dependencies that could not be computed the first time.

... is it safe to bypass the second build with "make install/fast"
or are the extra dependencies important?


> Many years
> ago when that approach was first written we did not have problems
> with building twice the first time,

I am using the sequence "cmake / make / make install".  It doesn't
build twice the first time "make" is invoked.  However, it does seem
to re-build EVERYTHING at the second "make" (i.e. "make install").


> but AFAIK that code has not been
> maintained much for years.  I would not be surprised if the second
> time CMake generates the build tree (from slightly changed input
> files) the build rules change enough to cause a rebuild.

It's a little hard to see what has changed.  In one instance, the
second build of ProcessUNIX.c simply adds a duplicate include
option: -I/usr/include/gdcm-2.0 appears twice.

Thanks,
-Steve

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: Digital signature
URL: <http://www.itk.org/pipermail/insight-users/attachments/20100816/66ac159f/attachment.pgp>