Commit Graph

29 Commits

Author SHA1 Message Date
Shoaib Meenai 56f7e5a822 [cmake] Add support for multiple distributions
LLVM's build system contains support for configuring a distribution, but
it can often be useful to be able to configure multiple distributions
(e.g. if you want separate distributions for the tools and the
libraries). Add this support to the build system, along with
documentation and usage examples.

Reviewed By: phosek

Differential Revision: https://reviews.llvm.org/D89177
2021-05-12 11:13:18 -07:00
Han Zhu 0c9230dad1 Reland [libclang] Install both libclang.a and libclang.so when LIBCLANG_BUILD_STATIC=ON
f8990feb12 enabled installing PIC version of both libclang.a and
libclang.so when LIBCLANG_BUILD_STATIC is ON. But it broke the no-PIC
build when LLVM_ENABLE_PIC=OFF with the following error:

```
CMake Error at
/b/s/w/ir/cache/builder/src/third_party/llvm/clang/tools/libclang/CMakeLists.txt:123
(target_compile_definitions):
    target_compile_definitions called with non-compilable target type
```

This is because as the code loops through ${name} and ${name}_static, it
introduced a side effect, which is adding an empty libclang_static to
targets. Later target_compile_definitions is called on libclang_static.
That function requires that target must have been created by a command
such as add_executable() or add_library(), so it crashed.

The solution is to not naively loop through both libclang and
libclang_static, but only the ones that are actually added by
llvm_add_library(). Here's the library build type to library target name
mapping:

| SHARED only | libclang |
| STATIC only | libclang |
| SHARED and STATIC | libclang and libclang_static |

So only when SHARED and STATIC are both set should we loop through two
targets. Explicitly parse the STATIC argument and set the list
accordingly.

Reviewed By: smeenai

Differential Revision: https://reviews.llvm.org/D79059
2020-05-06 19:33:58 -07:00
Hans Wennborg f03b505ee7 Revert f8990feb12 "[libclang] Install both libclang.a and libclang.so when LIBCLANG_BUILD_STATIC=ON"
This broke builds configured with

$ cmake -GNinja -DCMAKE_BUILD_TYPE=Release '-DLLVM_ENABLE_PROJECTS=clang' '-DLLVM_TARGETS_TO_BUILD=X86' -DLLVM_ENABLE_PIC=OFF ../llvm

CMake Error at
/b/s/w/ir/cache/builder/src/third_party/llvm/clang/tools/libclang/CMakeLists.txt:123
(target_compile_definitions):
    target_compile_definitions called with non-compilable target type

This reverts commit f8990feb12.
2020-04-28 10:10:33 +02:00
Han Zhu f8990feb12 [libclang] Install both libclang.a and libclang.so when LIBCLANG_BUILD_STATIC=ON
When LIBCLANG_BUILD_STATIC=ON and LLVM_ENABLE_PIC=ON, PIC version of
libclang.a and libclang.so are built as expected. However libclang.a is
not installed. Looking at the macro llvm_add_library(), when both SHARED
and STATIC are set, it renames the static library to ${name}_static and
then adds it to targets. But when add_clang_library() calls install, it
only checks if ${name} is in targets.

To work around this issue, loop through both ${name} and ${name}_static
and install both of them if they're in targets. This is still correct if
only shared or static library is built. In those cases, only ${name} is
added to targets and cmake install will generate the right install
script depending on the library's type.

Test Plan:
cmake with LIBCLANG_BUILD_STATIC=ON and then ninja install, from master
and this diff. Compare the result directory trees. Confirm that only
difference is the added libclang.a.

Differential Revision: https://reviews.llvm.org/D78534
2020-04-27 13:37:07 -07:00
Stephen Neuendorffer 0c0831f74b [CMAKE] Plumb include_directories() into tablegen()
Previously, the tablegen() cmake command, which defines custom
commands for running tablegen, included several hardcoded paths.  This
becomes unwieldy as there are more users for which these paths are
insufficient.  For most targets, cmake uses include_directories() and
the INCLUDE_DIRECTORIES directory property to specify include paths.
This change picks up the INCLUDE_DIRECTORIES property and adds it
to the include path used when running tablegen.  As a side effect, this
allows us to remove several hard coded paths to tablegen that are redundant
with specified include_directories().

I haven't removed the hardcoded path to CMAKE_CURRENT_SOURCE_DIR, which
seems generically useful.  There are several users in clang which apparently
don't have the current directory as an include_directories().  This could
be considered separately.

The new version of this path uses list APPEND rather than list TRANSFORM,
in order to be compatible with cmake 3.4.3. If we update to cmake 3.12 then
we can use list TRANSFORM instead.

Differential Revision: https://reviews.llvm.org/D77156
2020-04-03 11:23:38 -07:00
Stephen Neuendorffer f288c21687 Revert "[CMAKE] Plumb include_directories() into tablegen()"
This reverts commit ae044c5b0c.

