utils/gn/secondary/BUILD.gn

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