build macros and includes

Mon Oct 4 18:01:00 GMT 2004

Ray Auge wrote:
>The result is that in the java-gnome configure step when a query for the
>location of libgcj-?.?.?.jar is made, via "locate", we get two versions
>and the configure fails.
>>I'd like to know if this check is even required.
>>
gcj should always pick the correct .jar, and its definately a bug if 
this isn't happening. However, it might be desirable to provide support 
for adding it to the classpath if you want to be able to build a 
bytecode version of java-gnome with a compiler other than gcj (ie: ecj 
or jikes).
>Second, due to the nature of java-gnome it often requires the use of
>jni.h. I'd like to know if the gcj team provides a m4 macro that can be
>used to find it or do we simply always assume that it is located
>at /usr/include/libgcj-${gcjversion}/, or is this mostly system
>dependant?
>>I've seen problems occur with java-gnome when another, incomplete jni.h 
(from mozilla, iirc) gets picked up by gcc ahead of libgcj's, due to 
explicit -I's on the command line overriding the compiler's built-in 
include path. For that reason, we need to make sure that the correct 
jni.h is -I'ed on the command line ahead of any other jni.h's.
It should be possible to locate jni.h relative to the .spec path given 
by "gcj -v". Using that might be one approach to writing a configure 
macro. Note that we do not install jni.h in a version specific 
directory, however that shouldn't matter in most cases as JNI should be 
(at least somewhat) binary compatible in both directions. ie - as long 
as the jni.h found is "new enough" for your source code, you should be fine.
Bryce