Re: Q: On Windows why not ignore CRLF?

[Ray Donnelly]

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 provides a number of UNIX commands which is why I
> think many of the tests work even though the recipes use lots of UNIX
> code.  Also I have no idea what the shell settings are during these
> tests; maybe it finds the Git for Windows sh and uses that.

Beware: the Unix commands that come with Git for Windows, and are
found under the usr/ subdirectory of your Git installation directory,
are MSYS builds.  MSYS is a fork of Cygwin, so (a) those commands are
not native Windows programs, they use a separate (and very large)
substitute of runtime instead of msvcrt.dll; and (b) they generally
behave like Unix programs, in particular their default is to use
binary I/O, i.e. they do NOT convert CRLF to newlines and back, as
normal Windows C runtime would.

(The bulk of Git itself, those programs under the mingw64/ or mingw32/
subdirectory, are by contrast native Windows programs compiled by the
MinGW port of GCC and using the Windows C runtime.)


To be pedantic, Git for Windows uses MSYS2 and mingw-w64.


It is okay to use MSYS builds of Unix tools to run the test suite, I'm
doing the same with Gawk.  You just need to be aware of the above
gotcha, and make the necessary allowances.  For example, while most
Unix commands will produce text files with only the LF characters at
their EOLs, once you invoke Make itself, it will, of course, generate
Windows style CRLF EOLs.  So comparing files with cmp, for example, is
not a good idea; better do it with "diff --strip-trailing-cr" (I
actually have a shell script called 'diff' which invokes the "real"
diff with that switch -- works like a charm).

HTH

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Q: On Windows why not ignore CRLF?

[Ray Donnelly]

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 portable, unfortunately :-/).

I came across a test failure in the backslash/newline tests on Windows
which I was curious about, and it lead me to this code in
read.c:readline():

  #if !defined(WINDOWS32) && !defined(__MSDOS__) && !defined(__EMX__)
/* Check to see if the line was really ended with CRLF; if so ignore
   the CR.  */
if ((p - start) > 1 && p[-2] == '\r')
  {
--p;
memmove (p-1, p, strlen (p) + 1);
  }
  #endif

I'm not sure about this implementation (performance-wise) but leaving
that aside, I don't understand why this code is ifdef'd out on Windows.
I mean, CRLF is more prevalent on Windows so why wouldn't we have this
there?

Is the idea that on Windows we want to preserve the CRLF, for some
reason?  I'm not sure I see the point in doing that when we're parsing
the makefile; I mean we'd throw away all the newlines on UNIX, so why
would we preserve the CRLF on Windows?


I don't think so. Without checking the code, I expect the reason behind not
doing this stuff on Windows is because Windows had two modes of file
access, binary and text and perhaps whoever wrote that code expected text
mode to be used when opening makefiles.

Text mode means that Windows converts CRLF to LF behind the scenes.


But, I didn't want to change this without asking if there might be a
reason for it that I'm missing.

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: POSIX ruling on up-to-date vs. identical timestamps

[Ray Donnelly]

On Thu, Aug 21, 2014 at 4:32 PM, Eric Blake ebl...@redhat.com 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 when two files have identical timestamps: HP-UX considers the
 file as out-of-date, while GNU make considers it up-to-date.  A strict
 reading of POSIX can argue that GNU's behavior was required, but this
 reading has been called into question.

 GNU's behavior is an optimization that avoids needless churn on file
 systems with course timestamps (well, FAT still exists, but these days,
 MOST file systems have sub-second resolution, so it is harder to get
 files with identical timestamps without actually touch'ing them that
 way) - but it risks leaving a tree in an incomplete state.  HP-UX
 behavior guarantees the rules are run, even if they were not strictly
 necessary, but has the nice property that the tree is never left in an
 incomplete state due to unfortunate timing on a file system with course
 timestamps.

 The POSIX recommendation was therefore that GNU should change its
 behavior to act like HP-UX, and consider identical timestamps as
 out-of-date, because the standard will be fixed to allow HP-UX behavior.

 Autoconf folks:
 The section of the autoconf manual that discusses this should probably
 be modernized, particularly if changes to POSIX and/or GNU make result
 from this discussion.
 https://www.gnu.org/software/autoconf/manual/autoconf.html#Timestamps-and-Make


