Am 01.02.2026 um 01:53 schrieb Greg Troxel: > Roland Illig <roland.illig%gmx.de@localhost> writes: >> Am 28.01.2026 um 00:54 schrieb Greg Troxel: >>> I am testing an rc of ups-nut 2.8.5 (wip/ups-nut), and while it's mostly >>> ok, building on NetBSD 11 under pkgrsrc gets me: >>> >>> make[2]: warning: Invalid internal option "-J" in "/tmp/work/wip/ups-nut/work/nut-2.8.4.1239/tools"; see the manual page >>> >>> upstream doesn't think -J is in the sources. >>> >>> If I build MAKE_JOBS=1 (instead of 4 which my mk.conf defaults to), I >>> don't get the error. >>> >>> If I build -j4 in a subdir -- that provoked the warning from top level, >>> then I don't get a warning. >>> >>> Building on 9 or 10 does not get this error. >>> >>> Has anybody seen this? >> >> As the warning says, "see the manual page". In the diagnostics section, >> there is an extensive explanation of the warning, including a detailed >> approach to track down where exactly this warning comes from. > > I tried to read the man page before writing and didn't find it, but now > I do, in netbsd-11. > > I find this hard to follow: > > It says "-J private" but there are no hints about how to watch that > when debugging. Probably it's a unix-domain socket. Similar. It's a pair of pipes. The command line argument is typically "-J 15,16". > The warning is about a directory, but now I believe that it's really > about a sub-make invocation within a rule that is not labeled .MAKE, > and the location for the warning is the dir in which a make invocation > was troubled. But it doesn't give the makefile. An example output is: > bmake[2]: warning: Invalid internal option "-J" in ".../work/nut-2.8.4.1239/tests/NIT"; see the manual page > in bmake[2] in directory ".../work/nut-2.8.4.1239/tests/NIT" > in target "all/tests/NIT" > in bmake[1] in directory ".../work/nut-2.8.4.1239" > in target "all-fanout-maybe" > in bmake in directory ".../work/nut-2.8.4.1239" > in command "set -e; cd .../work/nut-2.8.4.1239 && cd .../wip/up... > in target "do-build" > in bmake[1] in directory ".../wip/ups-nut" > in command "set -e; if test -n "" && /home/rillig/pkg/sbin/pkg_info ... > in target "barrier" > in bmake in directory ".../wip/ups-nut" (I removed the duplicate stack trace. That's definitely a bug.) Usually, there is a single increasing sequence of "bmake[1]", "bmake[2]", and so on. In this case, the sequence is interrupted several times, which already looks suspicious, as it means that the MAKE_LEVEL environment variable is reset. This happens both in the pkgsrc part as well as in the package part. This is suspicious again, as the pkgsrc infrastructure doesn't mention MAKE_LEVEL or .MAKE.LEVEL.ENV anywhere. Back to the stack trace: The invalid option is detected when bmake[2] is run in tests/NIT. At this point, there is no makefile involved yet, thus no mention. The next lines reveal that the faulty bmake[2] is run from target "all/tests/NIT" in the main directory. At this point, bmake[1] could have revealed the location of the target "all/tests/NIT", but currently it doesn't record this information. $ grep -n all/tests/NIT Makefile ... 1856:all/tests/NIT: ... ... > I think I understand what's going on. The targets that call sub-makes > look like: > > ### Delivers: nut_version.h > all-libs-local/include: > +@NUT_VERSION_H_GENERATED=false; export NUT_VERSION_H_GENERATED; \ > $(SUBDIR_TGT_RULE) > > where > > SUBDIR_TGT_RULE = ( \ > ... \ > $(MAKE) ... \ > ... \ > ) > > > and this I think causes the "rule contains make" not to fire. Yes, exactly. To fire, the magic word "$(MAKE)" has to be directly in the rule, and in this case, only the word "$(SUBDIR_TGT_RULE)" is directly in the rule. > I wonder if -J is a concept in other BSD makes. In OpenBSD, parallel mode is implemented completely differently. For a heuristic, it looks at the expanded command, not the unexpanded and thus just works. > I wonder if the warning is new in 11, or if the behavior that can warn > is new. Yes, the warning is new in 11. > I wonder if you think not noticing the incorporated-by-reference $(MAKE) > is a bug/misfeature? I didn't think about it as a bug yet, but now that you mention it, the way OpenBSD does it makes more sense, it would free us from marking all the recursive targets explicitly as ".MAKE" targets. Roland