On 23.04.2014 20:36, Jonathan Schleifer wrote:
Am 23.04.2014 um 19:59 schrieb Ingo Weinhold <ingo_weinhold@xxxxxx>:I'm all for switching to clang eventually, but ATM making a decision would be premature. Once we have full clang support in the build system and everything turns out to work at least as good as with gcc, we can switch.I actually patched the missing things in the build system. Try ./configure with --use-clang. All that's missing is importing the sources, if we decide to go that way. For now it just uses the installed Clang, as that always is a cross-compiler.
IMO we can also go the HaikuPorts route -- i.e. source tar ball plus (optional) patch (or pre-patched tar ball) -- instead of importing the sources. As discussed a while back, waiting for the next official clang release is not a good solution when we run into an issue that requires a quick solution. So the option to build from the source is a must have. However, I wouldn't mind having the option to use a pre-built compiler (like already possible with gcc ATM (--cross-tools-prefix)).
Anyway, as long as using clang requires gcc I wouldn't consider the build system integration complete. The least that should be done (if it really isn't possible to get rid of the dependency) is to break the required parts out of the gcc package (we want to do that e.g. for the C++ runtime/standard library anyway) and make that package a mandatory build feature.
And afterward we can consider whether we drop gcc support. Though it might be a good idea to support both compilers anyway.I wouldn't drop GCC until Clang fully works, but we should at some point make it the default, if we want to go the Clang route. And we need to decide whether we want to go the Clang route. Because if not, working on these things is wasted time.
I doubt that anyone disagrees with having clang at least as an option. So I don't see how working on full support would be wasted time. Consequently no decision is necessary at this point.
CU, Ingo
