Re: Make 4.4 on Win10 behaving oddly

[Eli Zaretskii]

> Date: Mon, 24 Jul 2023 16:43:48 +1200
> From: Gary Turner 
> 
> Sorry if this isn't the right place to ask - I've been reading this list 
> for years, and it was an easy option :)
> I've been getting (copying) updated make.exe files from various 
> installations as I set up new machines over the years.
> I usually run make manually from a command prompt.
> I've been doing this for years with no changes to anything else but I'm 
> seeing some oddness with make 4.4.1 (Built for x86_64-pc-msys) that I 
> got from a ruby install.
> If I run make on my old makefiles, it looks to me  like it is starting a 
> shell instead of running the commands.
> It prints the necessary make command, and "Microsoft Windows[Version 
> 10.0...] and (c) Microsoft... and then a command prompt.
> The command window  title then shows ...\cmd - make. If I type exit, 
> (sometimes I have to Ctr-C first)  I get back to my original prompt.
> I guess something is going wrong with my shell selection, but I've never 
> had to manually set it before.
> I copied over an older 4.1 (Built for Windows32) which I don't recall 
> the source of, and that works fine.
> Is there an easy solution to this?

Please begin by showing the minimal Makefile which exhibits the above
behavior with Make 4.4.

In general, the x86_64-pc-msys target is not a build of Make you
should be running from cmd.exe, nor should you expect it to behave
like a native MS-Windows port of Make.  That build is for MSYS, and is
supposed to be run from Bash in order to execute Unix-style Makefiles.
So, for example, it doesn't know enough about cmd.exe shell rules, and
generally behaves like a Unix build of Make.  So it is better to avoid
it on MS-Windows, except when you are running Posix-style configure
script and the Makefiles it produces.

A native Windows build of Make 4.4.1 is available here:

  https://sourceforge.net/projects/ezwinports/files/

This is a 32-bit build (but will run on 64-bit Windows); if you want a
64-bit build instead, look in the MSYS2 project for a build thaat ends
with "-mingw64", not with "-msys".

Re: Prerelease GNU Make 4.4.0.90 on Windows using tcc compiler

[Eli Zaretskii]

> Date: Sun, 15 Jan 2023 16:39:39 +0200
> From: Eli Zaretskii 
> Cc: jull...@eligis.com, make-w32@gnu.org
> 
> > From: Paul Smith 
> > Cc: make-w32@gnu.org
> > Date: Sun, 15 Jan 2023 09:25:09 -0500
> > 
> > On Sun, 2023-01-15 at 08:40 +0100, Christian Jullien wrote:
> > > Trying the current snapshot I get this error. I've got this error
> > > each time I've tested a snapshot.
> > 
> > I'm afraid I don't know what you mean by a "snapshot".  The GNU Make
> > project doesn't publish "daily snapshots" like the ones published by
> > GCC etc. if that's what you mean, so I don't know where you got that
> > from but it wasn't from me.
> > 
> > The prerelease package I published and which is referenced in the
> > parent message absolutely has all the files you listed, contained in
> > it:
> > 
> > -rw-r--r-- 0/0   1444 2023-01-14 14:08 make-4.4.0.90/src/mkconfig.h
> > -rw-r--r-- 0/0   5990 2023-01-14 14:08 make-4.4.0.90/lib/glob.in.h
> > -rw-r--r-- 0/0  15528 2023-01-14 14:08 make-4.4.0.90/lib/intprops.h
> > 
> > etc.
> > 
> > Are you (and Eli) saying that this 4.4.0.90 prerelease package is
> > broken somehow?
> 
> Oops, sorry!  The tarball is okay, and builds fine.

And now I also verified that the test suite passes.

Re: Prerelease GNU Make 4.4.0.90 on Windows using tcc compiler

[Eli Zaretskii]

> From: Paul Smith 
> Cc: make-w32@gnu.org
> Date: Sun, 15 Jan 2023 09:25:09 -0500
> 
> On Sun, 2023-01-15 at 08:40 +0100, Christian Jullien wrote:
> > Trying the current snapshot I get this error. I've got this error
> > each time I've tested a snapshot.
> 
> I'm afraid I don't know what you mean by a "snapshot".  The GNU Make
> project doesn't publish "daily snapshots" like the ones published by
> GCC etc. if that's what you mean, so I don't know where you got that
> from but it wasn't from me.
> 
> The prerelease package I published and which is referenced in the
> parent message absolutely has all the files you listed, contained in
> it:
> 
> -rw-r--r-- 0/0   1444 2023-01-14 14:08 make-4.4.0.90/src/mkconfig.h
> -rw-r--r-- 0/0   5990 2023-01-14 14:08 make-4.4.0.90/lib/glob.in.h
> -rw-r--r-- 0/0  15528 2023-01-14 14:08 make-4.4.0.90/lib/intprops.h
> 
> etc.
> 
> Are you (and Eli) saying that this 4.4.0.90 prerelease package is
> broken somehow?

Oops, sorry!  The tarball is okay, and builds fine.

I'm guessing that Christian asked Savannah to produce a snapshot of
the Git repository (it has such abilities for every project), and that
gives a tarball where some files you generate when tarring a release
aren't present.

Re: Prerelease GNU Make 4.4.0.90 on Windows using tcc compiler

[Eli Zaretskii]

> From: "Christian Jullien" 
> Cc: 
> Date: Sun, 15 Jan 2023 08:40:22 +0100
> 
> Trying the current snapshot I get this error. I've got this error each time
> I've tested a snapshot.
> I never happened on an official release. Many 'port' files are missing (or
> not copied at the right location).
> mkconfig.h glob.h fnmath.h intpropos.h ...
> 
> Should I do something special with snapshot.
> 
> F:\wintcc\make-db351fe85b57fe4368a1396fb0e8ea5814825e68>build_w32.bat tcc
> 
> Creating GNU Make for Windows 9X/NT/2K/XP/Vista/7/8/10
> 
> - Building with TinyC
> - Enabling maintainer mode
> 
> tcc version 0.9.27 mob:d15dec7 2022-12-28T03:08:02+01:00 (x86_64 Windows)
> - pkg-config not found, building without Guile
> 
> Compiling .\TccRel version
> 1 file(s) copied.
> The system cannot find the path specified.
> The system cannot find the path specified.
> - Compiling src/ar.c
> In file included from src/ar.c:18:
> In file included from src/makeint.h:20:
> ./TccRel/src/config.h:18: error: include file 'mkconfig.h' not found

Right.

Paul, it looks like the tarball was not produced by the same procedure
as a release tarball.  What happened?

Re: GNUmake v4.4 port on Windows with tcc

[Eli Zaretskii]

> From: "Christian Jullien" 
> Cc: ,
>   ,
>   
> Date: Sat, 5 Nov 2022 17:03:44 +0100
> 
> Please note that even VisualC++ uses defines (in mapping.h)
> /**
>  * Map stroll to _strtoi64
>  *
>  * stroll does not properly map in Windows; this is needed to ensure calls to
>  * strtoll(const char *nptr, char **endptr, int base) will compile in Windows.
>  */
> #define strtoll _strtoi64
> 
> /**
>  * Map strtoull to _strtoui64
>  *
>  * strtoull does not properly map in Windows; this is needed to ensure calls 
> to
>  * strtoull(const char *nptr, char **endptr, int base) will compile in 
> Windows.
>  */
> #define strtoull _strtoui64
> 
> So, probably we'll do the same for tcc.

When you do, please tell, and we will fix config.h at that time.

Thanks.

Re: GNUmake v4.4 port on Windows with tcc

[Eli Zaretskii]

> From: Paul Smith 
> Cc: make-w32@gnu.org, tinycc-de...@nongnu.org
> Date: Sat, 05 Nov 2022 10:18:55 -0400
> 
> On Thu, 2022-11-03 at 16:45 +0200, Eli Zaretskii wrote:
> > > Of course it does.
> > 
> > Thanks.  Paul, should I install this?
> 
> Yes please thanks!

Done.

Re: GNUmake v4.4 port on Windows with tcc

[Eli Zaretskii]

> From: "Christian Jullien" 
> Cc: ,
>   ,
>   
> Date: Thu, 3 Nov 2022 15:59:53 +0100
> 
> Hi Eli, you've read too fast, the warnings are with cl (Visual C++ if you
> prefer), esp. when compiled with 64bit mode.

That's still for Paul, who actually has VC.  I only use GCC.

Re: GNUmake v4.4 port on Windows with tcc

[Eli Zaretskii]

> From: "Christian Jullien" 
> Cc: ,
>   
> Date: Thu, 3 Nov 2022 15:29:47 +0100
> 
> Of course it does.

Thanks.  Paul, should I install this?

> As side note, compiling GNUmake with cl x64 gives the following warnings

The "size_t to int" warnings are about EINTRLOOP, so I'll let Paul
worry about that, since there could be no loops on Windows.

The other warnings are in places where there are too many
system-dependent ifdef's for messing with them without a compiler
available for testing.  So either you suggest more ifdef's to take
care of those warnings, or Tiny C users will have to live with them.

Re: GNUmake v4.4 port on Windows with tcc

[Eli Zaretskii]

> From: Paul Smith 
> Cc: tinycc-de...@nongnu.org, 'Eli Zaretskii' 
> Date: Wed, 02 Nov 2022 11:50:45 -0400
> 
> On Wed, 2022-11-02 at 16:40 +0100, Christian Jullien wrote:
> > It appears that tcc on Windows lacks strtoll and strtoull (something
> > that
> > needs to be fixed on tcc side of course).
> > Meanwhile, it can easily be patched in build_w32.bat by adding
> > -Dstrtoull=_strtoui64 -Dstrtoll=_strtoi64 at line 330
> > 
> > call %COMPILER% -mthreads -Wall -std=c11 %OPTS% -I%OUTDIR%/src -
> > I./src
> > -I%OUTDIR%/lib -I./lib -I./src/w32/include -D_cdecl= -
> > Dstrtoull=_strtoui64
> > -Dstrtoll=_strtoi64 -D_MSC_VER -DHAVE_CONFIG_H %EXTRAS% -o
> > %OUTDIR%/%1.%O%
> > -c %1.c
> > 
> > Hope it helps.
> 
> Thanks for that note.  We will choose a different way to address this I
> expect but it's good to know there's a problem.

Christian, does the below fix the problem?

--- src/config.h.W32~0  2022-10-23 17:52:32.0 +0300
+++ src/config.h.W322022-11-03 15:47:14.46850 +0200
@@ -343,6 +343,10 @@ this program.  If not, see <https://www.
 /* #undef HAVE_STRSIGNAL */
 
 /* Define to 1 if you have the `strtoll' function. */
+#ifdef __TINYC__
+#define strtoll _strtoi64
+#define strtoull _strtoui64
+#endif
 #define HAVE_STRTOLL 1
 
 /* Define to 1 if `d_type' is a member of `struct dirent'. */

Re: How to choose the shell?

[Eli Zaretskii]

> From: Paul Smith 
> Cc: jfreema...@gmail.com, make-w32@gnu.org
> Date: Sun, 05 Sep 2021 16:47:03 -0400
> 
> On Sun, 2021-09-05 at 22:29 +0300, Eli Zaretskii wrote:
> > > We don't provide -c at all: we provide the options in the
> > > .SHELLFLAGS variable.
> > 
> > But there's a default if it is not provided, right?
> 
> Sure, but if the default is wrong (just like with SHELL) the user has
> to change it.

And what is the right flag for PowerShell?  Looks like -Command?

In general, on Posix platforms users only need to care about
.SHELLFLAGS when they use a "shell" that isn't really a shell, because
all shells support the default -c.  Here we are talking about a shell
which _requires_ using .SHELLFLAGS.  I wonder how many users will know
that.

> Consider someone using SHELL := perl ; that won't work with -c either
> even on POSIX.  That's why we created .SHELLFLAGS in the first place.

That's in the "you asked for it" department.  If we are to support
PowerShell better than we support Perl and its ilk, we should do
better, IMO, similarly to what we do with cmd.exe.

> > /* SHELL may be a multi-word command.  Construct a command line
> >"$(SHELL) $(.SHELLFLAGS) LINE", with all special chars in LINE 
> > escaped.
> >Then recurse, expanding this command line to get the final
> >argument list.  */
> 
> I've always felt that this code was FAR too complicated and never
> understood why it needed to be that way.  I suppose there was a desire
> to allow the SHELL variable to contain multiple words, quoting, etc.
> and have that DTRT but I think it's ultimately futile to try to support
> this.
> 
> I'll need to look at the details about how it works today but I think
> that regardless of that it SHOULD work essentially as I laid out:

It's not just that: once we are through with escaping special
characters, we call construct_command_argv_internal recursively, which
again attempts to avoid calling the shell to execute $SHELL, so it
again goes through all the rigmarole of parsing the command with its
quotes and escapes.

> > Before it works, we need to make sure argv[] won't fail the 'exec'
> > call due to these minor details.
> 
> Yes, it's frustrating the way Win32 requires explicit quoting of
> arguments.  However, as far as I'm aware this quoting is generic and
> doesn't depend on the actual command being invoked.

It is generic, but it's "tricky", because there's no 'exec' on
Windows, really.  The low-level API that starts processes wants the
command line as a single string, so we need to quote parts of it that
include whitespace and other special characters.  You can see the
quirks in subproc.c.  I have no idea whether PowerShell will require
any changes there, it's all pure heuristics based on many years of
trial and error.  Submitting batch files for execution by cmd.exe
needs special tricks there, for example.

> > > This is why I raised the generalization of batch files as an issue:
> > > some commands may not be able to accept "" on the command
> > > line like that, and if we could provide a _generic_ way to allow
> > > makefiles to change that final argv value to something else like a
> > > reference to a batch file where  was written, it could
> > > help.
> > 
> > Sure, but each shell has its own rules how to write batch files.  We
> > can support known shells, but what to do with unknown ones?
> 
> I'm saying that to gain portability *GNU make* should write the batch
> file.

Yes, that's what I meant as well.

> The batch file would contain exactly whatever text is in the recipe.
> The question is how to provide that filename to the command we invoke.

How to provide the file name is an issue (and PowerShell is different
here as well, AFAIU: it requires use of the -File switch), but it is
not the only issue.  The batch file may need some preamble specific to
a shell.  For example, for cmd.exe we add "@echo off" there.  I have
no idea whether PowerShell needs something special, nor whether the
nominal .ps1 extension has to be used for the batch file-name
extension.  These are all issues that need to be figured out before we
can declare that we support batch files for any shell.

Re: How to choose the shell?

[Eli Zaretskii]

> From: Paul Smith 
> Cc: jfreema...@gmail.com, make-w32@gnu.org
> Date: Sun, 05 Sep 2021 15:18:18 -0400
> 
> On Sun, 2021-09-05 at 22:08 +0300, Eli Zaretskii wrote:
> > First, how do you invoke the shell?  On Unix we do "$SHELL -c",
> > right?  What to do on Windows?  Most Windows shells don't support "-
> > c".
> > 
> > Next, what are the characters special to the shell, and how to escape
> > them?  We currently use Unix conventions for that, with some 
> > Windows fixups, but that won't necessarily work with an arbitrary
> > Windows shell.  What to use instead?
> 
> Sorry but I don't follow.  We don't invoke a shell at all: we invoke
> the command in the SHELL variable.

Yes, that's what I meant by $SHELL.

> We don't provide -c at all: we
> provide the options in the .SHELLFLAGS variable.

But there's a default if it is not provided, right?

> We don't escape anything at all: we provide the expansion of the
> command as the first argument.

I was alluding to the code described by this comment in job.c:

/* SHELL may be a multi-word command.  Construct a command line
   "$(SHELL) $(.SHELLFLAGS) LINE", with all special chars in LINE escaped.
   Then recurse, expanding this command line to get the final
   argument list.  */

> In other words, GNU make should basically run the equivalent of this
> "pidgin code":
> 
>   argv = [$(SHELL)]
>   argv += $(split $(.SHELLFLAGS))
>   argv += [""]
>   exec(argv);

But that's not exactly what the code there does, according to my
reading of it.

> It's up to the user to make sure the above construct actually works, if
> they're not using a default SHELL.

