On Sun, Nov 15, 2009 at 11:03 PM, Felipe Sateler<fsateler@gmail.com>
wrote:
I think the analysis it is wrong, because after the scons clean
stage, the
cache is deleted. Relevant section from debian/cdbs/1/class/scons.mk:
scons-clean::
$(DEB_SCONS_INVOKE) $(DEB_SCONS_CLEAN_TARGET)
$(DEB_SCONS_OPTIONS)
--keep-going --clean || true
rm -f debian/stamp-scons-build
rm -rf .sconf_temp/
rm -f .sconsign.dblite config.log
The cache are .scon*.
As can be seen in the build log, when scons uses a cached value (like
in the
install stage), it prints: Checking for foo... (cached) no.
However, in the buildd log the build stage shows no (cached) responses.
Thanks, I hadn't realized that this code was deleting the scons cache.
With this knowlege I went back, and verified a couple of things:
1) Verified that the custom.py (using md5sum) is installed before
scons is run.
2) Verified using strace that scons opens custom.py.
3) Verified using a compiler wrapper that the invocation by
configure.CheckHeader() contains the correct include path.
The following is the compiler invocation that configure.CheckHeader()
uses when looking for jni.h.
hppa-linux-gnu-g++ -o .sconf_temp/conftest_26.o -c -fexceptions
-Wno-format -DGNU_GETTEXT -g -fomit-frame-pointer -freorder-blocks
-DLINUX -DPIPES -DUSE_DOUBLE -DHAVE_SOCKETS
-DHAVE_PTHREAD_BARRIER_INIT -DHAVE_SYNC_LOCK_TEST_AND_SET -I. -IH
-I/usr/include/lua5.1 -I/usr/include/tcl -I/usr/include/tcl8.4
-I/usr/lib/jvm/default-java/include -I/usr/lib/jvm/java-gcj/include
-I/usr/local/include -I/usr/include -I/usr/include
-I/usr/X11R6/include .sconf_temp/conftest_26.cpp