[Top][All Lists]

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

Re: strange interaction between gmake and cygwin

From: Earnie Boyd
Subject: Re: strange interaction between gmake and cygwin
Date: Tue, 04 May 2004 16:38:20 -0400
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113

AFAIR, Cygwin has a modified version of make. You'll have to apply the necessary changes.


Sandy Currier wrote:

Hi all,

I seem to be getting a strange interaction between bash and gmake 3.81beta1 for DOS. The top level problem is that in some cases it appears that gmake is substituting a windows type path instead of a unix type path for the shell
even though it knows the shell is unix-like (bash).

Consider the following makefile:

SHELL        := bash.exe
DOS2UNIX    = $(shell cygpath -u $(1))
ifeq (,$(TEST1))
BAR        := /sandbox/scurrier/workspaces/bar
BAR        := ./bar
foo        := $(shell perl $(BAR))

   @echo "bash   =$(BASH)"
   @echo "wshell =$(SHELL)"
   @echo "ushell =$(call DOS2UNIX,$(SHELL))"
   @echo "foo    =$(foo)"
   @echo "PATH   =$(PATH)"
ifeq (,$(TEST2))
   PATH=/usr/local/bin:/bin $(BAR)

When the above is executed without any switches, I get:
$ make
bash   =
wshell =C:/cygwin/bin/bash.exe
ushell =/usr/bin/bash.exe
foo    =foobar
PATH =\depot\hub\win32\apps\make\latest\bin;C:\cygwin\usr\local\bin;C:\cygwin\bin;C:\cygwin\bin;C:\cygwin\usr\X11R6\bin;c:\WINNT;c:\WINNT\system32;.;.
process_begin: CreateProcess((null), /sandbox/scurrier/workspaces/bar, ...) failed.
make (e=3): The system cannot find the path specified.
\\depot\hub\win32\apps\make\latest\bin\make.exe: *** [all] Error 3

Note that the PATH has been 'set' to C: syntax. If the above makefile is invoked
with TEST2=1 (which adds a PATH setting to the shell command):
$ make -f foo TEST2=1
bash   =
wshell =C:/cygwin/bin/bash.exe
ushell =/usr/bin/bash.exe
foo    =foobar
PATH =\depot\hub\win32\apps\make\latest\bin;C:\cygwin\usr\local\bin;C:\cygwin\bin;C:\cygwin\bin;C:\cygwin\usr\X11R6\bin;c:\WINNT;c:\WINNT\system32;.;.
PATH=/usr/local/bin:/bin /sandbox/scurrier/workspaces/bar

The shell command runs fine. The contents of (both) bar files is a simple perl script:
$ cat bar

print "foobar";

The perl script is there to test the PATH EV under cygwin. It also happens to be the distilled failure case of a build problem. Note that there is no ActiveState
perl installed and that bar contains no filename suffix.

The interesting part occurs if TEST1=1 is set on the command line:
$ make -f foo TEST1=1
bash   =
wshell =C:/cygwin/bin/bash.exe
ushell =/usr/bin/bash.exe
foo    =foobar
PATH =\depot\hub\win32\apps\make\latest\bin;C:\cygwin\usr\local\bin;C:\cygwin\bin;C:\cygwin\bin;C:\cygwin\usr\X11R6\bin;c:\WINNT;c:\WINNT\system32;.;.

This also works! Both bar files are the same. However, when TEST1 is nil, the bar is coming from a cygwin mount which is not represented by a drive letter mapping:
$ mount
C:\cygwin\usr\X11R6\lib\X11\fonts on /usr/X11R6/lib/X11/fonts type system (binmode)
\\sandbox\scurrier on /sandbox/scurrier type system (binmode,exec)
\\home\scurrier on /home/scurrier type system (binmode)
C:\cygwin\bin on /usr/bin type system (binmode)
C:\cygwin\lib on /usr/lib type system (binmode)
\\depot\hub on /hub type system (binmode)
C:\cygwin on / type system (binmode)
c: on /cc type system (binmode)
d: on /dd type system (binmode)
s: on /ss type system (binmode)
h: on /cygdrive/h type user (binmode,noumount)
p: on /cygdrive/p type user (binmode,noumount)
x: on /cygdrive/x type user (binmode,noumount)
y: on /cygdrive/y type user (binmode,noumount)

That is, the /sandbox/scurrier mount point is based on a UNC drive path and not a drive letter, while the CWD is on the C drive (within the cygwin root directory). Things seem to work for the latter but does not seem to work on the former.

Can anyone help explain?

One of the reasons we want to use cygwin's bash on windows is so that we do not have to mount all those windows driver letters to get to all the shares that we need to get to when building. With cygwin, we just unix 'mount' and bash can handle it.
Or so we hope.


Make-w32 mailing list


reply via email to

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