On 01/15/2014 04:46 PM, Jonathan Schleifer wrote:
Am 15.01.2014 um 11:49 schrieb Ingo Weinhold <ingo_weinhold@xxxxxx>:I had a closer look at the clang setup and I think before continuing with the jam part of the build system, the first step should be to set up a clang cross compilation environment that no longer depends on gcc.This is unfortunately not possible yet, I guess. Clang uses gcc as assembler and linker. We can force Clang to use its own assembler using -integrated-as. I already force the integrated assembler, as Clang currently blindly passes all -f flags to the assembler as well, making it fail at flags like -fheinous-gnu-extensions as GCC does not know them. However, that keeps the linker. So, unless we change linking to using ld directly, we're stuck with having a dependency on GCC 4.x for Clang.
>
This is unfortunate, but fixable in Clang itself. But that also means we need to wait until the next Clang release. The problem exists for many platforms which are not primary targets of Clang. E.g. on MinGW32, it also calls back into the MinGW32 GCC as assembler and linker, which causes configure scripts to fail if they use clang-only flags. So if we want to get GCC-free, we need to teach Clang how to invoke the linker directly on Haiku. I think this is something we should definitely in the future, and then raise our minimum Clang version.
For the time being (or probably even permanently) we could host "our" version of clang somewhere to avoid having to wait for the next official release.
BTW, I'm less concerned about calling the assembler and the linker than about the actual gcc dependencies like the glue code, libgcc, lib{sup,std}c++. I hope there are equivalent replacements for clang.
When it is clear how that can be done, the configure script should be adjusted to support clang. We'll probably want to define a jam variable HAIKU_COMPILER_<arch> to identify the compiler ("gcc", "gcc2", "clang"). Then we can refactor the related code in the jam build system. The current approach, fixing the compilation while not even using a proper compilation environment, is just backward.Yes, I very much agree that the current approach is only a hack. It's a hack so that it's possible to at least build a Clang-only build. So I think we should come up with 2 solution: One short-term solution and a long-term solution.
Since there's no real hurry, I'd rather do it right in the first place. Temporary solutions/hacks have a tendency to be rather long-lived.
As the Jam system seems to be not so well-understood by many Haiku developers and it seems you and Axel are the only ones who know enough about it / really care about it, I would suggest that we 3 have a discussion on IRC so we can talk through the different approaches and select the best one (we could even do that in German then, to make things easier), as the problem seems to be more complex than any of us thought at first. After that discussion, we could send another mail to the list summarizing our decision to document it. Do you two agree on that?
I believe you're right in that the knowledge about build system internals isn't particularly wide-spread, since most developers only interface with certain parts of the build system, like the Jamfiles or image/package content definitions (and that's fine, too). I guess, if anything, that's a reason for keeping discussions on-list.
That being said, I don't think there isn't that much left to discuss. I actually already started to work on refactoring the compiler specific parts until I noticed that due to the entanglement of clang with gcc that can't be cleanly done yet. Hence I'd rather see those disentangled first.
CU, Ingo