Before it works, we need to make sure argv[] won't fail the 'exec'
call due to these minor details.

> This is why I raised the generalization of batch files as an issue:
> some commands may not be able to accept "" on the command line
> like that, and if we could provide a _generic_ way to allow makefiles
> to change that final argv value to something else like a reference to a
> batch file where  was written, it could help.

Sure, but each shell has its own rules how to write batch files.  We
can support known shells, but what to do with unknown ones?

Re: How to choose the shell?

[Eli Zaretskii]

> From: Paul Smith 
> Cc: jfreema...@gmail.com, make-w32@gnu.org
> Date: Sun, 05 Sep 2021 14:38:52 -0400
> 
> On Sun, 2021-09-05 at 20:15 +0300, Eli Zaretskii wrote:
> > But the way we build the batch file assumes cmd.exe, because we have
> > no idea how to write scripts for other programs that can be used as
> > "shells".  Also, we have no idea about the quoting used by other
> > shells, so the tests that decide to "goto slow" due to fancy quoting
> > are also prone to fail.
> 
> I'm not sure I understand.
> 
> Clearly if SHELL is not changed then we need to do whatever is
> necessary to get the default shell (sh or cmd) to work.  I understand
> that this involves more complexity with cmd than sh.
> 
> But if the user changes SHELL to something that's not known to make
> then it's up to the user to make that work.  In that situation we
> should simply pass along the expanded recipe lines as they are written
> in the makefile, using the value of SHELL as the command and the value
> of .SHELLFLAGS as the flags.  It's up to the user to make sure it works
> with their customized setup, it's not something GNU make can do
> anything about.  So it shouldn't try.

I understand the principles.  The devil is in the details.

First, how do you invoke the shell?  On Unix we do "$SHELL -c", right?
What to do on Windows?  Most Windows shells don't support "-c".

Next, what are the characters special to the shell, and how to escape
them?  We currently use Unix conventions for that, with some Windows
fixups, but that won't necessarily work with an arbitrary Windows
shell.  What to use instead?

> Perhaps there's a good argument to be made, in 2021 with PowerShell
> ubiquitous on Windows system and also available on non-Windows systems,
> that we should teach GNU make how to use PowerShell as an optional
> "builtin shell" so that if the user sets SHELL to PowerShell we can
> handle that properly.  But that's just another special case; we need to
> solve the general case as well.

Agreed.

> It's also possible that generalizing the batch file model of command
> invocation would be good; there are situations even in GNU/Linux, which
> has far higher limits than Windows, where providing an entire command
> as a single argument causes exec to fail by exceeding limits.  We have
> SHELL and .SHELLFLAGS.  Maybe adding a new variable like .SHELLARG that
> controlled the format of the argument somehow (either the command
> string, which would be the default, or some way to write it to a
> temporary file and pass that file to the SHELL) would be useful.

Not sure how this is related to the main issue at hand.

Re: How to choose the shell?

[Eli Zaretskii]

> From: Paul Smith 
> Cc: jfreema...@gmail.com, make-w32@gnu.org
> Date: Sun, 05 Sep 2021 12:53:47 -0400
> 
> On Sun, 2021-09-05 at 19:50 +0300, Eli Zaretskii wrote:
> > > If you change the default shell, then make will never use any
> > > shortcuts since, obviously, it can't know what the syntax is of
> > > some other random shell.
> > 
> > I don't think Make on Windows does this bit.
> 
> Are you sure?

Quite sure.  You will see in main.c that we set default_shell to the
name of the shell we find, and then the test in job.c, which compares
shell with default_shell and does "goto slow" if they don't compare
equal, is effectively disabled.

> If not, that's definitely a bad bug in the Windows port of GNU make.

It's a bug, but there are good reasons for it: unlike on Unix, the
"slow" operation on Windows is problematic, because Windows shells
don't support the "$SHELL -c COMMAND" way of invocation, and the
quoting of COMMAND also has its quirks.  So we only do "$SHELL -c" if
the shell is sh.exe or similar; otherwise we create a temporary batch
file and submit it to the shell.  But the way we build the batch file
assumes cmd.exe, because we have no idea how to write scripts for
other programs that can be used as "shells".  Also, we have no idea
about the quoting used by other shells, so the tests that decide to
"goto slow" due to fancy quoting are also prone to fail.

So patches to fix this are welcome, of course, but it isn't like the
problem has an easy solution in general, at least AFAIK.

Re: How to choose the shell?

[Eli Zaretskii]

> From: Paul Smith 
> Cc: make-w32@gnu.org
> Date: Sun, 05 Sep 2021 12:42:37 -0400
> 
> If you change the default shell, then make will never use any shortcuts
> since, obviously, it can't know what the syntax is of some other random
> shell.

I don't think Make on Windows does this bit.

Re: How to choose the shell?

[Eli Zaretskii]

> From: John Freeman 
> Date: Sun, 5 Sep 2021 10:48:26 -0500
> Cc: Paul Smith , make-w32@gnu.org
> 
>  My suggestion for running commands that are only known to some
>  non-standard shell is either write the commands in recipes to invoke
>  the shell explicitly, or create a batch file, in your case ls.cmd,
>  which would call PowerShell internally, and put it somewhere on PATH.
>  Then everything should work without any tricks.
> 
> I'm trying to write a particular Makefile that works on both Windows and 
> Linux without requiring my users to
> add a bunch of binaries to either system.

That won't work, neither on Posix systems nor on Windows.  Not with
GNU Make.  Your Windows users should install the port of Coreutils.
It's not hard, such ports are available out there (I have one of them
installed).  Relying on built-in commands of non-standard shells,
without having the same commands as standalone executables, is not a
good idea, IME.

>  The manual isn't supposed to explain how to trick Make into doing
>  something it wasn't supposed to do.  Of course, if the GNU Make
>  maintainers decide to document these internals in the manual, it's
>  their prerogative.
> 
> I'm just trying to trick Make into doing what it _says_ it does. This 
> optimization to skip the shell is a
> regression when Make doesn't sufficiently understand the selected shell. 
> Perhaps the optimization should
> only be enabled for shells that Make understands. Then no explanation of the 
> optimization would be
> necessary because it would be completely transparent to users.

That's how GNU Make worked since day one, AFAIK.  Explaining that in
more detail could help you understand what's going on, but it won't
necessarily allow you to solve every such problem, because not every
command in a Makefile recipe can be made to run through a shell
without changing its semantics.  Even redirection could be a problem.

Re: How to choose the shell?

[Eli Zaretskii]

