freebsd-src/lib/clang/Makefile


.include <src.opts.mk>

# These have to be built in order.
SUBDIR=		libllvm
.if ${MK_CLANG} != "no" || ${MK_LLDB} != "no"
SUBDIR+=	libclang
SUBDIR+=	headers
.endif
.if ${MK_LLDB} != "no"
SUBDIR+=	liblldb
.endif

.include <bsd.subdir.mk>
Import the build makefiles for clang/LLVM. Approved by: ed (mentor) 2010-06-09 19:32:20 +00:00
Use src.opts.mk in preference to bsd.own.mk except where we need stuff from the latter. 2014-05-06 04:22:01 +00:00			`.include <src.opts.mk>`
Add a WITH_CLANG_EXTRAS option for src.conf(5), disabled by default, that builds the following additional llvm/clang tools: - bugpoint - llc - lli - llvm-ar - llvm-as - llvm-bcanalyzer - llvm-diff - llvm-dis - llvm-extract - llvm-ld - llvm-link - llvm-mc - llvm-nm - llvm-objdump - llvm-prof - llvm-ranlib - llvm-rtdyld - llvm-stub - macho-dump - opt These tools are mainly useful for people that want to manipulate llvm bitcode (.bc) and llvm assembly language (.ll) files, or want to tinker with llvm and clang themselves. MFC after: 2 weeks 2012-02-05 23:56:22 +00:00
Completely revamp the way llvm, clang and lldb are built. * Bootstrap llvm-tblgen and clang-tblgen with a minimal llvm static library, that has no other dependencies. * Roll up all separate llvm libraries into one big static libllvm. * Similar for all separate clang and lldb static libraries. * For all these libraries, generate their .inc files only once. * Link all llvm tools (including extra) against the big libllvm. * Link clang and clang-format against the big libllvm and libclang. * Link lldb against the big libllvm, libclang and liblldb. N.B.: This is work in progress, some details may still be missing. It also heavily depends on bsd..mk's support for SRCS and DPSRCS with relative pathnames, which apparently does not always work as expected. For building llvm, clang and lldb though, it seems to work just fine. The main idea behind this restructuring is maintainability and build peformance. The previous large number of very small libraries, each with their own generated files and dependencies was slow to traverse and hard to understand. Possible future improvements: Only build certain targets, e.g. for most regular users having just one target will be fine. This will shave off some build time. * Building the big llvm, clang and lldb libraries as shared (private) libraries. * Adding other components from the LLVM project, such as lld. 2016-08-26 22:44:22 +00:00			`# These have to be built in order.`
			`SUBDIR= libllvm`
Build libclang also if LLDB is enabled LLDB depends on libclang as it uses Clang as the expression parser. Previously setting WITHOUT_CLANG but leaving LLDB enabled (as default) resulted in a build failure. Users who set WITHOUT_CLANG in order to reduce build time or size might want to set WITHOUT_LLDB in addition to WITHOUT_CLANG, or use WITHOUT_TOOLCHAIN instead. PR: 260993 Reported by: eugen Reviewed by: dim MFC after: 3 days Sponsored by: The FreeBSD Foundation 2022-01-07 15:34:08 +00:00			`.if ${MK_CLANG} != "no" \|\| ${MK_LLDB} != "no"`
Completely revamp the way llvm, clang and lldb are built. * Bootstrap llvm-tblgen and clang-tblgen with a minimal llvm static library, that has no other dependencies. * Roll up all separate llvm libraries into one big static libllvm. * Similar for all separate clang and lldb static libraries. * For all these libraries, generate their .inc files only once. * Link all llvm tools (including extra) against the big libllvm. * Link clang and clang-format against the big libllvm and libclang. * Link lldb against the big libllvm, libclang and liblldb. N.B.: This is work in progress, some details may still be missing. It also heavily depends on bsd..mk's support for SRCS and DPSRCS with relative pathnames, which apparently does not always work as expected. For building llvm, clang and lldb though, it seems to work just fine. The main idea behind this restructuring is maintainability and build peformance. The previous large number of very small libraries, each with their own generated files and dependencies was slow to traverse and hard to understand. Possible future improvements: Only build certain targets, e.g. for most regular users having just one target will be fine. This will shave off some build time. * Building the big llvm, clang and lldb libraries as shared (private) libraries. * Adding other components from the LLVM project, such as lld. 2016-08-26 22:44:22 +00:00			`SUBDIR+= libclang`
Add WITH_LLVM_BINUTILS to install LLVM binutils instead of Elftoolchain When WITH_LLVM_BINUTILS is set, we will install the LLVM binutils as ar/ranlib/nm/objcopy/etc. instead of the elftoolchain ones. Having the LLVM binutils instead of the elftoolchain ones allows us to use features such as LTO that depend on binutils that understand LLVM IR. Another benefit will be an improved user-experience when compiling with AddressSanitizer, since ASAN does not symbolize backtraces correctly if addr2line is elftoolchain addr2line instead of llvm-symbolizer. See https://lists.freebsd.org/archives/freebsd-toolchain/2021-July/000062.html for more details. This is currently off by default but will be turned on by default at some point in the near future. Reviewed By: emaste Differential Revision: https://reviews.freebsd.org/D31060 2021-09-06 08:49:49 +00:00			`SUBDIR+= headers`
			`.endif`
