[Some clarifications below] On Tue, May 15, 2012 at 2:57 PM, Dominique Belhachemi <domi...@debian.org> wrote: > Hi Mathieu, > > It was my intention to remove that patch. I am not even sure if that > patch was working.
It was working. > I would say that we forget that patch and try to solve the problem > within cmake. vtk is not the only package suffering under the > multiarch/cmake issue. There are a couple of things to take into account: vtk 5.8.0 has been superseded by vtk 5.10.0 first of all. There is nothing really wrong within cmake. It is just a default behavior that is hard to work around. One of the right way of properly solving this would be to follow one of cmake team suggestion: http://bugs.debian.org/661676#10 However this suggestion is extremely difficult to handle in the general case. 1. Indeed cmake introspection system hide lots of implementation details and will properly search for all Qt* libs when one simply states -for example-: find_package(Qt4) The suggestion above only works in simple case (single library). However -tedious- manual setting libs by the maintainer (or any other automagic script) will solve all issues with multi-arches libs. 2. find_package() is actually more complex to handle. Indeed let's take the example of : find_package(MPI) This call to find_package() is not searching for a lib called MPI but for an implementation for MPI. Which can be openmpi, lam4 and/or mpich2. To some extend find_package(Java) has related issues. In this case the debian maintainer cannot explicitly use suggestion above. Indeed one has to rely on default cmake introspection system and in this case full path will be used. Because of the amount taken for #1, and freeze is close (mid-june as per last email) and because I do not know how to solve #2. I am going to re-introduce the old patch from #506992. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
