This fixes a problem in the build introduced by Dalibor's latest patch. The check_jni_methods script is generated using @top_builddir@, which is a relative path that will be '..' from scripts (where check_jni_methods lives). However, Dalibor's patch also calls the script from native/jni which has a @top_builddir@ of ../../. Thus, when it comes time to run the script, it can't find the include files as the script uses the wrong relative path:
make[3]: Entering directory `/home/andrew/builder/classpath/native/jni'
/bin/sh ../../scripts/check_jni_methods.sh
grep: ../include/*.h: No such file or directory
Found a problem with the JNI methods declared and implemented.
This patch fixes it by using abs_top_builddir instead. There is still
a remaining minor issue in that the header files aren't generated in
the build directory of a parallel build if they exist in the source
directory.
ChangeLog:
2008-02-10 Andrew John Hughes <[EMAIL PROTECTED]>
* scripts/check_jni_methods.sh.in:
Use abs_top_builddir so that the absolute path
to the build directory is used by the script.
--
Andrew :-)
Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html
public class gcj extends Freedom implements Java { ... }
Index: scripts/check_jni_methods.sh.in
===================================================================
RCS file: /sources/classpath/classpath/scripts/check_jni_methods.sh.in,v
retrieving revision 1.1
diff -u -3 -p -u -r1.1 check_jni_methods.sh.in
--- scripts/check_jni_methods.sh.in 9 Feb 2008 21:16:21 -0000 1.1
+++ scripts/check_jni_methods.sh.in 10 Feb 2008 02:13:52 -0000
@@ -9,7 +9,7 @@ TMPFILE3=/tmp/check-jni-methods.$$.3
# Find all methods defined in the header files generated
# from the java source files.
-grep -h '^JNIEXPORT .* Java_' @top_builddir@/include/*.h | \
+grep -h '^JNIEXPORT .* Java_' @abs_top_builddir@/include/*.h | \
LC_ALL=C sed -e 's,.*JNICALL \(Java_[a-z_A-Z0-9]*\).*$,\1,' | \
sort > $TMPFILE
signature.asc
Description: Digital signature
