Re: Implicit dependency on the existence of /bin/ in make 3.79.1-7 - possible bug

[Igor Pechtchanski <pechtcha at cs dot nyu dot edu>]

Paul,

This particular Makefile will work, but if you do any sort of
shell-specific processing (e.g., using backticks, or $$var), the Makefile
will fail (with cmd.exe).

I'd suggest you download the source code for make-3.79.1-5 and
make-3.79.1-7, compare the two, and create a patch (based on the -7
source) that will work *for you*.  The make maintainer should be aware of
the other issues/implications that you've raised, and might work with you
to come up with a generic and compatible solution (I'm not trying to
second-guess him, but that's what I would do in his place).  You certainly
have nothing to lose by trying...
	Igor

On Wed, 21 May 2003, Paul Connell wrote:

> 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

-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton


--
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/