> 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
> 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, Christi
> 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
> 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).
>
> 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
> 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.
> 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.
> 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 a
> 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
> &
> 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.
&
> 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 o
> 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 scri
> 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, obvious
> 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.
> 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
> 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
> 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
> 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
> 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:
> 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.
> 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 yo
> 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
> 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
> 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 Chr
> 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 mentio
> 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.
> 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
> 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 bes
> 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 va
> 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 do
> 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 d
[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 dist
> 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 f
> 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/subpr
[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 a
> 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 withou
> 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 memo
> From: Adrian Muresan
> Date: Fri, 9 Sep 2016 18:32:14 +
>
> I'm using make 3.81 on windows doing parallel builds with this hack:
>
> make all -j4 MAKE="make -j4"
>
> It works but I need a way to limit CPU usage or number of simultaneous makes.
>
> I have to use 3.81 because it's part of
> From: Adrian Muresan
> CC: "psm...@gnu.org" , "make-w32@gnu.org"
> Date: Thu, 23 Jun 2016 03:01:18 +
>
> why don't we use a website like stackoverflow or some other forum-based site
> for these communications?
Because we have this forum, which was created exactly for this kind of
discus
> From: Paul Smith
> Cc: Eli Zaretskii , "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?
> From: Adrian Muresan
> CC: Eli Zaretskii , "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.
>
>
> From: Adrian Muresan
> CC: "make-w32@gnu.org"
> Date: Wed, 22 Jun 2016 17:57:25 +
>
> Should I submit a bug report to the GNU make site?
Bug report about what? The limitations of the MSYS port of Bash are
not Make's responsibility.
___
Make-w3
> From: Adrian Muresan
> CC: "make-w32@gnu.org"
> Date: Wed, 22 Jun 2016 17:44:33 +
>
> This is an interesting data-point.
>
> I used make 3.81 directly from SourceForge and it also failed with same error.
>
> C:\Users\mureadr\Desktop\A\HMI_FORGF\bld\armle-v7\release\fordhmi>"C:\GnuWin32\b
> 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:
> 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 m
> 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
> From: Adrian Muresan
> Date: Tue, 21 Jun 2016 22:53:50 +
>
> For more complete info, go to here
>
> http://stackoverflow.com/questions/37932984/gnu-make-4-2-and-4-2-1-on-windows-bug
That discussion is full of misinformation, so let's ignore it, OK?
> I am making this target only
>
> dep
> Date: Mon, 13 Jun 2016 09:21:13 -0700 (PDT)
> From: OrangeDog
>
> > The 32-bit build of GNU Make for Windows should work on 64-bit Windows just
> fine.
>
> Except that you cannot fork any 64-bit processes from it.
Windows doesn't support fork at all, so I'm not sure what you mean by
that. If
> 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 r
> 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, wh
> 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 al
> From: Paul Smith
> Cc: troy.run...@mathworks.com, make-w32@gnu.org
> Date: Tue, 08 Mar 2016 00:18:58 -0500
>
> > dosbuild.bat is for DOS, not for Windows.
>
> I know, but when I look at the content of that batch file I don't see
> the difference in the commands invoked between the build_w32.ba
> 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
>
> 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, h
> 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 a
> From: Paul Smith
> Date: Wed, 24 Feb 2016 20:25:43 -0500
>
> On Wed, 2016-02-24 at 17:27 +, Troy Runkel wrote:
> > 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
> Date: Mon, 13 Jul 2015 05:53:00 -0700 (PDT)
> From: ruzrulit
>
> Fabrice GIRARDOT wrote
> > Eli Zaretskii wrote :
> >
> >>> process_begin: CreateProcess(NULL, "", ...) failed
> >>
> >> Yes, this is a known bug in Make 3.81. I
> Date: Wed, 19 Nov 2014 17:45:15 +0530
> From: Ashish Soni
>
> I am getting below error while compiling c source using make 3.79.1.
This is a very old version of Make. The latest one is 4.1.
> Creating temporary batch file X:\testRep\gen\tmp\w2k\makeTemp\make68402.bat
> [exec] cl.exe Settingt
> Date: Sat, 18 Oct 2014 00:48:07 +0200
> From: Bostjan Mihoric
>
> 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, tha
> Date: Fri, 17 Oct 2014 15:14:37 +0200
> From: Bostjan Mihoric
>
> 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
[Please keep the list address on the CC, so that it gets archived, and
seen by others.]
Resending to the list.
> Date: Thu, 16 Oct 2014 17:06:01 +0200
> From: Bostjan Mihoric
>
> On Wed, Oct 15, 2014 at 10:56 PM, Eli Zaretskii wrote:
>
> > Date: Wed, 15 Oc
> Date: Wed, 15 Oct 2014 19:45:23 +0200
> From: Bostjan Mihoric
>
> Even if we ignore the impact this can have on (SSD) drive wear (doing a lot of
> big compilations),
I don't think this is a real problem. There are systems out there
which have the page file on an SSD disk, and still the disk r
> From: Paul Smith
> Date: Thu, 05 Jun 2014 11:33:05 -0400
> Cc: make-w32@gnu.org
>
> On Thu, 2014-06-05 at 18:45 +0530, chandrababu nallani wrote:
>
> > 1. Assume the Gnu Make depends on some dlls from the operating
> > system or other extensions, e.g. service packs or .NET
> >
> Date: Thu, 5 Jun 2014 18:45:29 +0530
> From: chandrababu nallani
>
> 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
> From: Paul Smith
> 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
> From: Troy Runkel
> Date: Mon, 11 Nov 2013 22:35:19 +
> Cc: Troy Runkel
>
> 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
> Date: Wed, 23 Oct 2013 23:14:20 +0400
> From: Alexey Pavlov
>
> 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 off
> Date: Wed, 23 Oct 2013 21:20:06 +0400
> From: Alexey Pavlov
> 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
> Date: Wed, 23 Oct 2013 11:01:02 +0400
> From: Alexey Pavlov
>
> Building latest MAKE from git with BAT file fail with
>
> C:\Test\nativesrc\mingw-builds\make32>gcc -mthreads -gdwarf-2 -g3 -o
> gnumake.exe variable.o rule.o remote-stub.o commands.o file.o
> getloadavg.o default.o signame.o expa
> From: Paul Smith
> Cc: Denis Excoffier ,
> 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 $(M
> Date: Fri, 4 Oct 2013 01:06:58 -0400
> From: Christopher Faylor
>
> >> 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 ab
> Date: Thu, 3 Oct 2013 01:23:15 -0400
> From: Christopher Faylor
>
> >@@ -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
> Date: Tue, 24 Sep 2013 07:34:44 +0200
> From: Markus Eisenmann
>
> 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 mai
> Date: Wed, 02 Oct 2013 19:17:58 +0300
> From: Eli Zaretskii
> 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
> > Cc: , , ,
> >
> >
> > The abspat
> Date: Wed, 02 Oct 2013 09:34:06 +0200
> From: Denis Excoffier
> Cc: , , ,
>
>
> The abspath error is gone.
Thanks for testing, I will commit the changes soon.
> However, output-sync, recursion, MAKE remain. Included work.tar.xz
All of those failures are because of the exact form of $(MAKE
> From: Paul Smith
> 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
>
> From: Paul Smith
> Cc: Denis Excoffier , Pavel Fedin
> , Chris Faylor
> , 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.
> From: Paul Smith
> 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-
> From: Paul Smith
> Cc: Denis Excoffier , Pavel Fedin
> , Chris Faylor
> , 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
> From: Paul Smith
> Cc: Markus Eisenmann , 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
> > > nee
> Date: Mon, 23 Sep 2013 16:21:30 +0200
> From: Markus Eisenmann
>
> 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' w
> Date: Mon, 23 Sep 2013 22:32:36 +0400
> From: Alexey Pavlov
>
> $ diff -Naur a/w32/compat/posixfcn.c b/w32/compat/posixfcn.c
> --- a/w32/compat/posixfcn.c 2013-09-23 21:25:20.36880 +0400
> +++ b/w32/compat/posixfcn.c 2013-09-23 22:28:15.60700 +0400
> @@ -26,7 +26,7 @@
> #include "
> Date: Thu, 23 May 2013 07:29:46 -0400
> From: LM
>
> > Which Bash-like shell exists on Windows, except Cygwin?
> >
>
> I've seen ports of zsh and tcsh for Windows.
They are buggy (even after I fixed some glaring bugs in zsh). Only
usable for very simple jobs.
> There's a bash like shell wit
> Date: Tue, 21 May 2013 15:40:34 -0400
> From: LM
>
> So msys make does not have the same issue with recursive calls to
> sync_Path_environment?
I'd be surprised to hear it does.
> I'd be interested to see what's different in the build that it
> avoids it.
It simply does not compile that code
> Date: Tue, 21 May 2013 09:02:57 -0400
> From: LM
>
> 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 ^^
> ^^^
> Date: Sat, 18 May 2013 18:48:05 +0400
> From: Алексей Павлов
> 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-
[Why a personal email?]
> Date: Sat, 18 May 2013 08:50:24 +0400
> From: Алексей Павлов
>
> 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-ari
> Date: Fri, 17 May 2013 15:45:14 +0400
> From: Алексей Павлов
>
> 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/loca
> Date: Fri, 17 May 2013 15:52:24 +0400
> From: Алексей Павлов
>
> Hi!
>
> I have troubles with building Make from git with mingw-w64 compiler. I
> has error:
Is GNUMake and Make the same program?
___
Make-w32 mailing list
Make-w32@gnu.org
https://l
> Date: Wed, 8 May 2013 09:49:22 +0200
> From: Erik Carstensen
> Cc: Duane Campbell , "make-w32@gnu.org"
>
>
> SHELL=cmd.exe
> foo:
> $(MAKE) 'a b'
>
> will complain that there is no target "a b", while
>
> SHELL=cmd.exe
> foo:
> call $(MAKE) 'a b'
>
> will complain that there is no
> Date: Mon, 6 May 2013 21:55:11 +0200
> From: Erik Carstensen
> Cc: Duane Campbell , make-w32@gnu.org
>
> On Mon, May 6, 2013 at 9:48 PM, Eli Zaretskii wrote:
>
>
> > Maybe c:\very-long-src-dir\..\very-long-build-dir together exceeded
> > 260 characters?
&
> Date: Mon, 6 May 2013 22:26:14 +0200
> From: Erik Carstensen
> 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)
> From: Duane Campbell
> CC: "make-w32@gnu.org" , Duane Campbell
>
> Date: Mon, 6 May 2013 11:55:28 -0700
>
> Windows has limits on path length, approximately (as I don't remember exactly
> off-hand):
> 256 chars total in dir or file path
> 128 chars in each element in dir or file pat
> Date: Mon, 6 May 2013 09:08:04 +0200
> From: Erik Carstensen
> Cc: make-w32@gnu.org
>
> I just thought it might be a more lightweight and robust solution for the
> other problem I reported earlier (spaces in .bat paths): You are detecting
> .bat files already, so instead of doing complicated sp
> Date: Mon, 6 May 2013 15:45:43 +0200
> From: Erik Carstensen
>
> I found the problem, there seems to be a limit in VPATH resolution of
> around 256 characters, where ..\ entries in the path are not collapsed. In
> my example, I ran make from c:\path\very-long-build-dir, and had
> ..\very-long-s
> From: Duane Campbell
> CC: "make-w32@gnu.org" , Duane Campbell
>
> 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
> Date: Fri, 3 May 2013 17:17:20 +0200
> From: Erik Carstensen
>
> 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 qu
> Date: Fri, 3 May 2013 19:17:37 +0200
> From: Erik Carstensen
>
> This makefile reproduces the problem:
>
> SHELL=cmd.exe
> default:
> ./x.bat ""
> ./x.bat
>
> The first line succeeds on make 3.82, while the second line fails. With
> master, both lines fail (because the first one is sh
> Date: Fri, 3 May 2013 10:22:40 +0200
> From: Erik Carstensen
> Cc: make-w32@gnu.org
>
> > 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 variable
> Date: Thu, 2 May 2013 21:22:34 +0200
> From: Erik Carstensen
> 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 re
1 - 100 of 841 matches
Mail list logo
