[CMake] Swig dependencies not being tested?

[Alan W. Irwin]

Tristan, I have been slow to respond to your e-mail because it took a long
time to investigate the java problems created by your patch.  Details,
below.

On 2007-12-11 10:59+0100 Tristan Carel wrote:

> On Dec 10, 2007 8:58 PM, Alan W. Irwin <irwin at beluga.phys.uvic.ca> wrote:
>> Tristan, since you do not encounter this problem, are you doing something
>> qualitatively different than above in your CMakeLists.txt file?
>
> I use `UseSWIG' the same way you do (except the unecessary `-python'
> in CMAKE_SWIG_FLAGS, already added by the module when you specify the
> target language in SWIG_ADD_MODULE macro). `UseSWIG.cmake' intends to
> be smart and takes cares of *all* files generated by swig: not only
> c/c++ code, but also wrappers in target language.

Thanks for that tip.  That line now reads

set(CMAKE_SWIG_FLAGS -DPL_DOUBLE -DSWIG_PYTHON)

>
> UseSwig.cmake uses basename of swig file to determine target language files.
>
> So, do you have %module plplotcmodule or %module plpotc in the plplotcmodule.i?

The first line of plplotcmodule.i is

%module plplotc

>
>
> This constraint on the filename can be quite inconvenient, furthermore
> this does not work with Java wrappers :)
> so here is a patch:

[...]

N.B. that patch did not work at all unless I changed

@@ -48,9 +49,15 @@

to

@@ -48,9 +49,14 @@

Anyhow, I am now using your patched version of UseSWIG.cmake

>
>
> So in case the module name is different than the file's basename, you
> can add a property SWIG_MODULE_NAME to swig files provided to the
> `SWIG_ADD_MODULE' macro in order to force the module name defined by
> these files:
>
> SET_SOURCE_FILES_PROPERTIES(callback.i PROPERTIES SWIG_MODULE_NAME Callbacks)
> # [...]
> SWIG_ADD_MODULE(callback_module python callback.i ...)
>
>

Although it appears to be redundant since "%module plplotc" is specified in
plplotcmodules.i, I added the following line to the CMake code

set_source_files_properties(plplotcmodule.i
PROPERTIES SWIG_MODULE_NAME plplotc
)

> I would be glad to know if it resolves your dependencies problem.

Yes, it does for the python case, but can you explain why this patched
version work (no gratuitous rebuilds) when "%module plplotc" alone does not
work with the unpatched version?

The remainder of this e-mail concerns the java compilation problems that
showed up with your patched version of UseSwig.cmake.

Your current approach for compiling java files does not work since there is
a whole boatload of *.java files generated by swig as well as some special
files which we need to compile as well.  For the PLplot case the complete
list of java files (all but those marked as hand-crafted or configured are
generated by swig) is the following:

bindings/java/PLStream.java (hand-crafted)

in the source tree and

bindings/java/PLGraphicsIn.java
bindings/java/plplotjavac.java
bindings/java/plplotjavacConstants.java
bindings/java/plplotjavacJNI.java
bindings/java/config.java  (configured)

in the build tree.

The plplotjavacConstants.java file can be taken care of by making the
following change to your patched UseSWIG.cmake:

-SET(SWIG_JAVA_EXTRA_FILE_EXTENSION "JNI.java" ".java")
+# Order is important
+SET(SWIG_JAVA_EXTRA_FILE_EXTENSION "JNI.java" "Constants.java" ".java")

Also, when compiling plplotjavacConstants.java, the results of
the plplotjavacJNI.java compilation cannot be found unless you
add

${CMAKE_BINARY_DIR}/CMakeFiles/plplotjavac_wrap.dir

to the list of directories referenced by INCLUDE_DIRECTORIES.  There is no
guarantee in the future that this directory prefix will continue to be used
to store the class files so this change must be classified as a temporary
workaround. See below for a better approach which controls the location
where the class files are located.

Additionally, there is the showstopper problem of the swig-generated file
PLGraphicsIn.java.  I only have a superficial knowledge of swig and java,
but I believe that file is generated because our API *.i file has a struct
defined that is called PLGraphicsIn.  Anyhow, it appears in the Java case
that swig-generated files will have a variety of names depending on the *.i
internals of each separate project.

Furthermore, there is the showstopper issue of the PLplot-specific java file
called PLStream.java in the source tree, and our configured java file called
config.java in the build tree which also must be compiled in the right
order.

Finally, the patched UseSWIG.cmake approach generates the following cmake.out
error message.

-- Configuring done
CMake Error: Error required internal CMake variable not set, cmake may be
not be built correctly.
Missing variable is:
CMAKE_Java_CREATE_SHARED_MODULE
-- Generating done
-- Build files have been written to: /home/software/plplot_cvs/HEAD/build_dir

That error message makes no sense since java file compilation generates
class files and not shared modules or libraries.  Anyhow, since the rest of
the message looks like everything worked, I believe that error message is
spurious.  When I continued on with showstopper make after that the problems
indicated above with the current patched approach showed up. (Note, I got
the reported good result for python only by turning off our java interface.)

Note, for our special case we make a complete list of the java files
we want to compile, and then after

swig_add_module(plplotjavac_wrap java plplotjavac.i)
swig_link_libraries(plplotjavac_wrap plplot${LIB_TAG})

we use (in the unpatched UseSwig.cmake case which only compiles the C file
generated by swig, and not the java files) the following custom
commands and overall custom target compile all our java files:

foreach( srcfile ${JAVA_FILES_FULL} )
   get_filename_component( fileroot ${srcfile} NAME_WE )
   add_custom_command(
   OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/plplot/core/${fileroot}.class
   COMMAND ${CMAKE_Java_COMPILER}
   -classpath ${CMAKE_CURRENT_BINARY_DIR} ${srcfile}
   -d ${CMAKE_CURRENT_BINARY_DIR}
   DEPENDS ${srcfile}
   )
endforeach( srcfile ${JAVA_FILES_FULL} )
add_custom_target(plplot_core ALL DEPENDS ${JAVA_CLASSES})

JAVA_CLASSES is created (not shown) to make the appropriate file
dependencies of the plplot_core target.

The above command compiles the java files in the correct order while
controlling the location of the generated class files in the build tree
while pointing to that same location with classpath.  (It also generates no
spurious cmake error messages involving CMAKE_Java_CREATE_SHARED_MODULE.)

You may want to follow something similar to the above approach if
you decide you do want to compile java files within your patched version of
UseSWIG.cmake.  You would have to allow users to communicate a list of
specially named java files to be compiled in the correct order with correct
classpath as well as communicate the java package name (plplot.core in our
case).

Tristan, if you decide to create a patch for UseSwig.cmake that does all
that for the java case, I would be happy to test it.  However, if it is
possible to solve the original gratuitous C rebuild issue for the java
interface case without compiling the java files, then that might greatly
reduce the changes you have to do for UseSwig.cmake.

I look forward to your reply.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________