command line limit in mingw-make

[Joe Burmeister]

Hi,

I'm building QT5 with MinGW and I've hit the Windows command line limit.

To start off I think I should say I'm don't think changing the build
system to require the handing around of less flags is the best option.
The command line limit can be 64k not 8k if things are done in the right
way.
Yes a @file option file could be used, but that would be hard to do with
the qmake files so it's only done for MinGW and I'm trying to avoid
touching other platforms. The QT guys I've spoke to don't think changing
qmake to do this automatically for MinGW is the right solution. MinGW
could just be like the other platforms up to 64k characters.

The first time I hit it was with windres.exe.

windres.exe calls gcc with _popen. Normally all is well, but not in this
case.
POSIX popen is specified to call the shell of the platform.

The shell of the Windows (NT) platform is cmd.exe, which will return
"command line is too long" if given more then 8k characters.

I solved this with a custom implementation of popen using CreateProcess
with it's limit of 64k characters.

Next time I hit it was an odd one that took me a while to find. The
8192nd character of the argument characters was being deleted when g++
was being called by mingw-make.
That character was the D part of the a command line define. So
"-Dsomething" became "-something" and g++ was erroring out about an
invalid option.

The call to g++ was from a temporary batch file that mingw-make had made.
So I made a custom mingw-make that padded around the 8192nd character,
and things built.

But this made me uncomfortable. Everything said the limit should be 8191
characters. So I dug deeper. There is no limit. You can keep adding
characters until when you call the app it doesn't run, causing the error
"The system cannot execute the specified program". For console apps that
was 32733 arg characters, for gui apps it's 32757, which makes sense as
they are different sub-systems in Windows. Every 8k boundary a character
was dropped.

So I don't think padding is the right solution because you don't know
what memory you are overflowing into.

I think better is to change mingw-make so that it doesn't create a
temporary batch file but uses CreateProcess to get access to the 64k
limit. If it's longer, error out.

I'm not written this patch yet because I figured I should talk with you
guys first.

Even if you disagree with me about the solution or that there needs to
be a solution, I don't think anyone would argue that spitting out what
should be illegal batch files is the right thing.

What are people thoughts?
Other than, "what happens if you write the right bytes after the crash
character limit" and "cmd.exe should error before then".



Thanks for any feedback,


Joe




_______________________________________________
Make-w32 mailing list
Make-w32@...
https://lists.gnu.org/mailman/listinfo/make-w32

[Eli Zaretskii]

> Date: Fri, 25 May 2012 14:19:59 +0100
> From: Joe Burmeister <joe.burmeister@...>
>
> Next time I hit it was an odd one that took me a while to find. The
> 8192nd character of the argument characters was being deleted when g++
> was being called by mingw-make.
> That character was the D part of the a command line define. So
> "-Dsomething" became "-something" and g++ was erroring out about an
> invalid option.
>
> The call to g++ was from a temporary batch file that mingw-make had made.
> So I made a custom mingw-make that padded around the 8192nd character,
> and things built.
>
> But this made me uncomfortable. Everything said the limit should be 8191
> characters. So I dug deeper. There is no limit. You can keep adding
> characters until when you call the app it doesn't run, causing the error
> "The system cannot execute the specified program". For console apps that
> was 32733 arg characters, for gui apps it's 32757, which makes sense as
> they are different sub-systems in Windows. Every 8k boundary a character
> was dropped.

That sounds like some bug somewhere.  Can you take a peek at the
temporary batch file while it runs, and see if the command line is
written correctly there?  I'd like to make sure Make isn't where that
bug is.

> I think better is to change mingw-make so that it doesn't create a
> temporary batch file but uses CreateProcess to get access to the 64k
> limit.

Make already does that, but only if the command line does not include
characters special for the shell, like redirection, pipes, etc.  Can
you show the command line, so that we could understand which part(s)
thereof triggered the use of a batch file?

