[bug #16362] Regression: make -n causes $(shell) failure on Windows
Update of bug #16362 (project make): Status:None = Fixed Assigned to:None = eliz Open/Closed:Open = Closed Fixed Release:None = CVS ___ Follow-up Comment #5: Sorry, my bad. The patch is committed to CVS now. ___ Reply to this item at: http://savannah.gnu.org/bugs/?16362 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #16362] Regression: make -n causes $(shell) failure on Windows
Follow-up Comment #4, bug #16362 (project make): (Submitted by J David Bryan jdbr...@acm.org) The patch in comment #3, which solves the originally reported problem, did not make it into version 3.82. Regrettably, I did not check for this in the RC. Could this patch please be included in the next release? ___ Reply to this item at: http://savannah.gnu.org/bugs/?16362 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #16362] Regression: make -n causes $(shell) failure on Windows
Follow-up Comment #3, bug #16362 (project make):
The following patch fixes this bug:
--- function.c~02006-04-01 12:36:40.0 +0300
+++ function.c 2006-05-27 15:58:26.984375000 +0300
@@ -1589,12 +1589,25 @@ func_shell (char *o, char **argv, const
int pid;
#ifndef __MSDOS__
+#ifdef WINDOWS32
+ /* Reset just_print_flag. This is needed on Windows when batch files
+ are used to run the commands, because we normally refrain from
+ creating batch files under -n. */
+ int j_p_f = just_print_flag;
+
+ just_print_flag = 0;
+#endif
/* Construct the argument list. */
command_argv = construct_command_argv (argv[0],
(char **) NULL, (struct file *) 0,
batch_filename);
if (command_argv == 0)
-return o;
+{
+#ifdef WINDOWS32
+ just_print_flag = j_p_f;
+#endif
+ return o;
+}
#endif
/* Using a target environment for `shell' loses in cases like:
@@ -1622,12 +1635,14 @@ func_shell (char *o, char **argv, const
#ifdef WINDOWS32
windows32_openpipe (pipedes, pid, command_argv, envp);
+ /* Restore the value of just_print_flag. */
+ just_print_flag = j_p_f;
if (pipedes[0] 0) {
/* open of the pipe failed, mark as failed execution */
shell_function_completed = -1;
- return o;
+return o;
} else
#elif defined(__MSDOS__)
___
Reply to this item at:
http://savannah.gnu.org/bugs/?func=detailitemitem_id=16362
___
Message sent via/by Savannah
http://savannah.gnu.org/
___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
[bug #16362] Regression: make -n causes $(shell) failure on Windows
Follow-up Comment #1, bug #16362 (project make): Sounds like I should stop trying to maintain the Windows port, as I cause more trouble than help. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16362 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #16362] Regression: make -n causes $(shell) failure on Windows
Follow-up Comment #2, bug #16362 (project make): Submitted by J David Bryan [EMAIL PROTECTED] Eli wrote, Sounds like I should stop trying to maintain the Windows port, as I cause more trouble than help. Seems a bit of a harsh judgment. In my view, the Windows port is in the best shape ever. To address the current problem, I see three alternative fixes: 1. Revert the patch so that batch files are always created, even with -n, and then add code to delete the files explicitly for the -n case around line 1125 of job.c. 2. Add an extra calling parameter to construct_command_argv to indicate whether the command will eventually be executed and so whether the batch file should be created (flag would be always true for the invocation via the shell function and conditional on -n otherwise). 3. Infer the type of call (shell function invocation vs. rule command invocation) from the values of the parameters and condition batch file creation on that and -n. I'm not crazy about (3), and I'm not sure which of the other two, if either, you'd find preferable. Also, I believe I've seen mention that job.c is undergoing renovations currently, so I'm loathe to select a repair method without advice. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16362 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #16362] Regression: make -n causes $(shell) failure on Windows
URL: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16362 Summary: Regression: make -n causes $(shell) failure on Windows Project: make Submitted by: None Submitted on: Monday 04/17/06 at 22:30 UTC Severity: 3 - Normal Item Group: Bug Status: None Privacy: Public Assigned to: None Open/Closed: Open Component Version: 3.81 Operating System: MS Windows Fixed Release: None ___ Details: Submitted by J David Bryan [EMAIL PROTECTED] With this makefile: files := $(shell dir /b *.c) all: @echo $(files) ...and presuming that touch a.c b.c is done initially, then running make-3.81 under Windows XP SP2 with the -n option fails as follows: F:\make --version GNU Make 3.81 [...] This program built for Windows32 F:\make a.c b.c F:\make -n process_begin: CreateProcess(NULL, , ...) failed. echo Running the same commands with the same makefile under Unix succeeds: $ make --version GNU Make 3.81 [...] This program built for sparc-sun-solaris2.9 $ make a.c b.c $ make -n echo a.c b.c This is a regression from 3.81 rc1 to rc2: F:\make-rc1 --version GNU Make 3.81rc1 [...] This program built for Windows32 F:\make-rc1 a.c b.c F:\make-rc1 -n echo a.c b.c F:\make-rc2 --version GNU Make 3.81rc2 [...] This program built for Windows32 F:\make-rc2 a.c b.c F:\make-rc2 -n process_begin: CreateProcess(NULL, , ...) failed. echo I believe that the problem is with this change: 2006-02-18 Eli Zaretskii [EMAIL PROTECTED] * job.c (construct_command_argv_internal): Don't create a temporary script/batch file if we are under -n. That corrected a problem with -n invocations leaving batch files behind (they were created in construct_command_argv_internal, but because they weren't executed, they weren't subsequently deleted). However, the change causes batch file creation to be omitted under all circumstances if -n is specified. What is wanted instead is omission for commands in rules but not for $(shell) function invocations. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16362 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
