Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
To: cygwin AT cygwin DOT com
Reply-To: paulconnell AT clara DOT co DOT uk
Subject: Re: Implicit dependency on the existence of /bin/ in make 3.79.1-7  - possible bug
Cc: 
X-Remote_Addr: 195.70.93.15
Message-Id: <E19IVbM-0000r4-00@oceanus.uk.clara.net>
From: Paul Connell <paulconnell AT clara DOT co DOT uk>
Date: Wed, 21 May 2003 16:34:00 +0100

Interestingly, in the example I gave, if you comment out the line that 
defines SHELL it works just fine too (presumably defaulting to using 
cmd.exe)

# SHELL=/gibberish/bin/sh
.PHONY: all
all:
ls

So I think you're right that perhaps the logic that sets unixy_shell 
ought to be:

1) If SHELL is defined *in the makefile*, use that value.
2) else try /bin/sh
3) else try and get it from the environment variable SHELL from outside 
the makefile
3) else try cmd.exe
4) else command.com
5) else fail

Perhaps 2) and 3) need to be swapped. I'm not sure of the implications 
being none-too-familiar with the make source code, or the history of 
modifications and bugfixes.

--
Thanks,
Paul

> On Wed, 21 May 2003, Paul Connell wrote:
> 
> > Hi.
> >
> > For historical reasons at my place of work, we maintain a subset of

> > some of the cygwin tools for our build processes (e.g. our 
makefiles
> > rely on sed, awk, grep etc). We do this so that we can keep the
> > necessary tools in source control (yeah, I know...) and folks don't

> > need to have full installs of cygwin cluttering their hard drives 
if
> > they don't want.
> >
> > The location of these executables is not /bin, and in the general 
case
> > the programmers do not have cygwin 'installed', just the subset 
from
> > out of source control.
> >
> > Because of this, I have found what may be a problem in v3.79.1-7 of

> > make, namely that it can fail in very simple test cases if it is 
not
> > executed within a proper installation of cygwin - which is 
undesirable
> > in our case.
> >
> > e.g. have a directory c:\gibberish\bin that contains make.exe ls.
exe
> > and sh.exe -and all related DLLs, which are all the latest versions 
as
> > of May 2003. Put it on your path. Temporarily rename your cygwin /
bin
> > directory - wherever it is - to /_bin
> >
> > The following makefile:
> > SHELL=/gibberish/bin/sh
> > .PHONY: all
> > all:
> > ls
> >
> > when processed - 'make -f test.mak' or whatever - will fail with an

> > error similar to:
> >
> > "cannot open /c:"
> >
> > I believe it may be due to line 33 of main.c in the make source.
> >
> > It used to say:
> >
> > /* start off assuming we are using native command shell */
> > unixy_shell = 1;
> >
> > Now it says:
> >
> > /* start off assuming we are using native command shell */
> > unixy_shell = access ("/bin/sh", X_OK) == 0;
> >
> > Note that make v3.79.1-5 works just fine in the same environment, 
with
> > the same makefile.
> >
> > The other solution I found was to ensure that c:\gibberish\bin is
> > mounted as /bin - but that felt a bit hacky, more of a workaround 
than
> > a solution.
> >
> > Basically, if make is intended to be usable outside of a proper 
install
> > of cygwin, this is a bug. If not, it's not.
> >
> > Thanks for reading.
> >
> > --
> > Cheers
> > Paul Connell
> 
> Paul,
> 
> I'd guess your problem spans from the following change:
> 
>   There is also a change which allows make to default to win32 mode 
if
>   /bin/sh is missing.  This means that make will use 'command.com' or

>   'cmd.exe' if /bin/sh is not available.
> 
> (from <http://cygwin.com/ml/cygwin-announce/2002-05/msg00010.html>).
> 
> Since this change is Cygwin-specific, and relatively recent, I'm sure 
the
> current make maintainer (Elfyn, IIRC) will consider reasonable
> alternatives (especially if they came with patches).  One quick 
solution I
> see is to check that $SHELL is set before looking for /bin/sh in make,
but
> that may have other connotations (e.g., if SHELL is sometimes set 
outside
> of Cygwin, it may screw up current Cygwin installations of make, and 
we
> don't want that).
> 	Igor

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/