[haiku-commits] Re: haiku: hrev46660 - build/jam src/system/libroot/posix/glibc/stdio-common
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Thu, 16 Jan 2014 14:46:46 +0100
On 01/16/2014 12:01 PM, Jonathan Schleifer wrote:
Am 16.01.2014 um 11:22 schrieb Ingo Weinhold <ingo_weinhold@xxxxxx>:
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.
Well, we need something to port it to Clang and test it first. Hacking files
individually and hardcoding flags for Clang then reverting that if you want to
compare is not an option at all.
I can't say I understand what you mean.
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.
That's why my current approach was "configure with GCC4, build GCC4, use a GCC4
environment - but actually compile with Clang". That's also what's done on most
Linux distributions. AFAIK, only Apple and FreeBSD got completely rid of GCC yet, so this
is no that easy. Our aim for the perfect solution should not stop us from getting there
via the pragmatic solution. We need the pragmatic solution first. Things need to work
well with Clang, then we can think about getting rid of GCC4.
I was under the impression you already did all the work to get Haiku
building. Anyway, I'm not opposed to pragmatic hacking. Do that as much
as you deem necessary. But what ends up in our repository should be
clean solutions.
On 01/16/2014 01:25 PM, Jonathan Schleifer wrote:> 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.
That doesn't matter all that much. That compiler only needs to be
rebuilt when it (or something that affects it) changes, which doesn't
happen all that often.
Besides, I suppose the build can be configured to omit stuff that we
don't need to shorten build times.
I think it even takes longer to build than all of Haiku.
That's probably also true for gcc 4 and gcc 2 (combined for sure).
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.
No one argues against getting changes upstream, but we cannot wait up to
six months for our changes to be available to our developers.
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.
Yeah, I can see how that will work: "Urgent build problem fixed. You
just have to wait a few months for the next clang release."
And we can always tell people to build Clang from trunk.
Sorry, but using unstable compiler versions is one thing that really is
not an option. There's a good reason why we have generally even avoided
gcc x.y.0 versions.
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.
Honestly, who cares?
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.
We do have more than a decade experience with maintaining our
compiler(s) and it simply is a fact that from time to time an issue
crops up that requires a change in the compiler. Having to wait a few
months for the next official release is not an option, nor is using an
unstable version. That leaves maintaining a copy of the last official
release with our patches applied. This isn't that much work,
particularly, if upstreaming patches is not a big problem.
Moreover, we actually want a well-known compiler version to be used.
That's a feature, not a bug. There are enough variables (hardware,
firmware) already that we don't need another one.
CU, Ingo
Other related posts:
