Suggesting that GCC is not following standards *on purpose* is just plain stupid though.
How is it lock-in if there's both documentation and code?
I'm not saying GCC avoids complience on purpose. If that's what you think because I've compared it to IE than that's incorrect. The development team was fired and is now in persuit of following standards (with BS extensions). Hell Windows 8 will use WebKit. You could as well compare it to FireFox.
I am just baffled at the releases. Shipping without full complience OK, but releasing new versions knowing you reduce complience is downright rediculous. What were the thinking?
Sure the is GCC optimized code. Sure EkoPath has never needed to compile non-supercomputer stuff or proprietary stuff from the beginning. But they target complience. For all we know what doesn't compile is not complient? (not stating that though)
But I've seen it elsewhere with GNU projects. For example KDE4 just does everything OpenGL the right way while Gnome 3 wants a ugly but working solution with the FLOSS drivers.
I don't get it. I would retract my complaints about GCC if they were to just focus on full complience before anything else.
About that lock in product; it's not lock in vendor. But can I compile GNU C with IBM C for example because I might like that compiler? No! What options do I have? Repackaging GCC? What good is that if I want a different compiler?
Once the Haiku devs feel to have the luxury to care about debugger integration in closed source IDEs, Clang is the natural choice as gdb simply can't be as tightly integrated into a non-GPL IDE.
Sure, today it's a low priority since GCC (2&4) work and the devs rather concentrate on more important stuff. So unless their attitude changed dramatically over the last 10 years (didn't follow that closely in the last 5), Clang will come as preferred compiler at some point.
Considering that even the today's “pragmatic” (and disillusioned about closed source adoption) devs still only port drivers from BSDs rather than Linux (even though Linux is often directly supported by the hardware vendors), it's pretty clear that they are not as “pragmatic” and “unideological” as you present them. The “pragmatic” way would be to simply get the best drivers and port them over no matter where they come from and no matter their license.
As for GCC offering compiler extensions, the reason Linux is chock-full of them is because the Linux kernel devs REQUESTED most of them from GCC in the first place. Hell, way back Linus was pissed because he felt GCC wasn't adding his requested extensions fast enough.
Now let's flip that coin, would the kernel devs have wanted these on a whim? No, they wanted them so that kernel development would be made easier and that they would be given better control of what code the compiler would generate.
This allows the kernel devs to benchmark their code for cache locality, branch-prediction etc and then give the compiler detailed instructions using extensions controlling that behaviour so as to maximize performance without resorting to assembly code.
That other developers outside Linux kernel development also finds these extensions desirable and choose to use them is also obviously not the fault of GCC.
Developers requested (in Linus case 'demanded') these extensions, as such developers will use these extensions.
If other compilers does not support these extensions, they will not be able to compile code in which the developers of said code CHOSE to use said extensions.
Now can we get back to Haiku here, plz!
MIT/BSD is obviously the preferred licence of the Haiku devs, else they would have switched ages ago, but as has been shown, Haiku is not about THE LICENCE. Where the licence have no effect on the core Haiku system, the best/practical open source solution is chosen rather than the one where the licence best correspond with MIT.