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

[David Cole]

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