[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 16:20:20 +0100
Am 16.01.2014 um 14:46 schrieb Ingo Weinhold <ingo_weinhold@xxxxxx>:
> 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.
Well, if you want to compile with Clang and not have the CLANG variable I
defined, you would need to manually adjust all Jamfile. Not really a task for
someone who wants to try building Haiku with Clang.
> 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.
Yes, but it needs testing. So we need an easy way *now* that others can use to
build it. E.g. there are still *_server crashes when shutting down Haiku. And
we need to have automated builds people can download, test and report bugs on.
>> 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.
You could always update to a snapshot, I don't really see the problem. After
all, Haiku is still alpha and usually you use Haiku snapshots as well.
>
>> 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."
See above.
>> 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.
This is not GCC! I'm always using Clang from trunk. And this *never* caused any
issues (the only issue I ever had was a false warning that was wrong and was
fixed just a few revs later). Clang trunk is generally stable. Changes are
usually tested before they go in and there is a huge testing framework. All
tests need to pass before the change goes in. And *everything* gets a test
case. Patches that don't add a test case usually get rejected. Tests actually
check if the expected IL / assembly is generated. So if the tests pass, it
means that exactly the same code is generated as before the patch. Sure, a bug
can always slip in, but so it can in a release. And then you can just
upgrade/downgrade one snapshot instead of waiting for a new release. But you
can already see the huge difference in code quality if you just look at the
versioning theme: While GCC has x.y.z and usually releases a new version with
z=1 quite quickly after a new y, Clang uses x.y and there has never been the
need to release a x.y.z so far.
PLEASE, stop it with the assumptions that how GCC behaved for you is how Clang
will behave.
>> 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?
I do, as a Clang build takes up several gigabytes.
> 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.
… and that compiler was GCC.
We can easily get our changes upstream and Clang usually doesn't just break
stuff, *especially* in a release. So if one version of Clang works, there's
little reason to assume the next version doesn't. Again, this is not GCC!
And should we add a new feature that needs a compiler change, then all it means
is that we have to use Clang snapshots for AT MOST 6 months, but it might also
be a few days - I already succeeded in getting in a small, yet for some use
cases important, change into the release branch in the last minute.
But all this could all be solved by a minimum version. It could be set to a
version like 3.2, but it could also be set to a svn revision that adds the
required change if there hasn't been a release yet with that change.
> Having to wait a few months for the next official release is not an option,
> nor is using an unstable version.
And why is using a snapshot not an option? This is not GCC where existing code
breaks all the time! Please stop making the assumption that just because GCC is
crap all compilers are!
> 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.
That should be more like the last resort. I'd be fine with having an option to
build Clang, because e.g. your distribution won't upgrade in the near time or
because you would need to build a snapshot anyway. But I really wouldn't make
it the default.
Plus, if code works on one version, but breaks in the next, it usually means
your code was wrong and uses some undefined behaviour. E.g. BFS broke when I
compiled it with Clang - because it used undefined behaviour. So this might
actually even reveal bugs!
> 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.
While I really can agree with that for GCC, I still think it's overkill for
Clang. The two are completely different compilers.
--
Jonathan
Other related posts:
