[CMake] [DOC] -f arg to cmake -E remove
Patch to specify -f arg in the documentation. $ cvs di Source/cmake.cxx Index: Source/cmake.cxx === RCS file: /cvsroot/CMake/CMake/Source/cmake.cxx,v retrieving revision 1.309 diff -u -r1.309 cmake.cxx --- Source/cmake.cxx16 Jul 2007 14:54:30 - 1.309 +++ Source/cmake.cxx17 Jul 2007 06:38:32 - @@ -867,7 +867,7 @@ make_directory dir - create a directory\n md5sum file1 [...] - compute md5sum of files\n remove_directory dir- remove a directory and its contents\n - remove file1 file2 ... - remove the file(s)\n + remove file1 file2 ... - remove the file(s). Add -f to force removal\n tar [cxt][vfz] file.tar file/dir1 file/dir2 ... - create a tar.\n time command [args] ... - run command and return elapsed time\n #if defined(_WIN32) !defined(__CYGWIN__) Thanks, -- Mathieu ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: Bugs in cmake-2.4.6, please solve for 2.4.7
On Tuesday 17 July 2007 03:06:15 [EMAIL PROTECTED] wrote: Re: Bugs in cmake-2.4.6, please solve for 2.4.7 Hi all, I would like to draw your attention to bug report 4209 that I submitted last year already: If you want your cmake project to be used with the xcode generator better stay away completely from EXCLUDE_FROM_ALL because the xcode generator will simply exclude all EXCLUDE_FROM_ALL targets completely such that you cannot even build them manually. It seems to me that this is a severe bug that should be fixed as soon as possible because it means you cannot rely on the fact that your cmake projects will work at all with all the supported generators. I work around this since quite a while and I am somewhat astonished to see that this bug seems not to have been adressed in the upcoming release. The same seems to hold true for bug 5238 and 5213 where libraries and executables that have a VERSION set in SET_TARGET_PROPERTIES will result in errors when using unix makefiles on cygwin. Same problem here. This means you have to adapt your cmake projects because otherwise they fail to produce a usuable result with some generators. So in short: if you intend to be portable with the current and the upcoming version of cmake better don't use VERSION and don't use EXCLUDE_FROM_ALL. Kind regards, -- Axel Roebel IRCAM Analysis/Synthesis Team Phone: ++33-1-4478 4845 | Fax: ++33-1-4478 1540 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Bugs in cmake-2.4.6, please solve for 2.4.7
Zitat von Axel Roebel [EMAIL PROTECTED]: So in short: if you intend to be portable with the current and the upcoming version of cmake better don't use VERSION and don't use EXCLUDE_FROM_ALL. So what? Xcode and Cygwin Makefiles generators are broken, that's no reason for me to not use the stuff that works with all others. On MacOS X, you can probably use plain Makefiles instead? Maybe it would be helpful to state somewhere the current state of the various generators, some may still be pre-beta. On Windows, cygwin is by far the worst choice, possibly introducing slow dependencies. I suggest using Mingw Makefiles or MSys Makefiles (both are _much_ faster) instead or go for MSVC. Not using VERSION property is not a good choice. Some systems that do not know about SONAME (which ones?) may need it to be able to use/install multiple versions of a library at the same time. HS PS: if it's not a generator that's broken, then it may as well be the make implementation or a strange concept of an IDE. And if that all works, you'll always hit messy compilers ;) ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Bugs in cmake-2.4.6, please solve for 2.4.7
On Tuesday 17 July 2007, [EMAIL PROTECTED] wrote: From: Hendrik Sattler [EMAIL PROTECTED] Zitat von Axel Roebel [EMAIL PROTECTED]: So in short: if you intend to be portable with the current and the upcoming version of cmake better don't use VERSION and don't use EXCLUDE_FROM_ALL. So what? Xcode and Cygwin Makefiles generators are broken, that's no reason for me to not use the stuff that works with all others. On MacOS X, you can probably use plain Makefiles instead? Very wise, as long as you use the project yourself you can do that. If you publish your project and you get users complaining about not being able to use what you provided you'll see that it will be you who has to deal with the problems. Not using VERSION property is not a good choice. Some systems that do not know about SONAME (which ones?) may need it to be able to use/install multiple versions of a library at the same time. You got the point. So that's why I considered VERSION to be important to be fixed. PS: if it's not a generator that's broken, then it may as well be the make implementation or a strange concept of an IDE. And if that all works, you'll always hit messy compilers ;) Very helpful this remark as well, thanks a lot. So you suggest not fixing cmake bugs because if they are fixed maybe the makefile or IDE will be broken anyway. Did you think about the main reason cmake came to existence? At least as I understand it and why I use it and what is written on the main cmake page is: platform and compiler portable project generation. The attitude my build tool is important but yours is a mess is certainly what is the least helpful here. -- Axel Roebel IRCAM Analysis/Synthesis Team Phone: ++33-1-4478 4845 | Fax: ++33-1-4478 1540 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] rc compile options in visual studio
When using visual studio, the resource compile options are updated with the cxx preprocessor definitions and the cxx include paths. How can I remove all of the cxx preprocessor/include definitions and redefine the options? I haven't had any luck trying to reset the options such as: set(CMAKE_RC_FLAGS CACHE STRING Resetting FORCE) set(CMAKE_RC_SOURCE_FILE_EXTENSIONS rc rc2 CACHE STRING Resetting FORCE) set(CMAKE_RC_COMPILE_OBJECT CMAKE_RC_COMPILER CMAKE_RC_FLAGS /foOBJECT SOURCE CACHE STRING Resetting the rc options. FORCE) Any ideas? Thank you, Jon ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Developer's Training Week for Visualization and Data Processing
Kitware is pleased to announce the Developer's Training Week covering our open source projects including VTK, ITK, ParaView, and CMake. This hands-on course is appropriate both for new users wishing to quickly gain proficiency and for experienced developers requiring advanced customization skills. This training course will be held the week of October 15 - 19, 2007, in scenic upstate NY; it is a great opportunity to meet some of the key contributors to these projects as well as other users in the community. As a course attendee, you will receive: - A complete set of course notes - The VTK User's Guide - The Visualization Toolkit textbook - The ITK Software Guide - The ParaView Guide - Mastering CMake - Snacks daily - Lunch (Monday through Thursday) - A dinner reception Monday and Wednesday evenings The course is divided into 9 half-day segments, allowing you to customize your experience based on your individual requirements. With early registration before September 15th, the cost is only $300 per half-day segment, or come for the full week for the discounted rate of $2200. No prior experience is necessary; however, you are expected to have a basic knowledge of C or C++ in order to fully participate in the interactive exercises. For more details, including the daily schedule, please visit the course web site at http://www.kitware.com/products/devtrainingweek.html. Additional information is available from [EMAIL PROTECTED] or by calling 518-371-3971. -- Amy Squillacote Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 Phone: (518) 371-3971 x106 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake.org website refresh rate?
Brandon Van Every wrote: http://public.kitware.com/Bug/bug.php?op=showbugid=5348 claims that http://www.cmake.org/HTML/Install.html now has MacOS X installation instructions on it. But I do not see them. What is the refresh time of the cmake.org website? Thought I'd ask before saying the bug isn't closed. Good grief, give me a day or so :-) It is done by hand. I have checked in the changes to CVS for the html stuff, but have not updated the server yet -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] SET_SOURCE_FILES_PROPERTY and multiple args
I have some code that sets a property and then I try to get it out later. This
property is some customized flags to the program:
SET(MY_FLAGS_VAL -Wall;-w512;-DSCI_NOPERSISTENT)
SET_SOURCE_FILES_PROPERTIES(myfile.w PROPERTIES MY_FLAGS ${MY_FLAGS_VAL})
GET_SOURCE_FILE_PROPERTY(myflags myfile.w MY_FLAGS)
MESSAGE(myfile.w:MY_FLAGS = ${myflags})
The problem I'm having is that only the first flag (-Wall) gets set. The rest
are ignored.
When I specify the flags explicitly it works fine:
SET_SOURCE_FILES_PROPERTIES(myfile.w PROPERTIES MY_FLAGS
-Wall;-w512;-DSCI_NOPERSISTENT)
I tried this:
SET(MY_FLAGS_VAL -Wall -w512 -DSCI_NOPERSISTENT)
But CMake replaced the spaces with '\ ' making the three args one arg.
Is it possible to set a source file property with a variable's value?
I'm using CMake 2.4.6 on linux.
Thanks,
James
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] SET_SOURCE_FILES_PROPERTY and multiple args
On Tuesday 17 July 2007 15:51, James Bigler wrote:
I have some code that sets a property and then I try to get it out later.
This property is some customized flags to the program:
SET(MY_FLAGS_VAL -Wall;-w512;-DSCI_NOPERSISTENT)
I think the qoutes here don't change a lot
SET(MY_FLAGS_VAL -Wall -w512 -DSCI_NOPERSISTENT)
would be the same. The semicolons already make it a list.
SET_SOURCE_FILES_PROPERTIES(myfile.w PROPERTIES MY_FLAGS ${MY_FLAGS_VAL})
GET_SOURCE_FILE_PROPERTY(myflags myfile.w MY_FLAGS)
MESSAGE(myfile.w:MY_FLAGS = ${myflags})
The problem I'm having is that only the first flag (-Wall) gets set. The
rest are ignored.
When I specify the flags explicitly it works fine:
SET_SOURCE_FILES_PROPERTIES(myfile.w PROPERTIES MY_FLAGS
-Wall;-w512;-DSCI_NOPERSISTENT)
I tried this:
SET(MY_FLAGS_VAL -Wall -w512 -DSCI_NOPERSISTENT)
But CMake replaced the spaces with '\ ' making the three args one arg.
Is it possible to set a source file property with a variable's value?
SET_SOURCE_FILES_PROPERTIES(myfile.w PROPERTIES MY_FLAGS ${MY_FLAGS_VAL})
should work.
Alex
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] SET_SOURCE_FILES_PROPERTY and multiple args
SET(MY_FLAGS_VAL -Wall -w512 -DSCI_NOPERSISTENT)
SET_SOURCE_FILES_PROPERTIES(myfile.w PROPERTIES MY_FLAGS ${MY_FLAGS_VAL})
Excellent! Works great.
Thanks,
James
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Help Please-Link Library
Thanks Eric and Bill. It works. On 7/16/07, Bill Hoffman [EMAIL PROTECTED] wrote: Eric Noulard wrote: 2007/7/16, Janny Dong [EMAIL PROTECTED]: Hi all, I am using Cmake to build MS Visual C++ program because I am using VTK. I'd like to link to another thirty-party library in my project. The library is already installed on my machine by running the executable setup file . In a project not built by Cmake, all I need to do is just modify the Project Properties: add mylibrary.lib to Linker-Input-Additional Dependencies. How can I do this in a project built by Cmake? I cannot add it directly in the Project Properties page because it complains. I am new to Cmake and I got lost in the Cmake commands. Any help would be appreciated! You should add a: TARGET_LINK_LIBRARY to your CMakeLists.txt see the documentation of the macro. in http://www.cmake.org/HTML/Documentation.html If your lib is not in the lib search path then you need to add the appropriate PATH using the LINK_DIRECTORIES macro It is much better to add the full path to the library, and use FIND_LIBRARY. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
