Re: new cygwin package: cgoban

[Charles Wilson <cwilson at ece dot gatech dot edu>]

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