On Mon, 2010-07-12 at 10:41 +0200, Corinna Vinschen wrote: > That's something I'll doo as soon as we really intend to switch the > Cygwin build to mingw64's w32api. Right now, what I get from all the > gory details, it's not that easy to keep mingw64's w32api headers and > libs apart from the mingw headers and libs anyway.
No, it's not. > You're missing number 4. Cygwin and Mingw are targeting the same > underlying "real" target, which is Windows. 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. 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. > If there's no way around it, I don't mind if we have multiple w32api, > one for the system and one for each mingw cross compiler. I don't > mind the disk space. I don't know beforehand which solution will > result in more or less user confusion. So just go ahead. This will be much easier from the packaging perspective. > As for the path issue, I'd prefer to get a layout which closely > resembles the Fedora mingw filesystem layout as in > http://fedoraproject.org/wiki/Packaging/MinGW#Filesystem_layout. That is what I'm working with now. Yaakov