summaryrefslogtreecommitdiffstats
path: root/llvm/utils/gn
Commit message (Collapse)AuthorAgeFilesLines
...
* gn build: Merge r360018Nico Weber2019-05-061-0/+2
| | | | llvm-svn: 360049
* [libcxxabi] Don't use -fvisibility-global-new-delete-hidden when not ↵Petr Hosek2019-05-061-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | defining them When builing the hermetic static library, the compiler switch -fvisibility-global-new-delete-hidden is necessary to get the new and delete operator definitions made correctly. However, when those definitions are not included in the library, then this switch does harm. With lld (though not all linkers) setting STV_HIDDEN on SHN_UNDEF symbols makes it an error to leave them undefined or defined via dynamic linking that should generate PLTs for -shared linking (lld makes this a hard error even without -z defs). Though leaving the symbols undefined would usually work in practice if the linker were to allow it (and the user didn't pass -z defs), this actually indicates a real problem that could bite some target configurations more subtly at runtime. For example, x86-32 ELF -fpic code generation uses hidden visibility on declarations in the caller's scope as a signal that the call will never be resolved to a PLT entry and so doesn't have to meet the special ABI requirements for PLT calls (setting %ebx). Since these functions might actually be resolved to PLT entries at link time (we don't know what the user is linking in when the hermetic library doesn't provide all the symbols itself), it's not safe for the compiler to treat their declarations at call sites as having hidden visibility. Differential Revision: https://reviews.llvm.org/D61572 llvm-svn: 360004
* [libcxx] Don't use -fvisibility-global-new-delete-hidden when not defining themPetr Hosek2019-05-061-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | When builing the hermetic static library, the compiler switch -fvisibility-global-new-delete-hidden is necessary to get the new and delete operator definitions made correctly. However, when those definitions are not included in the library, then this switch does harm. With lld (though not all linkers) setting STV_HIDDEN on SHN_UNDEF symbols makes it an error to leave them undefined or defined via dynamic linking that should generate PLTs for -shared linking (lld makes this a hard error even without -z defs). Though leaving the symbols undefined would usually work in practice if the linker were to allow it (and the user didn't pass -z defs), this actually indicates a real problem that could bite some target configurations more subtly at runtime. For example, x86-32 ELF -fpic code generation uses hidden visibility on declarations in the caller's scope as a signal that the call will never be resolved to a PLT entry and so doesn't have to meet the special ABI requirements for PLT calls (setting %ebx). Since these functions might actually be resolved to PLT entries at link time (we don't know what the user is linking in when the hermetic library doesn't provide all the symbols itself), it's not safe for the compiler to treat their declarations at call sites as having hidden visibility. Differential Revision: https://reviews.llvm.org/D61571 llvm-svn: 360003
* gn build: Merge r359878Nico Weber2019-05-031-0/+1
| | | | llvm-svn: 359888
* [gn] Include the missing BUILD.gn file for libcxxabi includesPetr Hosek2019-05-022-10/+11
| | | | | | | | This was omitted in r359805. Differential Revision: https://reviews.llvm.org/D61462 llvm-svn: 359828
* [gn] Update the clangd test lit site configurationPetr Hosek2019-05-023-7/+17
| | | | | | This reflects changes made in r359763. llvm-svn: 359825
* [gn] Include libcxx configuration filePetr Hosek2019-05-021-0/+10
| | | | | | This was omitted in r359806 but is already referenced in the GN build. llvm-svn: 359815
* [gn] Support for building libc++Petr Hosek2019-05-024-0/+584
| | | | | | | | | | | | This change introduces support for building libc++. The library build should be complete, but not all CMake options have been replicated in GN. We also don't support tests yet. We only support two stage build at the moment. Differential Revision: https://reviews.llvm.org/D61143 llvm-svn: 359806
* [gn] Support for building libcxxabiPetr Hosek2019-05-023-0/+151
| | | | | | | | | | | | This change introduces support for building libcxxabi. The library build should be complete, but not all CMake options have been replicated in GN. We also don't support tests yet. We only support two stage build at the moment. Differential Revision: https://reviews.llvm.org/D60372 llvm-svn: 359805
* [gn] Support for building libunwindPetr Hosek2019-05-023-1/+133
| | | | | | | | | | | | This change introduces support for building libuwind. The library build should be complete, but not all CMake options have been replicated in GN. We also don't support tests yet. We only support two stage build at the moment. Differential Revision: https://reviews.llvm.org/D60370 llvm-svn: 359804
* Revert r359717, "Make check-clang depend on the clang-check binary always"Nico Weber2019-05-011-1/+1
| | | | | | | | | | | | The Tooling tests do have a lit.local.cfg with if not config.root.clang_staticanalyzer: config.unsupported = True so what's wrong isn't the missing dep, but that lit prints a warning for the binary missing. This will need a different kind of fix. llvm-svn: 359739
* Make check-clang depend on the clang-check binary alwaysNico Weber2019-05-011-1/+1
| | | | | | | | | | | | | | | | | check-clang (the target that runs all clang tests) used to only depend on clang-check (a binary like clang-tidy, clang-refactor, etc) if the static analyzer is enabled. However, several lit tests call clang-check unconditionally, so always depend on it. Fixes a "could not find clang-check" lit warning in clean builds with the static analyzer disabled. Also sort the deps in the CMake file and put just one dep on each line. Differential Revision: https://reviews.llvm.org/D61324 llvm-svn: 359717
* gn build: Fix build on macOS after r359570 / r359527Nico Weber2019-04-301-1/+1
| | | | llvm-svn: 359637
* gn build: Merge r359626Nico Weber2019-04-301-0/+1
| | | | llvm-svn: 359635
* gn build: Add check-clangd target after r3359424Nico Weber2019-04-307-18/+119
| | | | | | | | | | | | | r359527 already merged some of that to the GN build, but it was missing some bits as well. The check-clangd target works (at least for now) differently than all the other check-foo targets, see https://reviews.llvm.org/D61187 For that reason, there's no gni file and the generated lit configs are not (yet?) added to llvm-lit/BUILD.gn. llvm-svn: 359570
* gn build: Merge r359455Nico Weber2019-04-301-0/+1
| | | | llvm-svn: 359562
* [clangd] Fix GN buildVitaly Buka2019-04-304-7/+1
| | | | llvm-svn: 359527
* gn build: Merge r359252Nico Weber2019-04-291-0/+1
| | | | llvm-svn: 359514
* [gn] Use label_name rather than target_output_name for objectsPetr Hosek2019-04-291-5/+5
| | | | | | | | | | | | | | Multiple targets in the same output directory can use the same target_output_name. The typical example of that is having a shared and a static library of the same, e.g. libc++.so and libc++.a. When that's the case, the object files produced for each target are going to conflict. Using the label_name avoids this conflict since labels are guaranteed to be unique within a single BUILD.gn file which corresponds to a single output directory. Differential Revision: https://reviews.llvm.org/D60329 llvm-svn: 359494
* gn: Fix check-clang build after r359179Hans Wennborg2019-04-291-0/+1
| | | | llvm-svn: 359429
* gn build: Document llvm_enable_dia_sdk variable betterNico Weber2019-04-251-0/+2
| | | | llvm-svn: 359196
* gn build: Make setting llvm_enable_dia_sdk=true workNico Weber2019-04-252-2/+8
| | | | | | | | If this is set, %INCLUDE% must contain ".../DIA SDK/include" and %LIB% must contain ".../DIA SKD/lib/amd64" (assuming you're doing a 64-bit build). llvm-svn: 359195
* gn build: Merge r359179Nico Weber2019-04-252-0/+2
| | | | llvm-svn: 359189
* gn build: Merge r359174Nico Weber2019-04-251-0/+1
| | | | llvm-svn: 359188
* gn build: Merge r359142Nico Weber2019-04-251-0/+1
| | | | llvm-svn: 359187
* gn build: Merge r359050 moreNico Weber2019-04-242-0/+2
| | | | llvm-svn: 359058
* gn build: Merge r359050Nico Weber2019-04-242-0/+2
| | | | llvm-svn: 359056
* gn build: Merge r358944Nico Weber2019-04-231-0/+1
| | | | llvm-svn: 358993
* gn build: Merge r358949Nico Weber2019-04-232-0/+2
| | | | llvm-svn: 358991
* gn build: Merge r358869Nico Weber2019-04-222-4/+4
| | | | llvm-svn: 358912
* gn build: Re-run `git ls-files '*.gn' '*.gni' | xargs llvm/utils/gn/gn.py ↵Nico Weber2019-04-212-2/+1
| | | | | | format` llvm-svn: 358862
* gn build: Merge r358749Nico Weber2019-04-213-9/+11
| | | | | | | | | | | | Since the symlinks list for llvm-symbolizer is now never empty, the :symlinks target no longer needs an explicit dep on :llvm-symbolizer -- there will be at least one dep on a symlink, and each symlink depends on :llvm-symbolizer already. Since llvm-symbolizer:symlinks now produces symlinks that check-llvm uses, make llvm/test depend on the symlink target. llvm-svn: 358861
* gn build: Merge r358818 (JITLink)Nico Weber2019-04-216-0/+56
| | | | llvm-svn: 358860
* gn build: Fix build after r358837Nico Weber2019-04-211-1/+0
| | | | llvm-svn: 358851
* [gn] Move Features.inc to clangd, create a config for itPetr Hosek2019-04-213-20/+25
| | | | | | | | | | | ClangdLSPServer and clangd unittests now include Features.inc so we need to append the target_gen_dir that contains it to their include_dirs. To do so, we use a public config that's applied to any target that depends on the features one. Differential Revision: https://reviews.llvm.org/D60919 llvm-svn: 358837
* Update GN files to build with r358103Vitaly Buka2019-04-193-2/+14
| | | | llvm-svn: 358790
* [gn] Support dots in CMake paths in the sync scriptPetr Hosek2019-04-192-1/+2
| | | | | | | | Some file paths use dots to pick up sources from parent directories. Differential Revision: https://reviews.llvm.org/D60734 llvm-svn: 358774
* gn build: Merge r358722Nico Weber2019-04-191-0/+1
| | | | llvm-svn: 358755
* gn build: Merge r358691Nico Weber2019-04-192-0/+2
| | | | llvm-svn: 358754
* gn build: Merge r358607Nico Weber2019-04-181-0/+1
| | | | llvm-svn: 358670
* gn build: Merge r358633Nico Weber2019-04-181-0/+1
| | | | llvm-svn: 358669
* gn build: Merge r358620Nico Weber2019-04-181-0/+1
| | | | llvm-svn: 358668
* gn build: Merge r358554Nico Weber2019-04-171-0/+1
| | | | llvm-svn: 358578
* Fixed error message printing in write_cmake_config.pyDmitri Gribenko2019-04-171-1/+4
| | | | | | | | | | | | | | Summary: Previously, write_cmake_config.py would raise an error while printing the error, because `leftovers` in "'\n'.join(leftovers)" is a tuple. Subscribers: mgorny, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60766 llvm-svn: 358557
* gn build: Merge r358422Nico Weber2019-04-161-0/+1
| | | | llvm-svn: 358486
* gn build: Merge r358390Nico Weber2019-04-151-0/+1
| | | | llvm-svn: 358397
* gn build: Merge r358297Nico Weber2019-04-141-0/+1
| | | | llvm-svn: 358366
* gn build: Merge r358243Nico Weber2019-04-141-0/+1
| | | | llvm-svn: 358365
* gn build: Merge r358272Nico Weber2019-04-141-0/+1
| | | | llvm-svn: 358364
* gn build: Fix Windows builds after r357797Nico Weber2019-04-091-1/+3
| | | | llvm-svn: 358004
OpenPOWER on IntegriCloud