Ludovic Courtès <ludo@gnu.org> writes:

> Hello!
>
> Marius Bakke <mbakke@fastmail.com> skribis:
>
>> This is an update for LLVM and Clang.  I haven't yet found a package
>> that actually works with this new version; the consumers I've tested
>> does not support LLVM >4.
>>
>> However they can keep using the old version, and if there turns out to
>> be a problem with 6.0 we can fix it later since there are no dependents.
>
> Sounds good!
>
>> From 28e48a152c99c4c0911c794dd449c4df5ed193f5 Mon Sep 17 00:00:00 2001
>> From: Marius Bakke <mbakke@fastmail.com>
>> Date: Sat, 31 Mar 2018 22:04:44 +0200
>> Subject: [PATCH] gnu: llvm, clang: Update to 6.0.0.
>>
>> * gnu/packages/llvm.scm (llvm, clang-runtime, clang): Update to 6.0.0.
>> (clang-from-llvm)(patches): Set to empty list.
>> [arguments]: Set CLANG_RESOURCE_DIR in #:configure-flags.  Adjust
>> substitutions depending on major version.
>> (llvm-3.8, clang-runtime-3.8, clang-3.8): New public variables.
>> (clang-3.7, clang-3.6, clang-3.5)(patches): Add 'clang-3.5-libc-search-path.patch'.
>> (clang-3.9.1)(patches): Add 'clang-3.8-libc-search-path.patch'.
>> * gnu/packages/patches/clang-6.0-libc-search-path.patch: New file.
>> * gnu/packages/patches/clang-libc-search-path.patch: Rename to ...
>> * gnu/packages/patches/clang-3.5-libc-search-path.patch: ... this.
>> * gnu/local.mk (dist_patch_DATA): Adjust accordingly.
>>
>> Add CLANG_RESOURCE_DIR (not sure if needed).
>
> Hmm?

Oops, squashing error.  It turns out that was not needed and removed in
the updated patch below.

The updated patch fixes another problem: in 3.8 (the current "clang"
variable) and 3.9, the getDriver.ResourceDir substitution was actually
ineffective, so "clang-runtime" would never be referenced.

> Does this change the derivation of ‘llvm’ proper?  If not, this could
> even go to ‘master’.

LLVM is unaffected by this patch, only "clang" is changed.  So I believe
master is fine indeed.

However as it stands, many packages would break since the "clang"
variable changes from 3.8 to 6.0.  I'll test out each dependent and
see if they can be updated or change back to 3.8/3.9 for those.

I'm busy today, but can probably commit this tomorrow.  Meanwhile, how
does the updated patch look?

FWIW I've managed to build much of Chromium 65 with this new Clang; it
still fails, but I at least get further than with GCC 5 :-/