[Debian-med-packaging] Bug#635300: Workaround for the *LibraryDepends.cmake issue

[Michael Schutte]

tags 506992 + patch
tags 635300 + pending
thanks

Hi everyone,

Yesterday I found some time to dive into the problem with full .so paths
in VTK and ITK, which currently cause frequent FTBFSes because of more
and more libraries moving down the directory hierarchy for multiarch.  I
suggest this workaround for the issue:  In debian/rules, run

	sed -i -e "s#/usr/lib/\(`dpkg-architecture -qDEB_HOST_MULTIARCH`/\)\?lib\([^;]*\)\.so#\2#g" \
		$(path_to_library_depends)

after building.  While I haven’t found a way to avoid getting the
absolute paths in the first place, CMake does manage to find libraries
in default locations.  This isn’t pretty, but we can remove it again
after all required libraries are “multiarched” – particularly when VTK
and ITK undergo that transition themselves ;-)

The other fixes I tried, namely removing *LibraryDepends.cmake
altogether, and converting to another way to use CMake, sadly don’t work
satisfactorily.  The former breaks some builds, the latter is a lot of
work and doesn’t fix the problem completely.

This one should be a low-maintenance solution, and AFAICT it works out
fine.  I locally test-built ants, elastix, gdcm, ginkgocadx, gofigure2
and ifrit, all of which depend on libinsighttoolkit3-dev, libvtk5-dev or
both (there are more, but my machine is slow).  The fix for ITK is
committed and ready to upload.  For VTK, please try the attached patch.

Cheers,
-- 
Michael Schutte                   | michi@{uiae.at,debian.org}
Innsbruck, Austria                | happily accepting encrypted mail
OpenPGP: 0x16fb 517b a866 c3f6 8f11 1485 f3e4 122f 1D8C 261A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vtk-506992.patch
Type: text/x-diff
Size: 552 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/debian-med-packaging/attachments/20110816/e482bcdf/attachment.patch>