[CMake] Cmake and Libltdl
Hi, I'm new to cmake and want to port a C++ project which is now built using autotools to cmake build system. The project has some libraries (we call them modules) which are used in two applications. The applications uses lt_dladdsearchdir to add the path where to search the modules and then uses the lt_dlopenext and lt_dlsym to register the modules. When using cmake, do I need to use ltdl as well or will cmake replace the way the libraries are found and registered? Thanks and sorry if the question doesn't make sense at all. Greetings, Carlos ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Various problems deploying a python module
Hi list,
I try to write a cmake script for a python module. Its finally working
now, but the solution I came up with is not very nice.
1. Finding the correct python environment:
I have two python frameworks on my mac: Python2.5 which comes with OS
X, and python2.6 from macports. If I just use
FIND_PACKAGE(PythonInterp) and FIND_PACKAGE(PythonLibs) I end up
getting the python2.6 interpreter from macports but the python2.5 libs
from OS X.
I solved it by manually setting the path to python2.6 libraries and
headers in INCLUDE_DIRECTORIES and TARGET_LINK_LIBRARIES but this is
quite ugly because it may break on another system wit a different path
prefix for macports.
Is there any way to set the desired python version for PythonInterp and
PythonLibs in cmake?
2. Renaming the library file:
This is probably very simple, but I startet wih cmake today: How do I
change the filename of my library/module? The module is called
libvlfeat.so, however python expects C modules to be named _name.so.
(In my case _vlfeat.so).
How do I do that?
3. Copy python files during installation
The python module needs some python files along with the compiled C
module. Currently, I just copy all the stuff using cmakes file()
command. That means, all files are created when the user types in
cmake .. It would be better if the files would not be copied until
the user says make install.
Is there a way that the file() commands are somehow converted to
similar commands in the makefile?
Thanks in advance,
Janosch
=== CMakeLists.txt ===
cmake_minimum_required(VERSION 2.8)
project(vlfeat)
set(CMAKE_VERBOSE_MAKEFILE off)
set(LIBRARY_OUTPUT_DIRECTORY python/vlfeat)
#set(CMAKE_C_FLAGS -msse -dynamiclib)
file(GLOB CFILES vl/*.c)
file(GLOB MSER python/vlfeat/mser/*.cpp)
file(GLOB SIFT python/vlfeat/sift/*.cpp)
file(GLOB IMOP python/vlfeat/imop/*.cpp)
file(GLOB MISC python/vlfeat/misc/*.cpp)
file(GLOB KMEANS python/vlfeat/kmeans/*.cpp)
add_library( vlfeat MODULE
${CFILES} ${MSER} ${SIFT} ${IMOP} ${MISC} ${KMEANS}
python/vlfeat/py_vlfeat.cpp
)
SET_TARGET_PROPERTIES(vlfeat PROPERTIES LINKER_LANGUAGE C)
FIND_PACKAGE(PythonInterp)
FIND_PACKAGE(PythonLibs)
find_package( Boost 1.36.0 COMPONENTS python)
execute_process( COMMAND python -c from distutils.sysconfig import
get_python_lib; print get_python_lib() OUTPUT_VARIABLE
PYTHON_SITE_PACKAGES OUTPUT_STRIP_TRAILING_WHITESPACE )
INCLUDE_DIRECTORIES(.
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6
${PYTHON_INCLUDE_DIRS} ${PYTHON_SITE_PACKAGES}/numpy/core/include
${Boost_INCLUDE_DIRS})
TARGET_LINK_LIBRARIES(vlfeat ${Boost_LIBRARIES}
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/Python
${PYTHON_LIBRARIES})
file(MAKE_DIRECTORY ${PYTHON_SITE_PACKAGES}/vlfeat)
file(GLOB PLOTOP_PY python/vlfeat/plotop/*.py)
file(GLOB MSER_PY python/vlfeat/mser/*.py)
file(GLOB KMEANS_PY python/vlfeat/kmeans/*.py)
file(COPY ${PLOTOP_PY} DESTINATION ${PYTHON_SITE_PACKAGES}/vlfeat/plotop)
file(COPY ${MSER_PY} DESTINATION ${PYTHON_SITE_PACKAGES}/vlfeat/mser)
file(COPY ${KMEANS_PY} DESTINATION ${PYTHON_SITE_PACKAGES}/vlfeat/kmeans)
file(COPY python/vlfeat/__init__.py DESTINATION
${PYTHON_SITE_PACKAGES}/vlfeat)
install(TARGETS vlfeat LIBRARY DESTINATION ${PYTHON_SITE_PACKAGES}/vlfeat)
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Choice of compilers
Hi Alok: I have changed the subject line to something more appropriate. On 2010-06-16 22:25-0700 Alok Govil wrote: Alan wrote: Isn't that the complete issue? My experience (under Wine, but the principle is the same) is you must have mingw32-make.exe on your PATH in order for -G MinGW Makefiles to work. So you will have to be careful of dependencies, but you should be able to download and unpack mingw32-make.exe from the normal SF location for that (under mingw) while keeping the normal MinGW gcc compilers off your PATH (since you want to use the different compilers, MinGW-W32 and MinGW-W64). I did not realize that cmake calls mingw32-make.exe, since the user has to call it explicitly after running cmake. But I see now. Cmake tries compiling as a part of finding the compilation tools. tries compiling is part of the story, but the CMake generator you choose with the -G option also configures the build tool. So Unix Makefiles configures Makefiles under Linux that GNU make can understand, MinGW Makefiles configures Makefiles under either Windows or Wine which mingw-make.exe understands, etc. That configuration fails if the build tool (GNU make, mingw-make.exe, etc.) is not available. Your suggestion worked, for both W32 and W64. I used -G MinGW Makefiles for both cases. Good. This also works with CMake 2.8 stable/release version. So I still cannot figure what's new in RC2 with respect to MinGW-W64. Since it works, there is no issue really. That's good as well. In fact that is pretty typical of CMake. Normally, new versions just work like the old. Just like CMake is able to distinguish different versions of Visual Studio, would it distinguish MinGW-32 with MinGW-64 also (which means either both would be in path simultaneously, or neither would be, and cmake picks the right one based on the generator specifed)? Let me know if so, and I'll be happy to test this. I had never heard of those MinGW variants until you mentioned them, and it appears CMake is not specifically aware of them either. I presume that's why you had to rename to gcc.exe (something CMake specifically recognizes) to get them to work. But that is a brute-force way to get CMake to recognize a compiler with a different name. I would forget the renaming, and instead use CMAKE_LANG_COMPILER (e.g., CMAKE_C_COMPILER, CMAKE_CXX_COMPILER, etc.) to allow you to choose which compiler (the 32-bit variant or 64-bit variant) you want to use. See the CMake documentation for how to use CMAKE_LANG_COMPILER. 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 __ ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Choice of compilers
Hi Alan, Just like CMake is able to distinguish different versions of Visual Studio, would it distinguish MinGW-32 with MinGW-64 also (which means either both would be in path simultaneously, or neither would be, and cmake picks the right one based on the generator specifed)? Let me know if so, and I'll be happy to test this. I had never heard of those MinGW variants until you mentioned them, and it appears CMake is not specifically aware of them either. I presume that's why you had to rename to gcc.exe (something CMake specifically recognizes) to get them to work. But that is a brute-force way to get CMake to recognize a compiler with a different name. I would forget the renaming, and instead use CMAKE_LANG_COMPILER (e.g., CMAKE_C_COMPILER, CMAKE_CXX_COMPILER, etc.) to allow you to choose which compiler (the 32-bit variant or 64-bit variant) you want to use. See the CMake documentation for how to use CMAKE_LANG_COMPILER. Just FYI: Reading the change-log for RC1 and RC2 (see below), I assuming that CMake has gained ability to build on MinGW-W64 (see below). As I now know, CMake 2.8 builds on MinGW-W64 already. Changes in CMake 2.8.2-rc1 (since 2.8.1): - Build on Tru64 (#10542) - Build on mingw-w64 ... I'll look into your suggestion again. In general, the prefixes and renaming issue with MinGW is a MinGW issue I would think. And this needs to be done not just for g++.exe, but some 15-20 .exe files in the bin folder. In fact to keep things compatible with different tools, they already put one file under several names! Best regards - Alok _ The New Busy is not the too busy. Combine all your e-mail accounts with Hotmail. http://www.windowslive.com/campaign/thenewbusy?tile=multiaccountocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_4___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Various problems deploying a python module
On 2010-06-17 16:23:09 +0200, Janosch Peters said: 3. Copy python files during installation The python module needs some python files along with the compiled C module. Currently, I just copy all the stuff using cmakes file() command. That means, all files are created when the user types in cmake .. It would be better if the files would not be copied until the user says make install. Is there a way that the file() commands are somehow converted to similar commands in the makefile? Ok I found out myself that this can be done with the INSTALL command, too. -- Janosch ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [vtkusers] VTK 5.6.0 Cmake Errors
On Thu, Jun 17, 2010 at 3:16 PM, Scott Johnson scott.john...@neuwave.com wrote: On a whim I totally changed the path to a different drive and naming structure and tried again. I was able to fully configure and generate the solution. Even after I set the options I was originally trying. I'm not sure where it was picking up the invalid path, but it's gone now. Is this a network path without short filename support? John ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Choice of compilers
On 6/17/2010 11:07 AM, Alok Govil wrote: Hi Alan, Just like CMake is able to distinguish different versions of Visual Studio, would it distinguish MinGW-32 with MinGW-64 also (which means either both would be in path simultaneously, or neither would be, and cmake picks the right one based on the generator specifed)? Let me know if so, and I'll be happy to test this. I had never heard of those MinGW variants until you mentioned them, and it appears CMake is not specifically aware of them either. I presume that's why you had to rename to gcc.exe (something CMake specifically recognizes) to get them to work. But that is a brute-force way to get CMake to recognize a compiler with a different name. I would forget the renaming, and instead use CMAKE_LANG_COMPILER (e.g., CMAKE_C_COMPILER, CMAKE_CXX_COMPILER, etc.) to allow you to choose which compiler (the 32-bit variant or 64-bit variant) you want to use. See the CMake documentation for how to use CMAKE_LANG_COMPILER. Just FYI: Reading the change-log for RC1 and RC2 (see below), I assuming that CMake has gained ability to build on MinGW-W64 (see below). As I now know, CMake 2.8 builds on MinGW-W64 already. Changes in CMake 2.8.2-rc1 (since 2.8.1): - Build on Tru64 (#10542) - Build on mingw-w64 ... I'll look into your suggestion again. In general, the prefixes and renaming issue with MinGW is a MinGW issue I would think. And this needs to be done not just for g++.exe, but some 15-20 .exe files in the bin folder. In fact to keep things compatible with different tools, they already put one file under several names! This has some information about the build on mingw64 and the choice of make: http://public.kitware.com/Bug/view.php?id=10690 -Bill ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[Cmake-commits] CMake branch, next, updated. v2.8.1-1435-gd2c75bd
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, next has been updated via d2c75bd0014099019e85bc13e956f4c7f4cc8441 (commit) via 9082fc8a4738b985fbb763af0bdee69ba9a52a23 (commit) via d7f8df694a16dde126ae3b5712027ab0dfea6a72 (commit) from e97fb728383556c1b574efffeff1d81a3e9fa8ae (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d2c75bd0014099019e85bc13e956f4c7f4cc8441 commit d2c75bd0014099019e85bc13e956f4c7f4cc8441 Merge: e97fb72 9082fc8 Author: David Cole david.c...@kitware.com Date: Thu Jun 17 17:17:24 2010 -0400 Merge branch 'vs10-path-issue' into next http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9082fc8a4738b985fbb763af0bdee69ba9a52a23 commit 9082fc8a4738b985fbb763af0bdee69ba9a52a23 Author: David Cole david.c...@kitware.com Date: Thu Jun 17 17:12:57 2010 -0400 Use full path file names in generate.stamp.list. The full path file names are important for Visual Studio 10, which apparently changes the current working directory when running custom command rules. diff --git a/Source/cmGlobalVisualStudio8Generator.cxx b/Source/cmGlobalVisualStudio8Generator.cxx index e423174..6e0f048 100644 --- a/Source/cmGlobalVisualStudio8Generator.cxx +++ b/Source/cmGlobalVisualStudio8Generator.cxx @@ -154,8 +154,6 @@ void cmGlobalVisualStudio8Generator::AddCheckTarget() stampFile += /; stampFile += cmake::GetCMakeFilesDirectoryPostSlash(); stampFile += generate.stamp; -stampFile = generators[0]-Convert(stampFile.c_str(), - cmLocalGenerator::START_OUTPUT); fout stampFile \n; stamps.push_back(stampFile); } --- Summary of changes: Source/cmGlobalVisualStudio8Generator.cxx |2 -- Source/kwsys/kwsysDateStamp.cmake |2 +- 2 files changed, 1 insertions(+), 3 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v2.8.1-1348-gabe355e
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via abe355ef1ca075c78dfea75f808a256b052699ec (commit) from d7f8df694a16dde126ae3b5712027ab0dfea6a72 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=abe355ef1ca075c78dfea75f808a256b052699ec commit abe355ef1ca075c78dfea75f808a256b052699ec Author: KWSys Robot kwro...@kitware.com Date: Fri Jun 18 00:01:02 2010 -0400 KWSys Nightly Date Stamp diff --git a/Source/kwsys/kwsysDateStamp.cmake b/Source/kwsys/kwsysDateStamp.cmake index 30d812d..b15685c 100644 --- a/Source/kwsys/kwsysDateStamp.cmake +++ b/Source/kwsys/kwsysDateStamp.cmake @@ -18,4 +18,4 @@ SET(KWSYS_DATE_STAMP_YEAR 2010) SET(KWSYS_DATE_STAMP_MONTH 06) # KWSys version date day component. Format is DD. -SET(KWSYS_DATE_STAMP_DAY 17) +SET(KWSYS_DATE_STAMP_DAY 18) --- Summary of changes: Source/kwsys/kwsysDateStamp.cmake |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
