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 consis
On Mon, 02 Mar 2015 13:17:12 +0100, Shahbaz Youssefi wrote:
> I do have a related suggestion nevertheless. You see, no matter how
> many scenarios you think about, there is always some use-case that's
> going to be desired by someone but is unforeseen. Why not just create
> a general rule? My sugge
On 02 Mar 2015 13:17, Shahbaz Youssefi wrote:
> On Mon, Mar 2, 2015 at 12:18 AM, Peter Johansson wrote:
> > On 02/28/2015 02:07 AM, Shahbaz Youssefi wrote:
> >>
> >> To align this with the other -local rules, why not generate it like this?
> >>
> >> check-am: all-am check-local
> >> $(MAKE) $(
On Mon, Mar 2, 2015 at 12:18 AM, Peter Johansson wrote:
> On 02/28/2015 02:07 AM, Shahbaz Youssefi wrote:
>>
>> To align this with the other -local rules, why not generate it like this?
>>
>> check-am: all-am check-local
>> $(MAKE) $(AM_MAKEFLAGS) check-TESTS
>
> I think it would be a mistake
On 02/28/2015 02:07 AM, Shahbaz Youssefi wrote:
Hi,
The -local and -hook targets are generally used like this:
X: X-local
# stuff to do X
$(MAKE) X-hook
That is, X-local is run first, then the automake generated rules do X
and then X-hook is called.
With check-local, the generated M
Hi,
The -local and -hook targets are generally used like this:
X: X-local
# stuff to do X
$(MAKE) X-hook
That is, X-local is run first, then the automake generated rules do X
and then X-hook is called.
With check-local, the generated Makefile.in looks like this:
check-am: all-am
$(