> From: John Freeman 
> Date: Sat, 4 Sep 2021 17:32:05 -0500
> Cc: make-w32@gnu.org
> 
>  It's not documented because the details are complex and hard to
>  explain, and the result isn't supposed to depend on whether Make
>  invokes commands directly or via the shell.  So why do you care to
>  know which way does make invoke a given command?
> 
> Not so complex and hard to explain that you couldn't concisely explain it in 
> this thread and [that thread]
> (https://lists.gnu.org/archive/html/make-w32/2020-05/msg1.html). Just use 
> one of the two explanations
> you gave. They're totally sufficient, in my opinion.

What I explained is only a part of what's going on.  There are
subtleties with quoting and with what exactly triggers invocation
through shell.  In addition, some of that depends on whether the shell
is sh.exe or cmd.exe.  It's complex, please take my word for it.  That
the simplistic explanation, tailored to your specific use case, was
enough in your case, doesn't yet mean it will satisfy everyone, and
will be accurate enough to be part of the official Make manual.

>  What for?  Make is for building programs by running shell commands.
>  As long as the results of running a command are the same, why should
>  you care how that command is invoked, and why would you need a way to
>  force invocation via the shell?
> 
> You assume that the results are the same. This thread and that thread have 
> demonstrated that they are not.

This part I don't yet understand.  Why invoking 'ls' via PowerShell
works whereas invoking it directly doesn't?  You never explained
that.  So I don't think I have a clear enough understanding of what you
wanted to do and how.

> Makefile that I thought should work according to the documented behavior, and 
> it didn't. _That_ is why I care
> how the commands are invoked. My commands work in the shell, and don't work 
> without the shell. So
> please let me use the shell without having to sign up for the mailing list 
> and jump through an extra hoop on
> every command. A naive implementation would do the right thing every time. 
> This optimization is doing the
> wrong thing some of the time.

If 'ls' in your case is a shell command, then Make doesn't know about
that.  Make on Windows only knows about built-in commands of 2 shells:
sh.exe and cmd.exe, and it applies them according to the current
shell.  So what you wanted to do (AFAIU) wouldn't work on any Posix
system either, and thus it isn't supposed to work on Windows.

My suggestion for running commands that are only known to some
non-standard shell is either write the commands in recipes to invoke
the shell explicitly, or create a batch file, in your case ls.cmd,
which would call PowerShell internally, and put it somewhere on PATH.
Then everything should work without any tricks.

The manual isn't supposed to explain how to trick Make into doing
something it wasn't supposed to do.  Of course, if the GNU Make
maintainers decide to document these internals in the manual, it's
their prerogative.

The above is my opinion; my involvement in GNU Make maintenance is
quite humble.  I CC Paul, the GNU Make maintainer, in case he would
like to comment.

Re: How to choose the shell?

[Eli Zaretskii]

> From: John Freeman 
> Date: Sat, 4 Sep 2021 11:33:01 -0500
> Cc: make-w32@gnu.org
> 
> I have since discovered [this 
> thread](https://lists.gnu.org/archive/html/make-w32/2020-05/msg1.html),
> the very previous thread on this mailing list, working through the exact same 
> problem. I'm happy that there is
> a workaround, but this seems to me like undocumented behavior. It is not 
> mentioned anywhere in the
> [pages](https://www.gnu.org/software/make/manual/html_node/Execution.html#Execution)
>  on Recipe
> Execution. One might argue that the parenthetical statement "(In practice, 
> make may take shortcuts that do
> not affect the results.)" implies this behavior, but I think we can see that 
> this behavior _does_ affect the
> results. At the very least, I think this behavior should be explicitly 
> documented. Perhaps a footnote?

It's not documented because the details are complex and hard to
explain, and the result isn't supposed to depend on whether Make
invokes commands directly or via the shell.  So why do you care to
know which way does make invoke a given command?

> My preference would be to have some other workaround that doesn't require me 
> to modify every recipe line,
> e.g. a special variable `.FORCE_SHELL`.

What for?  Make is for building programs by running shell commands.
As long as the results of running a command are the same, why should
you care how that command is invoked, and why would you need a way to
force invocation via the shell?

Re: How to choose the shell?

[Eli Zaretskii]

> From: John Freeman 
> Date: Sat, 4 Sep 2021 10:11:19 -0500
> 
> I previously sent this message to Eli Zaretskii, whose [EZWinPorts]
> (https://sourceforge.net/projects/ezwinports/files/) binary I am using. He 
> asked me to move this conversation
> here.

Thanks for taking it here, this is the right place for such
discussions.

> I'm trying to choose the shell for my Makefile recipes when I run 
> EZWinPorts's Windows port of Make 4.3
> (without Guile, [installed by 
> Scoop](https://github.com/ScoopInstaller/Main/blob/master/bucket/make.json)),
> but can't seem to get it to work.

First, I'd like to emphasize that the binaries on that site are
straight OOTB builds of the GNU Make sources, following the documented
build procedure.  There are no source-level changes, nor any special
build-time tricks.  So what I describe below is how the official GNU
Make behaves when compiled natively for MS-Windows.

> For example, I'm running on Windows with PowerShell installed and on the 
> `PATH`. If I make a target whose
> recipe is just "`ls`", I get this error:
> 
> process_begin: CreateProcess(NULL, ls, ...) failed.
> make (e=2): The system cannot find the file specified.
> make: *** [Makefile:4: ls] Error 2
> 
> That's fine. Maybe it's using `cmd` as the shell for that line (but it really 
> looks like it ignores all shells and
> directly calls Windows's equivalent of `popen`). Then I run through the 
> different [options]
> (https://www.gnu.org/software/make/manual/html_node/Choosing-the-Shell.html) 
> for choosing the shell as
> laid out in the docs.

GNU Make avoids calling the shell for commands that don't require any
shell functionality it knows about.  This is how GNU Make works on all
platforms, and the Windows port doesn't change that.  So if you don't
have ls.exe or ls.bat or ls.cmd somewhere on Path, the above is
expected, regardless of the value of SHELL in the Makefile.  (You can
see from the error message that it tried to invoke 'ls'; the shell is
nowhere in the call it shows that failed.)

To trigger the use of a shell, you need to use some feature on the
command line that needs a shell.  For example, redirection or some
fancy quoting.

> - I can see that `ComSpec` is set in my default environment. In PowerShell, I 
> can read it as `$env:ComSpec
> ` or `$env:COMSPEC`, but in a Makefile, it is only available as `${ComSpec}`. 
> If I remove and re-add the
> variable under the name `$env:COMSPEC`, it becomes available in the Makefile 
> as `${COMSPEC}`, but I
> still get the same error from the `ls` recipe.

I'm not sure I understand why you think this is a problem.
Environment variables are case-insensitive on MS-Windows, so why does
it matter whether you have ComSpec or COMSPEC?

> How can I achieve my goal?

What is your goal, exactly?  I don't think you stated it, or maybe I
missed that.

Re: powershell as a default GNU make SHELL in windows

[Eli Zaretskii]

> From: Илья 
> Date: Tue, 12 May 2020 19:43:05 +0300
> 
> Hello! Could you please help me with the following trouble?
> 
> https://stackoverflow.com/q/61754413/4105482

Try this:

  SHELL := pwsh.exe

  VAR=asdf/asdf

  .PHONY: get_var

  get_var:
@Write-Output $(VAR) 2>&1

Explanation:

 1) The value of SHELL should be with the .exe extension and without
the -c switch (or any other switches -- it's supposed to be the
name of the shell's executable file)
 2) GNU Make doesn't invoke the shell unless it (a) sees a shell
built-in command, or (b) sees some character special to the
shell.  Since the built-in commands of PowerShell are not known to
GNU Make, you are left with the second option, and the no-op
redirection achieves that.

More generally, for an unusual shell such as PowerShell, my
recommendation is to use the explicit "pwsh -c COMMAND" invocation in
the Makefile.

HTH

Re: [Tinycc-devel] I want to port make on Windows using tcc compiler

[Eli Zaretskii]

> From: "Christian Jullien" 
> Cc: ,
>   
> Date: Sun, 26 Jan 2020 17:57:25 +0100
> 
> I try to keep my dev. Machine a lite as possible so I'll decline to install
> more tools (sorry).

Fair enough.

Re: [Tinycc-devel] I want to port make on Windows using tcc compiler

[Eli Zaretskii]

> From: Paul Smith 
> Date: Sun, 26 Jan 2020 12:14:26 -0500
> Cc: make-w32@gnu.org
> 
> On Sun, 2020-01-26 at 17:57 +0100, Christian Jullien wrote:
> > I try to keep my dev. Machine a lite as possible so I'll decline to
> > install more tools (sorry).
> 
> If you install Perl and Git for Windows you'll have everything you need to
> get most of the tests running... in the instances where I have access to a
> Windows machine that's all I have installed (as best as I remember).

But the patches I made in the test suite are not for that
configuration.  (I do have Git for Windows installed, of course, but I
deliberately do not put it on the system-wide PATH.)

Re: [Tinycc-devel] I want to port make on Windows using tcc compiler

[Eli Zaretskii]

> From: "Christian Jullien" 
> Cc: ,
>   
> Date: Sun, 26 Jan 2020 07:51:46 +0100
> 
> c:\downloads\make-4.3\tests>run_make_tests.bat
> 
> --
>  Running tests for GNU make on cygwin
 ^^
What's this about?  Are you running this with Cygwin tools on PATH?
That's a recipe for disaster, you should run this from cmd.exe, and
you should have native Windows ports of Coreutils and of Perl
installed.  That's how I run the test suite.

Sorry, I should have said that explicitly before luring you into this
adventure.  Working with Cygwin ports will need an entirely different
set of patches to the test suite.

Re: [Tinycc-devel] I want to port make on Windows using tcc compiler

[Eli Zaretskii]

> Date: Fri, 24 Jan 2020 15:34:08 +0200
> From: Eli Zaretskii 
> Cc: make-w32@gnu.org, jull...@eligis.com
> 
> Thanks, then I guess when Christian's legal paperwork is done, I will
> apply these changes.

While we are waiting: Christian, did you happen to run the GNU Make
test suite with the tcc-built Make?  The test suite needs some patches
to run reasonably well on MS-Windows, but you can find the patched
tests here:

  
https://sourceforge.net/projects/ezwinports/files/make-4.3-w32-src.zip/download

I'd be interested to see the results reported by the test suite for
your build.  For the reference, the MinGW build fares like so:

  49 Tests in 19 Categories Failed

(out of 638 tests).

Thanks.

Re: [Tinycc-devel] I want to port make on Windows using tcc compiler

[Eli Zaretskii]

> From: Paul Smith 
> Cc: make-w32@gnu.org
> Date: Fri, 24 Jan 2020 07:49:37 -0500
> 
> On Fri, 2020-01-24 at 09:25 +0200, Eli Zaretskii wrote:
> > Paul, any comments?  The changes look reasonable to me, FWIW.
> 
> They seem good to me!

Thanks, then I guess when Christian's legal paperwork is done, I will
apply these changes.

Re: [Tinycc-devel] I want to port make on Windows using tcc compiler

[Eli Zaretskii]

> From: "Christian Jullien" 
> Cc: ,
>   
> Date: Fri, 24 Jan 2020 10:39:12 +0100
> 
> I let you decide if this modest contribution is worth for me to mention as
> contributor.

We always attribute the changes to their original authors.  So if your
changes are accepted, your name will be mentioned, of course.

Re: [Tinycc-devel] I want to port make on Windows using tcc compiler

[Eli Zaretskii]

> From: "Christian Jullien" 
> Cc: 
> Date: Fri, 24 Jan 2020 09:13:12 +0100
> 
> > Would you like me to send you the form to fill to start the legal
> paperwork?
> 
> For sure, I'll be glad to do so.

Thanks, form sent off-list.

Re: [Tinycc-devel] I want to port make on Windows using tcc compiler

[Eli Zaretskii]

> From: "Christian Jullien" 
> Cc: 
> Date: Wed, 22 Jan 2020 20:57:37 +0100
> 
> Ok here are the patches:

Thanks.  A few questions and comments below.

>  :: Find a compiler.  Visual Studio requires a lot of effort to locate :-/.
>  %COMPILER% >nul 2>&1
> @@ -172,6 +182,7 @@
>  set OUTDIR=.\GccRel
>  set LNKOUT=./GccRel
>  set OPTS=-O2
> +set DIRENT=N

What is this part about?  Is it needed, and if so, why?

> +:TccCompile
> +:: TCC Compile
> +echo on
> +%COMPILER% -mthreads -Wall -std=c11 %OPTS% -I%OUTDIR%/src -I./src

Why are you using -std=c11 here? this is unlike all the other
compilations, which use C99.

> +:TccLink
> +:: TCC Link
> +echo on
> +echo %GUILELIBS% -lkernel32 -luser32 -lgdi32 -lcomdlg32 -ladvapi32
> -lshell32 -lole32 -loleaut32 -lodbc32 -lodbccp32 >>%OUTDIR%\link.sc
> +%COMPILER% -mthreads %OPTS% -o %LNKOUT%/%MAKE%.exe @%LNKOUT%/link.sc 

Does this build the import library?  And in general, does the tcc
build support loadable modules?

Last, but not least: a contribution this large will need you to sign
legal papers assigning the copyright to the FSF.  Would you like me to
send you the form to fill to start the legal paperwork?

Paul, any comments?  The changes look reasonable to me, FWIW.

Re: Why SHELL defaults to sh.exe

[Eli Zaretskii]

> From: "Christian Jullien" 
> Cc: 
> Date: Thu, 23 Jan 2020 21:07:26 +0100
> 
> Perhaps my sample was too simple.
> If I supply a Makefile that can work with or without sh.exe presence (on any
> user machines) I must rely on what make knows about the shell.

I'm saying such strategy is not the best one on Windows, because there
are too many variables the name of the shell doesn't capture.  Even if
you have some sh.exe somewhere, you cannot know what kind of shell is
it (Bash? zsh? something else?) and what exactly is it capable of on
Windows.  Programs that can be expected to be found on Unix might
exist on Windows as well, but you cannot be sure.

So a better strategy is to leave it up to the user to decide whether
to run in Unix mode or in Windows mode, and whether to call, say,
'del' or 'rm'.

Another, better method of detecting whether you are on Windows is to
probe the $(OS) variable: all modern versions of Windows have it set,
so your probability of a correct decision is much higher in that
case.  (But issues with what commands to employ still apply even in
that case.)

> Another example, Cygwin which provides a sh.exe also dir.exe which gives a
> different output. If SHELL is sh.exe or cmd.exe output is different

That's the same problem as the one with having 'find' from GNU
Findutils or from Windows.  It's part of the "which commands to
invoke" issue discussed above, nothing new.

> For my need, which is to have a gnumake coming with tcc.exe, I know how to
> automatically patch and build make with sh.exe replaced by cmd.exe in source
> file. So it's not a problem for me. I just wanted to point out something
> which I find not consistency (aka a bug).

It is a subtle issue, but I don't consider it a bug, since GNU Make on
Windows behaves like that since its first ported version.  You need to
be aware of that subtlety, but once you are, it is rarely a real issue
in practice.

Maybe we could remove that nowadays, but I have no way of knowing
what, if anything, that will break, and no motivation to work on a
change that can potentially destabilize what has been a very stable
program.

Re: Why SHELL defaults to sh.exe

[Eli Zaretskii]

> From: "Christian Jullien" 
> Date: Thu, 23 Jan 2020 20:18:17 +0100
> 
> Hum I see! It only a problem if I want to execute something if a sh.exe
> exists.
> 
> search:
> ifeq ($(SHELL),sh.exe)
>   grep something file
> else
>   find "something" file
> endif

If you want to depend on the value of $(SHELL), set it explicitly in
the Makefile.

In any case, the above logic is flawed, because 'grep' can be
available on Windows as well (I certainly have it here), and 'find'
could actually invoke a ported GNU 'find'.  IME, it is much better to
have Make variables for such commands, and let users set them from the
Make command line.

Re: Why SHELL defaults to sh.exe

[Eli Zaretskii]

> From: "Christian Jullien" 
> Cc: 
> Date: Thu, 23 Jan 2020 15:54:50 +0100
> 
> cmd>type Makefile
> all:
> @echo $(SHELL)
> cmd>.\gnumake
> sh.exe<=== Argl!!

Why is that a problem?

If you do

  .\gnumake -f-
  all:
dir *c
  ^Z

does it not invoke cmd.exe's DIR command?  It does here.

All you've shown is the value of $(SHELL) set by Make internally,
that's all.  It doesn't mean this will be the shell that will be
invoked to execute shell commands.

Re: Why SHELL defaults to sh.exe

[Eli Zaretskii]

> From: "Christian Jullien" 
> Date: Thu, 23 Jan 2020 11:27:53 +0100
> 
> I wonder why Windows native gnumake.exe defaults to sh.exe ?

Historical reasons.

> Building gnumake.exe with build_w32.bat (which defaults to cl.exe) still uses 
> sh.exe while IMHO it should
> default to cmd.exe

It only defaults to sh.exe if it finds one on PATH.  If you are using
native Windows tools, why would you have sh.exe on PATH? there are no
known good native Windows ports of any Unixy shell, AFAIK, only broken
ones.

If you don't have sh.exe on PATH, GNU Make on Windows will use cmd.exe.

> In an ideal world, I should be able to get for example all .c source files 
> with:
> 
>  
> 
> FILES   = $(shell dir /b *.c)

In GNU Make, you have the $wildcard function instead, so no need to
use the shell in this case.

Re: [Tinycc-devel] I want to port make on Windows using tcc compiler

[Eli Zaretskii]

[Please keep the make-w32 list on the CC.]

> From: "Christian Jullien" 
> Date: Wed, 22 Jan 2020 20:23:33 +0100
> 
> I see. In this case I need an advice.
> 
> As you probably understand now, I want a simple mechanism which allows a
> non-technical user to rebuild gnumake.exe from an official distrib (like
> 4.3) and tcc.exe + cmd.exe (that's all).
> For example, with Visual C++ installed, build_w32.bat works perfectly and
> produces a fully working gnumake.exe (without the need to get mentioned
> template file).
> I want to do exactly the same replacing default cl by tcc.

OK, but what kind of advice do you need?  The changes to the template
file, if accepted, will eventually be propagated into config.h.W32 in
the release tarball, and so if you can build the tarball by editing
the config.h.W32 file, you will be able to do the same after the patch
for the template is accepted and installed.

> So, here is the patch to apply to template file:
> 
> F:\wintcc\make>diff config.h.W32.new config.h.W32.template

Please use "diff -u" or "diff -c".

> Can you please add it as well as my modified build_w32.bat ?

Please also show the diffs for the batch file.

Re: [Tinycc-devel] I want to port make on Windows using tcc compiler

[Eli Zaretskii]

> From: "Christian Jullien" 
> Date: Wed, 22 Jan 2020 18:44:25 +0100
> Cc: tinycc-de...@nongnu.org
> 
> Thank you Eli, your help is really appreciated.
> 
> >From the latest https://ftp.gnu.org/gnu/make/make-4.3.tar.gz I don't see the
> src/config.h.W32.template you're referring to.

The template file is not in the tarball, it is in the GNU Make Git
repository.  See https://savannah.gnu.org/git/?group=make.

Re: make compilation

[Eli Zaretskii]

> From: valerij zaporogeci 
> Date: Fri, 6 Oct 2017 15:43:28 +0300
> 
> As I said I used nmake /f nmakefile from the Studio command prompt.
> in the main nmakefile there is /I glob, but in the subproc's one there isn't.
> 
> subproc's nmakefile is invoked from the main:
> w32/subproc/WinDebug/subproc.lib w32/subproc/WinRel/subproc.lib:
> w32/subproc/misc.c w32/subproc/sub_proc.c w32/subproc/w32err.c
>   subproc.bat $(SUBPROC_MAKEFILE) $(MAKE)
>   if exist WinDebug\make.exe erase WinDebug\make.exe
>   if exist WinRel\make.exe erase WinRel\make.exe
> 
> isn't it?
> but in the Include path of that file, glob is missing.
> Anyway, without that change, it fails. :)

Paul, can you make this change in subproc/NMakefile?  I don't have MS
tools installed, so I cannot test this change with the latest Git
repository.

Thanks.

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

Re: make compilation

[Eli Zaretskii]

[Please keep the list address on the CC list.]

> From: valerij zaporogeci 
> Date: Fri, 6 Oct 2017 15:08:08 +0300
> 
> Yes, now I tried 4.2.1. the second problem is gone, since now ISBLANK is used.
> but the first still is there. complilation fails with "cannot open
> subproc.lib" message. After adding -I ../../glob in subproc's
> nmakefile everything compiles fine.

I must be missing something, because I don't see how subproc/NMakefile
comes into play here.  Are you building using the build_w32.bat batch
file?  Because if you are, that batch file doesn't reference any
NMakefile, it just compiles the files by directly invoking cl.exe, the
MSVC compiler, and the cl.exe command line does include "/I glob".

>From my POV, the various methods mentioned in README.W32, besides the
one which uses build_w32.bat, are much less reliable due to different
versions of Studio and Nmake that each have its own quirks.  The batch
file, by contrast, should "just work".

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

Re: make compilation

[Eli Zaretskii]

> From: valerij zaporogeci 
> Date: Fri, 6 Oct 2017 01:37:09 +0300
> 
> I've just compiled make 4.2 for Windows (XP x64, Visual Studio 2008
> compiler, through nmake). Didn't test it though, just made my small
> project with a quite simplistic makefile and it worked. The
> compilation wasn't without problems. I don't know either this is my
> fault or make's one. In any case, It would be useful to get your
> attention on it. for at least 1 side.
> First:
> subproc nmakefile doesn't set -I ..\..\glob so compiler says glob.h is
> missing. this include is inside makeint.h, the latter is included for
> example in sub_proc.c, w32err.c.
> second:
> in pathstuff.c there is a reference to isblank() which is not found
> anywhere, so in the end linker can not resolve symbol _isblank().
> During investigation I found that there is a macro ISBLANK in the
> makeint.h and just uppercased isblank() in pathstuff.c to ISBLANK().
> :D Of course it compiled now, but I cannot say whether this bravery
> isn't stupidity. How do you think? Is it supposed to be ISBLANK macro
> there or there is really a function isblank()?

Thank you for your report.  I believe all of these issues are solved
in Make 4.2.1, the latest released version.  Could you please try that
and see if any of the problems remain?

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

Re: [PATCH] Windows jobserver updates for GNU make 4.2.1

[Eli Zaretskii]

> From: Troy Runkel 
> Date: Tue, 1 Nov 2016 19:16:33 +
> 
> This patch expands the maximum number of simultaneous jobs on Windows from 63 
> (limit dictated by
> Windows MAXIMUM_WAIT_OBJECTS) to 4095.
> 
> It also fixes a situation where GNU make on Windows could deadlock and/or 
> suffer memory corruption issues
> if –j or –j63 was used. The problem was due to the way that $(shell …) 
> commands are handled.

Thanks, pushed.

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

Re: GNU make 4.2 (and 4.2.1) failing due to length of command-line

[Eli Zaretskii]

> From: Paul Smith <psm...@gnu.org>
> Cc: Eli Zaretskii <e...@gnu.org>, "make-w32@gnu.org" <make-w32@gnu.org>
> Date: Wed, 22 Jun 2016 16:54:35 -0400
> 
> On Wed, 2016-06-22 at 20:36 +, Adrian Muresan wrote:
> > Does batch_mode_shell = 1 mean that it always uses the sh.exe instead
> > of Windows.cmd?
> 
> No.  It's clear that make is not using Windows command.com, because the
> script you're running is a POSIX shell script, not a command.com batch
> script.  If you tried to enter those commands into your command.com
> prompt you'd get a syntax error.
> 
> What that flag means (as I understand it: I'm not that familiar with
> this aspect of Windows support) is that make will never try to invoke
> the shell directly passing the recipe to be run on the command line.
> 
> Instead it is being forced to always write the recipe to a temporary
> file ("batch file") on your disk and invoke the shell such that it runs
> the recipe in the temporary file.

Yes, that's true.  As an aside, the Windows shell is cmd.exe, not
command.com, and Make uses cmd.exe if either (a) the Makefile requires
that with the "SHELL =" command, or (b) it cannot find any sh.exe on
PATH.

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

Re: GNU make 4.2 (and 4.2.1) failing due to length of command-line

[Eli Zaretskii]

> From: Adrian Muresan <adrianmure...@outlook.com>
> CC: Eli Zaretskii <e...@gnu.org>, "make-w32@gnu.org" <make-w32@gnu.org>
> Date: Wed, 22 Jun 2016 18:48:35 +
> 
> I ran using GNU make 3.81 from two different sources:
> 
> once using the binary form sourceforge 
> And 
> once using the binary from QNX. 
> 
> QNX gave no error and SourceForge gave an error (the same error as 4.2, 4.2.1 
> I built and the 4.0+ binary version Eli told me to get from SourceForge). 
> 
> Doesn't this prove there's a bug? As Eli said, QNX obviously patched 
> something since everything else, even the shell used, was the same. 

The bug, or rather, the limitation is not in Make, it's in the shell
you use.  I suggested how to build Make in a way that might work
around this limitation, and I'm guessing that the QNX folks built
their make with that option as well.  Of course, it would be best to
know what changes they made, so that you could make the same changes
in the newer Make.

However, all this does not change the basic fact that the limitation
is in Bash.  Make, on its side, invokes Bash with the full command
line, but Bash only reads the first 16KB of it.  How is it a bug in
Make?  Make doesn't have a goal of catering to limitations of programs
invoked from Make, certainly not the limitations of MSYS Bash, which
is not even a simple native Win32 application.  GNU Make development
cannot be responsible for limitations of other programs out there,
it's unreasonable to expect it to do that.

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

Re: GNU make 4.2 (and 4.2.1) failing due to length of command-line

[Eli Zaretskii]

> From: Adrian Muresan 
> CC: "make-w32@gnu.org" 
> Date: Wed, 22 Jun 2016 17:01:22 +
> 
> I downloaded 
> https://sourceforge.net/projects/ezwinports/files/make-4.2-without-guile-w32-bin.zip/download
> 
> I ran the command
> C:\Users\mureadr\Desktop\A\HMI_FORGF\bld\armle-v7\release\fordhmi>"C:\Users\mureadr\Downloads\make-4.2-without-guile-w32-bin\bin\make.exe"
>  deploy_marketProperties --debug=vjm --print-data-base > 42-SForge.err 2>&1
> 
> And I still got the same error (see attachment).
> This time, I kept the entire output so you can reproduce it exactly. 

Thanks.  Indeed, I see the command truncated at 16384 bytes,
i.e. exactly 16KB.  This seems to be the limitation of sh.exe itself,
because if I replace the 1st "echo" on the command line with
"echo.exe", and remove all the && and the quotes (which force Make to
invoke the command through the shell), then I see the full untruncated
command line in the output.  Which means invoking echo.exe directly
with such long command lines does work, and the truncation is not
Make's fault.

So my guess is that your make 3.81 used a disk file to run the shell
command as a script, whereas the default build of Make 4.2 invokes the
shell directly.  You could try rebuilding Make 4.2 with
BATCH_MODE_ONLY_SHELL defined, see the end of the file config.h.  Or
maybe you could find a better port of Bash that doesn't suffer from
this limitation.

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

Re: GNU make 4.2 (and 4.2.1) failing due to length of command-line

[Eli Zaretskii]

> From: Michael Stahl 
> Date: Wed, 22 Jun 2016 17:43:44 +0200
> 
> >> FWIW i've noticed that with make 4.0/4.1 built for Win32, invoking the
> >> Cygwin bash shell as C:/cygwin/bin/sh.exe, the command lines are
> >> silently truncated at ~8K characters - this did not happen when we used
> >> GNU make 3.82 built for Cygwin.
> > 
> > You are talking about the Cygwin build of Make, yes?  That's a
> > different build from the one in the OP's report.
> 
> no, Win32 make - i noticed while adapting the LibreOffice build system
> from Cygwin make to Win32 make a couple years ago (which gave a large
> speed improvement, see [1] for details) that some commands that used to
> work before failed with Win32 make because the command lines were truncated.

That certainly doesn't happen here -- but I don't use Cygwin programs
at all.

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

Re: GNU make 4.2 (and 4.2.1) failing due to length of command-line

[Eli Zaretskii]

> From: Michael Stahl 
> Date: Wed, 22 Jun 2016 13:58:41 +0200
> 
> On 22.06.2016 00:53, Adrian Muresan wrote:
> > On GNU make 3.81, it works fine. But on make 4.2 and 4.2.1, I get an error:
> > 
> > cp: target `C' is not a directory
> > 
> > The problem appears to be the length of the command. If I delete some
> > JSON files, it works fine.
> 
> FWIW i've noticed that with make 4.0/4.1 built for Win32, invoking the
> Cygwin bash shell as C:/cygwin/bin/sh.exe, the command lines are
> silently truncated at ~8K characters - this did not happen when we used
> GNU make 3.82 built for Cygwin.

You are talking about the Cygwin build of Make, yes?  That's a
different build from the one in the OP's report.

And yes, the native Windows build of Make supports command lines up to
32K bytes, except when it invokes cmd.exe, which itself is limited to
4K bytes.

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

Re: [PATCH] Windows jobserver updates for GNU make 4.1

[Eli Zaretskii]

> From: Troy Runkel 
> CC: "make-w32@gnu.org" ,
> Troy Runkel
>   
> Date: Fri, 8 Apr 2016 12:19:27 +
> 
> I've contacted MathWorks legal and the originating developer regarding 
> getting a copyright assignment in place for these changes.  Whom should I 
> contact on the FSF side regarding the copyright assignment?

I can send you the assignment request form, if you want.  Then you
should act according to the instructions there.

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

Re: [PATCH] Windows jobserver updates for GNU make 4.1

[Eli Zaretskii]

> From: Paul Smith 
> Cc: troy.run...@mathworks.com, make-w32@gnu.org
> Date: Tue, 08 Mar 2016 16:11:55 -0500
> 
> >  . dosbuild.bat doesn't compile files under w32/
> >  . dosbuild.bat doesn't compile Guile support
> >  . dosbuild.bat doesn't compile load API
> >  . dosbuild.bat mentions DJGPP, which is the DOS GNU-based development
> >environment
> 
> OK.  I'll put down my editor and back away slowly, and let you all
> decide if the various build alternatives can be consolidated...
> 
> Maybe I'll see if I can get a DJGPP install just to verify things
> compile and run still; can you do on Windows or should I get a
> virtualbox running MS-DOS? :)

Yes, you can do that on Windows, if you install DJGPP.

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

Re: [PATCH] Windows jobserver updates for GNU make 4.1

[Eli Zaretskii]

> From: Troy Runkel 
> CC: "make-w32@gnu.org" ,
> Troy Runkel
>   
> Date: Tue, 8 Mar 2016 13:54:26 +
> 
> So, if I were to personally re-implement our Windows jobserver patch on top 
> of your changes and then submit a new patch, would you be able to accept the 
> patch using my already existing copyright assignment?

I see no problem with your assignment, Troy.

Thanks.

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

Re: [PATCH] Windows jobserver updates for GNU make 4.1

[Eli Zaretskii]

> From: Paul Smith 
> Cc: make-w32@gnu.org
> Date: Mon, 07 Mar 2016 17:11:25 -0500
> 
> I'm not sure what to do about the plethora of other ways we can build
> for Windows.  Do we still have any use for dosbuild.bat for example? 
>  It seems to invoke gcc... does that mean it's superseded by the
> build_w32.bat support for GCC builds?

dosbuild.bat is for DOS, not for Windows.

> I assume we still support NMakefile?

No, not really.

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

Re: [PATCH] Windows jobserver updates for GNU make 4.1

[Eli Zaretskii]

> From: Troy Runkel 
> CC: "make-w32@gnu.org" 
> Date: Tue, 1 Mar 2016 12:21:38 +
> 
> The changes for this patch were created by another developer where I work.  
> I've forwarded your questions to him and included his answers below.  Thanks!

Thanks.  But if changes were not written by you, how can we accept
them, without knowing the name of that person and verifying we have a
copyright assignment from him on file?  The changes are substantial
enough to require legal papers.

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

Re: [PATCH] Windows jobserver updates for GNU make 4.1

[Eli Zaretskii]

> From: Troy Runkel 
> Date: Wed, 24 Feb 2016 17:27:57 +
> Cc: Troy Runkel 
> 
> This patch expands the maximum number of simultaneous jobs on Windows from 63 
> (limit dictated by
> Windows MAXIMUM_WAIT_OBJECTS) to 4095.
> 
> It also fixes a situation where GNU make on Windows could deadlock and/or 
> suffer memory corruption issues
> if –j or –j63 was used. The problem was due to the way that $(shell …) 
> commands are handled.

Thanks.

I wonder how hard would it be to remove the limitation altogether?
If we are lifting the limitation, why not lift it entirely?

Another comment is about the busy-wait loop (with 10-msec sleep) that
this change uses -- it looks like, when there are 4095 jobs running,
we will be re-checking each process once every 640 msec, is that
right?  That might be too large a delay, I think.  Did you consider a
design that uses a separate thread for watching up to 64 processes?  I
think such a design might scale up better; in particular, the response
time for checking the status of each job will not decrease as the
number of jobs goes up.

> +DWORD GmakeWaitForMultipleObjects(
> +  DWORD nCount,
> +  const HANDLE *lpHandles,
> +  BOOL bWaitAll,
> +  DWORD dwMilliseconds
> +)
> +{
> +  assert(nCount <= GMAKE_MAXIMUM_WAIT_OBJECTS);
> +
> +  if (nCount <= MAXIMUM_WAIT_OBJECTS) {
> +DWORD retVal =  WaitForMultipleObjects(nCount, lpHandles, bWaitAll, 
> dwMilliseconds);
> +return (retVal == WAIT_TIMEOUT) ? GMAKE_WAIT_TIMEOUT : retVal;

This GMAKE_WAIT_TIMEOUT and GMAKE_WAIT_ABANDONED_0 stuff looks like a
kludge to me; can we get rid of it?

> +switch (retVal) {
> +  case WAIT_TIMEOUT:
> +retVal = GMAKE_WAIT_TIMEOUT;
> +continue;
> +break;
> +  case WAIT_FAILED:
> +fprintf(stderr,"WaitForMultipleOjbects failed waiting with error 
> %d\n", GetLastError());
> +break;

I guess this fprintf should go away, or be converted to a DB call?

Thank you for working on this.

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

Re: [SOLVED] Re: process_begin: CreateProcess(NULL, , ...) failed

[Eli Zaretskii]

 Date: Mon, 13 Jul 2015 05:53:00 -0700 (PDT)
 From: ruzrulit ruzru...@mail.ru
 
 Fabrice GIRARDOT wrote
  Eli Zaretskii wrote :
  
  process_begin: CreateProcess(NULL, , ...) failed
  
  Yes, this is a known bug in Make 3.81.  If you can build Make from
  sources, please try the following two patches (apply them in order):
  
  I successfully applied these 2 patches, and the bug has gone away.
  Thanks for your help.
  
  
  Regards.
  
  
  -- 
  Fabrice GIRARDOT
  
  
  
  ___
  Make-w32 mailing list
 
  Make-w32@
 
  http://lists.gnu.org/mailman/listinfo/make-w32
 
 Hello dear Fabrice,
 
 I also have the same issues and dont know how to solve them.
 Could you please send me that Make that u got after patching?

You can find precompiled binaries of the latest release of GNU Make
for MS-Windows here:

  
http://sourceforge.net/projects/ezwinports/files/make-4.1-with-guile-w32-bin.zip/download
  
http://sourceforge.net/projects/ezwinports/files/make-4.1-without-guile-w32-bin.zip/download

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

Re: Problematic temporary BAT files

[Eli Zaretskii]

 Date: Fri, 17 Oct 2014 15:14:37 +0200
 From: Bostjan Mihoric ccomplet...@gmail.com
 
 Redirecting the temporary folder doesn't work in this case.

Sorry, I'm probably missing something here.  What exactly is a
definition of a temporary folder for this purpose?  IOW, in which
folders are you not allowed to invoke programs or batch files?

I thought the problem was with the temporary folder under
CSIDL_PROFILE.  The TEMP environment variable is set to it as a side
effect.  But you seem to be saying that no matter which folder TEMP
points at, that folder would be regarded as a temporary folder, is
that right?  How can this make sense, if TEMP can be set differently
in every console cmd session a user has?

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

Re: Problematic temporary BAT files

[Eli Zaretskii]

 Date: Sat, 18 Oct 2014 00:48:07 +0200
 From: Bostjan Mihoric ccomplet...@gmail.com
 
 I thought the problem was with the temporary folder under
 CSIDL_PROFILE. The TEMP environment variable is set to it as a side
 effect. But you seem to be saying that no matter which folder TEMP
 points at, that folder would be regarded as a temporary folder, is
 that right? How can this make sense, if TEMP can be set differently
 in every console cmd session a user has?
 
 
 Ah, I see. Up until now, I knew that I could override temporary folder for the
 console session. But I thought that any new program that gets launched, will
 have the system value restored (including Make, of course).

This is only so for programs invoked from a desktop shortcut, or from
the Start-Run dialog, or by double clicking in Explorer.  For those,
the parent process is the Windows Explorer, so those programs get the
system-wide values of these variables.

But for a program invoked from the cmd window, the parent process is
cmd.exe, so it gets environment variables set in that cmd window.

 The test I just performed shows otherwise (child process inherits
 the value). This means I can probably use this localized redirection
 of temporary folder.
 
 Thank you for your help!

You are welcome.

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

Re: Gnu Make operating conditions

[Eli Zaretskii]

 Date: Thu, 5 Jun 2014 18:45:29 +0530
 From: chandrababu nallani nallani.chan...@gmail.com
 
 I am using Gnu Make 3.80 on windows.

That is an old and buggy version of Make.  It has a couple of
Windows-specific bugs fixed in version 3.81 and later.  So I suggest
to use Make 3.82.  (The last version of Make is 4.0, but it is not yet
as stable as 3.82.)

1. Assume the Gnu Make tool depends on the environment variable X,
which is set on installation of the tool. The user does not know this and
has accidently redefined X to another value.

GNU Make does not need any environment variables for its work.

2. Assume the Gnu Make depends on some dlls from the operating system or
other extensions, e.g. service packs or .NET packages. What happens if
these dll files are accidently replaced by other versions. Does the tool
recognize this, e.g. by checking if the correct versions of expected dlls
are present?

GNU Make doesn't depend on any DLLs that can be removed from a Windows
system without rendering that system completely unusable.  There are
no issues with versions of those DLLs, because the same DLLs are used
by the OS itself all the time.

3. Assume that the Gnu Make depends on some entries to the windows
registry, which are set on installation of the tool. The user has installed
other tools, e.g. other versions of the same tool, or done something else,
so that these registry values have changed to other values.

GNU Make does not access or need any registry entries.

4. Assume that somebody has accidently deleted some files from the Gnu
Make installation directory, or the installation has not completed.

GNU Make installation is a single executable (and a couple of
documentation files), so this can hardly happen.

5. Assume that two instances of the Gnu Make are executed on the same
windows session at the same time. Are both instances running completely
independently? Is it possible that both instances write/read data, e.g.
temporary files, to/from the same resource?

Temporary files are written to the temporary directory, but the names
of those files are computed dynamically so as not to conflict with
existing files.

6. Assume the Gnu Make is executed in a situation where the CPU is very
busy with executing other programs. Hence, the execution of the tool gets
interrupted extremely often. Can this situation cause deviations in the
tool’s outputs?

No.  GNU Make is a single-threaded program.

7. Assume the Gnu Make is executed in a situation where the available
RAM becomes lower than specified in the minimal system requirements. Can
this situation cause deviations in the tool’s outputs?

If there's not enough virtual memory for Make to create its data
structures, you will get a fatal error message and Make will abort.
But you need to have extremely memory-tight conditions and/or a very
large build, for this to happen.


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

Re: strange behavior with makefile

[Eli Zaretskii]

 From: Paul Smith psm...@gnu.org
 Date: Mon, 20 Jan 2014 08:17:43 -0500
 Cc: Make-w32@gnu.org
 
 As for why the / instead of \, make is a POSIX tool and it deals
 with / as a directory separator.  The Windows port of make has some
 facilities to read Windows paths instead, but when make constructs a
 pathname (as it does here as a result of vpath) it will always use /
 as the directory separator.
 
 However, almost all Windows commands accept both \ and / as
 directory separators, so usually this is not a problem.

Indeed.  And if some tool does care, just take the argument in quotes,
and it won't.

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

Re: Improving SIGINT handling on Windows.

[Eli Zaretskii]

 From: Troy Runkel troy.run...@mathworks.com
 Date: Mon, 11 Nov 2013 22:35:19 +
 Cc: Troy Runkel troy.run...@mathworks.com
 
 On UNIX, when you send SIGINT or Ctrl-C to a make process using -j, the child 
 processes terminate and the child targets are removed if they exist.

But a child process could catch SIGINT and not terminate until some
time later.

 According to this post, it's the responsibility of the OS to send signals to 
 all the processes in the same process group.  So all processes get the 
 SIGINT, including all instances of make AND all programs make invokes.
 
 http://lists.gnu.org/archive/html/make-w32/2005-08/msg5.html

That post is quite old, and in particular the way GNU Make handles
SIGINT on Windows changed a lot since then.

 On Windows, it appears that SIGINT is not propagated to make child processes 
 by the OS.

This is inaccurate, AFAIK.  See this page on MSDN:

  
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682541%28v=vs.85%29.aspx

which says, inter alia:

  By default, when a console window has the keyboard focus, CTRL+C or
  CTRL+BREAK is treated as a signal (SIGINT or SIGBREAK) and not as
  keyboard input. By default, these signals are passed to all console
  processes that are attached to the console. (Detached processes are
  not affected.)

My reading of this is that not only Make gets the signal, but every
one of its children, grandchildren, etc., provided that: (a) they did
not detach from the console (something that a console process run by
Make will rarely, if ever, do), and (b) that they are console
processes (again, a sure bet).

Of course, the whole issue of console handling by Windows is so
notoriously under-documented that it could very well be that the truth
is something else.  E.g., there could be additional conditions that
are required for the above behavior, which are not necessarily
fulfilled in our case.

 This post indicates that when make receives a SIGINT it waits for all child 
 processes to exit before proceeding.
 
 http://savannah.gnu.org/bugs/?40322

Yes; on Windows as well as on Posix.

 Would it be possible to update make on Windows to behave more like make on 
 UNIX?  I have a use case where 'make -j32' is invoked on 32-core Windows 
 servers.  Occasionally we need to stop the build and update the build area, 
 but it can take some time for the 32+ compilers/linkers/etc. to finish.  The 
 ability to send a SIGINT to the top-level make and have it propagate 
 throughout the process group would be very helpful.
 
 Could something like this be accomplished using Console Process Groups?
 
 http://msdn.microsoft.com/en-us/library/windows/desktop/ms682083(v=vs.85).aspx
 http://stackoverflow.com/questions/1453520/run-arbitrary-subprocesses-on-windows-and-still-terminate-cleanly
 
 Thought I'd ask for your opinions before I investigate further.

I would suggest to start by exploring what exactly keeps your 32+
compilers and linkers from stopping right away, or describing those
details if you already investigated that and reached some conclusions.
My experience (with far fewer compilers, but 5 to 10 are common) is
that they all stop, unless the program being run by Make catches
SIGINT -- but then the same will happen on Unix.

Please also note that a Ctrl-C signal cannot be sent to a process
group using GenerateConsoleCtrlEvent (according to MSDN
documentation), but only to all the processes attached to a console,
something that just pressing Ctrl-C on that console already does (or
so I understand).

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

Re: Building Make from git without guile fail.

[Eli Zaretskii]

 Date: Wed, 23 Oct 2013 11:01:02 +0400
 From: Alexey Pavlov alex...@gmail.com
 
 Building latest MAKE from git with BAT file fail with
 
 C:\Test\nativesrc\mingw-builds\make32gcc -mthreads -gdwarf-2 -g3 -o
 gnumake.exe variable.o rule.o remote-stub.o commands.o file.o
 getloadavg.o default.o signame.o expand.o dir.o main.o getopt1.o
 job.o output.o read.o version.o getopt.o arscan.o remake.o misc.o
 hash.o strcache.o ar.o function.o vpath.o implicit.o loadapi.o load.o
 glob.o fnmatch.o pathstuff.o posixfcn.o w32_misc.o sub_proc.o w32err.o
  -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32
 -lshell32 -lole32 -loleaut32 -luuid -lodbc32 -lodbccp32
 -Wl,--out-implib=libgnumake-1.dll.a
 main.o: In function `main':
 C:\Test\nativesrc\mingw-builds\make32/main.c:1293: undefined reference
 to `guile_gmake_setup'
 collect2.exe: error: ld returned 1 exit status

Right.  Paul changed the arrangements with compiling guile.c, but
build_w32.bat didn't get the corresponding update.

 Full build log in attach.

 $ cmd /c 'build_w32.bat gcc'
 
 sed: -e expression #4, char 7: unterminated `s' command
 ‘ª®¯¨à®¢ ­® ä ©«®¢: 1.

What is this Sed error about?  It doesn't happen to me.

 My proposed patch for it in attach.

Thanks, I fixed it slightly differently, and also took care of the
MSVC build.  In addition, makeint.h needed a change to avoid this
compiler warning when building without Guile:

  C:\Test\nativesrc\mingw-builds\make32gcc -mthreads -Wall -gdwarf-2 -g3 -O2 
-I. -I./glob -I./w32/include -DWINDOWS32 -DHAVE_CONFIG_H  -c main.c 
  main.c: In function 'main':
  main.c:1293:3: warning: implicit declaration of function 'guile_gmake_setup' 
[-Wimplicit-function-declaration]
 guile_gmake_setup (NILF);
 ^
  
Please try the latest git.

Thanks.


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

Re: Building Make from git without guile fail.

[Eli Zaretskii]

 Date: Wed, 23 Oct 2013 21:20:06 +0400
 From: Alexey Pavlov alex...@gmail.com
 Cc: make-w32@gnu.org
 
  sed: -e expression #4, char 7: unterminated `s' command
  Скопировано файлов: 1.
 
  What is this Sed error about?  It doesn't happen to me.
 
 This error in highlighted peace
 
 sed -e s/;.*// -e /^[ \t]*$/d -e s/\/\/g -e s/$/ \\/ 
 gmk-default.scm  gmk-default.h
  ^^

What's wrong with that part?  Which port of Sed are you using?  If
it's an MSYS port, perhaps try a native/MinGW port.

  Please try the latest git.
 
 Build fine.

Thanks for testing.


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

Re: Mingw MAKE with configure script

[Eli Zaretskii]

 Date: Wed, 23 Oct 2013 23:14:20 +0400
 From: Alexey Pavlov alex...@gmail.com
 
 Building mingw32-make under msys using configure script lead to non-working
 MAKE.

I'm not surprised: this method of building a MinGW Make is not
currently supported, and never was.  The only way to build a MinGW
Make that is officially supported is build_w32.bat.

If someone sends patches to fix the Posix configury to support the
MinGW build, I will review them and either recommend them for
inclusion, or provide feedback how to modify them to be suitable for
inclusion.

TIA

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

Re: Windows patches for the next release

[Eli Zaretskii]

 From: Paul Smith psm...@gnu.org
 Cc: Denis Excoffier cyg...@denis-excoffier.org,
  bug-...@denis-excoffier.org,  pavel_fe...@mail.ru, make-w32@gnu.org
 Date: Sat, 05 Oct 2013 20:05:03 -0400
 
   However, output-sync, recursion, MAKE remain.  Included work.tar.xz
  
  All of those failures are because of the exact form of $(MAKE).  What
  Cygwin produces is functionally equivalent to what the test suite
  expects, so I think we can consider these failures redundant, if not
  bogus.  (If Paul accepts your patch to the suite, they will be gone
  altogether.)
 
 Personally I think this is a real bug.  Make should try to use the
 fully-qualified pathname when it sets the MAKE variable, which is why
 the test suite prefixes the filename with the current working directory
 if the path is determined to be relative.
 
 If MAKE is set to a relative pathname, then it will fail in recursion
 when the directory is changed, since $(MAKE) will no longer be a valid
 path.
 
 Won't it?

Once again, I think this is the issue with . being on PATH, which is
always the case on Windows.  If you add . to PATH, Posix Make fails
as well.

We need a general solution here.

OTOH, since I cannot build and debug the Cygwin port, perhaps I'm
missing something here.  It would be nice if someone who actually uses
Cygwin could run Make under a debugger in these cases, and see why you
get ../make instead of an absolute file name.

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

Re: Windows patches for the next release

[Eli Zaretskii]

 Date: Fri, 4 Oct 2013 01:06:58 -0400
 From: Christopher Faylor cgf-use-the-mailinglist-ple...@gnu.org
 
  I'm not sure it's correct to consider \a to be an absolute path in the
  same way that /a is since they mean different things to Cygwin but I
  guess that's not something that I have to worry about.
 
 I thought about that as well.  I actually think that Cygwin should not
 consider a backslash as a directory separator, even if HAVE_DOS_PATHS
 is defined.  What do you think?
 
 Hmm.  I'm not sure.  It wouldn't bother me but there may be people who
 want to be able to use backslashes.

I just think that a backslash will fail to do what the users expect,
certainly if the recipe's commands are invoked via the shell.

Would asking on the Cygwin list help understanding whether users will
object to such a change?

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

Re: Windows patches for the next release

[Eli Zaretskii]

 Date: Thu, 3 Oct 2013 01:23:15 -0400
 From: Christopher Faylor cgf-use-the-mailinglist-ple...@gnu.org
 
 @@ -2001,13 +2005,17 @@ abspath (const char *name, char *apath)
  }
else
  {
 +#ifdef __CYGWIN__
 +  if (STOP_SET (name[0], MAP_PATHSEP))
 +root_len = 1;
 +#endif
 
 I've eyeballed the patch even though I won't be releasing a version of
 make which has this turned on.
 
 I think the above unnecessary if HAVE_DOS_PATHS is true and should be
 
 #if defined(__CYGWIN__)  defined(HAVE_DOS_PATHS)

You are right, I pushed a fix.

 I'm not sure it's correct to consider \a to be an absolute path in the
 same way that /a is since they mean different things to Cygwin but I
 guess that's not something that I have to worry about.

I thought about that as well.  I actually think that Cygwin should not
consider a backslash as a directory separator, even if HAVE_DOS_PATHS
is defined.  What do you think?

Anyway, such a change modifies behavior (under HAVE_DOS_PATHS), and
its prerequisite is to use STOP_SET everywhere in Make.  So I think I
will make that change after the release (unless you, or someone else
object).

Thanks.

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

Re: Windows patches for the next release

[Eli Zaretskii]

 Date: Wed, 02 Oct 2013 19:17:58 +0300
 From: Eli Zaretskii e...@gnu.org
 Cc: make-w32@gnu.org, bug-...@denis-excoffier.org, pavel_fe...@mail.ru
 
  Date: Wed, 02 Oct 2013 09:34:06 +0200
  From: Denis Excoffier cyg...@denis-excoffier.org
  Cc: psm...@gnu.org, bug-...@denis-excoffier.org, pavel_fe...@mail.ru,
   make-w32@gnu.org
  
  The abspath error is gone.
 
 Thanks for testing, I will commit the changes soon.

Done.

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

Re: Make 3.99.91/92 - Output-Synchronization fails with UAC or Non-Admins (under Windows)

[Eli Zaretskii]

 Date: Tue, 24 Sep 2013 07:34:44 +0200
 From: Markus Eisenmann ibiatiro...@gmail.com
 
 Thank you for your answer!
 
 I will test ist maybe tomorrow (not enough time today).

I hope you did get to testing this.  I committed the changes to the
git repo.

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

Re: Windows patches for the next release

[Eli Zaretskii]

 From: Paul Smith psm...@gnu.org
 Cc: bug-...@denis-excoffier.org, pavel_fe...@mail.ru, make-w32@gnu.org
 Date: Tue, 01 Oct 2013 01:08:32 -0400
 
 On Mon, 2013-09-30 at 18:15 +0300, Eli Zaretskii wrote:
  I suggest another RC, I think the changes since the last one are
  non-trivial.
 
 OK, I created a new RC, available now on make-alpha.

Thanks.  It still builds fine on Windows using MinGW GCC.

 I don't personally plan to make any more changes, so as soon as you feel
 you're happy with the Windows support I will release.

Here's the patch for $abspath that should fix the Cygwin build.  Would
Cygwin people please test it, and in particular see if the related
failures in the test suite are gone?  I don't have a Cygwin
environment to even compile with Cygwin.

I'd especially appreciate if Chris could at least eyeball the patch.

Thanks in advance.

Btw, Paul: I see that the sources don't consistently use STOP_SET
where characters are tested for being directory separators; sometimes
they actually test for both slashes and backslashes.  Should we fix
that throughout the sources?

===

--- function.c~02013-09-30 07:12:36.0 +0300
+++ function.c  2013-10-01 19:48:45.47200 +0300
@@ -1949,8 +1949,12 @@ func_not (char *o, char **argv, char *fu
 
 
 #ifdef HAVE_DOS_PATHS
-#define IS_ABSOLUTE(n) (n[0]  n[1] == ':')
-#define ROOT_LEN 3
+# ifdef __CYGWIN__
+#  define IS_ABSOLUTE(n) ((n[0]  n[1] == ':') || STOP_SET (n[0], 
MAP_PATHSEP))
+# else
+#  define IS_ABSOLUTE(n) (n[0]  n[1] == ':')
+# endif
+# define ROOT_LEN 3
 #else
 #define IS_ABSOLUTE(n) (n[0] == '/')
 #define ROOT_LEN 1
@@ -2001,13 +2005,17 @@ abspath (const char *name, char *apath)
 }
   else
 {
+#ifdef __CYGWIN__
+  if (STOP_SET (name[0], MAP_PATHSEP))
+   root_len = 1;
+#endif
   strncpy (apath, name, root_len);
   apath[root_len] = '\0';
   dest = apath + root_len;
   /* Get past the root, since we already copied it.  */
   name += root_len;
 #ifdef HAVE_DOS_PATHS
-  if (! STOP_SET (apath[2], MAP_PATHSEP))
+  if (! STOP_SET (apath[root_len - 1], MAP_PATHSEP))
 {
   /* Convert d:foo into d:./foo and increase root_len.  */
   apath[2] = '.';
@@ -2018,7 +2026,7 @@ abspath (const char *name, char *apath)
   name--;
 }
   else
-apath[2] = '/'; /* make sure it's a forward slash */
+apath[root_len - 1] = '/'; /* make sure it's a forward slash */
 #endif
 }
 

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

Re: Windows patches for the next release

[Eli Zaretskii]

 From: Paul Smith psm...@gnu.org
 Cc: Denis Excoffier bug-...@denis-excoffier.org, Pavel Fedin
  pavel_fe...@mail.ru, Chris Faylor
  cgf-use-the-mailinglist-ple...@gnu.org,  make-w32@gnu.org
 Date: Mon, 30 Sep 2013 08:47:39 -0400
 
 abspath / DOS paths fix

I posted a patch for this.  Let's hope some Cygwin user will be able
to test it soon.

 Also, from Savannah:
 
 https://savannah.gnu.org/bugs/index.php?30323
 Not sure what the final word on this one is.

I analyzed that and posted a comment.  Bottom line is that the Windows
build behaves exactly like a Posix build, when the Make executable is
found in the current directory via PATH.

 https://savannah.gnu.org/bugs/index.php?15718
 Don't know if this is fixed, but probably too much for this release.

Whatever is left is minor and doesn't merit waiting for.

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

Re: Windows patches for the next release

[Eli Zaretskii]

 From: Paul Smith psm...@gnu.org
 Cc: bug-...@denis-excoffier.org, pavel_fe...@mail.ru, make-w32@gnu.org
 Date: Tue, 01 Oct 2013 13:37:36 -0400
 
 On Tue, 2013-10-01 at 19:52 +0300, Eli Zaretskii wrote:
  Btw, Paul: I see that the sources don't consistently use STOP_SET
  where characters are tested for being directory separators; sometimes
  they actually test for both slashes and backslashes.  Should we fix
  that throughout the sources?
 
 STOP_SET() is basically a performance improvement.  It would be fine to
 use it in more places, but I don't want to change things at this point
 unless we are very confident they won't introduce any brown paper bag
 bugs for the 4.0 release :-).  So if you're confident, go ahead.
 
 Otherwise we can wait for a followup release.

I'm confident, but it's not important enough to have even a small
risk at this point.

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

Re: Windows patches for the next release

[Eli Zaretskii]

 From: Paul Smith psm...@gnu.org
 Cc: Denis Excoffier bug-...@denis-excoffier.org, Pavel Fedin
  pavel_fe...@mail.ru, Chris Faylor
  cgf-use-the-mailinglist-ple...@gnu.org,  make-w32@gnu.org
 Date: Mon, 30 Sep 2013 08:47:39 -0400
 
 There are some decisions to be made on outstanding Windows patches.
 Other than these I believe the next release is ready to go... not
 everything is fixed but at some point you have to pull the trigger.  I'm
 willing to apply the ones that are appropriate, but need some guidance
 from Eli.  Also, do you need another release tarball for testing, or is
 Git good enough?

I suggest another RC, I think the changes since the last one are
non-trivial.

 Things that I know of:
 
 Spawn patch: at this point I think we'll have to leave this one out; it
 can continue to be applied as an external patch for now by those who
 want it and we can try to get an official patch for the next release.

I agree.

 abspath / DOS paths fix

I'd like to fix this one, it should be easy.

 Also, from Savannah:
 
 https://savannah.gnu.org/bugs/index.php?30323
 Not sure what the final word on this one is.
 
 https://savannah.gnu.org/bugs/index.php?15718
 Don't know if this is fixed, but probably too much for this release.

I'll take a look soon.

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

Re: Make 3.99.91/92 - Output-Synchronization fails with UAC or Non-Admins (under Windows)

[Eli Zaretskii]

 Date: Mon, 23 Sep 2013 16:21:30 +0200
 From: Markus Eisenmann ibiatiro...@gmail.com
 
 I have built a windows-make version of the release-canditate versions
 3.99.91 and 3.99.92,
 using Visual Studio and MinGW. The result, I.e. make fails if I'm using
 parallel builds and the feature  'output-synchronization' with an error
 like 'could not create tmpfile'.
 
 After spending some time for debugging, I have detected the problem:
 - A temporary file is used to buffer the outputs (of course)
 - this file is created with calling 'tmpfile()'.
 
 As written in
 http://msdn.microsoft.com/en-us/library/x8x7sakw%28v=vs.90%29.aspx,
 tmpfile() does create a temporary file in the root directory; But in many
 cases - e.g. inhibited by NTFS-security or if UAC is active - a creation of
 files in the root-directory is forbidden.

I don't think this has anything to do with UAC, it's just that the
root of a system disk is write-protected from casual writes.  How
silly of Microsoft not to do something about this on Windows 7 and
later!

 IMHO, I think, this type of temporary files should be created like other
 needed temporary (batch-) files in the TMP/TEMP-folder (using the
 associated environment variable).

I agree.  Can you please test with the following patch?  I'm also
testing it; if it will give good results, I will commit it to the
repository.

Thanks.

--- output.c~0  2013-09-23 00:10:34.0 +0300
+++ output.c2013-09-23 22:58:51.963375000 +0300
@@ -72,6 +72,103 @@ msc_vsnprintf (char *str, size_t size, c
 }
 #endif
 
+#ifdef WINDOWS32
+/* A replacement for tmpfile, since the MSVCRT implementation creates
+   the file in the root directory of the current drive, which might
+   not be writable by our user.  Most of the code borrowed from
+   create_batch_file, see job.c.  */
+FILE *
+tmpfile (void)
+{
+  char temp_path[MAXPATHLEN];
+  unsigned path_size = GetTempPath (sizeof temp_path, temp_path);
+  int path_is_dot = 0;
+  /* The following variable is static so we won't try to reuse a name
+ that was generated a little while ago, because that file might
+ not be on disk yet, since we use FILE_ATTRIBUTE_TEMPORARY below,
+ which tells the OS it doesn't need to flush the cache to disk.
+ If the file is not yet on disk, we might think the name is
+ available, while it really isn't.  This happens in parallel
+ builds, where Make doesn't wait for one job to finish before it
+ launches the next one.  */
+  static unsigned uniq = 0;
+  static int second_loop = 0;
+  const char base[] = make_tmpf;
+  const unsigned sizemax = sizeof base - 1 + 4 + 10 + 10;
+  unsigned pid = GetCurrentProcessId ();
+
+  if (path_size == 0)
+{
+  path_size = GetCurrentDirectory (sizeof temp_path, temp_path);
+  path_is_dot = 1;
+}
+
+  ++uniq;
+  if (uniq = 0x1  !second_loop)
+{
+  /* If we already had 64K batch files in this
+ process, make a second loop through the numbers,
+ looking for free slots, i.e. files that were
+ deleted in the meantime.  */
+  second_loop = 1;
+  uniq = 1;
+}
+  while (path_size  0 
+ path_size + sizemax  sizeof temp_path 
+ !(uniq = 0x1  second_loop))
+{
+  sprintf (temp_path + path_size,
+  %s%s%u-%x.tmp,
+  temp_path[path_size - 1] == '\\' ?  : \\,
+  base, pid, uniq);
+  /* O_CREAT | O_EXCL | O_RDWR | O_BINARY | O_TEMPORARY
+SH_DENYNO */
+  HANDLE h = CreateFile (temp_path,  /* file name */
+ GENERIC_READ | GENERIC_WRITE | DELETE, /* desired 
access */
+ 0,/* no share mode */
+ NULL, /* default security 
attributes */
+ CREATE_NEW,   /* creation 
disposition */
+ FILE_ATTRIBUTE_NORMAL |   /* flags and 
attributes */
+ FILE_ATTRIBUTE_TEMPORARY |
+FILE_FLAG_DELETE_ON_CLOSE,
+ NULL);/* no template file 
*/
+
+  if (h == INVALID_HANDLE_VALUE)
+{
+  const DWORD er = GetLastError ();
+
+  if (er == ERROR_FILE_EXISTS || er == ERROR_ALREADY_EXISTS)
+{
+  ++uniq;
+  if (uniq == 0x1  !second_loop)
+{
+  second_loop = 1;
+  uniq = 1;
+}
+}
+
+  /* the temporary path is not guaranteed to exist */
+  else if (path_is_dot == 0)
+{
+  path_size = GetCurrentDirectory (sizeof temp_path, temp_path);
+  path_is_dot = 1;
+}
+
+  else
+   break;
+}
+  else
+{
+  int fd = _open_osfhandle ((intptr_t)h, 0);
+
+  return _fdopen (fd, w+b);
+}
+}
+
+  return NULL;
+}
+#endif
+
 

Re: Make 3.99.91/92 - Output-Synchronization fails with UAC or Non-Admins (under Windows)

[Eli Zaretskii]

 From: Paul Smith psm...@gnu.org
 Cc: Markus Eisenmann ibiatiro...@gmail.com, make-w32@gnu.org
 Date: Mon, 23 Sep 2013 16:38:36 -0400
 
 On Mon, 2013-09-23 at 23:04 +0300, Eli Zaretskii wrote:
   IMHO, I think, this type of temporary files should be created like
  other
   needed temporary (batch-) files in the TMP/TEMP-folder (using the
   associated environment variable).
  
  I agree.  Can you please test with the following patch?  I'm also
  testing it; if it will give good results, I will commit it to the
  repository.
 
 I wonder if this new tmpfile() would be better added to a source file in
 the w32 subdirectory somewhere, rather than ifdef'ing it into output.c?

Sure, can do.

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

Re: sync_Path_environment issue

[Eli Zaretskii]

 Date: Tue, 21 May 2013 09:02:57 -0400
 From: LM lme...@gmail.com
 
 I'm trying to build make 3.82 using MinGW (32 bit) in an msys environment.
 When I test the results out by attempting to rebuild autoconf with this
 version of make  ^^
  ^^^

This is your problem, right there: The MinGW Make is not supposed to
run in the MSYS environment.  Use the MSYS provided Make instead.
Even if this problem is somehow solved, you will hit others further
down the road.  The main problem is that the MSYS Bash wants to see
and outputs /d/foo/bar file names that the MinGW Make does not
understand.

The _only_ sane way to build packages under MSYS is to use the MSYS
Make.

 The line that's causing the trouble for make is:
 export PATH = $(shell echo `pwd`/tests:$$PATH)
 
 It's not that there are two instances of PATH in the command.  I can change
 the second PATH to any variable name I want and I still get the error.  I
 can change PATH = to PATH := and I don't get the error.

I actually wonder why Autoconf doesn't use := to begin with.  It is
the right way.

 It looks like when make sees PATH =, it assumes it's working with a
 variable it needs to expand (with f_recursive not f_simple).  To get
 the rest of the variable, it tries to call the shell and run the
 echo command.  For Windows only, before calling CreateProcess to run
 anything (such as the shell command), there's a call to
 sync_Path_environment.

That call is required, because the normal environment used by the C
runtime library is separate from the environment block used by
CreateProcess.  That call synchronizes them.  Without it, we will have
much more serious problems.

 Not sure of the best fix for this.

If you find a fix that doesn't remove the call to
sync_Path_environment, I will review it and see if it can be
accepted.  But please note that you are trying to solve a problem you
shouldn't bump into in the first place.  Just use MSYS Make.

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

Re: Build GNUMake from git with mingw-w64

[Eli Zaretskii]

[Why a personal email?]

 Date: Sat, 18 May 2013 08:50:24 +0400
 From: Алексей Павлов alex...@gmail.com
 
 If I manually add #define OUTPUT_SYNC to my config.h I have another error:
 
 mv -f .deps/getloadavg.Tpo .deps/getloadavg.Po
 gcc  -Wall -Wextra -Wdeclaration-after-statement -Wshadow
 -Wpointer-arith -Wbad-function-cast -g -O2   -o make.exe ar.o arscan.o
 commands.o  default.o dir.o expand.o  file.o function.o getopt.o
 getopt1.o implicit.o job.o  load.o loadapi.o main.o misc.o  read.o
 remake.o rule.o  signame.o strcache.o variable.o  version.o vpath.o
 hash.o  remote-stub.o  getloadavg.o  glob/libglob.a
   -Lw32 -lw32
 job.o: In function `acquire_semaphore':
 c:\test\nativesrc\mmake/../make_git/job.c:740: undefined reference to `fcntl'

That's because the configure script was not updated to compile the
added file w32/compat/posixfcn.c.  Patches are welcome.

The latest git should compile for you without OUTPUT_SYNC defined, so
that is another option.

Once again: I suggest to use the build_w32.bat script for building a
MinGW Make.  That script is currently the only officially supported
way of building the Windows port of Make, and it works out of git as
well.  It defines OUTPUT_SYNC automatically, and compiles all the
source files needed for that.


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

Re: Build GNUMake from git with mingw-w64

[Eli Zaretskii]

 Date: Sat, 18 May 2013 18:48:05 +0400
 From: Алексей Павлов alex...@gmail.com
 Cc: make-w32@gnu.org
 
 My patch for fix issue:

Thanks, I pushed that.

Would you also mind adding the necessary stuff to produce the
libgnumake import library?  All it needs is to add this to the final
link command:

  -Wl,--out-implib=libgnumake-1.dll.a

TIA


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

Re: Build GNUMake from git with mingw-w64

[Eli Zaretskii]

 Date: Fri, 17 May 2013 15:45:14 +0400
 From: Алексей Павлов alex...@gmail.com
 
 I have troubles with building Make from git with mingw-w64 compiler. I has
 error:
 
 mv -f .deps/loadapi.Tpo .deps/loadapi.Po
 gcc -DLOCALEDIR=\/usr/local/share/locale\ -DLIBDIR=\/usr/local/lib\
 -DINCLUDEDIR=\/usr/local/include\ -DHAVE_CONFIG_H -I.
 -I../make_git  -I../make_git/glob -I ../make_git/w32/include
 -DMAKE_MAINTAINER_MODE-Wall -Wextra -Wdeclaration-after-statement
 -Wshadow -Wpointer-arith -Wbad-function-cast -g -O2 -MT main.o -MD -MP -MF
 .deps/main.Tpo -c -o main.o ../make_git/main.c
 ../make_git/main.c: In function 'decode_output_sync_flags':
 ../make_git/main.c:749:7: warning: implicit declaration of function
 'RECORD_SYNC_MUTEX' [-Wimplicit-function-declaration]
 ../make_git/main.c: At top level:
 ../make_git/main.c:760:30: error: unknown type name 'sync_handle_t'

'sync_handle_t' is defined in job.h, which is included by main.c.  Are
OUTPUT_SYNC_ and WINDOWS32 defined in your config.h?

Btw: you seem to be using the configure script, instead of the
build_w32.bat batch file.  If so, please be advised that this build
procedure will not produce the libgnumake-1.dll.a import library that
is required to build GNU Make dynamic extensions.  Patches to add that
are welcome.


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

Re: Any known problems with relative paths in VPATH on Windows?

[Eli Zaretskii]

 Date: Mon, 6 May 2013 21:55:11 +0200
 From: Erik Carstensen mandolae...@gmail.com
 Cc: Duane Campbell dcampb...@nvidia.com, make-w32@gnu.org
 
 On Mon, May 6, 2013 at 9:48 PM, Eli Zaretskii e...@gnu.org wrote:
 
 
  Maybe c:\very-long-src-dir\..\very-long-build-dir together exceeded
  260 characters?
 
 
 No, make can find 'c:\very-long-src-dir\..\very-long-build-dir\a', but not
 'c:\very-long-src-dir\..\very-long-build-dir\very-long-filename'.

I looked into this.  It's Windows after all, not Make.  Once
'c:\very-long-src-dir\..\very-long-build-dir\very-long-filename'
becomes longer than 260 characters, every file-related library
function I tried fails, even though normalizing the file name would
give something well within the 260-char limits.  The functions that
fail and cause Make think the file is not anywhere along VPATH are
'stat' and/or 'opendir', and also '_fullpath' that is called in
between.

I guess some file-name normalization routine called by these has a
bug, like too small buffer or maybe an explicit test for the length of
the string applied before the normalization is attempted.

 On the symptoms, it seems that the problem in my case would be solved by
 normalizing (collapsing ..) earlier, but I'm not sure it's feasible to do
 so (and it just gives us a few more characters to play with).

The easiest way around the problem is this:

  VPATH = $(abspath ..\very-long-build-dir);$(abspath ..\yet-another-one)

etc.

Given that too many library functions fail with such names, I find it
impractical to work around this problem inside Make, because the fix
would have to be in too many places, while the workaround in the
Makefile, as shown above, is very simple.

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

Re: Incorrect quoting of in master branch, with SHELL=cmd.exe

[Eli Zaretskii]

 Date: Mon, 6 May 2013 22:26:14 +0200
 From: Erik Carstensen mandolae...@gmail.com
 Cc: make-w32@gnu.org
 
  why not use this instead:
 
  SHELL=cmd.exe
  default:
  $(MAKE) -f foo.mk x=a b
 
 
 The problem is that foo.mk will use $(x) directly in shell invocations.

Then you can quote $(x) inside foo.mk, as in $(x).

 Furthermore, foo.mk is provided by the user, and I don't want to ask my
 users to worry about quoting.

Well, quoting something that might include whitespace is natural.

 But these details are not so relevant, as \ indeed would solve this use
 case.

Right.

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

Re: With SHELL=cmd, make fails to execute bat file paths starting with ../

[Eli Zaretskii]

 From: Duane Campbell dcampb...@nvidia.com
 CC: make-w32@gnu.org make-w32@gnu.org, Duane Campbell
   dcampb...@nvidia.com
 Date: Fri, 3 May 2013 16:21:23 -0700
 
 I think gnu-make users need to be responsible for quoting (and proper 
 slashes) for the cmd.exe shell.

I couldn't agree more.  Make cannot fix something the shell doesn't
accept on its command line.  Make can only be required not to ruin
something a shell will accept.

 Here are some problems with proposal for special handling of argv[0] ending 
 .bat (or .cmd which is an alternate extension for batchfiles).
 - What should make do if argv[0] is foo (foo could be a .bat file, a .exe 
 (or any other registered type))
 - When argv[0] is foo.bat it might actually be an executable that runs 
 (foo.bat.exe).

If you are talking about the special handling of batch files with
whitespace in their names, then these two problems do not exist with
the current implementation.  That's because the decision whether the
special handling should be in effect is made _after_ Make already
searched and found argv[0], and determined its full absolute file
name, including the extension.  In addition to cleanly solving the
difficulties you mention, this solution has the benefit of doing TRT
with batch files which have whitespace characters in their leading
directories, not in their basenames.

(And yes, both .bat and .cmd batch files get this special handling.)

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

Re: Incorrect quoting of in master branch, with SHELL=cmd.exe

[Eli Zaretskii]

 Date: Fri, 3 May 2013 17:17:20 +0200
 From: Erik Carstensen mandolae...@gmail.com
 
 When passing   to a shell, it is evaluated to a single word   if
 cmd.exe evaluates it, but  to an unquoted single space if make
 short-circuits the cmd.exe argument.

You should use a backslash to produce a literal quote that should be
passed to a program.  That's what the Microsoft startup code provides
as the way to get quote characters into programs.

Unfortunately, cmd.exe does not support such escaping, so Make needs
to choose which method to support, and it naturally leans towards
programs rather than towards cmd.exe itself, because the commands that
need the shell or explicit batch files are the minority.

If you do know that cmd.exe will be invoked, you can either double the
quotes, as the cmd.exe documentation describes, or us the ^ character
to escape the quotes.

 My actual use case is similar to the 'mkdir' invocation in foo.mk (a file
 with spaces needs to be quoted twice in order to be passed to commands in a
 recursive make).

Please show that use case, or something similar.  I don't immediately
understand why recursive invocation means you'd need to quote a file
name twice.  E.g., why not use this instead:

SHELL=cmd.exe
default:
$(MAKE) -f foo.mk x=a b


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

Re: Bug: make fails to execute .BAT files with space in the path, with SHELL=cmd.exe

[Eli Zaretskii]

 Date: Thu, 2 May 2013 10:26:50 +0200
 From: Erik Carstensen mandolae...@gmail.com
 Cc: make-w32@gnu.org
 
 I think this fix deserves an item in NEWS.

Yes, I already did that.

 The change breaks makefiles like
 this one (succeeds with 3.82, fails with master):
 
 SHELL=cmd.exe
 X=C:\Program\ Files
 default: $(X)
ls.exe $(X)

Make on Windows cannot support escaping with backslash when the shell
is cmd.exe.  And Make in general doesn't support file names with
whitespace too well, you need to introduce blanks via variables, for
it to work reliably.  The only place where it works well is in the
command line itself, but not in variables and certainly not in
dependency lists.

 It does not! With the following makefile:
 
 SHELL=cmd.exe
 default:
 a b\x.bat
 
 I get this most of the time:
 make/gnumake.exe --debug=j
 a b\x.bat
 CreateProcess(NULL,C:\cygwin\tmp\a b\x.bat,...)
 (and make exits with code 127)
 
 Sometimes (1 in 5), the bat file is actually executed before make exits
 with 127.

That's strange, I cannot reproduce this.  I get 100% success and zero
exit code all the time.

 The machine runs Windows 7 Enterprise.

I tried both on Windows 7 and on XP SP3 here, and it works on both for
me.  I build Make with MinGW32, while yours is a 64-bit build AFAIU,
so maybe this could explain that -- perhaps there's some quirk in
64-bit executables.  Or maybe it's something specific to your system.
Can you test on another box?

It is also strange that it sometimes works.  Perhaps there's some
subtle Heisenbug, but I cannot debug something I cannot reproduce.
And the command you should under --debug=j looks correct to me.

If you can run Make under a debugger and look what's going on there,
I'd appreciate.

 I don't like calling CreateProcess with NULL as the first parameter - it will
 actually first look for cmd.exe in cwd, with interesting results.

You mean, if there's (an incompatible) cmd.exe in the current
directory?  Why else would that be interesting?  Windows always
looks in cwd for a program, that's nothing new.

 Using COMSPEC directly is more likely to be correct. The
 CreateProcess documentation suggests:
 
   To run a batch file, you must start the command interpreter; set
   lpApplicationName to cmd.exe and set lpCommandLine to the following
   arguments: /c plus the name of the batch file.
 
 Unfortunately this says nothing at all about how to quote the batch file name
 and its arguments.

Exactly!  And that's why this way is impractical.  Even CreateProcess
itself manages to trigger some bugs related with excess quoting of
cmd.exe commands -- do you really think someone like me, who is not a
Microsoft employee, can do that better?

 This means that the right way to run a batch file with multiple arguments is 
 to
 run cmd.exe with the command line
 
   /c batch_file arg1 arg2 ...
 
 where any or all of batch_file and the arguments may be quoted in turn, such 
 as
 
   /c my file.bat one arg another arg
 
 since the outermost quotes are stripped away. This seems to be what
 CreateProcess does when given a NULL first argument, although it also adds a
 dummy cmd before the /c. This can be seen quite clearly in Process Monitor.

You forget the use cases where you need to pass quotes into the
programs invoked by the batch files.  That complicates things quite a
bit.  And we already know that the above won't work anyway: it's the
original reason of the problem that you reported.  Going there means
going back; I don't want to do that.  Using NULL fixed the problem
entirely in my testing.  I hope you could find why it fails for you,
perhaps there's some other more subtle problem.

Anyway, I think I will install that patch soon, because I cannot see
anything wrong with it.

Thanks.

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

Re: Bug: make fails to execute .BAT files with space in the path, with SHELL=cmd.exe

[Eli Zaretskii]

 Date: Thu, 02 May 2013 19:50:25 +0300
 From: Eli Zaretskii e...@gnu.org
 Cc: make-w32@gnu.org
 
  SHELL=cmd.exe
  default:
  a b\x.bat
  
  I get this most of the time:
  make/gnumake.exe --debug=j
  a b\x.bat
  CreateProcess(NULL,C:\cygwin\tmp\a b\x.bat,...)
  (and make exits with code 127)
  
  Sometimes (1 in 5), the bat file is actually executed before make exits
  with 127.
 
 That's strange, I cannot reproduce this.  I get 100% success and zero
 exit code all the time.

I did succeed in reproducing this.  Stay tuned.

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

Re: Bug: make fails to execute .BAT files with space in the path, with SHELL=cmd.exe

[Eli Zaretskii]

 Date: Thu, 2 May 2013 14:16:19 +0200
 From: Erik Carstensen mandolae...@gmail.com
 Cc: make-w32@gnu.org
 
 So I assume then that make is expected to use the same quoting rules as CMD
 when short-circuiting the shell.

Yes.  But not because of that change: you always were supposed to do
that.

 Then there is another bug: make's arg quoting has some special
 treatment for single quotes, whereas cmd.exe itself hasn't. So, in
 
 SHELL=cmd.exe
 default:
 'a b\x.bat'
 'a b\x.bat' NUL
 
 The first invocation of x.bat works, while the second one won't (''a' is
 not recognized as...)

It's not a bug: cmd.exe doesn't know about '..' quoting, so this
command is not supposed to work.  That it does without redirection is
sheer luck.

I don't want to rock the boat any further in this regard before the
next release of Make, so I don't want to forcibly disable '..' quoting
support when cmd.exe is used.  Make worked like that forever; I think
one incompatible change per release is more than enough ;-)

 This is not a problem for my use case, but it did add to my confusion when
 doing experiments.

