Could you provide some supporting arguments / evidence for this statement - "GCC used to be the king of the compiler heap; now it's well on its way to becoming an historical footnote." ?
* Microsoft is supporting CLANG.
* Android switched from GCC default to CLANG default.
* The CLANG development community, combined with the LLVM development community, are both extremely robust.
* GCC used to have full time commercial developer contributors working for Google and Apple and other large companies; most such companies have migrated almost entirely to CLANG/LLVM support.
* Because of better management and the army of full time commercial developers contributing to it, CLANG is better in practically every conceivable way at this point than GCC. If GCC weren't GPL, CLANG would likely be (at most) a fork of GCC, and may have been merged back into trunk by now (this happened to GCC once before).
CLANG is also an excellent example of how a completely permissive license can be sufficient to encourage big companies to contribute their changes back to the commons. All of the GPL fearmongering would have you believe that CLANG couldn't exist, and yet it thrives.
And printer drivers are still almost all proprietary [1]. So GPL didn't even achieve the objective that inspired it.
GPL did prove that open source CAN work, and it jumpstarted the open source movement. But its time has past; enough people understand the benefits of contributing to open source that the coercion is no longer necessary, and in fact is harmful.
[1] Some printer drivers have been reverse-engineered for Linux, certainly. But modern printers frequently leave so much processing for the host that their drivers are nontrivial, and even when there exists "free" drivers for Linux, they pale in comparison feature-wise to the proprietary drivers. I'm sure there are exceptions.
The GPL is not harmful and I encourage you to utilize it when appropriate for it protects you (the original author) and your target users far more than BSD or other similar licenses.
[1] http://llvm.org/pubs/2004-01-30-CGO-LLVM.html Read full paper not just the abstract to get the full picture.
gcc was in fact set up to explicitly not be able to do this.
The developers of gcc made understanding the intermediate forms as well as creating plugins as hard as possible specifically so that you couldn't get around the GPL.
clang a direct result of attempting to coerce people with real money with the GPL.
> gcc was in fact set up to explicitly not be able to do this.
GCC was originally very difficult to integrate with so that non-free programs could not be built on top of it. However, the creation of LLVM does not reduce to: "GCC was difficult to work with so we made this." There had been many attempts to make "Universal Compiler IRs". These attempts had not gone well. LLVM instead chose to do something at a unique level of abstraction that wasn't good for everything but was very good for its particular niche. Once again, read the paper, LLVM really wasn't created as a reaction against GCC.
And the reason I switched was because Clang had better error messages.
Thinking about Clang, its better design didn't evolve in a vacuum. Clang was primarily developed by Apple [1] so that they would have (with LLVM) a full compiler toolchain that didn't include GPL code (and as others have mentioned, Clang is designed to integrate with editors for parsing, while GCC is explicitly designed to be HARD to integrate that way so that it can't be snuck into a proprietary project).
YOUR choice to change to Clang may not have been about licensing, but licensing and design choices in support of that license philosophy are what caused Clang to exist.
They're already moving to encourage / require iOS devs to ship them LLVM IR code - the most logical reason for this is so that they can keep the last part of compilation entirely proprietary in future, taking further freedoms from users and developers.
They design and fab their own ARM chips already, so this is plausible.
See how that works? And despite Google's BS, I have plenty of ways to keep Android devices largely under my control. On that side of the fence, people stopped worrying and started modding en masse. :)
Further, mobile security vendors such as OK Labs w/ OKL4 let us isolate that mess while programming directly on the kernel or a custom runtime (think MirageOS for mobile). So, we have plenty of options because we aligned with a company doing open-source mobile with little lock-in. Align with closed-source and lock-in loving companies then you get what you had coming. ;)
The best part is that so many have jumped on the LLVM bandwagon. There's even a formal semantics to get formal verification work going. Mainstream coders, tool developers, and high assurance people all under the same roof contributing a bit to the same tool. Lots of potential there.
On the desktop, I believe that BSD was (a) hamstrung by the AT&T / BSDI lawsuit at a critical time and (b) suffered from fragmentation brought about more by incompatible forceful personalities than by technical issues.
Still shares some userland, but this is irrelevant.
For a true picture, look at how well their open sourced Darwin OS project is doing in terms of update and support.
Apple gutted the FreeBSD core team back in the 90s, hiring them all away.
But fairly similar userland.
Still shares some userland, but this is irrelevant.
I would say that for most people, the API matters far more than the kernel implementing it.
not open sourced
http://www.opensource.apple.com has the kernel sources under "xnu". I don't think that substantially less is open sourced than e.g. for Android.
look at how well their open sourced Darwin OS project is doing in terms of update and support
The updates are fairly current (10.10.1 corresponds to the version of OS X shipped last fall), though there doesn't seem to be a very large community building on it.
Those are proprietary forms. I think we were talking about whether the decision to be BSD-licensed has been good for the health and contribution of the *BSD projects that OS X and iOS originated from. Then we can draw a conclusion (but hopefully after gathering more data) on whether releasing your codebase GPL or BSD is more likely to lead to long-term health for that open source codebase.
https://www.phoronix.com/scan.php?page=article&item=clang-gc...
Show gcc and clang to be broadly competitive without a clear winner in terms of speed of execution.
I used to work for a company which produced a game-playing virtual machine. We had a toolchain that allowed building C and C++ programs for it. The toolchain was based on LLVM and gcc (because clang wasn't around at the time).
Integrating gcc into our toolchain was appallingly hard, solely due to GPL restrictions. The extra work in dividing everything into GPL and non-GPL parts, interfacing between the two, producing split packaging and distribution etc was basically half a full time job.
If the company had survived long enough for clang to have become stable --- which, sigh, it didn't --- we would have switched to it like a shot.