Some projects that want to have deterministic builds by using the
gitian builder [1] use libfaketime to set the timestamps to a known
constant, and gnu make trips up on this, occasionally causing broken
builds and othertimes autoconf declares suck a build system insane.
There was a bug in libfaketime so that the nanosecond field wasn't
cleared and this allowed you to avoid both these bugs if the planets
were aligned correctly (which has since been fixed). I agree that
these issues should be fixed in make and autoconf.

[1] https://gitian.org/

 --
 Eric Blake   eblake redhat com+1-919-301-3266
 Libvirt virtualization library http://libvirt.org


 ___
 Bug-make mailing list
 Bug-make@gnu.org
 https://lists.gnu.org/mailman/listinfo/bug-make


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: POSIX ruling on up-to-date vs. identical timestamps

[Ray Donnelly]

On Thu, Aug 21, 2014 at 4:57 PM, Ray Donnelly mingw.andr...@gmail.com wrote:
 On Thu, Aug 21, 2014 at 4:32 PM, Eric Blake ebl...@redhat.com 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 when two files have identical timestamps: HP-UX considers the
 file as out-of-date, while GNU make considers it up-to-date.  A strict
 reading of POSIX can argue that GNU's behavior was required, but this
 reading has been called into question.

 GNU's behavior is an optimization that avoids needless churn on file
 systems with course timestamps (well, FAT still exists, but these days,
 MOST file systems have sub-second resolution, so it is harder to get
 files with identical timestamps without actually touch'ing them that
 way) - but it risks leaving a tree in an incomplete state.  HP-UX
 behavior guarantees the rules are run, even if they were not strictly
 necessary, but has the nice property that the tree is never left in an
 incomplete state due to unfortunate timing on a file system with course
 timestamps.

 The POSIX recommendation was therefore that GNU should change its
 behavior to act like HP-UX, and consider identical timestamps as
 out-of-date, because the standard will be fixed to allow HP-UX behavior.

 Autoconf folks:
 The section of the autoconf manual that discusses this should probably
 be modernized, particularly if changes to POSIX and/or GNU make result
 from this discussion.
 https://www.gnu.org/software/autoconf/manual/autoconf.html#Timestamps-and-Make


 Some projects that want to have deterministic builds by using the
 gitian builder [1] use libfaketime to set the timestamps to a known
 constant, and gnu make trips up on this, occasionally causing broken
 builds and othertimes autoconf declares suck a build system insane.

Freudian slip? I meant such, not suck.

 There was a bug in libfaketime so that the nanosecond field wasn't
 cleared and this allowed you to avoid both these bugs if the planets
 were aligned correctly (which has since been fixed). I agree that
 these issues should be fixed in make and autoconf.

 [1] https://gitian.org/

 --
 Eric Blake   eblake redhat com+1-919-301-3266
 Libvirt virtualization library http://libvirt.org


 ___
 Bug-make mailing list
 Bug-make@gnu.org
 https://lists.gnu.org/mailman/listinfo/bug-make


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: GNU make 4.0 crashes on Solaris 8

[Ray Donnelly]

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=e1863c05d82096aa2bfcddb436da1b54a41369e3
as 757849 introduced a memory overrun.

Cheers,

Ray.

