Summary:
Specify message levels in CMake. Prefer STATUS (stdout).
As the default message mode (i.e. level) is NOTICE in CMake, more then necessary messages get printed to stderr. Some tools, noticably ccmake treat this as an error and require additional confirmation and re-running CMake's configuration step.
This commit specifies a mode (either STATUS or WARNING or FATAL_ERROR) instead of the default.
* I used `csearch -f 'llvm-project/.+(CMakeLists\.txt|cmake)' -l 'message\("'` to find all locations.
* Reviewers were chosen by the most common authors of specific files. If there are more suitable reviewers for these CMake changes, please let me know.
Patch by: Christoph Siedentop
Reviewers: zturner, beanz, xiaobai, kbobyrev, lebedev.ri, sgraenitz
Reviewed By: sgraenitz
Subscribers: mgorny, lebedev.ri, #sanitizers, lldb-commits, llvm-commits
Tags: #sanitizers, #lldb, #llvm
Differential Revision: https://reviews.llvm.org/D63370
llvm-svn: 363821
When cross-compiling for Windows on Unix, the built toolchain will need
to be transferred to Windows to actually run. My opinion is that the
Unix build should use symlinks, and the transfer to Windows should take
care of making those symlinks usable. E.g., I envision tarballs to be a
common form of transfer from Unix to Windows, in which case the tarball
can be created using --dereference to follow the symlinks.
The motivation here is that, when cross-compiling for Windows on Unix,
the installation will *already* create symlinks. The reason is that the
installation script will be invoked without knowing the host system, so
the `if(UNIX)` check in the installation symlink creation script will
reflect the build system rather than the host system. We could either
make the build and install trees both contain copies or both contain
symlinks, and using symlinks is a significant space saving without (in
my opinion) having any detrimental effect on the usage of the cross-
compiled toolchain on Windows.
A secondary motivation is that Windows 10 version 1703 and later finally
lift the administrator rights requirement for creating symbolic links
(if the system is in Developer Mode), which makes symlinks a lot more
practical even on Windows. Of course Unix and Windows symlinks aren't
interoperable, but symlinks for Windows toolchains is a reasonable
future direction to be going in anyway.
Differential Revision: https://reviews.llvm.org/D41314
llvm-svn: 322061
In order to resolve PR25059, we're going to need to be able to generate symlinks to libraries manually, so I need this code to be reusable.
llvm-svn: 250573
In order to support building clang out-of-tree the install_symlink script needs to be installed, and it needs to be found by searching the CMAKE_MODULE_PATH.
This change renames install_symlink -> LLVMInstallSymlink so it doesn't conflict with naming from other projects, and adds searching behavior in AddLLVM.cmake
llvm-svn: 248009
Kirill Bobyrev