This breaks the buildbots, which use an older version of cmake.
2020-04-03 10:47:36 -07:00
Stephen Neuendorffer ae044c5b0c [CMAKE] Plumb include_directories() into tablegen()
Previously, the tablegen() cmake command, which defines custom
commands for running tablegen, included several hardcoded paths.  This
becomes unwieldy as there are more users for which these paths are
insufficient.  For most targets, cmake uses include_directories() and
the INCLUDE_DIRECTORIES directory property to specify include paths.
This change picks up the INCLUDE_DIRECTORIES property and adds it
to the include path used when running tablegen.  As a side effect, this
allows us to remove several hard coded paths to tablegen that are redundant
with specified include_directories().

I haven't removed the hardcoded path to CMAKE_CURRENT_SOURCE_DIR, which
seems generically useful.  There are several users in clang which apparently
don't have the current directory as an include_directories().  This could
be considered separately.

Differential Revision: https://reviews.llvm.org/D77156
2020-04-03 10:38:25 -07:00
John McCall c82e4ef696 Always -I clang/include when tblgen'ing in Clang. 2019-12-16 13:33:59 -05:00
Jordan Rose 5fd467feb8 [CMake] Clang: Don't use object libraries with Xcode
Undoes some of the effects of r360946 when using the Xcode CMake
generator---it doesn't handle object libraries correctly at all.
Attempts to still honor BUILD_SHARED_LIBS for Xcode, but I didn't
actually test it. Should have no effect on non-Xcode generators.

https://reviews.llvm.org/D68430

llvm-svn: 373769
2019-10-04 18:17:58 +00:00
Tom Stellard a196469e67 cmake: Add INSTALL_WITH_TOOLCHAIN option to add_*_library macros
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
2019-07-12 14:40:18 +00:00
Sylvestre Ledru 76b26550e9 Rename libclang_shared to libclang-cpp
Summary: Fix bug 42475

Reviewers: beanz, tstellar

Reviewed By: beanz

Subscribers: kimgr, mgorny, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D64278

llvm-svn: 365831
2019-07-11 21:42:55 +00:00
Tom Stellard 2e97d2aa1b cmake: Add CLANG_LINK_CLANG_DYLIB option
Summary:
Setting CLANG_LINK_CLANG_DYLIB=ON causes clang tools to link against
libclang_shared.so instead of the individual component libraries.

Reviewers: mgorny, beanz, smeenai, phosek, sylvestre.ledru

Subscribers: arphaman, cfe-commits, llvm-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D63503

llvm-svn: 365092
2019-07-03 22:45:55 +00:00
Chris Bieneman dbc2a12c73 Fix BUILD_SHARED_LIBS for clang which broke in D61909
llvm_add_library ignores `BUILD_SHARED_LIBS` `STATIC` is explicitly specified. This restores the `BUILD_SHARED_LIBS` behavior to the clang build.

llvm-svn: 361271
2019-05-21 15:56:17 +00:00
Chris Bieneman 876e39937e Re-land: Add Clang shared library with C++ exports
Summary:
This patch adds a libClang_shared library on *nix systems which exports the entire C++ API. In order to support this on Windows we should really refactor llvm-shlib and share code between the two.

This also uses a slightly different method for generating the shared library, which I should back-port to llvm-shlib. Instead of linking the static archives and passing linker flags to force loading the whole libraries, this patch creates object libraries for every library (which has no cost in the build system), and link the object libraries.

llvm-svn: 360985
2019-05-17 04:20:01 +00:00
Nico Weber 457d7caac8 Revert r360946 "Add Clang shared library with C++ exports"
It breaks LLVM_ENABLE_PIC=OFF builds, and it's not clear
if the object library approach doesn't impact the normal
clang binary.

llvm-svn: 360973
2019-05-17 01:42:37 +00:00
Chris Bieneman 10fba12e50 Add Clang shared library with C++ exports
Summary:
This patch adds a libClang_shared library on *nix systems which exports the entire C++ API. In order to support this on Windows we should really refactor llvm-shlib and share code between the two.

This also uses a slightly different method for generating the shared library, which I should back-port to llvm-shlib. Instead of linking the static archives and passing linker flags to force loading the whole libraries, this patch creates object libraries for every library (which has no cost in the build system), and link the object libraries.

Reviewers: tstellar, winksaville

Subscribers: mgorny, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D61909

llvm-svn: 360946
2019-05-16 22:06:07 +00:00
Shoaib Meenai 19c45546fc [cmake] Reset variable before using it
A bunch of macros use the same variable name, and since CMake macros
don't get their own scope, the value persists across macro invocations,
and we can end up exporting targets which shouldn't be exported. Clear
the variable before each use to avoid this.

