[cfe-dev] MinGW(-w64) fixes to InitHeaderSearch.cpp and float.h

[Ruben Van Boxem]

Op 27 jun. 2011 17:51 schreef "Douglas Gregor" <dgregor at apple.com> het volgende:
>
> On Jun 25, 2011, at 7:51 AM, Ruben Van Boxem wrote:
>
>> Hi,
>>
>> I bring fixes for MinGW(-w64) Clang users:
>>
>> 1. InitHeaderSearch.cpp: add a HeaderSearchOptions argument to
>> AddDefaultCXXIncludePaths (AddDefaultCIncludePaths already had this,
>> seems only logical to have it here) and use ResourceDir to find the
>> sysroot of where Clang.exe is located. From there, add the
>> x86_64-w64-mingw32 and i686-w64-mingw32 include paths for C and C++.
>> All mingw-w64 toolchains are built --with-sysroot, and thus
>> relocatable, so this change will always find the accompanying headers.
>
> I've committed this part as r133911.
>
>> 2. float.h: MinGW needs an #include_next, because as described on this
>> page (http://msdn.microsoft.com/en-us/library/y0ybw9fy.aspx) there are
>> non-standard extensions to float.h which are expected on Windows, and
>> MinGW provides these declarations in their system header. GCC's
>> float.h is "fixinclude"d to include_next the system header. Note that
>> a trivial change is needed in mingw-w64's float.h, and that change
>> will be committed as soon as Clang's header does what it's supposed to
>> do.
>
>
> If we're including MinGW's float.h first, then our own definitions of all of the standard float.h macros are going to stomp on the ones that come from MinGW's float.h. I think that's a reasonable thing to do, but if that's the intent, I'd prefer to have #undef's in our own float.h to make it explicit that this is what we're doing (and so that our own headers don't generate warnings, even if they're suppressed).

I just copied that behavior (and the comment) from <stdint.h>, but I
know that mingw-w64's float.h header does #undef everything it
redefines, so it would perhaps be better if the #include_next in
Clang's float.h came at the end. Then nothing else needs to change
much.

Ruben