This proposal emerged from an email discussion and a talk at Plumbers
last year:
https://lore.kernel.org/all/[email protected]/
The aim is to facilitate reproducing builds for CI bots as well as
developers using containers. It's achieved by providing a wrapper
around `make` in a separate Makefile. Here's an illustrative example
with a kernel.org toolchain in a Docker image from tuxmake:
$ make -f scripts/Makefile.container CONTAINER=tuxmake/korg-clang-21 LLVM=1
defconfig
Running in docker tuxmake/korg-clang-21
HOSTCC scripts/basic/fixdep
HOSTCC scripts/kconfig/conf.o
[...]
HOSTCC scripts/kconfig/util.o
HOSTLD scripts/kconfig/conf
*** Default configuration is based on 'x86_64_defconfig'
#
# configuration written to .config
#
$ make -f scripts/Makefile.container CONTAINER=tuxmake/korg-clang-21 LLVM=1
-j8
Running in docker tuxmake/korg-clang-21
make: warning: -j8 forced in submake: resetting jobserver mode.
SYNC include/config/auto.conf
GEN arch/x86/include/generated/asm/orc_hash.h
WRAP arch/x86/include/generated/uapi/asm/bpf_perf_event.h
WRAP arch/x86/include/generated/uapi/asm/errno.h
[...]
LD arch/x86/boot/setup.elf
OBJCOPY arch/x86/boot/setup.bin
BUILD arch/x86/boot/bzImage
Kernel: arch/x86/boot/bzImage is ready (#1)
The initial idea was to add an if-else block for when $(CONTAINER)
was defined directly in the top-level Makefile but this seemed too
intrusive, hence the approach here with a separate file. It's easy
enough to create an alias for development purposes if needed.
While the example above uses a tuxmake image, I've also started
preparing reference container images with kernel.org toolchains and
no third-party dependencies other than the base Debian distro:
https://gitlab.com/gtucker/korg-containers
These are convenient for exercising this feature but any arbitrary
image may be used of course.
Guillaume Tucker (1):
kbuild: add Makefile.container with CONTAINER option
scripts/Makefile.container | 15 +++++++++++++++
1 file changed, 15 insertions(+)
create mode 100644 scripts/Makefile.container
--
2.47.3
