Date: Wed, 16 Sep 1998 12:32:05 +0300 (IDT) From: Eli Zaretskii To: "Peter J. Farley III" 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: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk 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.