[CMake] Re: pkg-config and cache
Andreas Beckermann [EMAIL PROTECTED] writes: The pkg_check_modules() macro works mostly fine (thanks a lot, btw, this saved me a lot of work), however I have one problem with it: once it checked whether the modules are available, it defines a variable __pkg_config_checked_PREFIX in CMakeCache.txt and won't check for these modules again, once that variable is defined. It is a general flaw in CMake which affects other situations too... There is missing something like './config.status --recheck' which would regenerate the cache from scratch with the original cmdline and environment. Enrico pgplw3vUab4LI.pgp Description: PGP signature ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] C# support again
On 6/6/07, Joshua Jensen [EMAIL PROTECTED] wrote: So, for fun, I was trying to implement C# support through some extra .cmake files. It would be good to get a wiki page up about C# issues, so there's some stickiness to various people's efforts. When I apply for game development jobs, I typically bug them about CMake. They often ask does it handle C# ? PC and console game developers tend to use C or C++ for the fast stuff, but they often use C# for GUI-driven production tools that can afford to be slow. I'm too tired to do this right now. Perhaps someone else is more awake and doesn't mind adding a wiki page. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] RE: Is it possible to link against libraries, built
Alexander Ivash wrote: Hello, cmake. Is the subj is possible? I have two cmake-managed projects: the library and tests. And this tests need to be linked against the library. How can I get such result? (Of course I can place tests and library into the same cmakelists.txt, but I think there will be a lot of tests and I don't want to pollute library+examples+tools solution with tests, that is whyI created different project for tests) Have you considered instead 'ADD_SUBDIRECTORY(tests EXCLUDE_FROM_ALL)'? Then you can have one project, but the tests aren't built by default. Thank you! It seems really what I want! The only question now is how to make RUN_TESTS target dependant on all tests. -- Matthew ...yzarc gniog ylwols era uoY -- ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake End of CMake Digest, Vol 38, Issue 16 * ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Reexecute cmake to update build.make
Mathieu Malaterre wrote:
This is a follow up on a previous post.
I have written a simple dependency scanner macro (*). There is still
one dependency missing:
I need to reexecute the CMake macro every time the swig *.i file is
modified.
How do I do that ?
You don't. You add the dependencies directly and let CMake do its magic.
BTW... in the bug list there's already a UseSWIG with dependency
scanning/updating (don't recall who did it).
I attach my modified versions of such (which work with cmake2.5 now),
and also find swig a tad better.
--
Gonzalo Garramuño
[EMAIL PROTECTED]
AMD4400 - ASUS48N-E
GeForce7300GT
Kubuntu Edgy
# - Find SWIG
# This module finds an installed SWIG. It sets the following variables:
# SWIG_FOUND - set to true if SWIG is found
# SWIG_DIR - the directory where swig is installed
# SWIG_EXECUTABLE - the path to the swig executable
SET(SWIG_FOUND FOOBAR)
FIND_PATH(SWIG_DIR
SWIGConfig.cmake
/usr/local/share/swig/1.3.32
/usr/local/share/swig/1.3.31
/usr/local/share/swig/1.3.30
/usr/local/share/swig/1.3.29
/usr/local/share/swig1.3
/usr/share/swig1.3
/usr/lib/swig1.3)
FIND_PATH(SWIG_DIR
swig.swg
/usr/local/share/swig/1.3.32
/usr/local/share/swig/1.3.31
/usr/local/share/swig/1.3.30
/usr/local/share/swig/1.3.29
/usr/local/share/swig1.3
/usr/share/swig1.3
/usr/lib/swig1.3
$ENV{PROGRAMFILES}/swig/1.3.32
$ENV{PROGRAMFILES}/swig/1.3.31
$ENV{PROGRAMFILES}/swig/1.3.30
$ENV{PROGRAMFILES}/swig/1.3.29
$ENV{PROGRAMFILES}/swig1.3
C:/cygwin/usr/local/share/swig/1.3.32
C:/cygwin/usr/local/share/swig/1.3.31
C:/cygwin/usr/local/share/swig/1.3.30
C:/cygwin/usr/local/share/swig/1.3.29
C:/cygwin/usr/share/swig/1.3.32
C:/cygwin/usr/share/swig/1.3.31
C:/cygwin/usr/share/swig/1.3.30
C:/cygwin/usr/share/swig/1.3.29
C:/cygwin/usr/local/share/swig1.3
)
IF(EXISTS ${SWIG_DIR})
IF(x${SWIG_DIR}x STREQUAL x${CMAKE_ROOT}/Modulesx)
MESSAGE(SWIG_DIR should not be modules subdirectory of CMake)
ENDIF(x${SWIG_DIR}x STREQUAL x${CMAKE_ROOT}/Modulesx)
IF(EXISTS ${SWIG_DIR}/SWIGConfig.cmake)
INCLUDE(${SWIG_DIR}/SWIGConfig.cmake)
SET(SWIG_FOUND 1)
ELSE(EXISTS ${SWIG_DIR}/SWIGConfig.cmake)
FIND_PROGRAM(SWIG_EXECUTABLE
NAMES swig1.3 swig
PATHS ${SWIG_DIR} ${SWIG_DIR}/.. ${SWIG_DIR}/../../bin
${SWIG_DIR}/../../../bin )
FIND_PATH( SWIG_USE_FILE_PATH
NAME UseSWIG.cmake
PATHS ${CMAKE_MODULE_PATH} ${CMAKE_ROOT}/Modules )
SET( SWIG_USE_FILE ${SWIG_USE_FILE_PATH}/UseSWIG.cmake )
ENDIF(EXISTS ${SWIG_DIR}/SWIGConfig.cmake)
ENDIF(EXISTS ${SWIG_DIR})
IF(x${SWIG_FOUND}x STREQUAL xFOOBARx)
SET(SWIG_FOUND 0)
IF(EXISTS ${SWIG_DIR})
IF(EXISTS ${SWIG_USE_FILE})
IF(EXISTS ${SWIG_EXECUTABLE})
SET(SWIG_FOUND 1)
ENDIF(EXISTS ${SWIG_EXECUTABLE})
ENDIF(EXISTS ${SWIG_USE_FILE})
ENDIF(EXISTS ${SWIG_DIR})
IF(NOT ${SWIG_FOUND})
IF(${SWIG_FIND_REQUIRED})
MESSAGE(FATAL_ERROR Swig was not found on the system. Please specify the
location of Swig.)
ENDIF(${SWIG_FIND_REQUIRED})
ENDIF(NOT ${SWIG_FOUND})
ENDIF(x${SWIG_FOUND}x STREQUAL xFOOBARx)
# - SWIG module for CMake
# Defines the following macros:
# SWIG_ADD_MODULE(name language [ files ])
# - Define swig module with given name and specified language
# SWIG_LINK_LIBRARIES(name [ libraries ])
# - Link libraries to swig module
# SWIG_GET_WRAPPER_DEPENDENCIES(swigFile genWrapper language DEST_VARIABLE)
# - Put dependencies of the wrapper genWrapper generated by swig from
# swigFile in DEST_VARIABLE
# All other macros are for internal use only.
# To get the actual name of the swig module,
# use: ${SWIG_MODULE_name_REAL_NAME}.
# Set Source files properties such as CPLUSPLUS and SWIG_FLAGS to specify
# special behavior of SWIG. Also global CMAKE_SWIG_FLAGS can be used to add
# special flags to all swig calls.
# Another special variable is CMAKE_SWIG_OUTDIR, it allows one to specify
# where to write all the swig generated module (swig -outdir option)
# The name-specific variable SWIG_MODULE_name_EXTRA_DEPS may be used
# to specify extra dependencies for the generated modules.
SET(SWIG_CXX_EXTENSION cxx)
SET(SWIG_EXTRA_LIBRARIES )
SET(SWIG_PYTHON_EXTRA_FILE_EXTENSION py)
#
# Get dependencies of the generated wrapper.
#
MACRO(SWIG_GET_WRAPPER_DEPENDENCIES swigFile genWrapper language DEST_VARIABLE)
GET_FILENAME_COMPONENT(swig_getdeps_basename ${swigFile} NAME_WE)
GET_FILENAME_COMPONENT(swig_getdeps_outdir ${genWrapper} PATH)
GET_SOURCE_FILE_PROPERTY(swig_getdeps_extra_flags ${swigFile} SWIG_FLAGS)
IF(${swig_getdeps_extra_flags} STREQUAL NOTFOUND)
SET(swig_getdeps_extra_flags )
ENDIF(${swig_getdeps_extra_flags} STREQUAL NOTFOUND)
IF(NOT swig_getdeps_outdir)
SET(swig_getdeps_outdir ${CMAKE_CURRENT_BINARY_DIR})
ENDIF(NOT swig_getdeps_outdir)
SET(swig_getdeps_depsfile
${swig_getdeps_outdir}/swig_${swig_getdeps_basename}_deps.txt)
Re: [CMake] visual studio converter?
2007/6/6, Sylvain Benner [EMAIL PROTECTED]: Jon W a écrit : Are there any tools available to convert Visual Studio files to cmakelists.txt? I have hundreds of vcproj files and this would help make the conversion to cmake easier. I don't know if there are some tools to do this. If you don't find any tool and you have some knowledge about jscript you can do a customized wizard for Visual Studio; it's pretty quick to do. In VS2005, to create a new custom wizard: File - New - Project In General section choose Custom Wizard. I've written a simple hack in Ruby which extracts the most vital parts of a .vcproj file and generates a corresponding CMakeLists.txt. There are a lot of things it doesn't handle (custom build steps, multiple configurations, etc.), but its a good starting point. Feel free to use it; but I make no guarantees. It shouldn't wipe your harddrive, though. I hope. ;-) -- /Jesper vcproj2cmake.rb Description: Binary data ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] creating static library with references to other .lib files
Hi all, I would like to be able to create a static library on Windows which includes an import library to a DLL, so that users of the static library do not need to specify the import library. CMake does not allow me to do this. TARGET_LINK_LIBRARIES( FooLib BarLib ) does not work when creating static libraries. SET_TARGET_PROPERTIES( FooLib PROPERTIES LINK_FLAGS_RELEASE BarLib ) does not work either. What to do? -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Reexecute cmake to update build.make
On 6/7/07, gga [EMAIL PROTECTED] wrote:
Mathieu Malaterre wrote:
This is a follow up on a previous post.
I have written a simple dependency scanner macro (*). There is still
one dependency missing:
I need to reexecute the CMake macro every time the swig *.i file is
modified.
How do I do that ?
You don't. You add the dependencies directly and let CMake do its magic.
There is nothing magic in cmake. If you want a special dependencie to
happen on language other than C/CPP/Java/Fortran to have to specify
them explicitely.
BTW... in the bug list there's already a UseSWIG with dependency
scanning/updating (don't recall who did it).
I forgot to re-mention, that I cannot use this solution as I am using
an older swig executable that do not have -MM flag...
I attach my modified versions of such (which work with cmake2.5 now),
and also find swig a tad better.
...but anyway the very same exact problem occurs:
MACRO(SWIG_GET_WRAPPER_DEPENDENCIES swigFile genWrapper language DEST_VARIABLE)
EXECUTE_PROCESS(
COMMAND ${SWIG_EXECUTABLE} -MM -MF ${swig_getdeps_depsfile}
${swig_getdeps_extra_flags} ${CMAKE_SWIG_FLAGS} -${language} -o ${genWrapper}
${swig_getdeps_include_dirs} ${swigFile}
...
Example, your foo.i depends on bla.h. First time your configure,
dependency will be right, for instance:
Makefile:
...
foo_wrap.cpp: foo.i
foo_wrap.cpp: bla.h
tabswig -o foo_wrap.cpp foo.i
but now edit your foo.i file and add a new header file 'bar.h'. There
is absolutely nothing in the Makefile that will say 'Hey rebuild
foo_wrap.cpp, because it now depends on bar.h'
Thanks for help,
-Mathieu
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Reexecute cmake to update build.make
Mathieu Malaterre wrote: Example, your foo.i depends on bla.h. First time your configure, dependency will be right, for instance: Makefile: ... foo_wrap.cpp: foo.i foo_wrap.cpp: bla.h tabswig -o foo_wrap.cpp foo.i but now edit your foo.i file and add a new header file 'bar.h'. There is absolutely nothing in the Makefile that will say 'Hey rebuild foo_wrap.cpp, because it now depends on bar.h' Sure there is, even without those files I gave you. foo.so depends on foo.obj foo.obj depends on foo_wrap.cxx foo_wrap.cxx depends on foo.i when foo.i changes on disk (you added bar.h), foo_wrap.cxx gets regenerated and recompiled. What's missing by default in cmake is: foo.i depends on bla.h and other.i (this is what swig -MF gives you) so that whenever bla.h or other.i changes, so does foo.so. With the files I gave you and a proper swig with dependencies (ie. swig -MF), you should get that too. Works beautifully. -- Gonzalo Garramuño [EMAIL PROTECTED] AMD4400 - ASUS48N-E GeForce7300GT Kubuntu Edgy ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Reexecute cmake to update build.make
On 6/7/07, gga [EMAIL PROTECTED] wrote: Mathieu Malaterre wrote: Example, your foo.i depends on bla.h. First time your configure, dependency will be right, for instance: Makefile: ... foo_wrap.cpp: foo.i foo_wrap.cpp: bla.h tabswig -o foo_wrap.cpp foo.i but now edit your foo.i file and add a new header file 'bar.h'. There is absolutely nothing in the Makefile that will say 'Hey rebuild foo_wrap.cpp, because it now depends on bar.h' Sure there is, even without those files I gave you. foo.so depends on foo.obj foo.obj depends on foo_wrap.cxx foo_wrap.cxx depends on foo.i when foo.i changes on disk (you added bar.h), foo_wrap.cxx gets regenerated and recompiled. What's missing by default in cmake is: foo.i depends on bla.h and other.i (this is what swig -MF gives you) so that whenever bla.h or other.i changes, so does foo.so. With the files I gave you and a proper swig with dependencies (ie. swig -MF), you should get that too. Works beautifully. It looks like you are on windows. Could you please try a nmake (NMake Makefiles) build and do: 1) edit foo.i $ nmake TargetName vs 2) edit foo.i $ nmake rebuild_cache $ nmake TargetName Version #1 should fail, versus #2 should rebuild build.make, and redo the correct dep. IMHO you think this is working because you are either reexecuting CMake everytime, or Visual Studio has (somehow) a better dependency checking than the Makefile generator (remember CMake is not doing dep in the Visual Studio case). In any case this is not my test case : 1. Makefile (== CMake is doing the dep) 2. Do not explicitely reexecute a configure stage Thanks anyway for your help, Mathieu ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] moving project folder
Hi I configure cmake by writing a CMakeLists.txt file in a source folder. It runs fine. Now if I move the folder to some other location, cmake complains that the files still refer to the previous location. Then I have to edit CMakeCache.txt and replace the project path at 3-4 there. Then it works fine. Is there any elegant way to do this. regards abhijeet - Luggage? GPS? Comic books? Check out fitting gifts for grads at Yahoo! Search.___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] moving project folder
You cannot move a configured project. If you move it you need to clean the build folder and then run cmake again after the move. Warm regards, Kishore From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of abhijeet mhatre Sent: Thursday, June 07, 2007 7:47 PM To: cmake@cmake.org Subject: [CMake] moving project folder Hi I configure cmake by writing a CMakeLists.txt file in a source folder. It runs fine. Now if I move the folder to some other location, cmake complains that the files still refer to the previous location. Then I have to edit CMakeCache.txt and replace the project path at 3-4 there. Then it works fine. Is there any elegant way to do this. regards abhijeet Luggage? GPS? Comic books? Check out fitting gifts for grads http://us.rd.yahoo.com/evt=48249/*http:/search.yahoo.com/search?fr=oni_ on_mailp=graduation+giftscs=bz at Yahoo! Search. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Reexecute cmake to update build.make
Mathieu Malaterre wrote:
It looks like you are on windows. Could you please try a nmake (NMake
Makefiles) build and do:
I'm on Linux (thank god), but have also a windows box with vnc.
I tried it on both, with cmake2.5 (CVS), but cmake2.4 should be the same
( I was using it before ).
1)
edit foo.i
$ nmake TargetName
vs
2)
edit foo.i
$ nmake rebuild_cache
$ nmake TargetName
Version #1 should fail, versus #2 should rebuild build.make, and redo
the correct dep.
Both rebuild TargetName, as they should.
I did find two bugs that were making the stuff less efficient in the
modified UseSWIG.cmake file I posted.
One due to python files always need regeneration due to their .py files
(I was wrapping stuff for ruby, so it is now more efficient for
languages other than python) and that the swig -MF invocation was also
creating the wrapper needlessly.
There's still one minor gotcha where you can still fool the system not
to detect a dependency change, but it is somewhat obscure so I won't
mention it.
--
Gonzalo Garramuño
[EMAIL PROTECTED]
AMD4400 - ASUS48N-E
GeForce7300GT
Kubuntu Edgy
# - SWIG module for CMake
# Defines the following macros:
# SWIG_ADD_MODULE(name language [ files ])
# - Define swig module with given name and specified language
# SWIG_LINK_LIBRARIES(name [ libraries ])
# - Link libraries to swig module
# SWIG_GET_WRAPPER_DEPENDENCIES(swigFile genWrapper language DEST_VARIABLE)
# - Put dependencies of the wrapper genWrapper generated by swig from
# swigFile in DEST_VARIABLE
# All other macros are for internal use only.
# To get the actual name of the swig module,
# use: ${SWIG_MODULE_name_REAL_NAME}.
# Set Source files properties such as CPLUSPLUS and SWIG_FLAGS to specify
# special behavior of SWIG. Also global CMAKE_SWIG_FLAGS can be used to add
# special flags to all swig calls.
# Another special variable is CMAKE_SWIG_OUTDIR, it allows one to specify
# where to write all the swig generated module (swig -outdir option)
# The name-specific variable SWIG_MODULE_name_EXTRA_DEPS may be used
# to specify extra dependencies for the generated modules.
SET(SWIG_CXX_EXTENSION cxx)
SET(SWIG_EXTRA_LIBRARIES )
SET(SWIG_PYTHON_EXTRA_FILE_EXTENSION py)
#
# Get dependencies of the generated wrapper.
#
MACRO(SWIG_GET_WRAPPER_DEPENDENCIES swigFile genWrapper language DEST_VARIABLE)
GET_FILENAME_COMPONENT(swig_getdeps_basename ${swigFile} NAME_WE)
GET_FILENAME_COMPONENT(swig_getdeps_outdir ${genWrapper} PATH)
GET_SOURCE_FILE_PROPERTY(swig_getdeps_extra_flags ${swigFile} SWIG_FLAGS)
IF(${swig_getdeps_extra_flags} STREQUAL NOTFOUND)
SET(swig_getdeps_extra_flags )
ENDIF(${swig_getdeps_extra_flags} STREQUAL NOTFOUND)
IF(NOT swig_getdeps_outdir)
SET(swig_getdeps_outdir ${CMAKE_CURRENT_BINARY_DIR})
ENDIF(NOT swig_getdeps_outdir)
SET(swig_getdeps_depsfile
${swig_getdeps_outdir}/swig_${swig_getdeps_basename}_deps.txt)
GET_DIRECTORY_PROPERTY(swig_getdeps_include_directories INCLUDE_DIRECTORIES)
SET(swig_getdeps_include_dirs)
FOREACH(it ${swig_getdeps_include_directories})
SET(swig_getdeps_include_dirs ${swig_getdeps_include_dirs} -I${it})
ENDFOREACH(it)
EXECUTE_PROCESS(
COMMAND ${SWIG_EXECUTABLE} -MM -MF ${swig_getdeps_depsfile}
${swig_getdeps_extra_flags} ${CMAKE_SWIG_FLAGS} -${language} -o ${genWrapper}
${swig_getdeps_include_dirs} ${swigFile}
RESULT_VARIABLE swig_getdeps_result
ERROR_VARIABLE swig_getdeps_error
OUTPUT_STRIP_TRAILING_WHITESPACE)
IF(NOT ${swig_getdeps_result} EQUAL 0)
MESSAGE(SEND_ERROR Command \${SWIG_EXECUTABLE} -MM -MF
${swig_getdeps_depsfile} ${swig_getdeps_extra_flags} ${CMAKE_SWIG_FLAGS}
-${language} -o ${genWrapper} ${swig_getdeps_include_dirs} ${swigFile}\ failed
with output:\n${swig_getdeps_error})
SET(swig_getdeps_dependencies )
ELSE(NOT ${swig_getdeps_result} EQUAL 0)
FILE(READ ${swig_getdeps_depsfile} ${DEST_VARIABLE})
# Remove the first line
STRING(REGEX REPLACE ^.+: +\n +
${DEST_VARIABLE} ${${DEST_VARIABLE}})
# Clean the end of each line
STRING(REGEX REPLACE +()?\n \n ${DEST_VARIABLE}
${${DEST_VARIABLE}})
# Clean beginning of each line
STRING(REGEX REPLACE \n + \n
${DEST_VARIABLE} ${${DEST_VARIABLE}})
# clean paths
STRING(REGEX REPLACE / ${DEST_VARIABLE}
${${DEST_VARIABLE}})
STRING(REGEX REPLACE \n ;
${DEST_VARIABLE} ${${DEST_VARIABLE}})
ENDIF(NOT ${swig_getdeps_result} EQUAL 0)
ENDMACRO(SWIG_GET_WRAPPER_DEPENDENCIES)
#
# For given swig module initialize variables associated with it
#
MACRO(SWIG_MODULE_INITIALIZE name language)
STRING(TOUPPER ${language} swig_uppercase_language)
STRING(TOLOWER ${language} swig_lowercase_language)
SET(SWIG_MODULE_${name}_LANGUAGE ${swig_uppercase_language})
SET(SWIG_MODULE_${name}_SWIG_LANGUAGE_FLAG ${swig_lowercase_language})
IF(x${SWIG_MODULE_${name}_LANGUAGE}x MATCHES ^xUNKNOWNx$)
MESSAGE(FATAL_ERROR SWIG Error: Language
Re: [CMake] creating static library with references to other .lib files
On 6/7/07, Jesper Eskilson [EMAIL PROTECTED] wrote: Hi all, I would like to be able to create a static library on Windows which includes an import library to a DLL, so that users of the static library do not need to specify the import library. By chance, is your library a C library that is commonly available to the public, i.e. is typically present in Linux or Cygwin distributions and whatnot? If so, you have a problem that will likely sidestep the issue / render it moot. Regardless of the choice of linkage, you could suffer a namespace collision between the version you're maintaining in your own code, and the publically available version. Segfaults etc. Here's the issue in our bug tracker that we haven't resolved yet, it gives a lot of detail as to what kinds of things can go wrong. http://trac.callcc.org/ticket/215 Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] moving project folder
On 6/7/07, abhijeet mhatre [EMAIL PROTECTED] wrote: Hi I configure cmake by writing a CMakeLists.txt file in a source folder. It runs fine. Now if I move the folder to some other location, cmake complains that the files still refer to the previous location. Then I have to edit CMakeCache.txt and replace the project path at 3-4 there. Then it works fine. Is there any elegant way to do this. Do out-of-source builds. When you want the output to appear somewhere else, nuke the output directory and start over. http://www.cmake.org/Wiki/CMake_FAQ You cannot simply move CMake output directories around in the filesystem. They use hardcoded absolute paths for safety, so if you want them somewhere else you must regenerate them. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Is CMake powerful enough?
Hello, We are currently in the process of evaluating whether we shall/can update our build system from make to cmake. We see several problems, which we would like to post here, hoping about enlightenment on how to solve these problems (or not(!)). Perhaps a few words about the project: It's about a generative C++ library for some area of hard problem solving (SAT solving, to be precise, but this shouldn't matter here). Furthermore it is an active library, where using it means extending it, and where the library provides much more services than just header files (and link-libraries); this includes a higher-order test system, a performance measurement system, documentation building, automatic release etc. The point here is that the build system is used permanently by the users of the library, for all sorts of tasks (not just using it once as in configure; make; make install). We are mainly computer scientists, i.e., we cannot afford to be taken hostage by arcane technical details, but we need a more abstract, well-defined system, where we can afford to not working on it, say, for half-a-year, and after returning still after a few hours we can continue working on it. That's the problem with the make-system: There are so many peculiarities, that it's truly a pain maintaining it (especially extending it). So the hope is to find in cmake a powerful *meta-make*, by which we can create in a more abstract way, having more powerful tools at hand, the underlying make-files. Everybody involved creating a generative C++ library likely makes the experience, that it's not so easy, so to make life easier otherwise, 1. we support only Linux, 2. we do not care about any software dependencies, but the system builds locally all required software (compiler, Boost, database, etc.) itself. Now to the problems we see: The directory structure is fractal (or recursive) and dynamic, so for example modules have subdirectories Module/tests, containing generic tests for the components provided by the modules, where Module/tests might contain a tests-subdirectory itself for testing the testsystem etc.; additions are detected automatically, no registrations whatsoever is required for tests, but by running make check all new or changed tests are compiled and executed (of course, the produced link-libraries, executables, text files etc. are stored in some other directory-hierarchy, similar to the source-hierarchy, but, of course, also with many differences). So in the first stage stage of the the build process here, from configuration values, parameter values, targets given and the current state of the file-system we need to compute dynamically the list of second-stage-targets and -rules, and then we need to run make (this is actually achieved by the 2-stage-process of make itself, but it's quite clumsy). It appears now that the computational power of cmake is rather restricted? There seem to be no functions?? (While we had hoped that there are many more than in make?) Even just a shell-call seems to need to be programmed by ourselves?? (I can't believe that, but couldn't find it.) A lesser problem (likely) seems to be that there is no really fine-grained control over where all those auxiliary files go? It seems the basic assumption is that of having a build-directory (used only once), where all sort of stuff can be dumped to, and then with the final make install the relevant files are moved elsewhere? This does not neatly fit with our permanent use of the build-system, but likely one could live with it (by automatically always running make install). Another, perhaps more serious problem: We are exploiting the tree structure of the library, that is, at every point in the tree when calling make exactly the sub-tree at this node is considered (everything down, nothing up). This works very well for example for testing first the local module (we use continuous testing), then going one step up (which needs more time), and before having a break we run make check at the root of the (source-)tree. To avoid cluttering the library with many makefiles, at every node (of the source-tree!) there sits only a *link* to one generic makefile (so we have only *one* makefile!), and that's it. Now the cmake model seems to be, that either you clutter your source-tree with make-files, and then you get the binaries etc. delivered to the source tree (we don't want that), or you create the make-files in the build-tree, but then you have to operate in that tree, not in the source-tree?!? (We find it very convenient to only work in the source-sub-directory we are currently concerned with, and the build system directs all output to the right places (somewhere else); and having to be at two different places at the same time, in the source-directory and in the related build-directory, might open the possibility for subtle bugs.) Finally, it somehow seems to us that the conception of cmake is not really that of a powerful extension of make, but
Re: [CMake] creating static library with references to other .lib files
2007/6/7, Brandon Van Every [EMAIL PROTECTED]: On 6/7/07, Jesper Eskilson [EMAIL PROTECTED] wrote: Hi all, I would like to be able to create a static library on Windows which includes an import library to a DLL, so that users of the static library do not need to specify the import library. By chance, is your library a C library that is commonly available to the public, i.e. is typically present in Linux or Cygwin distributions and whatnot? If so, you have a problem that will likely sidestep the issue / render it moot. Regardless of the choice of linkage, you could suffer a namespace collision between the version you're maintaining in your own code, and the publically available version. Segfaults etc. Here's the issue in our bug tracker that we haven't resolved yet, it gives a lot of detail as to what kinds of things can go wrong. http://trac.callcc.org/ticket/215 I think we have all our bases covered, but thanks anyway. -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Is CMake powerful enough?
On 2007-06-07 20:45+0100 Oliver Kullmann wrote: It appears now that the computational power of cmake is rather restricted? There seem to be no functions?? (While we had hoped that there are many more than in make?) Even just a shell-call seems to need to be programmed by ourselves?? (I can't believe that, but couldn't find it.) cmake can configure generated Makefiles to do most things you can do directly with make. I say most things because I don't want to overgeneralize. However, ADD_CUSTOM_COMMAND is essentially equivalent to a make stanza with prerequisites (cmake file dependencies) and a rule (command). I have used ADD_CUSTOM_COMMAND to do all sorts of things (e.g., build docbook documentation, etc.) Does ADD_CUSTOM_COMMAND satisfy your needs or do you need something more? A lesser problem (likely) seems to be that there is no really fine-grained control over where all those auxiliary files go? True. It seems the basic assumption is that of having a build-directory (used only once), where all sort of stuff can be dumped to, and then with the final make install the relevant files are moved elsewhere? This does not neatly fit with our permanent use of the build-system, but likely one could live with it (by automatically always running make install). The build tree is definitely messy compared with the install tree, but I think you want the build tree since you can run make from subdirectories of it (which is not the case for the install tree, of course.) Also, you can run ctest (or make test) from the build tree (see below). Another, perhaps more serious problem: We are exploiting the tree structure of the library, that is, at every point in the tree when calling make exactly the sub-tree at this node is considered (everything down, nothing up). This works very well for example for testing first the local module (we use continuous testing), then going one step up (which needs more time), and before having a break we run make check at the root of the (source-)tree. To avoid cluttering the library with many makefiles, at every node (of the source-tree!) there sits only a *link* to one generic makefile (so we have only *one* makefile!), and that's it. Now the cmake model seems to be, that either you clutter your source-tree with make-files, and then you get the binaries etc. delivered to the source tree (we don't want that), or you create the make-files in the build-tree, but then you have to operate in that tree, not in the source-tree?!? (We find it very convenient to only work in the source-sub-directory we are currently concerned with, and the build system directs all output to the right places (somewhere else); and having to be at two different places at the same time, in the source-directory and in the related build-directory, might open the possibility for subtle bugs.) You can run make in sub-directories of the build_tree. If you have set up your cmake dependencies properly, then executables get updated properly whenever the source tree is changed. When CMakeLists.txt files are changed in the source tree, this updating includes running cmake to get everything up to date. I always run cmake with a separate build tree so one set of terminal windows is open in various sub-directories of the source tree and one set in various sub-directories of the build tree, and I now think of this as the natural way to develop. Also, you mentioned testing. For that, check out the ADD_TEST command. I know ctest (or the equivalent make test) works in the top directory of the build-tree, and I assume it also works in subdirectories of that tree although I haven't actually tried that. I think you also mentioned distribution. The cpack command is good for this, but is not documented very well yet (however, see http://www.cmake.org/Wiki/CMake:Packaging_With_CPack, and check out the top-level CMakeLists.txt file for CMake itself which sets up CPack to do all the various kinds of distributions of CMake itself). In sum, it is quite possible that cmake is not right for your special needs, but ADD_CUSTOM_COMMAND and ADD_TEST (as well as separate build-tree builds and CPack) are extremely powerful features you should be familiar with before you make a decision. 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] Is CMake powerful enough?
Hi, On Thursday 07 June 2007 15:45, Oliver Kullmann wrote: Hello, ... The directory structure is fractal (or recursive) and dynamic, so for example modules have subdirectories Module/tests, containing generic tests for the components provided by the modules, where Module/tests might contain a tests-subdirectory itself for testing the testsystem etc.; additions are detected automatically, no registrations whatsoever is required for tests, but by running make check all new or changed tests are compiled and executed (of course, the produced link-libraries, executables, text files etc. are stored in some other directory-hierarchy, similar to the source-hierarchy, but, of course, also with many differences). You can detect directories and/or files with cmake, using IF(EXISTS) or FILE(GLOB). This way you can collect at cmake time the directories or files you want to build. If you then add a new file/directory, you will have to touch any of the cmake files to force cmake to run again if you enter make (or run cmake directly). But I would not recommend this (because people will forget to rerun cmake or to touch a file). You can make these things easier by creating your own high-level cmake macros. It appears now that the computational power of cmake is rather restricted? There seem to be no functions?? (While we had hoped that there are many more than in make?) Even just a shell-call seems to need to be programmed by ourselves?? (I can't believe that, but couldn't find it.) Yes, because not all systems supported by cmake have a shell. So you better stay with cmake functions if you want to stay portable (which you don't want). If you want to call external programs, there are different ways in cmake: execute_process - at cmake time add_custom_command/add_custom_target - at build time A lesser problem (likely) seems to be that there is no really fine-grained control over where all those auxiliary files go? It seems the basic assumption is that of having a build-directory (used only once), where all sort of stuff can be dumped to, and then with the final make install the relevant files are moved elsewhere? Yes. But why would you care about helper files in your build tree ? But you can set up the directories where libraries and executables go explicitely by setting the EXECUTABLE_OUTPUT_PATH and LIBRARY_OUTPUT_PATH. ... then you have to operate in that tree, not in the source-tree?!? (We find it very convenient to only work in the source-sub-directory we are currently concerned with, and the build system directs all output to the right places (somewhere else); and having to be at two different places at the same time, in the source-directory and in the related build-directory, might open the possibility for subtle bugs.) While it takes a bit to get used to, building out-of-source has many advantages and once your used to it you don't want to build in-source anymore. -you can have buildtrees for multiple configurations (release, debug) -no file goes into the source tree, so it stays completely clean -you can have buildtrees for different toolchains to check whether they work -you can simply remove the buildtree and rerun cmake so everything's fresh again You really should do it (I also hesitated in the beginning). Finally, it somehow seems to us that the conception of cmake is not really that of a powerful extension of make, but more of a convenient user-interface, with the typical trade-off: What the user-interface does, it does convenient and well, but what it not does is very hard to integrate? CMake is not an extension to make, it is a cross-platform build-file generator (Makefiles, MSVC, XCode, KDevelop projects). It is powerful enough to build sophisticated projects like KDE4, so I doubt there is much it can't do. Bye Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Is CMake powerful enough?
On 6/7/07, Alexander Neundorf [EMAIL PROTECTED] wrote: On Thursday 07 June 2007 15:45, Oliver Kullmann wrote: Finally, it somehow seems to us that the conception of cmake is not really that of a powerful extension of make, but more of a convenient user-interface, with the typical trade-off: What the user-interface does, it does convenient and well, but what it not does is very hard to integrate? CMake is not an extension to make, it is a cross-platform build-file generator (Makefiles, MSVC, XCode, KDevelop projects). It is powerful enough to build sophisticated projects like KDE4, so I doubt there is much it can't do. KDE4, although big, is likely just as mundane as every other average piece of software out there. You're the expert on it; what's particularly dynamic about it? Is it anything more than a big static build tree with some dynamically generated parts? Oliver sounds like he wants crazy dynamic everything with all sorts of elegant CS interfaces and research possibilities etc. This isn't CMake. CMake is a pragmatic tool that generates native cross-platform build files for many compiler and operating system targets. It is geared towards the build processes that most people use. It is not a build systems research tool, and that sounds like what Oliver actually wants. Or at least he thinks he wants. CMake has many users, and it has proven itself in the real world. No research tool has. So I think Oliver and his group need to think about whether they're looking for the ultimate in research abstractions, or whether they want to go with what most have found to be actually useful for typical software. CMake is like GNU Autoconf. CMake is better, faster, more integrated, and is truly cross-platform, i.e. it supports all the versions of MS Visual Studio, and Autoconf never will. A lot of people move to CMake because Autoconf is so painful to work with, and because they need the cross-platform MSVC support. But from a design standpoint, how you actually write your build system, the mentality is the same. There's less to remember, because it's a more integrated and less tweaky design, but it's essentially the same drill. Some people think that a fully featured, elegant, abstract, powerful programming is necessary for a build system. They might be attracted to SCons, for instance, because it is based on Python. Around here, however, most people realize that you don't actually need a fancy language, you need a build system that accomplishes what you actually need to accomplish. Compilers and linkers are ugly, and CMake abstracts a lot of it away. It's worth noting that the KDE crowd dumped SCons in favor of CMake. Apparently, the fancy programming language was not that helpful. But your needs might be truly in the realm of research. If so, chasing down research papers and projects is your best option. Myself, I've gotten very irritated when looking at functional programming languages, only to see build systems based on untyped shells using incredibly error prone system tools. I think the SML/NJ guys got sick of it and did something about it, they made some kind of build tool, but I've never checked it out. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: Re: [CMake] moving project folder
Hi I configure cmake by writing a CMakeLists.txt file in a source folder. It runs fine. Now if I move the folder to some other location, cmake complains that the files still refer to the previous location. Then I have to edit CMakeCache.txt and replace the project path at 3-4 there. Then it works fine. Is there any elegant way to do this. Do out-of-source builds. When you want the output to appear somewhere else, nuke the output directory and start over. http://www.cmake.org/Wiki/CMake_FAQ You cannot simply move CMake output directories around in the filesystem. They use hardcoded absolute paths for safety, so if you want them somewhere else you must regenerate them. Suppose if I want distribute my project with the source code, CMake files and all, how do I do this? I dont mind regenerating build files using cmake . but I dont want to edit the CMakeLists.txt and CMakeCache.txt when I distriubute my project. Is this doable? regards Abhijeet - Get the free Yahoo! toolbar and rest assured with the added security of spyware protection. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
