Re: Proposed `cargo-upstream` dpkg-buildpackage etc. build profile
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
Reply to: