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

Rashad Kanavath mohammedrashadkm at gmail.com
Wed Dec 21 12:05:54 EST 2016 

On Wed, Dec 21, 2016 at 5:06 PM, Matt McCormick <matt.mccormick at kitware.com>
wrote:

> Hi Rashad,
>
> The Find<Package>.cmake are purposely not provided because it is not
> reliable and does not provide all the information required. The CMake
> package configuration file allows ITK to declare what is required to
> build it instead of requiring CMake to guess (and get it wrong).
>
> For this case, it is recommended to turn off ITK_USE_SYSTEM_ZLIB,
> which will make the ITK installation portable.
>

I need to use zlib, fftw and expat in that case from ITK build/

But I have also providing a different build of zlib for my other projects.

What are the missing information when using FindITK.cmake as opposed to itk
cmake configuration files?

I understand that saving absolute path of libraries which link with project
is easy to avoid any issues in linking or at runtime.
 And that is one type of solution and IMHO does not solve the problem.

Apart from that I would like to find out what are real issues with
Find<Package>.cmake



> HTH,
> Matt
>
> On Wed, Dec 21, 2016 at 9:03 AM, Rashad Kanavath
> <mohammedrashadkm at gmail.com> wrote:
> > Hello Dženan,
> >
> > Thanks for your reply.  Unfortunately, this won't work in my case. I will
> > try to explain it.
> >
> > I have installed itk in my system say: c:/projects/itk_install
> >
> > now I copy itk_install directory to another system of my colleague. If
> > he/she is copying my "itk_install" folder into any directory other than
> > c:/projects/, itk build is useless.
> > cmake says it cannot find file c:/projects/itk_install/lib/ITKxxxxx.dll
> > etc..
> >
> > This error is coming from
> > c:/projects/itk_install/lib/cmake/ITK-4.10/ITKTargets-release.cmake.
> Note
> > that this file is generated by cmake.
> >
> > So I have two options:
> > 1. ask to copy "itk_install" directory to c:/projects/itk_install (easy,
> )
> > 2. copy "itk_install" directory anywhere but search in
> > <your-install-prefix>/lib/cmake/ITK-4.10 and replace all occurrence of
> > c:/projects/itk_install with <your-install-prefix>
> >
> > Second solution is more awful compared to first. So for now, I insist on
> > first option. But after a couple of such installation of "itk_install",
> it
> > seems bad to me.
> > Like I mentioned in last thread, technically my itk_install could be
> reused
> > if cmake does not have absolute path in the install tree for ZLIB, fftw
> > etc..
> >
> > FYI, there are other projects which does same thing and for them I have a
> > custom Find<Package>.cmake in source tree. So don't care what ever they
> have
> > in their lib/cmake/<Package> files
> >
> > If ITK devs can provide FindITK.cmake , then we could reuse that.
> Instead of
> > ITKConfig.cmake stuff.
> >
> > Hope I explained case well. Let me know if you need any more information.
> >
> > Appreciate your help in solving this.
> >
> >
> > On Tue, Dec 20, 2016 at 4:15 PM, Dženan Zukić <dzenanz at gmail.com> wrote:
> >>
> >> 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/4135f9b1227ba56b92ceb8a9820163
> 70ad5c8894/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
> >>
> >>
> >
> >
> >
> > --
> > Regards,
> >    Rashad
>



-- 
Regards,
   Rashad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20161221/ce57e4e3/attachment.html>

More information about the Insight-developers mailing list