[CMake] make in a subdir takes ages.
Hiya, I'm using cmake in koffice and I work in a small library currently which is located in a subdir and it depends on nothing else in the project. I'm highly annoyed that each time I type make cmake takes about a minute before it actually decided what to do, thrashing my HD the whole time. (filling all diskbuffers, and thus making the whole system slow for the next 10 minutes) I'm guessing it looks at the whole project, but why is beyond me. Even if there are dependencies; I cd-ed into that dir for a reason. I hate it when software tries to be smarter than me. I would appreciate if the check-dependencies stuff was disabled by default, where cmake would only check if the libraries it depends on (thats in the CMakeLists.txt isn't it) exist; not if they are uptodate. -- Thomas Zander pgpBLdAHJN4lP.pgp Description: PGP signature ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] cmake 2.4.2 and qt 2.3nc
Title: cmake 2.4.2 and qt 2.3nc -Ursprüngliche Nachricht- Von: Zein Salah Gesendet: Mittwoch, 24. Mai 2006 14:02 An: ITK Users (E-Mail) Betreff: cmake 2.4.2 and qt 2.3nc Hello, I have newly built my qt-itk project with cmake 2.4.2. cmake generates a message: Multiple versions of Qt found, please set DESIRED_QT_VERSION Actually, I have only one version of qt, which is the 2.3 non commercial version. I tried to just give 230 in the field DESIRED_QT_VERSION, but as compiled the project with MS Studio .NET 2003, I got the following error. -- Build started: Project: qglviewer, Configuration: Debug Win32 -- QT Wrapped File moc: D:/NPRTool/qglviewer/qglviewer_MOC_SRCS: No such file Project : error PRJ0019: A tool returned an error code from QT Wrapped File Build log was saved at file://d:\NPRTool-BIN\qglviewer\qglviewer.dir\Debug\BuildLog.htm qglviewer - 1 error(s), 0 warning(s) -- Done -- Build: 0 succeeded, 1 failed, 0 skipped Any idea what to do?? what the problem is? Many thanks in advanced, Zein ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Problem Finding OpenGL on BSD...
Hi everyone :) I am at last enjoying new 2.4 feature on BSD :D many thanks to all those who made that possible. I am using Cmake to find few dependencies for some personal projects. I setup correctly the CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH to get all my SDL_* dependencies found and working fine. But I also in my script do a simple : FIND_PACKAGE(OpenGL) And when doing a ccmake, I get the following error : CMake Error: OPENGL_DIR is not set. It must be set to the directory containing OPENGLConfig.cmake in order to use OPENGL. And I cant find any file named OPENGLConfig.cmake... I wasnt able so far to find out where that might come from either... Any body having the same problem ? Any idea on what's wrong and how to fix it ? I am using cmake 2.4.2 from pkgsrc on NetBSD. I can remember I had a similar issue with 2.0.3... Thanks for the help! -- Asmodehn ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What about...
At 07:30 AM 5/26/2006, Thomas Zander wrote: Hiya; In KDE (including KOffice) we switched to cmake, as you are probably aware. I naturally like the speedups we got in linking etc. but I like the less then stellar usability of the cmake solution a lot less. (at this point I would gladly go back to the slower linking, to be honest) I'm wondering if you guys can look over some features I have seen/used in other make systems and see if you can steal some ideas. I would love to know what you guys think of these and if/when you can get them in cmake. cmake --projecthelp To print all 'make' targets the user can choose from. Makes it easy to find things like 'make dox'. After cmake is run, you can do make help It will show all the targets to choose from. cmake install to call 'make install' (naturally this goes for all targets) cmake -P cmake_install.cmake (that is what is run when you do make install) cmake --compile-jobs=n similar to -j but only for compile jobs, so it will not make multiple link/etc jobs be run at the same time. This is hard to do, but is on the TODO list. Currently, make -j is our only parallel approach. cmake -v for make VERBOSE=1 cmake -DCMAKE_VERBOSE_MAKEFILE=TRUE should do the trick. (c)make /usr/local/foo/bar/baz.la will compile the sources needed only for that lib and link/install it. Tends to be faster then a 'make all install'. make help will show the targets available. There are now also, fast targets that do not do the whole check. make library/fast A 'configure' script generator that will just convert between the (good old) configure and the cmake foo. Makes it actually possible to discover what features there are without consulting online documentation ;) That is very hard to do as configure scripts can have almost anything in them. Finally; I searched the FAQ / docs but I found no answer to a nagging question of mine. Why oh why did you guys choose to use make as the command the developer has to type. That decision leaves you without any options to make the user experience any better. I honestly can't tell people to type 'make VERBOSE=1' and not apologize in the same sentence about the horrible usability of that. I am not sure I understand what you want to type to do the build? If you build a makefile based project you run make to build it. If you build an Xcode project your run the Xcode GUI, if you build Kdevelop, you run that GUI, and if you do visual studio, you run that GUI. With autoconf, you run make. What would you want to type to build? -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What about...
On Friday 26 May 2006 16:24, you wrote: I am not sure I understand what you want to type to do the build? williamMake would do; of wmake if you want. :) Bottom line; I don't care what the name is as long as it _can_ be made more usable. Which is impossible with make. You apparently are completely used to the idea of having to type really long, non intuitive (at least I would never come up with them) and all capitals variable names; but I don't like um. And as I know a little about usability I know that the best way to solve the issue is to make it easier to find and type them. My first solution there would be to have to most used ones part of a new imaginary command; wmake with options like: wmake -v which ends up doing the same as 'make VERBOSE=true' but be easier to find since its visible when the user types 'wmake --help' If you read my email again you can see that you misinterpreted almost all my suggestions as they are all about this concept and not request for 'how do I accomplish task X in cmake lingo' For example: cmake install to call 'make install' (naturally this goes for all targets) cmake -P cmake_install.cmake (that is what is run when you do make install) Its not *just* about 'install' Read my question again. And your answer hardly is easier to discover. (I bet you had to look that up! :) The suggestion is to have a command, cmake in the quoted part, wmake in the suggestion above, that allows the developer to have a more usability friendly front end. Since make currently is, well, I won't start cursing here :-) Thanks -- Thomas Zander pgpLWIxQTUAAP.pgp Description: PGP signature ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] make in a subdir takes ages.
On Friday 26 May 2006 16:28, you wrote: If you only want to build a target, then run make targetname/fast it will skip all of the depend steps, and only build that target. Doesn't seem to work here on my 2.4-p2 -- Thomas Zander pgpqR2sSorTIU.pgp Description: PGP signature ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Problem Finding OpenGL on BSD...
Asmodehn Shade wrote: I am using Cmake to find few dependencies for some personal projects. I setup correctly the CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH to get all my SDL_* dependencies found and working fine. But I also in my script do a simple : FIND_PACKAGE(OpenGL) And when doing a ccmake, I get the following error : CMake Error: OPENGL_DIR is not set. It must be set to the directory containing OPENGLConfig.cmake in order to use OPENGL. And I cant find any file named OPENGLConfig.cmake... I wasnt able so far to find out where that might come from either... Any body having the same problem ? Any idea on what's wrong and how to fix it ? I am using cmake 2.4.2 from pkgsrc on NetBSD. I can remember I had a similar issue with 2.0.3... Is there a file FindOpenGL.cmake anywhere in your installation? It should be in PREFIX/share/CMake/Modules or something like that. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] make in a subdir takes ages.
Thomas Zander wrote: On Friday 26 May 2006 16:28, you wrote: If you only want to build a target, then run make targetname/fast it will skip all of the depend steps, and only build that target. Doesn't seem to work here on my 2.4-p2 Try it in the top level instead of the subdir. It looks like those shortcut targets were left out of the subdirs. We'll fix it. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What about...
Thomas Zander wrote: On Friday 26 May 2006 16:24, you wrote: I am not sure I understand what you want to type to do the build? williamMake would do; of wmake if you want. :) Bottom line; I don't care what the name is as long as it _can_ be made more usable. Which is impossible with make. [snip] And as I know a little about usability I know that the best way to solve the issue is to make it easier to find and type them. My first solution there would be to have to most used ones part of a new imaginary command; wmake with options like: wmake -v which ends up doing the same as 'make VERBOSE=true' but be easier to find since its visible when the user types 'wmake --help' [snip] The suggestion is to have a command, cmake in the quoted part, wmake in the suggestion above, that allows the developer to have a more usability friendly front end. CMake is a build system *generator*, not a build tool. It generates files for *native* build tools that do not come with CMake. The most common native tool on unix is...make! We have put some effort into making the Makefile interface nicer but as you said it is somewhat hopeless to make make pretty. If you do not like the command line interface provided by make then you have two choices: 1.) Use another interface such as KDevelop and the corresponding generator in CMake. 2.) Find or write your own native build tool with the command line interface of your choice and contribute a generator for it to CMake. This could be an unsermake generator for example. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What about...
On Friday 26 May 2006 17:05, Thomas Zander wrote: On Friday 26 May 2006 16:24, you wrote: I am not sure I understand what you want to type to do the build? williamMake would do; of wmake if you want. :) Bottom line; I don't care what the name is as long as it _can_ be made more usable. Which is impossible with make. You apparently are completely used to the idea of having to type really long, non intuitive (at least I would never come up with them) and all capitals variable names; but I don't like um. And as I know a little about usability I know that the best way to solve the issue is to make it easier to find and type them. My first solution there would be to have to most used ones part of a new imaginary command; wmake with options like: wmake -v which ends up doing the same as 'make VERBOSE=true' but be easier to find since its visible when the user types 'wmake --help' You can set this in the CMakeLists.txt file if you want so you dont have type it on cmd line.. set(CMAKE_VERBOSE_MAKEFILE TRUE) Craig ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What about...
At 11:05 AM 5/26/2006, Thomas Zander wrote: On Friday 26 May 2006 16:24, you wrote: I am not sure I understand what you want to type to do the build? williamMake would do; of wmake if you want. :) Bottom line; I don't care what the name is as long as it _can_ be made more usable. Which is impossible with make. OK, so what you want is a cmake front end to the build process. CMake is not a build tool, it just generates build files for various build tools, and make happens to be one of them. However, it would be possible to add a layer to cmake that actually does the build. Currently we do run build processes from ctest, so we have the code to do that. I have thought it might not be a bad addition to cmake. I mistakenly thought you wanted to know how to get things done with 2.4.2, and I was trying to help you. However, this is really a feature request. You want a new tool (say cmakebuld) that works something like this: cmakebuild help // list all the targets cmakebuild install// run the install target cmakebuild build // build all targets cmakebuild build -verbose // build all with VERBOSE set to true cmakebuild build target // build a target That is all not very hard to do, and would work with all of the generators, even the IDE generators. However, this request: cmake --compile-jobs=n similar to -j but only for compile jobs, so it will not make multiple link/etc jobs be run at the same time. is much harder. Since cmake is not a build tool, it never builds a file, it only generates the build files for other tools, we are limited to the capabilities of the tools we are using. Some of the generators do not support parallel builds. gmake does with -j, and we are looking into making it not link multiple things at the same time, and do have some ideas on how to do that. So, cmakebuild -jobs N could be made to work if you were using gmake. So, it would be possible to create cmakebuild. The question is how useful would it be. People that are used to the standard configure; make projects most likely are somewhat comfortable with the command line of make. People that do not like the command line of make, can currently use Kdevelop, Xcode or MS Visual studio generators for CMake. The advantage of creating a tool like this, would be that you could create a single set of docs that would work on any platform, with any build tool. A 'configure' script generator that will just convert between the (good old) configure and the cmake foo. Makes it actually possible to discover what features there are without consulting online documentation ;) I am not sure about what you want here. Do you want something that will convert a configure script into cmake files? Do you want to convert cmake files into a configure script? What is the goal with this question? -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What about...
On Friday 26 May 2006 17:52, Craig Bradney wrote: On Friday 26 May 2006 17:05, Thomas Zander wrote: On Friday 26 May 2006 16:24, you wrote: I am not sure I understand what you want to type to do the build? williamMake would do; of wmake if you want. :) Bottom line; I don't care what the name is as long as it _can_ be made more usable. Which is impossible with make. You apparently are completely used to the idea of having to type really long, non intuitive (at least I would never come up with them) and all capitals variable names; but I don't like um. And as I know a little about usability I know that the best way to solve the issue is to make it easier to find and type them. My first solution there would be to have to most used ones part of a new imaginary command; wmake with options like: wmake -v which ends up doing the same as 'make VERBOSE=true' but be easier to find since its visible when the user types 'wmake --help' You can set this in the CMakeLists.txt file if you want so you dont have type it on cmd line.. set(CMAKE_VERBOSE_MAKEFILE TRUE) Actually, I wonder why CMAKE_VERBOSE_MAKEFILE is not set to TRUE by default, each time, I have to set it manually and I find it quite annoying. Craig ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake -- * - * - * Frederic Heem Software Designer RD - Telsey SpA Telecommunications Viale Industria, 1 31055 Quinto di Treviso (TV) ITALY Tel. direct phone: (+39) 0422 377819 Tel. (+39) 0422 377711 Fax. (+39) 0422 470920 website == www.telsey.it ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What about...
On Friday 26 May 2006 17:55, you wrote: A 'configure' script generator that will just convert between the (good old) configure and the cmake foo. Makes it actually possible to discover what features there are without consulting online documentation ;) I am not sure about what you want here. Do you want something that will convert a configure script into cmake files? Do you want to convert cmake files into a configure script? What is the goal with this question? I have helped a set of people on irc to get started with koffice compiling using cmake. They all had a lot of problems with the arcane variables like the CMAKE_INSTALL_PREFIX and most people find that D in front a bit weird a well. So; instead of letting the user (not only a developer!!) type cmake ../../project -DCMAKE_INSTALL_PREFIX=$KDEDIR there would be a command line tool (which I want to call configure, I don't care if its shell script or perl or whatever) and that tool would parse: ./configure --prefix=foo and execute the cmake equivalent that I typed above. Again; this is all focussed on making cmake more usable for the KDE community; but I guess a lot of cmake users will benefit from it as well. You have to remember that there are a lot of end users downloading the sources and I can't in all honesty tell them its something better if they have to type the above cmake PREFIX thing instead of using the configure thing we had before. Hope that explains it better :) -- Thomas Zander pgpfuA41RkeWL.pgp Description: PGP signature ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Depending on a Config File (CMake and VC++)
You can use CONFIGURE_FILE to copy the file:
IF(CMAKE_CONFIGURATION_TYPES)
# Handle multi-configuration generators.
FOREACH(config ${CMAKE_CONFIGURATION_TYPES})
CONFIGURE_FILE(${CMAKE_CURRENT_SOURCE_DIR}/my.config.in,
${CMAKE_CURRENT_BINARY_DIR}/${config}/my.config)
ENDFOREACH(config)
ELSE(CMAKE_CONFIGURATION_TYPES)
# Handle single-configuration generators.
CONFIGURE_FILE(${CMAKE_CURRENT_SOURCE_DIR}/my.config.in,
${CMAKE_CURRENT_BINARY_DIR}/my.config)
ENDIF(CMAKE_CONFIGURATION_TYPES)
Excellent! Thanks very much for this info.
I'm seeing a problem, though.
CMake is not finding my config file, even though it does exist.
CMake announces its search with forward-slash paths, but I'm in the VS C++
IDE.
Is CMake not actually looking for:
c:\Temp\traps.p01\trunk\TRAPS2\traps_config.txt
(I guess not, or it would find it, because the file does exist there.)
Is this a bug, or a driver error of some sort?
Below is the CMake output from the Build -
Deleting intermediate files and output files for project 'jklib2',
configuration 'Debug|Win32'.
Building Custom Rule c:/Temp/traps.p01/trunk/JKLIB2/CMakeLists.txt
CMake Error: File c:/Temp/traps.p01/trunk/TRAPS2/traps_config.txt, does not
exist.
CMake Error: Error in cmake code at
c:/Temp/traps.p01/trunk/TRAPS2/CMakeLists.txt:28:
CONFIGURE_FILE Problem configuring file
CMake Error: File c:/Temp/traps.p01/trunk/TRAPS2/traps_config.txt, does not
exist.
CMake Error: Error in cmake code at
c:/Temp/traps.p01/trunk/TRAPS2/CMakeLists.txt:28:
CONFIGURE_FILE Problem configuring file
CMake Error: File c:/Temp/traps.p01/trunk/TRAPS2/traps_config.txt, does not
exist.
CMake Error: Error in cmake code at
c:/Temp/traps.p01/trunk/TRAPS2/CMakeLists.txt:28:
CONFIGURE_FILE Problem configuring file
CMake Error: File c:/Temp/traps.p01/trunk/TRAPS2/traps_config.txt, does not
exist.
CMake Error: Error in cmake code at
c:/Temp/traps.p01/trunk/TRAPS2/CMakeLists.txt:28:
CONFIGURE_FILE Problem configuring file
-- Configuring done
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Small nitpick...
Hi,Recently a bug fix was made to VS.Net 2003 generator to allow source files with the same.The fix was to specify an ObjectFile for each and every source file, so that they would be guaranteed to be unique. Unfortunately, even with CMAKE_VERBOSE_MAKEFILE set to FALSE, what you end up with now is the following:Compiling...stringutils_test.cppCompiling...operations_test.cppCompiling...path_test.cpp Compiling...main.cppCompiling...convert.cppVisual studio is so dumb that it just has to print out Compiling... before each and every file that has an ObjectFile specified. It really gets in the way and makes it harder to see what is currently being compiled. I know it is just a nitpick, but I really wish I knew how to get rid of those Compiling... lines.One solution would be to alter cmake to only specify ObjectFile for source files that actually have conflicting name. But that may be harder to implement. I would much rather just find a way to make VS.Net stop printing them out. It seems like VS.Net is the one being dumb. Any ideas...?Phillip ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What about...
Yo Thomas, We use cmake to build a large project (10 or so different SDKs). In our case, we too wanted a cmakebuild tool, so we wrote one. It wraps the native build tools with a higher level of commands build debug build release run tests package SDKs etc. Some of the commands for this build tool are very specific to our product and our problems others are perhaps generalizable. I had never thought this was something that cmake would provide, as I as a developer usually use native build tools directly, while the consumers of our software use the lightweight wrapper to build our stuff. As an interim solution you could provide a similar tool for people consuming KDE, and perhaps while writing the tool it would crystallize a set of features that would go into a generic cmakebuild tool. I'm still curious if there's enough there in the universal appeal bucket to make a general tool out of it, and am not familiar with what features/code cmake (ctest) already have built in to facilitate this. I would be willing to contrast our cmakebuild tool with what you come up with to try to identify the overlap and sketch out the commands of such a general tool as an experiment... best, lloyd /-- Around 6 PM on [05/26/06] ([EMAIL PROTECTED]) said -- On Friday 26 May 2006 17:55, you wrote: A 'configure' script generator that will just convert between the (good old) configure and the cmake foo. Makes it actually possible to discover what features there are without consulting online documentation ;) I am not sure about what you want here. Do you want something that will convert a configure script into cmake files? Do you want to convert cmake files into a configure script? What is the goal with this question? I have helped a set of people on irc to get started with koffice compiling using cmake. They all had a lot of problems with the arcane variables like the CMAKE_INSTALL_PREFIX and most people find that D in front a bit weird a well. So; instead of letting the user (not only a developer!!) type cmake ../../project -DCMAKE_INSTALL_PREFIX=$KDEDIR there would be a command line tool (which I want to call configure, I don't care if its shell script or perl or whatever) and that tool would parse: ./configure --prefix=foo and execute the cmake equivalent that I typed above. Again; this is all focussed on making cmake more usable for the KDE community; but I guess a lot of cmake users will benefit from it as well. You have to remember that there are a lot of end users downloading the sources and I can't in all honesty tell them its something better if they have to type the above cmake PREFIX thing instead of using the configure thing we had before. Hope that explains it better :) -- Thomas Zander ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake -- [EMAIL PROTECTED] | the of the organization appreciate within http://docs.yahoo.com/info/values/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What about...
Lloyd Hilaiel wrote: Yo Thomas, We use cmake to build a large project (10 or so different SDKs). In our case, we too wanted a cmakebuild tool, so we wrote one. It wraps the native build tools with a higher level of commands build debug build release run tests package SDKs etc. Some of the commands for this build tool are very specific to our product and our problems others are perhaps generalizable. I had never thought this was something that cmake would provide, as I as a developer usually use native build tools directly, while the consumers of our software use the lightweight wrapper to build our stuff. As an interim solution you could provide a similar tool for people consuming KDE, and perhaps while writing the tool it would crystallize a set of features that would go into a generic cmakebuild tool. I'm still curious if there's enough there in the universal appeal bucket to make a general tool out of it, and am not familiar with what features/code cmake (ctest) already have built in to facilitate this. I would be willing to contrast our cmakebuild tool with what you come up with to try to identify the overlap and sketch out the commands of such a general tool as an experiment... best, lloyd There is always ccmake and cmakeseup. Another option is to create a tool called cconfigure for those who like configure scripts. That shouldn't be to hard to implement. cconfigure --help would show the same options as ccmake: $ ./cconfigure --help --cmake_build_type Choose the type of build, options are: ... --cmake_install_prefix Install path prefix, prepended onto install directories --cmake_verbose_makefile If this value is on, makefiles will be generated ... [more options] $ ./configure --cmake_build_type=release --cmake_install_prefix=/usr --cmake_verbose_make_file=true ~/projects/my_project $ make $ make install -- Filipe Sousa signature.asc Description: OpenPGP digital signature ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Depending on a Config File (CMake and VC++)
Steve Johns wrote: Excellent! Thanks very much for this info. I'm seeing a problem, though. CMake is not finding my config file, even though it does exist. CMake announces its search with forward-slash paths, but I'm in the VS C++ IDE. Is CMake not actually looking for: c:\Temp\traps.p01\trunk\TRAPS2\traps_config.txt (I guess not, or it would find it, because the file does exist there.) Is this a bug, or a driver error of some sort? Below is the CMake output from the Build - Deleting intermediate files and output files for project 'jklib2', configuration 'Debug|Win32'. Building Custom Rule c:/Temp/traps.p01/trunk/JKLIB2/CMakeLists.txt CMake Error: File c:/Temp/traps.p01/trunk/TRAPS2/traps_config.txt, does not exist. Forward-slashes are the way CMake keeps track of paths internally, and they should work fine even on Windows. What is the exact CONFIGURE_FILE call you are using? -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Depending on a Config File (CMake and VC++)
Steve Johns wrote:
What is the exact CONFIGURE_FILE call you are using?
Here it is, cut and pasted:
IF(CMAKE_CONFIGURATION_TYPES)
# Handle multi-configuration generators.
FOREACH(config ${CMAKE_CONFIGURATION_TYPES})
CONFIGURE_FILE(${CMAKE_CURRENT_SOURCE_DIR}/traps_config.txt,
${CMAKE_CURRENT_BINARY_DIR}/${config}/traps_config.txt)
ENDFOREACH(config)
There was a typo in my example: it should not have the comma between the
arguments. The trailing comma is being considered part of the file name!
ELSE(CMAKE_CONFIGURATION_TYPES)
# Handle single-configuration generators.
CONFIGURE_FILE(${CMAKE_CURRENT_SOURCE_DIR}/traps_config.txt,
${CMAKE_CURRENT_BINARY_DIR}/traps_config.txt)
ENDIF(CMAKE_CONFIGURATION_TYPES)
Be careful with this. For an in-source build this may not work. That
is why my original example included a .in extension on the input file.
-Brad
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: CMake Digest, Vol 25, Issue 43
On Friday 26 May 2006 18:50, [EMAIL PROTECTED] wrote: Actually, I wonder why CMAKE_VERBOSE_MAKEFILE is not set to TRUE by default, each time, I have to set it manually and I find it quite annoying. It is a matter of taste. Some folks like to see pages and pages of output even if it builds nothing. Some folks only want to see what is being compiled and do not care about how it is being compiled. I think it is usually developers that like to see everything, and they are more likely to know how to change a setting. But users that just want to build the software, only want to build it and don't really care what is going on. It was felt that there are more users than developers, so that is why the default is off. I don't think that there is to much relation with developper or user. I am developper and I am building the same the configured project 100 times a day. I could not imagine something more annoying as seeing all the verbose messages for every compilation which would in fact distract me from the warnings in the compilation itself! I'd say make VERBOSE=1 is useful only as long as I debug the configuration. If this is fine it does not need to change and I don't want to see it ! -- Axel Roebel IRCAM Analysis/Synthesis Team ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What about...
On Friday 26 May 2006 18:02, frederic heem wrote: Actually, I wonder why CMAKE_VERBOSE_MAKEFILE is not set to TRUE by default, each time, I have to set it manually and I find it quite annoying. Everyone I know gave a sigh of relieve when unsermake (2 years ago) introduced the concept of showing minimal output. Unsermake does have a really good feature I'd like to see in cmake/make, though. It shows the full commandline of the last command when the build fails. This means that if you are missing an include dir it doesn't require you to restart the build with the verbose flag on since it shows the actual command that failed and thus the include flags etc. Best of both worlds. -- Thomas Zander pgp78AWYw8drG.pgp Description: PGP signature ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What about...
Thomas Zander wrote:
Its because it slows me down a lot.
When I change a couple of header files I suddenly see it reconfiguring for
no apparent reason.
Its when I type 'make' it takes upto a minute before it actually starts
with the first gcc, even if I typed make moments before. (I just typed
'make | less' this time).
I saw your other post about massive slowdowns. I haven't experienced
that sort of thing myself, but Chicken is a small project so it's not
likely I would. Best to keep that issue separate in its own thread.
Its that there is no feedback on what I am doing wrong when I alter the
CMakeLists.txt file,
When I type something wrong in CMakeLists.txt, and then I run
CMakeSetup or CCMake again, I get dialog boxes telling me there's some
error on such-and-such a line. The errors have usually been helpful,
if not always.
that combined with the 5 minutes it takes between
edit and output me frustrated when I need to add something.
At times I have wanted file-level dependency targets for this reason.
I don't find myself inconvenienced if I'm building a main target, like
"make silex."
Incidentally, my typical debugging technique is to look at the
generated Makefiles to see what's wrong with them. Usually there's a
path qualification error. Usually it's my error; sometimes I've found
a bona fide CMake bug.
Its the constant looking for words like VERBOSE=1 which are not easy to
find.
I consider the freely available documentation to be weak. Meaning,
it's not integrated, it's scattered across official documentation, the
FAQ, and the wiki. The $$ documentation might be better, I don't
know. The free help on this list is second to none, which is why I
became a CMake pundit. CMake may have problems, but the CMake team is
really good at providing solutions. I'd work on improving the CMake
documentation myself, but my time is currently limited and what little
I have goes towards improving the Chicken build.
cmake --projecthelp
To print all 'make' targets the user can choose from. Makes it easy
to find things like 'make dox'.
What build system uses this?
Java's ant (and I think maven as well).
Not my universe. --projecthelp may be a commonplace in Javaland, but
CMake is C/C++ land for the most part. I doubt that Ant conventions
are familiar to this crowd. Familiarity with ./configure conventions
are far more likely. CMake is designed to be a ./configure
replacement, in the sense that it does the same jobs and does a much
better job at cross-platform than ./configure does. When seeking
converts, "How does ./configure do it?" is more apropos than "How does
Ant do it."
Although it could be a useful feature,
I've never typed this before. I have no natural training, inclination,
or habit to type this sort of thing. I have typed "./configure --help"
plenty of times.
Sure; but do note that this is not the same. Configure is about
configuration options; I'm talking about make targets. Like 'all'.
'install', 'check', 'docs' etc.
Note that ant has a comment field for the custom targets that should be
shown so you only see those.
I think it's a good idea, I just don't know that it should be called
--projecthelp. --targets seems a lot more logical to me. Also, "cmake
--help" should list the "--targets" command. That way, people find
information in a workflow that they're used to. If CMakeSetup had a
menu option to display the targets, that would be useful.
Incidentally, you can use graphviz to generate a graph of all the
top-level targets. It won't show file-level dependencies though, and
it's not a great interface for just getting in there on the command
line. Very useful when you're at the head-scratching stage of your
project though, and you need to mull over all your dependencies at once.
(c)make /usr/local/foo/bar/baz.la
will compile the sources needed only for that lib and link/install
it. Tends to be faster then a 'make all install'.
Top-level targets do have names. For instance I can type "make
libchicken" or "make libchicken-static". File-level dependencies don't
have convenient names, though.
How can I find out what those targets are?
Any toplevel target has the same name as in CMakeLists.txt, i.e.
ADD_EXECUTABLE(chicken ${sourcefiles}) means you can type "make
chicken". ADD_LIBRARY(libchicken SHARED ${sourcefiles}) means you can
type "libchicken". You could also find out by inspecting the generated
Makefiles.
A 'configure' script generator that will just convert between the
(good old) configure and the cmake foo. Makes it actually possible
to discover what features there are without consulting online
documentation ;)
I'd like the whole autoconf toolchain to die.
This is not about autoconf!!
Its just reusing (abusing?) a well known filename. Thats all.
What I'm saying
Re: [CMake] What about...
Thomas Zander wrote: I have helped a set of people on irc to get started with koffice compiling using cmake. They all had a lot of problems with the arcane variables like the CMAKE_INSTALL_PREFIX and most people find that D in front a bit weird a well. So; instead of letting the user (not only a developer!!) type cmake ../../project -DCMAKE_INSTALL_PREFIX=$KDEDIR You know there are CMakeSetup and CCMake... to quote Boromir, are you sure you do not suffer needlessly? there would be a command line tool (which I want to call configure, I don't care if its shell script or perl or whatever) and that tool would parse: ./configure --prefix=foo and execute the cmake equivalent that I typed above. I think better policy is to have a ./configure that does nothing and tells the user this is a CMake build, not a ./configure build. Also, you can't just claim the ./configure namespace gratuitously. It is entirely valid to have both a CMake and a ./configure build of the same project. Chicken is currently in that position now. I'm working on killing ./configure, but I'm far from there yet. The transition will take many months. The new build has to prove itself to be 100% reliable, and then some, before old build goes away. I think it's a very good idea to add "cmake --prefix=foo" because 1 gazillion ./configure users would get warm squishy feelings from such functionality. Although, it could become an Uncanny Valley problem. The closer you get to representing ./configure, the more complaints about how it's not ./configure! So it may not be as good an idea as one would think. It might be better to train people to use CMakeSetup and CCMake. But that I admit is a GUI vs. command line battle. Maybe it's advisable to beef up CMake's command line usability, if only for marketing purposes. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: XML/expat link error
actually, I have found if I change the following entry (add expat to the linker flags) in cmxmlrpc/CMakeLists.txt this problem goes away:TARGET_LINK_LIBRARIES(xrtest cmXMLRPC cmexpat expat ${CMAKE_DL_LIBS})
On 5/26/06, Doug Henry [EMAIL PROTECTED] wrote:
I receive the errors below when building versions 2.2.3 and 2.4.2. It looks like the cmexpat library is not linking in when cmXMLRPC library is used. I have ./Utilities/cmexpat/libcmexpat.a so it did build, not sure what would cause this.
[TOOLS cmake-2.4.2]$ makeLinking C executable ../../bin/xrtest/mnt/tools/RPM/TMP/cmake-2.4.2/Utilities/cmxmlrpc/libcmXMLRPC.a(xmlrpc_expat.o): In function `xml_parse':xmlrpc_expat.c:(.text+0x848): undefined reference to `XML_ParserCreate'
xmlrpc_expat.c:(.text+0x862): undefined reference to `XML_SetUserData'xmlrpc_expat.c:(.text+0x87c): undefined reference to `XML_SetElementHandler'xmlrpc_expat.c:(.text+0x88d): undefined reference to `XML_SetCharacterDataHandler'
xmlrpc_expat.c:(.text+0x8a6): undefined reference to `XML_Parse'xmlrpc_expat.c:(.text+0x8d8): undefined reference to `XML_ParserFree'xmlrpc_expat.c:(.text+0x947): undefined reference to `XML_GetErrorCode'
xmlrpc_expat.c:(.text+0x94f): undefined reference to `XML_ErrorString'
xmlrpc_expat.c:(.text+0x96c): undefined reference to `XML_GetErrorCode'xmlrpc_expat.c:(.text+0x974): undefined reference to `XML_ErrorString'collect2: ld returned 1 exit statusmake[2]: *** [bin/xrtest] Error 1
make[1]: *** [Utilities/cmxmlrpc/CMakeFiles/xrtest.dir/all] Error 2
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: XML/expat link error
Doug Henry wrote:
actually, I have found if I change the following entry (add expat to the
linker flags) in cmxmlrpc/CMakeLists.txt this problem goes away:
TARGET_LINK_LIBRARIES(xrtest cmXMLRPC cmexpat expat ${CMAKE_DL_LIBS})
From where is that other expat library coming? I bet the build of
cmXMLRPC is accidentally using system expat headers instead of cmexpat
headers. The include directory order in Utilities/cmxmlrpc may need
fixing. In that directory's CMakeLists.txt file change the lines
INCLUDE_DIRECTORIES(
${CMAKE_CURRENT_SOURCE_DIR}
${CMAKE_CURRENT_BINARY_DIR}
${CMAKE_EXPAT_INCLUDES}
${CMAKE_CURL_INCLUDES}
)
to
INCLUDE_DIRECTORIES(BEFORE
${CMAKE_CURL_INCLUDES}
${CMAKE_EXPAT_INCLUDES}
${CMAKE_CURRENT_SOURCE_DIR}
${CMAKE_CURRENT_BINARY_DIR}
)
and try bootstrapping again with a fresh tree.
-Brad
On 5/26/06, *Doug Henry* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
I receive the errors below when building versions 2.2.3 and 2.4.2.
It looks like the cmexpat library is not linking in when cmXMLRPC
library is used. I have ./Utilities/cmexpat/libcmexpat.a so it did
build, not sure what would cause this.
[TOOLS cmake-2.4.2]$ make
Linking C executable ../../bin/xrtest
/mnt/tools/RPM/TMP/cmake-2.4.2/Utilities/cmxmlrpc/libcmXMLRPC.a(xmlrpc_expat.o):
In function `xml_parse':
xmlrpc_expat.c:(.text+0x848): undefined reference to `XML_ParserCreate'
xmlrpc_expat.c:(.text+0x862): undefined reference to `XML_SetUserData'
xmlrpc_expat.c:(.text+0x87c): undefined reference to
`XML_SetElementHandler'
xmlrpc_expat.c:(.text+0x88d): undefined reference to
`XML_SetCharacterDataHandler'
xmlrpc_expat.c:(.text+0x8a6): undefined reference to `XML_Parse'
xmlrpc_expat.c:(.text+0x8d8): undefined reference to `XML_ParserFree'
xmlrpc_expat.c:(.text+0x947): undefined reference to `XML_GetErrorCode'
xmlrpc_expat.c:(.text+0x94f): undefined reference to `XML_ErrorString'
xmlrpc_expat.c:(.text+0x96c): undefined reference to `XML_GetErrorCode'
xmlrpc_expat.c:(.text+0x974): undefined reference to `XML_ErrorString'
collect2: ld returned 1 exit status
make[2]: *** [bin/xrtest] Error 1
make[1]: *** [Utilities/cmxmlrpc/CMakeFiles/xrtest.dir/all] Error 2
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What about...
Filipe Sousa wrote: There is always ccmake and cmakeseup. Another option is to create a tool called "cconfigure" for those who like configure scripts. That shouldn't be to hard to implement. cconfigure --help would show the same options as ccmake: $ ./cconfigure --help --cmake_build_type Choose the type of build, options are: ... --cmake_install_prefix Install path prefix, prepended onto install directories --cmake_verbose_makefile If this value is on, makefiles will be generated ... [more options] $ ./configure --cmake_build_type=release --cmake_install_prefix=/usr --cmake_verbose_make_file=true ~/projects/my_project $ make $ make install "cconfigure" strikes me as a really bad naming choice. People will forever be typing "configure" and wondering what's wrong. You even did it yourself! As for functionality: the point of an autoconf ./configure is that you don't need any special tool installed to run it. If you have a Bourne shell, that's all you need. Now, I suppose CMake could generate a ./configure script of sorts, that expects a Makefile on a Unixy system and doesn't need any additional tools to run. Like, CMake itself isn't needed. This would be entirely comparable to what autoconf actually does. You use autoconf to generate ./configure, then you throw autoconf away during the actual build. The problem is, I bet CMake can't do all of the detection stuff with just Bourne shell code. It's going to need to interpret CMake code, which means you'll need to have CMake installed, which means you've defeated the purpose of not needing any special tool installed. If the user has got CMake, might as well train them to type "cmake --whatever". Another issue is that an autoconf ./configure script typically relies on libtool. You don't wanna go there. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Depending on a Config File (CMake and VC++)
There was a typo in my example: it should not have the comma between the
arguments. The trailing comma is being considered part of the file name!
Great eye, Brad!
So, here what I have now:
IF(CMAKE_CONFIGURATION_TYPES)
# Handle multi-configuration generators.
FOREACH(config ${CMAKE_CONFIGURATION_TYPES})
CONFIGURE_FILE(${CMAKE_CURRENT_SOURCE_DIR}/traps_config.txt
${CMAKE_CURRENT_BINARY_DIR}/${config}/traps_config.txt
COPYONLY)
ENDFOREACH(config)
ELSE(CMAKE_CONFIGURATION_TYPES)
# Handle single-configuration generators.
CONFIGURE_FILE(${CMAKE_CURRENT_SOURCE_DIR}/traps_config.txt
${CMAKE_CURRENT_BINARY_DIR}/traps_config.txt COPYONLY)
ENDIF(CMAKE_CONFIGURATION_TYPES)
and here is what happens:
-- Configuring done
-- Generating done
CMake Error: Unknown Target referenced : traps_config.txt
CMake Error: Target: traps depends on unknown target: traps_config.txt
this happens with both in-source and out-of-source builds.
Be careful with this. For an in-source build this may not work. That is
why my original example included a .in extension on the input file.
I don't really understand that part but I did try this, as an experiment
IF(CMAKE_CONFIGURATION_TYPES)
# Handle multi-configuration generators.
FOREACH(config ${CMAKE_CONFIGURATION_TYPES})
CONFIGURE_FILE(${CMAKE_CURRENT_SOURCE_DIR}/traps_config.in
${CMAKE_CURRENT_BINARY_DIR}/${config}/traps_config.txt
COPYONLY)
ENDFOREACH(config)
ELSE(CMAKE_CONFIGURATION_TYPES)
# Handle single-configuration generators.
CONFIGURE_FILE(${CMAKE_CURRENT_SOURCE_DIR}/traps_config.in
${CMAKE_CURRENT_BINARY_DIR}/traps_config.txt COPYONLY)
ENDIF(CMAKE_CONFIGURATION_TYPES)
with identical, failed results.
As I read the docs, we've asked the system to copy a file. The file is
there. I'm at a loss to see
why it doesn't just happen. Obviously, I have something more to learn here
...
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Depending on a Config File (CMake and VC++)
At 03:47 PM 5/26/2006, Steve Johns wrote:
IF(CMAKE_CONFIGURATION_TYPES)
# Handle multi-configuration generators.
FOREACH(config ${CMAKE_CONFIGURATION_TYPES})
CONFIGURE_FILE(${CMAKE_CURRENT_SOURCE_DIR}/traps_config.in
${CMAKE_CURRENT_BINARY_DIR}/${config}/traps_config.txt
COPYONLY)
ENDFOREACH(config)
ELSE(CMAKE_CONFIGURATION_TYPES)
# Handle single-configuration generators.
CONFIGURE_FILE(${CMAKE_CURRENT_SOURCE_DIR}/traps_config.in
${CMAKE_CURRENT_BINARY_DIR}/traps_config.txt COPYONLY)
ENDIF(CMAKE_CONFIGURATION_TYPES)
The failure is coming from some other place. If I create a CMakeList.txt
file with only the above in it, it works as expected.
Are there any other places in your cmakelist files that reference
traps_config.txt?
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] using CMAKE_BUILD_WITH_INSTALL_RPATH
What is the correct way to set the install RPATH under
CMake 2.4.2? At the moment I do the following within my
project's top most CMakeLists.txt file:
SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE)
SET(CMAKE_INSTALL_RPATH ${CMAKE_INSTALL_PREFIX}/lib)
And the RPATH refuses to show itself in the installed
binaries for my project.
Regards,
Iker
--
Iker Arizmendi
ATT Labs - Research
Speech and Image Processing Lab
e: [EMAIL PROTECTED]
w: http://research.att.com
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Depending on a Config File (CMake and VC++)
This is the point where we say: just don't do in-source builds... :-)
Use separate directories for source and binary trees.
2 cents,
David
Brad King wrote:
Steve Johns wrote:
ELSE(CMAKE_CONFIGURATION_TYPES)
# Handle single-configuration generators.
CONFIGURE_FILE(${CMAKE_CURRENT_SOURCE_DIR}/traps_config.txt
${CMAKE_CURRENT_BINARY_DIR}/traps_config.txt COPYONLY)
ENDIF(CMAKE_CONFIGURATION_TYPES)
Be careful with this. For an in-source build this may not work.
That is why my original example included a .in extension on the
input file.
I don't really understand that part but I did try this, as an experiment
If the build directory and source directory are the same then this may
try to copy the file onto itself. I think CMake may just not copy it
but I'm not sure what would happen with the dependency when the file
changed since it is never newer than itself.
-Brad
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What about...
At 05:03 PM 5/26/2006, Axel Roebel wrote: cmake --help cmake variables --build_type Choose the type of build, options are: ... --install_prefix Install path prefix, prepended onto install directories --verbose_make If this value is on, makefiles will be project options --USE_FOOBAR use the foobar package (FALSE) project variables MYPROJECT_INSTALL_PREFIX /myinstall/location So, I guess cmake --help would run cmake in some sort of run but do not do anything mode. It would read all the list files and collect up all the cache variables, but not write the cache, or any build files. It would read any cache that was there, to get the current state of things. If cmake is run and the options did change it could return with error and display a warning: cmake --prefix=/myopt --USE_FOOBAR=1 ... snip warning: configuration options changed see new choices with cmake --help The warning is not a bad idea, and the logic is in cmake -i. Which means the help should take into account the current settings. -- Axel Roebel IRCAM Analysis/Synthesis Team ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] OpenSSL
Has anyone managed to build OpenSSL with CMake? (I'm not looking for FindOpenSSL - I want to build the package itself) James ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
