GNU bug report logs - #19961
check-local is kind of like check-hook

Previous Next

To reply to this bug, email your comments to 19961 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Shahbaz Youssefi <shabbyx <at> gmail.com>
To: bug-automake <at> gnu.org
Subject: check-local is kind of like check-hook
Date: Fri, 27 Feb 2015 17:07:27 +0100

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
    $(MAKE) $(AM_MAKEFLAGS) check-TESTS check-local

Now as far as the documentation is concerned, this is valid:

> 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.

However, even with not-parallel make, check-local executes after the tests.

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

The reason I actually have a problem with the current method is that
it is impossible to perform an action before the check. In my
particular case, my test scripts use test kernel modules. Of course,
automake doesn't have a target like check_KERNELMODULE for example to
automatically build the kernel module before running the tests. So
ideally what I could do is to build the kernel module in check-local.
The way the Makefile.in's are currently generated, this is impossible.

In my case, I had to use all-local to build the test kernel modules,
even if the user is not interested in make check, which is annoying in
the least.

Good day,
Shahbaz

---

P.S. I think it's all very clear, but just for good measure, here is an example:

=================================

configure.ac:

AC_PREREQ([2.68])
AC_INIT([Demo], [0.0], [demo])
AC_CONFIG_AUX_DIR([bin])
AC_CONFIG_MACRO_DIR([m4])

AM_INIT_AUTOMAKE([1.14 -Wall -Werror foreign])

AC_CONFIG_FILES([Makefile])
AC_OUTPUT

=================================

Makefile.am:

ACLOCAL_AMFLAGS = -I m4

check_SCRIPT = test_script

TESTS = $(check_SCRIPT)

check-local:
    @echo "*******************************************"
    @echo "*******************************************"
    @echo "I wanted this to be called before the check"
    @echo "*******************************************"
    @echo "*******************************************"

=================================

test_script:

#! /bin/bash

echo "Running test script"

Message #8 received at 19961 <at> debbugs.gnu.org (full text, mbox):

From: Peter Johansson <trojkan <at> gmail.com>
To: Shahbaz Youssefi <shabbyx <at> gmail.com>
Cc: 19961 <at> debbugs.gnu.org
Subject: Re: bug#19961: check-local is kind of like check-hook
Date: Mon, 02 Mar 2015 09:18:25 +1000

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 Makefile.in looks like this:
>
> check-am: all-am
>      $(MAKE) $(AM_MAKEFLAGS) check-TESTS check-local
>
> Now as far as the documentation is concerned, this is valid:
>
>> 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.
> However, even with not-parallel make, check-local executes after the tests.
>
> 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 to change this rule. Some projects might 
rely on the fact that 'check-local' depends on 'all-am' and 
'check-local' might e.g. run some of the programs built within 'all-am'.


>
> The reason I actually have a problem with the current method is that
> it is impossible to perform an action before the check. In my
> particular case, my test scripts use test kernel modules. Of course,
> automake doesn't have a target like check_KERNELMODULE for example to
> automatically build the kernel module before running the tests. So
> ideally what I could do is to build the kernel module in check-local.
> The way the Makefile.in's are currently generated, this is impossible.
>
> In my case, I had to use all-local to build the test kernel modules,
> even if the user is not interested in make check, which is annoying in
> the least.

With my Automake the rule looks like:

check-am: all-am
    $(MAKE) $(AM_MAKEFLAGS) $(check_SCRIPTS) $(check_DATA)
    $(MAKE) $(AM_MAKEFLAGS) check-TESTS check-local

so you could move your check_kernelmodule into check_DATA with something 
like (untested)

check_DATA = kernelmodule.timestamp

kernelmodule.timestamp:
    @echo "*******************************************"
    @echo "*******************************************"
    @echo "I want this to be called before the check"
    @echo "*******************************************"
    @echo "*******************************************"





Cheers,
Peter

-- 
Peter Johansson

Message #11 received at 19961 <at> debbugs.gnu.org (full text, mbox):

From: Shahbaz Youssefi <shabbyx <at> gmail.com>
To: Peter Johansson <trojkan <at> gmail.com>
Cc: 19961 <at> debbugs.gnu.org
Subject: Re: bug#19961: check-local is kind of like check-hook
Date: Mon, 2 Mar 2015 13:17:12 +0100

