[Insight-users] Using ITK externally

[Neil Killeen]

Luis


On Mon, 16 Dec 2002, Luis Ibanez wrote:

> Hi Neil,
>
> Thanks for your comments on the building process.
>
> A) About the build/install process:
>
>    We are trying to further separate the demo-applications
>    from the actual ITK code. As you just noticed, having
>    the demo-application inside the ITK source tree leads
>    to confusion and sometimes encovers errors like missing
>    libraries on the link line.
>
>    We should probably have two separate build steps.
>    One for building just ITK, which comes down to the
>    "Code" directory. The built libraries and the headers
>    should be installed. This build process will not require
>    any of the external libraries (FLTK, VTK, OpenGL, GLUT...)
>    since ITK does not depend on them.
>
>    Then, a second pass in which the demo-applications and
>    the testing are built using the installed ITK. Here is
>    where external libraries will be needed, e.g. for supporting
>    GUI and visualization.
>
>    This is something Brad has been insisting on for some
>    time but we haven't paid enough attention...
>

this separation would be valuable.

naturally keep the ITK Testing build with the basic 'Code' build, but
the Examples which require external libraries could be usefully
built separately.

however, it would require the user to make a second 'cmake' pass
though, would it not, to configure the external libraries ?
This would leave the CMakeCache.txt file in a different state
to that from which the basic system was built and this is probably
not desirable. So some thought would need to go into the logistics.

>
> B) About the missing X11 libraries
>
>    X11 libraries are included directly by FindFLTK.cmake.
>    They should be in the link line of all the projects that
>    do include this CMake Module.
>
>    I wonder is this problem (of missing X11 libs) may be due
>    to your version of CMake. Could you please take a look at
>    the CMake/Modules/FindFLTK.cmake file and check if the
>    following lines are in there:
>
> > IF(UNIX)
> >   SET( FLTK_PLATFORM_DEPENDENT_LIBS ${CMAKE_X_LIBS}  -lm)
> > ENDIF(UNIX)
>

this does not exist in my version

>    and
>
> >   SET( FLTK_LIBRARIES ${FLTK_BASE_LIBRARY} ${FLTK_GL_LIBRARY}
> >     ${FLTK_FORMS_LIBRARY}  ${FLTK_IMAGES_LIBRARY} ${FLTK_PLATFORM_DEPENDENT_LIBS}
> >   )
>

this does except for the last PLATFORM_DEPENDENT bit


>    These lines set the "platform dependent" libraries for FLTK.
>    In windows they set wsock32 and comctl32. On Unix this set
>    the X11 libs as defined in the variable CMAKE_X_LIBS and the
>    math library "libm".
>
>    Please let us know what you find.
>
>

The version of cmake that i installed is 1.46, which I installed
from static tar balls.


> C) About the need of running CMake from the binary tree
>     instead of the source tree. The reason is (as you
>     already guessed) related with the need of building
>     diferent binary configurations by sharing the same
>     source tree.  you may notice for example that in
>     the dashboard there are machines building for:
>
>     - Borland 5.5
>     - Visual Studio 7
>     - Visual Studio 6
>
>     by sharing the same source tree.
>     The same happens in Linux where we build for gcc2.96,
>     gcc 3.02 and gcc3.2 in the same machine.
>
>     This versatility would have been impossible if CMake
>     stored the configuration on the source tree.
>


well.....

in the system that i have worked in for many years
(an astronomy environment called 'aips++'), we do exactly that !

we have one source tree, and many platforms.   The directory
structure looks like

data                       # Data
code                       # Code
docs                       # Documentation

linux_gnu                  # Binary trees; linux + gcc compiler
sun4sol_gnu                # solaris +  gcc compiler
sun4sol_ntv                # solaris + native compiler
irix_gnu

etc.  You can see we maintain both a platform and a compiler string in
the binary tree.   If you wish to maintain different flavours of
the same compiler (gcc 2.95.2, 3.1.1) you could also attach those
numbers to the compiler part of the path string.

The way it works, is that when you log in, an initialization script
is executed.  It works out what platform you are on (basically from
'uname' under Unix) and what compiler you are using (the latter you can
change if you wish).   This sets the  output location of any build
to be the appropriate path (and also the path for libraries and
executables if you are just a user.   The information is transmitted
around via environment variables I think.  I don't think there is any
hard coded configuration information except the root path of the source tree.

All the makefiles are stored in the source tree.  A developer
mirrors the source tree in his/her own workspace.  The only
difference is that the makefile in your own workspace, will
put the binaries you build into a location in your own personal
binary tree (but with the correct platform/compiler prefix).  As usual,
when you are satisifed with your development, you check your code in
and the next system build will deal with it.

This has the advantage that you work in one location, whether developing
code or building it.

I wondered if it was something to do with trying to handle Windows
builds (not Unix) that prevented this approach for you.  I really
don't know anything at all about WIndows in terms of the operating
system and how much flexibility it affords you.


>
> D) About regenerating only a subset of Makefiles with
>     CMake. This is actually pretty easy.
>

thanks for the comments on this.  i'll let you know hot it
goes when i give it a try.


cheers
Neil