So fine to remove from automake after all. Good!
So removed. Thanks to all. -k
On Sat, May 9, 2020 at 8:05 PM Harald van Dijk wrote:
> On 10/05/2020 02:10, Karl Berry wrote:
> > +Although we would like to remove this function from Automake, since it's
> > +not used, that would break older versions of Autoconf, which seems
> > +gratuitious. So we leave it, unchanged.
>
>
On 10/05/2020 02:10, Karl Berry wrote:
+Although we would like to remove this function from Automake, since it's
+not used, that would break older versions of Autoconf, which seems
+gratuitious. So we leave it, unchanged.
Autoconf has its own copy of this function, so why would it be affected
On Sat, May 9, 2020 at 6:10 PM Karl Berry wrote:
>
> Probably best to leave it, as is, and mark it as known-to-be-unused at
> least via comment.
>
> How does the text below look for an explanation?
Very good! Thanks for dealing with this.
Two suggestions below.
> (By the way, I noticed
Probably best to leave it, as is, and mark it as known-to-be-unused at
least via comment.
How does the text below look for an explanation?
(By the way, I noticed that FileUtils.pm, unlike the other *.pm in
lib/Automake, doesn't have an =over 4 ... =back around all the other
items,
On Mon, Apr 20, 2020 at 6:13 PM Karl Berry wrote:
> the command that updates autom4te.cache/traces.0 does not modify
> configure.ac at the same time.
>
> No argument for that specific case. But looking at the change in
> isolation:
>
> - if ($mtime < mtime ($dep))
> + if ($mtime
the command that updates autom4te.cache/traces.0 does not modify
configure.ac at the same time.
No argument for that specific case. But looking at the change in
isolation:
- if ($mtime < mtime ($dep))
+ if ($mtime <= mtime ($dep))
{
verb "up_to_date ($file):
On 2020-04-13, Paul Eggert wrote:
> I just checked, and GNU Make uses high-resolution file timestamps when
> available, and considers a file to be up-to-date if it has exactly the same
> timestamp as its dependency. I suspect that this is because Makefile rules
> like
> this:
>
> a: b
> cp
On Tue, Apr 14, 2020 at 08:06:14AM +0100, Harald van Dijk via Bug reports for
autoconf wrote:
> On 14/04/2020 04:34, Paul Eggert wrote:
> > On 4/13/20 4:21 PM, Harald van Dijk wrote:
> > > For better or worse, FAT is the most universally accepted file
> > > system, and for that reason it is
On 14/04/2020 04:34, Paul Eggert wrote:
On 4/13/20 4:21 PM, Harald van Dijk wrote:
For better or worse, FAT is the most universally accepted file system,
and for that reason it is widely used. It does not even support second
precision timestamps.
Let's not worry much about that. In practice,
On 4/13/20 4:21 PM, Harald van Dijk wrote:
For better or worse, FAT is the most universally accepted file system, and for
that reason it is widely used. It does not even support second precision
timestamps.
Let's not worry much about that. In practice, little development of
Automake-using
On 13/04/2020 23:58, Karl Berry wrote:
Hi Harald and all - well, Paul or Jim or any other automake worker will
know better than me, but my reactions, FWIW:
This caused intermittent failures in automake's t/subobj.sh test, which
This problem seems like the tip of the iceberg to me. With
Hi Harald and all - well, Paul or Jim or any other automake worker will
know better than me, but my reactions, FWIW:
This caused intermittent failures in automake's t/subobj.sh test, which
This problem seems like the tip of the iceberg to me. With this change,
any dependency which gets
On 11/04/2020 21:07, Paul Eggert wrote:
On 4/11/20 12:28 PM, Harald van Dijk wrote:
The up_to_date_p function uses mtime, which returns timestamps with
second precision. Even if it were capable of returning higher precision
timestamps, the file system might not support it.
These days file
14 matches
Mail list logo
