6 ms·

For someone not following the project, what's the reason for deprecation and switch over to LLVM ?

by psibi 11y ago

earlz 11y ago
As someone messing with LLVM a lot.. basically LLVM is where a ton of development effort is going. GCC is a dead end it seems like. LLVM is designed to be extended where as GCC.. well, usually doesn't really seem to have been designed.
- fixermark 11y ago
  It, sadly, goes deeper than that, past architecture to philosophy. LLVM is designed to be modularized and embedded in other binaries and toolchains, which makes it easier to build extensions and tooling around it. In addition to having a mountain of legacy code, gcc's project steering is philosophically opposed to allowing non-free (as in GPL) plugins [https://lwn.net/Articles/582242/ https://lwn.net/Articles/582242/]. Because of this, developers looking for the most flexible toolchain seem to be backing slowly toward the exist regarding gcc, as the Clang / LLVM steering team has made clear that they don't see similar incompatibilities between their tool and the way developers choose to use it. There is a project going on to break the gcc down into components [https://gcc.gnu.org/wiki/rearch https://gcc.gnu.org/wiki/rearch], so time will tell what comes of these two toolchains.
  - alblue 11y ago
    I think you have a typo in exist -> exits? Either that or I couldn't understand the sentence.
    - fixermark 11y ago
      Yep. Thanks for catching. :)
  - chii 11y ago
    > gcc's project steering is philosophically opposed to allowing non-free (as in GPL) plugins I think that's the right philosophy. Why shouldn't you be contributing your plugin if you derive value from it, so that other people can derive value from it just as you did with GCC (if you distribute it that is - if you wrote it inhouse for internal use, then it doesn't matter at all!). It's not like the code generated by GCC is licensed virally. It's a shame that GCC's code is hard to modify, and difficult to extend. LLVM's permissive license means that contributions don't flow back unless it's favourable to the entity contributing it (such as good PR). I imagine that if somebody/some company wrote an excellent, non-obvious, non-trivial toolchain using LLVM, derive profit from it, they will not _want_ to contribute it back.
    - dietrichepp 11y ago
      The philosophy went farther than, "We want GCC plugins to be free." It went to, "We want GCC plugins to be basically impossible, because otherwise the risk of non-free plugins is too high." So, the FSF sacrificed technical needs in order to serve philosophical goals.
      - fixermark 11y ago
        And in essence, the market is interpreting onerous licensing as damage and routing around it (to bastardize a famous quote about Usenet) ;)
    - fixermark 11y ago
      > LLVM's permissive license means that contributions don't flow back unless it's favourable to the entity contributing it (such as good PR). There are multiple reasons to push code up the chain to the wider world beyond fuzzy feelings regarding your corporation. Never underestimate the benefits of outsourcing your code maintenance and integration costs. ;)
    - dgellow 11y ago
      There is no such thing as "the right philosophy".
- steve19 11y ago
  GCC has been designed specifically NOT to be extended. Richard Stallman reasoned that by exposing an interface to other applications, or allowing other applications to access or modify intermediate code/trees, closed source proprietary applications could be built around GCC. He was probably right ... but we all ended up with a worse compiler.
  - sprash 11y ago
    > worse compiler Last time I checked gcc binaries beat Clang performance wise.
    - whateveracct 11y ago
      performance is far from the only or most important measure of a compiler
  - fche 11y ago
    "GCC has been designed specifically NOT to be extended." Several extension mechanisms have been built out in the last few years, including plugins for intermediate passes of compilation, and a library to operate as a JIT.
    - netheril96 11y ago
      I wonder if that would ever have happened had LLVM not existed.
  - tadfisher 11y ago
    More than that; we ended up with a crippled Emacs. What could and should be a full-featured IDE built into a self-documenting programmable Lisp-derivative virtual machine is instead a continuation of the "good-enough" conglomeration of regexp-driven hacks that continues to drive new engineers to real and productive solutions produced by the likes of Microsoft. https://lwn.net/Articles/629259/ https://lwn.net/Articles/629259/
duaneb 11y ago
Cleaner, better documented, better interface, highly competitive performance, faster compiles, active development community, emscripten, better tooling/IDE integration. License is not viral.
- Solarsail 11y ago
  Those are all general issues that would apply to developing GCC, aside from compile times and tooling integration they don't effect NDK users. So the question goes back to being specific, why deprecate GCC while it's still popular elsewhere and well supported on this hardware? Eddyit: Spelshing.
  - duaneb 11y ago
    A), I think you mean "deprecate", it's been depreciating just fine by itself. B) If you ever want to make a change to the toolchain, HARD SWERVE on supporting GCC. It's a liability if you need to modify it at all. This may have more to do with what Google wants to support rather than any effect on the end user.

