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>
In the Windows SDK headers, is the IMAGE_* defines in a separate file (e.g. winint.h)? Does the file have a guard against multiple inclusion? If so (and the guard was named _WINNT_H_), perhaps you can do something like: #define _WINNT_H_ #include <windows.h> So you would get everything except those file format defines. Of course, this would fail if other parts of the windows header rely on stuff declared in the the file being excluded. Alternately, could you include the lower level windows headers rather than the top level windows.h (e.g #include <winbase.h> but not <windows.h>) [I've never done Windows development, so I'm just stabbing in the dark here] -Nick On Aug 28, 2013, at 7:19 PM, Virgile Bello wrote:> 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 > >
The odds of #define _WINNT_H working are incredibly slim :) You can't include the separate headers (winbase.h etc), you have to just include windows.h Windows defines IMAGE_* whether we like it or not, we can't stop it doing it, so the only reasonable solution is to change LLVM to have it's own set of constant names. Nick Kledzik wrote:> In the Windows SDK headers, is the IMAGE_* defines in a separate file (e.g. winint.h)? Does the file have a guard against multiple inclusion? If so (and the guard was named _WINNT_H_), perhaps you can do something like: > > #define _WINNT_H_ > #include<windows.h> > > So you would get everything except those file format defines. Of course, this would fail if other parts of the windows header rely on stuff declared in the the file being excluded. > > Alternately, could you include the lower level windows headers rather than the top level windows.h (e.g #include<winbase.h> but not<windows.h>) > > [I've never done Windows development, so I'm just stabbing in the dark here] > > -Nick > > On Aug 28, 2013, at 7:19 PM, Virgile Bello wrote: > > >> 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 >>> >> > > > _______________________________________________ > 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/4478c24e/attachment.html>
On Wed, Aug 28, 2013 at 7:19 PM, Virgile Bello <virgile.bello at gmail.com>wrote:> 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...). >Can you write opaque wrappers for these things? Then you could include windows.h from the .cpp file and avoid it in any headers. Keeping windows.h out of your transitive includes is nice anyway. You shouldn't need COFF.h in the .cpp implementation files. In LLVM, most of this kind of functionality is in lib/Support, and nothing in include/llvm/Support includes windows.h.> 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. >I'd prefer it if you evaluated this first, but if it's too hard, yeah, let's change COFF.h.> Alternatively I could #undef everything right after including Windows.h. >I'd rather avoid this. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130829/37133faf/attachment.html>