[CMake] an easy way to clean cmake generated files?
Hi, I wonder if there's an easy, straightforward way to clean a cmake project of _all_ cmake-generated files? This would include: CMakeCache.txt cmake_install.cmake CMakeFiles and all of these in subdirectories added to the project with the add_subdirectory() statement.. Thanks, Akos ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] an easy way to clean cmake generated files?
On Monday 24 March 2008 12:23:04 Ákos Maróy wrote: Andreas Pakulat wrote: Use out-of-source builds, then you can just rm -rf builddir and be done. I'd love to, but I want to use Eclipse for the building itself, and it seems Eclipse needs in-source builds to be able to do meaningful debugging.. I use Eclipse too, but don't experience much problems. I just set up Build Directory in project options to place where I set up out-of-source build. Because debug info is embedded into output binaries, eclipse can easily find proper sources (May be after some playing with path mappings). Build directory can be specified in extra modules search path. Alternatively, you may choose to create build directory in source tree to make Eclipse find objects and symbols. For in-source-builds this is going to be manual work. :( conceptually I don't understand though. it's cmake that knows best what temporary files it is generating.. Akos ___ 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] Problem building fortran project on Windows using Intel Fortran 10 compiler
Xin XU wrote: Hello Bill, Thanks for your reply! I am using: CMake 2.4 patch 8 on Windows XP. I wrote a set of small C++ codes. When I put my codes and CMakeLists.txt on a Linux PC, the CMake works fine. When I put them on my Windows XP PC and asking CMake to configure for Microsoft Visual Studio 8, I got the error shown in the attachment. Sorry, I could not copy the text down, so I used print screen. Hope you can see that. OK, so it looks like ifort is not working from the command line. Can you run ifort by hand from a shell and compiler a fortran program? Are you running CMakeSetup from the SAME shell or command prompt that runs ifort? Also, please post to the cmake list and not to me directly. There maybe and most likely are people who have seen this error and know what to do to fix it. (I am not one of them, so please repost the error message to the list.) -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Suppressing Windows console in Qt app
Hi everyone, When I build my Qt 4 app (QTM) using CMake on Windows Vista and then run it from a prompt, the prompt does not come back as it does with normal Windows GUI apps; it behaves as if it's running a console-based application. If you press Ctrl+C, it kills the program. If you run it from Explorer, it opens a prompt window but doesn't give you a prompt, and similarly you can kill QTM by closing the window. When I build using qmake, I do not have this problem; it just gives me the prompt back. Does anyone know how to fix this? Regards, Matt Smith -- http://qtm.blogistan.co.uk/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Obtaining improved GNU make performance on Makefiles generated by cmake
One more warning about adding your own -I flags... I think this will break the dependency scanner of CMake, and the depends will be wrong if you do not use include_directories. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Suppressing Windows console in Qt app
On Monday 24 March 2008 7:45:57 am Matthew Smith wrote: Hi everyone, When I build my Qt 4 app (QTM) using CMake on Windows Vista and then run it from a prompt, the prompt does not come back as it does with normal Windows GUI apps; it behaves as if it's running a console-based application. If you press Ctrl+C, it kills the program. If you run it from Explorer, it opens a prompt window but doesn't give you a prompt, and similarly you can kill QTM by closing the window. When I build using qmake, I do not have this problem; it just gives me the prompt back. Does anyone know how to fix this? Regards, Matt Smith Use WIN32 in your ADD_EXECUTABLE command. You can see http://www.cmake.org/HTML/CMake-2.4.html for more details. Clint ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Suppressing Windows console in Qt app
My guess is that in your
ADD_EXECUTABLE statement, you are missing the WIN32 Argument:
cmake version 2.4-patch 8 ADD_EXECUTABLE Add an executable to
the project using the specified source files.
ADD_EXECUTABLE(exename [WIN32] [MACOSX_BUNDLE]
[EXCLUDE_FROM_ALL]source1 source2 ... sourceN)
This command adds an executable target to the current
directory. The executable will be built from the list of
source files specified.
After specifying the executable name, WIN32 and/or
MACOSX_BUNDLE can
be specified. WIN32 indicates that the executable (when compiled on
windows) is a windows app (using WinMain) not a console app (using
main). The variable CMAKE_MFC_FLAG be used if the windows app uses
MFC. This variable can be set to the following values:
0: Use Standard Windows Libraries
1: Use MFC in a Static Library
2: Use MFC in a Shared DLL
MACOSX_BUNDLE indicates that when build on Mac OSX,
executable should
be in the bundle form. The MACOSX_BUNDLE also allows several
variables to be specified:
MACOSX_BUNDLE_INFO_STRING
MACOSX_BUNDLE_ICON_FILE
MACOSX_BUNDLE_GUI_IDENTIFIER
MACOSX_BUNDLE_LONG_VERSION_STRING
MACOSX_BUNDLE_BUNDLE_NAME
MACOSX_BUNDLE_SHORT_VERSION_STRING
MACOSX_BUNDLE_BUNDLE_VERSION
MACOSX_BUNDLE_COPYRIGHT
If EXCLUDE_FROM_ALL is given the target will not be built by
default.
It will be built only if the user explicitly builds the target or
another target that requires the target depends on it.
If you are going to be building this as a cross platform application,
then the following is useful:
# Set some Win32 Specific Settings
IF(WIN32)
SET(GUI_TYPE WIN32)
ENDIF(WIN32)
# Set some Apple MacOS Specific settings
IF (APPLE)
SET(GUI_TYPE MACOSX_BUNDLE)
ENDIF (APPLE)
ADD_EXECUTABLE( MyApplication ${GUI_TYPE} ${PROJECT_SRCS} )
Mike
--
Mike Jackson Senior Research Engineer
Innovative Management Technology Services
On Mar 24, 2008, at 9:45 AM, Matthew Smith wrote:
Hi everyone,
When I build my Qt 4 app (QTM) using CMake on Windows Vista and
then run it from a prompt, the prompt does not come back as it does
with normal Windows GUI apps; it behaves as if it's running a
console-based application. If you press Ctrl+C, it kills the
program. If you run it from Explorer, it opens a prompt window but
doesn't give you a prompt, and similarly you can kill QTM by
closing the window. When I build using qmake, I do not have this
problem; it just gives me the prompt back. Does anyone know how to
fix this?
Regards,
Matt Smith
--
http://qtm.blogistan.co.uk/
___
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] Suppressing Windows console in Qt app
If you are going to be building this as a cross platform application,
then the following is useful:
# Set some Win32 Specific Settings
IF(WIN32)
SET(GUI_TYPE WIN32)
ENDIF(WIN32)
# Set some Apple MacOS Specific settings
IF (APPLE)
SET(GUI_TYPE MACOSX_BUNDLE)
ENDIF (APPLE)
ADD_EXECUTABLE( MyApplication ${GUI_TYPE} ${PROJECT_SRCS} )
I usually do that a simpler way.
ADD_EXECUTABLE( MyApplication WIN32 MACOSX_BUNDLE ${PROJECT_SRCS} )
It doesn't break a Linux build to have WIN32 there.
Clint
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Obtaining improved GNU make performance on Makefiles generated by cmake
On 2008-03-24 10:27-0400 Bill Hoffman wrote: One more warning about adding your own -I flags... I think this will break the dependency scanner of CMake, and the depends will be wrong if you do not use include_directories. Our use case is we have a directory where our many different device drivers are built with wildly varying compilation flag (both -I and -D) requirements. So it seemed natural to use SET_SOURCE_FILES_PROPERTIES( ... PROPERTIES COMPILE_FLAGS ...) to handle each device driver separately rather than using ADD_DEFINITIONS and INCLUDE_DIRECTORIES. The method appears to work fine, but I haven't tested the case where some external library header has been changed to see if CMake responds properly. I will probably just stick with the present method until CMake adds the feature of per-target ADD_DEFINITIONS and INCLUDE_DIRECTORIES (assuming they do handle the external dependency case correctly). For PLplot headers scattered all over our build tree for our various libraries we do use INCLUDE_DIRECTORIES to find them so all the internal dependencies should be correct. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] COMPILE_FLAGS on per target and per configuration basis
Hi, all. I need define some compile flags for my targets. This flags deepend on config tipe. With LINK_FLAGS I can do this very simple. I can write just set_target_properties(target1 PROPERTIES LINKER_FLAGS_FINAL some flags for target1) set_target_properties(target2 PROPERTIES LINKER_FLAGS_FINAL some flags for target2) May be exist some way do the same with COMPILE_FLAGS ? -- Ilya Shvetsov (mailto:chvetsov_at_kranx.com) KranX Productions (http://kranx.com/) ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] COMPILE_FLAGS on per target and per configuration basis
On Monday 24 March 2008 20:42:46 Ilya Shvetsov wrote:
Hi, all.
I need define some compile flags for my targets. This flags deepend on
config tipe.
With LINK_FLAGS I can do this very simple. I can write just
set_target_properties(target1 PROPERTIES
LINKER_FLAGS_FINAL some flags for target1)
set_target_properties(target2 PROPERTIES
LINKER_FLAGS_FINAL some flags for target2)
May be exist some way do the same with COMPILE_FLAGS ?
I do it following way:
set_source_files_properties(
${MyTarget_SRCS}
PROPERTIES COMPILE_FLAGS /J /Zc:wchar_t
)
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Obtaining improved GNU make performance on Makefiles generated by cmake
On 2008-03-24 10:33-0400 Bill Hoffman wrote: OK, I talked with Brad, and found out the difference from 2.4.8 and CVS. When make runs in a CMake project, the first thing it does is run cmake to check the depend information. It looks for missing header files, and other checks to see if CMake should re-run or not. In 2.4.8, CMake would do this globally for the whole project. These made a delay as CMake checked all the depends for the whole project. CMake now checks each targets header files separately. This means two things. First, if you are only building one target, then it should be much faster as all the headers for the entire project are not checked. Second, the initial delay for the project is much less, but over all time may increase some as the check is now done for each target and shared headers maybe double checked. That sounds like a good working hypothesis for the substantially increased latency of the cvs version, but you should probably confirm that analysis with some -d runs to make absolutely sure. If that hypothesis is confirmed, and if your judgement is most developers simply type make the majority of the time (which is what I tend to do) without bothering with individual targets, then you may want to reconsider that change because of the substantially increased latency penalty associated with it. That said, I have checked in a change to get PHONY targets into CMake, as it should not break other makes. This should help some, and it should fix the make test problem when you had a directory called test. make test sparked this investigation, but I have long since solved that issue by renaming our test subdirectory as plplot_test since we are a cross-platform product where some of our Unix users do not have access to GNU make. So the emphasis for most of this thread has simply focussed on the important issue of reducing the latency for GNU make users, and I really appreciate your attempts to address that issue. Unfortunately, the results for your newly implemented .PHONY support for GNU make are disappointing for some unknown reason. Just to review, the PLplot make latency for cmake 2.4.8 is [EMAIL PROTECTED] time make /dev/null real0m1.454s user0m0.800s sys 0m0.724s and for cmake version 2.7-20080320 is is real0m2.319s user0m1.356s sys 0m1.068s with timing errors of +/- 0.01 s or so for each measurement. For cmake version 2.7-20080324 (which includes your .PHONY changes as I checked with actual results in the build-tree Makefiles) that latency has been increased by a small amount that appears to be above the timing errors. [EMAIL PROTECTED] time make /dev/null real0m2.375s user0m1.444s sys 0m1.028s I notice cmake_force is still in the generated Makefiles for cmake 2.7-20080324. It's count is reduced compared to the number of .PHONY instances. [EMAIL PROTECTED] find -type f |xargs grep cmake_force |wc -l 824 [EMAIL PROTECTED] find -type f |xargs grep .PHONY |wc -l 5849 Both the above commands were executed from the top of the build tree. You should be able to eliminate cmake_force altogether for GNU make since .PHONY duplicates its function. My guess from the count above is that will make a noticable difference. I think it requires a CMake and make guru to find out what is really going on using a through investigation comparing cmake 2.4.8 with cmake 2.7-20080320 and cmake 2.7-20080324 with the make -d option. I am not that guru (all I know is that make -d outputs an enormous number of results which are hard for me to understand), but if one of the CMake developers wants to investigate further, PLplot should be a reasonably accessible test bed for such investigations. Note with PLplot there are a large number of options to simplify the build. For example, you easily can eliminate all the non-C language interfaces and/or the devices to simplify comparisons. You should probably check other projects as well including a simple hello-world project if timing errors don't completely swamp the results in that case. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] COMPILE_FLAGS on per target and per configuration basis
On Mon, 24 Mar 2008 20:02:27 +0200, Timenkov Yuri
[EMAIL PROTECTED] wrote:
May be exist some way do the same with COMPILE_FLAGS ?
I do it following way:
set_source_files_properties(
${MyTarget_SRCS}
PROPERTIES COMPILE_FLAGS /J /Zc:wchar_t
)
Problem still exist. I need per config type. Because of Visual Studio
Generator I can't write some thing like this:
if (CMAKE_BUILD_TYPE STREQUAL Final)
...
endif
Because of two targets in on CMakeLists.txt I can't use
CMAKE_CXX_COMPILE_FLAGS.
--
Ilya Shvetsov (mailto:[EMAIL PROTECTED])
Lead Programmer
KranX Productions (http://kranx.com/)
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] COMPILE_FLAGS on per target and per configuration basis
On Monday 24 March 2008 21:20:45 Ilya Shvetsov wrote:
On Mon, 24 Mar 2008 20:02:27 +0200, Timenkov Yuri
[EMAIL PROTECTED] wrote:
May be exist some way do the same with COMPILE_FLAGS ?
I do it following way:
set_source_files_properties(
${MyTarget_SRCS}
PROPERTIES COMPILE_FLAGS /J /Zc:wchar_t
)
Problem still exist. I need per config type. Because of Visual Studio
Generator I can't write some thing like this:
I think you can use same way of configuration-specific flags as for linker
(that is CMAKE_CXX_FLAGS_DEBUG, CMAKE_CXX_FLAGS_MINSIZEREL,
CMAKE_CXX_FLAGS_RELEASE)
But this way you can set them on per-source basis.
CMake is great tool, which allows you customize build in may ways (It seems so
at least :) ).
In my project, I had to use specific flags only for some sources but in all
configurations.
Look at advanced variables provided by CMakeSetup.exe or ccmake. It appears
sometimes useful for me to turn off optimization in RelWithDebInfo build type
(I need release version msvcrt dlls), And in CMakeSetup I can set it with one
simple change in hundred of projects.
I suppose these flags should help you, and affect
(project+configuration)-specific compiler options in Visual Studio.
if (CMAKE_BUILD_TYPE STREQUAL Final)
...
endif
Because of two targets in on CMakeLists.txt I can't use
CMAKE_CXX_COMPILE_FLAGS.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] How to make Visual Studio .vcproj with relative paths
Hi, This is a follow up to http://public.kitware.com/Bug/view.php?id=6642 I'm developing on Windows using Visual Studio 8 and in my project I use libraries like libogg, libvorbis, libpng, libbz2 and libz. Some of those libs ship VS files, some don't. Some include VS6 files, some VS7 or VS8. Most of the library developers probably don't have VS or even Windows. Now I've been wondering, would it be possible to make the VS project (and solution) files using cmake, on Linux? The first obstacle would be the use of absolute paths in the .vcproj file. VS itself uses relative paths, so this should be possible. The second obstacle is that the generated .vcproj file still depends on cmake (as far as I know). The third one is that cmake doesn't allow generating Windows VS project files on Linux. Cmake seems like a good candidate, but maybe it's just the wrong tool for the job. The project files I'd like to generate don't seem that complex, but maybe I'm overlooking something. Is there a chance support for this usecase could be added to cmake? Greetings, Olaf ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Obtaining improved GNU make performance on Makefiles generated by cmake
OK, so for a small project like PLplot, where it does a make in 1 to 2 seconds if nothing needs to be done, this stuff really does does not matter that much. Adding the phony targets may have actually made it take longer as make would have to parse that much more stuff. As for the new way cmake does the depend stuff, I think the new approach is much better for larger projects like KDE/ParaView. Basically for those larger projects make sometarget was almost unusable. We create sometarget/fast to get around the problem, but people lost some depend checks. It is basically a trade off between large and small projects. If it only takes a fraction of a second longer for the small project but saves minutes on the larger projects, then lets save minutes. The phony change is good because it fixes the make test issue. I think the makefiles are tuned well enough for me right now. If someone wants to contribute patches that show improvement that is fine as well. The cmake_force stuff is not used that much anyway. It is only used for foo.i which are targets that are not part of the all build anyway. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Curses libraries not found
:s, where are they? so i can install ccmake i'm usingKubunto, and i dowloaded the 2.4.7 version and make installed it. Any hints will be much appreciated, thank you. -- Dario Figueira - ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Curses libraries not found
Dario Figueira wrote: :s, where are they? so i can install ccmake i'm usingKubunto, and i dowloaded the 2.4.7 version and make installed it. Any hints will be much appreciated, thank you. Did you install the developers files for curses on the machine? It is not the default... -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Curses libraries not found
Hello Dario, Make sure you see the .h files for ncurses. Andy On Mon, Mar 24, 2008 at 1:04 PM, Bill Hoffman [EMAIL PROTECTED] wrote: Dario Figueira wrote: :s, where are they? so i can install ccmake i'm usingKubunto, and i dowloaded the 2.4.7 version and make installed it. Any hints will be much appreciated, thank you. Did you install the developers files for curses on the machine? It is not the default... -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake -- http://legoandy.com -o- http://capitalmtb.org Support my 150 mile bike ride to fight MS: http://bikecan.nationalmssociety.org/site/TR?px=3921627pg=personalfr_id=9066 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Cross compile + shared libs problem
Hi, I'm trying to cross-compile static libraries for RTEMS. Our project's also targets Linux, where we use shared libraries. We declare the libraries with: add_library(libname srcs...). So STATIC or SHARED is omitted. On RTEMS there are no static libraries, so I was expecting that by setting BUILD_SHARED_LIBS to OFF in the toolchain file, I would get static libraries. I do get static libraries for RTEMS, but cmake complains that: ADD_LIBRARY for library tsp_services is used with the SHARED option, but the target platform supports only STATIC libraries. Building it STATIC instead. This may lead to problems. Did I miss something, or is BUILD_SHARED_LIBS not working as expected? I'm using today's cmake CVS. Regards, Frederik ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Obtaining improved GNU make performance on Makefiles generated by cmake
Hi Bill: I just now tested (with the build on one of the PLplot C examples) the assertion that specific targets will have less latency with the new approach. Here are the results. [EMAIL PROTECTED] make x10c [ 0%] Built target plhershey-unicode-gen [ 0%] Built target plhershey-unicode.h_built [ 0%] Built target csirocsa [ 16%] Built target csironn [100%] Built target plplotd [100%] Built target x10c As you can see from this, the number of dependencies is fairly small. Furthermore, the VERBOSE=1 results indicate there are no actual commands being run by the above so this is a measure of true latency. Here are the corresponding latency results: 2.4.8: [EMAIL PROTECTED] time make x10c /dev/null real0m0.217s user0m0.160s sys 0m0.068s 2.7-20080324: [EMAIL PROTECTED] time make x10c /dev/null real0m0.209s user0m0.168s sys 0m0.036s Repeat runs indicate for this special case with a small number of dependencies, the timing errors are typically +/- 0.002 s. The conclusion therefore is the cvs version wins on latency for a specific target by a marginal amount that is just above the timing noise. On 2008-03-24 15:28-0400 Bill Hoffman wrote: OK, so for a small project like PLplot, where it does a make in 1 to 2 seconds if nothing needs to be done, this stuff really does does not matter that much. As for the new way cmake does the depend stuff, I think the new approach is much better for larger projects like KDE/ParaView. Large projects have the most serious potential latency problems (could be minutes rather than seconds if the number of dependencies is very high) so I agree they should be the ones driving latency improvements rather than PLplot. The only advantage of using PLplot for such tests is the initial build can be done in less than a minute so doing differential comparisons between various CMake versions is easy to do. In any case, it's fundamentally important not to guess about latency because reducing latency is generally a hard problem. Thus, before the next release I hope somebody steps forward with actual latency numbers for specific targets and the all target for large projects like KDE/ParaView. But it currently doesn't look good since the indications from the PLplot tests (which so far is the only hard data that has been reported) is the latency for make all will be substantially worse while the latency for specific targets with a lot fewer dependencies then all are only marginally better for the cvs version compared to 2.4.8. The principal conclusion I want to emphasize is the PLplot latency results are just an indication of what to expect in general, and what we need is hard latency numbers for big projects like KDE, ParaView, etc., (where latency issues should be more severe than in the PLplot case). That's the only way we can move forward with any further attempts to substantially improve latency. I have previously asked Alex to do the KDE case. Bill, would you be willing to measure latency for ParaView for cmake 2.4.8 and the present cvs version of CMake? Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Obtaining improved GNU make performance on Makefiles generated by cmake
Alan W. Irwin wrote: I have previously asked Alex to do the KDE case. Bill, would you be willing to measure latency for ParaView for cmake 2.4.8 and the present cvs version of CMake? Sure, it will take some time to do this, as a build of paraview can take some time, and I will have to do it twice. However, with the single target in ParaView case, I know when Brad made the change he saw significant speed ups, but I do not have the numbers. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] an easy way to clean cmake generated files?
On Mon, Mar 24, 2008 at 4:51 AM, Ákos Maróy [EMAIL PROTECTED] wrote: Hi, I wonder if there's an easy, straightforward way to clean a cmake project of _all_ cmake-generated files? This would include: CMakeCache.txt cmake_install.cmake CMakeFiles and all of these in subdirectories added to the project with the add_subdirectory() statement.. I've filed a feature request for this (i.e. a distclean target for CMake). It keeps coming up on the mailing list so it probably would make a nice addition to CMake. I've needed it before too when stubborn coworkers really want to keep using in-source build trees but want to return their source trees to a pristine state. http://public.kitware.com/Bug/view.php?id=6647 -- Philip Lowman ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
