Bug#924052: debhelper: dh_auto_test should prefer 'make check' over 'make test'

2023-03-28 Thread Jerome BENOIT

Dear Maintainer,

I second the request by Benjamin.

According to the interesting discussion on a very near subject for igraph [1],
VSCode and cmake appear to attribute a different purpose to the target `test`.

For packaging igraph I set a workaround in the `d/rules`.
However, I guess that the `test` and `check` targets must be considered to have
different purposes according to some current standards.
That is, they are not interchangeable.

hth,
Jerome

[1] https://github.com/igraph/igraph/issues/2290


--
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B


OpenPGP_signature
Description: OpenPGP digital signature


Bug#924052: debhelper: dh_auto_test should prefer 'make check' over 'make test'

2019-03-08 Thread Benjamin Moody
Package: debhelper
Version: 10.2.5
Severity: wishlist

Dear Maintainer,

If a package is built using make, dh_auto_test should prefer to run
'make check' (which is the GNU standard [1]) rather than 'make test'.

This is doubly true for packages that use automake [2], but I think it
would make sense for all packages using makefiles.

The reason I see for preferring 'make check' is that it's common to
have a test program named 'test.c', 'test.sh', etc., and thus 'make
test' is an instruction to compile the test program rather than to run
it.  I suspect that this (combined with the fact that old versions of
make didn't support the notion of phony targets) is the reason for
GNU's choice of 'make check'.

That is to say, I suspect 'check' was chosen deliberately because it
was (and is) a less common term, and thus less ambiguous.

Note, I'm not proposing that dh_auto_test should ignore the 'test'
target; rather, in cases where *both* 'test' and 'check' are defined
(possibly by implicit rules), 'check' is the one that should be used
by default.

A third possibility would be to run 'make test check', on the
assumption that it's unlikely to be harmful to run both targets.
('make test check' would be better than 'make test && make check',
since the makefile might define the two as aliases of each other.)

There is of course no way to have a single rule that works for every
package.  However, my suspicion is:

- Packages for which 'make check' runs the test suite, and 'make test'
  incidentally does something different, are more common than packages
  for which 'make test' runs the test suite, and 'make check'
  incidentally does something different.

- The least surprising behavior would be to follow the behavior of
  automake and the GNU standards.

The second point is a matter of opinion, but the first is in principle
a testable hypothesis...


[1] GNU Coding Standards: Standard Targets for Users
https://www.gnu.org/prep/standards/html_node/Standard-Targets.html

[2] Automake manual: Support for test suites
https://www.gnu.org/software/automake/manual/html_node/Tests.html


-- System Information:
Debian Release: 9.8
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'stable-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-8-amd64 (SMP w/40 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages debhelper depends on:
ii  autotools-dev20161112.1
ii  binutils 2.28-5
ii  dh-autoreconf14
ii  dh-strip-nondeterminism  0.034-1
ii  dpkg 1.18.25
ii  dpkg-dev 1.18.25
ii  file 1:5.30-1+deb9u2
ii  libdpkg-perl 1.18.25
ii  man-db   2.7.6.1-2
ii  perl 5.24.1-3+deb9u5
ii  po-debconf   1.0.20

debhelper recommends no packages.

Versions of packages debhelper suggests:
pn  dh-make  

-- no debconf information