Re: build macros and includes

[Bryce McKinlay <mckinlay at redhat dot com>]

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