The clang-resource-headers CMake target is not exported from the
packaged LLVM/Clang CMake modules, so we synthesize it by explicitly
copying resource/built-in headers from the package install root to the
build dir.
Clang 16 changed the structure not to use major.minor.patch but rather
just the major version (in line with LLVM versioning at large).
Adjust so we pick up the headers from the right place, and put them
where Clang libraries will be looking.
This makes it possible to build IWYU as part of LLVM using the
LLVM_EXTERNAL_PROJECTS feature of the LLVM build system.
Add separate instructions for this build mode to README.
Based on original patch from @bc-lee:
https://github.com/include-what-you-use/include-what-you-use/pull/994
This is the same kind of activity as looking for LLVM/Clang packages, and
synthesizing targets, so let's do it up-front.
Move the compile-option setting together with the others.
... instead of legacy add_definitions and include_directories.
Move compile options to after target is defined.
Batch abstract target properties with set_target_properties, looks nicer
than setting them individually.
* Use hanging closing parentheses for multiline invocations consistently
* Shorten overlong lines to colwidth 80
* Consistent placing of PRIVATE keyword
* Add space after if
In the parent commit, I forgot to update the build so that include-what-you-use
links with all targets, which led to link failures for builds against LLVM build
trees (as opposed to the Debian packages).
While troubleshooting this, I found a patch by @Romain-Geissler-1A that I had
previously misunderstood/overlooked:
https://github.com/include-what-you-use/include-what-you-use/pull/854#issuecomment-732487734
Borrowing the link dependencies from that patch to complete my accidental
plagiarism fixes the build again.
Slightly different /EH flags are now provided by LLVM's CMake system,
and MSVC warns that they're inconsistent.
They're the same in spirit, so let LLVM decide.
The LLVM headers require -std=c++14 to parse and several compilers are
not C++14 by default.
IWYU itself currently only needs C++11, but LLVM does not announce its
minimum required C++ standard anywhere in its CMake config, so open up
for C++14 in IWYU by specifying it explicitly.
Fixes#867 and #880.
LLVM_INSTALL_PREFIX is only set for the packaged LLVM.
When there's a local build dir, LLVM_LIBRARY_DIR points to the same
place (give or take some library suffix stuff that I will ignore for
now).
Using the latter makes the synthetic 'clang-headers' cmake target work
when the prefix path points to a local LLVM build tree.
It is not atypical for a user's CMake prefix path to include multiple
paths. (This is the case when installing a package with Spack, for
example.) Instead of using CMAKE_PREFIX_PATH, use the LLVM prefix path
defined by `find_package(LLVM)`.
The manual page is compiled from the builtin help and the extensive
documentation, condensed down to the essence. We leave details and
elaborated examples to the Markdown documentation.
This is just a way to get canonical directories for different types of
files, which where already used implicitly.
There should be no functional change.
The Clang packaging does not expose a CMake target for
clang-resource-headers.
But with some inside info on package structure, it's relatively
straightforward to create our own, which copies all builtin headers from
the package prefix into the build directory.
This makes it possible for IWYU to assume the resource headers are
always available in the build tree after build, which makes testing
more deterministic.
Clang itself no longer appears to use this solution folder, so there's
no need for IWYU to follow suit.
Gets rid of another "folder", but in this case it was actually the
correct terminology according to Visual Studio.
No functional change, but generated Visual Studio solutions will be
organized differently.
This is necessary to fix the below linker error on Linux with clang 8.
/usr/bin/ld: CMakeFiles/include-what-you-use.dir/iwyu_driver.cc.o:
undefined reference to symbol '_ZN5clang22PCHContainerOperationsC1Ev'
This ensures the builtin headers are copied to the build directory
before include-what-you-use is built.
The clang-headers target is not exposed in packaged LLVM, so this is
only relevant for in-tree builds. In out-of-tree builds, we can rely on
the builtin headers to be installed on the system.
When built against trunk LLVM with SHARED_LIBS enabled, LLMVOption is
missing from the libraries. Instead of hardcoding LLVM libnames, use the
appropriate macro to resolve libraries from components.
Since r337336 LLVM exports its LLVM_LINK_LLVM_DYLIB option, which means
that the add_llvm_executable() macro will automatically pick correctly
between the components set by LLVM_LINK_COMPONENTS and the singleton LLVM shared
library. Thus we can simplify linking a lot.
Now that we require CMake 3.4.3, we no longer need to check if CMP0048
is available before setting it to NEW.
Also move the policy setting and project declaration so we only create a
project for out-of-tree builds. In-tree builds will become part of the
LLVM project, which already has this policy set.
This is a breaking change.
Now that Debian packaging has been fixed, configuring IWYU should be as
easy as:
$ cmake -DCMAKE_PREFIX_PATH=/usr/lib/llvm-7 ../include-what-you-use
to link with published LLVM/Clang libraries and:
$ cmake -DCMAKE_PREFIX_PATH=/llvm-trunk/build ../include-what-you-use
to link with locally built libraries.
IWYU now prefers dynamic linking of LLVM if available, to avoid
accidentally linking LLVM both statically and dynamically.
Out-of-tree is now the only supported configuration, but we keep in-tree
around for convenience.
LLVM introduced PRIVATE scope for target_link_libraries for executables
in r319840. Since executables don't export link dependencies, this makes
sense.
CMake does not allow mixing target_link_libraries invocations
with/without scope specifiers, so add PRIVATE in IWYU's CMakeLists.txt
The out-of-tree build on my FreeBSD 11 machine failed with an unresolved
symbol for `backtrace`.
Use CMake's find provider for backtrace to satisfy the dependency.
We don't build with MSVC out-of-tree regularly, so a number of
compatibility issues with LLVM had snuck in:
- Suppressed warnings in header LLVM files
- Extended object format support (/bigobj)
- Use of noexcept requires sane C++ exception semantics (/EHSc)
- Clang's MSVCToolChain.cpp now uses functions from version.dll, so add it
to linker deps
While dabbling with this, we also found it was necessary to CMake with
-DCMAKE_BUILD_TYPE=Release to match LLVM's release-built libraries.
Mention this in the user docs.
Kim Gräsman