[Top][All Lists]

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

Re: strange interaction between gmake and cygwin

From: sandy currier
Subject: Re: strange interaction between gmake and cygwin
Date: Wed, 05 May 2004 05:49:02 -0400
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)

I tried that idea first but failed.  The cygwin source modifications had 12 file
conflicts with the 3.81beta1 sources.  I tried picking the best base version
I could for the 3-way merge - I picked the FSF CVS tree on Oct 5, 2002.
(It looks like the cygwin folks took that version.)  One conflict in
particular was a tad nasty in that it involves a cpp ifdef-else-endif tree
where the logic was re-arranged by both cygwin and FSF in different ways.

If this path fails, I will try that again with a different SCM tool to
see if I can get a better merge - and spend more time with it.  I asked
the cygwin folks for help (see their mail list), but they were not
interested in looking at a beta version of gmake.

To make matters more suspect, I tried building the native cygwin sources
unmodified, and found 3 somewhat concerning gmake test failures.  I asked
about the failures and whether or not they were real, but received no
response on that one.


Earnie Boyd wrote:
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]