[PATCH] Change base mutex implementations to use STL-provided mutexes

[Zachary Turner]

Couldn't this be solved by definining everything we need (e.g.
_WIN32_WINNT, NOMINMAX, etc) at the CMake level?  What's the problem with
COFF.h?


On Fri, Jun 6, 2014 at 11:07 AM, Reid Kleckner <rnk at google.com> wrote:

> On Fri, Jun 6, 2014 at 10:52 AM, Zachary Turner <zturner at google.com>
> wrote:
>>
>> Ack, this breaks everything.  WindowsSupport.h is in
>> src\llvm\lib\Support\Windows.  In other words, it's not in the include
>> path.  It's usually only included from source files, in which case it's in
>> the same tree, so it works.  It this kind of "don't put platform specific
>> stuff in header files" a universal policy?  It seems to me like the
>> WindowsSupport.h (and correspondingly, the Unix support headers), should be
>> in the include directories so other headers can use them.  I'm guessing a
>> lot of the reason that these void* impls are needed is precisely because of
>> this restriction, and could be done away with in many cases if header files
>> had access to platform specific types, even if only through other header
>> files which typedefed platformed specific types to a set of common,
>> platform-independent types.
>>
>
> LLVM has a bunch of conflicts with windows.h, so including it from
> include/* will break if someone includes it with llvm/Support/COFF.h.
>  windows.h has so many configuration macros (WIN32_LEAN_AND_MEAN, WINVER,
> NOMINMAX) that including it broadly is inviting include order dependence
> problems, so we've avoided it so far.
>
> I think we should be able to get by with a semi-opaque
> CriticalSectionMutex, where the methods are defined out-of-line in
> lib/Support/Windows/Something.inc.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140606/f4af5c70/attachment.html>