[bug #53879] Support for .ONESHELL target on Windows and DOS platforms

[V. Aleksandrov]

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/