On Jun 2, 2017 9:18 PM, "Eli Zaretskii" wrote:
> From: Paul Smith
> Cc: bug-make@gnu.org
> Date: Fri, 02 Jun 2017 15:56:51 -0400
>
> FYI, I don't know how "good" this is for testing requirements but on my
> Windows systems I've installed Git for Windows (along with Perl of
> course) and that pro
On Jun 1, 2017 12:49 AM, "Paul Smith" wrote:
This message is mainly for Eli but anyone else who uses GNU make on
Windows might have an opinion.
I'm working on ensuring that the test suite works on Windows (some of
that means disabling tests until someone has a chance to rework them to
be more po
On Thu, Aug 21, 2014 at 8:03 PM, David Boyce wrote:
> The obvious compromise would be to change the behavior only in the
> presence of the ".POSIX:" special target.
Sounds pragmatic; the repeatable builds people would probably like a
solution that doesn't require changing Makefiles though, either
On Thu, Aug 21, 2014 at 4:57 PM, Ray Donnelly wrote:
> On Thu, Aug 21, 2014 at 4:32 PM, Eric Blake wrote:
>> Make folks:
>> You may want to check out http://austingroupbugs.net/view.php?id=857 and
>> add comments and/or change GNU make behavior accordingly. There, the
>
On Thu, Aug 21, 2014 at 4:32 PM, Eric Blake wrote:
> Make folks:
> You may want to check out http://austingroupbugs.net/view.php?id=857 and
> add comments and/or change GNU make behavior accordingly. There, the
> argument is made that HP-UX make behavior is nicer than GNU's current
> behavior whe
If you are going to roll your own GNU make with the change mentioned:
http://git.savannah.gnu.org/cgit/make.git/commit/?id=757849cd93a9bc361a5113e3aaafe516773aad44
.. then you should take care to also apply:
http://git.savannah.gnu.org/cgit/make.git/commit/?id=e1863c05d82096aa2bfcddb436da1b54a4136
Follow-up Comment #1, bug #41518 (project make):
On MSYS2 we use the following patch:
--- a/w32/Makefile.am 2013-09-16 12:07:00.97600 +0400
+++ b/w32/Makefile.am 2013-10-18 22:09:50.53360 +0400
@@ -14,6 +14,7 @@
#
# You should have received a copy of the GNU General Public License a
I can't see it in the git repository yet.
.. am I being too impatient?
On Feb 2, 2014 4:00 PM, "Paul Smith" wrote:
> On Sun, 2014-01-26 at 16:35 +, Ray Donnelly wrote:
> > I missed a few assert cases in the previous patch. Please find a fixed
> > version attac
Follow-up Comment #11, bug #41246 (project make):
Hi Mike,
Sorry to hijack this thread a little.
I work on the MSYS2 project and I'd be keen to fix "sh.exe -c" to behave
correctly. If you are interested in this, could you please email me at
mingw.andr...@gmail.com with a testcase?
FWIW I agree
On Mon, Jan 27, 2014 at 5:29 PM, Paul Smith wrote:
> On Sun, 2014-01-26 at 16:35 +, Ray Donnelly wrote:
>> I missed a few assert cases in the previous patch. Please find a fixed
>> version attached.
>
> Thanks Ray; I'm utterly swamped for the last week or so with &q
I missed a few assert cases in the previous patch. Please find a fixed
version attached.
0001-output.c-Fix-memory-stomp-when-need-fmtbuf.size.patch
Description: Binary data
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinf
Hi,
Git commit 757849cd introduced a memory stomp in get_buffer() in
output.c. If "need" is is equal to "fmtbuf.size" then:
fmtbuf.buffer[need] = '\0';
.. writes '\0' to a byte 1 beyond the size of the allocated buffer.
Please find attached a patch which
Instead of adding the MS-specific "%Ix", could you not add (in the
batch file) the define of __MINGW_USE_ANSI_STDIO=1, otherwise I
suspect you'd be breaking people who prefer the stdio a bit more ansi
(mingw-builds for example).
On Tue, Nov 26, 2013 at 3:39 AM, Stephan T. Lavavej wrote:
> Hi,
>
>
Follow-up Comment #8, bug #40227 (project make):
Eli, I think that most of the GCC-on-Windows world have moved over to
MinGW-w64 (for both 32bit and 64bit) and I would encourage you to do the same
as you'd be in-sync with the majority of your users that way. Of course having
gnumake work well on b
Did you actually try your patch in a production environment? It breaks
make -jN, so any efficiency gains are negated by that fact. We tried
it in MSYS2 and had to remove it.
"because they already own the computing world"
... rght.
On Mon, Sep 2, 2013 at 6:45 AM, Pavel Fedin wrote:
>> I real
will try to remove the other (removing doc) part of
this hacky patch next, at which point the patch will cease to exist
entirely.
Ray.
On Sat, Apr 20, 2013 at 5:17 PM, Eli Zaretskii wrote:
> > Date: Sat, 20 Apr 2013 15:52:03 +0100
> > From: Ray Donnelly
> > Cc: bug-make@gnu.o
r are frowned up, so here's my archive
on Dropbox:
https://www.dropbox.com/s/uo16sugl70rk60n/gnumake-autoconf.tar.xz
Cheers,
Ray.
On Sat, Apr 20, 2013 at 1:54 PM, Eli Zaretskii wrote:
> > Date: Tue, 16 Apr 2013 17:24:42 +0100
> > From: Ray Donnelly
> > Cc: bug-make@g
Cheers,
Ray.
On Tue, Apr 16, 2013 at 3:01 PM, Eli Zaretskii wrote:
> Date: Tue, 16 Apr 2013 13:41:53 +0100
> > From: Ray Donnelly
> >
> > This is just for reference for anyone who wants to build gnumake on
> > Windows. I don&
retskii wrote:
> > Date: Tue, 16 Apr 2013 13:39:58 +0100
> > From: Ray Donnelly
> >
> > 'move' is not listed as a cmd.exe builtin when it needs to be.
> >
> >
> > Not sure how this hasn't been spotted and fixed before now!
>
> It'
Oops!
On Tue, Apr 16, 2013 at 1:41 PM, Paul Smith wrote:
> On Tue, 2013-04-16 at 13:40 +0100, Ray Donnelly wrote:
> > Pretty simple, needs little explanation.
>
> Maybe not but a patch would be nice :-) :-p
>
>
>
0003-Compile-fix-for-when-not-using-output-sync.patch
This is just for reference for anyone who wants to build gnumake on
Windows. I don't want it to be applied as the real bugs are in Autotools.
Best regards,
Ray Donnelly.
0004-Windows-MSYS-Autotools-doc-disabling-hack.patch
Description: Binary
Pretty simple, needs little explanation.
Best regards,
Ray Donnelly.
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
'move' is not listed as a cmd.exe builtin when it needs to be.
Not sure how this hasn't been spotted and fixed before now!
Best regards,
Ray Donnelly.
0002-Windows-Add-move-to-sh_cmds_dos.patch
Description: Binary data
___
Bug-ma
Because this modifies a batch file with Windows line endings it must
be applied with --keep-cr, e.g.:
git am 0001-Windows-Add-load.c-to-build_w32.bat.patch --keep-cr
Best regards,
Ray Donnelly.
0001-Windows-Add-load.c-to-build_w32.bat.patch
Description: Binary data
24 matches
Mail list logo