Converting these macros to functions would also help, since it would
avoid the variable leaking into its parent scope, and that's something I
plan to follow up with. It won't fully address the problem, however,
since functions still inherit variables from their parent scopes, so if
someone in the parent scope just happened to use the same variable name
we'd still have the same issue.

llvm-svn: 357036
2019-03-26 22:16:53 +00:00
Shoaib Meenai c2b3f62315 [cmake] Create exports for umbrella library targets
When using the umbrella llvm-libraries and clang-libraries targets, we
should export all library targets, otherwise they'll be part of our
distribution but not usable from the CMake package.

Differential Revision: https://reviews.llvm.org/D58862

llvm-svn: 355354
2019-03-05 00:38:32 +00:00
Shoaib Meenai 5be71faf4b [build] Rename clang-headers to clang-resource-headers
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
2019-03-04 21:19:53 +00:00
Shoaib Meenai defb5a383b [clang] Switch to LLVM_ENABLE_IDE
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
2019-02-20 23:08:43 +00:00
Shoaib Meenai d705864074 [clang] Add build and install targets for clang libraries
This is modeled after the existing llvm-libraries target. It's a
convenient way to include all clang libraries in a distribution.

This differs slightly from the llvm-libraries target in that it adds any
library added via add_clang_library, whereas llvm-libraries only
includes targets added via add_llvm_library that didn't use the MODULE
or BUILDTREE_ONLY arguments. add_clang_library doesn't appear to have
any equivalents of those arguments, so the conditions don't apply.

Differential Revision: https://reviews.llvm.org/D58269

llvm-svn: 354141
2019-02-15 15:59:04 +00:00
Shoaib Meenai b4ff1abae2 [clang] Create install targets for non-shared libraries
I don't see a reason for these to not have install targets created,
which in turn allows them to be bundled in distributions. This doesn't
affect the "install" target, since that just runs all CMake install
rules (and we were already creating install rules for these).

Differential Revision: https://reviews.llvm.org/D58268

llvm-svn: 354140
2019-02-15 15:59:02 +00:00
Haojian Wu 06098849c6 Build clang-headers when building clang tools.
Summary:
clang tools require clang headers to work on real project, e.g. when we
build clangd via `ninja clangd`, we expect the binary can run on
real-world project (without running another command `ninja clang-headers`).

Reviewers: sammccall

Reviewed By: sammccall

Subscribers: mgorny, ilya-biryukov, ioeric, kadircet, cfe-commits

Differential Revision: https://reviews.llvm.org/D52714

llvm-svn: 343459
2018-10-01 12:16:38 +00:00
Shoaib Meenai 669cae1f28 [clang] Use add_llvm_install_targets
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
2017-11-30 22:35:02 +00:00
Justin Bogner 5ca4d5f5fe cmake: Don't try to install exports if there aren't any
When using LLVM_DISTRIBUTION_COMPONENTS, it's possible for clang's
export list to be empty. If this happens the install(EXPORTS) command
will fail, but since there isn't anything to install anyway we really
just want to skip it.

llvm-svn: 286210
2016-11-08 05:02:33 +00:00
Justin Bogner 66b326bc55 cmake: Support exports correctly with LLVM_DISTRIBUTION_COMPONENTS
We need to apply the same export logic in clang as in llvm for
LLVM_DISTRIBUTION_COMPONENTS, or the clang exports will be invalid
when we use this config.

This makes using distribution components without setting
LLVM_TOOLCHAIN_ONLY=On work correctly.

llvm-svn: 286181
2016-11-07 23:46:05 +00:00
Michael Gottesman 66cc2d5210 [cmake] Follow LLVM's lead in creating exported tool targets for clang tools.
This is needed by downstream projects such as swift to get proper cmake
dependency information for LLVM/Clang targets.

A few months ago I added support for exporting this information for Clang
libraries. In order to be incremental, I did not add support for exporting clang
tools as well at that time. Now such support is needed, so I am committing this
incremental code.

llvm-svn: 284658
2016-10-19 22:46:06 +00:00
Michael Gottesman eb396a6cbf Add CLANG_BUILD_TOOLS as a clang counterpart for LLVM_BUILD_TOOLS
LLVM_BUILD_TOOLS is a boolean variable that controls whether or not generated
targets for llvm tools are built by the "all" target. CLANG_BUILD_TOOLS is an
analogous variable for clang targets.

This is useful functionality for selectively disabling the building of clang
targets by default to speed up builds.

In terms of implementation, I just followed the model of LLVM's implementation
of this functionality.

llvm-svn: 275006
2016-07-10 01:44:00 +00:00
Michael Gottesman ca589ccb02 Move add_clang_* entry points from the main clang CMakeLists.txt to cmake/modules/AddClang.cmake.
This matches how LLVM has its cmake files organized and is cleaner than just
shoving this business logic into the main CMakeLists.txt.

llvm-svn: 274992
2016-07-09 21:58:40 +00:00