Thanks.  The NEWS entry I added does mention that some
incompatibilities in borderline cases could be caused by that change.
I guess this is one of them.

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

Re: Bug: make fails to execute .BAT files with space in the path, with SHELL=cmd.exe

[Eli Zaretskii]

 Date: Thu, 02 May 2013 20:04:30 +0300
 From: Eli Zaretskii e...@gnu.org
 Cc: make-w32@gnu.org
 
  Date: Thu, 02 May 2013 19:50:25 +0300
  From: Eli Zaretskii e...@gnu.org
  Cc: make-w32@gnu.org
  
   SHELL=cmd.exe
   default:
   a b\x.bat
   
   I get this most of the time:
   make/gnumake.exe --debug=j
   a b\x.bat
   CreateProcess(NULL,C:\cygwin\tmp\a b\x.bat,...)
   (and make exits with code 127)
   
   Sometimes (1 in 5), the bat file is actually executed before make exits
   with 127.
  
  That's strange, I cannot reproduce this.  I get 100% success and zero
  exit code all the time.
 
 I did succeed in reproducing this.  Stay tuned.

It was a stupid thinko on my part.  Sorry.  Please apply the patch
below on top of the previous one:


--- w32/subproc/sub_proc.c~02013-05-02 19:53:47.39100 +0300
+++ w32/subproc/sub_proc.c  2013-05-02 20:36:54.437875000 +0300
@@ -28,13 +28,13 @@ this program.  If not, see http://www.g
 #include signal.h
 #include windows.h
 
