Cygwin/Mingw32 path difficulties

[Stephen Brandon]

Hi all,

Thanks to those who have given me advice about getting
things working on Windows. I'm slowly getting there.

There's another problem though, and I think that this may be
a relatively recent one. It's to do with the awful
interaction between cygwin paths, traditional Windows paths,
and mingw's idea of paths.

I have my cygwin and mingw directories on drive D.

These refer to the same directory:
Windows: d:\cygwin\usr\GNUstep
Cygwin tools (like ls, rm etc): /cygdrive/d/usr/GNUstep
MinGW tools (like gcc, cpp etc): d:/cygwin/usr/GNUstep

For MinGW tools, if you specify an absolute path without
drive letter, it's ok and does what you would expect. But
for CygWin tools, the path you specify gets appended to
cygwin's "virtual root", /cygdrive.

eg actual path: d:\foo.c
gcc /foo.c works...
ls -l /foo.c does not because it is looking for
/cygdrive/d/foo.c

In gnustep-make/Documentation/README.MinGW, the author
suggests using the following notation:

export GNUSTEP_SYSTEM_ROOT=//c/mingw/GNUstep/System

Unfortunately, neither MinGW nor Cygwin tools are happy with
this from the command line or in scripts.

One problem that all of this causes is that in
/usr/GNUstep/System/Makefiles/GNUstep.sh, the various
GNUSTEP_*_ROOT variables are stuck into PATH, with ":" as
the path separator. Of course, the "c:/..." style of drive
access conflicts with that.

So I use a sed command to change "c:..." style paths to
"/cygdrive/c/..." ones in GNUstep.sh when adding them to the
path. But then some of the other makefiles complain, in
particular common.make, which looks for
GNUSTEP_SYSTEM_ROOT/Tools explicitly within the path and
does not find it because it has been munged.

In any case, this does not address the fact that the paths
within $PATH may at times be interpreted differently by
different tools.

Have other people been able to address these issues?

Does anyone know if it would it be possible to change
cygwin's virtual mount point to simply "/" so that cygwin
and mingw paths become identical? I would prefer that as it
would mean being able to do away with drive letters in the
path, I think.

One way that this has tripped me up so far is that in the
configure script for gnustep-base, a check is made for
ffcall implementation. -I/usr/GNUstep/System/Headers is
included in the search path when looking for the
<objc/objc-api.h> header. For some reason (I thought that
the mingw gcc and cpp would not prepend the virtual root?!)
the specified search directory is not included unless it is
specified with drive letter as in -Ic:/usr/GNUstep/... or
wherever it happens to be.

So there are potentially lots of places where checks would
have to be made for which version of the path is being used.

Any advice appreciated,
Thanks,
Stephen Brandon
stephen@brandonitconsulting.co.uk