_______________________________________________
Make-w32 mailing list
Make-w32@...
https://lists.gnu.org/mailman/listinfo/make-w32

[Joe Burmeister]

On 25/05/12 15:08, Eli Zaretskii wrote:

>> Date: Fri, 25 May 2012 14:19:59 +0100
>> From: Joe Burmeister<joe.burmeister@...>
>>
>> Next time I hit it was an odd one that took me a while to find. The
>> 8192nd character of the argument characters was being deleted when g++
>> was being called by mingw-make.
>> That character was the D part of the a command line define. So
>> "-Dsomething" became "-something" and g++ was erroring out about an
>> invalid option.
>>
>> The call to g++ was from a temporary batch file that mingw-make had made.
>> So I made a custom mingw-make that padded around the 8192nd character,
>> and things built.
>>
>> But this made me uncomfortable. Everything said the limit should be 8191
>> characters. So I dug deeper. There is no limit. You can keep adding
>> characters until when you call the app it doesn't run, causing the error
>> "The system cannot execute the specified program". For console apps that
>> was 32733 arg characters, for gui apps it's 32757, which makes sense as
>> they are different sub-systems in Windows. Every 8k boundary a character
>> was dropped.
> That sounds like some bug somewhere.  Can you take a peek at the
> temporary batch file while it runs, and see if the command line is
> written correctly there?  I'd like to make sure Make isn't where that
> bug is.

Looks like I didn't put one aside.
I'll get one, but it requires me to rebuild qt5, again, which isn't a
small thing to build.

But the line looks correct, other than being crazy long. Attached is a
zip with the problem demo'ed outside of make.


>
>> I think better is to change mingw-make so that it doesn't create a
>> temporary batch file but uses CreateProcess to get access to the 64k
>> limit.
> Make already does that, but only if the command line does not include
> characters special for the shell, like redirection, pipes, etc.  Can
> you show the command line, so that we could understand which part(s)
> thereof triggered the use of a batch file?
I've just grabbed a short one as qt5 builds. It's just:

"
@echo off
g++ -c -include tmp\obj\debug_shared\qt_pch.h -fno-keep-inline-dllexport
-g -Wall -frtti -fexceptions -mthreads -DQT_SHARED -DUNICODE
-DQT_LARGEFILE_SUPPORT -DQT_BUILD_NETWORK_LIB -DQT_NO_USING_NAMESPACE
-DQT_MAKEDLL -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS
-DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -D_USE_MATH_DEFINES -DQT_DLL
-DQT_CORE_LIB -DQT_HAVE_MMX -DQT_HAVE_3DNOW -DQT_HAVE_SSE
-DQT_HAVE_MMXEXT -DQT_HAVE_SSE2 -I"..\..\include\QtCore\5.0.0"
-I"..\..\include\QtCore\5.0.0\QtCore" -I"..\..\include\QtCore"
-I"..\..\include" -I"..\..\include\QtNetwork\5.0.0"
-I"..\..\include\QtNetwork\5.0.0\QtNetwork" -I"..\..\include\QtNetwork"
-I"..\..\include" -I"tmp\rcc\debug_shared" -I"tmp" -I"..\3rdparty\zlib"
-I"kernel" -I"tmp\moc\debug_shared" -I"c:\MinGW\include"
-I"c:\MinGW\msys\1.0\local\include" -I"..\..\mkspecs\win32-g++" -o
tmp\obj\debug_shared\qnetworkreplyfileimpl.o
access\qnetworkreplyfileimpl.cpp
"

 From what you just told me, I don't see why this would trigger a
intermediate batch file like this.

It's the mingw32-make I got from the mingw install.

mingw32-make -v gives:

GNU Make 3.82
Built for i386-pc-mingw32
Copyright (C) 2010  Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.



Joe


_______________________________________________
Make-w32 mailing list
Make-w32@...
https://lists.gnu.org/mailman/listinfo/make-w32

