[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