Re: Quantifying the time overhead of Cygwin make

On 10/06/14 13:06, Michael Stahl wrote:
> On 10/06/14 12:47, Bjoern Michaelsen wrote:
> > Hi,
> >
> > On Tue, Jun 10, 2014 at 01:22:16PM +0300, Tor Lillqvist wrote:
> > > You mean cmd.exe + coreutils should be enough?
> >
> > > Probably bash or some other POSIX shell too, surely?
> >
> > Yeah. Note that e.g. busybox already includes the ash shell.
> >
> > > Is there a non-Cygwin such that actually would support all the shell
> > > constructs we use? Is its complexity that much less than Cygwin's?
> >
> > busybox, msys, there are quite a few standalone bash ports.
>
> it's possible that Msys has a lot of the things we need, but perhaps not
> things like cabextract, doxygen, gperf, perl, python.

was toying around with MSYS a bit, and it's not really usable... it
turns out it has its own Cygwin-like POSIX file-system thing, and it's a
little different:

- absolute paths don't have cygdrive in them, they look like /c/foo/bar

- there is no tool like cygpath to convert between POSIX and native path

- Cygwin's cygpath of course doesn't work because it produces "cygdrive"

- the conversion is done implicitly, with some bizarre heuristic that
  often does the wrong thing, e.g. it converts "@${RESPONSEFILE}" from
  "@C:/Cygwin/tmp/foo" to "@C;C:/Msys/Cygwin/tmp/foo", and you
  effectively can't disable that (you can start path with "//" but that
  doesn't help if you already have a native/mixed path...)
  http://www.mingw.org/wiki/Posix_path_conversion

oh and the MSYS perl and autotools were choking horribly on autogen.sh.

funnily Cygwin has the best support for "mixed" paths that we now use
~everywhere in gbuild (with the exception that tar expects its arguments
as Cygwin paths, because it already does something weird with
colon-separated arguments).