Rationale for check-am depending on all-am? (automake)

Question

When Automake generates a Makefile, check depends on all: check-am: all-am.

What is the reason for this?

My guess would be, that it is necessary for recursive builds, because it is not known, which tests depend on which target and the targets must be correctly build, as otherwise the test results will be out-of-date. However if the dependencies are known, either by dependency information from the compiler or by using non-recursive builds, this is behavior is annoying, because targets are build, that aren't really needed.

Answer 1

When Automake generates a Makefile, check depends on all: check-am: all-am.

What is the reason for this?

A fundamental assumption made here is that when you run tests, you want to run them against the current code.

Another plausible assumption is that the test suite aims to cover the project as completely as possible, or at least that it is reasonable to act as if that were so.

In light of those assumptions, and without claiming to speak for the actual design decision by Automake's developers, there are at least two reasons why it makes sense for check-am to have all-am as a prerequisite:

1. If you want to run the whole test suite then it's essential to have a build of the whole project -- both because that's what you want to test, and because if you have any build failures then the project is not in a state suitable to be tested.

2. Although tests can be built programs, Automake's support for testing anticipates that they will often be implemented as scripts. When they are scripts, there is no good way to perform automatic dependency generation for them. Automake being unable to reliably generate precise prerequisites for running each test, but supposing that the tests have good coverage of the project, it's a simple and efficient solution to make execution of the test suite depend on the whole project being up to date.

My guess would be, that it is necessary for recursive builds, because it is not known, which tests depend on which target and the targets must be correctly build, as otherwise the test results will be out-of-date.

This is another good reason, along the same lines as (2) above.

However if the dependencies are known, either by dependency information from the compiler or by using non-recursive builds, this is behavior is annoying, because targets are build, that aren't really needed.

I don't know about your test suites, but mine indeed do aim for substantially full coverage. As a result, no, ensuring the whole project up to date as a prerequisite for running the test suite does not build any targets that aren't needed.