Earnie Boyd wrote: >>(*) counter argument: gtk+ on cygwin currently uses X. However, the >>code is THERE to use native MS windowing -- because there is a native MS >>port (on a separate CVS branch). It might be possible, some time in the >>future, to have TWO different "gtk+" builds on cygwin: and X one and an >>MS one (it is not CURRENTLY possible to do that). But, in that >>eventuality, you could then have a whole SLEW of cygwin ports of >>gtk+-based programs that could be compile as "X" apps or as "native MS >>windowing" apps -- depending on which version of the gtk+ libs they were >>linked against. But should we borrow trouble against something that may >>never happen? (Tor Lilqvist, maintainer of the windows port of gtk+, >>doesn't seem too enthusiastic about refactoring to separate his >>native-windowing stuff from his msvcrt-not-glibc-runtime stuff; it's all >>#if _MSWIN ...). >> > > Ah, now the point at which I was trying to drive home at. Yes, IMO, we should > "borrow trouble" as that trouble is most likely to happen. It's much like the > MinGW libraries where the headers and libraries need to be segregated, so will > these apps.
Again, this is more of a name vs. a path issue -- especially when it comes to the gtk DLLs, for instance. SO WHAT if a cygwin "libgtk+1.3.0.dll" that uses the X libs lives in /usr/X11R6/bin and another cygwin "libgtk+1.3.0.dll" that uses native MS windowsing lives in /usr/bin -- switching PATH around to prefer one over the other is STILL a recipe for trouble. Not to mention conflicts with the truly natiove "libgtk+1.3.0.dll" that lives in you GIMP installation folder! Seems like The Right Thing is to have cyggtk+X-1.3.0.dll and cyggtk+MS-1.3.0.dll. And then it doesn't matter where the DLLs live, and you needn't muck with PATH at all. But then, you're talking about segregating the import libraries and header files (and possibly configuration files) -- and THAT takes MORE than just mucking with PATH. Whaddaya want to do, add new switches to cygwin's gcc: -muse-native-windowing-libraries and -muse-X-windowing-libraries to switch the default -I and -L paths, like -mno-cygwin does? My point: there are just too damn many issues to armchair this one. We are NOT going to get it right until we actually HAVE cygwin packages that are available as either X or MS windowing, but not both. Right now, we have NONE. ALL we have are X-only (many), MS-only (*), or BOTH X- and MS- in the same binary (**). The theoretical possibility of maybe perhaps having libraries or binaries that are available in X- or MS- windowing versions (excluding "both in same executable") is NOT enough to solve this one, IMO. Give me a REAL example where it ACTUALLY matters, right now. Otherwise, let's just drop this thread. We've changed packaging standards before. I've had to repackage my stuff at least twice (lib*.dll -> cyg*.dll, FOO_STATIC -> autoimport) due to merely packaging changes. If we have to rearrange things later, that's what maintainers DO. (*) actually, we may not have ANY of these -- except setup.exe itself, but that is not a cygwin-linked program anyway... (**) just one, at present - rxvt. --Chuck