If we want to tell everyone to build their own LLVM then that's fine too,
but an even
more efficient way to do that would be to only produce binaries for a
z80 or something.
Er, that's not what I said. I said people should rely on distro packages,
which don't use our binaries at all.
Distros should produce a plethora or packages, suitable for most people.
What are they used for, if it doesn't warrant being user friendly? As
you say, anyone serious will be building their own. That just leaves
people who want to do some quick checks as far as I can see; surely
they want everything to be as easy as possible. Or why do we bother
with the entire fiasco?
You're probably getting it wrong, or I am. My view of the utility of these
packages is to:
1. Make sure they get tested as much as they can, and the behaviour of the
standard build (the one we use for development and some production
environments) is stable and correct.
2. Nothing else.
We can't test every single variation, so we test the one makes more sense.
What makes more sense to you, or Pekka, probably doesn't make to me or
someone else. Even the "most" used method can be so alien to the rest of
the community that it has little utility in the real world.
My view is that, building for the least common denominator and testing that
gives everyone else (or at least most part of it) a chance to compare back
to a minimal standard build. In any form or shape, with any set of options
for any target (you surely understand that from an ARM point of view, the
nightmare it is to get it right), we will fail. Miserably.
But this is the kind of thing that distributions get right on the spot.
They have the ability to cross-link dependencies in a way where all that
becomes seamless. They can describe and control dependencies of "llvm-rtti"
and "llvm-shared" in ways we could only dream of. So, why try to reproduce
a behaviour that is clearly a distribution problem only to fail?
People should not be re-compiling the sources all the time, in multiple
ways, and nor should we. Distribution packagers should be doing that for
I don't think there's even a guarantee that those binaries will work on any
given target... That alone should tell you *not* to use them under any