* Create an install target for it
* Add it under tools/opt-remarks
* Add an export file for the dylib
* Install the llvm-c/OptRemarks.h header
* Add an API to query its version
rdar://45458839
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@346127 91177308-0d34-0410-b5e6-96231b3b80d8
There are several places where we use CMAKE_CONFIGURATION_TYPES to determine if we are using an IDE generator and in turn decide not to generate some of the convenience targets (like all the install-* and check-llvm-* targets). This decision is made because IDEs don't always deal well with the thousands of targets LLVM can generate.
This approach does not work for Visual Studio 15's new CMake integration. Because VS15 uses a Ninja generator, it isn't a multi-configuration build, and generating all these extra targets mucks up the UI and adds little value.
With this change we still don't generate these targets by default for Visual Studio and Xcode generators, and LLVM_ENABLE_IDE becomes a switch that can be enabled on the VS15 CMake builds, to improve the IDE experience.
This is a re-land of r340435, with a few minor fix-ups. The issues causing the revert were addressed in r344218, r344219, and r344553.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@344555 91177308-0d34-0410-b5e6-96231b3b80d8
There really aren't any generator behaviors that we need to take `CMAKE_EXTRA_GENERATOR` into account for. Where we need to take different behaviors for IDEs is mostly in enabling or disabling certain build system features that are optional but trip up the IDE UIs. Like the generation of lots of utility targets.
By changing the LLVM_ENABLE_IDE default to only being on for multi-configuration generators, we allow gating where it will impact the UI presentation, while also supporting optionally disabling the generation if your tooling workflow encounters problems. Presently being able to manually disable extra target generation is useful for Visual Studio 2017's CMake integration where the IDE has trouble displaying and working with the large number of optional targets.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@344553 91177308-0d34-0410-b5e6-96231b3b80d8
All uses of this option have been removed, and the intent is to change the purpose and default value of this option. To prevent it from having impacts on users, this patch temporarily removes the option and purges it from CMake caches. In a few days, once this has propagated to contributors I will re-introduce the option with the new default value.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@344219 91177308-0d34-0410-b5e6-96231b3b80d8
Previously adding header and table gen files was conditional on using an IDE. Since these files have the `HEADER_FILE_ONLY` attribute applied they are ignored as sources by all non-IDE generators, so there is really no reason not to include them.
Additionally having the CMake always include these files allows the CMake-server to include them in the sources list for targets, which is valuable to anyone using CMake-server integrated tools.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@344218 91177308-0d34-0410-b5e6-96231b3b80d8
Some projects rely on using libraries from the Windows SDK with their
original casing, just with a lowercase extension. E.g. the WinSock2 lib
is named WS2_32.Lib in the Windows SDK, and we would previously only
create a ws2_32.lib symlink for it (i.e. all lowercase). Also create a
WS2_32.lib symlink (i.e. original casing with lowercase extension) to
cover users of this casing. As a drive-by fix, only create these
symlinks when they differ from the original name to reduce the amount of
noise in the library symlinks directory.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@343832 91177308-0d34-0410-b5e6-96231b3b80d8
If required_libs happens to remain unset, CMake would fail with:
list sub-command REVERSE requires list to be present.
Fix by ensuring we do not attempt to reverse an unset variable.
Reported by Tu Vuong.
Differential Revision: https://reviews.llvm.org/D51799
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@343088 91177308-0d34-0410-b5e6-96231b3b80d8
We can't put the unittest source dir map in the configuration
specific directory because VS doesn't have a configure-specific
directory, instead it only knows this at runtime. So we have
to remove this from the path. This in turn means that the path
will be slightly different in VS configurations vs non vs
configurations. In the former, the source map will be in the
parent directory of the executable, and in the latter it will
be in the same directory as the executable. So check both.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@341590 91177308-0d34-0410-b5e6-96231b3b80d8
Occasionally it is useful to have unittest which take inputs.
While we normally try to have this test be more of a lit test
we occasionally don't have tools that can exercise the code
in the right way to test certain things. LLDB has been using
this style of unit test for a while, particularly with regards
to how it tests core dump and minidump file parsing. Recently
i needed this as well for the case where we want to test that
some of the PDB reading code works correctly. It needs to
exercise the code in a way that is not covered by any dumper
and would be impractical to implement in one of the dumpers,
but requires a valid PDB file. Since this is now needed by
more than one project, it makes sense to have this be a
generally supported thing that unit tests can do, and we just
encourage people to use this sparingly.
Differential Revision: https://reviews.llvm.org/D51561
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@341502 91177308-0d34-0410-b5e6-96231b3b80d8
That resulted in the check-llvm-* targets not being avaliable
in the QtCreator-configured build directories.
Moreover, that was a clearly non-NFC change, and i can't find any review
for it.
This reverts commit rL340435.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@341045 91177308-0d34-0410-b5e6-96231b3b80d8
This patch pulls google/benchmark v1.4.1 into the LLVM tree so that any
project could use it for benchmark generation. A dummy benchmark is
added to `llvm/benchmarks/DummyYAML.cpp` to validate the correctness of
the build process.
The current version does not utilize LLVM LNT and LLVM CMake
infrastructure, but that might be sufficient for most users. Two
introduced CMake variables:
* `LLVM_INCLUDE_BENCHMARKS` (`ON` by default) generates benchmark
targets
* `LLVM_BUILD_BENCHMARKS` (`OFF` by default) adds generated
benchmark targets to the list of default LLVM targets (i.e. if `ON`
benchmarks will be built upon standard build invocation, e.g. `ninja` or
`make` with no specific targets)
List of modifications:
* `BENCHMARK_ENABLE_TESTING` is disabled
* `BENCHMARK_ENABLE_EXCEPTIONS` is disabled
* `BENCHMARK_ENABLE_INSTALL` is disabled
* `BENCHMARK_ENABLE_GTEST_TESTS` is disabled
* `BENCHMARK_DOWNLOAD_DEPENDENCIES` is disabled
Original discussion can be found here:
http://lists.llvm.org/pipermail/llvm-dev/2018-August/125023.html
Reviewed by: dberris, lebedev.ri
Subscribers: ilya-biryukov, ioeric, EricWF, lebedev.ri, srhines,
dschuff, mgorny, krytarowski, fedor.sergeev, mgrang, jfb, llvm-commits
Differential Revision: https://reviews.llvm.org/D50894
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@340809 91177308-0d34-0410-b5e6-96231b3b80d8
There are several places where we use CMAKE_CONFIGURATION_TYPES to determine if we are using an IDE generator and in turn decide not to generate some of the convenience targets (like all the install-* and check-llvm-* targets). This decision is made because IDEs don't always deal well with the thousands of targets LLVM can generate.
This approach does not work for Visual Studio 15's new CMake integration. Because VS15 uses a Ninja generator, it isn't a multi-configuration build, and generating all these extra targets mucks up the UI and adds little value.
With this change we still don't generate these targets by default for Visual Studio and Xcode generators, and LLVM_ENABLE_IDE becomes a switch that can be enabled on the VS15 CMake builds, to improve the IDE experience.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@340435 91177308-0d34-0410-b5e6-96231b3b80d8
Changes the default Windows target triple returned by
GetHostTriple.cmake from the old environment names (which we wanted to
move away from) to newer, normalized ones. This also requires updating
all tests to use the new systems names in constraints.
Differential Revision: https://reviews.llvm.org/D47381
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@339307 91177308-0d34-0410-b5e6-96231b3b80d8
Append LLVM_VERSION_SUFFIX to SOVERSION. This makes it possible
to use the suffix to differentiate binary-incompatible versions
of LLVM built via BUILD_SHARED_LIBS.
We are planning to use this to temporarily preserve ABI-incompatible
variants of LLVM while switching the system between them, e.g. when
rebuilding the system to use libc++. Normally this would mean that once
LLVM is rebuilt using libc++ all the reverse dependencies become
immediately broken. Using a distinct SOVERSION allows us to preserve
the ABI compatibility before all the packages are rebuilt.
Differential Revision: https://reviews.llvm.org/D39939
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@339286 91177308-0d34-0410-b5e6-96231b3b80d8
Store LLVM_VERSION_SUFFIX along with other version components
in LLVMConfig.cmake. This fixes preserving the suffix set while building
LLVM to stand-alone builds of other components, e.g. clang,
and therefore improves uniformity between the two build models.
Given that there is no apparent reason to omit this part of version,
that it is distributed to subprojects when building as part of LLVM
and that it is included in LLVM_PACKAGE_VERSION, I think it was omitted
accidentally rather than done on purpose.
Differential Revision: https://reviews.llvm.org/D43701
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@339285 91177308-0d34-0410-b5e6-96231b3b80d8
This means it will be installed also in builds configured with
LLVM_INSTALL_TOOLCHAIN_ONLY, such as the Windows packages.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338495 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
As it was, always exporting LLVM_LINK_LLVM_DYLIB caused out-of-tree
clients to lose the ability to link against the dylib, even if in-tree tools did
not. By only exporting the setting if it is enabled, out-of-tree clients get the
correct default, but may still choose if they can.
Reviewers: mgorny, beanz, labath, bogner, chandlerc
Reviewed By: bogner, chandlerc
Subscribers: bollu, llvm-commits
Differential Revision: https://reviews.llvm.org/D49843
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338119 91177308-0d34-0410-b5e6-96231b3b80d8
It looks like currently the UBSan blacklist is only applied when "Undefined" is selected.
This patch updates the cmake file to apply it whenever Undefined is selected
(e.g. 'Address; Undefined' ). This allows us to use the workaround added in
rL335525 when using AddressSan and UBSan together.
Reviewers: eugenis, vitalybuka
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D49558
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337539 91177308-0d34-0410-b5e6-96231b3b80d8
It fires on things like SmallVector<std::pair<int, int>>, where we
intentionally use memcpy instead of calling the assignment operator.
This warning fires in practically every LLVM TU, so we have to do
something about it, even if we aren't interested in being 100% warning
clean with GCC.
Reported as PR37337
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337492 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
When building out-of-tree tools, there are several macros available to
automate linking against llvm. An examples is `add_llvm_executable`, or
the clang variant of this.
These macros use the LLVM_LINK_LLVM_DYLIB option to decide whether to
link against libraries defined by setting LLVM_LINK_COMPONENTS or to
link against libLLVM instead. Currently this is problematic in
out-of-tree targets, because they cannot identify whether this option is
required or even available. If the option was enabled in LLVM's own
build, the clang libraries are built against libLLVM, so a client
linking against those must link against it too. On the other hand the
client can't just always link against it, because it might not be
available.
This is related to D44391, but that change assumed the client knew
whether they wanted the dylib or not.
Reviewers: mgorny, beanz, labath
Reviewed By: mgorny
Subscribers: bollu, llvm-commits
Differential Revision: https://reviews.llvm.org/D49193
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337366 91177308-0d34-0410-b5e6-96231b3b80d8
Automatically codesign all executables and dynamic libraries if a
codesigning identity is given (via LLVM_CODESIGNING_IDENTITY). This
option is darwin only for now.
Also update platforms/iOS.cmake to pick up the right versions of
codesign and codesign_allocate.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@336708 91177308-0d34-0410-b5e6-96231b3b80d8
The test is about what can be run on the host, not the cmake target.
When cross-compiling (compiler-rt at least) on Windows, we end up with
lit being unable to run llvm-lit because it can't find the llvm-lit
module.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@335961 91177308-0d34-0410-b5e6-96231b3b80d8
This allows overriding the strip and dsymutil tools, and updates
iOS.cmake to do so. I've also added libtool to iOS.cmake, but it was
already respecting CMAKE_LIBTOOL if set.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@335900 91177308-0d34-0410-b5e6-96231b3b80d8
LLVM currently assumes that Apple platforms will always use ld64. In the
future, LLD Mach-O might also be supported, so add the beginnings of
linker detection support. ld64 is currently the only detected linker,
since `ld64.lld -v` doesn't yield any useful version output, but we can
add that detection later, and in the meantime it's still useful to have
the ld64 identification.
Switch clang's order file check to use this new detection rather than
just checking for the presence of an ld64 executable.
Differential Revision: https://reviews.llvm.org/D48201
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@334780 91177308-0d34-0410-b5e6-96231b3b80d8
On MacOS, if CMAKE_OSX_SYSROOT is used and the user has command line tools
installed, we currently get the include path for libxml2 as
/usr/include/libxml2, instead of ${CMAKE_OSX_SYSROOT}/usr/include/libxml2.
Make it consistent on MacOS by prefixing ${CMAKE_OSX_SYSROOT} when
possible.
rdar://problem/41103601
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@334746 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The macro parses out the USE_SHARED option out of the argument list, but
then ignores it and accesses the variable with the same name instead. It
seems the intention here was to check the argument value.
Technically, this is NFC, because the only in-tree usage
(add_llvm_executable) of USE_SHARED sets both the variable and the
argument when calling llvm_config, but it makes the usage of this macro
for out-of-tree users more sensible.
Reviewers: mgorny, beanz
Reviewed By: mgorny
Subscribers: foutrelis, llvm-commits
Differential Revision: https://reviews.llvm.org/D44420
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@334082 91177308-0d34-0410-b5e6-96231b3b80d8
The return value of sys::getDefaultTargetTriple, which is derived from
-DLLVM_DEFAULT_TRIPLE, is used to construct tool names, default target,
and in the future also to control the search path directly; as such it
should be used textually, without interpretation by LLVM.
Normalization of this value may lead to unexpected results, for example
if we configure LLVM with -DLLVM_DEFAULT_TARGET_TRIPLE=x86_64-linux-gnu,
normalization will transform that value to x86_64--linux-gnu. Driver will
use that value to search for tools prefixed with x86_64--linux-gnu- which
may be confusing. This is also inconsistent with the behavior of the
--target flag which is taken as-is without any normalization and overrides
the value of LLVM_DEFAULT_TARGET_TRIPLE.
Users of sys::getDefaultTargetTriple already perform their own
normalization as needed, so this change shouldn't impact existing logic.
Differential Revision: https://reviews.llvm.org/D46910
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@332750 91177308-0d34-0410-b5e6-96231b3b80d8
