[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251014094511.627258-1-gtucker@gtucker.io>
Date: Tue, 14 Oct 2025 11:45:10 +0200
From: Guillaume Tucker <gtucker@...cker.io>
To: Nathan Chancellor <nathan@...nel.org>,
Nicolas Schier <nicolas.schier@...ux.dev>
Cc: Guillaume Tucker <gtucker@...cker.io>,
Miguel Ojeda <ojeda@...nel.org>,
rust-for-linux@...r.kernel.org,
linux-kbuild@...r.kernel.org,
linux-kernel@...r.kernel.org,
automated-testing@...ts.yoctoproject.org,
Arnd Bergmann <arnd@...db.de>,
workflows@...r.kernel.org,
llvm@...ts.linux.dev
Subject: [RFC PATCH 0/1] kbuild: introduce containerized builds
This proposal emerged from an email discussion and a talk at Plumbers
last year:
https://lore.kernel.org/all/affb7aff-dc9b-4263-bbd4-a7965c19ac4e@gtucker.io/
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
Powered by blists - more mailing lists