On Thu, Apr 17, 2014 at 4:04 PM, Tom Kacvinsky
tom.kacvin...@vectorcast.com wrote:
 Martin,

 Thanks.  Does anyone know when is the next release of make 4.0 is planned?
 I'd rather not use development code for production purposes.

 Thanks,

 Tom


 On Thu, Apr 17, 2014 at 10:49 AM, Martin Dorey martin.do...@hds.com wrote:

 The vsnprintf thing was (probably) fixed in git under
 http://savannah.gnu.org/bugs/?40361.

 From: Tom Kacvinsky [mailto:tom.kacvin...@vectorcast.com]
 Sent: Thursday, April 17, 2014 07:23 AM
 To: Bug-make@gnu.org Bug-make@gnu.org
 Subject: GNU make 4.0 crashes on Solaris 8

 I have successfully built GNU make 4.0 on a Solaris 8 machine, using GCC
 4.7.3 and Sun Studio 11, but when I run make check, make dumps core

 Core was generated by
 `/Datastore/Public/tjk/make/src/make-4.0/tests/../make -f
 work/features/se_expli'.
 Program terminated with signal 11, Segmentation fault.
 #0  0xff108ac8 in vsnprintf () from /lib/libc.so.1
 (gdb) where
 #0  0xff108ac8 in vsnprintf () from /lib/libc.so.1
 #1  0x0003dbd8 in vfmtconcat (fmt=0x5d26c prerequisites cannot be defined
 in recipes, args=0xffbfe8dc) at output.c:631
 #2  0x0003e038 in fatal (flocp=0xffbfe9e8, fmt=0x5d26c prerequisites
 cannot be defined in recipes, ...=0x2e68) at output.c:737
 #3  0x00042c30 in record_files (filenames=0x854d0, pattern=0x0,
 pattern_percent=0x0, depstr=0x854e0 proj1.c, cmds_started=1,
 commands=0x86840 , commands_idx=0, two_colon=0,
 prefix=9 '\t', flocp=0xffbfe9e8) at read.c:1951
 #4  0x00040160 in eval (ebuf=0xffbfeab4, set_default=1) at read.c:1008
 #5  0x0003ece4 in eval_buffer (buffer=0x866a0 proj1.o : proj1.c,
 floc=0x0) at read.c:482
 #6  0x00029bd8 in func_eval (o=0x7f140 e :  proj1.o $(eval $(test)),
 argv=0xffbfec08, funcname=0x5aec4 eval) at function.c:1352
 #7  0x0002af3c in expand_builtin_function (o=0x7f140 e :  proj1.o $(eval
 $(test)), argc=1, argv=0xffbfec08, entry_p=0x6f0b4
 $XA6sV5Q1G_TT35K.function_table_init+408)
 at function.c:2294
 #8  0x0002b41c in handle_function (op=0xffbfecf0, stringp=0xffbfecf8) at
 function.c:2415
 #9  0x00021754 in variable_expand_string (line=0x7f138 proj1.o e :
 proj1.o $(eval $(test)), string=0x833f8 proj1.o $(eval $(test)),
 length=-1) at expand.c:256
 #10 0x00021dcc in variable_expand (line=0x833f8 proj1.o $(eval $(test)))
 at expand.c:419
 #11 0x00022020 in variable_expand_for_file (line=0x833f8 proj1.o $(eval
 $(test)), file=0x886a0) at expand.c:478
 #12 0x00023c88 in expand_deps (f=0x886a0) at file.c:605
 #13 0x00023f34 in snap_deps () at file.c:688
 #14 0x00037a04 in main (argc=3, argv=0xffbffc0c, envp=0xffbffc1c) at
 main.c:2076

 Any ideas as to what is going on?  I would like to see if an issue I
 encountered in 3.82 (related to a file compiling twice when running make in
 parallel) is fixed in this version.

 Thanks,

 Tom



 ___
 Bug-make mailing list
 Bug-make@gnu.org
 https://lists.gnu.org/mailman/listinfo/bug-make


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #41518] Can't build make from Git repository with recent autotools

[Ray Donnelly]

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 along
with
 # this program.  If not, see http://www.gnu.org/licenses/.
+AUTOMAKE_OPTIONS = subdir-objects
 
 noinst_LIBRARIES = libw32.a
 
--- a/configure.ac  2013-10-20 15:20:16.93140 +0400
+++ b/configure.ac  2013-10-18 22:18:46.65020 +0400
@@ -46,9 +46,11 @@
 
 # Enable gettext, in external mode.
 
-AM_GNU_GETTEXT_VERSION([0.18.1])
+AM_GNU_GETTEXT_VERSION([0.18.3])
 AM_GNU_GETTEXT([external])
 
+AM_PROG_AR
+
 # This test must come as early as possible after the compiler configuration
 # tests, because the choice of the file model can (in principle) affect
 # whether functions and headers are available, whether they work, etc.


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?41518

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: [PATCH] output.c: Fix memory stomp when need==fmtbuf.size

[Ray Donnelly]

No problem Paul, thanks for replying.

I could've made it less intrusive by changing the test for whether to
reallocate to:

  /* Make sure we have room.  */
  if (need = fmtbuf.size)

.. instead (so just a single '=' character change) but when I see
assert (fmtbuf.buffer[len] == '\0'); it doesn't sit well with me
(looks like a bug at first glance) so I thought it better change it
the way I did. Feel free to ask that I change to '=', or just make
that change yourself (provided you agree with my analysis that is).

Cheers,

Ray.

On Mon, Jan 27, 2014 at 5:29 PM, Paul Smith psm...@gnu.org 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 real life
 but I should have a bit more free time later this week; I'll check out
 your fix.

 Cheers!


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[PATCH] output.c: Fix memory stomp when need==fmtbuf.size

[Ray Donnelly]

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 fixes this.

Best regards,

Ray Donnelly.


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/listinfo/bug-make

Re: mingw-w64 build breaks and warnings

[Ray Donnelly]

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 s...@nuwen.net wrote:
 Hi,

 make's HEAD is currently broken for mingw-w64, and is also emitting several
 warnings.

 I'm building http://git.savannah.gnu.org/cgit/make.git/commit/?id=f5f5adb
 with build_w32.bat gcc.

 The attached make-mingw-w64.patch fixes all errors and warnings, and
 shouldn't affect other platforms.


 Here are the build breaks:

 #1:
 job.c: In function 'free_child':
 job.c:1015:11: warning: passing argument 1 of 'strlen' makes pointer from
 integer without a cast [enabled by default]
OSN (fatal, NILF,
^
 In file included from c:\mingw\x86_64-w64-mingw32\include\io.h:10:0,
  from c:\mingw\x86_64-w64-mingw32\include\sys\stat.h:14,
  from makeint.h:71,
  from job.c:17:
 c:\mingw\x86_64-w64-mingw32\include\string.h:54:18: note: expected 'const
 char *' but argument is of type 'DWORD'
size_t __cdecl strlen(const char *_Str);
   ^

 job.c: In function 'new_job':
 job.c:1962:13: warning: passing argument 1 of 'strlen' makes pointer from
 integer without a cast [enabled by default]
  OSN (fatal, NILF,
  ^
 In file included from c:\mingw\x86_64-w64-mingw32\include\io.h:10:0,
  from c:\mingw\x86_64-w64-mingw32\include\sys\stat.h:14,
  from makeint.h:71,
  from job.c:17:
 c:\mingw\x86_64-w64-mingw32\include\string.h:54:18: note: expected 'const
 char *' but argument is of type 'DWORD'
size_t __cdecl strlen(const char *_Str);
   ^

 main.c: In function 'main':
 main.c:1984:11: warning: passing argument 1 of 'strlen' makes pointer from
 integer without a cast [enabled by default]
OSN (fatal, NILF,
^
 In file included from c:\mingw\x86_64-w64-mingw32\include\io.h:10:0,
  from c:\mingw\x86_64-w64-mingw32\include\sys\stat.h:14,
  from makeint.h:71,
  from main.c:17:
 c:\mingw\x86_64-w64-mingw32\include\string.h:54:18: note: expected 'const
 char *' but argument is of type 'DWORD'
size_t __cdecl strlen(const char *_Str);
   ^

 This was introduced by
 http://git.savannah.gnu.org/cgit/make.git/commit/?id=757849c . Each of these
 lines is saying (Error %ld: %s), which corresponds to ONS() (I'm assuming
 that's Output Number, then String).

 #2:
 w32err.c: In function 'map_windows32_error_to_string':
 w32err.c:70:3: warning: passing argument 2 of 'fatal' makes integer from
 pointer without a cast [enabled by default]
fatal(NILF, szMessageBuffer);
^
 In file included from w32err.c:19:0:
 ../../makeint.h:433:6: note: expected 'size_t' but argument is of type 'char
 *'
  void fatal (const gmk_floc *flocp, size_t length, const char *fmt, ...)
   ^
 w32err.c:70:3: error: too few arguments to function 'fatal'
fatal(NILF, szMessageBuffer);
^
 In file included from w32err.c:19:0:
 ../../makeint.h:433:6: note: declared here
  void fatal (const gmk_floc *flocp, size_t length, const char *fmt, ...)
   ^

 This call wasn't updated by 757849c. Since it has no arguments for the
 ellipsis, I believe it needs plain O().


 Then there is a severe warning:

 #3:
 main.c: In function 'prepare_mutex_handle_string':
 main.c:796:7: warning: format '%x' expects argument of type 'unsigned int',
 but argument 3 has type 'sync_handle_t' [-Wformat=]
sprintf (sync_mutex, 0x%x, handle);
^

 job.h typedefs sync_handle_t to intptr_t for WINDOWS32 (otherwise it's int).
 When intptr_t is 64-bit, %x is definitely wrong.

 Note that this sprintf() is guarded by #ifdef WINDOWS32 above, so we don't
 need to worry about other platforms. Using the MS length modifier, %Ix
 will work for both 32-bit and 64-bit builds.

 Also note that job.c 197 is already using this length modifier in sprintf
 (pidstring, %Id, pid);.


 Then there are innocuous warnings:

 #4:
 function.c: In function 'func_shell_base':
 function.c:1625:7: warning: variable 'errfd' set but not used
 [-Wunused-but-set-variable]
int errfd;
^

 #5:
 getopt.c: In function '_getopt_internal':
 getopt.c:679:8: warning: suggest explicit braces to avoid ambiguous 'else'
 [-Wparentheses]
  if (opterr)
 ^

 #6:
 job.c: In function 'reap_children':
 job.c:666:9: warning: label 'remote_status_lose' defined but not used
 [-Wunused-label]
  remote_status_lose:
  ^

 #7:
 job.c: In function 'construct_command_argv_internal':
 job.c:2667:9: warning: variable 'end' set but not used
 [-Wunused-but-set-variable]
char *end;
  ^

 These were all easy to fix.

 Thanks,
 STL

 ___
 Bug-make mailing list
 

Re: [PATCH] Use spawn() in GNU Make on Cygwin, updated

[Ray Donnelly]

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 p.fe...@samsung.com wrote:
 I really consider the use of Cygwin's spawn() deprecated and I'm not
 really interested in spending time on it.

  Why ? It is a way to significantly increase performance. And, before Cygwin
 has posix_spawn(), it is the only way to do it.
  I was following various fork() discussions, Microsoft is not interested in
 solving this because they say absolutely the same phrase about POSIX and all
 that. And, in fact, their phrase weights much more, because they already own
 the computing world.

 Kind regards,
 Pavel Fedin
 Expert Engineer
 Samsung Electronics Research center Russia


 ___
 Bug-make mailing list
 Bug-make@gnu.org
 https://lists.gnu.org/mailman/listinfo/bug-make

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: [PATCH 4/4] Windows: MSYS Autotools doc disabling hack

[Ray Donnelly]

I tried with various autoconf versions, including 2.65, and also with three
different versions of m4.exe ( all from
http://sourceforge.net/projects/mingw/files/MSYS/Extension/m4/ ) with both
dos and unix line-endings and each time ran into the same problem.

Eli, would it be possible to describe your environment?

I tar.xz'ed (hopefully all of) the pertinent files via the following:

git clean -dxf; autoconf -v -i -d  autoconf.log 21; tar -cJf
gnumake-autoconf.tar.xz autom4te.cache configure.ac acinclude.m4 configure
autoconf.log

I'm not sure if attachments work, or 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 e...@gnu.org wrote:

  Date: Tue, 16 Apr 2013 17:24:42 +0100
  From: Ray Donnelly mingw.andr...@gmail.com
  Cc: bug-make@gnu.org
 
  This is all, of course, with sources from git.
 
  If configure contains the line continuation ('\') in AC_CONFIG_FILES,
  then we end up with this lovely construct in configure:
  config/Makefile) CONFIG_FILES=$CONFIG_FILES config/Makefile ;;
  \) CONFIG_FILES=$CONFIG_FILES \ ;;
  doc/Makefile) CONFIG_FILES=$CONFIG_FILES doc/Makefile ;;

 I cannot reproduce this, with today's git head, which still has the
 backslash:

   # Specify what files are to be created.
   AC_CONFIG_FILES([Makefile glob/Makefile po/Makefile.in config/Makefile \
doc/Makefile w32/Makefile])

 After running autoreconf -i, I get this:

   # Handling of arguments.
   for ac_config_target in $ac_config_targets
   do
 case $ac_config_target in
   config.h) CONFIG_HEADERS=$CONFIG_HEADERS config.h ;;
   depfiles) CONFIG_COMMANDS=$CONFIG_COMMANDS depfiles ;;
   po-directories) CONFIG_COMMANDS=$CONFIG_COMMANDS po-directories
 ;;
   Makefile) CONFIG_FILES=$CONFIG_FILES Makefile ;;
   glob/Makefile) CONFIG_FILES=$CONFIG_FILES glob/Makefile ;;
   po/Makefile.in) CONFIG_FILES=$CONFIG_FILES po/Makefile.in ;;
   config/Makefile) CONFIG_FILES=$CONFIG_FILES config/Makefile ;;
   doc/Makefile) CONFIG_FILES=$CONFIG_FILES doc/Makefile ;;
   w32/Makefile) CONFIG_FILES=$CONFIG_FILES w32/Makefile ;;

 *) as_fn_error invalid argument: \`$ac_config_target' $LINENO 5;;

 Which looks perfectly fine.  Could it be that you have an old version
 of Autoconf?  (I use 2.65, which is also not new.)  Perhaps that bug
 was already fixed in Autotools?


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[PATCH 1/4] Windows: Add load.c to build_w32.bat

[Ray Donnelly]

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
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[PATCH 2/4] Windows: Add 'move' to sh_cmds_dos

[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!


Best regards,


Ray Donnelly.


0002-Windows-Add-move-to-sh_cmds_dos.patch
Description: Binary data
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[PATCH 3/4] Compile fix for when not using output-sync

[Ray Donnelly]

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

Re: [PATCH 3/4] Compile fix for when not using output-sync

[Ray Donnelly]

Oops!


On Tue, Apr 16, 2013 at 1:41 PM, Paul Smith psm...@gnu.org 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
Description: Binary data
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: [PATCH 2/4] Windows: Add 'move' to sh_cmds_dos

[Ray Donnelly]

Thanks Eli,

On systems where move *is* a built-in, gnumake fails as CreateProcess(NULL,
move ...) doesn't work.
On systems where move *is not* a built-in, my proposed fix is fine as
cmd.exe /c move still works.

Cheers,

Ray.


On Tue, Apr 16, 2013 at 2:59 PM, Eli Zaretskii e...@gnu.org wrote:

  Date: Tue, 16 Apr 2013 13:39:58 +0100
  From: Ray Donnelly mingw.andr...@gmail.com
 
  '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's not a bug, it is done on purpose: 'move' is a built-in on some
 versions of Windows, and a .exe program on others.

 Thanks.

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: [PATCH 4/4] Windows: MSYS Autotools doc disabling hack

[Ray Donnelly]

This is all, of course, with sources from git.

If configure contains the line continuation ('\') in AC_CONFIG_FILES,
then we end up with this lovely construct in configure:
config/Makefile) CONFIG_FILES=$CONFIG_FILES config/Makefile ;;
\) CONFIG_FILES=$CONFIG_FILES \ ;;
doc/Makefile) CONFIG_FILES=$CONFIG_FILES doc/Makefile ;;
(I tested with configure.ac containing both styles of line-endings and
both with the same result).

If we attempt to make doc, we end up with
make[2]: Entering directory `/gnumake/make/doc'
Updating ./version.texi
make[2]: *** No rule to make target `fdl.texi', needed by `make.info'.  Stop.
make[2]: Leaving directory `/gnumake/make/doc'

Which seems to be very similar to this old bug
report:http://osdir.com/ml/gnu.make.windows/2005-03/msg00077.html


Cheers,

Ray.

On Tue, Apr 16, 2013 at 3:01 PM, Eli Zaretskii e...@gnu.org wrote:

 Date: Tue, 16 Apr 2013 13:41:53 +0100
  From: Ray Donnelly mingw.andr...@gmail.com
 
  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.

 What are the bugs, and how do they manifest themselves?

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make