[Cmake] RE: [Vxl-maintainers] RE: [Dart] using cp for the drop box

[Miller, James V (Research)]

I guess I would counter that this is not so much an argument against
separate source trees but an argument against having 100s of
libraries.

In my view of the universe, any given software toolkit only needs about
7 to 10 libraries (I would actually prefer having fewer libraries).
Anything over that and you run two risks.  First, nobody can keep track
of where anything is or where something new should go.  Second, it
becomes exponentially hard to keep the libraries partitioned such that
they all do not end up depending on each other.

Let's take another view of the problem.  Suppose that vxl could build
DLLs. If a given project does not have to list all the libraries that 
it depends on (because CMake does this for you automatically), how do
you know what libraries you need to distribute with an executable?
I personally only want to send my customers the minimal set of libraries
associated with an application. So I either have to hunt and peck
what the library dependencies are when I distribute the software or I 
can hunt and peck what the library dependencies are at compile time.
I guess that if CMake is doing this automatically one could dig through
the CMakeCache to find these.

What does "IF(LIBRARY_OUTPUT_PATH MATCHES "^$")" do? Whose
LIBRARY_OUTPUT_PATH are we talking about? vxl's? or a project that uses
vxl?




-----Original Message-----
From: Amitha Perera [mailto:perera at cs.rpi.edu]
Sent: Tuesday, July 30, 2002 10:31 PM
To: Miller, James V (Research)
Cc: vxl-maintainers at lists.sourceforge.net; cmake at public.kitware.com
Subject: Re: [Vxl-maintainers] RE: [Dart] using cp for the drop box


You comment about needing to specify all the LINK_DIRECTORIES brings
up a (to me) big disadvantage of building outside the tree: loss of
information. When building with the main vxl tree, paths to the
libraries (and hence LINK_DIRECTORIES) commands are unnecessary, since
CMake knows where the libraries are, and will supply the appropriate
path. This works correctly regardless of whether LIBRARY_OUTPUT_PATH
is set or not. Now, if you do explicit LINK_DIRECTORIES, then you have
to have the ugly "IF(LIBRARY_OUTPUT_PATH MATCHES "^$")" stuff.

CMake gathers its knowledge from the internal variables named after
libraries which contain path information. But, these variables are
INTERNAL, and hence won't pass through the LOAD_CACHE command. If they
were STATIC, like the dependency information, all would (probably) be
well. I'm guessing that making these variables STATIC is not an option
for CMake 1.4.x, so moving to a separate build tree implies choosing
between different levels of ugly:
- list all the 100s of path-carrying variables explicitly.
- list all the 100s of directories in which a library *could* be.
- force the vxl tree to use LIBRARY_OUTPUT_PATH and do a
  LINK_DIRECTORIES to that.

As you observed, there will no longer be any CMakeListsLink files to
do the magic for us, so the user is responsible for this, and also for
tracking changes in the vxl tree. Not good.

As it stands (will stand on Monday), if I need to link against vnl, I
can just TARGET_LINK_LIBRARIES( myexec vnl ), and that's it. If vnl
later required libraries super_vec_arith, which is built in
v3p/add_on_libs, I don't need to know. I don't need to specify the
dependency, I don't need to add a new directory to the search path.

Given all this, and given that it would be nice to build internal
projects indepdently of vxl, perhaps the CMake powers that be could
consider making the path information STATIC in version 1.4p2?

Amitha.


