d/freebsd-skq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
f139bcd72b
freebsd-skq/lib/clang/llvm.build.mk

56 lines
1.5 KiB
Makefile
Raw Normal View History

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
# $FreeBSD$
.ifndef LLVM_SRCS
.error Please define LLVM_SRCS before including this file
.endif
.ifndef SRCDIR
.error Please define SRCDIR before including this file
.endif
.PATH: ${LLVM_SRCS}/${SRCDIR}
Use SRCTOP and OBJTOP throughout the llvm/clang/lldb build.
2016-08-27 09:29:39 +00:00
CFLAGS+= -I${SRCTOP}/lib/clang/include
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${LLVM_SRCS}/include
Following upstream trunk, enable the new global instruction selection (GlobalISel), cleanup some defines, and adjust the libllvm Makefile for this.
2017-05-22 19:06:39 +00:00
CFLAGS+= -DLLVM_BUILD_GLOBAL_ISEL
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+= -D__STDC_LIMIT_MACROS
CFLAGS+= -D__STDC_CONSTANT_MACROS
#CFLAGS+= -DNDEBUG
TARGET_ARCH?= ${MACHINE_ARCH}
BUILD_ARCH?= ${MACHINE_ARCH}
Support armv7 builds for userland Make armv7 as a new MACHINE_ARCH. Copy all the places we do armv6 and add armv7 as basically an alias. clang appears to generate code for armv7 by default. armv7 hard float isn't supported by the the in-tree gcc, so it hasn't been updated to have a new default. Support armv7 as a new valid MACHINE_ARCH (and by extension TARGET_ARCH). Add armv7 to the universe build. Differential Revision: https://reviews.freebsd.org/D12010
2017-10-05 23:01:33 +00:00
# Armv6 and armv7 uses hard float abi, unless the CPUTYPE has soft in it.
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
# arm (for armv4 and armv5 CPUs) always uses the soft float ABI.
# For all other targets, we stick with 'unknown'.
Support armv7 builds for userland Make armv7 as a new MACHINE_ARCH. Copy all the places we do armv6 and add armv7 as basically an alias. clang appears to generate code for armv7 by default. armv7 hard float isn't supported by the the in-tree gcc, so it hasn't been updated to have a new default. Support armv7 as a new valid MACHINE_ARCH (and by extension TARGET_ARCH). Add armv7 to the universe build. Differential Revision: https://reviews.freebsd.org/D12010
2017-10-05 23:01:33 +00:00
.if ${TARGET_ARCH:Marmv[67]*} && (!defined(CPUTYPE) || ${CPUTYPE:M*soft*} == "")
For arm targets, place ABI at the end of the target triple For some reason, we have been inserting the ABI specification into the middle of the target triple, when building LLVM, like so: armv6-gnueabi-freebsd12.0 This is the wrong way around. LLVM even auto-canonicalizes it to: armv6--freebsd12.0-gnueabi Let's do this the right way in llvm.build.mk instead. While here, define a proper VENDOR macro which can be overridden easily. Reviewed by: emaste MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D10846
2017-06-01 21:05:56 +00:00
TARGET_ABI= -gnueabihf
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
.elif ${TARGET_ARCH:Marm*}
For arm targets, place ABI at the end of the target triple For some reason, we have been inserting the ABI specification into the middle of the target triple, when building LLVM, like so: armv6-gnueabi-freebsd12.0 This is the wrong way around. LLVM even auto-canonicalizes it to: armv6--freebsd12.0-gnueabi Let's do this the right way in llvm.build.mk instead. While here, define a proper VENDOR macro which can be overridden easily. Reviewed by: emaste MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D10846
2017-06-01 21:05:56 +00:00
TARGET_ABI= -gnueabi
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
.else
For arm targets, place ABI at the end of the target triple For some reason, we have been inserting the ABI specification into the middle of the target triple, when building LLVM, like so: armv6-gnueabi-freebsd12.0 This is the wrong way around. LLVM even auto-canonicalizes it to: armv6--freebsd12.0-gnueabi Let's do this the right way in llvm.build.mk instead. While here, define a proper VENDOR macro which can be overridden easily. Reviewed by: emaste MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D10846
2017-06-01 21:05:56 +00:00
TARGET_ABI=
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
.endif
For arm targets, place ABI at the end of the target triple For some reason, we have been inserting the ABI specification into the middle of the target triple, when building LLVM, like so: armv6-gnueabi-freebsd12.0 This is the wrong way around. LLVM even auto-canonicalizes it to: armv6--freebsd12.0-gnueabi Let's do this the right way in llvm.build.mk instead. While here, define a proper VENDOR macro which can be overridden easily. Reviewed by: emaste MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D10846
2017-06-01 21:05:56 +00:00
VENDOR= unknown
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
OS_VERSION= freebsd12.0
Prefix {TARGET,BUILD}_TRIPLE with LLVM_ to avoid Makefile.inc1 collision. The Makefile.inc1 TARGET_TRIPLE is for specifying which -target is used during the build of world. MFC after: 2 weeks Reviewed by: dim, imp Sponsored by: Dell EMC Isilon Differential Revision: https://reviews.freebsd.org/D12792
2017-10-25 21:45:55 +00:00
LLVM_TARGET_TRIPLE?= ${TARGET_ARCH:C/amd64/x86_64/:C/arm64/aarch64/}-${VENDOR}-${OS_VERSION}${TARGET_ABI}
LLVM_BUILD_TRIPLE?= ${BUILD_ARCH:C/amd64/x86_64/:C/arm64/aarch64/}-${VENDOR}-${OS_VERSION}
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
Prefix {TARGET,BUILD}_TRIPLE with LLVM_ to avoid Makefile.inc1 collision. The Makefile.inc1 TARGET_TRIPLE is for specifying which -target is used during the build of world. MFC after: 2 weeks Reviewed by: dim, imp Sponsored by: Dell EMC Isilon Differential Revision: https://reviews.freebsd.org/D12792
2017-10-25 21:45:55 +00:00
CFLAGS+= -DLLVM_DEFAULT_TARGET_TRIPLE=\"${LLVM_TARGET_TRIPLE}\"
CFLAGS+= -DLLVM_HOST_TRIPLE=\"${LLVM_BUILD_TRIPLE}\"
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+= -DDEFAULT_SYSROOT=\"${TOOLS_PREFIX}\"
Add function and data sections when building llvm, clang, lld and lldb, and allow the linker to garbage collect them. This shaves off up to a few MB from the final executables. MFC after: 3 days
2017-04-20 21:00:09 +00:00
CFLAGS+= -ffunction-sections
CFLAGS+= -fdata-sections
LDFLAGS+= -Wl,--gc-sections
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
CXXFLAGS+= -std=c++11
CXXFLAGS+= -fno-exceptions
CXXFLAGS+= -fno-rtti
CXXFLAGS.clang+= -stdlib=libc++
.if ${MACHINE_CPUARCH} == "arm"
Add -mlong-calls also to LLVM's STATIC_CFLAGS on ARM -mlong-calls was set only in STATIC_CXXFLAGS, but there are some .c source files in LLVM which also need -mlong-calls. Unfortunately this is not sufficient to fix linking lldb on ARM, because LLVM-generated calls to __aeabi_read_tp do not honour the -mlong-calls flag. See LLVM PR31769 for details. Reviewed by: dim Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D9348
2017-01-27 21:26:23 +00:00
STATIC_CFLAGS+= -mlong-calls
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
STATIC_CXXFLAGS+= -mlong-calls
.endif
Reference in New Issue Copy Permalink