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

[Reid Kleckner]

Something like this:
// windows.h
#define     IMAGE_FILE_MACHINE_AMD64     0x8664
// COFF.h
  enum MachineTypes {
    IMAGE_FILE_MACHINE_AMD64     = 0x8664,
  };



On Fri, Jun 6, 2014 at 11:09 AM, Zachary Turner <zturner at google.com> wrote:

> 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/d523f9bf/attachment.html>