[Eli Zaretskii]

> Date: Fri, 25 May 2012 15:57:10 +0100
> From: Joe Burmeister <joe.burmeister@...>
> CC: make-w32@...
>
> @echo off
> g++ -c -include tmp\obj\debug_shared\qt_pch.h -fno-keep-inline-dllexport
> -g -Wall -frtti -fexceptions -mthreads -DQT_SHARED -DUNICODE
> -DQT_LARGEFILE_SUPPORT -DQT_BUILD_NETWORK_LIB -DQT_NO_USING_NAMESPACE
> -DQT_MAKEDLL -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS
> -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -D_USE_MATH_DEFINES -DQT_DLL
> -DQT_CORE_LIB -DQT_HAVE_MMX -DQT_HAVE_3DNOW -DQT_HAVE_SSE
> -DQT_HAVE_MMXEXT -DQT_HAVE_SSE2 -I"..\..\include\QtCore\5.0.0"
> -I"..\..\include\QtCore\5.0.0\QtCore" -I"..\..\include\QtCore"
> -I"..\..\include" -I"..\..\include\QtNetwork\5.0.0"
> -I"..\..\include\QtNetwork\5.0.0\QtNetwork" -I"..\..\include\QtNetwork"
> -I"..\..\include" -I"tmp\rcc\debug_shared" -I"tmp" -I"..\3rdparty\zlib"
> -I"kernel" -I"tmp\moc\debug_shared" -I"c:\MinGW\include"
> -I"c:\MinGW\msys\1.0\local\include" -I"..\..\mkspecs\win32-g++" -o
> tmp\obj\debug_shared\qnetworkreplyfileimpl.o
> access\qnetworkreplyfileimpl.cpp
> "
>
>  From what you just told me, I don't see why this would trigger a
> intermediate batch file like this.

I'm guessing those are the quotes.

_______________________________________________
Make-w32 mailing list
Make-w32@...
https://lists.gnu.org/mailman/listinfo/make-w32

[Joe Burmeister]

On 25/05/12 16:49, Eli Zaretskii wrote:

>> Date: Fri, 25 May 2012 15:57:10 +0100
>> From: Joe Burmeister<joe.burmeister@...>
>> CC: make-w32@...
>>
>> @echo off
>> g++ -c -include tmp\obj\debug_shared\qt_pch.h -fno-keep-inline-dllexport
>> -g -Wall -frtti -fexceptions -mthreads -DQT_SHARED -DUNICODE
>> -DQT_LARGEFILE_SUPPORT -DQT_BUILD_NETWORK_LIB -DQT_NO_USING_NAMESPACE
>> -DQT_MAKEDLL -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS
>> -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -D_USE_MATH_DEFINES -DQT_DLL
>> -DQT_CORE_LIB -DQT_HAVE_MMX -DQT_HAVE_3DNOW -DQT_HAVE_SSE
>> -DQT_HAVE_MMXEXT -DQT_HAVE_SSE2 -I"..\..\include\QtCore\5.0.0"
>> -I"..\..\include\QtCore\5.0.0\QtCore" -I"..\..\include\QtCore"
>> -I"..\..\include" -I"..\..\include\QtNetwork\5.0.0"
>> -I"..\..\include\QtNetwork\5.0.0\QtNetwork" -I"..\..\include\QtNetwork"
>> -I"..\..\include" -I"tmp\rcc\debug_shared" -I"tmp" -I"..\3rdparty\zlib"
>> -I"kernel" -I"tmp\moc\debug_shared" -I"c:\MinGW\include"
>> -I"c:\MinGW\msys\1.0\local\include" -I"..\..\mkspecs\win32-g++" -o
>> tmp\obj\debug_shared\qnetworkreplyfileimpl.o
>> access\qnetworkreplyfileimpl.cpp
>> "
>>
>>   From what you just told me, I don't see why this would trigger a
>> intermediate batch file like this.
> I'm guessing those are the quotes.

