llvm dev - Oct 2015 - [llvm] r250383 - Speculatively unbreak Windows build

Ah, I see this was addressed in 250386 - though might be nice to address
across the whole project rather than this particular inclusion. Though
maybe we've few enough inclusions that it's not too bad.

On Fri, Oct 16, 2015 at 2:51 PM, David Blaikie <dblaikie at gmail.com>
wrote:
>
>
> On Thu, Oct 15, 2015 at 2:17 AM, David Majnemer via llvm-commits <
> llvm-commits at lists.llvm.org> wrote:
>
>> Author: majnemer
>> Date: Thu Oct 15 04:17:15 2015
>> New Revision: 250383
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=250383&view=rev
>> Log:
>> Speculatively unbreak Windows build
>>
>> <windows.h> defines macros named min and max in conflict with
>> <algorithm>.  Prevent macro expansion by wrapping std::min in
>> parenthesis.
>>
>
> Could we just build with NOMINMAX in the windows build?
>
>
>>
>> Modified:
>>     llvm/trunk/tools/llvm-pdbdump/llvm-pdbdump.cpp
>>
>> Modified: llvm/trunk/tools/llvm-pdbdump/llvm-pdbdump.cpp
>> URL:
>>
http://llvm.org/viewvc/llvm-project/llvm/trunk/tools/llvm-pdbdump/llvm-pdbdump.cpp?rev=250383&r1=250382&r2=250383&view=diff
>>
>>
=============================================================================>>
--- llvm/trunk/tools/llvm-pdbdump/llvm-pdbdump.cpp (original)
>> +++ llvm/trunk/tools/llvm-pdbdump/llvm-pdbdump.cpp Thu Oct 15 04:17:15
>> 2015
>> @@ -361,8 +361,8 @@ static void dumpStructure(MemoryBufferRe
>>        if (BytesLeftToReadInStream == 0)
>>          break;
>>
>> -      uint32_t BytesToReadInBlock >> -         
std::min(BytesLeftToReadInStream,
>> static_cast<uint32_t>(SB->BlockSize));
>> +      uint32_t BytesToReadInBlock = (std::min)(
>> +          BytesLeftToReadInStream,
static_cast<uint32_t>(SB->BlockSize));
>>        auto StreamBlockData >>           
StringRef(M.getBufferStart() + StreamBlockOffset,
>> BytesToReadInBlock);
>>        if (auto EC = checkOffset(M, StreamBlockData))
>>
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151016/bcddff52/attachment.html>

On Fri, Oct 16, 2015 at 2:55 PM, David Blaikie via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Ah, I see this was addressed in 250386 - though might be nice to address
> across the whole project rather than this particular inclusion. Though
> maybe we've few enough inclusions that it's not too bad.
>
I'd rather not have an extra flag to every compilation just to handle the
odd inclusion of windows.h. Most of LLVM should not be including
system-specific headers, and the parts that do should be small.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151016/d569282e/attachment.html>

Can you instead always proxy-include windows.h? Force all LLVM inclusions
of windows.h to go through lib/Support/Windows/WindowsSupport.h (move it to
include/ instead) and add NOMINMAX. It already has WIN32_LEAN_AND_MEAN, you
could even pile on with VC_EXTRALEAN.

On Fri, Oct 16, 2015 at 4:15 PM, Reid Kleckner via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On Fri, Oct 16, 2015 at 2:55 PM, David Blaikie via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Ah, I see this was addressed in 250386 - though might be nice to
address
>> across the whole project rather than this particular inclusion. Though
>> maybe we've few enough inclusions that it's not too bad.
>>
>
> I'd rather not have an extra flag to every compilation just to handle
the
> odd inclusion of windows.h. Most of LLVM should not be including
> system-specific headers, and the parts that do should be small.
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151016/af1c87ba/attachment.html>