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

[James Bigler]

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 <david.cole at 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?
>
>
>
> 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/1cb3340c/attachment.htm>