Re: [CMake] FIND_LIBRARY not finding libtoto.so.1 if libtoto.so linkismissing
Eric Noulard wrote: Is this a FIND_LIBRARY bug or bad installation of the concerned lib? Bad install of lib. -- 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] Programs linked to .a or .so libraries?
Philip Lowman wrote: I've never read that shared libraries are faster than static executables. One would think that, if anything, all of the hoops the OS has to run through to map all of the symbols would cause applications that use shared libraries to be slower to startup then statically built executables. The mapping happens pretty much automatically as it is usually done by an indirect table. This indirect table does add some overhead to runtime execution, but with current machines this is negligible. Loading all the code for a library can take some time (some seconds or minutes), even with today's machines. If the same shared library is used by multiple programs, loading the code in memory needs to happen only once. With static libraries, you always have to load the code regardless and as you say, you keep several copies of the same or similar code in memory. Most modern OSes also support the concept of delay loaded dsos. That is, shared dso files which are loaded only when a function to them is referenced, not just at startup of the executable. This allows an executable to be linked to a shared library but not have to load it unless the user actually uses a function belonging to the dso. There's no way to do that with static linking. Good OSes like linux will also often cache the access to shared libraries, making reopening the same .so several times almost immediate. Static executables are hardly ever cached. If you are also loading a library already used by your window manager (usually some KDE or Gnome library on linux these days, but also some other common libs like libz, libpng, etc), the shared library will probably not even need to be loaded at all, as the window manager already did it for you. Again, with static linking you loose that. All those benefits can lead a program using shared libraries to start up faster than if it had been linked statically. Of course, this does not mean it will indeed do so, just that it may. -- 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] --enable-* with cmake
Brandon Van Every wrote: On 8/8/07, gga [EMAIL PROTECTED] wrote: I know I can pass -D symbols to cmake to modify its behavior and that windows also has its ugly CmakeSetup gui. Ugly? Geez, what are you, a candidate for Windows Aero or something? No, I am a candidate for something that works and ccmake/cmakesetup does not work well. Don't confuse eye candy with functionality. When I mean ugly, I mean there's basic functionality missing from ccmake/cmakesetup. This, unfortunately, clearly rules cmake from being a good candidate to replace autotools, even if its core is much better. The problems with the current approach are: - Variables for configuration are unknown to the user unless he digs into all of the cmake modules used. Compare this to running any autotools project: ./configure (you get full help for all the libs and options you can use). ./cmake (I get cmake's documentation, nothing about my project) ../ccmake (on a clean project) (Nothing) - ccmake/cmakesetup list variables in the cache only. If you are building out of source (as I do), the CMakeCache.txt and the CMakeLists.txt are in different directories, which again can be confusing to a user. - As ccmake/cmakesetup rely on cached variables, a user running the project for the first time will not get ANY variables when he runs ccmake. He HAS to run cmake first. - ccmake/cmakesetup lists pretty much ALL variables. Scary as hell to a user not familiar with your project and tedious to find the variable you need if you do know the project. - AFAIK, -D does not allow DISABLING options, like --disable-X does. The FindXXX modules will take over and find the library even if I told it to disable some library. -- Gonzalo Garramuño [EMAIL PROTECTED] AMD4400 - ASUS48N-E GeForce7300GT Kubuntu Edgy ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] --enable-* with cmake
I'm currently using cmake for a variety of projects. Love it. However, one feature I find myself missing more and more is one from autotools configure scripts: AC_ARG_ENABLE(). That is, the ability to allow the configuration script (ie. cmake) to be run with arbitrary flags to turn on or turn off some options (--enable-X11 for example), regardless of what it finds on the standard paths. Also this option in autoconf allows too have those options available to the user thru a simple help line. I know I can pass -D symbols to cmake to modify its behavior and that windows also has its ugly CmakeSetup gui. However, neither approach seems to me as clean as what's available under autotools. I'm wondering if I have missed something obvious or is there some other approach to achieve the same functionality as autotools. -- 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] Passing -B on linux
Juan Sanchez wrote: When I create a new cmake area, the tests are failing since it cannot find the 64bit version of our tools on linux. Assuming they are installed in /usr/local or /usr, one should expect that to be automatic. That being said... Is there anyway to pass the -B option to C and C++ compiler during the compiler testing phase? Yes. ADD_DEFINITIONS() can be used to pass any flag to both compiler and linker. For more granularity, you can use: SET_SOURCE_FILES_PROPERTIES with the COMPILE_FLAGS property. SET_TARGET_PROPERTIES with the LINK_FLAGS property. Needless to say, a flag like -B will not be portable across compilers, so you'll need to check for the compiler you are using. -- 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] avoid object file recompilation
Timur Ivanov wrote: The problem is that common.cpp recompiled 3 times but I would like not to do that waste of time. Is it possible ? No and Yes. No, cmake in general does not allow to do it easily or reliably. But your OS does. Make common.cpp into either a static or dynamic library and add it to your subprojects. That's why you are using a make system in the first place. -- Gonzalo Garramuño [EMAIL PROTECTED] AMD4400 - ASUS48N-E GeForce7300GT Kubuntu Edgy ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] gettext example?
Does anyone have a simple gettext example being used with cmake? I'm looking for something to automate both the .cpp - .po conversion and merging as well as the .po - .mo creation. -- 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] Patch to FindBoost.cmake.
Andreas Schneider wrote: I've rewritten the FindBoost.cmake from scratch some time ago. And we have improved it at OpenWengo. I suggest to ship this version in CMake. http://cmake-modules.googlecode.com/svn/trunk/Modules/Boost/FindBoost.cmake +1 for this. This is without a doubt the best FindBoost.cmake I've seen so far. -- Gonzalo Garramuño [EMAIL PROTECTED] AMD4400 - ASUS48N-E GeForce7300GT Kubuntu Edgy ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] CMake, RPATH and installs for distribution of a commercial tool
I have a commercial application I'm developing and one feature of cmake is throwing me off. Or, put another way, I'm not quite sure how I can take advantage of it to make it work the way I want. Basically, by default cmake creates executables using the -rpath directive. This is great if you are going to do a local install later on, like when you do make install. That will force a relinking. However, for deploying a commercial application, I really cannot rely on make install. At the same time, to avoid users' confusions and potential library conflicts, I want to distribute the libraries used by my executable into its own platform/lib directory and then just set the LD_LIBRARY_PATH appropriately with a wrapper script, so that the libs I distribute are picked first. At the same time, I do need to copy all the libs I'm using into my own libs directory for distribution. A similar issue with this is the current lack of cmake to allow linking some libraries statically, while others are linked dynamically (which I'd also like to also avoid having to dist so many .so files). Now, the problem with make install and cpack, from what I saw, is that they seem to assume a very simple install a la GNU (and lack some of the features I need). My application requires a somewhat more complex distribution of files as some are cross platform and some are not. As such, I'm using a third party tool for the packaging of the files for installation (installjammer, which is cross platform). I do need to copy all the stuff from my build or development dirs onto a clean preinstall/prepackage location for the third party packaging tool, which I'm currently doing with some special cmake targets. My problem is: - If I leave rpath on, my executable in the build directory is linked against incorrect paths of libraries (some are in /usr/local or development directories), so I cannot just copy it. - If I turn off rpath with CMAKE_SKIP_RPATH, I obtain more or less the behavior I want. However, the link libraries (as shown by ldd) are versioned (which is good), but I have to specifically copy the version of the library like libfoo.5, instead of just copying the symlink for libfoo. This seems also error prone, as RPATH already fixes all that stuff for you to make sure no wrong library is used, and I really don't want to write my own code to figure out what version of the library should be copied for distribution. So... I'm figuring I'm missing something pretty obvious here, as this should be much easier than this. -- 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] MSYS static libraries under MSVC
Brandon Van Every wrote:
I guess this must be a problem with 3rd party libraries. I've never
had this problem with libraries I built myself, either with the MinGW
or the MSYS generators.
Maybe it is me. Whenever I compile libogg, libvorbis, etc. statically
or dynamically, the resulting static or import file remains named .a.
Maybe there's a way to fool autotools to create .lib files?
Interestingly enough, the ffmpeg libraries do build with a .lib suffix
when compiled dynamically and an .a suffix when statically.
What are you passing exactly to TARGET_LINK_LIBRARIES?
TARGET_LINK_LIBRARIES( mrViewer ${LIBRARIES} )
where LIBRARIES contains a bunch of libraries found by FIND_LIBRARIES(),
or, since it does not find libraries named .a, with FIND_FILE().
When run under MSVC, all of these are defined like:
CMAKE_FIND_LIBRARY_SUFFIXES=.lib
CMAKE_IMPORT_LIBRARY_SUFFIX=.lib
CMAKE_STATIC_LIBRARY_SUFFIX=.lib
CMAKE_SHARED_LIBRARY_SUFFIX=.dll
CMAKE_SHARED_MODULE_SUFFIX=.dll
so it makes perfect sense that cmake is trying to find libraries with a
.lib suffix only and then even if given a file called .a it will try to
add the .lib suffix before passing it as a command-line.
I may be able to force cmake to work like I want if I make
CMAKE_FIND_LIBRARY_SUFFIXES=.lib;.a and
CMAKE_STATIC_LIBRARY_SUFFIX=, but then any library passed in should
always come with the .a or .lib suffix.
Is there any way to make this work? I cannot change the extension for
all libraries, as most other libraries will probably be named .lib under
msvc.
Sounds like bugs.
Well, not really. It is not a bug. It is a lack of a feature.
Currently, static libraries can only be .lib.
--
Gonzalo Garramuño
[EMAIL PROTECTED]
AMD4400 - ASUS48N-E
GeForce7300GT
Kubuntu Edgy
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] MSYS static libraries under MSVC
I'm writing a better Find module for using some libraries compiled with MSYS under MSVC (FFMPEG to be more precise). My problem is that FIND_LIBRARY() seems to only search for .lib files, while MSYS static library files are named .a (even though they *are* .lib files compatible with MSVC). Switching to FIND_FILE() to find them, I still find that the TARGET_LINK_LIBRARIES() command will still add them as .lib, so it will end up trying to link in, for example, libogg.a.lib. Is there any way to make this work? I cannot change the extension for all libraries, as most other libraries will probably be named .lib under msvc. -- 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] FIND_PATH / FIND_LIBRARY order
gga wrote:
Currently, using cmake2.5, I am finding the lookup order of FIND_PATH /
FIND_LIBRARY to be counter productive, so I'm wondering if this is a bug
or intended behavior. If intended behavior, I would also want to know
what's the proper way around it.
Okay, no comments so far, so I logged it as a bug -- see bug #5156.
I've looked into it and it seems the order of the definitions in
Modules/Platform/UnixPaths.cmake are wrong.
This is a pretty serious bug that effects unix platforms, but luckily
also easy to fix.
Here's what I belive is a fixed UnixPaths.cmake file.
--
Gonzalo Garramuño
[EMAIL PROTECTED]
AMD4400 - ASUS48N-E
GeForce7300GT
Kubuntu Edgy
SET(CMAKE_SYSTEM_INCLUDE_PATH ${CMAKE_SYSTEM_INCLUDE_PATH}
# Locals first
/usr/local/include /opt/local/include
# Windows API on Cygwin
/usr/include/w32api
# X11
/usr/X11R6/include /usr/include/X11
# Other
/usr/pkg/include
/opt/csw/include /opt/include
# Standard
/usr/include /include
)
SET(CMAKE_SYSTEM_LIBRARY_PATH ${CMAKE_SYSTEM_LIBRARY_PATH}
# User environment first
$ENV{LD_LIBRARY_PATH}
# Locals first
/usr/local/lib /opt/local/lib
# Windows API on Cygwin
/usr/lib/w32api
# X11
/usr/X11R6/lib /usr/lib/X11
# Other
/usr/pkg/lib
/opt/csw/lib /opt/lib
# Standard
/usr/lib /lib
)
SET(CMAKE_SYSTEM_PROGRAM_PATH ${CMAKE_SYSTEM_PROGRAM_PATH}
/usr/local/bin /usr/pkg/bin /usr/bin /sbin /bin
)
SET(CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES
${CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES}
/usr/lib64 /usr/lib32 /usr/lib /lib
)
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FIND_PATH / FIND_LIBRARY order
gga wrote:
Currently, using cmake2.5, I am finding the lookup order of FIND_PATH /
FIND_LIBRARY to be counter productive, so I'm wondering if this is a bug
or intended behavior. If intended behavior, I would also want to know
what's the proper way around it.
Okay, no comments so far, so I logged it as a bug -- see bug #5156.
I've looked into it and it seems the order of the definitions in
Modules/Platform/UnixPaths.cmake are wrong.
This is a pretty serious bug that effects unix platforms.
Here's what I belive is a fixed UnixPaths.cmake file.
--
Gonzalo Garramuño
[EMAIL PROTECTED]
AMD4400 - ASUS48N-E
GeForce7300GT
Kubuntu Edgy
SET(CMAKE_SYSTEM_INCLUDE_PATH ${CMAKE_SYSTEM_INCLUDE_PATH}
# Locals first
/usr/local/include /opt/local/include
# Windows API on Cygwin
/usr/include/w32api
# X11
/usr/X11R6/include /usr/include/X11
# Other
/usr/pkg/include
/opt/csw/include /opt/include
# Standard
/usr/include /include
)
SET(CMAKE_SYSTEM_LIBRARY_PATH ${CMAKE_SYSTEM_LIBRARY_PATH}
# User environment first
$ENV{LD_LIBRARY_PATH}
# Locals first
/usr/local/lib /opt/local/lib
# Windows API on Cygwin
/usr/lib/w32api
# X11
/usr/X11R6/lib /usr/lib/X11
# Other
/usr/pkg/lib
/opt/csw/lib /opt/lib
# Standard
/usr/lib /lib
)
SET(CMAKE_SYSTEM_PROGRAM_PATH ${CMAKE_SYSTEM_PROGRAM_PATH}
/usr/local/bin /usr/pkg/bin /usr/bin /sbin /bin
)
SET(CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES
${CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES}
/usr/lib64 /usr/lib32 /usr/lib /lib
)
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FIND_PATH / FIND_LIBRARY order
Bill Hoffman wrote: So, I guess it depends on the UNIX system you are using... Say on Solaris or HPUX I would expect /usr to come before /usr/local, at least for the system compiler. AFAIK, that's not right. HPUX and Solaris work just like every other Unix distro, and /usr/local is expected to override /usr. LD_LIBRARY_PATH is also expected to override either. Solaris also can use RPATH to override paths (has less precedence than LD_LIBRARY_PATH). SGI uses LD_LIBRARY_PATH, LD_LIBRARYN32_PATH and LD_LIBRARYN64_PATH (depending on architecture). AIX uses LIBPATH instead. See for example (Solaris): http://prefetch.net/blog/index.php/2005/10/06/viewing-shared-library-search-order/ http://prefetch.net/blog/index.php/category/solaris-linker/ It seems a bit dangerous to have a system that has different versions of things in /usr and /usr/local, and to expect the /usr/local one to be picked first. No. Why? /usr/local is still a sudo or admin protected directory (or should be), so your average user cannot screw it up. It allows developers (and sometimes normal users) to have a sandbox to test their stuff without screwing up the rest of the facility. Any error or weird behavior can be checked with ldd on most unices. In the dark ages of computing, when a 2-3Gb hard disk was a luxury and 10baseT was the fastest thing around, it was not uncommon to have /usr/bin and /usr/lib be a network directory in some server while /usr/local remained local to the machine (hence the name of the dir). Today, with linux distros, this concept is still used. It allows you to have your own installed stuff on your machine without screwing up with the stuff the package manager for the distro handles. -- 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] FIND_PATH / FIND_LIBRARY order
Bill Hoffman wrote: /usr/local is not part of any of the systems, and has to be explicitly added by the user in LD_LIBRARY_PATH. Mostly true. Solaris and Linux's ld will also use ldconfig's paths when searching for libraries. Also, the discovery of run time libraries might not always be the same as libraries to link That's why it was listed as a bug and fixed in Edgy :) HP seems to suggest that /usr/local/lib should come after /usr/lib: http://docs.hp.com/en/B2355-90654/ch03s07.html That example shows how to place /usr/local after. Does not say that it is the default or best behavior. If anything, it implies the default behavior is the opposite. I guess my take is that most system tools like ld and such don't even know about /usr/local/lib, so why should cmake search there first? Somewhat agree. I'll admit those were not the best examples. Sigh... I went and read a lot of manuals, which was what I wanted to avoid... Here's a better example about /usr/local, like Debian's policy: http://www.debian.org/doc/debian-policy/ch-opersys.html#s-sysvinit (see point 9.1.2). In its policy /usr/local/lib clearly has to override /usr/lib. BSD does not have a policy about this either, but it has also been tradition since FreeBSD. This probably makes OSX also follow this. You are right however in that Solaris default tools do not touch /usr/local at all. Solaris policy allows it but does not seem to enforce anything about it. Sun is somewhat crazy as they want their users to support /usr/swf/ for custom software, and also uses the more standard but hardly used /opt. Sun is a bit vague about this IMO since their documentation used to also state that its not SysV r4 compliant and they advice you to use /opt/local instead and turn /usr/local into a symlink pointing to it (filesystem(5) solaris 10). Any tool built with autoconf will still place stuff by default in /usr/local (unless run as root). Solaris is madness, basically :) --- You were missing the point, however, that they do point the issue that cmake disregards LD_LIBRARY_PATH, which is an issue. This means something can compile and then fail to run within the same environment, or the other way around -- a library that is found normally is not found by cmake. Also, the problem right now is not that cmake does not search /usr/local, which would be somewhat fine if it didn't. The problem is that it does but it searches for it last, which is certainly wrong behavior. -- 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] cmake VS .net 2003 C++ properties missing
[EMAIL PROTECTED] wrote: Is there something that I can do to correct this? Am I doing something wrong? In digging around, I have not seen anything that indicates I need to do anything different when generating a VS .net 2003 solution from CMake. This seems to be a bug in VS .net that gets triggered by CMake for some weird reason. I had the same issue. I solved it by: Going to the properties of the main project (ie. solution). Usually that one will contain the C++ properties. After the panel appears, switching to other projects will make the panel will also show up in the other projects. At least that worked for me. -- 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] What source control system do you use?
Brandon Van Every wrote: CMake users: what source control systems are you using? For my own projects, I've recently switched to git. After years of using CVS, Subversion and a little of Perforce, git has clearly surpassed them imo. I tried darcs and it was just too slow and painful to use. Mercurial was better, but its speed still left something to be desider. git is not a pain to use anymore unlike what it was a year ago and qgit is maturing to be one of the nicest source control guis I have used. There's now also a pretty usable mingw port of git for windows, which is cool. For other open source projects, mainly Subversion. CVS still gets used every now and then, too, but it is clearly dying. -- 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] Is CMake powerful enough?
Oliver Kullmann wrote: 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). This is not a problem. CMake provides FILE( GLOB ...) and similar constructs to do what you want. It appears now that the computational power of cmake is rather restricted? Hardly. cmake's language has most of the features available on scripting languages (regexes, arrays, macros, variables, etc), albeit implemented in a somewhat more cumbersome syntax than, say, ruby. I'm using cmake on a huge project that requires swig, flex, bison, multiple APIs, 10 different libraries, a different build for each api, 3 OSes, and cmake has really excelled at it (this after having tried to use python's scons, ruby's rake and autoconf for it). scons and rake were not really up to the task. autoconf was, but maintaining it would have been too painful and windows would have needed to be handled separately. cmake has been a life saver. 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 does not have functions, but it does have a very simple to use macro system which in practice acts like functions. Shell calls can be added by ADD_CUSTOM_COMMAND() or EXECUTE_PROGRAM(). The first one creates an actual Makefile rule. The second one gets run only when cmake is run. These functions are very easy to use and can automatically store the outputs and results into cmake variables. 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). This is indeed somewhat of a problem with cmake. Out-of-source builds are not 'built-in' so you need to do something like: mkdir buildir cd buildir cmake .. make CMake provides some variables that can be set to control where output goes (see Wiki - useful variables). With them you can control where .a, .so, executables and the like get placed. The only thing you don't really have as much control over is where .o files go, as CMAKE_BINARY_DIR is more or less broken, but in principle you should not have to worry about that. I am attaching a simple 'mk' bash script I use to run cmake (and normal makefiles) in a cross-platform way (and to simplify the creating of out-of-source builds) and a simple optional FindBuildDir.cmake that, optionally, works with it. I think you'll find that useful in understanding how cmake can be made to work for a large project. 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
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] 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
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
[CMake] Modifying LIBRARY_OUTPUT_PATH dynamically in a macro
I'm trying to change the destination where some shared libraries are
created, trying to place them in subdirectories.
I need to have a macro, which in turn will modify the
LIBRARY_OUTPUT_PATH and create the new library in that new directory. I
have created such a beast. The debug output spits out the path properly
for LIBRARY_OUTPUT_PATH.
Unfortunately, this seems to not work. I am only able to change the
LIBRARY_OUTPUT_PATH in a new CMakeLists.txt file (ie. in a subdir), but
I don't seem to be able to modify it from within a single CMakeLists.txt
file and macro. Cmake does not respect the change and just dumps the
libraries in the previously defined LIBRARY_OUTPUT_PATH location.
# A simple macro to create a maya plugin.
#
# Usage is:
#
# CREATE_MAYA_PLUG_IN(
# mrLiquid 0.7
# test.cpp hello.cpp
# OpenMaya OpenMayaAnim
# )
#
MACRO(CREATE_MAYA_PLUG_IN NAME VERSION SOURCES LIBRARIES)
# define a bunch of maya variables
MAYA_DEFINITIONS()
# split input name into a plugin name and any optional subdir
STRING( REGEX MATCH [^/]+$ PLUGNAME ${NAME} )
STRING( REGEX REPLACE ${PLUGNAME}$ ANYPATH ${NAME} )
# store output path
SET( OLD_LIBRARY_PATH ${LIBRARY_OUTPUT_PATH} )
# make sure subdirs exist
FILE( MAKE_DIRECTORY
${LIBRARY_OUTPUT_PATH}
${LIBRARY_OUTPUT_PATH}/maya${MAYA_VERSION}
)
# change output path
SET( LIBRARY_OUTPUT_PATH
${LIBRARY_OUTPUT_PATH}/maya${MAYA_VERSION}/${ANYPATH} )
# make sure output directory exists
FILE( MAKE_DIRECTORY ${LIBRARY_OUTPUT_PATH} )
# debug the stuff
MESSAGE( STATUS # Creating Maya${MAYA_VERSION} plug-in ${PLUGNAME} in
${LIBRARY_OUTPUT_PATH} # )
# add the plugin
ADD_LIBRARY( ${PLUGNAME} SHARED ${SOURCES} )
TARGET_LINK_LIBRARIES( ${PLUGNAME} ${LIBRARIES} )
# get old link flags
GET_TARGET_PROPERTY( OLD_FLAGS ${PLUGNAME} LINK_FLAGS )
IF( NOT OLD_FLAGS )
SET( OLD_FLAGS )
ENDIF( NOT OLD_FLAGS )
# change properties
SET_TARGET_PROPERTIES(
${PLUGNAME}
PROPERTIES
PREFIX
SUFFIX ${MAYA_EXTENSION}
VERSION${VERSION}
SOVERSION ${VERSION}
LINK_FLAGS ${MAYA_LINK_FLAGS} ${OLD_FLAGS}
)
# revert output directory
SET( LIBRARY_OUTPUT_PATH ${OLD_LIBRARY_PATH} )
ENDMACRO(CREATE_MAYA_PLUG_IN)
--
Gonzalo Garramuño
[EMAIL PROTECTED]
AMD4400 - ASUS48N-E
GeForce7300GT
Kubuntu Edgy
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Modifying LIBRARY_OUTPUT_PATH dynamically in a macro
I'm trying to change the destination where some shared libraries are
created, trying to place them in subdirectories.
I need to have a macro, which in turn will modify the
LIBRARY_OUTPUT_PATH and create the new library in that new directory. I
have created such a beast. The debug output spits out the path properly
for LIBRARY_OUTPUT_PATH.
Unfortunately, this seems to not work. I am only able to change the
LIBRARY_OUTPUT_PATH in a new CMakeLists.txt file (ie. in a subdir), but
I don't seem to be able to modify it from within a single CMakeLists.txt
file and macro. Cmake does not respect the change and just dumps the
libraries in the previously defined LIBRARY_OUTPUT_PATH location.
# A simple macro to create a maya plugin.
#
# Usage is:
#
# CREATE_MAYA_PLUG_IN(
# mrLiquid 0.7
# test.cpp hello.cpp
# OpenMaya OpenMayaAnim
# )
#
MACRO(CREATE_MAYA_PLUG_IN NAME VERSION SOURCES LIBRARIES)
# define a bunch of maya variables
MAYA_DEFINITIONS()
# split input name into a plugin name and any optional subdir
STRING( REGEX MATCH [^/]+$ PLUGNAME ${NAME} )
STRING( REGEX REPLACE ${PLUGNAME}$ ANYPATH ${NAME} )
# store output path
SET( OLD_LIBRARY_PATH ${LIBRARY_OUTPUT_PATH} )
# make sure subdirs exist
FILE( MAKE_DIRECTORY
${LIBRARY_OUTPUT_PATH}
${LIBRARY_OUTPUT_PATH}/maya${MAYA_VERSION}
)
# change output path
SET( LIBRARY_OUTPUT_PATH
${LIBRARY_OUTPUT_PATH}/maya${MAYA_VERSION}/${ANYPATH} )
# make sure output directory exists
FILE( MAKE_DIRECTORY ${LIBRARY_OUTPUT_PATH} )
# debug the stuff
MESSAGE( STATUS # Creating Maya${MAYA_VERSION} plug-in ${PLUGNAME} in
${LIBRARY_OUTPUT_PATH} # )
# add the plugin
ADD_LIBRARY( ${PLUGNAME} SHARED ${SOURCES} )
TARGET_LINK_LIBRARIES( ${PLUGNAME} ${LIBRARIES} )
# get old link flags
GET_TARGET_PROPERTY( OLD_FLAGS ${PLUGNAME} LINK_FLAGS )
IF( NOT OLD_FLAGS )
SET( OLD_FLAGS )
ENDIF( NOT OLD_FLAGS )
# change properties
SET_TARGET_PROPERTIES(
${PLUGNAME}
PROPERTIES
PREFIX
SUFFIX ${MAYA_EXTENSION}
VERSION${VERSION}
SOVERSION ${VERSION}
LINK_FLAGS ${MAYA_LINK_FLAGS} ${OLD_FLAGS}
)
# revert output directory
SET( LIBRARY_OUTPUT_PATH ${OLD_LIBRARY_PATH} )
ENDMACRO(CREATE_MAYA_PLUG_IN)
--
Gonzalo Garramuño
[EMAIL PROTECTED]
AMD4400 - ASUS48N-E
GeForce7300GT
Kubuntu Edgy
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Modifying LIBRARY_OUTPUT_PATH dynamically in a macro
I'm trying to change the destination where some shared libraries are
created, trying to place them in subdirectories.
I need to have a macro, which in turn will modify the
LIBRARY_OUTPUT_PATH and create the new library in that new directory. I
have created such a beast. The debug output spits out the path properly
for LIBRARY_OUTPUT_PATH.
Unfortunately, this seems to not work. I am only able to change the
LIBRARY_OUTPUT_PATH in a new CMakeLists.txt file (ie. in a subdir), but
I don't seem to be able to modify it from within a single CMakeLists.txt
file and macro. Cmake does not respect the change and just dumps the
libraries in the previously defined LIBRARY_OUTPUT_PATH location.
# A simple macro to create a maya plugin.
#
# Usage is:
#
# CREATE_MAYA_PLUG_IN(
# mrLiquid 0.7
# test.cpp hello.cpp
# OpenMaya OpenMayaAnim
# )
#
MACRO(CREATE_MAYA_PLUG_IN NAME VERSION SOURCES LIBRARIES)
# define a bunch of maya variables
MAYA_DEFINITIONS()
# split input name into a plugin name and any optional subdir
STRING( REGEX MATCH [^/]+$ PLUGNAME ${NAME} )
STRING( REGEX REPLACE ${PLUGNAME}$ ANYPATH ${NAME} )
# store output path
SET( OLD_LIBRARY_PATH ${LIBRARY_OUTPUT_PATH} )
# make sure subdirs exist
FILE( MAKE_DIRECTORY
${LIBRARY_OUTPUT_PATH}
${LIBRARY_OUTPUT_PATH}/maya${MAYA_VERSION}
)
# change output path
SET( LIBRARY_OUTPUT_PATH
${LIBRARY_OUTPUT_PATH}/maya${MAYA_VERSION}/${ANYPATH} )
# make sure output directory exists
FILE( MAKE_DIRECTORY ${LIBRARY_OUTPUT_PATH} )
# debug the stuff
MESSAGE( STATUS # Creating Maya${MAYA_VERSION} plug-in ${PLUGNAME} in
${LIBRARY_OUTPUT_PATH} # )
# add the plugin
ADD_LIBRARY( ${PLUGNAME} SHARED ${SOURCES} )
TARGET_LINK_LIBRARIES( ${PLUGNAME} ${LIBRARIES} )
# get old link flags
GET_TARGET_PROPERTY( OLD_FLAGS ${PLUGNAME} LINK_FLAGS )
IF( NOT OLD_FLAGS )
SET( OLD_FLAGS )
ENDIF( NOT OLD_FLAGS )
# change properties
SET_TARGET_PROPERTIES(
${PLUGNAME}
PROPERTIES
PREFIX
SUFFIX ${MAYA_EXTENSION}
VERSION${VERSION}
SOVERSION ${VERSION}
LINK_FLAGS ${MAYA_LINK_FLAGS} ${OLD_FLAGS}
)
# revert output directory
SET( LIBRARY_OUTPUT_PATH ${OLD_LIBRARY_PATH} )
ENDMACRO(CREATE_MAYA_PLUG_IN)
--
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] Modifying LIBRARY_OUTPUT_PATH dynamically in a macro
Filipe Sousa wrote:
you can use
SET_TARGET_PROPERTIES(${target}
PROPERTIES LIBRARY_OUTPUT_DIRECTORY ...)
Really? That propery is not documented at www.cmake.org. However, it
does not seem to work, either -- using cmake 2.4-patch 4.
The library still gets placed directly in the ${LIBRARY_OUTPUT_PATH},
not in ${LIBRARY_OUTPUT_PATH}/${subdir} as I want.
--
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] Modifying LIBRARY_OUTPUT_PATH dynamically in a macro
gga wrote:
Filipe Sousa wrote:
you can use
SET_TARGET_PROPERTIES(${target}
PROPERTIES LIBRARY_OUTPUT_DIRECTORY ...)
Really? That propery is not documented at www.cmake.org. However, it
does not seem to work, either -- using cmake 2.4-patch 4.
The library still gets placed directly in the ${LIBRARY_OUTPUT_PATH},
not in ${LIBRARY_OUTPUT_PATH}/${subdir} as I want.
Never mind. I upgraded to the latest CVS version (cmake2.5) and now it
works.
--
Gonzalo Garramuño
[EMAIL PROTECTED]
AMD4400 - ASUS48N-E
GeForce7300GT
Kubuntu Edgy
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] cmakesetup.exe
Okay, first time trying cmake under windows, porting a project from linux. I'm trying to just create a simple cmake file for vc7.1. I downloaded the pre-built cmake (cmake 2.4 - patch 6). When I run CmakeSetup.exe, there's no option to allow me to select what build to create, as shown in the web docs. It only seems to know how to create a build for vc8. What am I missing? Also, is there a way to avoid this annoying gui and just use cmake command-line and have it create an nmake Makefile (or, better yet, a normal GNU makefile using cl.exe and ld.exe as the toolchain)? -- 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] cmakesetup.exe
Nikita V. Borodikhin wrote: Hello, Gonzalo! I don't think using MSVC programs in GNU Makefile is a very good idea because they (linker in paticular) are not GNU-compatible by flags and arguments. Thanks for the help. Still struggling, thou, due to nmake's crappy system. Sorry, also, as I was not clear. I would like to run microsoft's CL.exe, LIB.exe, etc. tools, but from within a Unix GNU Makefile. A makefile is just a makefile, so the rules can be anything. Currently, if I select cmake -G Unix Makefiles, the makefile generated uses gcc. While if I use -G NMake Makefiles, I get an nmake Makefile compatible with VisualC++. nmake is just such a poor make system compared to the GNU tools that it makes little sense using it. In the project I'm porting, it just dies, as it seems it cannot take rules such as mydirectory/myfile (my project is made of several subprojects). That's why I would rather use cygwin's make instead, but have the makefile create rules for the visual C toolchain, not gcc. Is there any way to make this work? I was hoping porting a cmake project would be trivial, but this is starting to be painful. -- 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] cmakesetup.exe
Bill Hoffman wrote: Can you send a small example that does not work with nmake? Not too small, I'm afraid. Is it okay to post a zip to the list? Or to send you one? I think I'm running into 2 or 3 issues, from what I can tell from the verbose logs. Here's what I have: Under NMake Makefiles (run from cmd.exe): - Linking fails on executable due to not finding WinMain, on even the simplest exe. Unfortunately, VERBOSE=1 does not print the flags, but just a @%TMPDIR/ns.tmp file, which gets removed at the end, so I don't know what flags it is passing. - Linking is using the incorrect debug dll. - Many rules don't work, including make clean which fails with syntax error, due to illegal character '/' in macro. This happens only when I have rules such as subdir/file, which work fine on unix. So far, using rules such as this is the only way I found cmake to create proper out-of-source builds for nested projects. Under Unix Makefiles (run from cygwin bash): - If creating a Unix Makefile with CXX and LD set to cl.exe and lib.exe, during the cmake steps, cmake complains about endianess not detected properly. - cl.exe obj files are incorrectly created with .o suffix. - Many rules don't work, including make clean, where it complains with: target pattern contains no %. Stop. Same thing on Linux works flawlessly, btw. -- Gonzalo Garramuño [EMAIL PROTECTED] AMD4400 - ASUS48N-E GeForce7300GT Kubuntu Edgy ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: [Swig-user] Performance bug in pycontainers.swg
Josh Cherry wrote:
1. The slowness depends (in part, at least) on the fact that there is a
cont.end() call for every iteration. If the code is changed to look like
this:
cont_end = cont.end()
while it != cont.end():
it.next()
it is much faster. Of course, calling end() *should* be constant time.
In C++, maybe, where the compiler may be able to inline the call
completely. When you bind it to a scripting language, end() is always a
function call. This slowdown is unavoidable.
Even in C++, the recommendation is NOT to call end() repeatedly if you
can avoid it, as inlining is just a hint and the compiler could fail to
do it (for whatever reason).
Ondrej Marsalek wrote:
n pyvector pylistpydeque pyset
1024 1.87 25.19 2.40 19.79
Those numbers don't look that right, but they don't look wrong either to
me.
I should also point out that this:
cont = pystl.pylist(xrange(n))
will indeed do a dummy check on each element of the range when *FILLING*
the container, not when iterating thru it. Again, this check cannot be
avoided.
Take this out of the timing and you'll see the numbers perform much better.
Here's for example the test fixed (for ruby):
--
%module li_std_speed
%include std_list.i
%include std_vector.i
%include std_deque.i
%include std_set.i
%template(RbList) std::listswig::GC_VALUE;
%template(RbVector) std::vectorswig::GC_VALUE;
%template(RbDeque) std::dequeswig::GC_VALUE;
%template(RbSet)std::setswig::GC_VALUE;
--
require 'li_std_speed'
include Li_std_speed
require 'benchmark'
def iterate(c)
i = c.begin
e = c.end
while i != e
i.next
end
end
n = 16384
elems = (0..n).to_a
puts '--- build containers (takes long)'
all = {}
[RbVector, RbList, RbDeque, RbSet].each do |klass|
puts build #{klass}
all[klass] = klass.new( elems )
end
puts '--- iterate'
GC.disable # to avoid measuring any GC slowdown
all.each do |klass, c|
Benchmark.benchmark('') do |x|
name = klass.to_s.sub(/.*::/,'') + ' '*5
name = name[0,10]
x.report(#{name} #{n}) { iterate(c) }
end
end
Iteration speed is linear on all containers:
--- build containers (takes long)
build Li_std_speed::RbVector
build Li_std_speed::RbList
build Li_std_speed::RbDeque
build Li_std_speed::RbSet
--- iterate
RbList 16384 0.08 0.00 0.08 ( 0.052038)
RbDeque16384 0.116667 0.00 0.116667 ( 0.061717)
RbVector 16384 0.10 0.00 0.10 ( 0.061583)
RbSet 16384 0.10 0.00 0.10 ( 0.063578)
If, however, assignment is taking into account (this is done with the
container's assign if available), each container behaves quite
differently.
require 'li_std_speed'
include Li_std_speed
require 'benchmark'
n = 16384
@elems = (0..n).to_a
def create_and_iterate(klass)
c = klass.new( @elems )
i = c.begin
e = c.end
while i != e
i.next
end
end
GC.disable # to avoid measuring any GC slowdown
[RbVector, RbList, RbDeque, RbSet].each do |klass|
Benchmark.benchmark('') do |x|
name = klass.to_s.sub(/.*::/,'') + ' '*5
name = name[0,10]
x.report(#{name} #{n}) { create_and_iterate(klass) }
end
end
---
RbVector 16384 4.18 0.03 4.216667 ( 2.550497)
RbList 16384 17.57 0.016667 17.58 ( 10.562868)
RbDeque16384 3.53 0.00 3.53 ( 2.118050)
RbSet 16384 17.07 0.016667 17.08 ( 10.272435)
*NOTE: std::set is slow as expected. std::deque and std::vector are
expected to be relatively fast.
The performance of std::list is weird, as you expect insertions on a
list to be constant time. Problem is, the list copy constructor is
*not* constant, while a std::vector/deque is (usually just a memcpy).
Currently swig is kind of dumb in how copy constructors are handled in
the STL, as the container is actually copied twice when the element
passed in is not another STL container, but the language's native
list/array container.
Summary: no bug.
--
Gonzalo Garramuño
[EMAIL PROTECTED]
AMD4400 - ASUS48N-E
GeForce7300GT
Kubuntu Edgy
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Linking issue under swig
I'm using cmake with swig to wrap several libraries into different modules (currently under Linux). The modules are inter-related. That is, there's a swig base module that needs to be loaded before the derived modules are and there are classes in the derived module that inherit from the base module. My problem is that the derived module crashes and burns upon running, due to a dynamic_cast failing within the swig code. After a lot of hair pulling and doing a simple test-suite, I found out that the culprit is cmake's command-line options. Particularly the linking with: -Wl,-Bsymbolic When that is removed from the linking of the derived module, all works fine and the dynamic casts succeed. Now, my two questions are: a) Where is -Wl,Bsymbolic being defined? I seem not to be able to locate it in any of the modules. Is there any way to turn it off? By default g++ seems to compile with that off. b) Looking at the ld manual, I'll admit I'm not too clear on what that option actually does. Or how to go around debugging what symbol is the one not being bound properly. Anyone can explain help? Perhaps also changing the visibility of some extern declaration may also solve the issue. -- Gonzalo Garramuño [EMAIL PROTECTED] AMD4400 - ASUS48N-E GeForce7300GT Kubuntu Edgy ___ CMake mailing list [EMAIL PROTECTED] http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Linking issue under swig
and sure enough... two seconds after sending the email, I found out that it is one of my own module definition setting -Wl,Bsymbolic. Still... not sure what that does, so any help might be appreciated. I seem to have borrowed the setting from the Makefile of the library I'm linking against. -- Gonzalo Garramuño [EMAIL PROTECTED] AMD4400 - ASUS48N-E GeForce7300GT Kubuntu Edgy ___ CMake mailing list [EMAIL PROTECTED] http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] regarding adding first-class RPM and DPKG support toCPack
Philip Lowman wrote: I gave some thought towards working on adding first-class RPM and DPKG support to CPack tonight. I was just wondering if anyone has toyed around with this idea as of late or if this is something that the CMake project would even be interested in adding. Obviously, I'm just talking binary package support at this point. You might want to take a look at epm (aka. esp): www.easysw.com/epm/ It may be easier to have cmake spit out a file that utility can read rather than you coding all the subtleties of rpm/deb. -- Gonzalo Garramuño [EMAIL PROTECTED] AMD4400 - ASUS48N-E GeForce7300GT Kubuntu Edgy ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Flex/Bison
I'm looking for a macro or library to handle Flex/Bison files/depencies from within cmake. Anyone? -- Gonzalo Garramuño [EMAIL PROTECTED] AMD4400 - ASUS48N-E GeForce7300GT Kubuntu Edgy ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Controlling CMake directories for some files
Hi. I have some code that creates out-of-source builds, by defining: EXECUTABLE_OUTPUT_PATH LIBRARY_OUTPUT_PATH CMAKE_LIBRARY_PATH CMAKE_BUILD_TYPE This is working okay, but my problem is that cmake's build system is still a tad simplistic for my taste. Even when I set all those variables, there are still some files that cmake creates that I don't know how to control. Ideally, I want to have an out-of-source build with 4 main root directories: bin/ obj/ lib/ aux/ where bin, obj and lib should be obvious, and aux should contain any cmake auxiliary files (CMakeCache's, cmake_install, swig files, etc). All of them should be with appropriate subdirectories as needed, to mimic the source tree. Unfortunately, I seem to be unable to redirect things properly. For one, cmake seems to always want to create a CMakeFiles/ directory (and no way to rename that) and dumps CMakeCache's by recreating the source structure, all together with the object files. Is there any way I can obtain some more fine grain control on this? -- 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] Native build system invocation
Roman Yakovenko wrote:
Hi. It seems that I cannot to find answer for pretty simple question:
how I can invoke native build system from\using CMake?
Short answer is that you invoke the native build system as usual (make,
nmake, etc).
Find attached a wrapper bash script I am using for cmake and normal
Makefiles.
It automatically creates out-of-source builds when run under cmake.
For running it on windows, you will need something like cygwin or MSYS
(for bash+uname), albeit it will probably not work as is, as I need to
update the -m32/-m64 flags for VC8 (which I don't have).
For docs, run:
mk -h
PS. If you do any improvements to it, send me a patch.
--
Gonzalo Garramuño
[EMAIL PROTECTED]
AMD4400 - ASUS48N-E
GeForce7300GT
Kubuntu Edgy
#!/bin/bash --norc
#
# Determine CPU architecture
#
KERNEL=`uname -s`
RELEASE=`uname -r`
export CMAKE_BUILD_ARCH=32
export CMAKE_BUILD_TYPE=Release
arch=`uname -a`
if [[ $arch == *x86_64* ]]; then
CMAKE_BUILD_ARCH=64
else
if [[ $arch == *ia64* ]]; then
CMAKE_BUILD_ARCH=64
fi
fi
OS=$KERNEL-$RELEASE
usage()
{
echo $0
echo
echo $0 [options] [--] [make options]
echo
echo Wrapper around CMake to easily create out of source
echo builds (ie. compilations where everything goes into
echo a BUILD/OS-VERSION-\$CMAKE_BUILD_TYPE-\$CMAKE_BUILD_ARCH directory.
echo
echo For this platform (default settings):
echo BUILD/$OS-$CMAKE_BUILD_TYPE-$CMAKE_BUILD_ARCH
echo
echo It must be run from a directory with a valid CMakeLists.txt
echo file outside of the build tree.
echo
echo Options:
echo
echo -q quiet build
echo -j N number of cpus to use (default: ${CMAKE_PROCS=4})
echo
echo debug|release|reldebug|small
echo debug- build a debug build
echo release - build a release build (default)
echo reldebug - build a release build with debug information
echo small- build a small release build
echo
echo clean- Cleans Makefile and CMakeCache.txt
echo
echo both|32|64
echo Builds both 32/64 bit versions, 32-bit only,
echo 64-bit only (default: $CMAKE_BUILD_ARCH)
echo
exit 1
}
#
# Parse command-line options
#
clean=0
opts='VERBOSE=1'
while [ $# -gt 0 ]; do
case $1 in
clean)
shift
if [ -r CMakeLists.txt ]; then
if [ -d BUILD ]; then
clean=1
fi
fi
;;
debug)
shift
export CMAKE_BUILD_TYPE=Debug
;;
release)
shift
export CMAKE_BUILD_TYPE=Release
;;
small)
shift
export CMAKE_BUILD_TYPE=MinSizeRel
;;
both)
shift
CMAKE_BUILD_ARCH='Both'
;;
64)
shift
CMAKE_BUILD_ARCH=64
export LDFLAGS=
export CXXFLAGS=
;;
32)
shift
CMAKE_BUILD_ARCH=32
export LDFLAGS=-m32
export CXXFLAGS=-m32
;;
-h)
shift
usage
;;
--help)
shift
usage
;;
-j)
shift
if [ $# == 0 ]; then
echo Missing parameter for -j!
usage
fi
CMAKE_PROCS=$1
shift
;;
-q)
shift
opts=
;;
--)
shift
break
;;
*)
break
;;
esac
done
#
# Simple function to run a command and print it out
#
run_cmd()
{
echo
echo $*
echo
command $*
}
#
# Function to just run make on a dir with a Makefile
#
run_make()
{
cmd=''
if [[ $KERNEL == *CYGWIN* ]]; then
cmd=nmake $@
else
cmd=make -j ${CMAKE_PROCS=4} $@
fi
run_cmd $cmd
}
#
# Function to run cmake and then run make on generated Makefile
#
run_cmake()
{
builddir=$OS-$CMAKE_BUILD_TYPE-$CMAKE_BUILD_ARCH
echo Buildir ${builddir}
if [ ! -d $builddir ]; then
cmd=mkdir $builddir $builddir/bin $builddir/lib
run_cmd $cmd
fi
cd $builddir
cmd=cmake ../.. -DEXECUTABLE_OUTPUT_PATH=$PWD/bin
-DLIBRARY_OUTPUT_PATH=$PWD/lib -DCMAKE_LIBRARY_PATH=$PWD/lib
-DCMAKE_BUILD_ARCH=$CMAKE_BUILD_ARCH -DCMAKE_BUILD_TYPE=$CMAKE_BUILD_TYPE
run_cmd $cmd
run_make $@
cd ..
}
#
# Function used to clean the build directory and exit
#
run_clean()
{
builddir=$OS-$CMAKE_BUILD_TYPE-$CMAKE_BUILD_ARCH
echo Cleaned BUILD/$builddir
rm -rf BUILD/$builddir
exit 0
}
#
# Main routine
#
if [ $clean == 1 ]; then
run_clean
fi
if [ -r Makefile ]; then
run_make $opts $@
else
if [ ! -r CMakeLists.txt ]; then
usage
fi
if [ ! -d BUILD ]; then
mkdir
Re: [CMake] Native build system invocation
Roman Yakovenko wrote: On 12/26/06, gga [EMAIL PROTECTED] wrote: Thanks for help. I know how to invoke native build system. What I don't know how to make it in portable way - I don't what to know what is the native build system. CMake already knows it, so I would like to reuse that knowledge. Hmm it isn't clear to me what your problem is. There isn't much knowledge to cmake, really. It basically boils down to: a) On windows, use nmake for the microsoft compiler b) On everything else (including compiling for windows' cygwin/mingw), use make The only tricky thing in windows is when people have a mixed environment where they run cygwin bash for their console, but they still do all their compilations using VisualStudio + nmake (I work this way, and most people I know that work in multiplatform projects do too). Another alternative on windows is msys+visual studio (which is now finally becoming as solid as cygwin, without all its bloat). But cmake will also probably get tripped about that unless the CMakeList.txt file checks properly for that. That's one of the reasons why you simple cannot make a wrapper script that will work everywhere, as it depends on how people work on windows. Anyway... coming back to it, cmake does not do anything special. My python is somewhat rusty (since I found ruby, I'm trying to do my best to forget python exists as a language or that I wasted time of my life to learn it and debug all of its headaches)... but... this will work for people on windows that use cmd.exe and bash/tcsh/etc for all else: #!/usr/bin/env python import os os.system(cmake .) if os.name == nt: os.system(nmake) else: os.system(make) Now, for more complex stuff, python's os.name does not distinguish between cygwin, msys, and any linux os, and will just give you 'posix' (unlike ruby's RUBY_PLATFORM that tells you EXACTLY the same as uname). Of course, to make matters worse, you may still be running a python that does not correspond to the environment you will be compiling for... which complicates things. So... your best bet is something nasty like: #!/usr/bin/env python import os os.system(cmake .) if os.name == nt: # # @todo: # # We are running a python compiled with the Microsoft compiler, # but user might still want to run a GNU Makefile, which should be # invoked by 'make'. # Only way to work around that is to open the Makefile and use a regex # to find any special GNU make setting (left as an exercise) # os.system(nmake) else: # See if user set up the Microsoft compiler environment. # if he did, he might be using cygwin/msys with visual studio. if os.environ[MSVCDir] or os.environ['VCINSTALLDIR']: os.system(nmake) else: os.system(make) -- 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] Xcode Generator
Bill Hoffman wrote: With MS IDE, there is no way for us to change the default build type in one of the files we can generate. Hmm... That's probably not right. Not sure about X code, but the MSVC IDE most definitively saves out what's the default build whenever you create a project from the GUI. That information is certainly kept in a file within the MS solution file and not within the windows registry, user directory or install directory. CMake is probably missing the ability to create such a file (or correct line within one of the current files). -- 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] Xcode Generator
Bill Hoffman wrote: Actually, it is not stored in the solution file. It is stored in the .ncb file. This is a binary file, that we do not know the format of. Ah... I see, but... If I am not mistaken, the MS IDE *has* to select some configuration as the default when a project is loaded. I would imagine that it would make the default configuration the first configuration it finds (seems the logical thing to do, anyways, but with Microsoft you never know), so cmake could re-spit the appropriate files changing the order of the configurations. If that's not the case, reverse engineering the file is probably not a good solution as the format of that file can easily change. The best solution is to check whether the user is running cmake on windows and whether the compiler IDE is installed. Most users wanting that feature will probably be running cmake in the same development machine where the IDE is. If that results on a positive, it should be possible to run the MSVC IDE on batch and force it to load the project and then re-save it with the correct setting, using either its COM interface or a simple script on later IDE versions, I would think. For X Code, I imagine something similar could be done but using either an Obj-C / Apple script little program. -- Gonzalo Garramuño [EMAIL PROTECTED] AMD4400 - ASUS48N-E GeForce7300GT Kubuntu Edgy ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Making CMakeLists.txt files work for 32 and 64-bit compiles
New to cmake but so far I love it. First question I have is whether CMake is 32-bits/64-bits aware and whether there is a way to set up a project to compile as either native only, 32-bits only, 64-bits only or both. So far I am unable to find anything of that nature in its built-in configuration files or on-line documentation. I can obviously pass the CPP/LD switches myself, as a work-around, albeit that kind of beats the point, as I am not fully aware of all the appropriate switches in each platform. I'm thinking something along the lines of -DCMAKE_BUILD_TYPE=Release, like -DCMAKE_BUILD_ARCH=64. -- Gonzalo Garramuño [EMAIL PROTECTED] AMD4400 - ASUS48N-E GeForce7300GT Kubuntu Edgy ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
