There are several ways of handling recursive targets. I found at least Mk/Scripts/do-depends.sh Mk/Scripts/depends-list.sh _FLAVOR_RECURSIVE_SH It looks that the latter has a couple of problems comparing to others. First, it does not handle '@' in a port name. Second, it would set FLAVOR to the empty value even if a package is not "flavored". That can confuse some ports. A fast demonstration of the second problem: $ make -C /usr/ports/lang/gcc9 checksum-recursive ... ===> native-binutils-2.33.1_4,1 depends on file: /usr/local/sbin/pkg - found ===> Fetching all distfiles required by native-binutils-2.33.1_4,1 for building ... Note how the package name is native-binutils instead of binutils. A longer demonstration of the problem would be with the package-resursive target. That issue was reported and analyzed some time ago, unfortunately with no action: https://www.mail-archive.com/freebsd-ports@freebsd.org/msg84543.html The proposed change brings _FLAVOR_RECURSIVE_SH closer to the other recursion methods and it should fix both of the problems: https://reviews.freebsd.org/D30579
Will fix with a slightly different patch. Note that portmgr is not omnipotent, while we read ports@, it is possible we miss things. For example, an mail thread that talks about lang/gcc9 does not strike me as something that I personally have any clue how to fix, it is for the lang/gcc9 maintainer. If nobody notifies portmgr of a problem, and there was no portmgr member taking part of the discussion, there is a good chance we won't see it. This is the reason we have a bug tracker, so that bugs get addressed to the right persons, and bugs don't get lost.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=e70bedf4f71eda15307b550cefd028a5a4b0281a commit e70bedf4f71eda15307b550cefd028a5a4b0281a Author: Mathieu Arnold <mat@FreeBSD.org> AuthorDate: 2021-06-01 07:04:25 +0000 Commit: Mathieu Arnold <mat@FreeBSD.org> CommitDate: 2021-06-01 07:16:35 +0000 Mk/bsd.port.mk: Don't pass up an empty flavor. The classic way to handle flavors is to set: FLAVORS= foo bar FLAVOR?= ${FLAVORS:[0]} And in that case, FLAVOR is only set if the variable is not defined. If you pass an empty flavor using `FLAVOR=` then it remains empty after that line. It can leads to some ports with complicated logic to assume the wrong flavor is set. PR: 256301 Reported by: avg Differential Revision: https://reviews.freebsd.org/D30579 Mk/bsd.port.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=bad84b3403f35e38153b86976e46a29ea1c30c9b commit bad84b3403f35e38153b86976e46a29ea1c30c9b Author: Andriy Gapon <avg@FreeBSD.org> AuthorDate: 2021-06-01 07:02:35 +0000 Commit: Mathieu Arnold <mat@FreeBSD.org> CommitDate: 2021-06-01 07:15:49 +0000 Mk/bsd.port.mk: Ignore @ in path in _FLAVOR_RECURSIVE_SH. While no port will ever have an @ in their path name, it might be possible that PORTSDIR has an @ somewhere in its path. PR: 256301 Differential Revision: https://reviews.freebsd.org/D30579 Mk/bsd.port.mk | 1 + 1 file changed, 1 insertion(+)
Thank you very much! Regarding that old thread, I actually expected that one of the participants would take a further action. I would never get interested in that thread myself, it just happened that I hit exactly the same problem. It seems that some of "-recursive" targets are not widely used these days.