> From: Dylan Cuthbert [mailto:email@example.com]
> "Bill Tutt" <firstname.lastname@example.org> wrote in message
> > > From: Dylan Cuthbert [mailto:email@example.com]
> > >
> > > Hey, cygwin isn't quite that evil, it gives windows users a breath
> > > fresh
> > > air, allowing the use of emacs, bash, even Xfree86.. not to
> > about
> > > another 500+ really useful unix tools and libraries.
> > >
> > For things that don't port well to Windows, then yes it does, and
> > power to folks who like such things.
> > However, for projects like Subversion that have been ported to work
> > Windows, cygwin just shouldn't be used. It makes the maintainer's
> > more annoying by introducing the machinery cygwin uses to accomplish
> > some of the API calls used in Unix programs. Usually to a perf
> > detriment, not to mention assuming the users cygwin install is
> Not strictly true, we use cygwin as a development environment even
> aren't developing cygwin apps, this is because it supports things such
> symbolic-linking and a decent shell environment and decent scripting.
> is ok, but it has none of the shell or scripting stuff, simply being a
> decent compiler in a crap environment.
You do know that Windows 2000 on does have "symbolic links" (aka NTFS
reparse points) don't you? APR's file stat routine even groks these
I just write Python if I want scripting code to happen. With tab
completion in Win32's shell, I never need a decent shell except for Unix
oriented reasons. (i.e. a bash script that needs to get run)
> We can, of course, use the Windows SVN tools but they don't know about
> symlinks and directory paths of our environment which can be very
> frustrating sometimes.
Yet another reason why cygwin is so annoying. APR doesn't grok cygwin
symlinks out side of cygwin for example. I'm sure you might be able to
submit a patch for such support though.
> We are not going to start using Visual Studio or MSDOS (or whatever it
> become nowadays) so what do you suggest to replace Cygwin? Cygwin is
> important tool and no longer just a porting tool as it used to be IMO.
Cygwin is always a porting layer, it is nothing more. Having said that,
it doesn't mean that you can't just deal with a cygwin ported legacy
Unix application. With the associated perf hits, and Win32 system
interaction overhead. (Nobody else understanding those cygwin symlinks,
You certainly can't develop a seriously focused Win32 application using
cygwin, and indeed mingw. Mingw still can't get a subset of the COM ABI
implemented correctly. (Although it's not gcc's fault, MS patented the
I was just suggesting using mingw to compile Subversion, not about
anything else you might want to be do with cygwin/gcc.
Glad you're willing to pitch in and try and help figure things out
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Fri Sep 6 13:16:38 2002