On Fri, 16 Dec 2022 at 11:01:58 +0000, Ian Jackson wrote: > With nopython, we want to *avoid doing the Python things at all*. But > "the Python things" here isn't "all Python things" - it's "certain > Python things that appear in the outputs". So that can't be done as a > blanket exclusion on B-d.
As a concrete example of this distinction, src:vulkan-loader runs a Python script during build to regenerate some mechanically-generated C code, but its only end result is a C library and some C/C++ headers. In principle it would be possible to have a build-profile that makes it use the pre-generated version provided by upstream[1] instead of regenerating it, perhaps <prebuilt> or something, but that would be outside the scope of <!nopython> (and apparently not useful enough in this case for anyone to want to implement it). Conversely, the main end result of compiling src:avahi is a collection of C libraries (and a daemon and some tools), but it optionally also produces a Python module (and a non-essential Python program that uses it). Excluding those Python parts with <!nopython> is in-scope: it's reasonable to say "I want a C/C++ library stack with libavahi and others, but I don't care about any Python bindings" (for instance for use inside an app-container that is designed for C/C++ code). smcv [1] in the past the pre-generated version was used unconditionally, until #981362 changed the build to regenerate it unconditionally