[Debian-med-packaging] Bug#826048: Bug#826048: Faulty CMake file impairs compiling against GDCM

[Gert Wollny]

Control: tags -1 wontfix 

Hello Peter, 

Am Mittwoch, den 01.06.2016, 22:49 +0200 schrieb Peter Mattern:
> Source: gdcm
> Version: 2.6.3-{6,5}
> Severity: important
> 
> Compiling recent Ginkgo CADx against GDCM on Debian stretch yields
> two cmake warnings which
> suggest there are corresponding errors in the packaging of GDCM.
> 
> > 
> > -- The imported target "vtkgdcmsharpglue" references the file
> >   "/usr/lib/x86_64-linux-gnu/libvtkgdcmsharpglue.so"
> > but this file does not exist.  Possible reasons include:
> > 
> > 

This is to be expected. The problem is that gdcm references all
libraries within this cmake file, also those that may not be needed to
compile and link a program - e.g. Ginkgo doesn't need sharp or java
bindings related libraries. 

> The reason to assume it's a packaging issue in Debian is the fact
> that the warning messages can not be seen when the same Ginkgo CADx
> checkout gets compiled against the same GDCM version on Arch Linux
> where packaging does not involve any tweaking of GDCM's paths.

AFAIK unlike in Debian, where we separate the original software into
different packages like -dev, -java, -cli, Arch Linux only provides one
package that contains everything that is build. Therefore, if something
is referenced in the according CMake file, then it is also installed. 

Since in Debian the libraries are separated into different packages one
solution to get cmake run without warnings would be to split the cmake-
targets file accordingly, and the other would be to always pull in all
library packages with the -dev package. The first one is an upstream
decision. We could do the latter, but usually this doesn't make much
sense, because for using GDCM with Java, Mono, or Python the -dev
package is not needed, and for compiling C++ code against GDCM the
language bindings are not needed. 

> Just saying as I'm not sure whether it's alright to not have those
> files at hand by default.
It is completely alright as long as the dependent package does not
FTBFS. In fact you will see similar messages by other packages that use
CMake as build tool and provide these *target.cmake files (e.g. VTK).


Best, 
Gert

PS: I leave this open as wontfix because it is a common gotcha that
other might stumble upon.