Hello, On ketvirtadienis 17 RugsÄ—jis 2009 13:33:24 Mathieu Malaterre wrote: > > I would think that DD cannot replace whatever choice is being done > upstream.
I'm not going to replace anything, I'm going to talk with cmake upstream about this. > > 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. > The actual proper fix in debian would be to have all libjawt.so > provider to install the symlinks properly. > > Don't you find it weird that vtk builds just > > *fine* with FindJNI.cmake on arches it supposedly does NOT support > > (according to this bug) but fails on powerpc which it supports properly? > > This bug obviously attracted too much false attention. > > No it does not build, see your own remark below. > > > FWIW, from vtk debian/rules: > > > > echo JAVA_AWT_LIBRARY:FILEPATH=/usr/lib/jvm/default- > > java/jre/lib/$(DEB_HOST_ARCH_CPU)/libjawt.so >> Build/CMakeCache.txt > > 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. > > So that's where the powerpc FTBFS is coming from. It *overrides* proper > > value FindJNI sets on powerpc. It is also true that you cannot drop this > > workaround until #544674 is fixed. You will have to improve it. > > 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. > 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. > 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. -- Modestas Vainius <[email protected]>
signature.asc
Description: This is a digitally signed message part.

