[CMake] triggering rebuild on windows

j s j.s4403 at gmail.com
Mon Aug 31 22:12:01 EDT 2009


According to Microsoft, the math macros are not part of standard C/C++:
http://msdn.microsoft.com/en-us/library/4hwaceh6(VS.80).aspx

I'm not going to quibble with them on that point, as they were nice enough
to provided them with:
_USE_MATH_DEFINES

as an alternative.  The problem is the config.h approach is I now have to
include a config.h everywhere I want to use a math macro.  Even worse is if
I put all my platform dependent options in that file.  If I put an unrelated
macro change in that file, I just retriggered a rebuild for many files not
requiring a rebuild.    The potential for triggering unnecessary rebuilds
anytime that file is regenerated is just not worth it.

I will quibble with Microsoft that Visual Studio does not detect when the
compilation options change.

Regards,

Juan

On Mon, Aug 31, 2009 at 8:45 PM, Philip Lowman <philip at yhbt.com> wrote:

> On Mon, Aug 31, 2009 at 8:02 PM, j s <j.s4403 at gmail.com> wrote:
>
>> I am doing cross-platform compilation.  I don't want everything to
>> recompile on all platforms.  That is a risk with having a configuration
>> header file.  If I remember correctly, cmake would ignore conditional
>> include guards when doing dependency scanning.  Therefore:
>> #ifdef WIN32
>> #include "config.hh"
>> #endif
>>
>> would trigger a compilation on all platforms if config.hh changed.
>>
>> I want everything to recompile on Windows, but not on my linux builds.
>>
>
> I think when he meant a config file he meant one created by CMake
> dynamically (which would only affect one build anyways).
>
> In other words:
>
> config.h.in:
> #cmakedefine FOO
>
> CMakeLists.txt:
> set(FOO true)
> configure_file(${CMAKE_CURRENT_SOURCE_DIR}/config.h.in
>                    ${CMAKE_CURRENT_BINARY_DIR}/config.h)
> include_directories(${CMAKE_CURRENT_BINARY_DIR})
>
> config.h now includes "#define FOO 1"
>
>
> Of course if all you need is the "unborkify MSVC so it supports math.h"
> define then it's probably not worth it. :)
>
>
> --
> Philip Lowman
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20090831/7926c43b/attachment.htm>


More information about the CMake mailing list