xref: /openbsd/gnu/llvm/llvm/utils/gn/secondary/BUILD.gn (revision 73471bf0) 
1import("//clang/lib/ARCMigrate/enable.gni")
2import("//clang/lib/StaticAnalyzer/Frontend/enable.gni")
3import("//llvm/utils/gn/build/toolchain/compiler.gni")
4
5group("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  }
29
30  testonly = true
31}
32
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.
55group("clang") {
56  deps = [ "//clang/tools/driver:symlinks" ]
57}
58group("lld") {
59  deps = [ "//lld/tools/lld:symlinks" ]
60}
61group("llvm-ar") {
62  deps = [ "//llvm/tools/llvm-ar:symlinks" ]
63}
64group("llvm-dwp") {
65  deps = [ "//llvm/tools/llvm-dwp:symlinks" ]
66}
67group("llvm-nm") {
68  deps = [ "//llvm/tools/llvm-nm:symlinks" ]
69}
70group("llvm-cxxfilt") {
71  deps = [ "//llvm/tools/llvm-cxxfilt:symlinks" ]
72}
73group("llvm-objcopy") {
74  deps = [ "//llvm/tools/llvm-objcopy:symlinks" ]
75}
76group("llvm-objdump") {
77  deps = [ "//llvm/tools/llvm-objdump:symlinks" ]
78}
79group("llvm-rc") {
80  deps = [ "//llvm/tools/llvm-rc:symlinks" ]
81}
82group("llvm-readobj") {
83  deps = [ "//llvm/tools/llvm-readobj:symlinks" ]
84}
85group("llvm-size") {
86  deps = [ "//llvm/tools/llvm-size:symlinks" ]
87}
88group("llvm-strings") {
89  deps = [ "//llvm/tools/llvm-strings:symlinks" ]
90}
91group("llvm-symbolizer") {
92  deps = [ "//llvm/tools/llvm-symbolizer:symlinks" ]
93}
94
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.)
97pool("console") {
98  depth = 1
99}
100