bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: some emacs-21.1.1 problems


From: Eli Zaretskii
Subject: Re: some emacs-21.1.1 problems
Date: Fri, 23 Nov 2001 15:10:36 +0200

> From: David Kastrup <David.Kastrup@t-online.de>
> Newsgroups: gnu.emacs.bug
> Date: 23 Nov 2001 11:58:08 +0100
> 
> >>>>> "Eli" == Eli Zaretskii <eliz@is.elta.co.il> writes:
> 
>  >> From: David Kastrup <David.Kastrup@t-online.de>
>  >> Newsgroups: gnu.emacs.bug
>  >> Date: 22 Nov 2001 21:24:35 +0100
>  >> 
>  >> From the above, BTW, I get the impression that the first thing you
>  >> should throw out, free or not, is Cygwin.
> 
>  Eli> Apart from Cygwin and DJGPP, there's no other comparable effort
>  Eli> to port GNU software to Windows, so Windows users who cannot
>  Eli> toss Windows have nowhere else to go.
> 
> We were talking just an Emacs port and I have to say I find it
> surprising that you snipped my reference to mingw32 in order to make
> your point.  Emacs compiles with mingw32 and then should not exhibit
> the multitude of idiosyncrasies the original poster encountered.

AFAIU, we were talking about ports of GNU software _besides_ Emacs.
Jason made his remark about a program that wouldn't work with Emacs
because that program was a Cygwin port, while Emacs wasn't.

That's why I didn't keep the reference to the MinGW build of Emacs: it
was IMHO irrelevant to the Cygwin program that started this
discussion, which wasn't Emacs.

If I misunderstood the issue at hand, I apologize for the line noise.

> While the mingw32 might not be a "comparable effort", I find it
> laudable that they don't go to such lengths of making the environment
> seem what it isn't.

I agree.  The problem which Windows users face is that you can't
easily find MinGW ports of GNU utilities beyond the most basic ones
(Emacs, GCC, Binutils, and Make).

> In short, I consider the decidedly smaller effort a good design
> decision.

Actually, it takes more effort to produce a MinGW port than to
produce the Cygwin port.  Cygwin tries to hide the problems inside
the C library, and the Cygwin ``ports'' are simply straight
compilations of the original sources.  The problem with this approach
is that the library doesn't know enough about the context to DTRT in
some subtle cases.  The _real_ solution to this is to make changes to
the application sources (e.g., when some code assumes every absolute
file name begins with a slash), but Cygwin ports don't do that.  To
do that correctly requires to go through the whole application source
and modify it where appropriate.  That's a non-trivial job.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]