[PATCH] D75425: [docs] Added solutions to slow build under common problems

[Michael Kruse via Phabricator via llvm-commits]

Meinersbur added inline comments.


================
Comment at: llvm/docs/GettingStarted.rst:1108-1112
+ * -DLLVM_ENABLE_LLD
+   Set this to ON to use the LLD linker. This significantly improves build time.
+ 
+ * -DLLVM_USE_LINKER
+   Set this to gold to use the gold linker to improve performance during build.
----------------
`LLVM_ENABLE_LLD` and `LLVM_USE_LINKER` are mutually exclusive. In particular, `LLVM_ENABLE_LLD=ON` is equivalent to `LLVM_USE_LINKER=lld`. I think "choice of linker" should be just one item.

Could you document what `LLVM_USE_LINKER` would be for using the gold linker?


================
Comment at: llvm/docs/GettingStarted.rst:1114-1119
+ * -DCMAKE_BUILD_TYPE  
+   Set this equal to the build you wish to use, either Debug or Release. The 
+   Debug build may consume more memory during the linking phase. Another build 
+   type you may wish to consider is release-with-asserts which compiles at 
+   nearly the same rate as the Release build; however, it may not be as easy
+   to debug.
----------------
Actually, LLVM defaults to `CMAKE_BUILD_TYPE=Debug` in its CMakeLists.txt:
```
if (NOT CMAKE_BUILD_TYPE AND NOT CMAKE_CONFIGURATION_TYPES)
  message(STATUS "No build type selected, default to Debug")
  set(CMAKE_BUILD_TYPE "Debug" CACHE STRING "Build type (default Debug)" FORCE)
endif()
```
This is is not generally true for CMake projects, so as a rule of thumb, I personally always define CMAKE_BUILD_TYPE.

For the documentation, we should make aware of `CMAKE_BUILD_TYPE=Release` (or maybe even MinSizeRel) in contrast to the default `Debug`. Consider switching `LLVM_ENABLE_ASSERTIONS=ON` for release builds. It is off by default for non-debug builds.


================
Comment at: llvm/docs/GettingStarted.rst:1122-1124
+   Set this equal to number of jobs you wish to run simultaneously. This is 
+   similar to the -j option used with make, but only for link jobs. This option 
+   is of course only meaningful if you plan to build with ninja.
----------------
Could you also mention that link jobs may require much more memory that compile jobs, so limiting the number of parallel link jobs may reduce the peak memory usage?

If memory is limited, I'd also recommend starting with `LLVM_PARALLEL_LINK_JOBS=1` and optionally increase it afterwards. Limiting the link jobs does not increase the total build time that much.


================
Comment at: llvm/docs/GettingStarted.rst:1135-1138
+ * -DLLVM_ENABLE_PROJECTS  
+   Set this equal to the projects you wish to compile. If compiling more than one
+   project, deliniate the list with a semicolon. Should you run into issues with 
+   the semicolon, surround it with single quotes.  
----------------
A recommendation would be useful for beginners. For instance, `LLVM_ENABLE_PROJECTS=clang` (instead of `LLVM_ENABLE_PROJECT=all`) may suffice for many users.


================
Comment at: llvm/docs/GettingStarted.rst:1141
+ * -DCLANG_ENABLE_STATIC_ANALYZER  
+   Set this option to OFF if you do not require the STATIC_ANALYZER. This should 
+   improve your build time significantly.
----------------
Just "clang static analyzer", no need to captialize.


================
Comment at: llvm/docs/GettingStarted.rst:1144-1146
+ * -DLLVM_USE_SPLIT_DWARF
+   Consider setting this to ON if you require a debug build, as this will ease 
+   memory pressure on the linker.
----------------
I have never used this option myself. It would be nice to mention what it does.

See also https://www.productive-cpp.com/improving-cpp-builds-with-split-dwarf/


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D75425/new/

https://reviews.llvm.org/D75425