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

[David Cole]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20081210/cf5b637c/attachment-0001.htm>