Re: [PATCH] fmt-merge-msg: avoid open "-|" list form for Perl 5.6

From: Christopher Faylor <me@cgf.cx>
Date: Feb 26, 2006, 20:33 UTC
Message-ID: <20060226203310.GB30735@trixie.casa.cgf.cx>
In-Reply-To: <43FDB8CC.5000503@op5.se>

On Thu, Feb 23, 2006 at 02:29:48PM +0100, Andreas Ericsson wrote:

Show 23 quoted lines

>Alex Riesen wrote:
>>On 2/23/06, Andreas Ericsson <ae@op5.se> wrote:
>>
>>>Not to be unhelpful or anything, but activestate perl seems to be quite
>>>a lot of bother. Is it worth supporting it?
>>
>>
>>It's not activestate perl actually. It's only one platform it also
>>_has_ to support.
>>Is it worth supporting Windows?
>
>
>With or without cygwin? With cygwin, I'd say "yes, unless it makes 
>things terribly difficult to maintain and so long as we don't take 
>performance hits on unices". Without cygwin, I'd say "What? It runs on 
>windows?".
>
>If we claim to support windows but do a poor job of it, no-one else will 
>start working on a windows-port. If we don't claim to support windows 
>but say that "it's known to work with cygwin, although be aware of these 
>performance penalties...", eventually someone will come along with their 
>shiny Visual Express and hack up support for it, even if some tools will 
>be missing and others unnecessarily complicated.

Well, with Cygwin, you've at least got the ear of one of the Cygwin maintainers, which should be worth something.

Even if I disappear, you can always send concerns to the Cygwin mailing list. Do the ActiveState folks respond to complaints about things as basic as pipes not working in perl?

Cygwin's goal is to make Windows look as much like Linux as we can manage, so, unless we're total incompetents (which has been hinted in this mailing list from time to time), it has *got* to be better, source-code-wise to target Windows-running-Cygwin than just-plain-Windows. However, as has been noted, that means that there will be a speed tradeoff.

I think that, for most projects, the convenience of not having to clutter the code with substantial accommodations for the windows/POSIX mismatch usually offsets the annoyance of the speed penalty. Maybe that's not the case for git, however.

Anyway, we're willing, within the limits of available time, to help out where git uncovers issues with Cygwin. I just fixed some stuff in dirent.h in the last Cygwin release, as a direct result of people noting a problem here. Basically, I don't want git to be a morasse of #ifdef __CYGWIN_'s and I'll do whatever I can to help.

We're always trying to tweak things to improve speed in Cygwin and am open to intelligent suggestions about how we can make things better. The dance between total linux compatibility and speed is one that we struggle with all of the time and, sadly, over time, we've probably sacrificed speed in the name of functionality. That's probably because it's easy to fix a problem like "close-on-exec doesn't work for sockets" and feel good that you've fixed a bug even if you've just added a few microseconds to fork/exec.

cgf