The current libclang.so exports only the symbols required for the stable
C api. This is opposed to libLLVM.so, which exports all the symbols
from the LLVM libraries, including those from the C++ API. This patch
adds libclang-cxx.so that is similar to libLLVM.so and exports all
symbols from the clang libraries. The motivation for this library is to
be used by Clang tools that use Clang's C++ api. They no longer need to
link against the individual static libraries.
Details
- Reviewers
- None
Diff Detail
- Repository
- rC Clang
- Build Status
Buildable 21148 Build 21148: arc lint + arc unit
Event Timeline
This implements the new library proposed in http://lists.llvm.org/pipermail/cfe-dev/2018-August/058736.html.
Add empty source file to silence CMake warning.
Support more platforms, similar to libLLVM.so
As I mentioned in the discussion, we decided to carry build rules for the proposed library in downstream. I've updated this to make it more general, and will leave it open in case there's more interest to revive it in the future.
The motivation for this library is to
be used by Clang tools that use Clang's C++ api. They no longer need to
link against the individual static libraries.
I would personally consider that to be a regression.
It hides layering violations.
Of course, in downstream one might not care.
I'm in support as long as it's a configuration option defaulting similar to LLVM's one. Should likely follow the same naming convention as LLVM, ie. clang-shlib. Clang has a lot of tools it ships with especially if you consider extras, I think this is one of the cases where an exception for libClang-8.so can be made as long as it's not a default. It would make builds of things like clang-tidy much faster without requiring a fully shared library build.
IIRC libclang is a tool in itself, and is not mandatory for Clang driver tool build which is the most fundamental part to most customers, while this new library is not. There are a lot of things the downstream discussions have not covered it seems since this only accounts for for a full Clang+Tools+ARCMT+StaticAnalyzer+Extra (ie. tidy, include fixer) build. This just fails to account for so much. The pairing of libclang and the new shared library defeats the entire point of it altogether, since libclang is not required by the driver. Nor by most in-tree tools.
To elaborate, consider a scenario where a customer wants to build the clang driver, diagtool and just for the sake of the argument change-namespace from extras. Clang tools do not provide nearly the same level of control as most LLVM tools, so in that scenario, you'd have to maintain your own CMakeLists.txt for clang tools(/extra) to neuter unwanted artifacts like clang-tidy or libclang.so (the C API re-exporter) etc.
Unless I deeply misunderstand the functionality of toggles within LLVM's main build system, the only way of neutering those artifacts while still being able to use libclang-cxx.so would be surgery on several CMakeLists as it's not the same as, say, LLVM_TOOL_LLVM_YAML_NUMERIC_PARSER_FUZZER_BUILD=Off which is possible for top level LLVM tools.