Re: New CamiTK 5.2.0 release

Dear Andreas,

Thank you very much for checking the package and uploading it.

>> Thank you very much for the explanation, the wiki update and the link to
>> routine-update, that will probably my saviour in the future!
> Routine-update is saving me a lot of time and I hope it will do so
> for others. ;-)
+1

>>> The repository has the line with "lib/x86_64-linux-gnu" while the
>>> downloaded tarball has only "lib".  If you really need to adapt the
>>> original tarball to some Debian specific things this needs to be done in
>>> a quilt patch.  Please also note:  This change only works for amd64
>>> architecture which currently is the only architecture where the Debian
>>> package is built.  However, this restriction is only due to the fact
>>> that libinsighttoolkit5-dev is only available for this architecture.  In
>>> case it might be available for other architectures as well your patch
>>> above will fail on those.
>> Understood. Now that the correct libDir variable is set back to just "lib",
>> the multiarch support should be taken into account directly in the
>> debian/rules.
>> The first instruction of the target override_dh_auto_configure target is:
>> sed -i 's+libDir = "lib";+libDir = "lib/$(DEB_HOST_MULTIARCH)";+g'
>> sdk/libraries/core/CamiTKVersion.h
> Just a general think I do not understand:  Why is it necessary that a
> header file knows about the location of the (shared/static?) library?
>> Which, from what I understand, should replace the libDir variable with the
>> specific architecture version, hopefully making it ready for when/if
>> libinsighttoolkit5-dev supports other architectures.
>> Let me know if that sounds correct for you.
> Using the correct lib dir on different architectures is probably the
> right way to support these architectures.  But its the first time I see
> that a header file needs to know the location of the lib.

I agree it is probably (very) unusual.
I created an issue upstream with a tentative explanation of the reason 
behind this [1] and in order to check if this (probable) technical debt 
inherited from the past cannot be simplified in the next version (please 
do not hesitate to comment, or suggest any idea).

Kind regards,
Emmanuel
[1] https://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/180