This is the mail archive of the
mailing list for the Cygwin XFree86 project.
Re: AW: SETUP WIZARD FOR CYGWIN?XFREE
- To: cygwin-xfree at cygwin dot com
- Subject: Re: AW: SETUP WIZARD FOR CYGWIN?XFREE
- From: Charles Wilson <cwilson at ece dot gatech dot edu>
- Date: Fri, 27 Jul 2001 17:09:41 -0400
- References: <3B61095D.4D45AFE0@ece.gatech.edu>
> On Fri, Jul 27, 2001 at 02:25:33AM -0400, Charles Wilson wrote:
>>The cygwin developers TRY to maintain forward compatibility when
>>possible -- and in fact, the 1.3.1 problem you mention was a mistake.
>>The check_for_executable should have been encapsulated inside an opaque
>>structure like __impure_ptr, but it was overlooked.
> Actually, it was not a mistake. I knew that I was breaking backwards
> compatibility. Putting this inside impure_ptr would have been very
> difficult. I thought I had a magical way of speeding up cygwin's
> stat function but it turned out to be flawed.
> We break compatibility with older DLLs all of the time. For instance,
> "I've" just added the signgam export
Ouch! A hit, a palpable hit! <g>
(For those who don't know, *I* submitted the patch to export signgam.)
> and I'm in the process of exporting
> sys_nerr and sys_errlist.
> As soon as something is compiled which uses one of those
> variables/functions, it will be unusable with older dlls.
Right, but I think the problem w.r.t. check_for_executable was not that
the ncurses source code explicitly called it (at least, not on purpose),
but that ncurses called a cygwin function that called
check_for_executable, or the 1.3.1 .h files #defined or __inline__'d
something...but I don't remember all the details., and I could just be
talking bull patties.
However, your point about signgam is well taken.
> The reason that Cygwin is "flaky" is that I'm trying to fix a pretty
> serious problem in 1.3.2. I have had zero time to devote to fixing the
> flakiness this week, though.
I know -- I wasn't being critical, even if it sounded that way. I must
admit, though, that I haven't really understood what all the fuss was
about w.r.t. 1.3.2 -- it's been working great for me, so I haven't
really been paying much attention. (sorry) <but we can take that
> And, *of course* we release versions that have unknown side effects.
> You might as well say that we all need oxygen to survive. If the side
> effects were *known* then we wouldn't release them.
> The usual counter to that is "You should do better testing" and I would
> love to have a fully fleshed out test suite and someone to run the
> tests. I don't have any of that. What I have is people who try out
> cygwin snapshots. If they report bugs in the snapshots, I try to fix
> them. When things seem relatively stable (which they are definitely not
> right now) then I release a new DLL.
Just so everybody knows, there ARE the beginnings of a test suite -- for
winsup -- in cygwin CVS. It just doesn't have many tests in it --
> Consider it a rite of passage. When Chuck reports a bug, I think "Hmm.
> There must be a bug" and I investigate it. Guess why that is?
Aw, gee, I feel so warm and fuzzy.
> When random cygwin mailing list person reports a bug and I am not
> immediately familiar with it I usually put it in my queue to investigate
> or I ask Corinna to look at it, if it is in her area of expertise. We
> have an incredible number of people reporting non-bugs, asking the same
> question, making the same "suggestions". So, bugs from unknown sources
> don't get a lot of my attention.
> FWIW, these days when I see email from Ralf, I put it in my priority
>>Sure, betas -- fine by me. But I thought you were preparing for a
>>"real" release -- and THAT's what got me steamed.
> Also, I don't think that it is extremely clear that the libraries will
> be disappearing or that the cygwin DLL is unofficial. It's mentioned in
> your readme but we all know how many people read that.
> Also, since you include a modified version of the cygwin 1.3.2 DLL, I'm
> not sure why you need versions of Chuck's packages.
Hmmm...that's a good point. I think we're running into a version skew
problem of our own: at first, kde1 only worked with 1.1.8 because of
the cygwin bug Ralk discovered. So, he wanted to distribute kde1 with
1.1.8, BUT because of the check_for_executable thing, he needed to
distribute an old ncurses dll too (and got carried away with jpeg, tiff...).
But then a fix was found for the cygwin bug, Ralf rolled his own
cygwin1.dll-1.3.2+ and is distributing THAT now with kde1. But...he
neglected to remove ncurses (and ....)
>>>Additional I have read about a "non-new-package" of cygwin, so
>>>distributing kde directly with cygwin isn*t possible at now. As I have
>>>to work on other projects in the next time too, so I have to release
>>>this beta now.
>>Right. Beta. Good. Beta...
> ...and the whole purpose of the "no new packages" is so that we can
> work out a scheme to include X11 and KDE in cygwin setup.
Yep. What he said.