+#include makeint.h
 #include sub_proc.h
 #include proc.h
 #include w32err.h
 #include debug.h
 
 static char *make_command_line(char *shell_name, char *exec_path, char **argv);
-extern char *xmalloc (unsigned int);
 
 typedef struct sub_process_t {
intptr_t sv_stdin[2];
@@ -690,7 +690,8 @@ process_begin(
 batch_file_with_spaces(exec_fname)
 _stricmp(exec_path, argv[0]) == 0) {
pass_null_exec_path = 1;
-   argv[0] = exec_fname;
+   free (argv[0]);
+   argv[0] = xstrdup(exec_fname);
}
command_line = make_command_line( shell_name, exec_fname, argv);
}

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

Re: Bug: make fails to execute .BAT files with space in the path, with SHELL=cmd.exe

[Eli Zaretskii]

 Date: Thu, 2 May 2013 21:22:34 +0200
 From: Erik Carstensen mandolae...@gmail.com
 Cc: make-w32@gnu.org
 
 What I meant is that it's a GNU make bug that the first line does work.

Yes, but it worked like that since about forever.

  I don't want to rock the boat any further in this regard before the
  next release of Make, so I don't want to forcibly disable '..' quoting
  support when cmd.exe is used.  Make worked like that forever; I think
  one incompatible change per release is more than enough ;-)
 
 
 That's a shame... this means that it will continue to be risky to use ' in
 recipes. I would count it as a single change to fix short-circuiting to
 actually interpret quoting like cmd.