Eliminate EARLY_BUILD flag. It is redundant and means MK_CLANG_FULL=no and MK_LLDB=no, so set those explicitly (now that we can do that). Simplify tests for these variables as well, since we know they will always be defined regardless of the phase of the build. 2014-05-10 16:38:03 +00:00			`.if ${MK_LLDB} != "no"`
Completely revamp the way llvm, clang and lldb are built. * Bootstrap llvm-tblgen and clang-tblgen with a minimal llvm static library, that has no other dependencies. * Roll up all separate llvm libraries into one big static libllvm. * Similar for all separate clang and lldb static libraries. * For all these libraries, generate their .inc files only once. * Link all llvm tools (including extra) against the big libllvm. * Link clang and clang-format against the big libllvm and libclang. * Link lldb against the big libllvm, libclang and liblldb. N.B.: This is work in progress, some details may still be missing. It also heavily depends on bsd..mk's support for SRCS and DPSRCS with relative pathnames, which apparently does not always work as expected. For building llvm, clang and lldb though, it seems to work just fine. The main idea behind this restructuring is maintainability and build peformance. The previous large number of very small libraries, each with their own generated files and dependencies was slow to traverse and hard to understand. Possible future improvements: Only build certain targets, e.g. for most regular users having just one target will be fine. This will shave off some build time. * Building the big llvm, clang and lldb libraries as shared (private) libraries. * Adding other components from the LLVM project, such as lld. 2016-08-26 22:44:22 +00:00			`SUBDIR+= liblldb`
			`.endif`
Add a SUBDIR_PARALLEL option to bsd.subdir.mk, to allow make to process all the SUBDIR entries in parallel, instead of serially. Apply this option to a selected number of Makefiles, which can greatly speed up the build on multi-core machines, when using make -j. This can be extended to more Makefiles later on, whenever they are verified to work correctly with parallel building. I tested this on a 24-core machine, with make -j48 buildworld (N = 6): before stddev after stddev ======= ====== ======= ====== real time 1741.1 16.5 959.8 2.7 user time 12468.7 16.4 14393.0 16.8 sys time 1825.0 54.8 2110.6 22.8 (user+sys)/real 8.2 17.1 E.g. the build was approximately 45% faster in real time. On machines with less cores, or with lower -j settings, the speedup will not be as impressive. But at least you can now almost max out a machine with buildworld! Submitted by: jilles MFC after: 2 weeks 2014-03-26 22:30:38 +00:00
Import the build makefiles for clang/LLVM. Approved by: ed (mentor) 2010-06-09 19:32:20 +00:00			`.include <bsd.subdir.mk>`