[Scons-users] Issues Generating Java Classes from a Swig Interface (.i) under Scons

[Bailey Stephen]

On Sun, Oct 11, 2015 at 10:10 PM, Bailey Stephen via Scons-users <scons-users at scons.org> wrote:

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']) #2Both #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 classpathFor 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(This does not contain the additional files for the accessors, enums, structs, etc. that are generated by SWIG, and so javac fails.)
>Do you mean Java files or class files?  What step is failing specifically?
The additional Java files generated by SWIG are not compiled to classes, and are not included in the sourcepath, so the compilation of the top level objects (source.java in the above example) fails.
 
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?
>In order for SCons to know what class files come from a Java file, SCons Java scanner must open the Java file and parse out the contents.  When the Java file doesn't exist, the Java scanner (naively) places a single class file as the output. On a second compile pass (after the Java files exist), the dependency graph will be expanded to something better (though I know there are issues with anonymous classes).  I do not know how SCons goes from SWIG to Java though.  Is it 1:1 or 1:N?
So does the user need to specify that SCons should scan through the list of files after the SWIG has run? My understanding from reading through swig.py was that there is a regex used to match the symbol '%module', and this is the list of files used by the emitter, with the suffixes -JNI.java and -.java. This means that there SCons has no knowledge of the additional generated java files.


>This could also be related to CrossLanguageScanning not working.  Please see the following pull request slated for SCons 2.5.0: https://bitbucket.org/scons/scons/pull-requests/244/issue-2264-cross-language-scanner-support/diff
This looks like it may be related, if I come across further issues will try the patch. Our current solution is a custom builder that manually compile the SWIG file to a jar, and the output of this is used to build the shared library. 
For reference the source files (if stripped back) would look like:Sconscript (part of a larger build tree):loc_env = env.Clone()loc_env['JAVACLASSPATH']= ['build/$TARGET_ARCH/$TARGET_OS/.../java']swig_j = loc_env.Java(target='.', source=['source_java.i'])loc_env.Alias('java_swig', swig_j)


Swig File (source_java.i):%module source%{
#include "source.h"
%}
#Typemaps and conversions in here%include "source.h"

and the source dragged in would look like:source.h:
#include <stdint.h>
#include <stddef.h>
typedef struct{    int field1;    int field2;    int field3;} custom_struct1// More typedefs in here// Helper functions, etccustom_struct1 func_prototype(void);
Thank you for the feedback so far,
Steve  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20151012/d3b43818/attachment-0001.html>