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]>

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply via email to