Mailing-List: contact cygwin-apps-help AT cygwin DOT com; run by ezmlm Sender: cygwin-apps-owner AT cygwin DOT com List-Subscribe: List-Archive: List-Post: List-Help: , Mail-Followup-To: cygwin-apps AT cygwin DOT com Delivered-To: mailing list cygwin-apps AT cygwin DOT com Message-ID: <3CD57490.20709@ece.gatech.edu> Date: Sun, 05 May 2002 14:06:08 -0400 From: Charles Wilson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Earnie Boyd CC: Robert Collins Subject: Re: new cygwin package: cgoban References: <3CD3DD22 DOT 76BD5C0 AT yahoo DOT com> <3CD428C7 DOT 8000206 AT ece DOT gatech DOT edu> <3CD42CF7 DOT 874A8C49 AT yahoo DOT com> <3CD440EF DOT 9070405 AT ece DOT gatech DOT edu> <3CD51E19 DOT 5A7708D7 AT yahoo DOT com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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