In MinGW world, UNIX like lib prefix is preferred for the libraries.
This patch adjusts CMake files to do that.
Differential Revision: https://reviews.llvm.org/D87517
Based on the discussion on D55415, also make the flag default to false.
Having libclang depend on clang-tools-extra means check-clang builds all
of clang-tools-extra, which besides being a layering violation takes
quite some time, since clang-tools-extra has many files that are slow
to compile.
Longer term, we likely will want to remove this flag completely. If
people need this functionality, maybe there could be a
libclang-tools-extra that's libclang + clang-tidy and
clang-includes-fixer linked in.
Differential Revision: https://reviews.llvm.org/D79599
follow-up "libclang: Make shared object symbol exporting by default"
This reverts commit 7a7c753b0c.
This reverts commit 7ff1f55a12.
They broke building libclang.dll on Windows, see
https://reviews.llvm.org/D74564
https://reviews.llvm.org/D74564 enabled static building for libclang,
and for non CMake consumers they had to set the `CMAKE_EXPORTS` define
when consuming libclang.
This commit makes the non CMake users of the static building have to define `CMAKE_NO_EXPORTS`.
Differential Revision: https://reviews.llvm.org/D74907
Without this, the build would sometimes fail with
In file included from clang/tools/libclang/CIndexer.cpp:17:
In file included from clang/include/clang/Driver/Driver.h:15:
clang/include/clang/Driver/Options.h:44:10: fatal error:
'clang/Driver/Options.inc' file not found
#include "clang/Driver/Options.inc"
^~~~~~~~~~~~~~~~~
if Options.inc wasn't generated before libclang was built
by coincidence.
(In the GN build, this works because lib/Driver there declares
the dep on tablegen as a public_dep since the generated file
is part of Driver's public interface, and then things work out
automatically without every client of Driver having to be careful.)
llvm-svn: 371205
Summary:
This will simplify the macros by allowing us to remove the hard-coded
list of libraries that should be installed when
LLVM_INSTALL_TOOLCHAIN_ONLY is enabled.
Reviewers: beanz, smeenai
Reviewed By: beanz
Subscribers: aheejin, mehdi_amini, mgorny, steven_wu, dexonsmith, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D64580
llvm-svn: 365902
Summary:
It is useful to build with _XOPEN_SOURCE defined on AIX, enabling X/Open
and POSIX compatibility mode, to work around stray macros and other
bugs in the headers provided by the system and build compiler.
This patch adds the config to cmake to build with _XOPEN_SOURCE defined
on AIX with a few exceptions. Google Test internals require access to
platform specific thread info constructs on AIX so in that case we build
with _ALL_SOURCE defined instead. Libclang also uses header which needs
_ALL_SOURCE on AIX so we leave that as is as well.
We also add building on AIX with the large file API and doing CMake
header checks with X/OPEN definitions so the results are consistent with
the environment that will be present in the build.
Reviewers: hubert.reinterpretcast, xingxue, andusy
Reviewed By: hubert.reinterpretcast
Subscribers: mgorny, jsji, cfe-commits, llvm-commits
Tags: #llvm, #clang
Differential Revision: https://reviews.llvm.org/D62533
llvm-svn: 362808
Summary:
The current install-clang-headers target installs clang's resource
directory headers. This is different from the install-llvm-headers
target, which installs LLVM's API headers. We want to introduce the
corresponding target to clang, and the natural name for that new target
would be install-clang-headers. Rename the existing target to
install-clang-resource-headers to free up the install-clang-headers name
for the new target, following the discussion on cfe-dev [1].
I didn't find any bots on zorg referencing install-clang-headers. I'll
send out another PSA to cfe-dev to accompany this rename.
[1] http://lists.llvm.org/pipermail/cfe-dev/2019-February/061365.html
Reviewers: beanz, phosek, tstellar, rnk, dim, serge-sans-paille
Subscribers: mgorny, javed.absar, jdoerfert, #sanitizers, openmp-commits, lldb-commits, cfe-commits, llvm-commits
Tags: #clang, #sanitizers, #lldb, #openmp, #llvm
Differential Revision: https://reviews.llvm.org/D58791
llvm-svn: 355340
r344555 switched LLVM to guarding install targets with LLVM_ENABLE_IDE
instead of CMAKE_CONFIGURATION_TYPES, which expresses the intent more
directly and can be overridden by a user. Make the corresponding change
in clang. LLVM_ENABLE_IDE is computed by HandleLLVMOptions, so it should
be available for both standalone and integrated builds.
Differential Revision: https://reviews.llvm.org/D58284
llvm-svn: 354525
libclang can be built in shared or static mode. On Windows, with
LLVM_ENABLE_PIC=OFF, it was built in neither mode, leading to clients of
libclang (c-index-test, c-arcmt-test) failing to link with it set.
Since PIC isn't really a thing on Windows, build libclang in shared mode when
LLVM_ENABLE_PIC=OFF there. This is also somewhat symmetric with the existing
ENABLE_STATIC a few lines down.
Differential Revision: https://reviews.llvm.org/D57258
llvm-svn: 352253
Frontend headers have undefined reference on the symbol `clang::PCHContainerOperations::PCHContainerOperations()` through some shared_ptr usage. Any dependents will get the undefined reference which can only be resolved by explicit dependency on clangSerialization (due to -z defs).
llvm-svn: 349259
This is a more thorough fix of rC348911.
The story about -DBUILD_SHARED_LIBS=on build after rC348907 (Move PCHContainerOperations from Frontend to Serialization) is:
1. libclangSerialization.so defines PCHContainerReader dtor, ...
2. clangFrontend and clangTooling define classes inheriting from PCHContainerReader, thus their DSOs have undefined references on PCHContainerReader dtor
3. Components depending on either clangFrontend or clangTooling cannot be linked unless they have explicit dependency on clangSerialization due to the default linker option -z defs. The explicit dependency could be avoided if libclang{Frontend,Tooling}.so had these undefined references.
This patch adds the explicit dependency on clangSerialization to make them build.
llvm-svn: 348915
Add installation support for the python bindings for libclang. Add an
additional CMake configuration variable to enumerate the python versions for
which the bindings should be installed. This allows for a LLVM/clang
distribution to distribute the python bindings for libclang as part of the
image. Because the python versions need to be explicitly stated by the user,
the default image remains unchanged.
llvm-svn: 340228
Use this function to create the install targets rather than doing so
manually, which gains us the `-stripped` install targets to perform
stripped installations.
Differential Revision: https://reviews.llvm.org/D40675
llvm-svn: 319489
`LLVM_DISTRIBUTION_COMPONENTS` assumes that each component has both
`component` and `install-component` targets. Add a dummy no-op target
for `libclang-headers` to placate this check.
Differential Revision: https://reviews.llvm.org/D39524
llvm-svn: 317188
CLANG_TOOL_EXTRA_BUILD doesn't affect headers.
_CINDEX_LIB_ is defined when the target is SHARED.
On Win32, it affects clang-c/Platform.h and it shouldn't be ignored.
This is part of https://reviews.llvm.org/D35559
llvm-svn: 309557
include-fixer only slightly bloats the size of libclang, but since
libclang has no explicit plugin mechanism it's the only way of getting
this to work. Clang-tidy is already there and so far there weren't many
complaints ;)
This is designed to be easy to remove again if libclang ever grows
proper plugin support.
llvm-svn: 287229
This is a sad workaround for the lack of plugin support in libclang. Depends
on D17807, a tools-extra change that also contains the test case.
This is designed to be easy to remove again if libclang ever grows proper
plugin support.
Differential Revision: http://reviews.llvm.org/D17808
llvm-svn: 262596
LLVM_SUBMIT_VERSION and LLVM_SUBMIT_SUBVERSION are commonly used variable names in the autoconf build system. They seem to have leeched into clang's CMake in a few places, and should just be replaced by the LLVM_VERSION_* variables where appropriate.
llvm-svn: 250246
- introduces a new cc1 option -fmodule-format=[raw,obj]
with 'raw' being the default
- supports arbitrary module container formats that libclang is agnostic to
- adds the format to the module hash to avoid collisions
- splits the old PCHContainerOperations into PCHContainerWriter and
a PCHContainerReader.
Thanks to Richard Smith for reviewing this patch!
llvm-svn: 242499
This patch adds ObjectFilePCHContainerOperations uses the LLVM backend
to put the contents of a PCH into a __clangast section inside a COFF, ELF,
or Mach-O object file container.
This is done to facilitate module debugging by makeing it possible to
store the debug info for the types defined by a module alongside the AST.
rdar://problem/20091852
llvm-svn: 241620