On 21/02/11 10:12, Guillem Jover wrote:
This was already discussed in this list some time ago [0]. But it came
up again when restarting the discussion for the proposed new armhf port
for Debian.
[0]<http://gcc.gnu.org/ml/gcc/2010-07/msg00179.html>
My arguments for why a distinct triplet is needed can be found in [1],
it's a big long though. Most of the points there revolve around the
fact that we rely on the toolchains as configured by_default_ to
produce the expected output targetting a concrete architecture, it
also has implications for the file system paths.
[1]<http://lists.debian.org/debian-dpkg/2011/02/msg00039.html>
It seems from reading the past discussion on this list that the main
objection was that the triplet should not be used to decide what
floating point ABI to use in gcc. No problem with that!
Up front, let me say I disagree with the previous finding that the
triplet isn't the right place for this kind of thing. It's clear to me
that there's plenty of prior art here, and it would work for us very
nicely, thank you very much. That said, there are down-sides to
target-triplets (not least that once you've chosen one, you find
yourself stuck with it for backward compatibility, even after it makes
no sense any more), and many people seem to believe it would be better
if they had never been invented, so .....
I fail to see how abusing the OS/ABI field is any better than abusing
the vendor field?
The patch you posted is surely just the tip of the iceberg - there are
thousands of packages in Debian, and any one of them might need
adjustment to cope with this change.
When I proposed a new triplet before, in the thread you referenced
above, I proposed having an 'official' name that everyone would agree
on. That would have been disruptive. Your triplet would be unofficial,
so I would say it would be hard to justify all that disruption. In the
worst case, third parties would start to use your unofficial triplet
inconditionally, and would need fixing up to work with anything that is
not Debian.
In July's thread, it was decided (sort of) that the compiler should not
choose its (micro-)configuration based on the triplet. I didn't really
agree with that, but there it is. You've decided to stick with that, and
have the triplet influence only your build-system. Surely that's exactly
what the 'vendor' field is for? It seems like (it has to be) a
vendor-specific configuration to me.
Adjusting the vendor field should not break any of those thousands of
packages (although, no doubt there'll be the odd one or two). It will
give you your differentiated pathnames. It will tell your build-system
what to do. Why do it the hard way if there is no advantage?
Andrew