bug-automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#19961: check-local is kind of like check-hook


From: Karl Berry
Subject: bug#19961: check-local is kind of like check-hook
Date: Wed, 23 Feb 2022 19:38:49 -0700

I think it would be a mistake to change where check-local runs,
in any way. In Peter's message, it is running after any $(check_DATA).
It does not seem that is still the case after your patch, Mike?
(As usual, I didn't actually try it. Sorry.)

Although it would be nice if there were perfect consistency from the
beginning about the names and timing of -hook and -local, I strongly
believe that trying to retrofit consistency is not worth creating
incompatibilities. Not at all.

To address the original request for something that runs before check-am,
I would instead suggesting creating a new check-pre instead of changing
check-local.

However, since the original case can be addressed otherwise, and there
are no other bug reports that require this (are there?), my actual
suggestion is to do nothing.

Except possibly to sharpen the rather annoyingly vague statement in the
manual about timing that was already quoted:

  With the `-local' targets, there is no particular guarantee of
  execution order; typically, they are run early, but with parallel
  make, there is no way to be sure of that.

which gives the user essentially zero information. Maybe it has to be
that way, but if, apart from check-local, the OP's description of
Automake's output as being

X: X-local

is correct, then we could at least say that "X-local" runs before "X",
except for "check-local". That does not change with parallel makes.

I admit the whole behavior of -local and -hook is rather unclear in my mind.

As for changing the names of -local and -hook: I agree -pre and -post
would have been better, but given the long history, I do not think it
would be good to change the names, or support alternative/preferred
names, just for the sake of names. That just seems like creating
unnecessary confusion. --best, karl.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]