It's not a single change, believe me.  It's a tip of an iceberg.

Feel free to submit a Savannah bug, so that this is not forgotten.
Barring any disasters, I will get to this, eventually.  Or maybe
someone else will.

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

Re: Bug: make fails to execute .BAT files with space in the path, with SHELL=cmd.exe

[Eli Zaretskii]

 Date: Tue, 30 Apr 2013 19:48:12 +0300
 From: Eli Zaretskii e...@gnu.org
 Cc: make-w32@gnu.org
 
  Date: Tue, 30 Apr 2013 11:23:41 +0200
  From: Erik Carstensen mandolae...@gmail.com
  
   Alas, this won't help you for long, because the next release of Make
will not invoke cmd.exe just because the command line has quotes.
   Such commands are also short-circuited in the development sources.
  
  
  Oh. This seems to change make behaviour in a non-backward-compatible way
  when one argument has a trailing backslash.
 
 I will look into this.  I don't remember whether this is on purpose.

It is a side effect of the change that removed the double quote  from
the list of special characters for the Windows shells.  (The reason
for that was to avoid hitting the command-line length limitations of
the Windows shells, which are 4KB or 8KB, depending on the Windows
version, while the limit imposed by the OS is 32KB.)

So now commands that use quotes go through the fast path, instead of
being submitted to cmd.exe via a batch file, which exposed these
commands to this (very old) bug.

