bcm5719-llvm/llvm/cmake, branch meklort-10.0.1 Project Ortega BCM5719 LLVM https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.1 2020-06-23T21:35:35+00:00 Make LLVM_APPEND_VC_REV=OFF affect clang, lld, and lldb as well. 2020-06-23T21:35:35+00:00 Nico Weber thakis@chromium.org 2020-01-17T00:04:08+00:00 urn:sha1:0777c907268a8197de102f3770432b0f185de30a When LLVM_APPEND_VC_REV=OFF is set, the current git hash is no longer embedded into binaries (mostly for --version output). Without it, most binaries need to relink after every single commit, even if they didn't change otherwise (due to, say, a documentation-only commit). LLVM_APPEND_VC_REV is ON by default, so this doesn't change the default behavior of anything. With this, all clients of GenerateVersionFromVCS.cmake honor LLVM_APPEND_VC_REV. Differential Revision: https://reviews.llvm.org/D72855 (cherry picked from commit fb5fafb23cc2d8613f8be2487afe94d8594a88ce) Fix spurious warning in ExtensionDependencies.inc [nfc] 2020-06-17T23:57:30+00:00 serge-sans-paille sguelton@redhat.com 2020-04-30T08:14:37+00:00 urn:sha1:3ca8b23cf5b9afc4ea05ac0533fbb874c5660e1d (cherry picked from commit 37309fb02f60557f18971dc575904c0fc56c91ab) Use components instead of libraries in Polly linkage step 2020-06-17T23:57:30+00:00 serge-sans-paille sguelton@redhat.com 2020-04-18T06:14:52+00:00 urn:sha1:576559ed5d0805120d3729db24b33d00489be5f8 As a side effect, this tests (and fix a bug) in the compiler extension handling of components. Differential Revision: https://reviews.llvm.org/D78358 (cherry picked from commit e849e7a700907441ee82ace9d0a9555ae7eb9811) Do not declare compiler extension member as const 2020-06-17T23:57:30+00:00 serge-sans-paille sguelton@redhat.com 2020-04-24T09:44:42+00:00 urn:sha1:2f6b23d4d00ce08e71f1046158efe209aa01fcd1 It keeps them default constructible. (cherry picked from commit e307eeba0137700e75893089cf0de03383d851ca) Update compiler extension integration into the build system 2020-06-17T23:57:30+00:00 serge-sans-paille sguelton@redhat.com 2020-04-20T10:39:32+00:00 urn:sha1:5f510e51dd4e6de5987a162f232c514a4dc8b0e3 The approach here is to create a new (empty) component, `Extensions', where all statically compiled extensions dynamically register their dependencies. That way we're more natively compatible with LLVMBuild and llvm-config. Fixes: https://bugs.llvm.org/show_bug.cgi?id=44870 Differential Revision: https://reviews.llvm.org/D78192 (cherry picked from commit 8f766e382b77eef3102798b49e087d1e4804b984) [nfc] Cleanup extension header generation 2020-06-17T23:57:30+00:00 serge-sans-paille sguelton@redhat.com 2020-04-20T12:43:21+00:00 urn:sha1:0c05269e0232d5eebfd835aa1401913b181031a3 (cherry picked from commit f44a508df629ecc97e0b1345726b12f25927409e) Fix compiler extension in standalone mode 2020-06-17T23:57:30+00:00 serge-sans-paille sguelton@redhat.com 2020-02-16T08:31:16+00:00 urn:sha1:4b932da77db7405f075fa2519edef6efd41b047c Use a dedicated cmake file to store the extension configured within LLVM. That way, a standalone build of clang can load this cmake file and get all the configured standalone extensions. This patch is related to https://reviews.llvm.org/D74602 Differential Revision: https://reviews.llvm.org/D74757 (cherry picked from commit 3a0f6e699bb6d96dc62dce6faef20ac26cf103fd) Fix standalone build interaction with compiler extension 2020-06-17T23:57:30+00:00 serge-sans-paille sguelton@redhat.com 2020-02-14T11:11:20+00:00 urn:sha1:7831c48b06678c2921f725e5e779f8ab00efedf1 As suggested in https://github.com/llvm/llvm-project/issues/120, don't try to generate the extension file from clang, only do the linking step. Fixes the regression introduced in D74464 when running cmake inside the clang directory. Differential Revision: https://reviews.llvm.org/D74602 (cherry picked from commit 87dac7da68ea1e0adac78c59ef1891dcf9632b67) Revert abb00753 "build: reduce CMake handling for zlib" (PR44780) 2020-03-03T13:31:05+00:00 Hans Wennborg hans@chromium.org 2020-03-03T08:45:14+00:00 urn:sha1:5f9211bc46fa1a8d1db3a2bc27c2b115cd617795 and follow-ups: a2ca1c2d "build: disable zlib by default on Windows" 2181bf40 "[CMake] Link against ZLIB::ZLIB" 1079c68a "Attempt to fix ZLIB CMake logic on Windows" This changed the output of llvm-config --system-libs, and more importantly it broke stand-alone builds. Instead of piling on more fix attempts, let's revert this to reduce the risk of more breakages. (cherry picked from commit 916be8fd6a0a0feea4cefcbeb0c22c65848d7a2e) [CMake] Use PUBLIC link mode for static libraries 2020-03-02T09:59:49+00:00 Petr Hosek phosek@google.com 2020-02-06T03:07:43+00:00 urn:sha1:499b1699621eb0aed9bec7017c1db60ccad30ae4 Using INTERFACE prevents the use of imported libraries as we've done in 00b3d49 because these aren't linked against the target, they're only made part of the interface. This doesn't affect the output since static libraries aren't being linked into, but it enables the use of imported libraries. Differential Revision: https://reviews.llvm.org/D74106 (cherry picked from commit 50a6d3a6486d81d21a2c31ce8522321e19bed35e)