[ITK-dev] installed ITK cannot be moved due to absolute path

Dženan Zukić dzenanz at gmail.com
Tue Dec 20 10:15:03 EST 2016


Hi Rashad,

one way to generate install tree in a different location is by
changing CMAKE_INSTALL_PREFIX in CMake, reconfiguring, regenerating
project, the building the INSTALL target. That should generate the install
tree in your desired location.

Regards,
Dženan

On Tue, Dec 20, 2016 at 4:48 AM, Rashad Kanavath <mohammedrashadkm at gmail.com
> wrote:

> Hello all,
>
> Is there a simple FindITK.cmake which can be used instead of config and
> targets cmake files?
>
> in my install tree, in ITKTargets-release.Cmake there exists absolute path
> for include and lib file.
>
> My install tree of ITK does not work on a different machine unless I copy
> them too exact same directory where I installed on machine.
>
> This goes against portability and it is cmake who is doing this work.
>
> Here is code in ITKTargets-release.cmake
>
> set_property(TARGET ITKMetaIO APPEND PROPERTY IMPORTED_CONFIGURATIONS
> RELEASE)
> set_target_properties(ITKMetaIO PROPERTIES
>   IMPORTED_IMPLIB_RELEASE "${_IMPORT_PREFIX}/lib/ITKMetaIO-4.10.lib"
>   IMPORTED_LINK_INTERFACE_LIBRARIES_RELEASE "C:/dashboard/otb/install_sb_
> x86/lib/zdll.lib;comctl32;wsock32"
>   IMPORTED_LOCATION_RELEASE "${_IMPORT_PREFIX}/bin/ITKMetaIO-4.10.dll"
>   )
>
> see the absolute path to C:/dashboard/otb/install_sb_x86/lib/zdll.lib
>
> so if on a different machine no matter where I copy these cmake files for
> ITK, I must have zdll.lib in C:/dashboard/otb/install_sb_x86/lib/
> and same goes for fftw, expat etc.. if enabled.
>
> A simple find_package searching for for include and headers is portable
> than config files. Right now even copying the files on same compiler won't
> work.
> But in reality there is no technical issues.
>
> Is anyone aware of a better way other than manually updating those
> absolute path to zdll.lib
>
> On Tue, May 24, 2016 at 1:21 AM, Matt McCormick <
> matt.mccormick at kitware.com> wrote:
>
>> Hi Rashad,
>>
>> It looks like MXE is configured to use system versions of EXPAT, HDF5,
>> JPEG, PNG, TIFF, and ZLIB:
>>
>>   https://github.com/mxe/mxe/blob/4135f9b1227ba56b92ceb8a98201
>> 6370ad5c8894/src/itk.mk#L28-L33
>>
>> USE_SYSTEM could be disabled for these libraries.
>>
>> Or, it may be possible for the module system to learn relative
>> locations of these libraries with ITK_USE_SYSTEM*. But, it would work
>> best if these projects were configured with CMake, create a
>> <project>Config.cmake or <project>-config.cmake file, and use relative
>> paths internally.
>>
>> HTH,
>> Matt
>>
>> On Tue, May 10, 2016 at 5:25 PM, Rashad Kanavath
>> <mohammedrashadkm at gmail.com> wrote:
>> >
>> >
>> > On Tue, May 10, 2016 at 10:50 PM, Dženan Zukić <dzenanz at gmail.com>
>> wrote:
>> >>
>> >> Hi Rashad,
>> >>
>> >> a few months ago relative paths were completely removed from CMake,
>> >> because they were never fully implemented. Have you followed
>> recommendations
>> >> from here for cross-compiling?
>> >
>> >
>> > Yes. indeed. I had updated the mxe/src/itk.mk for several versions of
>> ITK!
>> >
>> > Regarding relative path in cmake, I don't understand.  I didn't use
>> cmake
>> > specific REL_PATH.
>> >>
>> >>
>> >> As for integrating your changes into ITK, you should submit a patch
>> >> following the instructions here. If your changes don't break anything,
>> they
>> >> are likely to be integrated.
>> >
>> >
>> > issue here is a bit different. For all libitk* stuff the story ends
>> well.
>> > For thirdparties, zlib, expat etc.. it is good idea to put the full path
>> > because we don't know if they are in same install directory as ITK or
>> not.
>> > But this make the installed cmake modules non-portable even to a
>> different
>> > location on the same disk.
>> >
>> > Now if anyone want to provide a distributable setup of ITK. patch the
>> > generated cmake files with sed and then copy it. This is what I am doing
>> > right now!
>> > A simple not perfect solution is to have all thirdparties make
>> > <LIBRARY>_PREFIX variable inside the ITKConfig.cmake
>> >
>> > and for each library we use <LIBRARY>_PREFIX/include and
>> > <LIBRARY>_PREFIX/lib
>> >
>> >
>> > Another option is to avoid full path directly inside cmake module files
>> and
>> > put find_package() calls in the install tree.
>> >
>> > As these files are autogenerated by cmake, don't know what is possible.
>> >
>> >
>> >
>> >
>> >
>> >>
>> >> Regards,
>> >> Dženan
>> >>
>> >> On Mon, May 9, 2016 at 4:27 PM, Rashad Kanavath
>> >> <mohammedrashadkm at gmail.com> wrote:
>> >>>
>> >>> Hello all,
>> >>>
>> >>> I have some issue when copying ITK install directory to a different
>> >>> system. I agree this is not usual and may not appear on a linux
>> distro or
>> >>> windows.
>> >>>
>> >>> My requirement is bit different. I cross-compile ITK and then use the
>> >>> binaries on Windows. Using dll and headers are fine. But the
>> installed cmake
>> >>> files are a problem. They have absolute path in
>> ITK-4.8/Modules/*.cmake
>> >>> files. It is not in all .cmake files even though I put a wildcard
>> there..
>> >>>
>> >>> For a easy and quick workaround. I rely on mighty sed command to
>> insert
>> >>> something into installed cmake file.
>> >>>
>> >>> For example see this;
>> >>> lib/cmake/ITK-4.8/ITKTargets-release.cmake
>> >>>
>> >>> set(CMAKE_IMPORT_FILE_VERSION 1)
>> >>> set(LIB_INSTALL_PREFIX)
>> >>> get_filename_component(CURRENT_FILE_DIR "${CMAKE_CURRENT_LIST_FILE}"
>> >>> PATH)
>> >>> get_filename_component(LIB_INSTALL_PREFIX "${CURRENT_FILE_DIR}" PATH)
>> >>> get_filename_component(LIB_INSTALL_PREFIX "${LIB_INSTALL_PREFIX}"
>> PATH)
>> >>> get_filename_component(LIB_INSTALL_PREFIX "${LIB_INSTALL_PREFIX}"
>> PATH)
>> >>>
>> >>> and at last:
>> >>>
>> >>> $(SED) -i 's,$(PREFIX)/$(TARGET),\${LIB_INSTALL_PREFIX},g'
>> >>> 'lib/cmake/ITK-$(ITK_VER)/ITKTargets-release.cmake'
>> >>>
>> >>> I would like to have this patch inside the other .cmake files in the
>> >>> installation and avoid the sed commands during post-installation
>> >>>
>> >>> Here is the list of cmake files that needs this change.
>> >>> lib/cmake/ITK-4.8/ITKTargets-release.cmake
>> >>> lib/cmake/ITK-4.8/Modules/ITKZLIB.cmake
>> >>> lib/cmake/ITK-4.8/Modules/ITKExpat.cmake
>> >>> lib/cmake/ITK-4.8/Modules/ITKHDF5.cmake
>> >>> lib/cmake/ITK-4.8/Modules/ITKJPEG.cmake
>> >>> lib/cmake/ITK-4.8/Modules/ITKTIFF.cmake
>> >>> lib/cmake/ITK-4.8/Modules/ITKPNG.cmake
>> >>>
>> >>> So is it possible to make the change into future version of ITK?
>> >>>
>> >>> The major issue here is those cmake files are generated by cmake. Is
>> >>> there a way cmake could use relative path ?
>> >>>
>> >>>
>> >>> --
>> >>> Regards,
>> >>>    Rashad
>> >>>
>> >>> _______________________________________________
>> >>> Powered by www.kitware.com
>> >>>
>> >>> Visit other Kitware open-source projects at
>> >>> http://www.kitware.com/opensource/opensource.html
>> >>>
>> >>> Kitware offers ITK Training Courses, for more information visit:
>> >>> http://kitware.com/products/protraining.php
>> >>>
>> >>> Please keep messages on-topic and check the ITK FAQ at:
>> >>> http://www.itk.org/Wiki/ITK_FAQ
>> >>>
>> >>> Follow this link to subscribe/unsubscribe:
>> >>> http://public.kitware.com/mailman/listinfo/insight-developers
>> >>>
>> >>
>> >
>> >
>> >
>> > --
>> > Regards,
>> >    Rashad
>> >
>> > _______________________________________________
>> > Powered by www.kitware.com
>> >
>> > Visit other Kitware open-source projects at
>> > http://www.kitware.com/opensource/opensource.html
>> >
>> > Kitware offers ITK Training Courses, for more information visit:
>> > http://kitware.com/products/protraining.php
>> >
>> > Please keep messages on-topic and check the ITK FAQ at:
>> > http://www.itk.org/Wiki/ITK_FAQ
>> >
>> > Follow this link to subscribe/unsubscribe:
>> > http://public.kitware.com/mailman/listinfo/insight-developers
>> >
>>
>
>
>
> --
> Regards,
>    Rashad
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20161220/ed3f06aa/attachment.html>


More information about the Insight-developers mailing list