When I attempt to run scons (2.3.0) to build a class from a SWIG interface file, scons fails to pick up all the generated files, either as being in the sourcepath, or to be included in the build (even with classpath set). Instead only two java files are attempted to be compiled, both of which fail because they are derived from other classes.
loc_env = env.Clone()
loc_env['JAVACLASSPATH']= ['build/$TARGET_ARCH/$TARGET_OS/.../java']
swig_j = loc_env.Java(target='.', source=['source_java.i']) #1
#swig_j = loc_env.Jar(target='.', source=['source_java.i']) #2
Both #1, and #2 fail to produce a result. #2 shows an error message that the source has not been accepted, and is a blank string, which I can accept, even with example code suggesting it should work.
For #1 The root cause seems to be in Scons/Tool/swig.py def _find_modules(src):, which has a regex to match all modules generated, but fails to account for any raw enums or other artefacts from wrapping up C code. When I had a hand-rolled makefile the classpath
For reference, The javac build instruction for #1 is:
javac -classpath build/x86_64/linux/.../java -d build/x86_64/linux/.../java/ -sourcepath build/x86_64/linux/.../java build/x86_64/linux/release/.../source.java build/x86_64/linux/release/.../sourceJNI.java
Is this a known bug (As part of SCONS' handling of 1->N mappings)? Is it a flaw in the Scons Parsing of .i files? or is it a more fundamental issue?
This is a bug in SCons. The changes slated for 2.5.0 fix the issue, by improving cross-language scanning. I look forwards to ripping out my hack sometime next year!