Clang and FSF's strategy
gcc.gnu.org
Clang and FSF's strategy
1–10 of 143 posts
Re: Clang and FSF's strategy
#2esr seems to conflate technical differences with political issues here. clang is not superior in some areas because it isn't GPL'd. It's because it is a newer project with more resources and different priorities. Sure, it attracted some developers who didn't like gcc's and the FSF's policies, but so do all kinds of crappy proprietary products. The point is, gcc doesn't need to relax its policies to better compete with LLVM, it just needs to become a technically better product. I don't buy the implication that it cannot become that without dropping some of the FSF's goals.
The gcc project is ancient and while I don't know the code base well, I'd assume that the fact doesn't necessarily help make it more approachable for new developers. Why can't a newer version of gcc be based on parts of LLVM, if the latter is considered superior by so many people? The licenses seem to allow it.
Re: Clang and FSF's strategy
#3Sounds like the open source vs free software debate all over again. I don't have a strong position in that one, but I find GCC's position rather obvious: They want to support free tools, and they explicitly don't want to support proprietary tools.
I cannot believe that this isn't obvious to esr, of all people. Is this just him trying to start a flame war?
edit: I'm now aware that esr is not talking about license restrictions but technical restrictions here. I have yet to find any evidence of technical restrictions for political reasons though, and it looks like the folks responding to him on the mailing list are not sure what he means either.
Re: Clang and FSF's strategy
#4esr trolling the gnu mailing lists...
Re: Clang and FSF's strategy
#5ESR may be incorrect; GCC has a plugin system. (YMMV)
http://gcc.gnu.org/ml/gcc/2014-01/msg00182.html / http://gcc.gnu.org/ml/gcc/2014-01/msg00181.html
Re: Clang and FSF's strategy
#6esr seems to conflate technical differences with political issues here. clang is not superior in some areas because it isn't GPL'd. It's because it is a newer project with more resources and different priorities. Sure, it attracted some developers who didn't like gcc's and the FSF's policies, but so do all kinds of crappy proprietary products. The point is, gcc doesn't need to relax its policies to better compete wit…
I think GCC receives a lot of undeserved hate at the moment. It is still a very good compiler which constantly improves. E.g., for my projects it generates better (faster) code. But still there are a lot of flame comments made against GCC. It was very similar when Chrome was released and suddenly the web was filled with flame comments against Firefox.
I think one problem is that many developers on Apple systems think the Apple GCC was state of the art. When in fact the latest release (a patched 4.1?) was rather old and obsolete. The Clang homepage still used to compares itself to GCC 4.1 instead of 4.8.2 or 4.9. It was similar when Chrome was released and Firefox was stuck on 3.6.1 waiting for 4.0. Sure Chrome was a lot faster but Firefox quickly caught on. But still people seem to think otherwise.
There is a GCC for LLVM, called DragonEgg http://dragonegg.llvm.org/. It is a _plugin_ (yes GCC has those since 4.5) for GCC. But I don't know what huge advantage it's supposed to bring. Especially when GCC seems to have the better backend (at least for my projects) at the moment.
I think the GCC folks should make the GCC Python plugin official because it provides a more stable and clean API (mentioned by ian lance taylor here: http://gcc.gnu.org/ml/gcc/2014-01/msg00181.html). They should continue with the transition for C++ (which will help to clean up the code base a lot, no matter what the C++ haters say) and increase the work towards modularization (http://gcc.gnu.org/wiki/ModularGCC that would probably allow making the frontend available as a library similar to libclang). Libgccjit could be very interesting as well http://gcc.gnu.org/wiki/JIT
Re: Clang and FSF's strategy
#7esr seems to conflate technical differences with political issues here. clang is not superior in some areas because it isn't GPL'd. It's because it is a newer project with more resources and different priorities. Sure, it attracted some developers who didn't like gcc's and the FSF's policies, but so do all kinds of crappy proprietary products. The point is, gcc doesn't need to relax its policies to better compete wit…
You are the one conflating technical differences with political issues. The problem with gcc is not the license, but the decision to architect the system so that the intermediate formats are not accessible to plugin developers. Plenty of the projects that LLVM has made possible have no beef at all in licensing under GPL, however, under the current design of the gcc they are flatly impossible to write for it.
This is because the FSF deliberately designed gcc not for technical goals, but to prevent access to intermediate formats without merging the compiler, because that would allow non-free plugins (as they wouldn't be derivative works of the gcc and so could choose their own license). Unfortunately, these choices not only restrict non-free work, but the technical decisions made prevent a lot of useful things from being made, and makes contributing to the project much harder than contributing to LLVM/Clang.
Re: Clang and FSF's strategy
#8Sounds like the open source vs free software debate all over again. I don't have a strong position in that one, but I find GCC's position rather obvious: They want to support free tools, and they explicitly don't want to support proprietary tools. I cannot believe that this isn't obvious to esr, of all people. Is this just him trying to start a flame war? edit: I'm now aware that esr is not talking about license rest…
No. It's not that at all. The GCC/LLVM debate has nothing whatsoever to do with licensing, but crippling the design of gcc for political aims. Educate yourself on the subject.
Re: Clang and FSF's strategy
#9esr seems to conflate technical differences with political issues here. clang is not superior in some areas because it isn't GPL'd. It's because it is a newer project with more resources and different priorities. Sure, it attracted some developers who didn't like gcc's and the FSF's policies, but so do all kinds of crappy proprietary products. The point is, gcc doesn't need to relax its policies to better compete wit…
> The point is, gcc doesn't need to relax its policies to better compete with LLVM, it just needs to become a technically better product.
gcc has an explicit policy against making the code modular and reusable, for political reasons (to make it hard to use individual pieces of GCC as independent programs, which could form part of a proprietary compiler toolchain). The point is, this political policy has made gcc's code technically inferior in some ways to clang (modular code, with separation of concerns and clearly defined interfaces between components, is a technically good thing). GCC can't resolve this technical problem without abandoning this policy.
> Why can't a newer version of gcc be based on parts of LLVM, if the latter is considered superior by so many people?
That would inherently mean abandoning this policy. And the answer is that while it's possible, the GCC codebase is still good, it still outperforms clang in many cases, and pulling in parts of clang would already require cleaning up and modularizing the GCC codebase - at which point we'd quite possibly end up with a compiler that's better than clang in all respects. So why not just do that?
Re: Clang and FSF's strategy
#10ESR may be incorrect; GCC has a plugin system. (YMMV) http://gcc.gnu.org/ml/gcc/2014-01/msg00182.html / http://gcc.gnu.org/ml/gcc/2014-01/msg00181.html
However, the interfaces are not stable across releases, making using the system sufficiently hard that almost no-one bothers.