[For context on Jim's message below, see the very bottom of this email.]

On Tue, Jul 30, 2002 at 03:40:22PM -0400, Miller, James V (Research) wrote:
> There are a few steps to this:
> 
> You should probably have a FindVXL.cmake module.  For a quick and 
> dirty test I just modified the FindVTK.cmake module.
> 
> In the vxl source tree, I would have two files UseVXL.cmake and
> perhaps vxlCMakeOptions.cmake.
> 
> UseVXL.cmake basically "loads" the vxl CMakeCache into the current project
> excluding any components of the cache that are not useful for other 
> projects (you can look at the UseVTK.cmake file to see the types of 
> things to exclude when importing the cache). 
> 
> vxlCMakeOptions.cmake defines all the INCLUDE_DIRECTORIES and LINK_DIRECTORIES commands that a
> project would need to use vxl.
> 
> In ITK, I put together an example in Insight/Examples/SampleProject that
> illustrates how to put together a program that uses ITK as opposed to 
> being inside the ITK checkout.  Basically, you copy the SampleProject
> directory to somewhere outside the source tree. Run CMake on the
> SampleProject.  One of the cache entries is "where is ITK binary directory".
> Once the ITK binary directory is defined, SampleProject will build 
> against that ITK source and binary directory.
> 
> I just put together a project to build against vxl today. I had some
> problems with vxl CMakeListLinks.txt files (which I think you are 
> trying to remove).  The problem I has was that despite including all the CMakeListLinks.txt files,
I
> still needed to specify all the LINK_DIRECTORIES.
> 
> Here is the toplevel CMakeLists.txt file for that project (names
> changed to protect the innocent).
> 
> 
> # ./Garf/CMakeLists.txt
> PROJECT(garf)
> 
> 
> # Add VXL code here (most of this should be put in a FindVXL.cmake module)
> #
> INCLUDE( ${garf_SOURCE_DIR}/Modules/FindVXL.cmake )
> 
> IF (allvxl_BINARY_PATH)
>   LOAD_CACHE(${allvxl_BINARY_PATH} 
>     EXCLUDE
>       BUILD_DOCUMENTATION
>       BUILD_SHARED_LIBS
>       BUILD_TESTING
>       BUILD_EXAMPLES
>       DOCUMENTATION_HTML_HELP
>       DOCUMENTATION_HTML_TARZ
>       LIBRARY_OUTPUT_PATH
>       EXECUTABLE_OUTPUT_PATH
>       MAKECOMMAND 
>       SITE
>       BUILDNAME
>       allvxl_BINARY_PATH
>       USE_VXL_FILE 
>       CVS_UPDATE_OPTIONS
>     INCLUDE_INTERNALS
>       allvxl_BINARY_DIR
>       allvxl_BUILD_SHARED_LIBS
>       allvxl_LIBRARY_PATH
>       allvxl_EXECUTABLE_PATH
>     )
> #    INCLUDE (${allvxl_SOURCE_DIR}/vxlCMakeOptions.cmake)
>   LINK_DIRECTORIES(${allvxl_LIBRARY_PATH})
> ENDIF (allvxl_BINARY_PATH)
> 
> 
> # Garf libraries and executables
> #
> ADD_LIBRARY( garf garf_sources )
> ADD_EXECUTABLE( garf_fit garf_fit.cxx )
> TARGET_LINK_LIBRARIES(garf_fit garf)
> 
> SOURCE_FILES( garf_sources
>   garf_regression.cxx
> )
> 
> AUX_SOURCE_DIRECTORY( Templates garf_sources )
> 
> IF (WIN32)
>   IF (NOT CYGWIN)
>     INCLUDE(${garf_SOURCE_DIR}/CMakeListsHeaders.txt)
>   ENDIF (NOT CYGWIN)
> ENDIF(WIN32)
> 
> 
> INCLUDE_DIRECTORIES( ${garf_SOURCE_DIR} )
> 
> INCLUDE_DIRECTORIES( ${allvxl_SOURCE_DIR}/vcl )
> IF(WIN32)
>   INCLUDE_DIRECTORIES( ${allvxl_SOURCE_DIR}/vcl/config.win32-vc60 )
> ENDIF(WIN32)
> 
> INCLUDE_DIRECTORIES( ${allvxl_SOURCE_DIR}/vxl )
> INCLUDE_DIRECTORIES( ${allvxl_SOURCE_DIR}/mul )
> INCLUDE_DIRECTORIES( ${allvxl_SOURCE_DIR}/gel )
> INCLUDE_DIRECTORIES( ${allvxl_SOURCE_DIR}/rpl )
> 
> INCLUDE( ${allvxl_SOURCE_DIR}/config.cmake/Modules/FindNetlib.cmake )
> INCLUDE( ${allvxl_SOURCE_DIR}/v3p/netlib/CMakeListsLink.txt )
> INCLUDE( ${allvxl_SOURCE_DIR}/vxl/vnl/algo/CMakeListsLink.txt )
> INCLUDE( ${allvxl_SOURCE_DIR}/vxl/vnl/CMakeListsLink.txt )
> INCLUDE( ${allvxl_SOURCE_DIR}/vxl/vbl/CMakeListsLink.txt )
> INCLUDE( ${allvxl_SOURCE_DIR}/vxl/vgl/CMakeListsLink.txt )
> INCLUDE( ${allvxl_SOURCE_DIR}/gel/vsol/CMakeListsLink.txt )
> INCLUDE( ${allvxl_SOURCE_DIR}/mul/mbl/CMakeListsLink.txt )
> INCLUDE( ${allvxl_SOURCE_DIR}/rpl/rrel/CMakeListsLink.txt )
> 
> # why do I have to do this explictly? shouldn't these be in 
> # the various CMakeListsLink.txt files?
> LINK_DIRECTORIES( ${allvxl_BINARY_DIR}/vcl )
> LINK_DIRECTORIES( ${allvxl_BINARY_DIR}/v3p/netlib )
> LINK_DIRECTORIES( ${allvxl_BINARY_DIR}/vxl/vnl )
> LINK_DIRECTORIES( ${allvxl_BINARY_DIR}/vxl/vnl/algo )
> LINK_DIRECTORIES( ${allvxl_BINARY_DIR}/vxl/vnl/io )
> LINK_DIRECTORIES( ${allvxl_BINARY_DIR}/vxl/vbl )
> LINK_DIRECTORIES( ${allvxl_BINARY_DIR}/vxl/vgl )
> LINK_DIRECTORIES( ${allvxl_BINARY_DIR}/vxl/vgl/algo )
> LINK_DIRECTORIES( ${allvxl_BINARY_DIR}/vxl/vgl/io )
> LINK_DIRECTORIES( ${allvxl_BINARY_DIR}/vxl/vul )
> LINK_DIRECTORIES( ${allvxl_BINARY_DIR}/vxl/vsl )
> LINK_DIRECTORIES( ${allvxl_BINARY_DIR}/gel/vsol )
> LINK_DIRECTORIES( ${allvxl_BINARY_DIR}/mul/mbl )
> LINK_DIRECTORIES( ${allvxl_BINARY_DIR}/rpl/rrel )
> 
> 
> SET (LIBRARY_OUTPUT_PATH ${garf_BINARY_DIR}/bin/ CACHE PATH "Single output directory for building
all
> libraries.")
> SET (EXECUTABLE_OUTPUT_PATH ${garf_BINARY_DIR}/bin/ CACHE PATH "Single output directory for
building
> all executables.")
> MARK_AS_ADVANCED(LIBRARY_OUTPUT_PATH EXECUTABLE_OUTPUT_PATH)
> 
> IF( BUILD_TESTING )
>   SUBDIRS(tests)
> ENDIF( BUILD_TESTING )
> 
> 
> From: Amitha Perera [mailto:perera at cs.rpi.edu]
> Sent: Tuesday, July 30, 2002 3:07 PM
> To: Miller, James V (Research)
> Cc: Vxl-Maintainers (E-mail)
> Subject: Re: [Vxl-maintainers] RE: [Dart] using cp for the drop box
> 
> 
> On Tue, Jul 30, 2002 at 11:16:43AM -0400, Miller, James V (Research) wrote:
> > What we have done for VTK, is that we again have a separate repository
> > for our internal code, in this case called GEVTK.  But we always check
> > out the GEVTK code to be parallel to the VTK code (as opposed to being 
> > inside the VTK checkout).  We have a separate CMake build structure for 
> > GEVTK but the GEVTK build process has to pointed at a VTK source tree and a
> > VTK build tree. The GEVTK build process actually loads the cache from the
> > VTK build tree in order to get consistent compiler settings and so the 
> > GEVTK build process knows what options were set in the VTK build process.
> 
> This sounds like a good idea. Is there any documentation on how this
> should be done? Otherwise, could you let us know the basic steps
> involved, and any issues that we should be aware of? I'd like to try
> it out, and perhaps write up some text on how this would be done.
> 
> Currently, we at RPI are doing the dual dashboard thing, and it is a
> pain to maintain. Not to mention that I compile vxl twice every night,
> once for each dashboard.
> 
> Amitha.