bugmake - Bugs: bug #16362, Regression: make -n causes...

 
 

bug #16362: Regression: make -n causes $(shell) failure on Windows

Submitter:  None
Submitted:  Mon 17 Apr 2006 10:30:36 PM UTC
   
 
Severity:  3 - Normal Priority:  5 - Normal
Item Group:  Bug Status:  Fixed
Privacy:  Public Assigned to:  eliz
Open/Closed:  Closed Component Version:  3.81
Operating System:  MS Windows Fixed Release:  4.0
Triage Status:  None
* Mandatory Fields

Post a Comment

Add a New Comment Rich Markup
   

Discussion

Sat 07 Aug 2010 08:47:47 AM UTC, comment #5: 

Sorry, my bad.  The patch is committed to CVS now.

Eli Zaretskii <eliz>
Group Member
Tue 03 Aug 2010 04:33:16 AM UTC, comment #4: 

(Submitted by J David Bryan <jdbryan@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?

Anonymous
Sat 27 May 2006 01:09:45 PM UTC, comment #3: 

The following patch fixes this bug:

--- function.c~0 2006-04-01 12:36:40.000000000 +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_)

Eli Zaretskii <eliz>
Group Member
Tue 18 Apr 2006 03:42:37 PM UTC, comment #2: 

Submitted by J David Bryan <jdbryan@acm.org>

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.

Anonymous
Tue 18 Apr 2006 09:01:49 AM UTC, comment #1: 

Sounds like I should stop trying to maintain the Windows port, as I cause more trouble than help.

Eli Zaretskii <eliz>
Group Member
Mon 17 Apr 2006 10:30:36 PM UTC, original submission:  

Submitted by J David Bryan <jdbryan@acm.org>

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  <eliz@gnu.org>

        * 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.

Anonymous

 

Attached Files

This item currently has no attached files.

(Note: upload size limit is set to 4.0MiB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

 

Dependencies

This item does not depend on any other items.

No items depend on this one.

 

Mail Notification Carbon-Copy List

Carbon-Copy List
  • -email is unavailable- added by eliz (Posted a comment)
  •  

    Votes

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

    History

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-08-07 eliz StatusNone Fixed
        Assigned toNone eliz
        Open/ClosedOpen Closed
        Fixed ReleaseNone 4.0

    Back to the top

    Powered by Savane 3.16-a7ba.
    Corresponding source code