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

[Gert Wollny]

Am Donnerstag, den 02.06.2016, 01:34 +0200 schrieb Peter Mattern:
> Thanks for your reply. But IMO it is missing the point.
> 
> But the problem addressed in this report is CMake returning faulty
> paths or  files that aren't available in the distribution at all
> besides they do belong to GDCM. Could you by any chance have another
> look at the paragraphs after the two  messages above?
> libvtkgdcmsharpglue.so *was installed* when cmake got invoked but
> wasn't  found as CMake didn't know the correct path. 

This is because the library is moved out of /usr/lib/ to a
gdcm specific path. It is not a library a third party is supposed to
link against. Locations for these packages are distribution specific,
because of this we cannot expect that upstream takes care of adjusting
the library path accordingly. At most they might consider in such cases
to not issue an entry in the cmake file at all, but most people use
cmake macros for library creation that would have to be adjusted for
each case and we can not expect that they think of this kind of
packaging issues that don't influence the functionality. 

> libvtkgdcmPython.so *isn't available at all* in 
> stretch besides it is basically part of GDCM. Apparently it was
> succeeded by  libvtkgdcmPython.x86_64-linux-gnu.so but
> again CMake just isn't aware of this.
Same thing here, the package creates the library without the arch
specific suffix, but because the package supports multi-arch the name
of the library must be changed (Python modules don't have an arch
specific path),  and one should also not link to this library directly
it is only relevant for the gdcm Python module. 

> And both shouldn't happen, should it?
Granted, it doesn't look nice, but it is really not that important. 

Best, 
Gert 

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

[Mathieu Malaterre]

On Thu, Jun 2, 2016 at 1:34 AM, Peter Mattern  wrote:
> Thanks for your reply. But IMO it is missing the point.

No, Gert is right. This pattern is common to a lot of cmake-based
package. One need to break the monolithic installation mechanism
(single cmake entry point) to make it match the desired behavior for
Debian (a cmake file per binary package).

Another possible hack is to s/WARNING/STATUS/ the cmake GDCM package
(VTK used to do that), so that user(s) wont complain.

-M

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

[Peter Mattern]

Thanks for your reply. But IMO it is missing the point.

Maybe we should first reconsider the workflow that takes place.
An application, here Ginkgo CADx, is sort of querying CMake like "Could you 
please tell
me which library is providing feature foo?" and CMake replies "Sure. It's 
library

/usr/lib/x86_64-linux-gnu/libFoo.so.".

Due to the sophisticated packaging in Debian it may very well happen that 
libFoo.so isn't
accessible right when cmake gets invoked simply as the package providing 
the library isn't

installed.
This is what I had in mind writing the "side note" in the initial posting 
and what you

were referring to in your reply.

But the problem addressed in this report is CMake returning faulty paths or 
files that aren't

available in the distribution at all besides they do belong to GDCM.
Could you by any chance have another look at the paragraphs after the two 
messages above?
libvtkgdcmsharpglue.so *was installed* when cmake got invoked but wasn't 
found as CMake didn't
know the correct path. libvtkgdcmPython.so *isn't available at all* in 
stretch besides it is
basically part of GDCM. Apparently it was succeeded by 
libvtkgdcmPython.x86_64-linux-gnu.so but

again CMake just isn't aware of this.
And both shouldn't happen, should it?

Bug#826048: [Debian-med-packaging] 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.