Since v6.10 the Linux kernel depends on Python to build, at least if you need support for the drm/msm driver (CONFIG_DRM_MSM=y).

This is used to generate headers from source xml during build, not an unreasonable scenario. I much prefer Python over C or Perl or shell scripting for this type of file and string processing.

Yet I'm unsure what the stance for the Python build dependency is among the powers that be. It may have snug in under their radar.

Should I try it with drm/i915...?

#kernel

@jani Sounds like a perfectly reasonable thing to do

@jani Documentation/Changes says Python is optional; that should be fixed at least.

@emersion @jani I concur

especially for hw headers generating them from the real source sounds so much better than the hundreds of megabytes of generated stuff we get otherwise

@jani yes

@pavel I suppose the meaning of "optional" in that file is not well-defined.

It's not required if CONFIG_DRM_MSM=n...

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=627395716cc36eff127aa81997b535818ab003fa

@sima @emersion I think we all agree the use case makes sense. It's using Python for this that makes me slightly uneasy, even though it would be my first choice if there were no restrictions.

Side note, looks like there's support for Rust hostprogs, with a caveat that "since a Rust toolchain is not mandatory for kernel compilation, it may only be used in scenarios where Rust is required to be available (e.g. when ``CONFIG_RUST`` is enabled)"

@jani @emersion maybe check with @airlied but since so much of the gpu userspace infra is python and especially the r/e register tools there's really no other choice

@sima @emersion @airlied This was in part inspired by the patch https://lore.kernel.org/r/20240906-macos-build-support-v2-3-06beff418848@samsung.com to xe_gen_wa_oob.c https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/xe/xe_gen_wa_oob.c

Like, yeah, the tool is "simple", but when you write it in C you get all these silly corner cases.

@jani Traditionally, "optional" means we ship the generated files in tarballs, so that end user does not need given tool. So I believe current situation is not ok.

@sima @jani @emersion I think that is a definite radar sneak, I haven't seen distro pushback but I would expect some

@jani cc @landley, who I know has very strong feelings about dependencies at build time

@rburchell @jani I've been trying to defend the core. My multiple years removing perl dependencies from the build didn't get them out of the raid subsystem etc.

Python is in an especially terrible dependency these days because it's developed a single magic implementation policed by its userbase and forcibly expired every few months:

https://landley.net/notes-2024.html#09-04-2024

No ruby/mruby, php/ph7 gcc/llvm/tinycc allowed, only "you must upgrade to the current version of Microsoft (tm) Word to read this file".

re: the ongoing deterioration of Python... how do you get this wrong?
https://mastodon.social/@nf3xn/113129649501654985

So you have your own language specific package repository, separate from the distro repository, because you decided something perl did was a good idea. Sigh. Ok.

But either you are installing packages into the current user's home directory and having $LANGPATH find them, or your installer goes SUID root to install them globally. PICK ONE. If you run pip as root, why doesn't it install in ~root/.pip ?