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$
|
|
|
|
|
|
Add support for selectively enabling LLVM targets
This makes it possible, through src.conf(5) settings, to select which
LLVM targets you want to build during buildworld. The current list is:
* (WITH|WITHOUT)_LLVM_TARGET_AARCH64
* (WITH|WITHOUT)_LLVM_TARGET_ARM
* (WITH|WITHOUT)_LLVM_TARGET_MIPS
* (WITH|WITHOUT)_LLVM_TARGET_POWERPC
* (WITH|WITHOUT)_LLVM_TARGET_SPARC
* (WITH|WITHOUT)_LLVM_TARGET_X86
To not influence anything right now, all of these are on by default, in
situations where clang is enabled.
Selectively turning a few targets off manually should work. Turning on
only one target should work too, even if that target does not correspond
to the build architecture. (In that case, LLVM_NATIVE_ARCH will not be
defined, and you can only use the resulting clang executable for
cross-compiling.)
I performed a few measurements on one of the FreeBSD.org reference
machines, building clang from scratch, with all targets enabled, and
with only the x86 target enabled. The latter was ~12% faster in real
time (on a 32-core box), and ~14% faster in user time. For a full
buildworld the difference will probably be less pronounced, though.
Reviewed by: bdrewery
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D11077
2018-06-22 15:00:00 +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 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}
|
|
|
|
|
|
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
|
|
|
|
|
CFLAGS+= -D__STDC_CONSTANT_MACROS
|
2019-08-23 22:17:36 +00:00
|
|
|
CFLAGS+= -D__STDC_FORMAT_MACROS
|
|
|
|
|
CFLAGS+= -D__STDC_LIMIT_MACROS
|
2019-09-06 20:38:25 +00:00
|
|
|
CFLAGS+= -DHAVE_VCS_VERSION_INC
|
2018-10-21 15:54:38 +00:00
|
|
|
#CFLAGS+= -DNDEBUG
|
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
|
|
|
|
|
|
|
|
TARGET_ARCH?= ${MACHINE_ARCH}
|
|
|
|
|
BUILD_ARCH?= ${MACHINE_ARCH}
|
|
|
|
|
|
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'.
|
2017-10-05 23:01:33 +00:00
|
|
|
.if ${TARGET_ARCH:Marmv[67]*} && (!defined(CPUTYPE) || ${CPUTYPE:M*soft*} == "")
|
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*}
|
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
|
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
|
2017-06-01 21:05:56 +00:00
|
|
|
VENDOR= unknown
|
2018-10-19 00:37:47 +00:00
|
|
|
OS_VERSION= freebsd13.0
|
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
|
|
|
|
2019-11-12 21:35:05 +00:00
|
|
|
LLVM_TARGET_TRIPLE?= ${TARGET_ARCH:C/amd64/x86_64/:C/[hs]f$//:S/mipsn32/mips64/}-${VENDOR}-${OS_VERSION}${TARGET_ABI}
|
|
|
|
|
LLVM_BUILD_TRIPLE?= ${BUILD_ARCH:C/amd64/x86_64/:C/[hs]f$//:S/mipsn32/mips64/}-${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
|
|
|
|
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 support for selectively enabling LLVM targets
This makes it possible, through src.conf(5) settings, to select which
LLVM targets you want to build during buildworld. The current list is:
* (WITH|WITHOUT)_LLVM_TARGET_AARCH64
* (WITH|WITHOUT)_LLVM_TARGET_ARM
* (WITH|WITHOUT)_LLVM_TARGET_MIPS
* (WITH|WITHOUT)_LLVM_TARGET_POWERPC
* (WITH|WITHOUT)_LLVM_TARGET_SPARC
* (WITH|WITHOUT)_LLVM_TARGET_X86
To not influence anything right now, all of these are on by default, in
situations where clang is enabled.
Selectively turning a few targets off manually should work. Turning on
only one target should work too, even if that target does not correspond
to the build architecture. (In that case, LLVM_NATIVE_ARCH will not be
defined, and you can only use the resulting clang executable for
cross-compiling.)
I performed a few measurements on one of the FreeBSD.org reference
machines, building clang from scratch, with all targets enabled, and
with only the x86 target enabled. The latter was ~12% faster in real
time (on a 32-core box), and ~14% faster in user time. For a full
buildworld the difference will probably be less pronounced, though.
Reviewed by: bdrewery
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D11077
2018-06-22 15:00:00 +00:00
|
|
|
.if ${MK_LLVM_TARGET_AARCH64} != "no"
|
|
|
|
|
CFLAGS+= -DLLVM_TARGET_ENABLE_AARCH64
|
|
|
|
|
. if ${MACHINE_CPUARCH} == "aarch64"
|
|
|
|
|
LLVM_NATIVE_ARCH= AArch64
|
|
|
|
|
. endif
|
|
|
|
|
.endif
|
|
|
|
|
.if ${MK_LLVM_TARGET_ARM} != "no"
|
|
|
|
|
CFLAGS+= -DLLVM_TARGET_ENABLE_ARM
|
|
|
|
|
. if ${MACHINE_CPUARCH} == "arm"
|
|
|
|
|
LLVM_NATIVE_ARCH= ARM
|
|
|
|
|
. endif
|
|
|
|
|
.endif
|
2018-08-09 21:28:31 +00:00
|
|
|
.if ${MK_LLVM_TARGET_BPF} != "no"
|
|
|
|
|
CFLAGS+= -DLLVM_TARGET_ENABLE_BPF
|
|
|
|
|
.endif
|
Add support for selectively enabling LLVM targets
This makes it possible, through src.conf(5) settings, to select which
LLVM targets you want to build during buildworld. The current list is:
* (WITH|WITHOUT)_LLVM_TARGET_AARCH64
* (WITH|WITHOUT)_LLVM_TARGET_ARM
* (WITH|WITHOUT)_LLVM_TARGET_MIPS
* (WITH|WITHOUT)_LLVM_TARGET_POWERPC
* (WITH|WITHOUT)_LLVM_TARGET_SPARC
* (WITH|WITHOUT)_LLVM_TARGET_X86
To not influence anything right now, all of these are on by default, in
situations where clang is enabled.
Selectively turning a few targets off manually should work. Turning on
only one target should work too, even if that target does not correspond
to the build architecture. (In that case, LLVM_NATIVE_ARCH will not be
defined, and you can only use the resulting clang executable for
cross-compiling.)
I performed a few measurements on one of the FreeBSD.org reference
machines, building clang from scratch, with all targets enabled, and
with only the x86 target enabled. The latter was ~12% faster in real
time (on a 32-core box), and ~14% faster in user time. For a full
buildworld the difference will probably be less pronounced, though.
Reviewed by: bdrewery
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D11077
2018-06-22 15:00:00 +00:00
|
|
|
.if ${MK_LLVM_TARGET_MIPS} != "no"
|
|
|
|
|
CFLAGS+= -DLLVM_TARGET_ENABLE_MIPS
|
|
|
|
|
. if ${MACHINE_CPUARCH} == "mips"
|
|
|
|
|
LLVM_NATIVE_ARCH= Mips
|
|
|
|
|
. endif
|
|
|
|
|
.endif
|
|
|
|
|
.if ${MK_LLVM_TARGET_POWERPC} != "no"
|
|
|
|
|
CFLAGS+= -DLLVM_TARGET_ENABLE_POWERPC
|
|
|
|
|
. if ${MACHINE_CPUARCH} == "powerpc"
|
|
|
|
|
LLVM_NATIVE_ARCH= PowerPC
|
|
|
|
|
. endif
|
|
|
|
|
.endif
|
2019-04-07 18:24:26 +00:00
|
|
|
.if ${MK_LLVM_TARGET_RISCV} != "no"
|
|
|
|
|
CFLAGS+= -DLLVM_TARGET_ENABLE_RISCV
|
|
|
|
|
. if ${MACHINE_CPUARCH} == "riscv"
|
|
|
|
|
LLVM_NATIVE_ARCH= RISCV
|
|
|
|
|
. endif
|
|
|
|
|
.endif
|
Add support for selectively enabling LLVM targets
This makes it possible, through src.conf(5) settings, to select which
LLVM targets you want to build during buildworld. The current list is:
* (WITH|WITHOUT)_LLVM_TARGET_AARCH64
* (WITH|WITHOUT)_LLVM_TARGET_ARM
* (WITH|WITHOUT)_LLVM_TARGET_MIPS
* (WITH|WITHOUT)_LLVM_TARGET_POWERPC
* (WITH|WITHOUT)_LLVM_TARGET_SPARC
* (WITH|WITHOUT)_LLVM_TARGET_X86
To not influence anything right now, all of these are on by default, in
situations where clang is enabled.
Selectively turning a few targets off manually should work. Turning on
only one target should work too, even if that target does not correspond
to the build architecture. (In that case, LLVM_NATIVE_ARCH will not be
defined, and you can only use the resulting clang executable for
cross-compiling.)
I performed a few measurements on one of the FreeBSD.org reference
machines, building clang from scratch, with all targets enabled, and
with only the x86 target enabled. The latter was ~12% faster in real
time (on a 32-core box), and ~14% faster in user time. For a full
buildworld the difference will probably be less pronounced, though.
Reviewed by: bdrewery
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D11077
2018-06-22 15:00:00 +00:00
|
|
|
.if ${MK_LLVM_TARGET_SPARC} != "no"
|
|
|
|
|
CFLAGS+= -DLLVM_TARGET_ENABLE_SPARC
|
|
|
|
|
. if ${MACHINE_CPUARCH} == "sparc64"
|
|
|
|
|
LLVM_NATIVE_ARCH= Sparc
|
|
|
|
|
. endif
|
|
|
|
|
.endif
|
|
|
|
|
.if ${MK_LLVM_TARGET_X86} != "no"
|
|
|
|
|
CFLAGS+= -DLLVM_TARGET_ENABLE_X86
|
|
|
|
|
. if ${MACHINE_CPUARCH} == "i386" || ${MACHINE_CPUARCH} == "amd64"
|
|
|
|
|
LLVM_NATIVE_ARCH= X86
|
|
|
|
|
. endif
|
|
|
|
|
.endif
|
|
|
|
|
|
|
|
|
|
.ifdef LLVM_NATIVE_ARCH
|
|
|
|
|
CFLAGS+= -DLLVM_NATIVE_ASMPARSER=LLVMInitialize${LLVM_NATIVE_ARCH}AsmParser
|
|
|
|
|
CFLAGS+= -DLLVM_NATIVE_ASMPRINTER=LLVMInitialize${LLVM_NATIVE_ARCH}AsmPrinter
|
|
|
|
|
CFLAGS+= -DLLVM_NATIVE_DISASSEMBLER=LLVMInitialize${LLVM_NATIVE_ARCH}Disassembler
|
|
|
|
|
CFLAGS+= -DLLVM_NATIVE_TARGET=LLVMInitialize${LLVM_NATIVE_ARCH}Target
|
|
|
|
|
CFLAGS+= -DLLVM_NATIVE_TARGETINFO=LLVMInitialize${LLVM_NATIVE_ARCH}TargetInfo
|
|
|
|
|
CFLAGS+= -DLLVM_NATIVE_TARGETMC=LLVMInitialize${LLVM_NATIVE_ARCH}TargetMC
|
|
|
|
|
.endif
|
|
|
|
|
|
2017-04-20 21:00:09 +00:00
|
|
|
CFLAGS+= -ffunction-sections
|
|
|
|
|
CFLAGS+= -fdata-sections
|
|
|
|
|
LDFLAGS+= -Wl,--gc-sections
|
|
|
|
|
|
Standardize `-std=c++* as `CXXSTD`
CXXSTD was added as the C++ analogue to CSTD.
CXXSTD defaults to `-std=c++11` with supporting compilers; `-std=gnu++98`,
otherwise for older versions of g++.
This change standardizes the CXXSTD variable, originally added to
googletest.test.inc.mk as part of r345203.
As part of this effort, convert all `CXXFLAGS+= -std=*` calls to use `CXXSTD`.
Notes:
This value is not sanity checked in bsd.sys.mk, however, given the two
most used C++ compilers on FreeBSD (clang++ and g++) support both modes, it is
likely to work with both toolchains. This method will be refined in the future
to support more variants of C++, as not all versions of clang++ and g++ (for
instance) support C++14, C++17, etc.
Any manual appending of `-std=*` to `CXXFLAGS` should be replaced with CXXSTD.
Example:
Before this commit:
```
CXXFLAGS+= -std=c++14
```
After this commit:
```
CXXSTD= c++14
```
Reviewed by: asomers
Approved by: emaste (mentor)
MFC after: 1 month
MFC with: r345203, r345704, r345705
Relnotes: yes
Tested with: make tinderbox
Differential Revision: https://reviews.freebsd.org/D19732
2019-03-29 18:45:27 +00:00
|
|
|
CXXSTD?= c++11
|
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+= -fno-exceptions
|
|
|
|
|
CXXFLAGS+= -fno-rtti
|
|
|
|
|
CXXFLAGS.clang+= -stdlib=libc++
|
|
|
|
|
|
|
|
|
|
.if ${MACHINE_CPUARCH} == "arm"
|
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
|
