This was intended to be a generic CMake solution to a problem
shared across several projects. It turns out it doesn't interact
very well certain CMake configurations, and furthermore the
"problem" is actually not a problem, as the problematic code
is never executed to begin with. So this really isn't solving
anything.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313191 91177308-0d34-0410-b5e6-96231b3b80d8
Some projects need to add conditional dependencies on other projects.
compiler-rt is already doing this, and I attempted to add this to
debuginfo-tests when I ran into the ordering problem, that you can't
conditionally add a dependency unless that dependency's CMakeLists.txt
has already been run (which would allow you to say if (TARGET foo).
The solution to this seems to be to determine very early on the entire
set of projects which is enabled. This is complicated by the fact that
there are multiple ways to enable projects, and different tree layouts
(e.g. mono-repo, out of -tree, external, etc). This patch attempts to
centralize all of this into one place, and then updates compiler-rt to
demonstrate as a proof of concept how this can simplify code.
Differential Revision: https://reviews.llvm.org/D37637
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313091 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
When repo is used with git, 'clang --version' option does not display
the correct revision information (i.e. git hash on TOP) as the following:
clang version 6.0.0 --->
clang version 6.0.0 (clang version) (llvm version)
This is because repo also creates .git/svn folder as git-svn does and
this makes repo with git uses "git svn info" command, which is only for
git-svn, to retrieve its revision information, making null for the info.
To correctly distinguish between git-svn and repo with git, the folder
hierarchy to specify for git-svn should be .git/svn/refs as the "git svn
info" command depends on the revision data in .git/svn/refs. This patch
in turn makes repo with git passes through to the third macro,
get_source_info_git, in get_source_info function, resulting in correctly
retrieving the revision information for repo with git using "git log ..."
command.
This patch is tested with git, svn, git-svn, and repo with git.
Reviewers: llvm-commits, probinson, rnk
Reviewed By: rnk
Subscribers: rnk, mehdi_amini, beanz, mgorny
Differential Revision: https://reviews.llvm.org/D35532
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@312864 91177308-0d34-0410-b5e6-96231b3b80d8
FuzzMutate might not be the best place for these, but it makes more
sense than an entirely new library for now. This will make setting up
fuzz targets with consistent CLI handling easier.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@312425 91177308-0d34-0410-b5e6-96231b3b80d8
This is needed for building LLVM on Android with new NDK (newer
than r15c) and API level < 24. Android C library (Bionic) didn't have
support for 64 bit file position until Android N.
Differential Revision: https://reviews.llvm.org/D37314
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@312389 91177308-0d34-0410-b5e6-96231b3b80d8
This adds a dummy main so we can build and run the llvm-isel-fuzzer
functionality when we aren't building LLVM with coverage. The approach
here should serve as a template to stop in-tree fuzzers from
bitrotting (See llvm.org/pr34314).
Note that I'll probably move most of the logic in DummyISelFuzzer's
`main` to a library so it's easy to reuse it in other fuzz targets,
but I'm planning on doing that in a follow up that also consolidates
argument handling in our LLVMFuzzerInitialize implementations.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@312338 91177308-0d34-0410-b5e6-96231b3b80d8
The buildbots have shown that -Wstrict-prototypes behaves differently in GCC
and Clang so we should keep it disabled until Clang follows GCC's behaviour
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@312246 91177308-0d34-0410-b5e6-96231b3b80d8
This moves the cmake configuration for fuzzers in LLVM to a new macro,
add_llvm_fuzzer. This will make it easier to keep things consistent
while implementing llvm.org/pr34314.
I've also made a couple of minor functional changes here:
- the fuzzers now use add_llvm_executable rather than add_llvm_tool.
This means they won't create install targets and stuff like that,
because those made little sense for these fuzzers.
- I've grouped these under "Fuzzers" rather than in with "Tools" for
people who build with IDEs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@312200 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Plugins can (and should) be enabled under mingw if we are building
libLLVM.dll, so this is just a missed case. This allows LLVMgold.dll to
be built now under mingw.
Reviewers: llvm-commits, pirama, beanz, chapuni
Reviewed By: chapuni
Subscribers: chapuni, mgorny
Differential Revision: https://reviews.llvm.org/D37116
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@311973 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes an issue with the use of LLVM_PARALLEL_LINK_JOBS.
Original commit message:
macOS 10.13 added a new API (futimens). This API is only available on macOS 10.13
and later, but the cmake check we have in place only tests if the symbol is
present and ignores the availability attribute. Luckily we have new warning for
this and by making this warning an error the cmake check will return the correct
result.
See also rdar://problem/33992750.
Differential Revision: https://reviews.llvm.org/D37027
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@311965 91177308-0d34-0410-b5e6-96231b3b80d8
macOS 10.13 added a new API (futimens). This API is only available on macOS 10.13
and later, but the cmake check we have in place only tests if the symbol is
present and ignores the availability attribute. Luckily we have new warning for
this and by making this warning an error the cmake check will return the correct
result.
See also rdar://problem/33992750.
Differential Revision: https://reviews.llvm.org/D37027
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@311949 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The `LLVM${c}Info` mask is listed twice in LLVM-Config.cmake. This results in the libraries such as LLVMARMInfo, LLVMAArch4Info, etc appearing twice in `extract_symbols.py` command line while building `clangShared`. `Extract_symbols.py` does not work well in such a case and completely ignores the symbols from the duplicated libraries. Thus, the LLVM(...)Info symbols do not get exported from `clangShared` and linking clang against it fails with unresolved dependencies.
Seems to be a mere copy-paste mistake.
Reviewers: beanz, chapuni
Reviewed By: chapuni
Subscribers: chapuni, aemerson, mgorny, kristof.beyls, llvm-commits, asl
Differential Revision: https://reviews.llvm.org/D36119
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@310590 91177308-0d34-0410-b5e6-96231b3b80d8
Detect [/-][DU]NDEBUG in CMAKE_C_FLAGS* and pass them through to ocamlc.
This is necessary because their value might affect visibility of dump
functions in LLVM and ocamlc uses its own compiler and flags by default.
Differential Revision: https://reviews.llvm.org/D35898
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@309483 91177308-0d34-0410-b5e6-96231b3b80d8
Install the OCaml dynamic libraries in the 'stubdirs' directory rather
than the llvm subdirectory in order to fix running executables created
by ocamlc. Otherwise, the executables fail to run being unable to locate
the libraries (unless the LLVM directory is explicitly added to
LD_LIBRARY_PATH).
The staging directories are not altered since they work for our
development setup anyway, and installing into two directories would
unnecessarily make the code more complex.
Differential Revision: https://reviews.llvm.org/D35995
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@309481 91177308-0d34-0410-b5e6-96231b3b80d8
By creating a dummy of this target in LLVMConfig.cmake, projects that can build against out-of-tree LLVM can freely depend on the target without needing to have conditionals for if LLVM is in-tree or out-of-tree.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@309389 91177308-0d34-0410-b5e6-96231b3b80d8
Pass the values of CMAKE_C_FLAGS and CMAKE_C_FLAGS_${CMAKE_BUILD_TYPE}
as -ccopt to ocamlc. This enforces the specific flags used for the LLVM
build to be used for OCaml bindings as well, notably -O and -march
flags.
This also solves the issue of the user being unable to force specific
flags for OCaml bindings builds. Gentoo needs this to enforce -DNDEBUG
consistently between the LLVM build and the split OCaml bindings build.
Differential Revision: https://reviews.llvm.org/D35898
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@309320 91177308-0d34-0410-b5e6-96231b3b80d8
libxml2 is supported for 32 bit, so our build system should be checking
the target rather than native os when choosing shared libs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@309242 91177308-0d34-0410-b5e6-96231b3b80d8
Reapply "Set a different var for checking I686, because LLVM_NATIVE_ARCH is"
This reverts commit e7400d7cbc2b7539de3aa7a20adc8f4ee0cb7bef.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@309181 91177308-0d34-0410-b5e6-96231b3b80d8
compile_commands.json file is very useful both for tooling and for
reproducible builds.
For files generated from recursive CMake invocation this information was
not previously generated.
Differential Review: https://reviews.llvm.org/D35219
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@308698 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
GetSVN.cmake currently takes one or two pairs of <source directory path,
name>, then attempts to get the remote repository URL and source control
revision of the repositories at those one or two paths.
It takes two pairs in order for Clang to get the revision of both
itself, and its dependency LLVM.
For projects that rely upon both LLVM and Clang (Apple's Swift is one
example, but there are others), GetSVN.cmake is used to fetch *three*
revisions: Swift, Clang, and LLVM.
To support this use case, change GetSVN.cmake: instead of taking one or
two pairs (specified via `FIRST_SOURCE_DIR`/`FIRST_NAME`, have it take a list
of pairs (`SOURCE_DIRS`/`NAMES`).
In order to allow Clang to migrate, have GetSVN.cmake support both sets
of arguments for now. The old arguments can be removed once Clang begins
using the new arguments, and Swift can follow when it updates its
copy of LLVM.
Test Plan:
1. Perform a clean build of Clang, verify that `clang --version` still
prints the correct LLVM and Clang revision information.
2. Modify Clang's CMake to use the new arguments, then perform another
clean build. `clang --version` should still print the correct
revision information.
Reviewers: jordan_rose, beanz, probinson
Subscribers: echristo, chapuni, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D35132
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@308507 91177308-0d34-0410-b5e6-96231b3b80d8
Solaris ld is not the only linker available on Solaris.
Introducing linker detection and using LLVM_LINKER_IS_SOLARISLD to
select Solaris-ld specific handling.
Patch by: Fedor Sergeev
Differential Revision: https://reviews.llvm.org/D35325
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307852 91177308-0d34-0410-b5e6-96231b3b80d8
This changes adds support for building runtimes for multiple
different targets using LLVM runtimes directory.
The implementation follow the model used already by the builtins
build which already supports this option. To specify the runtimes
targets to be built, use the LLVM_RUNTIME_TARGETS variable, where
the valuae is the list of targets to build runtimes for. To pass
a per target variable to the runtimes build, you can set
RUNTIMES_<target>_<variable> where <variable> will be passed to the
runtimes build for <target>.
Each runtime target (except for the default one) will be installed
into lib/<target> subdirectory. Build targets will be suffixed with
the target name.
Differential Revision: https://reviews.llvm.org/D32816
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307731 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This is like the LLVM_TOOLS_INSTALL_DIR option, but for the utils
that are installed when the LLVM_INSTALL_UTILS. This option
defaults to 'bin' to remain consistent with the current behavior, but
distros may want to install these to libexec/llvm.
Reviewers: beanz
Reviewed By: beanz
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D30655
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307150 91177308-0d34-0410-b5e6-96231b3b80d8
CMake emits build targets as relative paths (from build.ninja) but Ninja doesn't identify absolute path (in *.d) as relative path (in build.ninja).
So, let file names, in the command line, relative from ${CMAKE_BINARY_DIR}, where build.ninja is.
Note that tblgen is executed on ${CMAKE_BINARY_DIR} as working directory.
Differential Revision: https://reviews.llvm.org/D33707
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@305961 91177308-0d34-0410-b5e6-96231b3b80d8
This commit causes LLVM_USE_SANITIZER to now accept the "Leaks" option. This
will cause cmake to pass in -fsanitize=leak in all of the appropriate places.
I am making this change so that I can setup a linux bot that only detects
leaks.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@305839 91177308-0d34-0410-b5e6-96231b3b80d8
No behavior is changed if LLVM_TARGET_TRIPLE_ENV is blank or undefined.
If LLVM_TARGET_TRIPLE_ENV is "TEST_TARGET_TRIPLE" and $TEST_TARGET_TRIPLE is not blank,
llvm::sys::getDefaultTargetTriple() returns $TEST_TARGET_TRIPLE.
Lit resets config.target_triple and config.environment[LLVM_TARGET_TRIPLE_ENV] to change the default target.
Without changing LLVM_DEFAULT_TARGET_TRIPLE nor rebuilding, lit can be run;
TEST_TARGET_TRIPLE=i686-pc-win32 bin/llvm-lit -sv path/to/test/
TEST_TARGET_TRIPLE=i686-pc-win32 ninja check-clang-tools
Differential Revision: https://reviews.llvm.org/D33662
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@305632 91177308-0d34-0410-b5e6-96231b3b80d8
LLVM_TABLEGEN_TARGET is undefined in clang standalone build.
STREQUAL cannot omit LHS. Then I saw an error;
CMake Error at /path/to/install/llvm/lib/cmake/llvm/TableGen.cmake:40 (if):
if given arguments:
"STREQUAL" "/path/to/install/llvm/bin/llvm-tblgen.exe"
Unknown arguments specified
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@305159 91177308-0d34-0410-b5e6-96231b3b80d8
For the case when LLVM_OPTIMIZED_TABLEGEN is ON (enables LLVM_USE_HOST_TOOLS),
we need both _TABLEGEN_TARGET and _TABLEGEN_EXE in the DEPENDS list
to have .inc files rebuilt on a tablegen change, as cmake does not propagate
file-level dependencies of custom targets.
We could always have just one dependency on both the target and
the file, but the 2 cases would produce cleaner cmake files.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@305142 91177308-0d34-0410-b5e6-96231b3b80d8
