RFC: Reworking build flags — Multiple toolchains support
Wookey
wookey at wookware.org
Sat Dec 2 02:43:01 GMT 2023
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/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-llvm-team/attachments/20231202/7da8d85c/attachment.sig>
More information about the Pkg-llvm-team
mailing list