[CMake] Should changing, adding or removing add_definitions call trigger a recompile of affected files

[James Bigler]

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 <david.cole at kitware.com> 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 <philip at yhbt.com> wrote:
>>
>> On Tue, Dec 9, 2008 at 1:08 PM, Philip Lowman <philip at yhbt.com> 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 at cmake.org
>> http://www.cmake.org/mailman/listinfo/cmake
>
>