On 2024-06-16 21:35, Jacob Bachmeyer wrote:
> I think we might best be able to avoid this by using AC_CONFIG_COMMANDS_POST
> to touch config.status if neccessary, instead of trying to decide
> whether to sleep before writing config.status.
If the problem is simply that we want to avoid the situati
Karl Berry wrote:
make(1) in AM_SANITY_CHECK seems to be a logic error, since the user
may want to build with a different $MAKE,
You're right. Crap. It never ends.
In practice it probably doesn't matter, though. Although in theory one
can imagine that "make" succeeds while $MAKE fails,
Karl Berry wrote:
Find here attached a revised proposed patch.
Ok on the reorg, but sorry, I remain confused. This whole thing started
with Mike Vapier's change in Feb 2022 (commit 720a11531):
https://lists.gnu.org/archive/html/automake-commit/2022-02/msg9.html
As I read it now, his goa
Two days ago, I wrote:
> Find here attached a revised proposed patch.
But I had missed the parallel 'sleep $am_cv_filesystem_timestamp_resolution'.
Sorry, I have to withdraw that patch as well.
Now, with the big picture that I gained by replying to Karl's
questions, here are two alternative, prop
Hi Karl,
> I understand that equal timestamps are considered up to date
Yes, except for old HP-UX 'make', which no one uses any more, all 'make'
programs consider equal timestamps as "up-to-date".
> Ok, but
> then why is configure generating config.status/etc. such a special case
> that it requi
make(1) in AM_SANITY_CHECK seems to be a logic error, since the user
may want to build with a different $MAKE,
You're right. Crap. It never ends.
In practice it probably doesn't matter, though. Although in theory one
can imagine that "make" succeeds while $MAKE fails, resulting in a fals
Find here attached a revised proposed patch.
Ok on the reorg, but sorry, I remain confused. This whole thing started
with Mike Vapier's change in Feb 2022 (commit 720a11531):
https://lists.gnu.org/archive/html/automake-commit/2022-02/msg9.html
As I read it now, his goal was to speed up ot
