Provide standalone clang 8 project usable across all platforms

We plan to ship to clang 8 where a clang is needed in Firefox 68. We should create a separate project for it and retire the llvm one we have later on as the consensus seems to be to use "clang" instead of "llvm". This ticket is motivated as well by comment:43:ticket:28716.

Trac:
Parent Ticket: #28716 (moved)

added GeorgKoppen201907 TorBrowserTeam201907R component::applications/tor browser ff68-esr owner::tbb-team parent::28716 priority::high resolution::fixed severity::normal sponsor::44-can status::closed tbb-9.0-must-nightly tbb-rbm type::defect labels

bug_30585 (https://gitweb.torproject.org/user/gk/tor-browser-build.git/commit/?h=bug_30585&id=6af8cc6de4010ff0011a55dcefb4927e9e389872) in my tor-browser-build repo has a patch for review.

Trac:
Keywords: TorBrowserTeam201905 deleted, TorBrowserTeam201905R added
Status: new to needs_review

Moving reviews over to June.

Trac:
Keywords: TorBrowserTeam201905R deleted, TorBrowserTeam201906R added

Moving my tickets to June

Trac:
Keywords: GeorgKoppen201905 deleted, GeorgKoppen201906 added

No reviews in June 2019 anymore, moving them.

Trac:
Keywords: TorBrowserTeam201906R deleted, TorBrowserTeam201907R added

Moving my tickets to July.

Trac:
Keywords: GeorgKoppen201906 deleted, GeorgKoppen201907 added

Starting with 9.0 keywords

Trac:
Keywords: N/A deleted, tbb-9.0-must-nightly added

Replying to gk:

bug_30585 (https://gitweb.torproject.org/user/gk/tor-browser-build.git/commit/?h=bug_30585&id=6af8cc6de4010ff0011a55dcefb4927e9e389872) in my tor-browser-build repo has a patch for review.

This patch looks good to me.

In branch bug_30585 I added some minor improvements in fixup patches:

• With https://gitweb.torproject.org/user/boklm/tor-browser-build.git/commit/?h=bug_30585&id=aceef52a65523cec2ad4d97dae0c885e2e94dc09 we define gpg_keyring and sig_ext at the top of the file so we don't need to do it for each input files.
• with https://gitweb.torproject.org/user/boklm/tor-browser-build.git/commit/?h=bug_30585&id=f0c2046ecf2e9da1574ddd6d67395fa67399b00e we move all the patch into a win-patches directory, so we don't need to list all patches individually. We also use git apply instead of patch so we don't need to handle the binary file bigobj.o.gz separately. This required fixing paths in some of the patches as git apply doesn't like them. Looking at tor-browser/build/build-clang/build-clang.py I also see that mozilla is using patch to apply the patches, so I'm wondering how it works for them.

I squashed those two fixup commits in branch bug_30585_v2: https://gitweb.torproject.org/user/boklm/tor-browser-build.git/commit/?h=bug_30585_v2&id=4c2b3a98e04605ce7fcbd1c2c7c4864c6a5125a2

If you agree with those changes, I think it is ready to merge.

Looks good. Merged to master as 7b6444dd34d7a9e32d619c194e078464529fd5c1. I was a bit worried about creating yet another container-image by just using git for applying patch in the clang project. However, I think that's fine as it is a temporary measure only anyway as all the LLVM patches landed upstream (dunno either why patch is working for Mozilla but not for us, weird).

Trac:
Status: needs_review to closed
Resolution: N/A to fixed

Adding Sponsor 44 to ESR68 tickets

Trac:
Sponsor: N/A to Sponsor44-can

closed

moved to tpo/applications/tor-browser#30585 (closed)