Lines Matching +full:llvm +full:- +full:build
2 Building LLVM with GN
13 *Warning* The GN build is experimental and best-effort. It might not work,
15 necessary. LLVM's official build system is CMake, if in doubt use that.
16 If you add files, you're expected to update the CMake build but you don't need
17 to update GN build files. Reviewers should not ask authors to update GN build
18 files. Keeping the GN build files up-to-date is on the people who use the GN
19 build.
23 which then shell out to ninja for the actual build.
25 The main motivation behind the GN build is that some people find it more
26 convenient for day-to-day hacking on LLVM than CMake. Distribution, building
27 just parts of LLVM, and embedding the LLVM GN build from other builds are
28 non-goals for the GN build.
37 #. ``git clone https://github.com/llvm/llvm-project.git; cd llvm-project`` if
40 #. ``llvm/utils/gn/get.py`` to download a prebuilt gn binary if you're on a
41 64-bit X86 system running Linux, macOS, or Windows. `Build gn yourself
42 <https://gn.googlesource.com/gn/#getting-started>`_ if you're on a different
45 #. ``llvm/utils/gn/gn.py gen out/gn`` to run GN and create build files.
46 ``out/gn`` is the build directory, it can have any name, and you can have as
47 many as you want, each with different build settings. (The ``gn.py`` script
48 adds ``--dotfile=llvm/utils/gn/.gn --root=.`` and just runs regular ``gn``;
54 #. ``ninja -C out/gn check-lld`` to build all prerequisites for and run the LLD
57 By default, you get a release build with assertions enabled that targets
58 the host arch. You can set build options by editing ``out/gn/args.gn``, for
59 example putting ``is_debug = true`` in there gives you a debug build. Run
60 ``llvm/utils/gn/gn.py args --list out/gn`` to see a list of all possible
61 options. After touching ``out/gn/args.gn`` just run ninja: it will re-invoke gn
62 before starting the build.
64 GN has extensive built-in help; try e.g. ``llvm/utils/gn/gn.py help gen`` to see
69 ``git ls-files '*.gn' '*.gni' | xargs llvm/utils/gn/gn.py format``
70 after making GN build changes is your friend.
72 To not put ``BUILD.gn`` files into the main tree, they are all below
73 ``utils/gn/secondary``. For example, the build file for ``llvm/lib/Support``
74 is in ``utils/gn/secondary/llvm/lib/Support``.
81 Sometimes after pulling in the latest changes, the GN build doesn't work.
83 Run ``llvm/utils/gn/build/sync_source_lists_from_cmake.py`` to print a report
84 of which files need to be added to or removed from ``BUILD.gn`` files to
89 a new corresponding ``BUILD.gn`` file below ``llvm/utils/gn/secondary/``.
99 GN believes in using GN arguments to configure the build explicitly, instead
105 - compiler checks. In GN, these could use exec_script to identify the host
106 compiler at GN time. For now the build has explicit toggles for compiler
117 - library checks. For e.g. like zlib, GN thinks it's better to say "we require
118 zlib, else we error at build time" than silently omitting features. People
122 - header checks (does system header X exist). These are generally not needed
124 necessary in the future, they should be done at build time and the few
125 targets that need to know if header X exists then depend on that build-time
126 check while everything else can build parallel with it.
128 - LLVM-specific build toggles (assertions on/off, debug on/off, targets to
129 build, ...). These map cleanly to GN args (which then get copied into
130 config.h in a build step).
132 For the last two points, it would be nice if LLVM didn't have a single
138 variable, it wants the build to be controlled by .gn files.