On Thu, Sep 17, 2009 at 1:26 PM, Modestas Vainius <[email protected]> wrote: >> > Secondly, fixing #544674 bug will NOT fix #545335. Current FindJNI.cmake >> > refers to $JAVA_HOME/ppc in the search path as it is supposed to >> > (according to openjdk-6-jre-headless package). >> >> There is no convention AFAIK. So unless you inspect all of them you >> will *not* find libjawt.so. > > Well, I've found how openjdk determines its libarch dir and mostly have proper > cmake code for it.
Excellent. How about all the other ones ? http://packages.debian.org/search?suite=sid&searchon=contents&keywords=libjawt.so >> That's just wrong. cmake is doing system inspection. This was written >> by someone not knowing the cmake enough. > > That's a workaround for broken FindJNI, it could be improved a bit to exclude > i386,amd64,powerpc where FindJNI does its job well. Well FindJNI is an interface, it should work regardless of CPU/ARCH. >> You missed earlier discussion, I do not know why Maitland push the >> issue over to you without the full discussion thread. If you look back >> in the history reverting the change will also break in other way. >> So in summary: you have to do system inspection because no DEB_*_ARCH >> / DEB_*_CPU will work on all combination of java package provider for >> libjawt.so > > I know I have to do it. And I will. Just don't push this as critical bug which > holds testing migration. It does not. All you have to do is to patch up vtk > packaging a bit. It is broken anyway. True. >> I can understand that you would prefer another solution (I also >> personnaly do), but for the time being there is no convention for >> debian package providing libjawt.so and symlinks are not always >> provided. > > So you just added Debian arches. What about linux arches debian does not > support? I'm trying to think about broader issue here. Correct it will fails miserably. I just do not know how to deal with that in a portable manner. I haven't found any documentation that describe where libjawt.so should be located. >> I'd really see VTK / ITK / Slicer / GDCM being considered for testing >> for such a small issue that is so deeply burried in cmake internals. >> >> cmake will soon be released so this patch will be integrated anyway. > > The point is vtk NEEDS sourceful upload even if I fix FindJNI. Please don't > put it like cmake is blocking something here. Just exclude i386,amd64,powerpc > in vtk debian/rules for the time being to get quick resolution. Well the patch you describe in your other mail: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=544674#68 has just been applied upstream (thanks to Denis Barbier), it took *several* round to get it right (Denis, Berk, Jeff, Brad and I did work on that patch). I doubt anyone will actually spent the time to integrate this large patch to VTK 5.2 since it is so old. VTK 5.4 is out and VTK 5.6 should come out soon. So I thought -again for the time being- that this modest patch was ok. -- Mathieu -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