On Mon, Mar 2, 2015 at 12:18 AM, Peter Johansson <trojkan <at> 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 mistake to change this rule. Some projects might rely
> on the fact that 'check-local' depends on 'all-am' and 'check-local' might
> e.g. run some of the programs built within 'all-am'.
>

Fair enough. Wouldn't something like this address that issue?

check-local: all-am

check-am: check-local
     $(MAKE) $(AM_MAKEFLAGS) check-TESTS

>
> With my Automake the rule looks like:
>
> check-am: all-am
>     $(MAKE) $(AM_MAKEFLAGS) $(check_SCRIPTS) $(check_DATA)
>     $(MAKE) $(AM_MAKEFLAGS) check-TESTS check-local
>
> so you could move your check_kernelmodule into check_DATA with something
> like (untested)
>
> check_DATA = kernelmodule.timestamp
>
> kernelmodule.timestamp:
>     @echo "*******************************************"
>     @echo "*******************************************"
>     @echo "I want this to be called before the check"
>     @echo "*******************************************"
>     @echo "*******************************************"
>

Ok, I haven't seen check_DATA before (is that new in Automake 1.15?).
This could be a solution of course, although a bit strange, since the
kernel module is not really "data".

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 suggestion is to have for each target X, the
following two targets:

- X-pre is guaranteed to run before X
- X-post is guaranteed to run after X

This way, regardless of the target, anyone with whatever strange,
foreseen or unforeseen scenario, can use these two to extend the
operation of the target.

Kampai,
Shahbaz

Message #14 received at 19961 <at> debbugs.gnu.org (full text, mbox):

From: Mike Frysinger <vapier <at> gentoo.org>
To: 19961 <at> debbugs.gnu.org
Subject: [PATCH 1/2] automake: support check-hook target
Date: Sun, 20 Feb 2022 22:36:31 -0500

Related to automake bug https://bugs.gnu.org/19961.

Add hook support for the check target as requested by Shahbaz Youssefi.

* NEWS: Mention new check-hook.
* bin/automake.in: Run check-hook if defined.
* doc/automake.texi: Document new check-hook.
---
 NEWS              | 2 ++
 bin/automake.in   | 2 ++
 doc/automake.texi | 2 +-
 3 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/NEWS b/NEWS
index 665d8329d667..183825e8f2ed 100644
--- a/NEWS
+++ b/NEWS
@@ -29,6 +29,8 @@ New in 1.17:
   - Variables using escaped \# will trigger portability warnings, but be
     retained when appended.  GNU Make & BSD Makes are known to support it.
 
+  - The check target now supports user defined check-hook.
+
 * Obsolescent features:
 
   - py-compile no longer supports Python 0.x or 1.x versions.  Python 2.0,
diff --git a/bin/automake.in b/bin/automake.in
index 6d55884023cd..1a47865474f9 100644
--- a/bin/automake.in
+++ b/bin/automake.in
@@ -4670,6 +4670,8 @@ sub do_check_merge_target ()
   # Include user-defined local form of target.
   push @check_tests, 'check-local'
     if user_phony_rule 'check-local';
+  push @check_tests, 'check-hook'
+    if user_phony_rule 'check-hook';
 
   # The check target must depend on the local equivalent of
   # 'all', to ensure all the primary targets are built.  Then it
diff --git a/doc/automake.texi b/doc/automake.texi
index b6a38dc27ce5..b13f96809ce3 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -11609,7 +11609,7 @@ In contrast, some rules also have a way to run another rule, called a
 @dfn{hook}; hooks are always executed after the main rule's work is done.
 The hook is named after the principal target, with @samp{-hook} appended.
 The targets allowing hooks are @code{install-data},
-@code{install-exec}, @code{uninstall}, @code{dist}, and
+@code{install-exec}, @code{uninstall}, @code{check}, @code{dist}, and
 @code{distcheck}.
 
 For instance, here is how to create a hard link to an installed program:
-- 
2.34.1

Message #17 received at 19961 <at> debbugs.gnu.org (full text, mbox):

From: Mike Frysinger <vapier <at> gentoo.org>
To: 19961 <at> debbugs.gnu.org
Subject: [PATCH 2/2] automake: allow check-local to run early
Date: Sun, 20 Feb 2022 22:36:32 -0500

Fixes automake bug https://bugs.gnu.org/19961.

