summaryrefslogtreecommitdiffstats
path: root/llvm/utils/gn/build/toolchain
Commit message (Collapse)AuthorAgeFilesLines
* gn build: Bump Android API level to 29, and NDK to r21.Peter Collingbourne2019-12-051-1/+1
| | | | | | | These are both necessary in order to use ELF TLS, which is needed by the scudo unit tests. Differential Revision: https://reviews.llvm.org/D71079
* gn build: Add support for cross-compiling the builtins and profile runtimes ↵Peter Collingbourne2019-10-312-0/+12
| | | | | | for Android aarch64 and arm. Differential Revision: https://reviews.llvm.org/D69681
* gn build: make windows build less brokenNico Weber2019-10-061-0/+3
| | | | llvm-svn: 373858
* gn build: Make builtin library build on macOSNico Weber2019-07-311-0/+2
| | | | | | | | For now, it only builds the x86_64 slice. Differential Revision: https://reviews.llvm.org/D65513 llvm-svn: 367449
* gn build: Add check-clangd target after r3359424Nico Weber2019-04-301-3/+3
| | | | | | | | | | | | | 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] 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] Use "$link /lib" for archives instead of lib.exeReid Kleckner2019-04-041-1/+1
| | | | | | | | | | | | | | | | Summary: This avoids the need to talk about lib.exe or llvm-lib.exe and it does the right thing with LLD. Reviewers: thakis Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60155 llvm-svn: 357660
* gn build: Add build files for clangd xpc framework codeNico Weber2019-04-031-1/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a bit of a larger change since this is the first (and as far as I can tell only) place where the LLVM build produces macOS framework bundles. GN has some built-in support for this, so use that. `gn help create_bundle` has a terse description (but it's a bit outdated: `deps` must be `public_deps` and the conditionals in the example in the help aren't quite right on non-iOS). We need a new 'copy_bundle_data' tool, and since we copy the clangd.xpc bundle as bundle_data into ClangdXPC.framework it needs to be able to handle directories in addition to files. GN also insists we have a compile_xcassets tool even though it's not used. I just made that run `false`. Despite GN's support for bundles, we still need to manually create the expected symlink structure in the .framework bundle. Since this code never runs on Windows, it's safe to create the symlinks before the symlink targets exist, so we can just make the bundle depend on the steps that create the symlinks. For this to work, change the symlink script to create the symlink's containing directory if it doesn't yet exist. I locally verified that CMake and GN build create the same bundle structure. (I noticed that both builds set LC_ID_DYLIB to the pre-copy libClangdXPCLib.dylib name, but that seems to not cause any issues and it happens in the CMake build too.) (Also add an error message to clangd-xpc-test-client for when loading the dylib fails – this was useful while locally debugging this.) Differential Revision: https://reviews.llvm.org/D60130 llvm-svn: 357574
* gn build: Add 32-bit Linux support.Peter Collingbourne2019-03-061-0/+4
| | | | | | Differential Revision: https://reviews.llvm.org/D58839 llvm-svn: 355467
* gn build: Upgrade to NDK r19.Peter Collingbourne2019-02-052-24/+4
| | | | | | | | | | NDK r19 includes a sysroot that can be used directly by the compiler without creating a standalone toolchain, so we just need a handful of flags to point Clang there. Differential Revision: https://reviews.llvm.org/D57733 llvm-svn: 353139
* gn build: Windows: use a more standard format for PDB filenamesDavid Major2019-02-041-7/+13
| | | | | | | | The current build was producing names like llvm-undname.exe.pdb, which looks unusual to me at least. This switches them to the more common llvm-undname.pdb style. Differential Revision: https://reviews.llvm.org/D57613 llvm-svn: 353099
* gn build: Revert r353094 (bad merge)David Major2019-02-041-14/+8
| | | | llvm-svn: 353098
* gn build: Windows: use a more standard format for PDB filenamesDavid Major2019-02-041-8/+14
| | | | | | | | The current build was producing names like llvm-undname.exe.pdb, which looks unusual to me at least. This switches them to the more common llvm-undname.pdb style. Differential Revision: https://reviews.llvm.org/D57613 llvm-svn: 353094
* gn build: Create regular archives for the sanitizer runtimes.Peter Collingbourne2019-02-011-1/+1
| | | | | | | | | | We'll need to do this eventually if we create an installable package. For now, this lets me use the archives to build Android, whose build system wants to copy the archives to another location. Differential Revision: https://reviews.llvm.org/D57607 llvm-svn: 352907
* gn build: Fix `lld-link: unknown flag: -fuse-ld=lld` warnings on WindowsNico Weber2019-01-281-1/+3
| | | | | | | | | | Fixes a minor regression from r351248. While here, also make it possible to opt out of lld by saying use_lld=false when clang_base_path is set. (use_lld still defaults to true if clang_base_path is set.) llvm-svn: 352415
* gn build: Set is_clang to true in stage2 toolchains.Peter Collingbourne2019-01-251-0/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D57202 llvm-svn: 352146
* gn build: unbreak mac (and maybe win) after r351258, r351277Nico Weber2019-01-181-2/+6
| | | | | | | | | | | | | The check-hwasan build files assert that current_os == "linux" || current_os == "android", so pull it in only there. ar is unused on mac, so don't set it in the stage2 toolchain. (It'd be nicer to use llvm-libtool on mac instead of host libtool, but llvm-libtool doesn't seem to understand the -no_warning_for_no_symbols flag.) Differential Revision: https://reviews.llvm.org/D56898 llvm-svn: 351519
* gn build: Add a stage2 host toolchain and make the hwasan runtime buildable ↵Peter Collingbourne2019-01-151-2/+16
| | | | | | | | on x86_64 Linux. Differential Revision: https://reviews.llvm.org/D56711 llvm-svn: 351258
* gn build: Move target flags from toolchain to a .gni file.Peter Collingbourne2019-01-153-28/+47
| | | | | | | | | While here, add a use_lld flag and default it to true when using clang on non-mac. Differential Revision: https://reviews.llvm.org/D56710 llvm-svn: 351248
* gn build: Rename llvm_host_triple to llvm_current_triple and have it use ↵Peter Collingbourne2019-01-151-0/+3
| | | | | | | | | | | | | | | | | | current_{cpu,os}. This makes e.g. ToolChain::isCrossCompiling() in clang/lib/Driver/ToolChain.cpp return the correct result if the compiler was cross-compiled. This change also affects llvm_default_target_triple, so cross-compiled compilers default to targeting the cross-compilation target, which makes more sense than the host that the compiler was compiled on. This change will also be necessary in order for the correct triples to appear in generated lit files for non-native targets. Differential Revision: https://reviews.llvm.org/D56696 llvm-svn: 351168
* gn build: Make a couple of improvements to the unix toolchain.Peter Collingbourne2019-01-151-2/+12
| | | | | | | | | | Add an asm tool (will be required for building sanitizer_common on x64) and set a soname for DSOs so that anything that links against them gets the correct DT_NEEDED. Differential Revision: https://reviews.llvm.org/D56705 llvm-svn: 351167
* gn build: Unbreak mac build after r350977Nico Weber2019-01-141-1/+3
| | | | llvm-svn: 351090
* gn build: Add a stage2 toolchain for Android.Peter Collingbourne2019-01-112-10/+52
| | | | | | | | | This makes it possible to build llvm-symbolizer for Android, which is one of the prerequisites for running the sanitizer tests on Android. Differential Revision: https://reviews.llvm.org/D56577 llvm-svn: 350979
* gn build: Create a template for unix toolchains.Peter Collingbourne2019-01-111-96/+112
| | | | | | | | | | Also change the toolchain description to use current_os instead of host_os so that the template can be used for cross builds, and add a current_os to the win toolchain to match the unix toolchain. Differential Revision: https://reviews.llvm.org/D56576 llvm-svn: 350977
* [gn build] Run `git ls-files '*.gn' '*.gni' | xargs -n 1 gn format`Nico Weber2019-01-091-2/+1
| | | | | | Looks like I forgot to do that for the PowerPC target. llvm-svn: 350711
* gn build: Stop passing -o to ar.Peter Collingbourne2019-01-081-1/+1
| | | | | | | | | The -o flag means something different to ar than what appears to be intended here. Also, llvm-ar doesn't accept the flag in this position. Differential Revision: https://reviews.llvm.org/D56426 llvm-svn: 350604
* [gn build] Create abi-breaking.h, config.h, llvm-config.h, and add a build ↵Nico Weber2018-11-271-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | file for llvm/lib/Support. The comments at the top of llvm/utils/gn/secondary/llvm/include/llvm/Config/BUILD.gn and llvm/utils/gn/build/write_cmake_config.py should explain the main bits happening in this patch. The main parts here are that these headers are generated at build time, not gn time, and that currently they don't do any actual feature checks but just hardcode most things based on the current OS, which seems to work well enough. If this stops being enough, the feature checks should each be their own action writing the result to somewhere, and the config write step should depend on those checks (so that they can run in parallel and as part of the build) -- utils/llvm/gn/README.rst already has some more words on that in "Philosophy". (write_cmake_config.py is also going to be used to write clang's clang/include/clang/Config/config.h) This also adds a few files for linking to system libraries in a consistent way if needed in llvm/utils/gn/build/libs (and moves pthread to that model).0 I'm also adding llvm/utils/gn/secondary/llvm/lib/Target/targets.gni in this patch because $native_arch is needed for writing llvm-config.h -- the rest of it will be used later, when the build files for llvm/lib/Target get added. That file describes how to select which archs to build. As a demo, also add a build file for llvm-undname and make it the default build target (it depends on everything that can currently be built). Differential Revision: https://reviews.llvm.org/D54678 llvm-svn: 347636
* Add initial scaffolding for the GN build.Nico Weber2018-11-172-0/+249
See "GN build roundtable summary; adding GN build files to the repo" on llvm-dev and cfe-dev for discussion. In particular, this build is completely unsupported. People adding new files to LLVM are not expected to update the GN build files, and reviewers are not supposed to request the gn build files to be updated. This adds just enough to be able to build llvm/lib/Demangle. It requires using a monorepo. This adds a few build config options you can set in args.gn (`gn args out/foo --list` for all): - is_debug = true to enable debug builds (defaults to release) - llvm_enable_assertions to toggle assertions (defaults to true) - clang_base_path, if set an absolute path to a locally-built clang to be used as host compiler Differential Revision: https://reviews.llvm.org/D54345 llvm-svn: 347128
OpenPOWER on IntegriCloud