On 05/13/2012 01:21 AM, Michel Alexandre Salim wrote: <snip> > 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? 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. Therefore, if ExclusiveArch is a solution, it ought to be ExclusiveArch: none. Instead, while I think some arches do need to be considered for exclusion - for example, if you compare the build flags for gcc and llvm+clang today for non-ARM and non-x86 you'll see various stuff on ppc/s390x that (to me) raises some concerns just in terms of the build itself - I think more this should be "ExclusivePackage". I believe one should have to make a case for growing a dependence like this within the distribution. So we need it for soft rendering? Great. That's a wonderful exception to a general rule of not requiring it. I don't mean to sound anal, but we need to stop any growing in dependence on this until we're in a position to broadly support on any arches. (it's rather like how we have core packages depending on nonsense like ruby or python in the SPEC file just to do something that a shell escape could trivially have done ten years ago - if we don't make rules to stop this growth there, we're making it much harder to bootstrap - therefore rules do matter and we need them in this case before we start growing a dependence on something as core as a new toolchain) > 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. I think upstream also not providing "support" is another red flag to be honest. On the secondary arch front btw, I believe we have two problems on ARM: one is some tests are failing (not unique to ARM), and two I believe I am onto a heretofore not-well-isolated general futex bug that isn't related to LLVM/clang as a package. Anyway, I don't feel in a good position to comment on the libstdc++ resolution other than to again repeat my concerns about having any growth in dependency. Obviously don't take this personally! You do a great job Michel :) But it's become clear to me that supporting a toolchain in Fedora requires a team of folks to back it up that we don't seem to have here. Jon. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
