Am 01.11.2011 19:55, schrieb Eric Sunshine: > On Nov 1, 2011, at 2:05 PM, Andreas Färber wrote: >> Am 01.11.2011 19:01, schrieb Peter Maydell: >>> On 1 November 2011 17:59, Andreas Färber <andreas.faer...@web.de> wrote: >>>> Apple's FSEvents.h has #include <Block.h>, which wants >>>> /usr/include/Block.h but due to case-insensitive file system and >>>> include path jungle gets QEMU's ./block.h, which in turn includes >>>> softfloat.h indirectly. >>> >>> Incidentally, surely you need to fix this anyway (ie fix the >>> include path issue somehow)? >> >> Yes, that's why I'm explicitly documenting it. I have no clue how to fix >> it though. Experts' opinion welcome! > > > It probably is not a good idea to emphasize the particular #include > stack issued by this one build environment (presumably XCode on Lion?) > so loudly in the commit message. The type redefinition error will > manifest regardless of #include ordering and regardless of whether or > not ./block.h is picked up accidentally instead of <Block.h>. For > instance, on Leopard with XCode 3.1.4, the #include stack emitted with > the error message is entirely different even though the underlying issue > is the same: > > OBJC ui/cocoa.o > In file included from ./bswap.h:8, > from ./qemu-common.h:107, > from ui/cocoa.m:29: > /Users/sunshine/Desktop/qemu/fpu/softfloat.h:60: error: conflicting > types for 'uint16' > /System/Library/Frameworks/Security.framework/Headers/cssmconfig.h:68: > error: previous declaration of 'uint16' was here > make: *** [ui/cocoa.o] Error 1 > > In fact, on Leopard, FSEvents.h does not #include <Block.h>, so focusing > on it in the log message is misleading.
My point is, that's the reason it needs to be fixed *this* way and not in cocoa.m like you'd expect. If it doesn't show up in git-blame, people will not understand and "clean up". It's always just an example since it includes user-specific paths - here Snow Leopard. Rewording. AF
