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

2014-08-23 Thread Paul Eggert
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. When you see a file timestamp whose tv_nsec is nonzero modulo 100

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

2014-08-23 Thread David Boyce
On Sat, Aug 23, 2014 at 6:25 PM, Paul Smith wrote: > I pretty much agree with everything Paul says in this thread. And I tend to agree with David right down the line :-) But I guess two Pauls beat a David. ___ Bug-make mailing list Bug-make@gnu.org htt

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

2014-08-23 Thread Paul Smith
On Thu, 2014-08-21 at 13:57 -0700, Paul Eggert wrote: > David Boyce wrote: > > The obvious compromise would be to change the behavior only in the > > presence of the ".POSIX:" special target. > > We should limit ".POSIX" to what POSIX requires. Even if the ruling > stands POSIX won't require the

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

2014-08-23 Thread Paul Smith
On Sat, 2014-08-23 at 16:25 +0100, Ralph Corderoy wrote: > It seems a design flaw that I must > > make -sj clean && make -sj all && make -sj check && make -sj install Well, that's because you're only considering this use-case, where we know the context and it's clear that building them in par

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

2014-08-23 Thread Ralph Corderoy
Hi, I find it odd that -j breaks the idiomatic `make clean all check install'. Consider $ cat makefile #! /usr/bin/make -f SHELL = /bin/bash all: sleep 0.$$((RANDOM % 10)) && echo all clean:: sleep 0.$$((RANDOM % 10)) && echo clean check::