Lines Matching +full:ninja +full:- +full:build
26 - know how to use an editor,
28 - have basic C++ knowledge,
30 - know how to install software on your system,
32 - are comfortable with the command line,
34 - have basic knowledge of git.
38 -----------------------
45 $ clang -c -Wall ~/test.cc
46 test.cc:1:12: warning: all paths through this function will call itself [-Winfinite-recursion]
53 test.cc:1:12: warning: to understand recursion, you must first understand recursion [-Winfinite-recursion]
57 ------------
61 - git: to check out the LLVM source code,
63 - a C++ compiler: to compile LLVM source code. You'll want `a recent
66 - CMake: used to configure how LLVM should be built on your system,
68 - ninja: runs the C++ compiler to (re)build specific parts of LLVM,
70 - python: to run the LLVM tests.
76 $ sudo apt-get install git clang cmake ninja-build python
84 --------
87 Github <https://github.com/llvm/llvm-project>`__ in one large repository
94 $ git clone https://github.com/llvm/llvm-project.git
96 This will create a directory "llvm-project" with all of the source
97 code. (Checking out anonymously is OK - pushing commits uses a different
101 ------------------------
103 Before we can build the code, we must configure exactly how to build it
106 - explicit choices you make (is this a debug build?)
108 - settings detected from your system (where are libraries installed?)
110 - project structure (which files are part of 'clang'?)
112 First, create a directory to build in. Usually, this is ``llvm-project/build``.
116 $ mkdir llvm-project/build
117 $ cd llvm-project/build
123 $ cmake -G Ninja ../llvm -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_PROJECTS=clang
132 Build files have been written to: /path/llvm-project/build
134 And you should see a ``build.ninja`` file in the current directory.
138 - **-G Ninja**: Tells CMake that we're going to use ninja to build, and to create
139 the ``build.ninja`` file.
141 - **../llvm**: this is the path to the source of the "main" LLVM
144 - The two **-D** flags set CMake variables, which override
147 - **CMAKE_BUILD_TYPE=Release**: build in optimized mode, which is
157 - **LLVM_ENABLE_PROJECTS=clang**: this lists the LLVM subprojects
162 Finally, create a symlink (or copy) of ``llvm-project/build/compile-commands.json``
163 into ``llvm-project/``:
167 $ ln -s build/compile_commands.json ../
170 tools like clang-tidy, clang-query, and clangd to work in your source
174 Build and test
175 --------------
177 Finally, we can build the code! It's important to do this first, to
178 ensure we're in a good state before making changes. But what to build?
179 In ninja, you specify a **target**. If we just want to build the clang
184 $ ninja clang
186 The first time we build will be very slow - Clang + LLVM is a lot of
187 code. But incremental builds are fast: ninja will only rebuild the parts
193 $ bin/clang --version
199 $ ninja check-clang
201 This is a common pattern in LLVM: check-llvm is all the checks for the core of
202 LLVM, other projects have targets like ``check-lldb``, ``check-flang`` and so on.
210 ----------
220 printed by Clang. ``*.td`` files define tables - in this case it's a list
233 ----------
235 To verify our change, we can build clang and manually check that it
240 $ ninja clang
241 $ bin/clang -c -Wall ~/test.cc
242 test.cc:1:12: warning: in order to understand recursion, you must first understand recursion [-Winfinite-recursion]
248 $ ninja check-clang
250 Notice that it is much faster to build this time, but the tests take
251 just as long to run. Ninja doesn't know which tests might be affected,
258 Clang :: SemaCXX/warn-infinite-recursion.cpp
269 $ vi ../clang/test/SemaCXX/warn-infinite-recursion.cpp
271 Everywhere we see ``// expected-warning{{call itself}}`` (or something similar
273 ``// expected-warning{{to understand recursion}}``.
276 iterate on a change! Instead, let's find a way to re-run just the
279 - **lit tests** (e.g. ``SemaCXX/warn-infinite-recursion.cpp``).
281 These are fancy shell scripts that run command-line tools and verify the
283 ``clang/**test**/FixIt/dereference-addressof.c``. Re-run like this:
287 $ bin/llvm-lit -v ../clang/test/SemaCXX/warn-infinite-recursion.cpp
289 - **unit tests** (e.g. ``ToolingTests/ReplacementTest.CanDeleteAllText``)
292 They live in suites like ToolingTests. Re-run like this:
296 $ ninja ToolingTests && tools/clang/unittests/Tooling/ToolingTests --gtest_filter=ReplacementTest.CanDeleteAllText
300 --------------
311 $ git checkout -b myfirstpatch
312 $ git commit -am "[clang][Diagnostic] Clarify -Winfinite-recursion message"
323 $ git log --oneline ../clang/
325 Or using GitHub, for example https://github.com/llvm/llvm-project/commits/main/clang.
334 -----------------------------
336 LLVM code reviews happen through pull-request on GitHub, see the
337 :ref:`GitHub <github-reviews>` documentation for how to open
338 a pull-request on GitHub.
341 ------------------
354 --------------
356 When you open a pull-request, some automation will add a comment and
357 notify different members of the sub-projects depending on the parts you have
377 your branch with more commits and push to your GitHub fork of ``llvm-project``.
385 -------------------
387 In order to make LLVM a long-term sustainable effort, code needs to be
390 and push-back on design decisions that do not fit well within the
395 - be kind, and expect reviewers to be kind in return - LLVM has a
399 - be patient - understanding how a new feature fits into the
404 - if you can't agree, generally the best way is to do what the reviewer
412 ------------------------
424 ---------------
433 The pull-request will be closed and you will be notified by GitHub.
436 ---------------------
441 - you've landed 3-5 patches of larger scope than "fix a typo"
443 - you'd be willing to review changes that are closely related to yours
445 - you'd like to keep contributing to LLVM.
451 ----------------
462 Once your change is submitted it will be picked up by automated build
463 bots that will build and test your patch in a variety of configurations.
467 build bots, this should be the first place to look.
469 The columns are build configurations and the rows are individual commits. Along
470 the rows are colored bubbles. The color of the bubble represents the build's
471 status. Green is passing, red has failed and yellow is a build in progress.
473 A red build may have already been failing before your change was committed. This
474 means you didn't break the build but you should check that you did not make it
479 there, rely on PR comments and build bot emails to notify you of any problems.
481 If there is a problem in a build that includes your changes, you may receive
486 To see the details of a build, click the bubble in the console view, or the link
488 each stage of that build.
497 -------
507 the `GitHub interface <https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/reverting-a-pull-request>`__.
518 the expectations of different sub-projects may vary too.