[Bug 270584] make -q exits 1 when there's no work to do

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270584

            Bug ID: 270584
           Summary: make -q exits 1 when there's no work to do
           Product: Base System
           Version: 13.1-RELEASE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: bin
          Assignee: bugs@FreeBSD.org
          Reporter: kreuter@progn.net

"/usr/bin/make -q" on 13.1-RELEASE-p7 exits with status 1 when there's no work
to do for an explicitly specified target file. This both contradicts the man
page, "Do not execute any commands, but exit 0 if the specified targets are
up-to-date and 1, otherwise", and is apparently incompatible with SUSv4's make
specfication at
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/make.html

Here's a pared-down reproduction: given this Makefile,

--
foo:
        touch foo

bar: foo
        sleep 1
        touch bar
--

Here is a commented transcript:

# Ensure foo and bar do not exist
$ rm foo bar
$ /usr/bin/make -q bar
$ echo $?
1
# The preceding 1 agrees with the man page and SUSv4.
# Now let's create stuff.
$ /usr/bin/make bar
touch foo
sleep 1
touch bar
$ /usr/bin/make -q bar
$ echo $?
1
# That 1 is disagrees with the manual and POSIX.
# There's no work to do, so it should be 0.

By inspection, both GNU make 4.4 and the "BSD make" available in MacPorts on
OSX exit 0 in the last case. 

N.B., ISTM that both the man page and SUSv4 don't fully specify what "make -q"
should do in all cases: the man page might be understood to only apply when
there are "specified targets"; and SUSv4 might be understood to apply only when
a target is a file. In the example above, "bar" is both a specified target and
a file, so I think that this example is in the intersection of the manual and 
the standard.

However, if anybody undertakes changing make, I'd request that -q cause make to
exit with status 0 whenever there's no work to do for all targets make is
considering, whether those targets are specified or implied, and whether
they're files or not. That behavior would, IMO, seem to be the most useful for
what it seems '-q' is for: asking make to determine whether there's any work to
do, irrespective of the nature of the target and how make's caller invoked it.

Here's system info, in case it's helpful for the bug report. I've got no local
patches or anything on this host:

$ uname -a
uname -a
FreeBSD ruk 13.1-RELEASE-p6 FreeBSD 13.1-RELEASE-p6 GENERIC amd64
$ freebsd-version -u
freebsd-version -u
13.1-RELEASE-p7

Please let me know if further information would be useful for this report.

-- 
You are receiving this mail because:
You are the assignee for the bug.