kristina added a comment.
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,
kristina added a comment.
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
lebedev.ri added a comment.
> 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
pirama added a comment.
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.
Repository:
rC Clang
pirama updated this revision to Diff 165118.
pirama added a comment.
Herald added a subscriber: fedor.sergeev.
Add empty source file to silence CMake warning.
Support more platforms, similar to libLLVM.so
Repository:
rC Clang
https://reviews.llvm.org/D50359
Files:
CMakeLists.txt
pirama added a comment.
This implements the new library proposed in
http://lists.llvm.org/pipermail/cfe-dev/2018-August/058736.html.
Repository:
rC Clang
https://reviews.llvm.org/D50359
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
pirama created this revision.
Herald added a subscriber: mgorny.
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
