[LLVMdev] COFF.h and windows.h conflict

[Virgile Bello]

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).


On Wed, Aug 28, 2013 at 9:52 AM, Reid Kleckner <rnk at google.com> wrote:

> IMO the fact that it uses the standard names from the COFF documentation
> is a feature, not a bug.
>
> The elf and macho headers in the same directory use the standard
> enumeration names, correct?
>
>
> On Tue, Aug 27, 2013 at 5:41 PM, Virgile Bello <virgile.bello at gmail.com>wrote:
>
>> Hello,
>>
>> I noticed that if include\llvm\Support is included alongside Windows.h,
>> there will be many define conflict leading to compilation errors, such as:
>>
>> COFF.h (enum): enum MachineTypes { IMAGE_FILE_MACHINE_UNKNOWN   = 0x0,
>> ... };
>>
>> and
>>
>> winnt.h (same but define): #define IMAGE_FILE_MACHINE_UNKNOWN 0
>>
>> Of course I could try to avoid to include both (but it's rather difficult
>> and would require lot of refactoring -- we have this clash currently in
>> LLDB MinGW32 port).
>> I was wondering if instead it was possible to simply rename those enum
>> little bit differently in COFF.h so that it doesn't clash?
>> I know windows.h is quite invasive, so maybe it's better not try to
>> collide with any of its weird define.
>>
>> If that makes sense I'm fine with doing the patch.
>> If yes, feel free to propose an alternative naming prefix or scheme.
>>
>> Note that if tools depend on COFFDumper::printFileHeaders output, it
>> might still need to print as it was before -- so the easiest choice might
>> be to maybe just drop the IMAGE_ (anyway it's in llvm::COFF so it shouldn't
>> matter). Is it important?
>>
>> Thanks,
>> Virgile
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130828/f6eea1aa/attachment.html>