On Thu, Oct 29, 2009 at 11:46 AM, Modestas Vainius <modes...@vainius.eu> wrote: > Ok. If you had thought about this more, you would have realized that it would
Yeah, well, I don't like regression, esp. on rc4. > not be "my code" you would have to fix. You patched library directories, but I have no clue who did what. I thought you were the only person after me working on FindJNI.cmake. Please apologize if that portion was not part of your actual patch. > that's includes which are wrong! In addition, I added a openjdk-6 directory to > the include search (to be on par with library directories) thinking I made a > favour for everyone, but here we go, it exposed another "problem". from everyone: "Thank you modestats !" >> If you are not going to fix your code, please revert to official cmake >> 2.6.4/FindJNI.cmake. VTK on debian is using my patch(*) and is working >> ok so far. > > First of all, this is a huge mess with all those JVMs and their directory ok. > naming schemes around. You see this issue because gcj-4.4-jdk does not provide > /usr/lib/jvm/java-1.5.0-gcj-4.4/include/jni_md.h compat symlink to > /usr/lib/jvm/java-1.5.0-gcj-4.4/include/linux/jni_md.h (provided by java-gcj- > compat-dev for gcj 4.3) which openjdk-6 does. Since the lib are also very messy. > ${JAVA_AWT_INCLUDE_DIRECTORIES} is first searched for JAVA_INCLUDE_PATH2 too, > openjdk-6 stuff is found first. So it is a messy scheme of gcj or yet another > bug in FindJNI (depends how you look at it) to blame. > > IMHO, the most logical fix would be: > > diff --git a/Modules/FindJNI.cmake b/Modules/FindJNI.cmake > index 8c9523a..6c8ff85 100644 > --- a/Modules/FindJNI.cmake > +++ b/Modules/FindJNI.cmake > @@ -192,7 +192,7 @@ FIND_PATH(JAVA_INCLUDE_PATH jni.h > ) > > FIND_PATH(JAVA_INCLUDE_PATH2 jni_md.h > - ${JAVA_AWT_INCLUDE_DIRECTORIES} > + ${JAVA_INCLUDE_PATH} > ${JAVA_INCLUDE_PATH}/win32 > ${JAVA_INCLUDE_PATH}/linux > ${JAVA_INCLUDE_PATH}/freebsd Sorry but -again- I do not like your proposed fix. jni_md.h and jawt.h should be found within the same subdirectory as jni.h (by contract). So something like (not tested): <...> FIND_PATH(JAVA_INCLUDE_PATH jni.h ${JAVA_AWT_INCLUDE_DIRECTORIES} ) # ok we found jni.h, now derive other location from it: get_filename_component(jni_path ${JAVA_INCLUDE_PATH} PATH) FIND_PATH(JAVA_INCLUDE_PATH2 jni_md.h ${jni_path} ${jni_path}/win32 ${jni_path}/linux ${jni_path}/freebsd ) FIND_PATH(JAVA_AWT_INCLUDE_PATH jawt.h ${jni_path} ) <...> > But I don't really know if it breaks on older JVMs or other platforms. In > addition, I don't really know why it was done the way it was done. Ah, that's > not my code that I'm fixing (rings the bell, Mathieu?). again, sorry, I really thought you were the only person working on FindJNI.cmake after my change. > P.S. Mathieu, typically finger pointing does not lead you anywhere in open > source. All help is appreciated if you want your problem solved faster. Still cmake 2.6.4/debian has the same problem. You cannot blame me for integrating that into debian. Please revert, it make debian/cmake/2.6.4-3 unusable for me. Thank you, -- Mathieu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org