[CMake] Bug#553151: CMake 2.8.0 RC 4 ready for testing!

[Mathieu Malaterre]

On Thu, Oct 29, 2009 at 11:46 AM, Modestas Vainius <modestas at 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