[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Csound build failure in hppa

Carlos O'Donell wrote:

On Fri, Nov 13, 2009 at 10:52 AM, Felipe Sateler <fsateler@gmail.com> wrote:

Hi, my package csound failed to build in hppa due to some java issues.
Csound tries to detect if it can find jni.h to build the java part of
the code. For all arches, it is possible do so by
adding /usr/lib/jvm/default-java/include to the preprocessor path.
However, it failed to detect it in hppa. Is this some issue I should
resolve, or should I report a bug against default-jre-headless (which
manages /usr/lib/jvm/default-java)?

latest build log at
https://buildd.debian.org/fetch.cgi?&pkg=csound&ver=1%3A5.11.1~dfsg-1&arch=hppa&stamp=1256443628&file=log


This is a bug in the csound debian/rules file.

During `debian/rules clean` the package build runs scons *before*
custom.py is copied over the default distribution version. Even though
scons is running to cleanup the install it checks for java (without
the added customCPPPATHS) and fails to find it, and worse it caches
this result.

Later during `debian/rules build` the package build runs scons *again*
with custom.py in place, but it is too late and the cached values are
used and the java wrapper is not built.

Adding `--config=force` to debian/rules (DEB_SCONS_OPTS) allows the
package to build for hppa. It is not the correct solution.

Perhaps the other architectures have jni.h or jni_md.h are in a more
standard location than hppa, and therefore the initial configure
enables java.

However, this is still a serious bug in the csound package and could
cause misconfiguration on more targets than hppa.
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 for looking into this!

Saludos,
Felipe Sateler
Reply to: