Commit Graph

5 Commits

Author SHA1 Message Date
John Baldwin
de6feefdb7 Improve the coverage of debug symbols for MK_DEBUG_FILES.
- Include debug symbols in static libraries.  This permits binaries
  to include debug symbols for functions obtained from static libraries.
- Permit the C/C++ compiler flags added for MK_DEBUG_FILES to be
  overridden by setting DEBUG_FILES_CFLAGS.  Use this to limit the debug
  information for llvm libraries and binaries.

Reviewed by:	emaste
Sponsored by:	DARPA / AFRL
Differential Revision:	https://reviews.freebsd.org/D12025
2017-08-23 23:30:25 +00:00
Dimitry Andric
b989893ac8 Undo r305299, since it also sets up BINDIR, via usr.bin/Makefile.inc.
Just set WARNS to zero instead.
2016-09-02 20:07:05 +00:00
Dimitry Andric
710f7c3aa1 For now, undo the WARNS=3 setting for the clang and llvm tools. More
work needs to be done first to get everything compiling without warnings.
2016-09-02 19:26:39 +00:00
Dimitry Andric
e92a9ae100 Compile clang, lldb and related tools with WARNS=3 by default. 2016-08-27 16:01:10 +00:00
Dimitry Andric
986e05bc2a 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