[Insight-users] [CMake] INSTALL(EXPORT)

[Luis Ibanez]

Hi Rupert,

If you have got this to work in your local build, please feel free
to commit the changes to ITK. In that way we can test them early
enough before the release of ITK 3.10.

Please note that currently we only have one build testing an
installed version of ITK. This is done by building the Testing
tree against a Nightly installed ITK.

It will be nice if you could submit another Nightly build of the
Testing tree against the installed ITK where you are using the
Release/Debug name variations.


When committing the changes, it will be ideal if you do it
early in the morning, so we have time during the day to clean
up any potential issues in the Dashboard.


   Thanks


      Luis


---------------------
Rupert Brooks wrote:
> Hi folks,
> 
> My apologies for cross-posting - I'm hoping this is of interest to the
> ITK list, and it continues a month-old conversation on the CMake list.
> 
> Recap:
> I like to have the debug and optimized versions of my ITK libraries
> have different names (e.g. ITKCommon.lib, ITKCommond.lib).  This way i
> can install them in the same place, and link against the appropriate
> one depending on my build type.  Unfortunately this isn't supported in
> the current out of the box ITK.  Heres a way I found to get it working
> - I hope it will help out a few people.
> 
> Its my understanding (from Brad King, see email chain further down)
> that this will be included in a later ITK release.  For the impatient,
> here is what I did.
> 
> Caveats:
> 1. I never got this to work so i could link against the build tree.
> It only works when installed.
> 2. I only build debug, and release, im not sure what happens if
> RelWithDebInfo is used, etc.
> 3. I tested on both Intel Windows XP 32 bit and Intel Linux 32 and 64
> bit, and so far so good.  It ought to work on other systems, but i
> didnt test.
> 4. This relies on the cleverness of the CMAKE Export scheme (Thanks
> Brad for pointing me to this).  I'm using CMake 2.6.1 - I THINK its
> supported in 2.4, but again, i didnt try.  Might be worth upgrading if
> your going to try it.
> 
> Briefly, the main CMakeLists.txt must be edited to add the option
> controlling the debug postfix, and to allow a new way of exporting the
> library dependencies.  Then each CMakeList must be edited to add an
> EXPORT command for every library created.
> 
> Then when building, I can merrily build and install both the debug and
> release versions and install them to the same path.   For a project
> that uses it, the CMakeLists.txt does a FindITK in the usual way - so
> theres no difference between building against an ITK modified like
> this, and the regular case.  Other than its easier to end up using the
> right library, of course.  This way if i release my project to someone
> who doesnt modify their ITK this way, it will still work for them.
> 
> Heres more details:
> 
> The main CMakeLists.txt file (in the Insight directory) must be edited
> as follows.  Lines that are changed are shown with **'s, others for
> context.   Dont actually put the **'s, obviously....
> 
> ==================================================================
> # If CMake is the version we're expecting, don't show the
> # CMAKE_BACKWARDS_COMPATIBILITY option. If the version is higher than the
> # minimal version required, then show the backward compatibility option.
> IF("${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION}" MATCHES "^2\\.4$")
>   MARK_AS_ADVANCED(FORCE CMAKE_BACKWARDS_COMPATIBILITY)
> ELSE("${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION}" MATCHES "^2\\.4$")
>   MARK_AS_ADVANCED(CLEAR CMAKE_BACKWARDS_COMPATIBILITY)
> ENDIF("${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION}" MATCHES "^2\\.4$")
> 
> 
> **#-----------------------------------------------------------------------------
> **# Option to add a debug postfix
> **OPTION(ITK_USE_DEBUG_POSTFIX "Append a d to names of debug libraries" OFF)
> **#MARK_AS_ADVANCED(USE_DEBUG_POSTFIX)
> **IF( ITK_USE_DEBUG_POSTFIX )
> **    SET(CMAKE_DEBUG_POSTFIX "d")
> **ENDIF( ITK_USE_DEBUG_POSTFIX )
> 
> ==================================================================
> and, further down, to write out a LibraryDependencies file.
> ==================================================================
> ENDIF(NOT ITK_INSTALL_NO_DEVELOPMENT)
> 
> **FILE(REMOVE ITKLibraryDepends.cmake)
> **  INSTALL(EXPORT Libraries
> **    DESTINATION ${ITK_INSTALL_PACKAGE_DIR_CM24}
> **    FILE ITKLibraryDepends.cmake
> **    )
> ==================================================================
> 
> Now EVERY CMakeLists.txt in the whole ITK tree must be modified so
> that any installed libraries get added to the "Libraries" export. This
> way the export command above knows about them, and they get written to
> the itkLibraryDepends.cmake.
> Example:
> 
>   INSTALL(TARGETS ITKAlgorithms
>     RUNTIME DESTINATION ${ITK_INSTALL_BIN_DIR_CM24} COMPONENT RuntimeLibraries
>     LIBRARY DESTINATION ${ITK_INSTALL_LIB_DIR_CM24} COMPONENT RuntimeLibraries
>     ARCHIVE DESTINATION ${ITK_INSTALL_LIB_DIR_CM24} COMPONENT Development)
> 
> becomes
> 
>     **INSTALL(TARGETS ITKAlgorithms EXPORT Libraries
>     RUNTIME DESTINATION ${ITK_INSTALL_BIN_DIR_CM24} COMPONENT RuntimeLibraries
>     LIBRARY DESTINATION ${ITK_INSTALL_LIB_DIR_CM24} COMPONENT RuntimeLibraries
>     ARCHIVE DESTINATION ${ITK_INSTALL_LIB_DIR_CM24} COMPONENT Development)
> 
> hope someone finds it useful.
> 
> Cheers,
> 
> Rupert B.
> 
> On Wed, Aug 13, 2008 at 11:41 AM, Rupert Brooks <rupe.brooks at gmail.com> wrote:
> 
>>Thanks Brad,
>>
>>I will either export them as i go, or store them in a variable, and
>>export that list at the end.
>>
>>
>>>FYI, I am planning to construct build-tree and install-tree export rules
>>>for upstream VTK and ITK once we require CMake 2.6.
>>
>>I guess I am impatient  ;-).  The reason that I am trying to do this
>>is that i use the CMAKE_DEBUG_POSTFIX option to have my debug
>>libraries coexist with the non-debug libraries.  This was pretty
>>important for development, but lead to all kinds of unmaintainable
>>hackery in my project CMakeLists to deal with it.   Now that im
>>sharing my code, i want a clean way for the USEItk.cmake to set up the
>>debug vs optimized library dependencies if they exist, and do it the
>>old way for "out of the box" ITK, so my collaborators dont run into
>>problems.
>>
>>I was planning to share whatever I came up with on the ITK List - i
>>think other people like the CMAKE_DEBUG_POSTFIX thing too.  I'll CC
>>here for sure.   I just want to get it pretty solid first, as i build
>>on a range of different systems.
>>
>>Cheers,
>>Rupert B.
>>
>>--
>>--------------------------------------------------------------
>>Rupert Brooks
>>McGill Centre for Intelligent Machines (www.cim.mcgill.ca)
>>Ph.D Student, Electrical and Computer Engineering
>>http://www.cyberus.ca/~rbrooks
>>
> 
> 
> 
>