Mail Archives: cygwin/2003/12/29/16:24:04
> Well, first off, I've done the obvious test, and verified
> that there is no "13k space saving". There might be 1/2k.
There is no 13k space saving *now*. There may well have
been with a previous set of sources and build tools.
> I can indeed run tests, but right now, no one has offered
> even a TINY SHRED of actual evidence that the current broken
> behavior ever saved any space or time.
Immaterial, unless you think you somehow deserve an apology?
> The one evidential claim made in the past was that getopts
> was 13k of executable size. It isn't.
As pointed out, all you know is that it isn't 13k *now*.
Besides, as Larry Hall has mentioned:
"It was the slowness of configure scripts that prompted the
streamlining of Cygwin's ash."
Larry's been around and involved in Cygwin for a good while, so
unless someone else can present some information that contradicts
his statement, I'm inclined to take his word on the matter.
> This suggests to me that no amount of testing matters; the
> decision here is an ego one, not an engineering one. The
> decision Was Made; therefore it is the Cygwin Way to break
> /bin/sh in the name of saving space, even if the space
> savings are actually 1/26th of what was claimed.
You *do* know what the Cygwin motto is, don't you?
WJM. PTC.
The ball is in your court. As Larry and others have mentioned,
you need to:
(a) Show that ash without getopt no longer results in a
significant space savings (which you've already done)
(b) Show that ash + getopt no longer results in configure
script slowness (yet to be done)
(c) Contingent on (a) and (b), submit a patch to the ash
maintainer that re-enables getopt in ash
> Can anyone honestly tell me that, if it turns out that
> enabling getopts imposes no significant performance penalty,
> that this will result in fixing the shell?
See (c), above. I'd wager that without a patch from you,
the maintainer will have little or no reason to re-examine
the issue.
Providing a patch and data showing that there's no regression
to the slow-configure-script issue will probably significantly
increase the chance of the problem being addressed.
> I see no reason to believe it, simply because there's never been
> any evidence that getopts was causing problems in the first place.
Maybe I'm naieve; but my thought is that at some point, people
who knew what they were doing made the decision that removing
getopt support from ash as a Good Thing.
While I have come to know and respect the people who apparently
made this decision, I have no idea who you are.
You've gained some measure of credibility by bringing up the issue,
and doing some simple experimentation to prove your point. It's a
shame that there is an increasingly shrill tone in your messages that
is swamping out your more reasoned arguments.
-Samrobb
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -