This is the mail archive of the cygwin-xfree@cygwin.com mailing list for the Cygwin XFree86 project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: AW: SETUP WIZARD FOR CYGWIN?XFREE


> 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 
discussion off-line>.


> 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 -- 
please contribute...


> 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
> pile.


<g>


>>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.

--Chuck





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]