Follow-up Comment #5, bug #53879 (project make):
Indeed, the DJGPP library provides tempnam() and tmpnam() for generation of a
random file name. An implementation of function create_batch_file() that uses
aforementioned functions would be simpler.
The advantage of the pseudo-random file name generator is that the source code
is independent on the presence of such library functions. Other compilers rely
on
libraries that lack optimized functions for file name generation.
Here is a more detailed explanation why the code is removed from file
variable.c.
Let consider a makefile taken from the test suite:
.RECIPEPREFIX = >
.ONESHELL:
SHELL = perl
.SHELLFLAGS = -e
all:
> @$$a=5
> +7;
> @y=qw(a b c);
>print "a = $$a, y = (@y)\n";
If the shell is specified without extension then function
find_and_set_default_shell() called from variable.c would not set the shell
variable to perl because
it can't find the executable in the path environment. Then sh.exe is used
which can't interpret the script.
If the shell is specified with extension as `SHELL = perl.exe' then the perl
executable is found in the path.
My understanding is to not have separate code for Windows from the code for
Unix. So removing the code from file variable.c logically solves the issue as
the shell
variable is initialized to `perl'. This is enough information for the process
creation function at a later stage to find the perl executable.
Now, we are able to suggest that appending an extension when such is not given
to the required shell in function find_and_set_default_shell() while
preserving
the Windows specific code in variable.c would resolve the issue as well.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?53879>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