I fixed that in the repository; the patch is below if you want to try
it.

Please also tell me if your original problem was fixed by the patches
I sent earlier.  Thanks.


--- job.c~3 2013-04-29 08:25:48.616354500 +0300
+++ job.c   2013-05-01 12:05:57.502319100 +0300
@@ -3072,6 +3072,15 @@ construct_command_argv_internal (char *l
 if (ap == new_argv[i])
   p = next_token (p + 1) - 1;
  }
+#ifdef WINDOWS32
+   /* Backslash before whitespace is not special if our shell
+  is not Unixy.  */
+   else if (isspace (p[1])  !unixy_shell)
+ {
+   *ap++ = *p;
+   break;
+ }
+#endif
else if (p[1] != '\0')
   {
 #ifdef HAVE_DOS_PATHS

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

Re: Bug: make fails to execute .BAT files with space in the path, with SHELL=cmd.exe

[Eli Zaretskii]

 Date: Mon, 29 Apr 2013 05:40:25 +0300
 From: Eli Zaretskii e...@gnu.org
 Cc: make-w32@gnu.org
 
 When invoking commands through cmd.exe, the problem disappears because
 cmd.exe's name does not include whitespace.  As I wrote, the problem
 only happens when _both_ the command and its arguments are quited and
 include whitespace.  I'm not yet sure why this triggers the problem.

Further investigation reveals that the problem happens only with .bat
and .cmd files; if you replace a b.bat with some a b.exe (I used a
simple program that just echoes its argv[] array), all of your
examples will suddenly work.

Based on some extensive testing and the corresponding reactions, I
think that what happens is that CreateProcess invokes cmd.exe to run
the batch file, and while doing so, it quotes the command line.  When
the original command already has quotes, the additional quoting by
CreateProcess is buggy (or maybe it's trying to solve a problem that
is unsolvable within its constraints), and the result sometimes
utterly confuses cmd.exe.  Moreover, at least in some cases, the 1st
argument to CreateProcess (which is the full absolute file name of the
batch file) is completely ignored, and instead CreateProcess lets
cmd.exe to intuit the batch name from the command line: the 'a' which
it is complaining about is the beginning of the command line, not the
first letter of the batch file name.

Anyway, can you please try the patch below?  It detects the situation
which triggers this bug, and passes NULL as the first argument to
CreateProcess.  If this gives good results, I will install it in the
repository.  (For best results, I suggest to use the latest
development sources, since that's where I tested these changes.)


--- w32/subproc/sub_proc.c~02013-04-28 06:42:01.0 +0300
+++ w32/subproc/sub_proc.c  2013-04-29 11:47:37.944075900 +0300
@@ -23,6 +23,7 @@ this program.  If not, see http://www.g
 #else
 # include stdint.h
 #endif
+#include string.h
 #include process.h  /* for msvc _beginthreadex, _endthreadex */
 #include signal.h
 #include windows.h
@@ -540,6 +541,26 @@ find_file(const char *exec_path, const c
return INVALID_HANDLE_VALUE;
 }
 
+/*
+ * Return non-zero of FNAME specifies a batch file and its name
+ * includes embedded whitespace.
+ */
+
+static int
+batch_file_with_spaces(const char *fname)
+{
+   size_t fnlen = strlen(fname);
+
+   return (fnlen  4
+(_strnicmp(fname + fnlen - 4, .bat, 4) == 0
+   || _strnicmp(fname + fnlen - 4, .cmd, 4) == 0)
+   /* The set of characters in the 2nd arg to strpbrk
+  should be the same one used by make_command_line
+  below to decide whether an argv[] element needs
+  quoting.  */
+strpbrk(fname,  \t) != NULL);
+}
+
 
 /*
  * Description:   Create the child process to be helped
@@ -570,6 +591,7 @@ process_begin(
STARTUPINFO startInfo;
PROCESS_INFORMATION procInfo;
char *envblk=NULL;
+   int pass_null_exec_path = 0;
 
/*
 *  Shell script detection...  if the exec_path starts with #! then
@@ -651,8 +673,27 @@ process_begin(
 
if (file_not_found)
command_line = make_command_line( shell_name, exec_path, argv);
-   else
+   else {
+   /* If exec_fname includes whitespace, CreateProcess
+  behaves erratically and unreliably, and often fails
+  if argv[0] also includes whitespace (and thus will
+  be quoted by make_command_line below).  So in that
+  case, we don't pass exec_fname as the 1st arg to
+  CreateProcess, but instead replace argv[0] with
+  exec_fname (to keep its leading directories and
+  extension as found by find_file), and pass NULL to
+  CreateProcess as its 1st arg.  This works around
+  the bugs in CreateProcess, which are probably
+  caused by its passing the command to cmd.exe with
+  some incorrect quoting.  */
+   if (!shell_name
+batch_file_with_spaces(exec_fname)
+_stricmp(exec_path, argv[0]) == 0) {
+   pass_null_exec_path = 1;
+   argv[0] = exec_fname;
+   }
command_line = make_command_line( shell_name, exec_fname, argv);
+   }
 
if ( command_line == NULL ) {
pproc-last_err = 0;
@@ -669,7 +710,7 @@ process_begin(
}
}
 
-   if ((shell_name) || (file_not_found)) {
+   if (shell_name || file_not_found || pass_null_exec_path) {
exec_path = 0;  /* Search for the program in %Path% */
} else {
exec_path = exec_fname;

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

Re: Bug: make fails to execute .BAT files with space in the path, with SHELL=cmd.exe

[Eli Zaretskii]

 Date: Sat, 27 Apr 2013 21:48:54 +0200
 From: Erik Carstensen mandolae...@gmail.com
 
 I have the following makefile:
 
 SHELL=cmd.exe
 default:
 a b.bat xy
 a b.bat x y
 a\ b.bat xy
 a\ b.bat x\ y
 
 I also have a file 'a b.bat', which contains a single line:
 echo a b
 
 Now when I run make, this happens:
 
 /tmp$ /cygdrive/c/mingw64-i686-20110207/bin/make.exe
 a b.bat xy
 a b
 a b.bat x y
 a b
 a\ b.bat xy
 
 C:\cygwin\tmpecho a b
 a b
 a\ b.bat x\ y
 'a' is not recognized as an internal or external command,
 operable program or batch file.
 make: *** [default] Error 1

Thanks for the report.  (Any real reason to use batch files whose
names include whitespace?)

 I think the problem is in the lpCommandLine parameter to CreateProcess,
 where argv[0] needs cmd.exe-style quoting of spaces if it is a .BAT file

I don't think so.  If you add --debug=j switch to the Make command
line, you will see that the quoting is perfectly correct.

So this looks like some quirk of CreateProcess, either with batch
files or with any command with embedded spaces.  Exactly how to format
the 1st and the 2nd arguments to CreateProcess when they include
whitespace is insufficiently documented, and CreateProcess invokes a
variety of heuristics that make the job of discovering its rules all
but impossible.  Note that it only fails if both the batch file name
and its argument are quoted and include whitespace; if any one of the
two does not have whitespace, the command works.

I will try to find a good solution to this when I have time.

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

Re: Bug: make fails to execute .BAT files with space in the path, with SHELL=cmd.exe

[Eli Zaretskii]

 Date: Sun, 28 Apr 2013 22:15:11 +0200
 From: Erik Carstensen mandolae...@gmail.com
 Cc: make-w32@gnu.org
 
 The problem only happens when make attempts to run the command directly
 (short-circuiting cmd.exe). So one workaround might be to quote spaces with
 double quotes instead of backslashes when invoking commands.

Alas, this won't help you for long, because the next release of Make
will not invoke cmd.exe just because the command line has quotes.
Such commands are also short-circuited in the development sources.

When invoking commands through cmd.exe, the problem disappears because
cmd.exe's name does not include whitespace.  As I wrote, the problem
only happens when _both_ the command and its arguments are quited and
include whitespace.  I'm not yet sure why this triggers the problem.

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

Re: .ONESEHLL not working as expected in 3.82

[Eli Zaretskii]

 Date: Mon, 30 Aug 2010 17:09:51 +0100
 From: Anjum Naseer a.nas...@resilientplc.com
 
 I have built the 3.82 version of GNU Make using the Microsoft Visual C++
 compiler and it seems to work fine.
 However, I cannot get it to work correctly with the .ONESHELL option.
 I created a dummy makefile (dummy.mak) with this content:
 
 .ONESHELL:
 
 .PHONY: dummy
 
 dummy:
   set xyz=abc
   @echo xyz=%xyz%
 
 
 If I invoke this with make -d -r -f dummy.mak I get:
 Vvvv
 GNU Make 3.82
 Built for Windows32
 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.
 Reading makefiles...
 Reading makefile `dummy.mak'...
 Updating makefiles
  Considering target file `dummy.mak'.
   Looking for an implicit rule for `dummy.mak'.
   No implicit rule found for `dummy.mak'.
   Finished prerequisites of target file `dummy.mak'.
  No need to remake target `dummy.mak'.
 Updating goal targets
 Considering target file `dummy'.
  File `dummy' does not exist.
  Finished prerequisites of target file `dummy'.
 Must remake target `dummy'.
 Invoking recipe from dummy.mak:6 to update target `dummy'.
 Creating temporary batch file
 C:\Users\ADB14~1.NAS\AppData\Local\Temp\make5868-1.bat
 Batch file contents:
 @echo off
 set xyz=abc
 set xyz=abc
 CreateProcess(C:\Users\ADB14~1.NAS\AppData\Local\Temp\make5868-1.bat,C:\
 Users\ADB14~1.NAS\AppData\Local\Temp\make5868-1.bat,...)
 Putting child 0094AFB8 (dummy) PID 9620224 on the chain.
 Live child 0094AFB8 (dummy) PID 9620224
 Main thread handle = 0054
 Reaping winning child 0094AFB8 PID 9620224
 Cleaning up temp batch file
 C:\Users\ADB14~1.NAS\AppData\Local\Temp\make5868-1.bat
 Creating temporary batch file
 C:\Users\ADB14~1.NAS\AppData\Local\Temp\make5868-1.bat
 Batch file contents:
 @echo off
 echo xyz=%xyz%
 CreateProcess(C:\Users\ADB14~1.NAS\AppData\Local\Temp\make5868-1.bat,C:\
 Users\ADB14~1.NAS\AppData\Local\Temp\make5868-1.bat,...)
 Live child 0094AFB8 (dummy) PID 9620224
 xyz=
 Reaping winning child 0094AFB8 PID 9620224
 Cleaning up temp batch file
 C:\Users\ADB14~1.NAS\AppData\Local\Temp\make5868-1.bat
 Removing child 0094AFB8 PID 9620224 from chain.
 Successfully remade target file `dummy'.
 
 
 As you can see from the debug trace above, it looks like it is still
 loading a separate SHELL for each line of the recipe. Have I
 misunderstood the .ONESHELL feature or is this a bug?

(Yes, this was almost 3 years ago.  Sorry for a long delay.)

The .ONESHELL feature is now supported on MS-Windows, for the default
Windows shell (cmd.exe) or compatible replacements, in the development
version (commit e56aad4).

I realize that one of the important use cases for .ONESHELL is to use
a shell that Make knows nothing about, but as such shells are not yet
supported by the Windows build, I didn't feel it was right to postpone
.ONESHELL any longer.  Volunteers are welcome to contribute support
for foreign shells.

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

Re: .ONESEHLL not working as expected in 3.82

[Eli Zaretskii]

 From: Paul Smith p...@mad-scientist.net
 Cc: make-w32@gnu.org, bug-m...@gnu.org
 Date: Sat, 27 Apr 2013 12:54:10 -0400
 
 Also, I wonder if you have a few minutes to go through the open Windows
 bugs in Savannah and make a comment or whatever to those which are still
 waiting (some are waiting for other people, not us).  Looks like 18 bugs
 total, some pretty old.  Here's a link I hope will work for you:
 
 https://savannah.gnu.org/bugs/index.php?go_report=Applygroup=makefunc=browseset=custommsort=0report_id=141advsrch=0status_id=1platform_version_id=105fix_release_id=100

Thanks.  I went through that list and closed several bugs, either
because they were fixed or because they sound no longer relevant.
There are now only 11 open issues in that list.

Out of those 11, I will try to find time to work on about 2 or 3; the
rest are either enhancements (4 of them) that don't sound too
important to me (volunteers are welcome, of course), or await for
additional information without which I cannot advance in my
investigation of the issue.

Note: there's one more major feature in current git repo that needs to
be made available on Windows: dynamic loading of extensions.  That is
my highest priority for Make todo list.

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

Re: .ONESEHLL not working as expected in 3.82

[Eli Zaretskii]

 From: Paul Smith psm...@gnu.org
 Cc: make-w32@gnu.org, bug-m...@gnu.org
 Date: Sat, 27 Apr 2013 14:28:18 -0400
 
 On Sat, 2013-04-27 at 20:55 +0300, Eli Zaretskii wrote:
  Note: there's one more major feature in current git repo that needs to
  be made available on Windows: dynamic loading of extensions.  That is
  my highest priority for Make todo list.
 
 Yes.  I wonder if there are features of gnulib which make this work in a
 cross-platform way?  I've often wondered if we might get some win out of
 utilizing gnulib more in GNU make code.

AFAICS, gnulib does not offer any modules that support dynamic loading
of shared libraries.

 However, I think that investigation and reworking will need to wait
 until after the next release.  I don't want to open that can of worms
 yet... at least not widely.  But if you see something there that would
 make your work for load simpler let me know and we'll look into it.

I added a similar facility to Gawk, but there a problem was much
simpler, because Gawk itself was tracking the loaded extensions in
platform-independent code.  So my emulation of dlopen didn't need to
support NULL as its first argument, and didn't care about RTLD_GLOBAL.

By contrast, the way Make's code in load.c is written, it relies on
dlopen to track the shared libraries already loaded.  This is a PITA
on Windows, because there's no similar functionality built in, and the
emulation of dlopen will have to record each loaded extension in some
internal data structure, and search that when dlopen is called with
its 1st argument NULL.  Not rocket science, granted, but it does make
the job larger and the required testing more extensive.

If Make could behave like Gawk, I could have simply copied the code I
wrote for Gawk and reuse it almost verbatim.

 One other thing: I want to make a format cleanup commit at some point to
 deal with a number of annoying issues related to TABs, EOL syntax, etc.,
 as well as update copyright dates, etc.  I don't want to do that when it
 will conflict with major work anyone else is doing, so let me know when
 a good time is for you.

As far as I'm concerned, you can do it whenever you want.  I'd be
greatly surprised if git couldn't figure out how to merge stuff like
that cleanly.  CVS could have barfed, but not git (or any other modern
VCS that tracks the history DAG).

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

Re: How to get gnumake3.8.2 Run in Unix mode on windows platform

[Eli Zaretskii]

 From: Paul Smith psm...@gnu.org
 Date: Tue, 09 Apr 2013 09:51:54 -0400
 
  I just download gnumake3.8.2 and tried to compile but it seems --unix
  option is remove and I am getting following error:
 
 There is not nor has there ever been a --unix option for GNU make in
 the standard version.

Right.

 If your version of GNU make had a --unix option, it must have been
 a customized version.  Are you using Cygwin?  Maybe this is
 something added by the Cygwin folks.

Or maybe MSYS.  What does make --version display for gnu make 3.80
and for 3.82?

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

Re: mingw32-make does not set $(RM) to del

[Eli Zaretskii]

 Date: Mon, 7 Jan 2013 19:48:59 +0800
 From: Yongwei Wu wuyong...@gmail.com
 Cc: make-w32@gnu.org
 
 On 6 January 2013 11:51, Eli Zaretskii e...@gnu.org wrote:
  Date: Sun, 6 Jan 2013 08:27:37 +0800
  From: Yongwei Wu wuyong...@gmail.com
  Cc: make-w32@gnu.org
 
  undefining $(RM) will break certain makefiles
 
  Can you show them and point to projects that use them?
 
 No, I do not know popular projects that do this (they use more formal
 methods). I do use $(RM) this way (in personal and proprietary
 projects) to minimize the Makefile difference between Unix and Windows
 platforms.
 
 For a personal project, you can check:
 
 https://github.com/adah1972/libunibreak/blob/master/src/Makefile.gcc
 
 Maybe it is just informal, or even foolish. I doubt I am the only one
 doing this.

But if Sed, cat, head, and even rm are called by their literal names,
as in that project of yours, then why is it important to be able to
use $(RM) instead of rm?

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

Re: mingw32-make does not set $(RM) to del

[Eli Zaretskii]

 Date: Sun, 6 Jan 2013 08:27:37 +0800
 From: Yongwei Wu wuyong...@gmail.com
 Cc: make-w32@gnu.org
 
 undefining $(RM) will break certain makefiles

Can you show them and point to projects that use them?

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

Re: mingw32-make does not set $(RM) to del

[Eli Zaretskii]

 Date: Sat, 5 Jan 2013 14:29:17 +0800
 From: Yongwei Wu wuyong...@gmail.com
 
  There just isn't a good alternative on Windows.  I might support
  leaving this variable undefined on Windows, but using 'del is a
  non-starter.
 
 If one uses Unix-style tools like make.exe, one should definitely also
 need tools like rm, ls, wc, grep, etc.

I agree (and I do), but I won't force others to do that.  So if it is
deemed better to have that variable undefined on Windows, I might be
convinced to do that.  The number of Makefile's out there which use
these defaults is small anyway, according to my experience.

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

Re: mingw32-make does not set $(RM) to del

[Eli Zaretskii]

 Date: Thu, 03 Jan 2013 09:59:53 +0100
 From: Fabian Greffrath fab...@greffrath.com
 CC: make-w32@gnu.org
 
 Am 02.01.2013 18:56, schrieb Eli Zaretskii:
  This won't work on older Windows versions, where DEL can only accept
  a single argument, and (AFAIR) doesn't have the equivalent of the -f
  option.
 
 Fine, but then del is still a better choice on Windows than rm -f, 
 which is usually not existent on Windows.

Sorry, I disagree.  A command that fails completely with a clear error
message is better than a command that silently does only part of a
job.

There just isn't a good alternative on Windows.  I might support
leaving this variable undefined on Windows, but using 'del is a
non-starter.

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

Re: mingw32-make does not set $(RM) to del

[Eli Zaretskii]

 Date: Wed, 02 Jan 2013 14:38:29 +0100
 From: Fabian Greffrath fab...@greffrath.com
 
 occationally, I use mingw32-make for building very simple projects. 
 However, it fails to call the clean: rules, because they remove the 
 object files with (RM) *.o (similar). However, $(RM) is still set to 
 rm -f, which does not exist outside MSYS. Please fall back to 
 Windows' own del in such case.

This won't work on older Windows versions, where DEL can only accept
a single argument, and (AFAIR) doesn't have the equivalent of the -f
option.

The solution is to install a Windows port of GNU Coreutils.  One such
port is available from the GnuWin32 site.

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

Re: command line limit in mingw-make

[Eli Zaretskii]

 Date: Wed, 05 Dec 2012 01:15:10 +1100
 From: Jonathan Liu net...@gmail.com
 CC: make-w32@gnu.org
 
 On 8/11/2012 3:08 AM, Eli Zaretskii wrote:
  Date: Wed, 07 Nov 2012 22:52:26 +1100
  From: Jonathan Liunet...@gmail.com
  CC: joe.burmeis...@codethink.co.uk, make-w32@gnu.org
 
  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.

Yes, I didn't do that yet.

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

Re: command line limit in mingw-make

[Eli Zaretskii]

 Date: Wed, 07 Nov 2012 22:52:26 +1100
 From: Jonathan Liu net...@gmail.com
 CC: joe.burmeis...@codethink.co.uk, make-w32@gnu.org
 
 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@gnu.org
https://lists.gnu.org/mailman/listinfo/make-w32

Re: Multiple target patterns

[Eli Zaretskii]

 Date: Sat, 03 Nov 2012 15:42:27 +
 From: Greg Chicares gchica...@sbcglobal.net
 
 On 2012-11-03 06:18Z, lucky7456969 wrote:
  
  Makefile: PERFEC~1.pro  c:/Qt/4.8.0/mkspecs/win32-g++/qmake.conf
  c:/Qt/4.8.0/mkspecs/qconfig.pri \
 [...]
  $(QMAKE) -o Makefile PERFEC~1.pro
  
  Makefile:66: *** multiple target patterns.  Stop.
  
  How do I go about solving this problem?
 
 The diagnostic points to the sixty-sixth line of 'Makefile',
 so it would help to see that line and anything it depends on.
 I would guess that a colon in a path like c:/whatever is
 being interpreted as makefile target punctuation.

It shouldn't be: Make on Windows does support drive letters in file
names.

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

Re: command line limit in mingw-make

[Eli Zaretskii]

 Date: Fri, 19 Oct 2012 19:34:01 +1100
 From: Jonathan Liu net...@gmail.com
 CC: joe.burmeis...@codethink.co.uk, make-w32@gnu.org
 
 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.0 +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@gnu.org
https://lists.gnu.org/mailman/listinfo/make-w32

Re: command line limit in mingw-make

[Eli Zaretskii]

 Date: Tue, 18 Sep 2012 09:28:13 +0100
 From: Joe Burmeister joe.burmeis...@codethink.co.uk
 CC: Eli Zaretskii e...@gnu.org, make-w32@gnu.org
 
  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@gnu.org
https://lists.gnu.org/mailman/listinfo/make-w32

Re: command line limit in mingw-make

[Eli Zaretskii]

 Date: Sat, 13 Oct 2012 11:27:07 +0200
 From: Eli Zaretskii e...@gnu.org
 Cc: make-w32@gnu.org
 
  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.0 +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@gnu.org
https://lists.gnu.org/mailman/listinfo/make-w32