[LLVMdev] COFF.h and windows.h conflict

[Virgile Bello]

It was happening in a few files using COFF.h in LLDB for the windows branch
(Windows.h is required for some typedef over Mutex, thread, socket, etc...).

As said before, I am currently checking if it could be avoided (probably
some refactoring will be needed). However I was wondering if it might not
be easier to just avoid this clash at all by avoiding it in LLVM.

Alternatively I could #undef everything right after including Windows.h.


On Thu, Aug 29, 2013 at 11:08 AM, Nick Kledzik <kledzik at apple.com> wrote:

>
> On Aug 28, 2013, at 7:05 PM, Virgile Bello <virgile.bello at gmail.com>
> wrote:
>
> Right now, we have:
> In COFF.h:
>     class COFF { enum MachineTypes { IMAGE_FILE_MACHINE_UNKNOWN   = 0x0,
> ... }; };
> In windows.h:
>     #define IMAGE_FILE_MACHINE_UNKNOWN 0
>
> * If you first include COFF.h and then windows.h,
>     COFF::IMAGE_FILE_MACHINE_UNKNOWN
> will be preprocessed into
>     COFF:0.
>
> * If you first include Windows.h and then COFF.h, COFF.h won't work
> because it's enum will become:
>     enum MachinTypes { 0 = 0x0 };
>
> Sorry, I was not clear.  Why is Windows.h being included at all?  That
> header does not exist on some OS’s so the code would not build be portable.
>  If this use is in the one or two files of llvm that implement platform
> support, why is COFF.h being included in those instances?
>
> -Nick
>
>
>
>
> On Thu, Aug 29, 2013 at 6:03 AM, Nick Kledzik <kledzik at apple.com> wrote:
>
>>
>> On Aug 27, 2013, at 5:56 PM, Virgile Bello <virgile.bello at gmail.com>
>> wrote:
>>
>> Yes of course I understand it was done on purpose.
>> It's just that it makes it impossible to include COFF.h and Windows.h
>> side by side (which probably wasn't necessary until now).
>>
>>
>> I too am in the camp that it is a feature to use the standard names.  For
>> instance doing a search it google or github of the documented names will
>> find uses.
>>
>> Where exactly is the conflict happening?    Is the problem that something
>> in llvm is including windows.h?  Or that some std lib C/C++ header is being
>> included and the OS provided std header is including windows.h?
>>
>> -Nick
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130829/39c2d876/attachment.html>