Re: RFC: Reworking build flags — «*_FOR_BUILD» flags handling
Hi Guillem,
On Thu, Nov 30, 2023 at 01:17:37PM +0100, Guillem Jover wrote:
> [ See <https://lists.debian.org/debian-dpkg/2023/11/msg00031.html>. ]
>
> This problem is related to the *_FOR_BUILD support (to specify flags for
> the build instead of host system during cross-building), which got
> recently partially improved (in dpkg 1.22.1), but there are still things
> not covered.
>
> These are at least two of the sub-problems that need to be tackled:
I am not sure whether these problems actually need solving, but saying
this I may curse myself in some years. ;)
> * Need to make features per-arch in output (such as --query), but that
> might break users not expecting repeated entries. I guess the options
> here might be to either:
>
> a) try to look for users of the interfaces and make them cope (but
> that would miss internal/private usage),
> [ If starting from scratch I'd rather do this, but it has now
> the potential for breakage. ]
> b) version the interface via a CLI option,
> [ This would be a general solution that would allow extensions in
> the future, but complicates the interface. ]
> c) add an explicit --for-build mode which would turn the output into
> the *_FOR_BUILD features,
> [ This is a targeted straightforward change, and a clear interface,
> but it involves running the tool twice to get all the info. ]
> d) or use different field keys for the paragraphs.
> [ This is rather meh. ]
e) dpkg-architecture -a${DEB_BUILD_ARCH} -f -c dpkg-buildflags --query-feature $SOMEFEATURE
This is roughly the same as c) and works today.
> None of which seem ideal (although some seem less desirable) TBH.
>
> * Need to honor build features, either from DEB_BUILD_OPTIONS or a
> new envvar (and finding a non-confusing name!), but probably only for
> a few of the features where it might really make sense (such as abi,
> qa, hardening.pie) and which might affect the buildability or
> runability of the artifacts, as anything else seems unnecessary.
>
> I'm not certain about the envvar part, I think the last part is in
> theory straightforward, the code just needs to duplicate the checks
> per the various arches, and keep track of the various features per arch
> internally, which might require breaking changes in the interfaces,
> but I think the perl modules are not public interfaces anyway.
In general, using a different variable than DEB_BUILD_OPTIONS seems a
difficult sell to me. For instance, DEB_BUILD_OPTIONS=noopt affects
build and host and to me that seems vaguely sane. Beyond that, I concur
with there being little need for configurability here.
Maybe this is just me being unimaginative.
Helmut
Reply to: