RFC: Reworking build flags — Multiple toolchains support

[Helmut Grohne]

On Thu, Nov 30, 2023 at 01:35:17PM +0100, Guillem Jover wrote:
> This problem is related to the current (dpkg) policy where flags target
> the current default compiler and version for the specific vendor, but
> some of the flags emitted are toolchain specific and can break when
> used with another toolchain (say gcc vs clang for example).

As far as I can see, there currently is no support for toolchain
selection nor toolchain-dependent compiler flags. To put this another
way: Anyone who wants to build with a non-default toolchain not only has
to supply CC and friens but also CFLAGS and friends. While this is very
inconvenient, it readily works today.

> I guess the options are either introducing a global toolchain setting,
> for example a new CLI option and say global DEB_BUILD_TOOLCHAIN or
> similar, or one per flag type, for example DEB_CFLAGS_TOOLCHAIN or
> DEB_FCFLAGS_FOR_BUILD_TOOLCHAIN. But this would need to contain a
> generic term such as «gcc» or «clang», instead of a specific command
> to use such as «g++-13», or «clang-17».

I'm not sure whether per-setting toolchain actually is that useful in
the end. I would expect most users of this to want to change them all at
once. For instance, changing CC without to clang without also updating
CFLAGS accordingly is doomed to failure. The global setting very much
makes sense to me.

However, I think that both users building a package and maintainers of a
package may want to express a preference here much like compiler flags
have a "MAINT" variant that can be used from debian/rules without
overriding a user choice.

> The problem with a global selector is that maintainers (or tooling
> such as debhelper) might need to call dpkg-buildflags multiple times
> in case the build system uses different toolchains, or each different
> flag might in fact use a different toolchain by default already. So
> I'm inclined to go with a per flag selector.

Given that the use case of multiple toolchains is rare, I see little
problems with the requirement of calling dpkg-buildflags multiple times.
This doesn't seem like a use case we want to optimize for.

> This also ties with the variables for the actual toolchain and specific
> compiler tools being used (such as CC or CXX), where there is currently
> only partial support for this in the dpkg Makefile fragments, but not
> in dpkg-buildpackage or dpkg-buildflags proper. Ideally these would be
> set by dpkg-buildpackage so the tools and flags would be coherent, and
> as a side effect its arch detection from the toolchain would then be
> also consistent with the arch specified (#644664), but this cannot be
> done as debian/rules is still the supported entry point for builds.

Can we eventually challenge debian/rules being a supported entry point?
Practically, nobody does this.

> Setting this by dpkg-buildflags would be an option, and it is heavily
> related to its purpose, but it's a bit off relative to its name, but
> oh well. So I'm pondering to add support for setting compiler variables
> too (such as CC or CXX) in dpkg-buildflags, although that would only
> fix one aspect of the overall tool vs flags coherence.

This comes with another wrinkle. What do you set CC to when your
toolchain is clang and your host architecture differs from your build
architecture? I think the only correct way is to include the -target
option in the CC variable and that's going to trip up a lot of uses.
Until clang provides <triplet>-clang symlinks (which clang already
interprets correctly as far as I know), I don't clang as a supportable
toolchain given our interface. Also clang supporting pkgconf seems like
a requirement to me to become a first-class toolchain in Debian. Fixing
its many Multi-Arch: same violations also kinda feels like a requirement
to me. So I think, clang very much is not up to the task and needs
significant improvement in order to be considered. The current state is
so broken that it only works in exceptional circumstances by chance. I'd
object to it becoming easily selectable by maintainers given the current
problems.

Helmut