that will be why it's pretty much everything. No doubt they are added
for spaces safety.

A quick test with CreateProcess seams to show it's not necessary for
this to trigger an intermediate batch file.

Joe

_______________________________________________
Make-w32 mailing list
Make-w32@...
https://lists.gnu.org/mailman/listinfo/make-w32

[Eli Zaretskii]

> Date: Fri, 25 May 2012 17:04:12 +0100
> From: Joe Burmeister <joe.burmeister@...>
> CC: make-w32@...
>
> >>   From what you just told me, I don't see why this would trigger a
> >> intermediate batch file like this.
> > I'm guessing those are the quotes.
> that will be why it's pretty much everything. No doubt they are added
> for spaces safety.
>
> A quick test with CreateProcess seams to show it's not necessary for
> this to trigger an intermediate batch file.

Probably.  Can you try building make.exe with MinGW, after removing
the " character from sh_chars_dos[] defined on job.c under WINDOWS32?

(Building a MinGW Make requires to run the build_w32.bat batch file;
see the file README.W32 for instructions.)

_______________________________________________
Make-w32 mailing list
Make-w32@...
https://lists.gnu.org/mailman/listinfo/make-w32

On 26/05/2012 4:05 AM, Eli Zaretskii wrote:

>> Date: Fri, 25 May 2012 17:04:12 +0100
>> From: Joe Burmeister<joe.burmeister@...>
>> CC: make-w32@...
>>
>>>>     From what you just told me, I don't see why this would trigger a
>>>> intermediate batch file like this.
>>> I'm guessing those are the quotes.
>> that will be why it's pretty much everything. No doubt they are added
>> for spaces safety.
>>
>> A quick test with CreateProcess seams to show it's not necessary for
>> this to trigger an intermediate batch file.
>
> Probably.  Can you try building make.exe with MinGW, after removing
> the " character from sh_chars_dos[] defined on job.c under WINDOWS32?
>
> (Building a MinGW Make requires to run the build_w32.bat batch file;
> see the file README.W32 for instructions.)

I have removed the " character from sh_chars_dos and it works.
I can now build qt5 qtwebkit which has really long command lines (around
12000 characters long). Also, quoted filenames that have spaces still
work fine in Makefiles.

Could this be change applied to CVS?

Regards,
Jonathan


_______________________________________________
Make-w32 mailing list
Make-w32@...
https://lists.gnu.org/mailman/listinfo/make-w32

On 26/05/2012 4:05 AM, Eli Zaretskii wrote:

>> Date: Fri, 25 May 2012 17:04:12 +0100
>> From: Joe Burmeister<joe.burmeister@...>
>> CC: make-w32@...
>>
>>>>     From what you just told me, I don't see why this would trigger a
>>>> intermediate batch file like this.
>>> I'm guessing those are the quotes.
>> that will be why it's pretty much everything. No doubt they are added
>> for spaces safety.
>>
>> A quick test with CreateProcess seams to show it's not necessary for
>> this to trigger an intermediate batch file.
>
> Probably.  Can you try building make.exe with MinGW, after removing
> the " character from sh_chars_dos[] defined on job.c under WINDOWS32?
>
> (Building a MinGW Make requires to run the build_w32.bat batch file;
> see the file README.W32 for instructions.)

I have removed the " character from sh_chars_dos and it works.
I can now build qt5 qtwebkit which has really long command lines (around
12000 characters long). Also, quoted filenames that have spaces still
work fine in Makefiles.

Could this be change applied to CVS?

Regards,
Jonathan

_______________________________________________
Make-w32 mailing list
Make-w32@...
https://lists.gnu.org/mailman/listinfo/make-w32

[Eli Zaretskii]

> Date: Sun, 02 Sep 2012 21:26:14 +1000
> From: Jonathan Liu <net147@...>
> CC: Joe Burmeister <joe.burmeister@...>, make-w32@...
>
> >> A quick test with CreateProcess seams to show it's not necessary for
> >> this to trigger an intermediate batch file.
> >
> > Probably.  Can you try building make.exe with MinGW, after removing
> > the " character from sh_chars_dos[] defined on job.c under WINDOWS32?
> >
> > (Building a MinGW Make requires to run the build_w32.bat batch file;
> > see the file README.W32 for instructions.)
>
> I have removed the " character from sh_chars_dos and it works.
> I can now build qt5 qtwebkit which has really long command lines (around
> 12000 characters long). Also, quoted filenames that have spaces still
> work fine in Makefiles.
>
> Could this be change applied to CVS?

I'll add this to my TODO.  Thanks for testing.

_______________________________________________
Make-w32 mailing list
Make-w32@...
https://lists.gnu.org/mailman/listinfo/make-w32

On 3/09/2012 3:20 AM, Eli Zaretskii wrote:

>> Date: Sun, 02 Sep 2012 21:26:14 +1000
>> From: Jonathan Liu<net147@...>
>> CC: Joe Burmeister<joe.burmeister@...>, make-w32@...
>>
>>>> A quick test with CreateProcess seams to show it's not necessary for
>>>> this to trigger an intermediate batch file.
>>> Probably.  Can you try building make.exe with MinGW, after removing
>>> the " character from sh_chars_dos[] defined on job.c under WINDOWS32?
>>>
>>> (Building a MinGW Make requires to run the build_w32.bat batch file;
>>> see the file README.W32 for instructions.)
>> I have removed the " character from sh_chars_dos and it works.
>> I can now build qt5 qtwebkit which has really long command lines (around
>> 12000 characters long). Also, quoted filenames that have spaces still
>> work fine in Makefiles.
>>
>> Could this be change applied to CVS?
> I'll add this to my TODO.  Thanks for testing.

Patch attached for reference.

--- make-3.82.orig/job.c
+++ make-3.82/job.c
@@ -2367,7 +2367,7 @@
      "unset", "unsetenv", "version",
      0 };
 #elif defined (WINDOWS32)
-  static char sh_chars_dos[] = "\"|&<>";
+  static char sh_chars_dos[] = "|&<>";
   static char *sh_cmds_dos[] = { "assoc", "break", "call", "cd", "chcp",
  "chdir", "cls", "color", "copy", "ctty",
  "date", "del", "dir", "echo", "echo.",

_______________________________________________
Make-w32 mailing list
Make-w32@...
https://lists.gnu.org/mailman/listinfo/make-w32

[Joe Burmeister]

On 02/09/12 12:26, Jonathan Liu wrote:

> On 26/05/2012 4:05 AM, Eli Zaretskii wrote:
>>> Date: Fri, 25 May 2012 17:04:12 +0100
>>> From: Joe Burmeister<joe.burmeister@...>
>>> CC: make-w32@...
>>>
>>>>>     From what you just told me, I don't see why this would trigger a
>>>>> intermediate batch file like this.
>>>> I'm guessing those are the quotes.
>>> that will be why it's pretty much everything. No doubt they are added
>>> for spaces safety.
>>>
>>> A quick test with CreateProcess seams to show it's not necessary for
>>> this to trigger an intermediate batch file.
>>
>> Probably.  Can you try building make.exe with MinGW, after removing
>> the " character from sh_chars_dos[] defined on job.c under WINDOWS32?
>>
>> (Building a MinGW Make requires to run the build_w32.bat batch file;
>> see the file README.W32 for instructions.)
>
> I have removed the " character from sh_chars_dos and it works.
> I can now build qt5 qtwebkit which has really long command lines (around
> 12000 characters long). Also, quoted filenames that have spaces still
> work fine in Makefiles.
>
> Could this be change applied to CVS?
>
> Regards,
> Jonathan

The other got ya with qt5 is windres.exe.
It uses MS's popen, which calls cmd.exe and thus introduces a 8k limit.
This would mean qtdeclarative wouldn't build for me.
My solution was to change windres.exe to use a custom popen on Windows,
one that calls CreateProcess with the command line directly, accessing
the higher 32k limit.

Anyway, really pleased there is progress on this. :-)


Joe

_______________________________________________
Make-w32 mailing list
Make-w32@...
https://lists.gnu.org/mailman/listinfo/make-w32

On 3/09/2012 3:20 AM, Eli Zaretskii wrote:

>> Date: Sun, 02 Sep 2012 21:26:14 +1000
>> From: Jonathan Liu<net147@...>
>> CC: Joe Burmeister<joe.burmeister@...>, make-w32@...
>>
>>>> A quick test with CreateProcess seams to show it's not necessary for
>>>> this to trigger an intermediate batch file.
>>>
>>> Probably.  Can you try building make.exe with MinGW, after removing
>>> the " character from sh_chars_dos[] defined on job.c under WINDOWS32?
>>>
>>> (Building a MinGW Make requires to run the build_w32.bat batch file;
>>> see the file README.W32 for instructions.)
>>
>> I have removed the " character from sh_chars_dos and it works.
>> I can now build qt5 qtwebkit which has really long command lines (around
>> 12000 characters long). Also, quoted filenames that have spaces still
>> work fine in Makefiles.
>>
>> Could this be change applied to CVS?
>
> I'll add this to my TODO.  Thanks for testing.

Any update on this?

Regards,
Jonathan

_______________________________________________
Make-w32 mailing list
Make-w32@...
https://lists.gnu.org/mailman/listinfo/make-w32

[Eli Zaretskii]

> Date: Wed, 03 Oct 2012 19:04:38 +1000
> From: Jonathan Liu <net147@...>
> CC: make-w32@...
>
> On 3/09/2012 3:20 AM, Eli Zaretskii wrote:
> >> Date: Sun, 02 Sep 2012 21:26:14 +1000
> >> From: Jonathan Liu<net147@...>
> >> CC: Joe Burmeister<joe.burmeister@...>, make-w32@...
> >>
> >>>> A quick test with CreateProcess seams to show it's not necessary for
> >>>> this to trigger an intermediate batch file.
> >>>
> >>> Probably.  Can you try building make.exe with MinGW, after removing
> >>> the " character from sh_chars_dos[] defined on job.c under WINDOWS32?
> >>>
> >>> (Building a MinGW Make requires to run the build_w32.bat batch file;
> >>> see the file README.W32 for instructions.)
> >>
> >> I have removed the " character from sh_chars_dos and it works.
> >> I can now build qt5 qtwebkit which has really long command lines (around
> >> 12000 characters long). Also, quoted filenames that have spaces still
> >> work fine in Makefiles.
> >>
> >> Could this be change applied to CVS?
> >
> > I'll add this to my TODO.  Thanks for testing.
>
> Any update on this?

Not yet, sorry.  Life intervened.

_______________________________________________
Make-w32 mailing list
Make-w32@...
https://lists.gnu.org/mailman/listinfo/make-w32

[Eli Zaretskii]

> Date: Tue, 18 Sep 2012 09:28:13 +0100
> From: Joe Burmeister <joe.burmeister@...>
> CC: Eli Zaretskii <eliz@...>, make-w32@...
>
> > I have removed the " character from sh_chars_dos and it works.
> > I can now build qt5 qtwebkit which has really long command lines (around
> > 12000 characters long). Also, quoted filenames that have spaces still
> > work fine in Makefiles.
> >
> > Could this be change applied to CVS?
> >
> > Regards,
> > Jonathan
>
> The other got ya with qt5 is windres.exe.
> It uses MS's popen, which calls cmd.exe and thus introduces a 8k limit.
> This would mean qtdeclarative wouldn't build for me.
> My solution was to change windres.exe to use a custom popen on Windows,
> one that calls CreateProcess with the command line directly, accessing
> the higher 32k limit.
>
> Anyway, really pleased there is progress on this. :-)

