5 ms·

Something interesting to note is that the complexity and internal coupling in GCC was an intentional design decision by GNU to make it harder for non-free softw

by tkahn6 14y ago

Something interesting to note is that the complexity and internal coupling in GCC was an intentional design decision by GNU to make it harder for non-free software projects to make use of gcc. Here's a pretty good talk about the philosophical motivations behind Clang and the current work being done on it: http://channel9.msdn.com/Events/GoingNative/GoingNative-2012/Clang-Defending-C-from-Murphy-s-Million-Monkeys http://channel9.msdn.com/Events/GoingNative/GoingNative-2012...

jmillikin 14y ago
Although the Clang developers claim GCC was poorly adapted to non-compiler use on purpose, the GCC developers seem to have been very eager to accept patches that make these use cases work better. If they were truly opposed to people using GCC as a module in a larger system, why would they go out of their way to encourage modularization? And please don't link to that RMS email as "evidence"; RMS has about as much control over GNU projects' technical details as Charles Manson does over the music industry.
- shardling 14y ago
  >If they were truly opposed to people using GCC as a module in a larger system, why would they go out of their way to encourage modularization? The claim I've seen repeatedly is that this is precisely because they must now compete with Clang/etc.
  - jmillikin 14y ago
    That implies that the previous lack of modularization was a practical decision, not a political or philosophical one. Implementation of the GCC plugins system started in 2008. Can you imagine the GCC team completely changing their philosophical stance almost overnight (Clang's first release was in mid 2007), just to get more users? It would be as if they'd relicensed to proprietary software to better compete with VC++. Previously GCC's primary competitor was ICC, and they were compared based on the quality of their output. Now GCC's primary competitor is Clang, and they compete on how user-friendly their interface is. Modularization is a user interface improvement, just like better error messages or more comprehensive warnings.
- masklinn 14y ago
  > If they were truly opposed to people using GCC as a module in a larger system, why would they go out of their way to encourage modularization? Because Clang happened.
- categoryjid 14y ago
  Do you have a link to that email? Interested to see what he said.
  - helmut_hed 14y ago
    This appears to be at least one of the source emails: http://gcc.gnu.org/ml/gcc/2000-01/msg00572.html http://gcc.gnu.org/ml/gcc/2000-01/msg00572.html
    - saurik 14y ago
      Another example (this time a private e-mail thread that was made public) is this one, which later became a massive discussion on the FreeBSD advocacy mailing list. Here, as a University project, someone wrote a backend for gcc that generated Java bytecodes (not like gcj, which bypasses most of gcc itself, but a true backend that could generate bytecodes from arbitrary front-ends, such as C). http://gcc.gnu.org/ml/gcc/2001-02/msg00895.html http://gcc.gnu.org/ml/gcc/2001-02/msg00895.html In this case, Stallman not only indicated that the code should not be accepted, but even requested that the code that had already been published be retracted. He felt that Java bytecodes were sufficiently high-level that they could be used as an intermediate language, allowing closed-source backends to be indirectly connected to gcc's frontends. FWIW, here again, it isn't clear whether going to RMS was even the right path; it could be that addressing the gcc mailing list in the first place would have caused a different discussion. In fact, even once posted to the gcc mailing list, the response was actually largely positive, although now somewhat colored into a discussion of the e-mail thread, and not the patch; I am not certain (but would love to know) why this patch then continued to not happen.
      - ecopoesis 14y ago
        I am really amazed and disturbed by this email. It seems so absurd that RMS is trying to hold back progress, and keep people from using and expanding gcc as they see fit. In the name of his twisted version of "freedom", he even tries to get Trent to censor the code from his site. I've always thought RMS was a little off, but I just chalked that up to the typical eccentricities of genius. This isn't just eccentric though: suppressing code in the name of freedom is just plain evil. I'm not sure how anyone can take RMS, and by extension the FSF that he controls, seriously anymore.
- Someone 14y ago
  http://gcc.gnu.org/wiki/GCC_Plugins http://gcc.gnu.org/wiki/GCC_Plugins is a good starting point. I have no reason to believe that page deviates significantly from what GNU's. stance was at some point in time.
- bcoates 14y ago
  Until around 2001, GCC supported U/WIN as a host and target platform. The FSF/RMS demanded they remove any code allowing that platform to work, so they did. The GCC project allowing technical decisions to be made for them for political reasons is not new.
  - jmillikin 14y ago
    That's because the UWIN support had been implemented in a way that caused distributors of GCC to be infringing copyright. This is no different than if the FSF discovered someone had copied proprietary code into GCC. In both cases, the solution is to remove the infringing code immediately. You might argue that compliance with copyright law is a "political reason", but I think you'd find that to be a very difficult position to defend.
- saurik 14y ago
  I remember being somewhat excited about the "GCC Introspector" project, which was a modification of GCC that allowed it to dump XML from various stages of GCC. I also remember that it was very negatively received on various occasions. You can use this situation to find non-RMS examples. By your own words, you've been working for three years on trying to get information out of GCC for use in other tools. Even if you have no intent of trying to attach proprietary back ends to GCC, you are working very hard to enable others to do so. ... > I think the GCC list has to ask itself how long are we going to wait before addressing the issues at hand, and not just ignoring the problem to death. As long as possible, because as long as there isn't a really clean way to attach proprietary front ends and back ends, people who are on the fence about going proprietary or submitting their code back will choose the latter. -- Joe Buck, http://gcc.gnu.org/ml/gcc/2002-02/msg01823.html http://gcc.gnu.org/ml/gcc/2002-02/msg01823.html (To note: James Michael Dupont, the person doing the work on Introspector, himself was perfectly fine with the licensing even being quite explicit that things attached to his XML data feeds would have to be themselves GPL. This was clarified, and people seemed to understand; however, his work was still being explicitly rejected as it could lead to proprietary backends.) You still think that I think you're a bad guy. I don't. Long-term, GCC is going to have to open up the interfaces. Our current policy is that we don't accept patches that do this, but we can't prevent others from doing it. -- Joe Buck, http://gcc.gnu.org/ml/gcc/2002-06/msg01392.html http://gcc.gnu.org/ml/gcc/2002-06/msg01392.html (Honestly, I'm not even certain this is the wrong attitude for the FSF to take, although it certainly is a futile one: you can always build in your own mechanisms to do this, or hell, use one of the new alternatives. It really seems somewhat important that the FSF has been around as long as they have been taking a stance that they refuse to water down; yes, it would be better if we all could work together without this kind of inanity, but the world isn't perfect.)

by tkahn6 14y ago

jmillikin 14y ago

Although the Clang developers claim GCC was poorly adapted to non-compiler use on purpose, the GCC developers seem to have been very eager to accept patches that make these use cases work better. If they were truly opposed to people using GCC as a module in a larger system, why would they go out of their way to encourage modularization? And please don't link to that RMS email as "evidence"; RMS has about as much control over GNU projects' technical details as Charles Manson does over the music industry.

shardling 14y ago
>If they were truly opposed to people using GCC as a module in a larger system, why would they go out of their way to encourage modularization? The claim I've seen repeatedly is that this is precisely because they must now compete with Clang/etc.
- jmillikin 14y ago
  That implies that the previous lack of modularization was a practical decision, not a political or philosophical one. Implementation of the GCC plugins system started in 2008. Can you imagine the GCC team completely changing their philosophical stance almost overnight (Clang's first release was in mid 2007), just to get more users? It would be as if they'd relicensed to proprietary software to better compete with VC++. Previously GCC's primary competitor was ICC, and they were compared based on the quality of their output. Now GCC's primary competitor is Clang, and they compete on how user-friendly their interface is. Modularization is a user interface improvement, just like better error messages or more comprehensive warnings.
masklinn 14y ago
> If they were truly opposed to people using GCC as a module in a larger system, why would they go out of their way to encourage modularization? Because Clang happened.
categoryjid 14y ago
Do you have a link to that email? Interested to see what he said.
- helmut_hed 14y ago
  This appears to be at least one of the source emails: http://gcc.gnu.org/ml/gcc/2000-01/msg00572.html http://gcc.gnu.org/ml/gcc/2000-01/msg00572.html
  - saurik 14y ago
    Another example (this time a private e-mail thread that was made public) is this one, which later became a massive discussion on the FreeBSD advocacy mailing list. Here, as a University project, someone wrote a backend for gcc that generated Java bytecodes (not like gcj, which bypasses most of gcc itself, but a true backend that could generate bytecodes from arbitrary front-ends, such as C). http://gcc.gnu.org/ml/gcc/2001-02/msg00895.html http://gcc.gnu.org/ml/gcc/2001-02/msg00895.html In this case, Stallman not only indicated that the code should not be accepted, but even requested that the code that had already been published be retracted. He felt that Java bytecodes were sufficiently high-level that they could be used as an intermediate language, allowing closed-source backends to be indirectly connected to gcc's frontends. FWIW, here again, it isn't clear whether going to RMS was even the right path; it could be that addressing the gcc mailing list in the first place would have caused a different discussion. In fact, even once posted to the gcc mailing list, the response was actually largely positive, although now somewhat colored into a discussion of the e-mail thread, and not the patch; I am not certain (but would love to know) why this patch then continued to not happen.
    - ecopoesis 14y ago
      I am really amazed and disturbed by this email. It seems so absurd that RMS is trying to hold back progress, and keep people from using and expanding gcc as they see fit. In the name of his twisted version of "freedom", he even tries to get Trent to censor the code from his site. I've always thought RMS was a little off, but I just chalked that up to the typical eccentricities of genius. This isn't just eccentric though: suppressing code in the name of freedom is just plain evil. I'm not sure how anyone can take RMS, and by extension the FSF that he controls, seriously anymore.
Someone 14y ago
http://gcc.gnu.org/wiki/GCC_Plugins http://gcc.gnu.org/wiki/GCC_Plugins is a good starting point. I have no reason to believe that page deviates significantly from what GNU's. stance was at some point in time.
bcoates 14y ago
Until around 2001, GCC supported U/WIN as a host and target platform. The FSF/RMS demanded they remove any code allowing that platform to work, so they did. The GCC project allowing technical decisions to be made for them for political reasons is not new.
- jmillikin 14y ago
  That's because the UWIN support had been implemented in a way that caused distributors of GCC to be infringing copyright. This is no different than if the FSF discovered someone had copied proprietary code into GCC. In both cases, the solution is to remove the infringing code immediately. You might argue that compliance with copyright law is a "political reason", but I think you'd find that to be a very difficult position to defend.
saurik 14y ago
I remember being somewhat excited about the "GCC Introspector" project, which was a modification of GCC that allowed it to dump XML from various stages of GCC. I also remember that it was very negatively received on various occasions. You can use this situation to find non-RMS examples. By your own words, you've been working for three years on trying to get information out of GCC for use in other tools. Even if you have no intent of trying to attach proprietary back ends to GCC, you are working very hard to enable others to do so. ... > I think the GCC list has to ask itself how long are we going to wait before addressing the issues at hand, and not just ignoring the problem to death. As long as possible, because as long as there isn't a really clean way to attach proprietary front ends and back ends, people who are on the fence about going proprietary or submitting their code back will choose the latter. -- Joe Buck, http://gcc.gnu.org/ml/gcc/2002-02/msg01823.html http://gcc.gnu.org/ml/gcc/2002-02/msg01823.html (To note: James Michael Dupont, the person doing the work on Introspector, himself was perfectly fine with the licensing even being quite explicit that things attached to his XML data feeds would have to be themselves GPL. This was clarified, and people seemed to understand; however, his work was still being explicitly rejected as it could lead to proprietary backends.) You still think that I think you're a bad guy. I don't. Long-term, GCC is going to have to open up the interfaces. Our current policy is that we don't accept patches that do this, but we can't prevent others from doing it. -- Joe Buck, http://gcc.gnu.org/ml/gcc/2002-06/msg01392.html http://gcc.gnu.org/ml/gcc/2002-06/msg01392.html (Honestly, I'm not even certain this is the wrong attitude for the FSF to take, although it certainly is a futile one: you can always build in your own mechanisms to do this, or hell, use one of the new alternatives. It really seems somewhat important that the FSF has been around as long as they have been taking a stance that they refuse to water down; yes, it would be better if we all could work together without this kind of inanity, but the world isn't perfect.)