Re: [CMake] Swig dependencies not being tested?
On 2007-12-12 17:17+0100 Tristan Carel wrote: On Dec 12, 2007 12:33 AM, Alan W. Irwin <[EMAIL PROTECTED]> wrote: [...] 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. As we can't get the exact list of generated files by swig, we won't try to guess it, so won't try to build them too :) I have added an entry at CMake BT: http://www.cmake.org/Bug/bug_view_page.php?bug_id=6151 The patch is sensibly different from the previous one: it mainly remove the spurious entry SET(SWIG_JAVA_EXTRA_FILE_EXTENSION "JNI.java" ".java") It fixes unecessary rebuilds, whatever the language target. I just tried your latest patch for UseSWIG.cmake, and indeed it works fine (original build is fine and redoing make does not rebuild anything) with PLplot if I add set_source_files_properties(plplotjavac.i PROPERTIES SWIG_MODULE_NAME plplotjavac ) for the java case and set_source_files_properties(plplotcmodule.i PROPERTIES SWIG_MODULE_NAME plplotc ) for the python case. Thanks a lot for figuring out this unnecessary rebuild issue for swig with such a minimalistic patch! I don't have CVS write access on the modules repository. I will ask Bill for it. Good move. 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 __ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Swig dependencies not being tested?
On Dec 12, 2007 12:33 AM, Alan W. Irwin <[EMAIL PROTECTED]> wrote:
> 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 <[EMAIL PROTECTED]> wrote:
> >> Tristan, since you do not encounter this problem, are you doing something
> >> qualitatively different than above in your CMakeLists.txt file?
> >
> [...]
>
>
> N.B. that patch did not work at all unless I changed
>
> @@ -48,9 +49,15 @@
>
> to
>
> @@ -48,9 +49,14 @@
>
Ooops!
>
> [...]
>
> 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?
>
In Python specific case, with "%module plplotc" alone, UseSwig.cmake
creates the following make rule:
plplotcmodulePYTHON_wrap.c plplotcapi.py: plplotcapi.i
/usr/bin/swig ...
To get module's name, UseSwig.cmake does not look in swig files'
content: plplotcapi.py is deduced from the swig filename. So when
module's name specified with "%module " directive differs
from the swig filename, you can tell `UseSwig.cmake' the real module's
name with the `SWIG_MODULE_NAME' property.
So that if plplotcapi.py is (accidently) removed, `make' runs `swig'
to re-create it.
> 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.
building wrappers generated by swig is not UseSwig.cmake's duty. But
to know which files are created by swig, I guess this is mandatory.
`UseSwig.cmake' should prevent user to painfully manage list of
generated wrappers, like you do to compile java bindings.
For example if you delete one of the generated java file, `make'
should re-run swig, which is not currently the case.
About the weird error you have with java:
Relative to the way I have used swig + java, I guessed the line:
SET(SWIG_JAVA_EXTRA_FILE_EXTENSION "JNI.java" ".java")
Unfortunately with plplot, some others are created.
For the moment, swig does not provide list of created files. With
option -MM, swig writes to standard output:
/tmp/plplot/bindings/java/plplotjavac_wrap.c: \
/tmp/plplot/bindings/java/plplotjavac.i \
/tmp/plplot/bindings/swig-support/plplotcapi.i
This is good actually, as we can determine list of dependencies. But
not good enough as we don't know the list of generated wrappers. This
feature of Swig is not currently used by `UseSwig.cmake', but we will
be soon to get exact dependencies.
> 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 tre
Re: [CMake] Swig dependencies not being tested?
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 <[EMAIL PROTECTED]> 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
Re: [CMake] Swig dependencies not being tested?
On Dec 10, 2007 8:58 PM, Alan W. Irwin <[EMAIL PROTECTED]> wrote:
> On 2007-12-10 17:08+0100 Tristan Carel wrote:
>
> > On Dec 10, 2007 7:15 AM, Alan W. Irwin <[EMAIL PROTECTED]> wrote:
> >> On 2007-12-10 05:33+0100 Christiaan Putter wrote:
> >>
> >>> Hi all,
> >>>
> >>> I know swig support isn't all that great at the moment but was wondering
> >>> if
> >>> someone happens to have a working Swig module for cmake that doesn't
> >>> rebuild
> >>> every time even without the dependencies having changed.
> >>
> >> I do confirm that is a problem, and I hope somebody fixes it.
> >>
> >
> > I use the Swig module, the one provided by CMake, and it's working
> > well. Swig wrappers generation and library compilation are properly
> > managed (not rebuild all the time). I use it the same way than Alan
> > described: only one swig file, which takes care of all inclusions, is
> > provided to the macro SWIG_ADD_MODULE. To specify missing
> > dependencies, I use the variable `SWIG_MODULE__EXTRA_DEPS':
>
> One weakness of the previous PLplot implementation was the lack of
> dependency on the common file, but now I am using
> SWIG_MODULE__EXTRA_DEPS to provide that. Thanks for drawing my
> attention to that possibility.
>
> However, that is a side issue from the problem that swig is always re-invoked
> (for the PLplot case) which means the interface always gets rebuilt. Here
> are some more details.
>
> CMakeLists.txt fragment:
>
> # This is currently the include list for swig, the C wrapper and the
> # the Python headers. Not particular pretty...
> set(python_interface_INCLUDE_PATHS
> ${CMAKE_SOURCE_DIR}/include
> ${CMAKE_BINARY_DIR}
> ${CMAKE_BINARY_DIR}/include
> ${CMAKE_CURRENT_BINARY_DIR}
> ${PYTHON_INCLUDE_PATH}
> ${CMAKE_SOURCE_DIR}/bindings/swig-support
> )
> include_directories(${python_interface_INCLUDE_PATHS})
>
> set(CMAKE_SWIG_FLAGS -DPL_DOUBLE -DSWIG_PYTHON -python)
>
> set(CMAKE_SWIG_OUTDIR ${CMAKE_CURRENT_BINARY_DIR})
>
> set(SWIG_MODULE_plplotcmodule_EXTRA_DEPS
> ${CMAKE_SOURCE_DIR}/bindings/swig-support/plplotcapi.i)
>
> # Set up swig + c wrapper.
> # N.B. the python target has an underscore prepended automatically.
> swig_add_module(plplotcmodule python plplotcmodule.i)
>
> swig_link_libraries(plplotcmodule plplot${LIB_TAG} ${PYTHON_LIBRARIES})
>
> If I rerun make, here is the (partial) verbose result showing that swig is
> re-run, then the interface is rebuilt:
>
> [...]
>
> I get the same gratuitous rebuild behaviour for our Java interface as well.
>
> 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.
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?
This constraint on the filename can be quite inconvenient, furthermore
this does not work with Java wrappers :)
so here is a patch:
--- /home/carel/CMake/CMake/Modules/UseSWIG.cmake 2007-03-05
21:21:49.0 +0100
+++ /usr/local/share/cmake-2.5/Modules/UseSWIG.cmake2007-12-11
10:31:38.0 +0100
@@ -18,7 +18,8 @@
SET(SWIG_CXX_EXTENSION "cxx")
SET(SWIG_EXTRA_LIBRARIES "")
-SET(SWIG_PYTHON_EXTRA_FILE_EXTENSION "py")
+SET(SWIG_PYTHON_EXTRA_FILE_EXTENSION ".py")
+SET(SWIG_JAVA_EXTRA_FILE_EXTENSION "JNI.java" ".java")
#
# For given swig module initialize variables associated with it
@@ -48,9 +49,15 @@
#
MACRO(SWIG_GET_EXTRA_OUTPUT_FILES language outfiles generatedpath infile)
- FOREACH(it ${SWIG_PYTHON_EXTRA_FILE_EXTENSION})
+ GET_SOURCE_FILE_PROPERTY(SWIG_GET_EXTRA_OUTPUT_FILES_module_basename
+${infile} SWIG_MODULE_NAME)
+ IF(SWIG_GET_EXTRA_OUTPUT_FILES_module_basename STREQUAL "NOTFOUND")
+GET_FILENAME_COMPONENT(SWIG_GET_EXTRA_OUTPUT_FILES_module_basename
"${infile}" NAME_WE)
+ ENDIF(SWIG_GET_EXTRA_OUTPUT_FILES_module_basename STREQUAL "NOTFOUND")
+ FOREACH(it ${SWIG_${language}_EXTRA_FILE_EXTENSION})
SET(${outfiles} ${${outfiles}}
- "${generatedpath}/${infile}.${it}")
+ "${generatedpath}/${SWIG_GET_EXTRA_OUTPUT_FILES_module_basename}${it}")
ENDFOREACH(it)
ENDMACRO(SWIG_GET_EXTRA_OUTPUT_FILES)
@@ -105,7 +112,7 @@
SWIG_GET_EXTRA_OUTPUT_FILES(${SWIG_MODULE_${name}_LANGUAGE}
swig_extra_generated_files
"${swig_outdir}"
-"${swig_source_file_name_we}")
+"${infile}")
SET(swig_generated_file_fullname
"${swig_generated_file_fullname}/${swig_source_file_name_we}")
# add the language into the name of the file (i.e. TCL_wrap)
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
Re: [CMake] Swig dependencies not being tested?
Am Montag 10 Dezember 2007 schrieb Tristan Carel:
> On Dec 10, 2007 7:15 AM, Alan W. Irwin <[EMAIL PROTECTED]> wrote:
> > On 2007-12-10 05:33+0100 Christiaan Putter wrote:
> > > Hi all,
> > >
> > > I know swig support isn't all that great at the moment but was
> > > wondering if someone happens to have a working Swig module for cmake
> > > that doesn't rebuild every time even without the dependencies having
> > > changed.
> >
> > I do confirm that is a problem, and I hope somebody fixes it.
>
> I use the Swig module, the one provided by CMake, and it's working
> well. Swig wrappers generation and library compilation are properly
> managed (not rebuild all the time). I use it the same way than Alan
> described: only one swig file, which takes care of all inclusions, is
> provided to the macro SWIG_ADD_MODULE. To specify missing
> dependencies, I use the variable `SWIG_MODULE__EXTRA_DEPS':
>
> SET(SWIG_MODULE_foo_EXTRA_DEPS bar.i foobar.i bar.h ...)
> SWIG_ADD_MODULE(foo PYTHON foo.i)
And there is the whole point: that adds a cmake target "foo" with output
name "_foo.so". So an
SWIG_ADD_MODULE(foo PERL foo.i)
conflicts with the first cmake target. Add even an
SWIG_ADD_MODULE(foo RUBY foo.i)
conflict with the cmake target _and_ the output name of the PERL line. That
could be improved a lot.
The following recompiles every time:
---snip
option ( BUILD_BINDINGS "Build the SWIG bindings" )
if ( BUILD_BINDINGS )
find_package ( SWIG REQUIRED )
include (${SWIG_USE_FILE})
include_directories ( ${CMAKE_CURRENT_SOURCE_DIR} )
set ( FOO_SWIG_FILE "${CMAKE_CURRENT_SOURCE_DIR}/foo.i" )
set ( CMAKE_SWIG_FLAGS "" )
set_source_files_properties ( ${FOO_SWIG_FILE} PROPERTIES
CPLUSPLUS OFF
SWIG_FLAGS ""
)
foreach ( LANG perl python ruby )
string ( TOUPPER "${LANG}" LANG_UPPERCASE)
option ( BUILD_${LANG_UPPERCASE}_BINDING "Build the ${LANG} binding" ON )
include ( ${LANG}/CMakeLists.txt)
endforeach ( LANG )
endif ( BUILD_BINDINGS )
---snip
The python/CMakelists.txt then contains:
---snip
find_package ( PythonLibs )
include_directories ( ${PYTHON_INCLUDE_PATH} )
swig_add_module ( foo_python python ${FOO_SWIG_FILE} )
swig_link_libraries ( foo_python libobexftp )
set_target_properties ( ${SWIG_MODULE_foo_python_REAL_NAME}
PROPERTIES
OUTPUT_NAME "_foo"
)
---snip
You have your example :)
The same for PERL does _not_ recompile every time.
> Attached to #4147, you can find a macro
> `SWIG_GET_WRAPPER_DEPENDENCIES' which use -MM option provided by Swig
> to compute dependencies. This intend to replace use of variable
> SWIG_MODULE__EXTRA_DEPS
>
> Could you please describe a use case which create the unnecessary
> rebuilt of your project?
>
> > > Someone else also pointed out a problem with .i files having to be in
> > > the current source dir.
> >
> > We have never felt constrained by that limitation (in fact I was unaware
> > of it) since it is possible to specify just one *.i file in the current
> > source directory that then includes *.i files from elsewhere in the
> > source tree.
>
> > Despite the convenience of this approach, others will have different
> > needs that would best be served by allowing the initial *.i file (that
> > includes the rest of the *.i files) to be somewhere else than the current
> > source directory so on these general grounds I hope this limitation is
> > removed at the same time as when the dependency problem is fixed.
>
> I agree, it should work.
> I guess it is alright if you specify a path like "../common.i" but not
> something like ${CMAKE_SOURCE_DIR}/swig/common.i.
No, neither works currently.
HS
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Swig dependencies not being tested?
On 2007-12-10 17:08+0100 Tristan Carel wrote:
On Dec 10, 2007 7:15 AM, Alan W. Irwin <[EMAIL PROTECTED]> wrote:
On 2007-12-10 05:33+0100 Christiaan Putter wrote:
Hi all,
I know swig support isn't all that great at the moment but was wondering if
someone happens to have a working Swig module for cmake that doesn't rebuild
every time even without the dependencies having changed.
I do confirm that is a problem, and I hope somebody fixes it.
I use the Swig module, the one provided by CMake, and it's working
well. Swig wrappers generation and library compilation are properly
managed (not rebuild all the time). I use it the same way than Alan
described: only one swig file, which takes care of all inclusions, is
provided to the macro SWIG_ADD_MODULE. To specify missing
dependencies, I use the variable `SWIG_MODULE__EXTRA_DEPS':
One weakness of the previous PLplot implementation was the lack of
dependency on the common file, but now I am using
SWIG_MODULE__EXTRA_DEPS to provide that. Thanks for drawing my
attention to that possibility.
However, that is a side issue from the problem that swig is always re-invoked
(for the PLplot case) which means the interface always gets rebuilt. Here
are some more details.
CMakeLists.txt fragment:
# This is currently the include list for swig, the C wrapper and the
# the Python headers. Not particular pretty...
set(python_interface_INCLUDE_PATHS
${CMAKE_SOURCE_DIR}/include
${CMAKE_BINARY_DIR}
${CMAKE_BINARY_DIR}/include
${CMAKE_CURRENT_BINARY_DIR}
${PYTHON_INCLUDE_PATH}
${CMAKE_SOURCE_DIR}/bindings/swig-support
)
include_directories(${python_interface_INCLUDE_PATHS})
set(CMAKE_SWIG_FLAGS -DPL_DOUBLE -DSWIG_PYTHON -python)
set(CMAKE_SWIG_OUTDIR ${CMAKE_CURRENT_BINARY_DIR})
set(SWIG_MODULE_plplotcmodule_EXTRA_DEPS
${CMAKE_SOURCE_DIR}/bindings/swig-support/plplotcapi.i)
# Set up swig + c wrapper.
# N.B. the python target has an underscore prepended automatically.
swig_add_module(plplotcmodule python plplotcmodule.i)
swig_link_libraries(plplotcmodule plplot${LIB_TAG} ${PYTHON_LIBRARIES})
If I rerun make, here is the (partial) verbose result showing that swig is
re-run, then the interface is rebuilt:
make -f bindings/python/CMakeFiles/_plplotcmodule.dir/build.make
bindings/python/CMakeFiles/_plplotcmodule.dir/depend
make[2]: Entering directory `/home/software/plplot_cvs/HEAD/build_dir'
/usr/bin/cmake -E cmake_progress_report /home/software/plplot_cvs/HEAD/build_dir/CMakeFiles
[ 9%] Swig source
cd /home/software/plplot_cvs/HEAD/build_dir/bindings/python && /usr/bin/swig
-python -DPL_DOUBLE -DSWIG_PYTHON -python -outdir
/home/software/plplot_cvs/HEAD/build_dir/bindings/python
-I/home/software/plplot_cvs/HEAD/plplot_cmake/include
-I/home/software/plplot_cvs/HEAD/build_dir
-I/home/software/plplot_cvs/HEAD/build_dir/include
-I/home/software/plplot_cvs/HEAD/build_dir/bindings/python -I/usr/include/python2.4
-I/usr/lib/python2.4/site-packages/numpy/core/include/numpy
-I/home/software/plplot_cvs/HEAD/plplot_cmake/bindings/swig-support -o
/home/software/plplot_cvs/HEAD/build_dir/bindings/python/plplotcmodulePYTHON_wrap.c
/home/software/plplot_cvs/HEAD/plplot_cmake/bindings/python/plplotcmodule.i
Scanning dependencies of target _plplotcmodule
cd /home/software/plplot_cvs/HEAD/build_dir && /usr/bin/cmake -E cmake_depends "Unix
Makefiles" /home/software/plplot_cvs/HEAD/plplot_cmake
/home/software/plplot_cvs/HEAD/plplot_cmake/bindings/python
/home/software/plplot_cvs/HEAD/build_dir /home/software/plplot_cvs/HEAD/build_dir/bindings/python
/home/software/plplot_cvs/HEAD/build_dir/bindings/python/CMakeFiles/_plplotcmodule.dir/DependInfo.cmake
make[2]: Leaving directory `/home/software/plplot_cvs/HEAD/build_dir'
make -f bindings/python/CMakeFiles/_plplotcmodule.dir/build.make
bindings/python/CMakeFiles/_plplotcmodule.dir/build
make[2]: Entering directory `/home/software/plplot_cvs/HEAD/build_dir'
/usr/bin/cmake -E cmake_progress_report /home/software/plplot_cvs/HEAD/build_dir/CMakeFiles
[ 9%] Building C object bindings/python/CMakeFiles/_plplotcmodule.dir/plplotcmodulePYTHON_wrap.o
/usr/bin/gcc -D_plplotcmodule_EXPORTS -fPIC
-I/home/software/plplot_cvs/HEAD/plplot_cmake/include
-I/home/software/plplot_cvs/HEAD/build_dir
-I/home/software/plplot_cvs/HEAD/build_dir/include
-I/home/software/plplot_cvs/HEAD/build_dir/bindings/python
-I/usr/include/python2.4
-I/usr/lib/python2.4/site-packages/numpy/core/include/numpy
-I/home/software/plplot_cvs/HEAD/plplot_cmake/bindings/swig-support
-DHAVE_CONFIG_H -o
bindings/python/CMakeFiles/_plplotcmodule.dir/plplotcmodulePYTHON_wrap.o -c
/home/software/plplot_cvs/HEAD/build_dir/bindings/python/plplotcmodulePYTHON_wrap.c
/home/software/plplot_cvs/HEAD/build_dir/bindings/python/plplotcmodulePYTHON_wrap.c:2510:1:
warning: "PySequence_Fast_GET_ITEM" redefined
In file included from /usr/include/python2.4/Python.h:123,
from
/home/software/plplot_cvs/HEAD/build_dir/bindings/python/plplotcmodu
Re: [CMake] Swig dependencies not being tested?
I have a modified version of the Swig module (edited before the
EXTRA_DEPS flag was present). It uses the -MM to create dependencies
and a python script to convert the file into a CMake consumable
version. The make2cmake.py file could be rewritten in cmake script (see
below). It just needs some regular expression magic. We've done it for
other compilers (cuda), but I haven't bothered since I had one that just
worked.
You can find the code in our online repository.
svn cat
https://code.sci.utah.edu/svn/Manta/trunk/CMake/MantaUseSWIG.cmake >
MantaUseSWIG.cmake
svn cat https://code.sci.utah.edu/svn/Manta/trunk/CMake/make2cmake.py >
make2cmake.py
svn cat https://code.sci.utah.edu/svn/Manta/trunk/CMake/empty.depend.in
> empty.depend.in
You don't have to do anything special on the using side. It can be used
as a drop in replacement for the existing swig module. You just have to
place these three files in a CMake directory at the top of your source tree.
The mechanics were takes from some code I found in VTK. You create two
additional targets. One generates the .swig-depends file via swig -MM.
The next converts the file to a cmake readable form. Swig doesn't
regenerate the .swig-depends file if the dependencies don't change, so
you get reasonable behavior. We've been using this script for a couple
of years now with out problems.
James
P.S. Here's my first stab at a make2cmake.cmake script (note it probably
isn't complete).
SET(IN_FILENAME "test.swig-depend")
MESSAGE("IN_FILENAME = ${IN_FILENAME}")
FILE(READ ${IN_FILENAME} FILESTUFF)
MESSAGE("FILESTUFF = ${FILESTUFF}")
STRING(REGEX REPLACE "^.*:[ ]*\n" "" FILESTUFF ${FILESTUFF})
STRING(REGEX REPLACE "[ ]*\n" ";" FILESTUFF ${FILESTUFF})
MESSAGE("FIXED = ${FILESTUFF}")
FOREACH(VAR ${FILESTUFF})
MESSAGE("VAR = ${VAR}")
ENDFOREACH(VAR)
We did get this working for cuda, but the regular expression may need to
be modified to the one above.
svn cat
https://code.sci.utah.edu/svn/people/abe/code/CMake-cuda/CMake/cuda/make2cmake.cmake
> make2cmake.cmake
On Dec 10, 2007, at 9:08 AM, Tristan Carel wrote:
On Dec 10, 2007 7:15 AM, Alan W. Irwin <[EMAIL PROTECTED]> wrote:
On 2007-12-10 05:33+0100 Christiaan Putter wrote:
Hi all,
I know swig support isn't all that great at the moment but was
wondering if
someone happens to have a working Swig module for cmake that doesn't
rebuild
every time even without the dependencies having changed.
I do confirm that is a problem, and I hope somebody fixes it.
I use the Swig module, the one provided by CMake, and it's working
well. Swig wrappers generation and library compilation are properly
managed (not rebuild all the time). I use it the same way than Alan
described: only one swig file, which takes care of all inclusions, is
provided to the macro SWIG_ADD_MODULE. To specify missing
dependencies, I use the variable `SWIG_MODULE__EXTRA_DEPS':
SET(SWIG_MODULE_foo_EXTRA_DEPS bar.i foobar.i bar.h ...)
SWIG_ADD_MODULE(foo PYTHON foo.i)
Attached to #4147, you can find a macro
`SWIG_GET_WRAPPER_DEPENDENCIES' which use -MM option provided by Swig
to compute dependencies. This intend to replace use of variable
SWIG_MODULE__EXTRA_DEPS
Could you please describe a use case which create the unnecessary
rebuilt of your project?
Someone else also pointed out a problem with .i files having to be
in the
current source dir.
We have never felt constrained by that limitation (in fact I was
unaware of
it) since it is possible to specify just one *.i file in the current
source
directory that then includes *.i files from elsewhere in the source tree.
+1
Despite the convenience of this approach, others will have different
needs
that would best be served by allowing the initial *.i file (that includes
the rest of the *.i files) to be somewhere else than the current source
directory so on these general grounds I hope this limitation is removed
at the same time as when the dependency problem is fixed.
I agree, it should work.
I guess it is alright if you specify a path like "../common.i" but not
something like ${CMAKE_SOURCE_DIR}/swig/common.i.
--
Tristan Carel
Music with dinner is an insult both to the cook and the violinist.
http://www.tristancarel.com
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Swig dependencies not being tested?
On 2007-12-10 10:12+0100 Hendrik Sattler wrote: Quoting "Alan W. Irwin" <[EMAIL PROTECTED]>: Someone else also pointed out a problem with .i files having to be in the current source dir. We have never felt constrained by that limitation (in fact I was unaware of it) since it is possible to specify just one *.i file in the current source directory that then includes *.i files from elsewhere in the source tree. I could also copy the .i file multiple times but that somewhat defeats the purpose. I have a bug open for that. Just to clarify we do not copy *.i files or have duplicate *.i information in multiple files for our particular swig configuration. Instead, we keep all the common swig information (e.g., the definition of our library's API) in one large common file which is included by our relatively small language-specific swig *.i files. If you are unable/unwilling to use a similar organization (small language-specific *.i files which include *.i files with the common swig information) and therefore are forced by the above CMake limitation to copy *.i files for your particular swig needs, then obviously the removal of that CMake limitation is a high priority for you. 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 __ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Swig dependencies not being tested?
On Dec 10, 2007 7:15 AM, Alan W. Irwin <[EMAIL PROTECTED]> wrote:
> On 2007-12-10 05:33+0100 Christiaan Putter wrote:
>
> > Hi all,
> >
> > I know swig support isn't all that great at the moment but was wondering if
> > someone happens to have a working Swig module for cmake that doesn't rebuild
> > every time even without the dependencies having changed.
>
> I do confirm that is a problem, and I hope somebody fixes it.
>
I use the Swig module, the one provided by CMake, and it's working
well. Swig wrappers generation and library compilation are properly
managed (not rebuild all the time). I use it the same way than Alan
described: only one swig file, which takes care of all inclusions, is
provided to the macro SWIG_ADD_MODULE. To specify missing
dependencies, I use the variable `SWIG_MODULE__EXTRA_DEPS':
SET(SWIG_MODULE_foo_EXTRA_DEPS bar.i foobar.i bar.h ...)
SWIG_ADD_MODULE(foo PYTHON foo.i)
Attached to #4147, you can find a macro
`SWIG_GET_WRAPPER_DEPENDENCIES' which use -MM option provided by Swig
to compute dependencies. This intend to replace use of variable
SWIG_MODULE__EXTRA_DEPS
Could you please describe a use case which create the unnecessary
rebuilt of your project?
> >
> > Someone else also pointed out a problem with .i files having to be in the
> > current source dir.
>
> We have never felt constrained by that limitation (in fact I was unaware of
> it) since it is possible to specify just one *.i file in the current source
> directory that then includes *.i files from elsewhere in the source tree.
+1
> Despite the convenience of this approach, others will have different needs
> that would best be served by allowing the initial *.i file (that includes
> the rest of the *.i files) to be somewhere else than the current source
> directory so on these general grounds I hope this limitation is removed
> at the same time as when the dependency problem is fixed.
I agree, it should work.
I guess it is alright if you specify a path like "../common.i" but not
something like ${CMAKE_SOURCE_DIR}/swig/common.i.
--
Tristan Carel
Music with dinner is an insult both to the cook and the violinist.
http://www.tristancarel.com
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Swig dependencies not being tested?
Quoting "Alan W. Irwin" <[EMAIL PROTECTED]>:
On 2007-12-10 05:33+0100 Christiaan Putter wrote:
I know swig support isn't all that great at the moment but was wondering if
someone happens to have a working Swig module for cmake that doesn't rebuild
every time even without the dependencies having changed.
I do confirm that is a problem, and I hope somebody fixes it.
The problem only exists for FindPythonLibs.cmake, though, as the
rebuilding does not happen for Perl (once FindPerlLibs.cmake is fixed,
see bug db) or Ruby.
Someone else also pointed out a problem with .i files having to be in the
current source dir.
We have never felt constrained by that limitation (in fact I was unaware of
it) since it is possible to specify just one *.i file in the current source
directory that then includes *.i files from elsewhere in the source tree.
I could also copy the .i file multiple times but that somewhat defeats
the purpose. I have a bug open for that.
Same goes for target naming: the output name and the cmake target name
have a too close relationsship (the former is derived from the
latter). And since the binding language is not taken into account for
the cmake target name, one practically must do that himself and then
use SET_TARGET_PROPERTIES to change the OUTPUT_NAME to something
useful. Very inconvenient.
Cmake target name should be: ${SWIG_TARGET_NAME)_${SWIG_LANGUAGE}
and output name then only derived from ${SWIG_TARGET_NAME}
HS
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Swig dependencies not being tested?
On 2007-12-10 05:33+0100 Christiaan Putter wrote:
Hi all,
I know swig support isn't all that great at the moment but was wondering if
someone happens to have a working Swig module for cmake that doesn't rebuild
every time even without the dependencies having changed.
I do confirm that is a problem, and I hope somebody fixes it.
Someone else also pointed out a problem with .i files having to be in the
current source dir.
We have never felt constrained by that limitation (in fact I was unaware of
it) since it is possible to specify just one *.i file in the current source
directory that then includes *.i files from elsewhere in the source tree.
For example our principal library has an API defined
in ${CMAKE_SOURCE_DIR}/bindings/swig-support/plplotcapi.i which is used
by our two separate swig-generated (python and java) interfaces as follows:
Both the bindings/java/CMakeLists.txt file and its python equivalent
put ${CMAKE_SOURCE_DIR}/bindings/swig-support in the INCLUDE_DIRECTORIES
list. Then both java/plplotjavac.i and its python equivalent contain
the following line:
%include plplotcapi.i
which conveniently includes the bulk of the *.i information from
one common place in the source tree for our two separate swig-generated
interfaces.
Despite the convenience of this approach, others will have different needs
that would best be served by allowing the initial *.i file (that includes
the rest of the *.i files) to be somewhere else than the current source
directory so on these general grounds I hope this limitation is removed
at the same time as when the dependency problem is fixed.
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
__
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Swig dependencies not being tested?
Hi all, I know swig support isn't all that great at the moment but was wondering if someone happens to have a working Swig module for cmake that doesn't rebuild every time even without the dependencies having changed. Someone else also pointed out a problem with .i files having to be in the current source dir. If someone's got an updated module please post a link, and maybe someone can tell me if it's possible to make changes to those modules myself. Can I just do that via svn? Hope you're all having a nice day, cputter ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