Progress report: I've made the change in my private copy of Make.  If
I see no problems with this in a couple of weeks, I will commit the
change to CVS.

_______________________________________________
Make-w32 mailing list
Make-w32@...
https://lists.gnu.org/mailman/listinfo/make-w32

[Eli Zaretskii]

> Date: Sat, 13 Oct 2012 11:27:07 +0200
> From: Eli Zaretskii <eliz@...>
> Cc: make-w32@...
>
> > Anyway, really pleased there is progress on this. :-)
>
> Progress report: I've made the change in my private copy of Make.  If
> I see no problems with this in a couple of weeks, I will commit the
> change to CVS.

Sigh... nothing is ever as simple as it looks.  I needed the
additional patch below to get Make to work correctly when " is removed
from sh_chars_dos.  Without this, it would work incorrectly when the
command line used escaped quotes inside quotes, like in "foo=\"bar\"".

Please try using this change in your future tests.

--- job.c~ 2012-01-16 15:46:46.000000000 +0200
+++ job.c 2012-10-13 13:56:37.708375000 +0200
@@ -2660,6 +2667,10 @@ construct_command_argv_internal (char *l
      quotes have the same effect.  */
   else if (instring == '"' && strchr ("\\$`", *p) != 0 && unixy_shell)
     goto slow;
+#ifdef WINDOWS32
+  else if (instring == '"' && strncmp (p, "\\\"", 2) == 0)
+    *ap++ = *++p;
+#endif
   else
     *ap++ = *p;
  }

_______________________________________________
Make-w32 mailing list
Make-w32@...
https://lists.gnu.org/mailman/listinfo/make-w32

On 13/10/2012 11:19 PM, Eli Zaretskii wrote:

> Sigh... nothing is ever as simple as it looks.  I needed the
> additional patch below to get Make to work correctly when " is removed
> from sh_chars_dos.  Without this, it would work incorrectly when the
> command line used escaped quotes inside quotes, like in "foo=\"bar\"".
>
> Please try using this change in your future tests.
>
> --- job.c~ 2012-01-16 15:46:46.000000000 +0200
> +++ job.c 2012-10-13 13:56:37.708375000 +0200
> @@ -2660,6 +2667,10 @@ construct_command_argv_internal (char *l
>       quotes have the same effect.  */
>    else if (instring == '"'&&  strchr ("\\$`", *p) != 0&&  unixy_shell)
>      goto slow;
> +#ifdef WINDOWS32
> +  else if (instring == '"'&&  strncmp (p, "\\\"", 2) == 0)
> +    *ap++ = *++p;
> +#endif
>    else
>      *ap++ = *p;
>   }

I have applied the change to my local copy. Seems to be working okay.
I don't think the Makefiles that I use have \" inside quotes though.

Regards,
Jonathan

_______________________________________________
Make-w32 mailing list
Make-w32@...
https://lists.gnu.org/mailman/listinfo/make-w32

[Eli Zaretskii]

> Date: Fri, 19 Oct 2012 19:34:01 +1100
> From: Jonathan Liu <net147@...>
> CC: joe.burmeister@..., make-w32@...
>
> On 13/10/2012 11:19 PM, Eli Zaretskii wrote:
> > Sigh... nothing is ever as simple as it looks.  I needed the
> > additional patch below to get Make to work correctly when " is removed
> > from sh_chars_dos.  Without this, it would work incorrectly when the
> > command line used escaped quotes inside quotes, like in "foo=\"bar\"".
> >
> > Please try using this change in your future tests.
> >
> > --- job.c~ 2012-01-16 15:46:46.000000000 +0200
> > +++ job.c 2012-10-13 13:56:37.708375000 +0200
> > @@ -2660,6 +2667,10 @@ construct_command_argv_internal (char *l
> >       quotes have the same effect.  */
> >    else if (instring == '"'&&  strchr ("\\$`", *p) != 0&&  unixy_shell)
> >      goto slow;
> > +#ifdef WINDOWS32
> > +  else if (instring == '"'&&  strncmp (p, "\\\"", 2) == 0)
> > +    *ap++ = *++p;
> > +#endif
> >    else
> >      *ap++ = *p;
> >   }
> I have applied the change to my local copy. Seems to be working okay.

