Re: Like C++? Not afraid of quirky build systems? Seeking LLVM co-maintainers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Hash: SHA1

On 05/11/2012 02:16 AM, Jon Masters wrote:
> On 05/10/2012 04:56 AM, David Airlie wrote:
>> Don't confuse llvm and clang, llvm has no equivalent in gcc
>> world, clang is a C compiler like gcc that uses llvm tech.
> Right so I wasn't confusing these :) However, we package both
> together and for ease of discussion many folks are going to think
> of it as a gcc alternative (aside from the specific gfx situations
> you and ajax have).
> My main concern was potential for growing use beyond that. I made
> an analogy about glibc to which I accept ajax's response that
> they're trying to reconcile with eglibc, but it's more the general
> concept I was getting at. Let me avoid a specific example because
> someone will find a way to find a hole in it :) Instead, my stance
> is we want to be very careful about unsupportable use of LLVM. I've
> filed a ticket with FESCo so hopefully there can be some debate as
> to acceptable use :)
>> It probably makes sense that one of myself, ajax or glisse help
>> out packaging llvm, but we aren't the most reliable people in
>> terms of spare time to commit.
> Right. You guys have various incentives to care about specific use
> of LLVM itself so I'm sure it will always be supported to some
> level, but for the other piece - clang+LLVM, etc. - to grow further
> use in the distro (in displacement of gcc) I feel we'd need to have
> actual RH staff to support it that I don't think we have any plans
> to have. So I want to cut this off at the pass before we blink and
> we have a problem.

Maybe we should draw more of a distinction between LLVM and clang, and
use ExclusiveArch: on the latter to whitelist only architectures we
feel comfortable supporting?

I'm at the moment not really comfortable switching LLVM to be built
with Clang as the default -- given that on Linux it has a brittle
dependency on specific versions of libstdc++. But we could certainly
make it a switchable build-time option.

Apart from the worrying test suite results on secondary archs,
actually it's the libstdc++ issue that's causing the most headache.
How much effort does it take to maintain a compatibility version of
libstdc++? It'd make clang much more useful if we're not caught
between upstream (that abandons released versions) and the Fedora GCC
team's fast update cycles.


- -- 
Michel Alexandre Salim
Fedora Project Contributor:

Email:  salimma@xxxxxxxxxxxxxxxxx  | GPG key ID: A36A937A
Jabber: hircus@xxxxxxxxxxxxx       | IRC: hircus@xxxxxxxxxxxxxxxx

()  ascii ribbon campaign - against html e-mail
/\   - against proprietary attachments
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla -

devel mailing list

[Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Legacy Announce]     [Home]     [Fedora Tools]     [Fedora PHP Devel]     [Kernel List]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Big List of Linux Books]     [Gimp]     [Yosemite News]

Add to Google Powered by Linux