Re: RFC: Reworking build flags — Multiple toolchains support

Wookey <[email protected]> Sat, 2 Dec 2023 02:43:01 +0000

Newsgroups	gmane.linux.debian.devel.dpkg.general
Organization	Wookware
Message-ID	<[email protected]>

On 2023-11-30 21:10 +0100, Helmut Grohne wrote:

[lots of sensible things]

> 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 to clang without also updating
> CFLAGS accordingly is doomed to failure. The global setting very much
> makes sense to me.

agreed

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

That's not entirely true. I still do 'debian/rules clean' a lot and
'debian/rules binary' quite often. But I agree that if we need to run
dpkg-buildpackage to set up the right environment, then declaring that
to be the suppported interface is reasonable at this point. I do
recall 'debian/rules binary' being more reliable than
'dpkg-buildpackage -nc -T binary' in the past, but I forget why. 

> 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 class clang as a supportable
> toolchain given our interface.

Yes this has been a problem for many years and no-one has shown much
interest in fixing it over the last decade or so. Providing the
symlinks at least shouldn't be very hard?

Wookey
-- 
Principal hats:  Debian, Wookware, ARM
http://wookware.org/

signature.asc (application/pgp-signature, 833 B)