* NEWS: Note that check-local may run earlier that before.
* bin/automake.in: Allow check-local to run before check-am instead
of after like check-hook does.
---
 NEWS            | 5 +++++
 bin/automake.in | 7 +++++--
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/NEWS b/NEWS
index 183825e8f2ed..a4f3d6063073 100644
--- a/NEWS
+++ b/NEWS
@@ -31,6 +31,11 @@ New in 1.17:
 
   - The check target now supports user defined check-hook.
 
+* Miscellaneous changes
+
+  - The user defined check-local target may now run earlier in the check
+    process.  Users who want to always run at the end should use check-hook.
+
 * Obsolescent features:
 
   - py-compile no longer supports Python 0.x or 1.x versions.  Python 2.0,
diff --git a/bin/automake.in b/bin/automake.in
index 1a47865474f9..5a151455019e 100644
--- a/bin/automake.in
+++ b/bin/automake.in
@@ -4668,7 +4668,7 @@ sub handle_user_recursion ()
 sub do_check_merge_target ()
 {
   # Include user-defined local form of target.
-  push @check_tests, 'check-local'
+  $output_rules .= "check-local: all-am\n"
     if user_phony_rule 'check-local';
   push @check_tests, 'check-hook'
     if user_phony_rule 'check-hook';
@@ -4676,7 +4676,10 @@ sub do_check_merge_target ()
   # The check target must depend on the local equivalent of
   # 'all', to ensure all the primary targets are built.  Then it
   # must build the local check rules.
-  $output_rules .= "check-am: all-am\n";
+  $output_rules .= "check-am: all-am";
+  $output_rules .= " check-local"
+    if user_phony_rule 'check-local';
+  $output_rules .= "\n";
   if (@check)
     {
       pretty_print_rule ("\t\$(MAKE) \$(AM_MAKEFLAGS)", "\t  ", @check);
-- 
2.34.1

Message #22 received at 19961 <at> debbugs.gnu.org (full text, mbox):

From: Mike Frysinger <vapier <at> gentoo.org>
To: Shahbaz Youssefi <shabbyx <at> gmail.com>
Cc: Peter Johansson <trojkan <at> gmail.com>, 19961 <at> debbugs.gnu.org
Subject: Re: bug#19961: check-local is kind of like check-hook
Date: Sun, 20 Feb 2022 22:59:44 -0500

[Message part 1 (text/plain, inline)]

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) $(AM_MAKEFLAGS) check-TESTS
> >
> > I think it would be a mistake to change this rule. Some projects might rely
> > on the fact that 'check-local' depends on 'all-am' and 'check-local' might
> > e.g. run some of the programs built within 'all-am'.
> 
> Fair enough. Wouldn't something like this address that issue?
> 
> check-local: all-am
> 
> check-am: check-local
>      $(MAKE) $(AM_MAKEFLAGS) check-TESTS

should be doable to add check-hook (to support people who want to run at the
end) and to add check-local (to support people who want to run early).

although i think the right answer for you specifically is what Peter already
suggested -- use an existing check_XXX primary instead.

> > With my Automake the rule looks like:
> >
> > check-am: all-am
> >     $(MAKE) $(AM_MAKEFLAGS) $(check_SCRIPTS) $(check_DATA)
> >     $(MAKE) $(AM_MAKEFLAGS) check-TESTS check-local
> >
> > so you could move your check_kernelmodule into check_DATA with something
> > like (untested)
> >
> > check_DATA = kernelmodule.timestamp
> >
> > kernelmodule.timestamp:
> >     @echo "*******************************************"
> >     @echo "*******************************************"
> >     @echo "I want this to be called before the check"
> >     @echo "*******************************************"
> >     @echo "*******************************************"
> >
> 
> Ok, I haven't seen check_DATA before (is that new in Automake 1.15?).

no, it's been around for a very long time -- at least since Automake 1.5
from Aug 2001.  i didn't dive deeper in the source beyond that.

> This could be a solution of course, although a bit strange, since the
> kernel module is not really "data".

sure, but out of all the primaries Automake understands, what would you call
it ?  a program ?  a script ?  a library ?  from userspace pov, it might as
well just be "data".  i don't think adding support for LINUXKERNELMODULE makes
that much sense since it's not portable (beyond Linux), no one has asked for
it, and the way a kernel module is built is veeeery tightly coupled with the
exact version of Linux that you're building.
-mike

[signature.asc (application/pgp-signature, inline)]

Message #27 received at 19961 <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: vapier <at> gentoo.org, 19961 <at> debbugs.gnu.org
Subject: Re: 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.