[cfe-dev] [3.3 Release] Release Candidate 2 Available

[James Molloy]

But they're our design decisions that we really shouldn't be imposing
on everyone who wants to link against LLVM. 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.


Tim,

I don't really understand your logic here. We choose not to rely upon RTTI
and exceptions because they violate the "only pay for what you use" policy
of C++ - i.e. enabling them slows stuff down.

Why would we disable use of something for speed reasons but then enable
them when releasing? Isn't that somewhat pointless?

James

On 1 June 2013 22:39, Renato Golin <renato.golin at linaro.org> wrote:

> On 1 June 2013 22:18, Tim Northover <t.p.northover at gmail.com> wrote:
>
>> 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.
> Not us.
>
>
> 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
> them.
>
> 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
> circumstance.
>
> cheers,
> --renato
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130601/e912be6c/attachment.html>