Re: [CMake] Should changing, adding or removing add_definitions call trigger a recompile of affected files
On Wed, Dec 10, 2008 at 3:53 PM, David Cole david.c...@kitware.com wrote: Why wouldn't having this:// CMAKE_CXX_FLAGS = '@CMAKE_CXX_FLAGS@' in the header.h.in file at configure time solve the issue of recompiling if you change the compilation flags? If you change the flags, CMake will change header.h when it configures it... Or this: #if 0 CMAKE_CXX_FLAGS = '@CMAKE_CXX_FLAGS@' #endif if you're worried about whether the flags contain something that might break a compiler if found on a comment line... (Like a \ at the end of the line...?) Am I missing something? That's a good suggestion except you wouldn't be able to do it with CMAKE_CXX_FLAGS, you'd have to coax the definitions out of CMake some other way because CMAKE_CXX_FLAGS doesn't contain the results of ADD_DEFINITIONS(). There is unfortunately another major drawback to this solution. If you don't already use a config.h include file in your software project, it's going to be a lot of work to switch. -- Philip Lowman ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Should changing, adding or removing add_definitions call trigger a recompile of affected files
One way that might work would be to configure a header file that contains a string representing the options of interest. Then include that header file in *all* source files that you want to rebuild. When you change options in CMake and configure the header, it will only change if something has changed, and then it will trigger a rebuild of the source files that include it. For this to work reliably you'd have to include that header in every source file in a given library or executable. I realize the downside of this approach, but it may work for your situation better than saying tell your developers to clean and rebuild everything when they change an ADD_DEFINITION HTH, David On Wed, Dec 10, 2008 at 12:25 AM, Philip Lowman [EMAIL PROTECTED] wrote: On Tue, Dec 9, 2008 at 1:08 PM, Philip Lowman [EMAIL PROTECTED] wrote: This is a known problem. Visual Studio has no way of knowing that the compiler flags changed in a project file CMake is writing to. I would love to see a patch for this for CMake 2.8. One thought I had here was to have the vcbuild command clean any affected projects. This would have the advantage of isolating CMake from implementing any Visual Studio specific mods (i.e. delete these object files to force a recompilation, etc.). This would have some downsides though. 1. The easiest implementation would just be to perform the clean if a project file changes. This would result in more cleaning then necessary as changing source files (for example) shouldn't cause a rebuild. Certain project modifications like adding a source file to a target shouldn't cause a clean of that target. 2. Perhaps the biggest gotcha of all, cleaning a target would wipe out any binaries/libraries already generated. This is far different from the behavior of CMake's Makefile generator which simply causes targets to be rebuilt on the next make. Anyone have any ideas for fixing this? I've been bit by this one before (forgetting to rebuild everything when I change a preprocessor definition at the global scope). -- Philip Lowman ___ 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] Should changing, adding or removing add_definitions call trigger a recompile of affected files
Why wouldn't having this:// CMAKE_CXX_FLAGS = '@CMAKE_CXX_FLAGS@' in the header.h.in file at configure time solve the issue of recompiling if you change the compilation flags? If you change the flags, CMake will change header.h when it configures it... Or this: #if 0 CMAKE_CXX_FLAGS = '@CMAKE_CXX_FLAGS@' #endif if you're worried about whether the flags contain something that might break a compiler if found on a comment line... (Like a \ at the end of the line...?) Am I missing something? On Wed, Dec 10, 2008 at 3:23 PM, James Bigler [EMAIL PROTECTED] wrote: In other projects in the past (using autoconf), this is what we did. We used header files with configured options in them. After switching to CMake we noticed that when using makefiles changing compile flags would recompile the appropriate files. Hurray! It wasn't until recently we started to make more VS projects and noticed that it didn't follow the same behavior. One possible solution to this would be to create dependency file at each level you specify a set of flags for (i.e. directories/targets/source file). Then for each source you add a dependency on that file to the appropriate set of dependency files. If a flag or something else changes that should trigger a recompile the corresponding dependency file would also change (configure_file mechanism perhaps if it is thread safe). This might get us most of the way there. The only reservation I would have would be the amount of extra file I/O involved, but perhaps it wouldn't be that bad. I imagine this would be a large undertaking for anyone to implement. It's unfortunate that VS recognizes when you change the settings from the IDE, but not if settings change after reloading though I can understand why it doesn't work. Well, the most reliable solution (for options) is to configure header files based on CMake options than to use compiler preprocessor definitions as you suggest. This doesn't solve the issue of not recompiling if you change compilation flags (i.e. CMAKE_CXX_FLAGS). James On Wed, Dec 10, 2008 at 7:27 AM, David Cole [EMAIL PROTECTED] wrote: One way that might work would be to configure a header file that contains a string representing the options of interest. Then include that header file in *all* source files that you want to rebuild. When you change options in CMake and configure the header, it will only change if something has changed, and then it will trigger a rebuild of the source files that include it. For this to work reliably you'd have to include that header in every source file in a given library or executable. I realize the downside of this approach, but it may work for your situation better than saying tell your developers to clean and rebuild everything when they change an ADD_DEFINITION HTH, David On Wed, Dec 10, 2008 at 12:25 AM, Philip Lowman [EMAIL PROTECTED] wrote: On Tue, Dec 9, 2008 at 1:08 PM, Philip Lowman [EMAIL PROTECTED] wrote: This is a known problem. Visual Studio has no way of knowing that the compiler flags changed in a project file CMake is writing to. I would love to see a patch for this for CMake 2.8. One thought I had here was to have the vcbuild command clean any affected projects. This would have the advantage of isolating CMake from implementing any Visual Studio specific mods (i.e. delete these object files to force a recompilation, etc.). This would have some downsides though. 1. The easiest implementation would just be to perform the clean if a project file changes. This would result in more cleaning then necessary as changing source files (for example) shouldn't cause a rebuild. Certain project modifications like adding a source file to a target shouldn't cause a clean of that target. 2. Perhaps the biggest gotcha of all, cleaning a target would wipe out any binaries/libraries already generated. This is far different from the behavior of CMake's Makefile generator which simply causes targets to be rebuilt on the next make. Anyone have any ideas for fixing this? I've been bit by this one before (forgetting to rebuild everything when I change a preprocessor definition at the global scope). -- Philip Lowman ___ 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] Should changing, adding or removing add_definitions call trigger a recompile of affected files
Yes, this is possible, but it isn't *automatic*. I have to manually include header.h in every one of my source files. In addition, I would have to keep separate header.h files for each target or source file that might have different flags. By not being automatic this become a horrible maintenance issue. Using header files is fine for configurations that would have used a -Doption, but for general flags I don't see this being a viable option. For one of my projects, I actually create a file with all the options used to run a custom command. If the options change, a rebuild is triggered. This is OK, because my custom command doesn't generate too many files. I can't imagine doing this for every .cpp file in my system, though I imagine it could be done by replacing add_library and add_executable with my own version. Doing this for every single source file in the project would get kind of excessive. CMake already has machinery to do target level and source level compilation options (set_target_properties and set_source_file_properties), and it may be possible to reuse some of that same logic to create dependency files on a target or source file basis based on these options. I'm guessing that could be a lot of work. For now, I'm going to just have to configure_file header files for options, and tell users to recompile on flag changes. James On Wed, Dec 10, 2008 at 1:53 PM, David Cole [EMAIL PROTECTED] wrote: Why wouldn't having this:// CMAKE_CXX_FLAGS = '@CMAKE_CXX_FLAGS@' in the header.h.in file at configure time solve the issue of recompiling if you change the compilation flags? If you change the flags, CMake will change header.h when it configures it... Or this: #if 0 CMAKE_CXX_FLAGS = '@CMAKE_CXX_FLAGS@' #endif if you're worried about whether the flags contain something that might break a compiler if found on a comment line... (Like a \ at the end of the line...?) Am I missing something? On Wed, Dec 10, 2008 at 3:23 PM, James Bigler [EMAIL PROTECTED]wrote: In other projects in the past (using autoconf), this is what we did. We used header files with configured options in them. After switching to CMake we noticed that when using makefiles changing compile flags would recompile the appropriate files. Hurray! It wasn't until recently we started to make more VS projects and noticed that it didn't follow the same behavior. One possible solution to this would be to create dependency file at each level you specify a set of flags for (i.e. directories/targets/source file). Then for each source you add a dependency on that file to the appropriate set of dependency files. If a flag or something else changes that should trigger a recompile the corresponding dependency file would also change (configure_file mechanism perhaps if it is thread safe). This might get us most of the way there. The only reservation I would have would be the amount of extra file I/O involved, but perhaps it wouldn't be that bad. I imagine this would be a large undertaking for anyone to implement. It's unfortunate that VS recognizes when you change the settings from the IDE, but not if settings change after reloading though I can understand why it doesn't work. Well, the most reliable solution (for options) is to configure header files based on CMake options than to use compiler preprocessor definitions as you suggest. This doesn't solve the issue of not recompiling if you change compilation flags (i.e. CMAKE_CXX_FLAGS). James On Wed, Dec 10, 2008 at 7:27 AM, David Cole [EMAIL PROTECTED] wrote: One way that might work would be to configure a header file that contains a string representing the options of interest. Then include that header file in *all* source files that you want to rebuild. When you change options in CMake and configure the header, it will only change if something has changed, and then it will trigger a rebuild of the source files that include it. For this to work reliably you'd have to include that header in every source file in a given library or executable. I realize the downside of this approach, but it may work for your situation better than saying tell your developers to clean and rebuild everything when they change an ADD_DEFINITION HTH, David On Wed, Dec 10, 2008 at 12:25 AM, Philip Lowman [EMAIL PROTECTED] wrote: On Tue, Dec 9, 2008 at 1:08 PM, Philip Lowman [EMAIL PROTECTED] wrote: This is a known problem. Visual Studio has no way of knowing that the compiler flags changed in a project file CMake is writing to. I would love to see a patch for this for CMake 2.8. One thought I had here was to have the vcbuild command clean any affected projects. This would have the advantage of isolating CMake from implementing any Visual Studio specific mods (i.e. delete these object files to force a recompilation, etc.). This would have some downsides though. 1. The easiest implementation
[CMake] Should changing, adding or removing add_definitions call trigger a recompile of affected files
I'm using CMake 2.6.3R5 on WinXP 64 using VS 2005 building a 32 bit binary. When I changed a CMake option it removed a call to add_definitions. The flags used to compile the project now changed. I thought I remember (and perhaps this was when I was using Makefiles more), that it should trigger a compile on the files that are now out of date. After configuring from cmake-gui, I clicked generate and the project reloaded. It started to compile, but everything was up to date. ??? Is this the intended behavior? I thought it used to cause recompiles of the affected files. Thanks, James ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Should changing, adding or removing add_definitions call trigger a recompile of affected files
On Tue, Dec 9, 2008 at 1:08 PM, Philip Lowman [EMAIL PROTECTED] wrote: This is a known problem. Visual Studio has no way of knowing that the compiler flags changed in a project file CMake is writing to. I would love to see a patch for this for CMake 2.8. One thought I had here was to have the vcbuild command clean any affected projects. This would have the advantage of isolating CMake from implementing any Visual Studio specific mods (i.e. delete these object files to force a recompilation, etc.). This would have some downsides though. 1. The easiest implementation would just be to perform the clean if a project file changes. This would result in more cleaning then necessary as changing source files (for example) shouldn't cause a rebuild. Certain project modifications like adding a source file to a target shouldn't cause a clean of that target. 2. Perhaps the biggest gotcha of all, cleaning a target would wipe out any binaries/libraries already generated. This is far different from the behavior of CMake's Makefile generator which simply causes targets to be rebuilt on the next make. Anyone have any ideas for fixing this? I've been bit by this one before (forgetting to rebuild everything when I change a preprocessor definition at the global scope). -- Philip Lowman ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
