On 10/02/2008, Andrew John Hughes <[EMAIL PROTECTED]> wrote: > On 09/02/2008, Dalibor Topic <[EMAIL PROTECTED]> wrote: > > hi all, > > > > the attached patch makes sure that the headers are generated in the > > build dir, rather than in the source dir. > > > > cheers, > > dalibor topic > > > > 2008-02-09 Dalibor Topic <[EMAIL PROTECTED]> > > > > * native/jni/Makefile.am (all-local): Call check_jni_methods.sh > > directly. > > > > * scripts/Makefile.am (EXTRA_DIST): Removed check_jni_methods.sh. > > > > * include/Makefile.am (SOUND_H_FILES, GST_PEER_H_FILES) > > (XMLJ_H_FILES, GTKPEER_H_FILES, QTPEER_H_FILES) > > (GCONF_PREFS_FILES, H_FILES): Don't generate header files > > in the source directory, as it may not be writeable. > > (DISTCLEANFILES) Added H_FILES. > > > > * configure.ac (AC_CONFIG_FILES): Added > > scripts/check_jni_methods.sh. > > > > * scripts/check_jni_methods.sh: Removed. Moved over to .. > > * scripts/check_jni_methods.sh.in: New file. Added > > top_srcdir and top_builddir where necessary. > > > > > > > > Did you test this fully? I'm seeing two issues here with separate > build and source trees: > > * The script no longer works because it is run from native/jni but > looks for the include files in ../include (as the script was generated > with top_builddir being relative to scripts). > > 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. > > * The rules to generate the headers are satisfied by the remaining > presence of header files in the source tree (generated by a build in > between your's and Mario's patches). This isn't a usual case but it > still seems wrong. I tested this by removing the java.io.VMFile > header from the include directory in the source tree and as expected a > make in the include directory of the build tree then generates this > file. > > Also we still seem to be looking for a javah, which means we are now > reliant on its existence for a successful build. Given we bundle > gjavah, couldn't we build tools first and then invoke this? This > wasn't possible before, but we now rely on compilers with VM > requirements anyway. > -- > Andrew :-) > > Support Free Java! > Contribute to GNU Classpath and the OpenJDK > http://www.gnu.org/software/classpath > http://openjdk.java.net >
I've fixed the first issue. The second is a side effect of VPATH support (the VPATH for include is the source include directory so it will be searched for the header files too). The solution is simply to clean out your source directories :) -- Andrew :-) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net
