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

Michel Alexandre Salim salimma at fedoraproject.org
Sun May 13 05:21:53 UTC 2012


-----BEGIN PGP SIGNED MESSAGE-----
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.

Thanks,

- -- 
Michel Alexandre Salim
Fedora Project Contributor: http://fedoraproject.org/

Email:  salimma at fedoraproject.org  | GPG key ID: A36A937A
Jabber: hircus at jabber.ccc.de       | IRC: hircus at irc.freenode.net

()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPr0TxAAoJEEr1VKujapN6uZsIAIGhhi29Z81Ko9ayvsYqijfR
b7lpEwHihJBETbsFrP5zxqAIwdr5lIvE+Ox6thK9RIHdpICIurwO9rWQ0pparBqf
JLcsLeYfm96P7uoTWkjdwJTs9KHvntLtXJLek40vGq74vX43ysnNuI8vs2DqN0zB
8W10OIQfj1G7dw9tDtQjDKXZLc3mIki3lAAUesv78oSZNdFjkv28Go8K+Fku27uU
XQAmK3SzIApvSPAvjuemDruwU9M2TwXmVsUDlNLtI/LYRZfm1NikX+BfP/bNCelj
51aP1livuXdhqndrEMj5/6sL2V0ku1IAJtQgdutS9bgQIJzhm2E31Mr3uE3uSlM=
=iiGx
-----END PGP SIGNATURE-----


More information about the devel mailing list