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
Description: PGP signature
