David Blaikie via llvm-dev
2015-Oct-16 21:55 UTC
[llvm-dev] [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>
Reid Kleckner via llvm-dev
2015-Oct-16 23:15 UTC
[llvm-dev] [llvm] r250383 - Speculatively unbreak Windows build
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>
JF Bastien via llvm-dev
2015-Oct-17 04:59 UTC
[llvm-dev] [llvm] r250383 - Speculatively unbreak Windows build
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>