net/wifi-firmware-*kmod: improve build logic, add flavors, update version

[bz]

Summary

• update framework to no longer depend on local distfiles for firmware(9) but generate the Makefile hierarchy in post-extract. Keep a Makefile.inc.in in files for simplicity.
• update extracting WHENCE parts using a local WHENCE.awk.in in files and a pattern to match the section(s).
• use the already prepared FWSUBS sections for flavors and add the FWDRV as "default". Generate the CONFLICTS_INSTALL conflict and PKGNAMESUFFIX entries. Adjust paths and logic for flavors. Depend on the flavors rather the combined ("default flavor") packages by default if someone installs wifi-firmware-kmod. The wifi-firmware-${name}-kmod packages are still built for older versions of fwget shipping in releases.
• add support for iwlwifi and ath12k firmware
• update firmware to linux-firmware.git tag: 20240410 for all drivers.

TODOs for the next iteration (to ease review for the current changes):

• use plain firmware files and no longer .ko where supported (currently in main)
• add the logic to deal with different versions and sets of files in different branches; currently this is still the old "one size fits all" logic which currently likely works for all but iwlwifi but for that stable branches still have firmware in src so we should be good.

Sponsored by: The FreeBSD Foundation

[jrm]

net/wifi-firmware-ath10k-kmod/Makefile

13–21

Flavors must be [a-z0-9_].

net/wifi-firmware-ath11k-kmod/Makefile

14–17

Flavors must be [a-z0-9_].

net/wifi-firmware-ath12k-kmod/Makefile

14

Flavors must be [a-z0-9_].

[bz]

net/wifi-firmware-ath10k-kmod/Makefile

13–21

Hmm I saw the comment somewhere (but probably did not think about that anymore).
Why does nothing in ports barf on this enforcing it but it "just work"?
I am probably asking the wrong questions.
Hmm show-dev-errors should barf.

DEV_ERROR+=             "FLAVORS contains flavors that are not all [a-z0-9_]: ${_BAD_FLAVOR_NAMES}"

I wonder which target I should have run and did not?

I'll go and fix...

net/wifi-firmware-kmod/Makefile

10

FLAVOR names MUSt be lower case here too then.

[jrm]

net/wifi-firmware-ath10k-kmod/Makefile

13–21

It does barf.

jrm@ser /usr/ports/net/wifi-firmware-ath12k-kmod [arcpatch-D44945|✔] % make
/!\ wifi-firmware-ath12k-kmod-20240410: Makefile errors /!\

FLAVORS contains flavors that are not all [a-z0-9_]: WCN7850_hw20

*** Error code 1

Stop.
make: stopped in /usr/ports/net/wifi-firmware-ath12k-kmod

[bz]

Rebuild all the wifi-firmware flavors from scripts, this time hopefully with lower case names.

[bz]

net/wifi-firmware-ath10k-kmod/Makefile

13–21

I did not get that error; and my shell script rebuilding things has set -e set so would also have stopped (and didn't).
I did check that I have work directories everywhere and things were built, but I indeed did not have packages for all of them.

Hope the update solves this.

[jrm]

The build now looks good to me. I asked a few minor questions below.

net/wifi-firmware-kmod/Makefile.inc

35

I'm unclear why this is necessary. bsd.port.mk includes

.    if !empty(FLAVORS) && empty(FLAVOR)
FLAVOR=	${FLAVORS:[1]}
.    endif

62–91

Can this simply be @${MKDIR} ${WRKSRC}/${FLAVOR}/fw?

[bz]

net/wifi-firmware-kmod/Makefile.inc

35

Otherweise it wasn't properly set in the .for loop in post-extract. That was the case with or without the intermediate variable. Given the ports handbook suggests it and I saw the same in some Uses/ (?) file and it helped, it's there. If there is a better solution I am all for it but it needs someone understanding the internals, which I am not and I do not want to spend 3 hours on figuring it out if avoidable.

62–91

Is MKDIR in ports guaranteed to always do -p ? Hmm looks like ../Mk/bsd.commands.mk:MKDIR?= /bin/mkdir -p; I'll fold this into one line in a minute and update the review.

[bz]

fold the three $MKDIR into one as suggested by @jrm.

[bz]

Update firmware to 20240513 (I have locally updated the commit message).
Also sort out some iwlwifi bits (we try to find the best supported
firmware version if the latest does not exist; may not have made a difference
to the lastet review version?)