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

[Bill Hoffman]

OK, it is a bit more complicated than just changing it from INTERNAL to STATIC.
That variable is used in two ways:

1. to be able to jump into a directory and build a missing library.
2. To add a -L path IF the LIBRARY_OUTPUT_PATH is not set.   


So, for 1, it has to point to the directory where the library is built.
However, for 2, if you could load this from a cache you would want this
to be either the directory of build, or the LIBRARY_OUTPUT_PATH (because
checking if LIBRARY_OUTPUT_PATH is set for the current project would not
tell you anything about the project you just loaded.)
So, I think that the change is too much for cmake 1.4.x.   However, it
is now on the board for cmake 1.6.

For VXL, I would think that this is the best option:
- force the vxl tree to use LIBRARY_OUTPUT_PATH and do a
  LINK_DIRECTORIES to that.

We have done that for VTK now.   And for VXL, it actually would be a good thing
to do, not just for this problem.   Since there are so many directories in
vxl, if you had a project that used them all, the -R, and -L path options to
the compiler could get VERY VERY long, and possibly break some limitations in
compilers and shells.   With the single directory for executables and libraries, it
would shrink the link lines for all vxl projects.   Also, if you every get around
to adding support for DLL's on windows, you will want to do this because there
is no -rpath or -R for windows, the only thing you have is the shells PATH, and
you will want all the DLL's and EXE's to be in one place so they can run without
adding 100 directories to your PATH.

-Bill




At 10:31 PM 7/30/2002 -0400, Amitha Perera wrote:
>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.
>_______________________________________________
>Cmake mailing list
>Cmake at public.kitware.com
>http://public.kitware.com/mailman/listinfo/cmake