[ORC] Add std::tuple support to SimplePackedSerialization.
[llvm-project.git] / llvm / utils / gn / secondary / BUILD.gn
blob16b4c986d74757fd61f2f88e885a31b33d0cca82
1 import("//clang/lib/ARCMigrate/enable.gni")
2 import("//clang/lib/StaticAnalyzer/Frontend/enable.gni")
3 import("//llvm/utils/gn/build/toolchain/compiler.gni")
5 group("default") {
6   deps = [
7     "//clang-tools-extra/clangd/test",
8     "//clang-tools-extra/test",
9     "//clang/test",
10     "//clang/tools/scan-build",
11     "//compiler-rt",
12     "//compiler-rt/include",
13     "//compiler-rt/lib/scudo",
14     "//lld/test",
15     "//llvm/test",
16   ]
17   if (current_os == "linux") {
18     deps += [
19       "//libcxx",
20       "//libcxxabi",
21     ]
22   }
23   if (current_os == "linux" || current_os == "android") {
24     deps += [ "//compiler-rt/test/hwasan" ]
25   }
26   if (current_os == "linux" || current_os == "mac") {
27     deps += [ "//libunwind" ]
28   }
30   testonly = true
33 # Symlink handling.
34 # On POSIX, symlinks to the target can be created before the target exist,
35 # and the target can depend on the symlink targets, so that building the
36 # target ensures the symlinks exist.
37 # However, symlinks didn't exist on Windows until recently, so there the
38 # binary needs to be copied -- which requires it to exist. So the symlink step
39 # needs to run after the target that creates the binary.
40 # In the cmake build, this is done via a "postbuild" on the target, which just
41 # tacks on "&& copy out.exe out2.exe" to the link command.
42 # GN doesn't have a way to express postbuild commands.  It could probably be
43 # emulated by having the link command in the toolchain be a wrapper script that
44 # reads a ".symlinks" file next to the target, and have an action write that
45 # and make the target depend on that, but then every single link has to use the
46 # wrapper (unless we do further acrobatics to use a different toolchain for
47 # targets that need symlinks) even though most links don't need symlinks.
48 # Instead, have a top-level target for each target that needs symlinks, and
49 # make that depend on the symlinks. Then the symlinks can depend on the
50 # executable.  This has the effect that `ninja lld` builds lld and then creates
51 # symlinks (via this target), while `ninja bin/lld` only builds lld and doesn't
52 # update symlinks (in particular, on Windows it doesn't copy the new lld to its
53 # new locations).
54 # That seems simpler, more explicit, and good enough.
55 group("clang") {
56   deps = [ "//clang/tools/driver:symlinks" ]
58 group("lld") {
59   deps = [ "//lld/tools/lld:symlinks" ]
61 group("llvm-ar") {
62   deps = [ "//llvm/tools/llvm-ar:symlinks" ]
64 group("llvm-dwp") {
65   deps = [ "//llvm/tools/llvm-dwp:symlinks" ]
67 group("llvm-nm") {
68   deps = [ "//llvm/tools/llvm-nm:symlinks" ]
70 group("llvm-cxxfilt") {
71   deps = [ "//llvm/tools/llvm-cxxfilt:symlinks" ]
73 group("llvm-objcopy") {
74   deps = [ "//llvm/tools/llvm-objcopy:symlinks" ]
76 group("llvm-objdump") {
77   deps = [ "//llvm/tools/llvm-objdump:symlinks" ]
79 group("llvm-rc") {
80   deps = [ "//llvm/tools/llvm-rc:symlinks" ]
82 group("llvm-readobj") {
83   deps = [ "//llvm/tools/llvm-readobj:symlinks" ]
85 group("llvm-size") {
86   deps = [ "//llvm/tools/llvm-size:symlinks" ]
88 group("llvm-strings") {
89   deps = [ "//llvm/tools/llvm-strings:symlinks" ]
91 group("llvm-symbolizer") {
92   deps = [ "//llvm/tools/llvm-symbolizer:symlinks" ]
95 # A pool called "console" in the root BUILD.gn is magic and represents ninja's
96 # built-in console pool. (Requires a GN with `gn --version` >= 552353.)
97 pool("console") {
98   depth = 1