macOS paths usually start with /Users, which clang-cl interprets as a
macro undefine, leading to pretty much everything failing to compile.
CMake should be taught to put a -- in its compilation rules for clang-cl
(and I've been meaning to submit that upstream for a while). In the
meantime, however, and to support older CMake versions, we can just
create a custom make rules override to fix the compilation rules.
Differential Revision: https://reviews.llvm.org/D41219
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320785 91177308-0d34-0410-b5e6-96231b3b80d8
Newer versions of CMake (I'm on 3.10, but I believe 3.9 behaves the same
way) attempt to query the system for information about the VS 2017
install. Unfortunately, this query fails on non-Windows systems:
cmake_host_system_information does not recognize <key> VS_15_DIR
CMake isn't going to find these system libraries on non-Windows anyway
(and we were previously silencing the resultant warnings in our
cross-compilation toolchain), so it makes sense to just omit the
attempted installation entirely on non-Windows.
Differential Revision: https://reviews.llvm.org/D41220
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320724 91177308-0d34-0410-b5e6-96231b3b80d8
When the Windows SDK is hosted on a case-sensitive filesystem (e.g. when
compiling on Linux and not using ciopfs), we can automatically generate
a VFS overlay for headers and symlinks for libraries.
Differential Revision: https://reviews.llvm.org/D41156
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320657 91177308-0d34-0410-b5e6-96231b3b80d8
When cross-compiling using clang-cl 5.0 (which is currently the latest
stable release of the compiler), the default MS compatibility level is
set to VS 2013, which is too low to build LLVM. Explicitly set the
compatibility level to VS 2017 to support cross-compiling LLVM for
Windows using clang-cl 5.0. This will be a no-op when using clang-cl 6.0
and above, where the default MS compatibility level is already VS 2017.
Differential Revision: https://reviews.llvm.org/D41157
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320616 91177308-0d34-0410-b5e6-96231b3b80d8
This is useful for some edge cases where detecting things gets tricky. Specifically LLDB needs this to support iOS because CMake doesn't support running tests using obj-c code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@295392 91177308-0d34-0410-b5e6-96231b3b80d8
- Remove a comment that was clearly copy pasted from Android.cmake and
isn't relevant.
- Remove the toolchain's sensitivity to the environment. It's less
error prone to just allow users to set CMAKE_OSX_SYSROOT if they
want to use a custom SDK.
- Stop explicitly setting -mios-version-min to the default value. It
just adds needless complexity.
This makes building the native tablegen work for me even when SDKROOT
is set in the environment (or passed in as -DCMAKE_OSX_SYSROOT).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@260763 91177308-0d34-0410-b5e6-96231b3b80d8
* There is no reason to require SDKROOT as an environment variable because we can derive it from xcrun
* Setting CMAKE_RANLIB makes our static archives usable
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232053 91177308-0d34-0410-b5e6-96231b3b80d8
The basic idea is similar to the existing cross compilation support. A directory must be configured to build host versions of tablegen tools and llvm-config. This directory can be user provided (and configured), or it can be created during the build. During a build the native build directory will be configured and built to supply the tablegen tools used during the build. A user could also explicitly provide the tablegen executables to run on the CMake command line.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217105 91177308-0d34-0410-b5e6-96231b3b80d8
