freebsd-src/lib/clang/clang.build.mk


.include <src.opts.mk>

.ifndef CLANG_SRCS
.error Please define CLANG_SRCS before including this file
.endif

CFLAGS+=	-I${CLANG_SRCS}/include

.if ${MK_CLANG_FULL} != "no"
CFLAGS+=	-DCLANG_ENABLE_ARCMT
CFLAGS+=	-DCLANG_ENABLE_STATIC_ANALYZER
.endif

CFLAGS.gcc+=	-fno-strict-aliasing

.include "llvm.build.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>`

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			`.ifndef CLANG_SRCS`
			`.error Please define CLANG_SRCS before including this file`
			`.endif`
Upgrade our copy of llvm/clang to r130700, from upstream's trunk. 2011-05-02 21:04:37 +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			`CFLAGS+= -I${CLANG_SRCS}/include`
Import the build makefiles for clang/LLVM. Approved by: ed (mentor) 2010-06-09 19:32:20 +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			`.if ${MK_CLANG_FULL} != "no"`
			`CFLAGS+= -DCLANG_ENABLE_ARCMT`
			`CFLAGS+= -DCLANG_ENABLE_STATIC_ANALYZER`
			`.endif`
Use the new -d option that was added to tblgen between llvm/clang 3.3 and 3.4 to generate dependency files for the '.inc.h' files generated from .td files, and .sinclude those dependency files in clang.build.mk. This will make future incremental builds of lib/clang and usr.bin/clang work correctly, whenever any of the .td files get modified. Note that this will not fix any problems with incremental builds from before this revision, since there will not yet be any generated dependency files. A quick workaround is to run the following: find /usr/obj -type f -name '*.inc.h' \| xargs rm and then a regular incremental buildworld (e.g. with -DNO_CLEAN). MFC after: 3 days 2014-05-14 17:11:57 +00:00
clang: Build with -fno-strict-aliasing when using GCC Somewhat ironically, there are strict aliasing violations in Clang, which can result in the following assertion failure: Assertion `(NamedDecl *)&Data == ND && "PointerUnion mangles the NamedDecl pointer!"' failed. Upstream's clang/CMakeLists.txt specifically (not LLVM as a whole) passes -fno-strict-aliasing if the compiler is not Clang, and this fixes the above issue. This was seen when cross-building from Linux using a bootstrap compiler, but likely also affects worlds built with a new enough external GCC toolchain. MFC after: 1 week Reviewed by: dim Differential Revision: https://reviews.freebsd.org/D31533 2021-08-24 13:59:36 +00:00			`CFLAGS.gcc+= -fno-strict-aliasing`

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			`.include "llvm.build.mk"`