PACKAGE_BUILDING is already known in the ports tree as a variable
use to defined when the packages is being actually built in an
automation process, reuse that variable to define the default set
of kernel we plan to build for the default pkgbase.
Details
Details
- Reviewers
manu freebsd_igalic.co - Group Reviewers
pkgbase - Commits
- rG8bc5e4f54b40: pkgbase: set a default set of kernel for when PACKAGE_BUILDING=1
rG181cc65dc462: pkgbase: set a default set of kernel for when PACKAGE_BUILDING=1
rGdf6e7e11c5f6: pkgbase: set a default set of kernel for when PACKAGE_BUILDING=1
Diff Detail
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Skipped - Unit
Tests Skipped - Build Status
Buildable 54258 Build 51148: arc lint + arc unit
Event Timeline
| Makefile.inc1 | ||
|---|---|---|
| 1684 | We could add GENERIC-MMCCAM-NODEBUG for completeness, but given that we're planning on switching GENERIC-MMCCAM to the default, we might as well postpone that indefinitely. | |
Comment Actions
This will require a note somewhere for when we branch we need to switch -NODEBUG to -DEBUG etc ...
Comment Actions
I wonder if some sort of EXTRA_KERNCONF_${TARGET_ARCH} that gets added would be tidier.
Comment Actions
I thought about EXTRA_KERNCONF_${TARGET_ARCH} but I could find a way which was userfriendly, the goal being if a user sets KERNCONF we don't touch it, event if PACKAGE_BUILDING is set, if he hasn't and no PACKAGE_BUILDING is set we keep the current behaviour and if PACKAGE_BUILDING is set and no KERNCONF we have multiple kernels
Comment Actions
I don't see any immediate reason we couldn't .if exists(${KRNLCONFDIR}/GENERIC-DEBUG) or whatnot and act accordingly
Comment Actions
make the code more generic,
test the existance of the config
automatically switch between DEBUG and NODEBUG
| Makefile.inc1 | ||
|---|---|---|
| 1680–1684 | Should these not be DEF_KERNCONF_arch to match that they're feeding into DEF_KERNCONF not KERNCONF? Or perhaps GENERIC_KERNCONF_arch, since it's really about "what is the GENERIC-like thing I should be building"? | |
| 1683–1687 | ||
| 1695 | These don't make sense if GENERIC isn't the right thing for that architecture. It just so happens that there is no sys/powerpc/conf/{MINIMAL,GENERIC-MMCCAM} but were they to exist they would be 32-bit and you'd want MINIMAL64(LE)/GENERIC64(LE)-MMCCAM or some MPC85XXSPE thing. Certainly downstream we have aarch64c, which has sys/arm64/conf/GENERIC-MORELLO (and other variants), so this would pick up aarch64's non-Morello MINIMAL and GENERIC-MMCCAM, which would fall over if you tried to actually boot them with that world. | |
| 1711 | Stray? | |
| Makefile.inc1 | ||
|---|---|---|
| 1695 | yes but that would make it inconsistent, so I think it is an acceptable risk of failure. | |
| Makefile.inc1 | ||
|---|---|---|
| 1695 | What do you mean? It would be consistent. But this would try and build it for powerpcspe. | |