On 7/12/2010 8:02 AM, Corinna Vinschen wrote: > On Jul 12 05:25, Yaakov S wrote: >> On Mon, 2010-07-12 at 10:41 +0200, Corinna Vinschen wrote: >>> You're missing number 4. Cygwin and Mingw are targeting the same >>> underlying "real" target, which is Windows.
I wasn't actually "missing" it; I just considered this part of #2, but didn't fully express it: "things that should be identical...out of sync". E.g. if it's all one OS, then all compilers should use identical headers. And, if they are (or should be) identical, then why not have a single common location? I understand that argument, but we're not sure they all really CAN be identical (e.g. the 64bit libs vs. the 32bit ones; the possible issue with mingw64 headers' provenance, etc). So, if there might be SOME differences, then... It makes sense to me, then, that each toolchain should provide, in a private area (e.g. sysroot), that version of the w32api libs and headers with which it has been tested. Rather than a hodge-podge where "these two cross toolchains have their own custom w32api headers that they share between them but separate copies of the w32api libs; /that/ one has a custom w32api that isn't shared with anybody, but /this/ one shares w32api with cygwin's gcc..." Ick.) >>> Both systems use different >>> approaches and both have their own set of libs and headers which only >>> make sense in their own environment. But underneath they both run on >>> Windows. For that reason my POV is that w32api is an intrinsic part of >>> the system and that's why it belongs into /usr/include and /usr/lib. >>> IMHO. I assume that you were not proposing to move the w32api headers from /usr/include/w32api/ into /usr/include/ proper, nor the libs from /usr/lib/w32api into /usr/lib proper, were you? If the cross toolchains provide their own w32api (and mingw-runtime) [or, for 64bit, "mingw64-crt-headers" and "mingw64-crt-lib"], then...the only remaining user of our current w32api api package is cygwin's own gcc (all versions). And the only remaining user of our current mingw-runtime packages is cygwin's gcc3 (and anything that might require /usr/bin/mingwm10.dll). So, after all of the cross compilers are deployed, we might think about what optimizations we could make with regards to how the non-toolchain-sysroot-specific w32api and mingw-runtime packages are...packaged. (The answer may be: make no changes.) But I don't want to start that discussion too early, so let's table it for now. >> OTOH there are a number of packages out there that see <windows.h> in >> the default include path and say, "Oh, this must be a Windows system! >> Let's use winsock/GDI/etc." which is often -- but not always -- >> incorrect on Cygwin. w32api may not be limited to cross-compiling, but >> having it in the default search path isn't always great either. > > Yeah, everything comes with a price tag. Yep. I have to keep reminding people that #including <windows.h> will cause _WIN32 to be defined, and that #ifdef _WIN32 does not, actually, mean !CYGWIN... -- Chuck