On Sun, May 13, 2012 at 01:33:46AM -0400, Jon Masters wrote: > We could. Right now, for ARM (as an example), there is really about as > much representation as x86 from what I can see in terms of core arch > support. I'm sure upstream bits will be pulled in, and David and ajax > will do a great job - but unless I'm mistaken they're not offering to > take on the task of being a architectural maintainer for core x86 code. > On x86, we have Jeff's tools group within Red Hat that does an excellent > job of providing all of the kinds of behind-the-scenes support that an > architecture really needs. It's not just fixing build issues, or whether > stuff builds on ARM - it's known how and why specific instructions are > emitted and how that relates to the design. IOW it's a full time job to > support something like clang at the same level that we support gcc today > and I don't see that level available. Which bit of this doesn't apply to *any* package requiring a niche toolchain component? It would be problematic for packages to gratuitously migrate to llvm, but packages that actually depend on its functionality are as welcome in the distribution as anything written in ADA, go, falcon, R, AGI, Pure, Q, any of the lisps or any other compiler or interpreter we ship. Some of our toolchain components are much better supported than others, and obviously relying on one of the less supported ones is risky - unless anyone's willing to do the support work, it'll go away and so will all the packages that depend on it. Any maintainer is expected to understand that risk and make an appropriate and rational choice. >From a purely practical perspective, the popularity of OS X as a development platform means that we're likely to see a gradual increase in the amount of code written to assume LLVM-specific functionality. People are just going to have to cope. -- Matthew Garrett | mjg59@xxxxxxxxxxxxx -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
