Mail Archives: cygwin-apps/2002/05/05/14:05:43
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
- Raw text -