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

[Bill Deegan]

Steve,

See notes inline below.

-Bill




On Mon, Oct 12, 2015 at 4:38 AM, Bailey Stephen <stephen3200 at yahoo.com>
wrote:

> 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']) #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
>
> (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.
>

No.
Likely the issue is that the emitter for swig is not detecting that the
java files in question would be generated.
This can be verified by running: scons --tree=prune and pastebin'ing the
output.
If you don't see the java files in the tree, then the swig builder is
missing that they'll be generated.

So the resolution would be to fix the swig builder.
It's possible the fixes in CrossLanguageScanning path could resolve it, and
with a simple test case it will be easy to verify that and/or to file a
useful bug and be able to resolve the issue.


>
>
>
> >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)
>


The provide SConscript snippet is not sufficient to reproduce the problem.
If you can produce a "Free standing" single  SConstruct and a .i file which
would reproduce the issue that will make it easier to figure out the root
cause and possibility resolve.


>
>
> 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, etc
> custom_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/edd3f793/attachment-0001.html>