Thanks.  Please report any findings.

> I don't think the Makefiles that I use have \" inside quotes though.

That's okay, I have plenty...

_______________________________________________
Make-w32 mailing list
Make-w32@...
https://lists.gnu.org/mailman/listinfo/make-w32

On 19/10/2012 8:51 PM, Eli Zaretskii wrote:

>> Date: Fri, 19 Oct 2012 19:34:01 +1100
>> From: Jonathan Liu<net147@...>
>> CC: joe.burmeister@..., make-w32@...
>>
>> On 13/10/2012 11:19 PM, Eli Zaretskii wrote:
>>> Sigh... nothing is ever as simple as it looks.  I needed the
>>> additional patch below to get Make to work correctly when " is removed
>>> from sh_chars_dos.  Without this, it would work incorrectly when the
>>> command line used escaped quotes inside quotes, like in "foo=\"bar\"".
>>>
>>> Please try using this change in your future tests.
>>>
>>> --- job.c~ 2012-01-16 15:46:46.000000000 +0200
>>> +++ job.c 2012-10-13 13:56:37.708375000 +0200
>>> @@ -2660,6 +2667,10 @@ construct_command_argv_internal (char *l
>>>         quotes have the same effect.  */
>>>      else if (instring == '"'&&   strchr ("\\$`", *p) != 0&&   unixy_shell)
>>>        goto slow;
>>> +#ifdef WINDOWS32
>>> +  else if (instring == '"'&&   strncmp (p, "\\\"", 2) == 0)
>>> +    *ap++ = *++p;
>>> +#endif
>>>      else
>>>        *ap++ = *p;
>>>     }
>> I have applied the change to my local copy. Seems to be working okay.
> Thanks.  Please report any findings.
>
>> I don't think the Makefiles that I use have \" inside quotes though.
> That's okay, I have plenty...

No problems yet so far. Using mingw32-make with these patches:
https://github.com/niXman/mingw-builds/tree/master/patches/make

Regards,
Jonathan

_______________________________________________
Make-w32 mailing list
Make-w32@...
https://lists.gnu.org/mailman/listinfo/make-w32

[Eli Zaretskii]

> Date: Wed, 07 Nov 2012 22:52:26 +1100
> From: Jonathan Liu <net147@...>
> CC: joe.burmeister@..., make-w32@...
>
> No problems yet so far. Using mingw32-make with these patches:
> https://github.com/niXman/mingw-builds/tree/master/patches/make

Thanks for the feedback.  I have zero problems as well, so I will
probably commit these changes to the repository soon.

_______________________________________________
Make-w32 mailing list
Make-w32@...
https://lists.gnu.org/mailman/listinfo/make-w32

On 8/11/2012 3:08 AM, Eli Zaretskii wrote:
>> Date: Wed, 07 Nov 2012 22:52:26 +1100
>> From: Jonathan Liu<net147@...>
>> CC: joe.burmeister@..., make-w32@...
>>
>> No problems yet so far. Using mingw32-make with these patches:
>> https://github.com/niXman/mingw-builds/tree/master/patches/make
>
> Thanks for the feedback.  I have zero problems as well, so I will
> probably commit these changes to the repository soon.

Doesn't seem to be committed yet.

_______________________________________________
Make-w32 mailing list
Make-w32@...
https://lists.gnu.org/mailman/listinfo/make-w32