Date:	Wed, 16 Sep 1998 12:32:05 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To:	"Peter J. Farley III" <pjfarley AT banet DOT net>
cc:	djgpp AT delorie DOT com
Subject:	Re: Why does make fail to run path-qualified commands?
In-Reply-To:	<3.0.3.32.19980915215729.007d4240@pop5.banet.net>
Message-ID:	<Pine.SUN.3.91.980916123142.5874Y-100000@is>
MIME-Version:	1.0

On Tue, 15 Sep 1998, Peter J. Farley III wrote:

> >In any case, if you use these variables in your routine
> >work, you should watch closely to not let their consequences crawl
> >into your Makefiles, because that won't work.  That is why, for
> >example, when running configure scripts, I usually set
> >INSTALL=${DJDIR}/bin/ginstall in the environment so that the Makefile
> >won't end up with //c/djgpp/bin/install or some such.
> 
> But wouldn't this work?  Doesn't bash translate "//c/djgpp/bin/install"
> into something like "c:/djgpp/bin/install" before calling spawnvpe?

It can't do that, because it doesn't have any idea what do such
arguments really mean.  Who says that "//c/djgpp/bin" is a pathname?
It could well be something entirely different.  Bash tries to do that
when invoking external programs (and this works reasonably well), but
it cannot do that with its internal commands, and typical configure
scripts use internal shell commands to edit Makefile.in into
Makefile.

(Actually, even for external commands it is not always a good idea to
perform such correction.  Sed is one notable case: a sed script can
look very much like a pathname.  So Bash actually makes an exception
for Sed and does NOT convert its arguments.)

> Maybe the "right"
> way is to set up and/or enhance package-specific autoconf aclocal.m4 files,
> so as not to break more than is fixed.  I'll play with this idea and see
> whether it works.

The ``right way'' (IMHO) is to add support for //d/foo pathnames into
core DJGPP functionality, i.e. into libc.a.  That is the only way this
could work without subtle misfeatures.

- Raw text -