[CMake] Fwd: CMAKE + SWIG + more wrapped languages
Hallo everybody.
May I ask you for a help with SWIG module in CMake? I need to create more
wrapping libraries from one set of .i SWIG files. To use SWIG from CMake is
really trivial for one wrapped language, but I need to create more wrappers
in one step, as illustrated below:
I have directory structure like this:
wrap
|
+-- Module.i
+-- *.i (other SWIG interface files included by Module.i)
|
+-- python
+-- perl
+-- java
The wrap/CMakeLists.txt looks simple:
SUBDIRS(python perl java)
And for example wrap/python/CMakeLists.txt looks like (the CMakeLists will
look similarly for perl and java packages):
# Find and include required packages
FIND_PACKAGE( SWIG REQUIRED )
FIND_PACKAGE( PythonLibs REQUIRED )
INCLUDE( ${SWIG_USE_FILE} )
# Set include python path
INCLUDE_DIRECTORIES( ${PYTHON_INCLUDE_PATH} )
# Generated file is C++, tell it to SWIG
SET_SOURCE_FILES_PROPERTIES( Module.i PROPERTIES CPLUSPLUS ON )
# ! Tell to SWIG that .i files are one directory up !
SET_SOURCE_FILES_PROPERTIES( Module.i PROPERTIES SWIG_FLAGS -I../)
# Create wrapper
SWIG_ADD_MODULE( module python Module.i )
SWIG_LINK_LIBRARIES( module python2.4 )
# Copy the generated files as post-build step
ADD_CUSTOM_COMMAND( TARGET ${SWIG_MODULE_module_REAL_NAME}
POST_BUILD
COMMAND ${CMAKE_COMMAND}
ARGS -E copy ${CMAKE_CURRENT_BINARY_DIR}/*.py
${CMAKE_CURRENT_SOURCE_DIR} )
#
ADD_CUSTOM_COMMAND( TARGET${SWIG_MODULE_module_REAL_NAME}
POST_BUILD
COMMAND ${CMAKE_COMMAND}
ARGS -E copy ${CMAKE_CURRENT_BINARY_DIR}/*.so
${CMAKE_CURRENT_SOURCE_DIR} )
However, when the build process is started, it finishes by error:
make[5]: Entering directory `/home//build//wrap/python'
make[5]: *** No rule to make target `/home//wrap/python/Module.i',
needed by `/home//build//wrap/python/Module_wrap.c'. Stop.
When I looked at .../build/python/Makefile, there is target:
/home//build//wrap/python/Module_wrap.c:
/home//wrap/python/Module.i
@echo Building Swig
source /home//build/wrap/python/Module_wrap.c...
/usr/bin/swig -python -I/usr/include/python2.4 -o
/home//build//wrap/python/Module_wrap.c /home//wrap/python/Module.i
However, there is no -I../ switch specified by
SET_SOURCE_FILES_PROPERTIES( Module.i PROPERTIES SWIG_FLAGS -I../).
Moreover, there is absolute path to the Module.i which is, however, wrong.
When I tries to call SWIG directly, but only with Module.i it was OK - the
-I switch seems to ensure the right path.
I have also tried to set relative paths during CMake configuration, but it
leaded to other errors during the build.
Could someone give me a hint how to solve this problem? Did I choose the
right approach, or should it be solved in different way? Or how to instruct
CMake not to use the whole path to .i file (neither absolute, nor relative)?
Any help will really be appreciated.
Thank you very much,
Dan
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Fwd: CMAKE + SWIG + more wrapped languages
Daniel,
I figured out a solution which is more a trick than anything else. Basically,
I created an empty .i file as a stub for each language. For example, you have
Module.i and you could add ModulePython.i which contains:
%include Module.i. I then use CMake with these stubs.
This works but I then run into a long known issue with the CMake SWIG macro,
i.e. the dependencies don't handle files included by SWIG using the %include.
I believe there is a ticket opened for this issue.
Anton
- Original Message -
From: Daniel Tihelka [EMAIL PROTECTED]
Date: Monday, July 24, 2006 4:47 am
Subject: [CMake] Fwd: CMAKE + SWIG + more wrapped languages
Hallo everybody.
May I ask you for a help with SWIG module in CMake? I need to
create more
wrapping libraries from one set of .i SWIG files. To use SWIG from
CMake is
really trivial for one wrapped language, but I need to create more
wrappersin one step, as illustrated below:
I have directory structure like this:
wrap
|
+-- Module.i
+-- *.i (other SWIG interface files included by Module.i)
|
+-- python
+-- perl
+-- java
The wrap/CMakeLists.txt looks simple:
SUBDIRS(python perl java)
And for example wrap/python/CMakeLists.txt looks like (the
CMakeLists will
look similarly for perl and java packages):
# Find and include required packages
FIND_PACKAGE( SWIG REQUIRED )
FIND_PACKAGE( PythonLibs REQUIRED )
INCLUDE( ${SWIG_USE_FILE} )
# Set include python path
INCLUDE_DIRECTORIES( ${PYTHON_INCLUDE_PATH} )
# Generated file is C++, tell it to SWIG
SET_SOURCE_FILES_PROPERTIES( Module.i PROPERTIES CPLUSPLUS ON )
# ! Tell to SWIG that .i files are one directory up !
SET_SOURCE_FILES_PROPERTIES( Module.i PROPERTIES SWIG_FLAGS -I../)
# Create wrapper
SWIG_ADD_MODULE( module python Module.i )
SWIG_LINK_LIBRARIES( module python2.4 )
# Copy the generated files as post-build step
ADD_CUSTOM_COMMAND( TARGET ${SWIG_MODULE_module_REAL_NAME}
POST_BUILD
COMMAND ${CMAKE_COMMAND}
ARGS -E copy
${CMAKE_CURRENT_BINARY_DIR}/*.py${CMAKE_CURRENT_SOURCE_DIR} )
#
ADD_CUSTOM_COMMAND( TARGET${SWIG_MODULE_module_REAL_NAME}
POST_BUILD
COMMAND ${CMAKE_COMMAND}
ARGS -E copy
${CMAKE_CURRENT_BINARY_DIR}/*.so${CMAKE_CURRENT_SOURCE_DIR} )
However, when the build process is started, it finishes by error:
make[5]: Entering directory `/home//build//wrap/python'
make[5]: *** No rule to make target
`/home//wrap/python/Module.i', needed by
`/home//build//wrap/python/Module_wrap.c'. Stop.
When I looked at .../build/python/Makefile, there is target:
/home//build//wrap/python/Module_wrap.c:
/home//wrap/python/Module.i @echo Building Swig
source /home//build/wrap/python/Module_wrap.c...
/usr/bin/swig -python -I/usr/include/python2.4 -o
/home//build//wrap/python/Module_wrap.c
/home//wrap/python/Module.i
However, there is no -I../ switch specified by
SET_SOURCE_FILES_PROPERTIES( Module.i PROPERTIES SWIG_FLAGS -
I../). Moreover, there is absolute path to the Module.i which
is, however, wrong.
When I tries to call SWIG directly, but only with Module.i it was
OK - the
-I switch seems to ensure the right path.
I have also tried to set relative paths during CMake
configuration, but it
leaded to other errors during the build.
Could someone give me a hint how to solve this problem? Did I
choose the
right approach, or should it be solved in different way? Or how to
instruct CMake not to use the whole path to .i file (neither
absolute, nor relative)?
Any help will really be appreciated.
Thank you very much,
Dan
___
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] CMAKE + SWIG + more wrapped languages
Great, this is a good idea, thank you very much!
I have tried to create wrap/python/ModulePy.i including the original
wrap/Module.i only, and when it was called as
.../python $ swig -c++ -python -I../ Module.py
everything seemed to be OK (well, I did not try to compile it, I just saw the
module.p and Module_wrap.cxx generated). So even if tricky, it seems to
work.
However, there is still the issue with -I../ flag set to the SWIG through
CMake list files: the setting of:
SET_SOURCE_FILES_PROPERTIES( Module.i PROPERTIES SWIG_FLAGS -I../)
does not work. The -I../ does not appear in the SWIG call. This call is copied
from
http://www.cmake.org/Wiki/CMake_FAQ#How_do_I_use_CMake_to_generate_SWIG_wrapper_libraries.3F;.
I have also tried to use CMAKE_SWIG_FLAGS instead of SWIG_FLAGS, but the
behavior is the same. Unfortunately, there is not much written about
the Mastering CMake book, which I have.
Do you know anything about it?
Thank you very much,
regards
Dan
BTW: the dependency issue means that CMake dos not check changes in .i files
(or the change of date), in order to call SWIG to generate new wrapper
classes?
On Monday 24 July 2006 13:47, ANTON DEGUET wrote:
Daniel,
I figured out a solution which is more a trick than anything else.
Basically, I created an empty .i file as a stub for each language. For
example, you have Module.i and you could add ModulePython.i which contains:
%include Module.i. I then use CMake with these stubs.
This works but I then run into a long known issue with the CMake SWIG
macro, i.e. the dependencies don't handle files included by SWIG using the
%include. I believe there is a ticket opened for this issue.
Anton
- Original Message -
From: Daniel Tihelka [EMAIL PROTECTED]
Date: Monday, July 24, 2006 4:47 am
Subject: [CMake] Fwd: CMAKE + SWIG + more wrapped languages
Hallo everybody.
May I ask you for a help with SWIG module in CMake? I need to
create more
wrapping libraries from one set of .i SWIG files. To use SWIG from
CMake is
really trivial for one wrapped language, but I need to create more
wrappersin one step, as illustrated below:
I have directory structure like this:
wrap
+-- Module.i
+-- *.i (other SWIG interface files included by Module.i)
+-- python
+--perl
+-- java
The wrap/CMakeLists.txt looks simple:
SUBDIRS(python perl java)
And for example wrap/python/CMakeLists.txt looks like (the
CMakeLists will
look similarly for perl and java packages):
# Find and include required packages
FIND_PACKAGE( SWIG REQUIRED )
FIND_PACKAGE( PythonLibs REQUIRED )
INCLUDE( ${SWIG_USE_FILE} )
# Set include python path
INCLUDE_DIRECTORIES( ${PYTHON_INCLUDE_PATH} )
# Generated file is C++, tell it to SWIG
SET_SOURCE_FILES_PROPERTIES( Module.i PROPERTIES CPLUSPLUS ON )
# ! Tell to SWIG that .i files are one directory up !
SET_SOURCE_FILES_PROPERTIES( Module.i PROPERTIES SWIG_FLAGS -I../)
# Create wrapper
SWIG_ADD_MODULE( module python Module.i )
SWIG_LINK_LIBRARIES( module python2.4 )
# Copy the generated files as post-build step
ADD_CUSTOM_COMMAND( TARGET ${SWIG_MODULE_module_REAL_NAME}
POST_BUILD
COMMAND ${CMAKE_COMMAND}
ARGS -E copy
${CMAKE_CURRENT_BINARY_DIR}/*.py${CMAKE_CURRENT_SOURCE_DIR} )
#
ADD_CUSTOM_COMMAND( TARGET${SWIG_MODULE_module_REAL_NAME}
POST_BUILD
COMMAND ${CMAKE_COMMAND}
ARGS -E copy
${CMAKE_CURRENT_BINARY_DIR}/*.so${CMAKE_CURRENT_SOURCE_DIR} )
However, when the build process is started, it finishes by error:
make[5]: Entering directory `/home//build//wrap/python'
make[5]: *** No rule to make target
`/home//wrap/python/Module.i', needed by
`/home//build//wrap/python/Module_wrap.c'. Stop.
When I looked at .../build/python/Makefile, there is target:
/home//build//wrap/python/Module_wrap.c:
/home//wrap/python/Module.i @echo Building Swig
source /home//build/wrap/python/Module_wrap.c...
/usr/bin/swig -python -I/usr/include/python2.4 -o
/home//build//wrap/python/Module_wrap.c
/home//wrap/python/Module.i
However, there is no -I../ switch specified by
SET_SOURCE_FILES_PROPERTIES( Module.i PROPERTIES SWIG_FLAGS -
I../). Moreover, there is absolute path to the Module.i which
is, however, wrong.
When I tries to call SWIG directly, but only with Module.i it was
OK - the
-I switch seems to ensure the right path.
I have also tried to set relative paths during CMake
configuration, but it
leaded to other errors during the build.
Could someone give me a hint how to solve this problem? Did I
Re: [CMake] CMAKE + SWIG + more wrapped languages
I am sorry - the previous mail was wrong. The directives:
SET_SOURCE_FILES_PROPERTIES( ErisPython.i PROPERTIES CPLUSPLUS
ON )
SET_SOURCE_FILES_PROPERTIES( ErisPython.i PROPERTIES SWIG_FLAGS -I../)
seems to work fine. The -I../ flag is set in the SWIG call. I had to miss
something.
I am sorry again, and thank you very much for your help!
Dan
On Monday 24 July 2006 14:22, Daniel Tihelka wrote:
Great, this is a good idea, thank you very much!
I have tried to create wrap/python/ModulePy.i including the original
wrap/Module.i only, and when it was called as
.../python $ swig -c++ -python -I../ Module.py
everything seemed to be OK (well, I did not try to compile it, I just saw
the module.p and Module_wrap.cxx generated). So even if tricky, it seems
to work.
However, there is still the issue with -I../ flag set to the SWIG through
CMake list files: the setting of:
SET_SOURCE_FILES_PROPERTIES( Module.i PROPERTIES SWIG_FLAGS -I../)
does not work. The -I../ does not appear in the SWIG call. This call is
copied from
http://www.cmake.org/Wiki/CMake_FAQ#How_do_I_use_CMake_to_generate_SWIG_wr
apper_libraries.3F. I have also tried to use CMAKE_SWIG_FLAGS instead of
SWIG_FLAGS, but the behavior is the same. Unfortunately, there is not much
written about the Mastering CMake book, which I have.
Do you know anything about it?
Thank you very much,
regards
Dan
BTW: the dependency issue means that CMake dos not check changes in .i
files (or the change of date), in order to call SWIG to generate new
wrapper classes?
On Monday 24 July 2006 13:47, ANTON DEGUET wrote:
Daniel,
I figured out a solution which is more a trick than anything else.
Basically, I created an empty .i file as a stub for each language. For
example, you have Module.i and you could add ModulePython.i which
contains: %include Module.i. I then use CMake with these stubs.
This works but I then run into a long known issue with the CMake SWIG
macro, i.e. the dependencies don't handle files included by SWIG using
the %include. I believe there is a ticket opened for this issue.
Anton
- Original Message -
From: Daniel Tihelka [EMAIL PROTECTED]
Date: Monday, July 24, 2006 4:47 am
Subject: [CMake] Fwd: CMAKE + SWIG + more wrapped languages
Hallo everybody.
May I ask you for a help with SWIG module in CMake? I need to
create more
wrapping libraries from one set of .i SWIG files. To use SWIG from
CMake is
really trivial for one wrapped language, but I need to create more
wrappersin one step, as illustrated below:
I have directory structure like this:
wrap
+-- Module.i
+-- *.i (other SWIG interface files included by Module.i)
+-- python
+-- perl
+-- java
The wrap/CMakeLists.txt looks simple:
SUBDIRS(python perl java)
And for example wrap/python/CMakeLists.txt looks like (the
CMakeLists will
look similarly for perl and java packages):
# Find and include required packages
FIND_PACKAGE( SWIG REQUIRED )
FIND_PACKAGE( PythonLibs REQUIRED )
INCLUDE( ${SWIG_USE_FILE} )
# Set include python path
INCLUDE_DIRECTORIES( ${PYTHON_INCLUDE_PATH} )
# Generated file is C++, tell it to SWIG
SET_SOURCE_FILES_PROPERTIES( Module.i PROPERTIES CPLUSPLUS ON )
# ! Tell to SWIG that .i files are one directory up !
SET_SOURCE_FILES_PROPERTIES( Module.i PROPERTIES SWIG_FLAGS -I../)
# Create wrapper
SWIG_ADD_MODULE( module python Module.i )
SWIG_LINK_LIBRARIES( module python2.4 )
# Copy the generated files as post-build step
ADD_CUSTOM_COMMAND( TARGET ${SWIG_MODULE_module_REAL_NAME}
POST_BUILD
COMMAND ${CMAKE_COMMAND}
ARGS -E copy
${CMAKE_CURRENT_BINARY_DIR}/*.py${CMAKE_CURRENT_SOURCE_DIR} )
#
ADD_CUSTOM_COMMAND( TARGET${SWIG_MODULE_module_REAL_NAME}
POST_BUILD
COMMAND ${CMAKE_COMMAND}
ARGS -E copy
${CMAKE_CURRENT_BINARY_DIR}/*.so${CMAKE_CURRENT_SOURCE_DIR} )
However, when the build process is started, it finishes by error:
make[5]: Entering directory `/home//build//wrap/python'
make[5]: *** No rule to make target
`/home//wrap/python/Module.i', needed by
`/home//build//wrap/python/Module_wrap.c'. Stop.
When I looked at .../build/python/Makefile, there is target:
/home//build//wrap/python/Module_wrap.c:
/home//wrap/python/Module.i @echo Building Swig
source /home//build/wrap/python/Module_wrap.c...
/usr/bin/swig -python -I/usr/include/python2.4 -o
/home//build//wrap/python/Module_wrap.c
/home//wrap/python/Module.i
However, there is no -I../
Re: [CMake] CMakeSetup broken, fails in the root directory
At 09:49 PM 7/22/2006, William A. Hoffman wrote: At 06:09 PM 7/22/2006, William A. Hoffman wrote: OK, found the problem. It seems to have been broken for some time now, but the fix should make it in 2.4.3 when that is ready. It should be in cvs soon, after I run all the tests. I spoke to soon the fix worked with makefiles but not visual studio projects. It may take a bit longer... A fix has been checked into CVS: Checking for path: /cvsroot/CMake/CMake/Source Unrestricted user: hoffman Checking for path: /cvsroot/CMake/CMake/Source/kwsys Unrestricted user: hoffman /cvsroot/CMake/CMake/Source/cmLocalVisualStudio7Generator.cxx,v -- cmLocalVis ualStudio7Generator.cxx new revision: 1.141; previous revision: 1.140 /cvsroot/CMake/CMake/Source/kwsys/SystemTools.cxx,v -- SystemTools.cxx new revision: 1.170; previous revision: 1.169 -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Fwd: CMAKE + SWIG + more wrapped languages
ANTON DEGUET wrote: Daniel, This works but I then run into a long known issue with the CMake SWIG macro, i.e. the dependencies don't handle files included by SWIG using the %include. I believe there is a ticket opened for this issue. Yes, this is quite annoying. I've been looking at trying to implement the work around described in this ticket. http://public.kitware.com/Bug/bug.php?op=showbugid=1731 This is the source code for the hack, but you will have to dig it out. I'm still trying to decipher the relevant code and make a simple macro that does what I think it should. I'll post that code as soon as I get something working, unless someone else has some http://www.itk.org/cgi-bin/viewcvs.cgi/Wrapping/CSwig/CMakeLists.txt?rev=1.55root=Insightview=auto James ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Testing shared library
Hi,
I am trying to test a shared library using cmake. In my top level
directory, I have the source directory (src), which contains the source
files to build the library, and a test directory (test), which contains
the source files to build the binaries that will be used to test the
shared library. The problem is the binaries in the test diretory are not
being compiled properly, i. e., they are not being linked against the
shared library in the src directory. In autotools, the shared library
was added as one obj file, like:
g++ -o test1 obj1.o obj2.o ../src/libmylib.so
I was not able to configure CMake to produce a similar command line.
How can I achieve this ?
I am using the following piece of code:
SET( SRC test1.cpp test2.cpp test3.cpp )
ENABLE_TESTING()
MACRO( ADD_TESTS SRC_LIST )
FOREACH( IN_FILE ${SRC_LIST} )
STRING( REGEX REPLACE .cpp TARGET_NAME ${IN_FILE} )
ADD_EXECUTABLE( ${TARGET_NAME} ${IN_FILE} test.cpp )
TARGET_LINK_LIBRARIES( ${TARGET_NAME} mylib )
ADD_TEST( ${TARGET_NAME} ${TARGET_NAME} )
ENDFOREACH( IN_FILE )
ENDMACRO( ADD_TESTS )
LINK_DIRECTORIES( ../src )
ADD_TESTS( ${SRC} )
Flavio
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Fortran question
I have a simple Fortran project that I am testing with cmake.
PROJECT(multi_patch Fortran)
SET( SRCS
aAdjKeep.f
Main_mp.f
)
ADD_EXECUTABLE(multi_patch ${SRCS})
However, the first file is a Fortran 95 module and when I try to build I get
the following error.
Scanning dependencies of target multi_patch
Building Fortran object CMakeFiles/multi_patch.dir/aAdjKeep.o
Error copying Fortran module for. Tried FOR.mod and for.mod.
If I just do a
gfortran -c aAdjKeep.f
it compiles and creates aadjkeep.mod.
What is the status of the Fortran support. Where is a good starting place to
look in the code base to see what is going on?
Karl
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Problems I have
One of the persons indicated that more info is required ito the problems that I have. I am busy compiling/capturing problems, but the results are kind of big. How should I handle that in terms of posting? Louis. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Testing shared library
Flávio P. Duarte wrote: Hi, I am trying to test a shared library using cmake. In my top level directory, I have the source directory (src), which contains the source files to build the library, and a test directory (test), which contains the source files to build the binaries that will be used to test the shared library. The problem is the binaries in the test diretory are not being compiled properly, i. e., they are not being linked against the shared library in the src directory. In autotools, the shared library was added as one obj file, like: g++ -o test1 obj1.o obj2.o ../src/libmylib.so I was not able to configure CMake to produce a similar command line. How can I achieve this ? CMake will generate a command line like g++ -o test1 obj1.o obj2.o -L../src -lmylib What problem are you having with this version? Note also that when linking to another target in the same project with TARGET_LINK_LIBRARIES you do not need to add the LINK_DIRECTORIES explicitly. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Problems I have
Louis Kruger wrote: One of the persons indicated that more info is required ito the problems that I have. I am busy compiling/capturing problems, but the results are kind of big. How should I handle that in terms of posting? Just cut-and-paste the portion of your log at which the first error message is reported. Include a few extra lines of context above and below the error. Thanks, -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] RPATH questions
On 2006-07-24 11:14-0400 Brad King wrote: If you don't set BUILD_WITH_INSTALL_RPATH or SKIP_BUILD_RPATH properties then the modules built into the build tree will have the proper rpath to load from there. Thanks for that useful information which I have just confirmed. I have also just confirmed that the rpath properties propagate in the build tree without any special intervention. What I mean by that is I have two target libraries: libplplotcxxd which depends on libplplotd but which has no direct dependend on libltdl, and libplplotd which depends on libltdl in a special location. Here are the ldd results: ldd bindings/c++/libplplotcxxd.so libplplotd.so.9 = /home/software/plplot_cvs/HEAD/build_dir/src/libplplotd.so.9 (0xb7fa2000) libltdl.so.3 = /home/software/autotools/install/lib/libltdl.so.3 (0xb7f9b000) ... ldd src/libplplotd.so libm.so.6 = /lib/tls/libm.so.6 (0xb7f7b000) libltdl.so.3 = /home/software/autotools/install/lib/libltdl.so.3 (0xb7f73000) ... So all is well in the build tree, but see below for the bad install tree results. Then just set the INSTALL_RPATH property to the desired rpath for the installed version. When you run make install a separate copy will be linked and installed with the modified rpath. Summary: Just set INSTALL_RPATH on the module target to be the rpath needed in the install tree. Then things will just work. I followed that advice for INSTALL_RPATH with libplplotd, and it worked, but unlike the build tree case it did not automatically propagate to libplplotcxxd. Here are the ldd results for the install location: ldd ~/plplot_cvs/installcmake/lib/libplplotd.so libm.so.6 = /lib/tls/libm.so.6 (0xb7f7b000) libltdl.so.3 = /home/software/autotools/install/lib/libltdl.so.3 (0xb7f73000) ... ldd ~/plplot_cvs/installcmake/lib/libplplotcxxd.so libplplotd.so.9 = /home/software/plplot_cvs/installcmake/lib/libplplotd.so.9 (0xb7fa3000) libltdl.so.3 = /usr/lib/libltdl.so.3 (0xb7f87000) Note, the last one is the system libltdl.so location which is out of date and which I therefore want to consistently avoid. Note, libplplotcxxd has no direct dependencies on libltdl so the only reason why it even knows about libltdl is through its dependency on the libplplotd target. So why doesn't it automatically pick up the correct INSTALL_RPATH information from that target? Is this a bug in CMake-2.4.2? Of course, I can presumably work around this CMake-2.4.2 limitation by supplying INSTALL_RPATH information to every target in my project which depends on the libplplot target, but there are a lot of targets in my project and virtually all of them depend on the libplplot core library so this is quite a messy workaround. 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 Yorick front-end to PLplot (yplot.sf.net); 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] RPATH questions
Alan W. Irwin wrote:
On 2006-07-24 11:14-0400 Brad King wrote:
Summary: Just set INSTALL_RPATH on the module target to be the rpath
needed in the install tree. Then things will just work.
I followed that advice for INSTALL_RPATH with libplplotd, and it worked,
but
unlike the build tree case it did not automatically propagate to
libplplotcxxd. Here are the ldd results for the install location:
ldd ~/plplot_cvs/installcmake/lib/libplplotd.so
libm.so.6 = /lib/tls/libm.so.6 (0xb7f7b000)
libltdl.so.3 = /home/software/autotools/install/lib/libltdl.so.3
(0xb7f73000)
...
ldd ~/plplot_cvs/installcmake/lib/libplplotcxxd.so
libplplotd.so.9 =
/home/software/plplot_cvs/installcmake/lib/libplplotd.so.9 (0xb7fa3000)
libltdl.so.3 = /usr/lib/libltdl.so.3 (0xb7f87000)
Note, the last one is the system libltdl.so location which is out of date
and which I therefore want to consistently avoid.
Note, libplplotcxxd has no direct dependencies on libltdl so the only
reason
why it even knows about libltdl is through its dependency on the libplplotd
target. So why doesn't it automatically pick up the correct INSTALL_RPATH
information from that target? Is this a bug in CMake-2.4.2?
Of course, I can presumably work around this CMake-2.4.2 limitation by
supplying INSTALL_RPATH information to every target in my project which
depends on the libplplot target, but there are a lot of targets in my
project and virtually all of them depend on the libplplot core library so
this is quite a messy workaround.
No attempt has been made in CMake to implement automatic propagation of
INSTALL_RPATH settings. This may be added in the future.
For now you'll have to set the rpath on all targets individually. You
can do this pretty cleanly by creating a macro to make a target a client
of libplplotd:
MACRO(MAKE_PLPLOTD_CLIENT target)
TARGET_LINK_LIBRARIES(${target} libplpotd)
SET_TARGET_PROPERTIES(${target} PROPERTIES INSTALL_RPATH ...)
ENDMACRO(MAKE_PLPLOTD_CLIENT)
ADD_LIBRARY(plplotcxxd SHARED ...)
MAKE_PLPLOTD_CLIENT(plplotcxxd)
-Brad
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Fortran question
Karl Merkley wrote:
I have a simple Fortran project that I am testing with cmake.
PROJECT(multi_patch Fortran)
SET( SRCS
aAdjKeep.f
Main_mp.f
)
ADD_EXECUTABLE(multi_patch ${SRCS})
However, the first file is a Fortran 95 module and when I try to build I get
the following error.
Scanning dependencies of target multi_patch
Building Fortran object CMakeFiles/multi_patch.dir/aAdjKeep.o
Error copying Fortran module for. Tried FOR.mod and for.mod.
If I just do a
gfortran -c aAdjKeep.f
it compiles and creates aadjkeep.mod.
What is the status of the Fortran support. Where is a good starting place to
look in the code base to see what is going on?
Unfortunately we don't have time to debug/fix problems with the module
support for Fortran ourselves. Use grep to look for references to
fortran in the CMake/Source directory. In particular you might look for
cmake_copy_f90_mod to see code related to this error message.
-Brad
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] CMakelists.txt non-trivial examples?
Im setting up the build environment for our project and Ive been looking around to find some examples of how to create CMakelists.txt files and the only examples Ive come across so far are the trivial ones on the cmake page and the crazy convoluted ones (well, from my novice perspective) from kde, vtk and such. Are there any other places that I can look to find some examples while I wait for my cmake book to arrive in the mail? Any pointers would be useful. Thanks The project is a mixture of java and C++. Ill have multiple executables created from common libraries (in our jargon, many Products reusing the same Component(s)) and theres a code generator that creates an unknown number of files that the rest of the project has a dependency on. The dir structure looks kinda like whats below Project Common (same structure as below) Components (same structure as below) Products (same structure as below) Services Service_a (same structure as below) Service_b (same structure as below) Service_c Bin Docs Lib Src Test I just downloaded the cmake source, so maybe thatll shed some light on things. Thanks Richard ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMakelists.txt non-trivial examples?
Hi Richard, Richard Fuchs wrote: Are there any other places that I can look to find some examples while I wait for my cmake book to arrive in the mail? Any pointers would be useful. Thanks I found the latest Scribus (http://www.scribus.net) CVS source to be quite helpful as an example when I made the switch over to CMake for my project. Best, Scott ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMakelists.txt non-trivial examples?
Richard Fuchs wrote: Im setting up the build environment for our project and Ive been looking around to find some examples of how to create CMakelists.txt files and the only examples Ive come across so far are the trivial ones on the cmake page and the crazy convoluted ones (well, from my novice perspective) from kde, vtk and such. I actively develop the CMake build for the Chicken Scheme compiler. http://www.call-with-current-continuation.org/index.html Chicken is a fairly small project. There is only 1 subdirectory and 2 CMakeLists.txt files. It has a lot of non-trivial stuff for the problem of bootstrapping a compiler. In particular, a lot of dependencies on generated files and exes. You can get the latest CMake build from the Darcs repository. We still don't ship the CMake build in the official tarballs as the build is still provisional. Only today did I wipe out the last major build impediment, I think. Directions for how to obtain and build the CMake build are in the official tarball sources though. Look for INSTALL-CMake.txt. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] RPATH questions
On 2006-07-24 13:22-0700 Alan W. Irwin wrote: On 2006-07-24 11:14-0400 Brad King wrote: If you don't set BUILD_WITH_INSTALL_RPATH or SKIP_BUILD_RPATH properties then the modules built into the build tree will have the proper rpath to load from there. Thanks for that useful information which I have just confirmed. I have also just confirmed that the rpath properties propagate in the build tree without any special intervention. What I mean by that is I have two target libraries: libplplotcxxd which depends on libplplotd but which has no direct dependend on libltdl, and libplplotd which depends on libltdl in a special location. Here are the ldd results: ldd bindings/c++/libplplotcxxd.so libplplotd.so.9 = /home/software/plplot_cvs/HEAD/build_dir/src/libplplotd.so.9 (0xb7fa2000) libltdl.so.3 = /home/software/autotools/install/lib/libltdl.so.3 (0xb7f9b000) ... ldd src/libplplotd.so libm.so.6 = /lib/tls/libm.so.6 (0xb7f7b000) libltdl.so.3 = /home/software/autotools/install/lib/libltdl.so.3 (0xb7f73000) ... So all is well in the build tree, [...] Well, there is one caveat (which turns out to be the source of most of my confusion in this area). If you find your external library using FIND_LIBRARY and pass that result to TARGET_LINK_LIBRARIES, then Brad's assertion that you don't have to do anything special in the build tree with RPATH is correct. That is what I did above, and that is why I got a good result. BTW, when you print out that result on Linux it is the complete path + filename, e.g., /home/software/autotools/install/lib/libltdl.so. However, if you use PKGCONFIG (which I must use to find dependencies of another target for my PLplot project), that returns library locations as a combination of -L and -l options. When those are passed to TARGET_LINK_LIBRARIES, the link step occurs without errors but the rpath information for the external library is dropped in the build tree. Presumably this occurs because those -L and -l flags are just passed directly to the linker without any RPATH interpretation by TARGET_LINK_LIBRARIES. The workaround for this PKGCONFIG build-tree RPATH issue is to follow each PKGCONFIG step with FIND_LIBRARY using the PATH information determined by PKGCONFIG. This puts the result in a form that TARGET_LINK_LIBRARIES can interpret correctly with respect to RPATH. _Then_, all is well in the build tree with regard to RPATH with no special intervention required. Thanks, Brad, for your responses to my comments and questions including your recent confirmation that I am going to have to apply INSTALL_RPATH for every target that depends on my main library. You have been most helpful. 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 Yorick front-end to PLplot (yplot.sf.net); 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] Building a library with a complex hierarchy
Hello, I'm going to begin with the usual I'm not sure this is the right place to post this, but hopefully it is, so with that done I can get on to my real question. I'm trying to build a game engine, or rather what is currently there, I'm currently developing. The output of the build is supposed to be a library, a shared one is preferable, and a few functional tests I will worry about later. The problem is that I'm not quite sure on how to structure the build, as the directory hierarchy is a little more complex than I'm used to. The directories of the project root (just to show what my situation is): core i18n math subsystem util With core/ being the most interesting part at the moment. core: eventsystem log time worldobject kernel memorymanager datamanager script threadmanager My first thought was to compile all the different parts into their own libraries and then link them all into a common shared one. This, apperently, wasn't possible and maybe not a very clever way to do it. Simply having a ADD_LIBRARY with all the source files would look very ugly, and be error prone. Another way to do it could be by defining lots of varibles, but that doesn't sound very good to me either. So if anyone could give me a hint on how to do this, or a good documentation on writing builds for these kind of more complicated projects (doesn't have to be cmake), it'd be very happy. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Building a library with a complex hierarchy
At 09:00 PM 7/24/2006, Tilo Wiklund wrote: Hello, I'm going to begin with the usual I'm not sure this is the right place to post this, but hopefully it is, so with that done I can get on to my real question. I'm trying to build a game engine, or rather what is currently there, I'm currently developing. The output of the build is supposed to be a library, a shared one is preferable, and a few functional tests I will worry about later. The problem is that I'm not quite sure on how to structure the build, as the directory hierarchy is a little more complex than I'm used to. The directories of the project root (just to show what my situation is): core i18n math subsystem util With core/ being the most interesting part at the moment. core: eventsystem log time worldobject kernel memorymanager datamanager script threadmanager My first thought was to compile all the different parts into their own libraries and then link them all into a common shared one. This, apperently, wasn't possible and maybe not a very clever way to do it. Simply having a ADD_LIBRARY with all the source files would look very ugly, and be error prone. Another way to do it could be by defining lots of varibles, but that doesn't sound very good to me either. So if anyone could give me a hint on how to do this, or a good documentation on writing builds for these kind of more complicated projects (doesn't have to be cmake), it'd be very happy. ___ How is this project currently built? That might be a good place to start. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Building a library with a complex hierarchy
On 2006-07-25 03:00+0200 Tilo Wiklund wrote: My first thought was to compile all the different parts into their own libraries and then link them all into a common shared one. This, apperently, wasn't possible and maybe not a very clever way to do it. Simply having a ADD_LIBRARY with all the source files would look very ugly, and be error prone. I would go for a multiple libraries approach, and have them link to each other. However, with this approach you have to be careful of the direction of dependencies so that you avoid cross-dependencies or circular dependencies between libraries. So for example, if liba depends on libb (i.e., libb resolves symbols in liba), and libb depends on libc, then you cannot have libc depending back on libb or liba, and libb cannot depend on liba. Also, you should consider whether certain parts of your project would best by dynamically loaded using plug-ins (i.e., the library or executable optionally loads the plug-in at run-time at user request rather than the run-time loader always loading all components of the project software). The PLplot project went through this sort of assessment several years ago. It was a lot of work, but well worth it in the end. The result is a lean/mean shared core library which does nothing but core plotting functions, a number of languages interfaces which are implemented as shared libraries which link to the core library, and a lot of different plotting device plug-ins. Each plug-in is dynamically loaded by the core library only if the user requests that particular device. And, yes, we historically implemented all of this with autotools, but my project to also do the same with cmake is nearly finished, and I quite like the results (especially the speed!) 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 Yorick front-end to PLplot (yplot.sf.net); 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
