beside clang/llvm don't have feature parity with gcc nor offers better performance (i don't mean cute build logs i mean AVX/FMA, PGO, LTO, Graphite, OpenMP(<--for god sakes), etc).
beside this is a policy for main distro packagers it doesn't mean you can download clang and compile your X favorite app with it and publish in your X prefered Repo.
llvm/clang is a nice project but is not prime time ready nor is ready to replace GCC at least for 2 more years
2a.) Mac is mostly Objetive C where Linux is GNU/ISO C and C++(except maybe libre/open office)
2b.) Mac is extremely tied to very specific hardware so they can uber ultra optimize their clang code(reads not neccesatily available since clang in BSD licensed) where Linux run in almost any hardware known in these galaxy and even when you specify a target plataform like x86(and variants) you have to support several vendors (amd/intel/others) specific architectures and extensions/features(AVX/FMA/XoR/cache/etc) efficiently(and Michael has proved again and again that GCC is way faster even using default flags, if you add proper falgs and PGO/LTO that difference tends mostly to get only bigger)
so even if Apple have their ObjC branch uber optimized for their very specific set of hardware my point is still true Clang is not ready for prime time in the Linux world neither is more efficient or the binaries are faster than GCC and Clang only support a small subset of plataforms compared to GCC.
again im not saying llvm/clang sucks, i am saying it need to mature a lot more to be a real GCC replacement cuz today is a nice proof of concept with a nice future ahead but is not in the same league as GCC is
A couple side points:
* The LLVM/Clang/etc that Apple uses will never be the same LLVM/Clang/etc that everybody else uses.
* Also if you use LLVM/Clang/etc you can run into situations were things that are legal for Apple to do is illegal for you to do because of Apple's licensing agreements.
After all then why the hell would Apple want to run away from GPLv3 code? It's all about the patents that Apple controls, of course.
Because the packager is not in a position to know what is best for the software. They are the packager, not the developer. In addition the use of alternative toolchains has a cascading effect on the rest of the system. In the end it will create maintenance headaches and other unnecessary crap that everybody else will have to deal with.This is what I do not understand about this policy: Why not let the packager decide which compiler works better for the package?
If the package maintainer wants to use LLVM then the correct way to approach it would be to get involved in upstream development and work with them to port their code base over to using LLVM. THEN the appropriate compiler to use for the application would be LLVM and not GCC, and thus easily meet Fedora's criteria.
That is the correct approach. If you are going to fuck around with alternate configs and compilers and all sorts of other development decisions then the appropriate place to do that is with the developers, upstream. Not the package making level.
Before you make such assumptions, try to think, please. Apple binaries are signed for security reasons. GPLv3 would require Apple to hand over the sign keys (aka “TIVO clause”).
2.) well is logical they do since for example why waste binary space on AMD specifics or Exynos ARM specifics, if you only have access to Intel and A15 hardware? and making memory i don't recall those exists in macport-clang at all, so yes they mostly use their own branch of clang and prlly since they hardware is so static prolly they have many Next BSD/Mach/intel/A15 aggresive optimizations lying around that prolly no one else would use(maybe hackintosh ppl??), etc.
3.) well licence flame wars, all you say is true and fake at the same time, lets lawyer deal with it
4.) well clang only support x86 missing the previous topics and some ARM archs so is very unlikely a dev won't have access to that plataform besides packagers making changes downstream is a formula for a disaster, no decent distro should allow non upstream changes in their main distro packages especially in something so delicate as a compiler.
sure some very weird and specific software could run better using clang right now but the maintenance burden don't worth it but like i said no one is forbidden it in an external repo (ppa like or epel like, etc), so you are free to recompile fedora using clang if you want you just can't add them to the main repo