Re: [CMake] automatically re-generating makefiles

Brad King wrote: The problem with Makefile: input-foo.txt input-bar.txt regenerate-rule is that when someone removes "input-bar.txt" from disk Make will refuse to run the regeneration rule. Ah, wasn't thinking about that. Thanks for the info. -- Matthew Please do not quote my e-mail ad

Re: [CMake] automatically re-generating makefiles

Brad King wrote: AFAIK there is no way to implement the make my-new-target interface reliably. FYI, you can write the above like this: make rebuild_cache && make my-new-target if you know that it is a new target. -Brad ___ Powered by www.kitw

Re: [CMake] automatically re-generating makefiles

Matthew Woehlke wrote: Bill Hoffman wrote: I still don't get the original problem??? We used to have Makefile: . It was removed when that work was pushed into cmake_check_build_system. Ah. Maybe it should come back? The problem with Makefile: input-foo.txt input-bar.txt regene

Re: [CMake] automatically re-generating makefiles

Bill Hoffman wrote: I still don't get the original problem??? We used to have Makefile: . It was removed when that work was pushed into cmake_check_build_system. Ah. Maybe it should come back? The original problem is: 'make foo' doesn't work after adding a target 'foo', because the Makefi

Re: [CMake] Feature request question

0008725 & 0008743 Thanks again for the help. On Tue, Mar 17, 2009 at 1:56 PM, Bill Hoffman wrote: > Steven Wilson wrote: > >> Following the FAQ ( >> http://www.cmake.org/Wiki/CMake_FAQ#I_want_a_new_feature_in_CMake._What_should_I_do.3F) >> I have submitted a couple feature requests(8725, 8743)

Re: [CMake] Feature request question

Steven Wilson wrote: Following the FAQ (http://www.cmake.org/Wiki/CMake_FAQ#I_want_a_new_feature_in_CMake._What_should_I_do.3F) I have submitted a couple feature requests(8725, 8743) to the cmake bugs database along with source patches implementing the features. I haven't yet received any f

Re: [CMake] preventing redundant compilations

On Tue, Mar 17, 2009 at 12:43:50PM -0700, Bill O'Hara wrote: > One of the users I support complained about the following: > > add_library(foo a.c b.c) > add_library(bar a.c c.c) > > because a.c will be compiled twice (the real case is more complex of course > but essentially the same thing with m

Re: [CMake] automatically re-generating makefiles

Matthew Woehlke wrote: Bill Hoffman wrote: Matthew Woehlke wrote: Makefile : cmake_check_build_system Shouldn't this rather be: Makefile: cmake_check_build_system ? ...in which case, the only thing that should get checked is if the CMakeLists.txt are newer than the Makefile. So in most

[CMake] Feature request question

Following the FAQ ( http://www.cmake.org/Wiki/CMake_FAQ#I_want_a_new_feature_in_CMake._What_should_I_do.3F) I have submitted a couple feature requests(8725, 8743) to the cmake bugs database along with source patches implementing the features. I haven't yet received any feedback yet on either of

[CMake] preventing redundant compilations

One of the users I support complained about the following: add_library(foo a.c b.c) add_library(bar a.c c.c) because a.c will be compiled twice (the real case is more complex of course but essentially the same thing with more files). While its possible to pull a.c out into a library and link agai

Re: [CMake] automatically re-generating makefiles

Bill Hoffman wrote: Matthew Woehlke wrote: Makefile : cmake_check_build_system Shouldn't this rather be: Makefile: cmake_check_build_system ? ...in which case, the only thing that should get checked is if the CMakeLists.txt are newer than the Makefile. So in most cases this should be f

Re: [CMake] automatically re-generating makefiles

Matthew Woehlke wrote: Makefile : cmake_check_build_system Shouldn't this rather be: Makefile: cmake_check_build_system ? ...in which case, the only thing that should get checked is if the CMakeLists.txt are newer than the Makefile. So in most cases this should be fast. We need to ru

Re: [CMake] Progress reporting in CMake

Denis Scherbakov wrote: I see progress jumping even on freshly CMake prepared, but never compiled tree. So is this a bug or a feature? The progress is an approximation at best. It should always betting bigger, and it should not go over 100%. Working with make there really is not a better

[CMake] Strange install behavior

Hello, I noticed a strange behavior of cmake during the installation phase with Visual Studio 2008. To demonstrate what's happening I made this CMakeLists.txt: - - - CMAKE_MINIMUM_REQUIRED(VERSION 2.6) IF(MSVC) SET(CMAKE_INSTALL_PREFIX c:/Temp/cmake_test) SET(FOO_DEF foo.def) ELSE(MSVC) SE

Re: [CMake] Progress reporting in CMake

I see progress jumping even on freshly CMake prepared, but never compiled tree. So is this a bug or a feature? Denis > Works pretty good for me (~120 .c's). I notice jumps > when building > semi-up-to-date trees (ie, only some of the source files > have changed) > which seems reasonable. > >

Re: [CMake] automatically re-generating makefiles

Eric Noulard wrote: 2009/3/16 Matthew Woehlke : I think if this isn't working, either a: cmake isn't writing optimal dependencies for the makefiles themselves, Optimal depends in which sense. With the current scheme I would say that dependency is checked "almost always when needed", with your

[CMake] Progress reporting in CMake

Dear CMake Gurus, Can you, please explain, how progress reporting in CMake is organised? I have a project with more than 100 files organised into subprojects. Still progress jumps from 0% to 4% ... from 14% to 19%. Why is that? Frankly speaking, I've never seen in any of my CMake projects (inc

Re: [CMake] Interpretation of RUNTIME_OUTPUT_DIRECTORY in VisualStudio

Hi Michael, thanks a lot, this solves the problem. Regards, Martin Michael Jackson wrote: > try the following: > ADD_CUSTOM_TARGET(QtLibs > COMMAND ${CMAKE_COMMAND} -E > copy_if_different ${CMAKE_CURRENT_SOURCE_DIR}/libQtCore.so.4 > ${CMAKE_RUNTIME_O

Re: [CMake] Interpretation of RUNTIME_OUTPUT_DIRECTORY in VisualStudio

try the following: ADD_CUSTOM_TARGET(QtLibs COMMAND ${CMAKE_COMMAND} -E copy_if_different ${CMAKE_CURRENT_SOURCE_DIR}/libQtCore.so.4 ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/${CMAKE_CFG_INTDIR}...) • CMAKE_CFG_INTDIR: Build time configuration directo

[CMake] Interpretation of RUNTIME_OUTPUT_DIRECTORY in VisualStudio

Hi all, I am trying to write CMake rules to copy shared libraries / DLLs to the runtime directory (not "installing"), right besides the binaries generated by my project. In order to do this, I have rules like the following: ADD_CUSTOM_TARGET(QtLibs COMM

Re: [CMake] Problems with REGEX REPLACE

Hi, With some off-list help from Pau, and by introducing a few work-arounds, I settled with this solution: In CMakeLists.txt: MACRO (FILE_TO_STRING infile outfile var) ADD_CUSTOM_COMMAND(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/${outfile} COMMAND ${CMAKE_COMMAND} A

[CMake] CTest and CMakeCache.txt

Hi all, Following section 10.5 in "Mastering CMake" and the example in the Tests directory of the CMake source distribution, I was trying to setup a separate build stage for test programs for our project. The reason for doing so is, that I want to separate compiling the source files from compilin

Re: [CMake] Precompiled Headers for Intel on windows

2009/3/17 : > I looked around for precompiled header support and couldn't figure out > how/if it works for intel compilers. > The links such as: http://www.mail-archive.com/cmake@cmake.org/msg05456.html > appear to be pretty MSVC centric and I don't think the stdafx.cpp approach > will work on int

Re: [CMake] automatically re-generating makefiles

2009/3/16 Matthew Woehlke : > Eric Noulard wrote: >> >> 2009/2/26 Alex Flint : >>> >>> Hi there, >>> >>> I've noticed that when I run "make blah" then the makefile is >>> automatically re-generated if I've changed anything in CMakeLists.txt >>> since the last time I built "blah". However, if I add