For someone not following the project, what's the reason for deprecation and switch over to LLVM ?

by psibi 11y ago

For someone not following the project, what's the reason for deprecation and switch over to LLVM ?

earlz 11y ago

As someone messing with LLVM a lot.. basically LLVM is where a ton of development effort is going. GCC is a dead end it seems like. LLVM is designed to be extended where as GCC.. well, usually doesn't really seem to have been designed.

fixermark 11y ago
It, sadly, goes deeper than that, past architecture to philosophy. LLVM is designed to be modularized and embedded in other binaries and toolchains, which makes it easier to build extensions and tooling around it. In addition to having a mountain of legacy code, gcc's project steering is philosophically opposed to allowing non-free (as in GPL) plugins [https://lwn.net/Articles/582242/ https://lwn.net/Articles/582242/]. Because of this, developers looking for the most flexible toolchain seem to be backing slowly toward the exist regarding gcc, as the Clang / LLVM steering team has made clear that they don't see similar incompatibilities between their tool and the way developers choose to use it. There is a project going on to break the gcc down into components [https://gcc.gnu.org/wiki/rearch https://gcc.gnu.org/wiki/rearch], so time will tell what comes of these two toolchains.
- alblue 11y ago
  I think you have a typo in exist -> exits? Either that or I couldn't understand the sentence.
  - fixermark 11y ago
    Yep. Thanks for catching. :)
- chii 11y ago
  > gcc's project steering is philosophically opposed to allowing non-free (as in GPL) plugins I think that's the right philosophy. Why shouldn't you be contributing your plugin if you derive value from it, so that other people can derive value from it just as you did with GCC (if you distribute it that is - if you wrote it inhouse for internal use, then it doesn't matter at all!). It's not like the code generated by GCC is licensed virally. It's a shame that GCC's code is hard to modify, and difficult to extend. LLVM's permissive license means that contributions don't flow back unless it's favourable to the entity contributing it (such as good PR). I imagine that if somebody/some company wrote an excellent, non-obvious, non-trivial toolchain using LLVM, derive profit from it, they will not _want_ to contribute it back.
  - dietrichepp 11y ago
    The philosophy went farther than, "We want GCC plugins to be free." It went to, "We want GCC plugins to be basically impossible, because otherwise the risk of non-free plugins is too high." So, the FSF sacrificed technical needs in order to serve philosophical goals.
    - fixermark 11y ago
      And in essence, the market is interpreting onerous licensing as damage and routing around it (to bastardize a famous quote about Usenet) ;)
  - fixermark 11y ago
    > LLVM's permissive license means that contributions don't flow back unless it's favourable to the entity contributing it (such as good PR). There are multiple reasons to push code up the chain to the wider world beyond fuzzy feelings regarding your corporation. Never underestimate the benefits of outsourcing your code maintenance and integration costs. ;)
  - dgellow 11y ago
    There is no such thing as "the right philosophy".
steve19 11y ago
GCC has been designed specifically NOT to be extended. Richard Stallman reasoned that by exposing an interface to other applications, or allowing other applications to access or modify intermediate code/trees, closed source proprietary applications could be built around GCC. He was probably right ... but we all ended up with a worse compiler.
- sprash 11y ago
  > worse compiler Last time I checked gcc binaries beat Clang performance wise.
  - whateveracct 11y ago
    performance is far from the only or most important measure of a compiler
- fche 11y ago
  "GCC has been designed specifically NOT to be extended." Several extension mechanisms have been built out in the last few years, including plugins for intermediate passes of compilation, and a library to operate as a JIT.
  - netheril96 11y ago
    I wonder if that would ever have happened had LLVM not existed.
- tadfisher 11y ago
  More than that; we ended up with a crippled Emacs. What could and should be a full-featured IDE built into a self-documenting programmable Lisp-derivative virtual machine is instead a continuation of the "good-enough" conglomeration of regexp-driven hacks that continues to drive new engineers to real and productive solutions produced by the likes of Microsoft. https://lwn.net/Articles/629259/ https://lwn.net/Articles/629259/

duaneb 11y ago

Cleaner, better documented, better interface, highly competitive performance, faster compiles, active development community, emscripten, better tooling/IDE integration. License is not viral.

Solarsail 11y ago
Those are all general issues that would apply to developing GCC, aside from compile times and tooling integration they don't effect NDK users. So the question goes back to being specific, why deprecate GCC while it's still popular elsewhere and well supported on this hardware? Eddyit: Spelshing.
- duaneb 11y ago
  A), I think you mean "deprecate", it's been depreciating just fine by itself. B) If you ever want to make a change to the toolchain, HARD SWERVE on supporting GCC. It's a liability if you need to modify it at all. This may have more to do with what Google wants to support rather than any effect on the end user.