Re: Parallel Build, but Not for the Command-Line Targets.

2014-08-26 Thread dprovan
The discussion so far has been based on the idea that the user is expressing an order on the command line and will be surprised if that order is not followed. That definitely makes sense, and I was quite shocked to discover this problem. ("make -j clean all" does /what/?!) But when I ran into this

Re: [PATCH] Enhance/fix VMS setting of program name, MAKE/MAKE_COMMAND, variables

2014-08-26 Thread h.becker
On 08/26/2014 11:19 AM, Ralph Corderoy wrote: ... > progname = malloc(strlen(p) + 1); > > Can malloc fail on VMS? ... > if (0 == strcasecmp(&progname[len - 4], ".exe")) > > What if len is less than 4? Parsing the file specification myself wasn't a good idea. I sho

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

2014-08-26 Thread Keith Marshall
On 26/08/14 18:22, Eli Zaretskii wrote: >> Date: Tue, 26 Aug 2014 08:25:38 -0700 >> From: Paul Eggert >> Cc: Autoconf , Eric Blake , >> bug-make >> >> As far as Windows goes, NTFS file systems have 100 ns resolution, and >> FAT file systems are the joker as they have a 2-second resolution f

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

2014-08-26 Thread Keith Marshall
On 26/08/14 16:18, Paul Smith wrote: > Can't we just #define stat(_p,_b) _stat(_p,_b)? Not sure if that's > sufficient: I'm not overly familiar with the limitations on the POSIX > emulation functions in Windows. That's effectively what MinGW does anyway, (although it does it through an import lib

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

2014-08-26 Thread Eli Zaretskii
> Date: Tue, 26 Aug 2014 18:30:12 +0100 > From: Keith Marshall > CC: autoc...@gnu.org, ebl...@redhat.com, bug-make@gnu.org > > > FAT filesystems are hardly important these days. > > Except insofar as they tend to be prevalent on removable media devices, > such as USB flash drives; woe betide any

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

2014-08-26 Thread Eli Zaretskii
> Date: Tue, 26 Aug 2014 08:25:38 -0700 > From: Paul Eggert > Cc: Autoconf , Eric Blake , > bug-make > > As far as Windows goes, NTFS file systems have 100 ns resolution, and > FAT file systems are the joker as they have a 2-second resolution for > last-modified time. That's true, but F

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

2014-08-26 Thread Eli Zaretskii
> From: Paul Smith > Cc: egg...@cs.ucla.edu, autoc...@gnu.org, ebl...@redhat.com, bug-make@gnu.org > Date: Tue, 26 Aug 2014 11:18:35 -0400 > > > The main problem is that this requires to write a replacement 'stat' > > (not rocket science). > > Can't we just #define stat(_p,_b) _stat(_p,_b)? Not

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

2014-08-26 Thread Paul Eggert
Paul Smith wrote: It's trivial to determine the filesystem in POSIX via the device ID available from stat() Yes, that's what the Gnulib utimecmp module does: the idea is that after every stat-like operation you look at the file's time stamps to infer more information about the containing file

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

2014-08-26 Thread Paul Smith
On Tue, 2014-08-26 at 18:04 +0300, Eli Zaretskii wrote: > > (I don't know why Windows doesn't, because NTFS does support > > millisecond resolution timestamps I believe) > > Because no one wrote the code, of course. Ah, the oldest reason in free software :-). > The main problem is that this requ

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

2014-08-26 Thread Eli Zaretskii
> From: Paul Smith > Date: Tue, 26 Aug 2014 10:52:32 -0400 > Cc: Autoconf , Eric Blake , > bug-make > > Of course the ability to track filesystems could be added without too > much effort. It's trivial to determine the filesystem in POSIX via the > device ID available from stat(), of cour

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

2014-08-26 Thread Paul Smith
On Sat, 2014-08-23 at 18:33 -0700, Paul Eggert wrote: > Paul Smith wrote: > > > It needs to be considered carefully. > > How about having GNU 'make' do what GNU 'cp -u' does? > > The idea is to infer filesystem timestamp resolution by looking at every > file timestamp that crosses your desk. W

Re: Parallel Build, but Not for the Command-Line Targets.

2014-08-26 Thread Eli Zaretskii
> Date: Tue, 26 Aug 2014 15:03:34 +0200 > From: Reinier Post > > Maybe an interesting use case could be shells that don't support &&? There aren't any. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make

Re: [PATCH] Enhance/fix VMS setting of program name, MAKE/MAKE_COMMAND, variables

2014-08-26 Thread Paul Smith
On Tue, 2014-08-26 at 10:19 +0100, Ralph Corderoy wrote: > Can malloc fail on VMS? All calls to memory allocation in GNU make should use the x*() functions (xmalloc, xcalloc, xrealloc, xstrdup) which will stop the process if memory allocation fails. We don't attempt to recover from running out of

Re: Parallel Build, but Not for the Command-Line Targets.

2014-08-26 Thread Reinier Post
On Mon Aug 25 10:40:39 2014, ra...@inputplus.co.uk (Ralph Corderoy) wrote: > Hi Reinier, > > > > Yes, but it's an idiomatic one, oft suggested; "Unpack and run > > > `./configure && make all check install'". > > > > I don't get it. What is wrong with > > > > make -sj clean; make -sj all; mak

Re: [PATCH] Enhance/fix VMS setting of program name, MAKE/MAKE_COMMAND, variables

2014-08-26 Thread Ralph Corderoy
Hi becker, /* * Argv0 will be a full vms file specification, like * node$dka100:[utils.gnumake]make.exe;47 * the vms progname should be , the filename without * file type .exe and ;version (and there are some checks, * just in case something unexpected is passed an