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?
