Why wouldn't having this:<div>// CMAKE_CXX_FLAGS = '@CMAKE_CXX_FLAGS@'<br><br></div><div>in the <a href="http://header.h.in">header.h.in</a> 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...</div>
<div><br></div><div>Or this:<br></div><div>#if 0</div><div>CMAKE_CXX_FLAGS = '@CMAKE_CXX_FLAGS@'<br><div class="gmail_quote">#endif</div><div class="gmail_quote"><br></div><div class="gmail_quote">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...?)</div>
<div class="gmail_quote"><br></div><div class="gmail_quote">Am I missing something?</div><div class="gmail_quote"><br></div><div class="gmail_quote"><br></div><div class="gmail_quote"><br></div><div class="gmail_quote">On Wed, Dec 10, 2008 at 3:23 PM, James Bigler <span dir="ltr"><<a href="mailto:jamesbigler@gmail.com">jamesbigler@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">In other projects in the past (using autoconf), this is what we did.<br>
We used header files with configured options in them. After switching<br>
to CMake we noticed that when using makefiles changing compile flags<br>
would recompile the appropriate files. Hurray! It wasn't until<br>
recently we started to make more VS projects and noticed that it<br>
didn't follow the same behavior.<br>
<br>
One possible solution to this would be to create dependency file at<br>
each level you specify a set of flags for (i.e.<br>
directories/targets/source file). Then for each source you add a<br>
dependency on that file to the appropriate set of dependency files.<br>
If a flag or something else changes that should trigger a recompile<br>
the corresponding dependency file would also change (configure_file<br>
mechanism perhaps if it is thread safe). This might get us most of<br>
the way there. The only reservation I would have would be the amount<br>
of extra file I/O involved, but perhaps it wouldn't be that bad.<br>
<br>
I imagine this would be a large undertaking for anyone to implement.<br>
<br>
It's unfortunate that VS recognizes when you change the settings from<br>
the IDE, but not if settings change after reloading though I can<br>
understand why it doesn't work.<br>
<br>
Well, the most reliable solution (for options) is to configure header<br>
files based on CMake options than to use compiler preprocessor<br>
definitions as you suggest. This doesn't solve the issue of not<br>
recompiling if you change compilation flags (i.e. CMAKE_CXX_FLAGS).<br>
<font color="#888888"><br>
James<br>
</font><div><div></div><div class="Wj3C7c"><br>
On Wed, Dec 10, 2008 at 7:27 AM, David Cole <<a href="mailto:david.cole@kitware.com">david.cole@kitware.com</a>> wrote:<br>
> One way that might work would be to configure a header file that contains a<br>
> string representing the options of interest.<br>
> Then include that header file in *all* source files that you want to<br>
> rebuild.<br>
> When you change options in CMake and configure the header, it will only<br>
> change if something has changed, and then it will trigger a rebuild of the<br>
> source files that include it. For this to work reliably you'd have to<br>
> include that header in every source file in a given library or executable.<br>
> I realize the downside of this approach, but it may work for your situation<br>
> better than saying "tell your developers to clean and rebuild everything<br>
> when they change an ADD_DEFINITION"....<br>
><br>
> HTH,<br>
> David<br>
><br>
> On Wed, Dec 10, 2008 at 12:25 AM, Philip Lowman <<a href="mailto:philip@yhbt.com">philip@yhbt.com</a>> wrote:<br>
>><br>
>> On Tue, Dec 9, 2008 at 1:08 PM, Philip Lowman <<a href="mailto:philip@yhbt.com">philip@yhbt.com</a>> wrote:<br>
>>><br>
>>> This is a known problem. Visual Studio has no way of knowing that the<br>
>>> compiler flags changed in a project file CMake is writing to.<br>
>>><br>
>>> I would love to see a patch for this for CMake 2.8.<br>
>><br>
>> One thought I had here was to have the "vcbuild" command clean any<br>
>> affected projects. This would have the advantage of isolating CMake from<br>
>> implementing any Visual Studio specific mods (i.e. delete these object files<br>
>> to force a recompilation, etc.). This would have some downsides though.<br>
>><br>
>> 1. The easiest implementation would just be to perform the clean if a<br>
>> project file changes. This would result in more cleaning then necessary as<br>
>> changing source files (for example) shouldn't cause a rebuild. Certain<br>
>> project modifications like adding a source file to a target shouldn't cause<br>
>> a clean of that target.<br>
>><br>
>> 2. Perhaps the biggest gotcha of all, "cleaning" a target would wipe out<br>
>> any binaries/libraries already generated. This is far different from the<br>
>> behavior of CMake's Makefile generator which simply causes targets to be<br>
>> rebuilt on the next "make".<br>
>><br>
>> Anyone have any ideas for fixing this? I've been bit by this one before<br>
>> (forgetting to rebuild everything when I change a preprocessor definition at<br>
>> the global scope).<br>
>><br>
>><br>
>> --<br>
>> Philip Lowman<br>
>><br>
>> _______________________________________________<br>
>> CMake mailing list<br>
>> <a href="mailto:CMake@cmake.org">CMake@cmake.org</a><br>
>> <a href="http://www.cmake.org/mailman/listinfo/cmake" target="_blank">http://www.cmake.org/mailman/listinfo/cmake</a><br>
><br>
><br>
</div></div></blockquote></div><br></div>