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
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
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 troj...@gmail.com 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
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
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
