* Felipe Sateler <fsate...@gmail.com> [091118 23:39]:
>> You apparently fail to see that building the packages on mips uncovers
>> bugs that would otherwise be there, but take a longer time to uncover on
>> the 'mainstream' platforms.
>
> This is not generally true. There are are classes of bugs that appear on
> different platforms _due to being different platforms_, not just because
> they were latent bugs waiting to be discovered. I presume that packages
> that require as much efficiency as possible (like Charles is implying in
> his packages) are very likely to implement platform-specific
> hacks/optimizations to run faster. It can be considered bad design, ugly
> and whatnot, but it is irrelevant if nobody ever uses other platforms.
But even in this class lazily disabling build on obscure architectures
can have severe downsizes:
- the platform-specific hacks usually work (or are not an problem of the
slower architectures, because there are typically no hacks for them).
What in my experience breaks is the unoptimized fall back code path.
Having that one tested and working makes it much easier for future porters
for new architectures you might actually care for.
- platform-specific characteristica are not guaranteed to stay obscure.
I doubt amd64 would have had much more trouble if the alpha port would
not have had several years to fix all those little 64 bit errors.
(It would have been quite easy back then to claim that some strange
display errors in some little graphical games are not worth the
efford to fix as noone would buy and run an alpha to play games).
- a big issue outside i386 is alignment. People coming from i386 are
used to cast pointers without any ill effects. Having the other
architectures fixing this bugs makes not only i386 faster by avoiding
uncatched unaligned issuses. But it also future-proofes the code, as
even in x86 processors the new vectorisation support has alignment
requirements.
- very often only the more obscure architectures may break but that's
because some specific things in that architecture break some invalid
code, often supposed to be some clever "optimisation". While there
are optimisations that are valid C code and still platform specific,
there are more of them that actually misuse undefined behaviour.
While those "clever tricks" work now, they may break with every new
compiler version because new optimisations in the compiler easily
break the invalid code. Those are usually some of the most hardest
things to track down (which also explains why many "porting issues"
so often appear to intel-centric maintainers as making no progress,
as they usually take this time even if they hit a mainline
architecture. Only that this does not happen so often as it hit an
less common architecture first and was resolved there already).
Hochachtungsvoll,
Bernhard R. Link
--
"Never contain programs so few bugs, as when no debugging tools are available!"
Niklaus Wirth
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
