[haiku-commits] Re: haiku: hrev46660 - build/jam src/system/libroot/posix/glibc/stdio-common

  • From: Jonathan Schleifer <js-haiku-commits@xxxxxxxxxxx>
  • To: haiku-commits@xxxxxxxxxxxxx
  • Date: Thu, 16 Jan 2014 13:25:39 +0100

Am 16.01.2014 um 12:07 schrieb Stephan Aßmus <superstippi@xxxxxx>:

> But doesn't Clang build on all the platforms we support as host platforms for 
> a Haiku build? Why can't it work exactly like for GCC4 where it is build from 
> the buildtools source? For a whole operating system, having a known good 
> compiler version is a good idea. Our GCC2 is even heavily patched.

We could do that, but it's not a really good idea. Clang will take several 
hours to build on older systems. I think it even takes longer to build than all 
of Haiku. And it's not even necessary, as the host Clang will work: Clang is 
always a cross-compiler. So requiring a minimum version is enough. If we need 
to have more Haiku-specific changes, we need to get them upstream, not build 
our own Clang.

We could build our own Clang until there is a new release, but that is a waste 
of human resources: There's a new release every 6 months, and importing Clang 
into our repository and integrating it into the build seems like a huge waste 
of time if the problem can be solved by waiting at most 6 month. And we can 
always tell people to build Clang from trunk. Or install a snapshot from their 
distribution. But always building our own Clang would mean that people on e.g. 
an OS X system usually have 3(!) installed Clang versions: Apple's, upstream 
and Haiku's.

Anyway, current Clang builds Haiku just fine. As a matter of fact, it does so 
since 3.2 already. That's already quite old and I haven't seen a distribution 
which isn't at 3.2 yet. We would only have this problem if we decide to get rid 
of GCC completely, as then Clang would need to act as a linker as well. So that 
means we would have to wait at most 6 months until a Clang release can do that. 
In the meantime, we could just use GCC4. We need to have GCC4 and Clang at the 
same time anyway for at least some time. And we can patch Clang in advance, 
before we remove GCC4, so that distributions have a recent enough version of 
Clang at the time GCC4 is removed.


Other related posts: