Since commit 1c2d031cbd (Add -E cmake_llvm_rc to preprocess files for
llvm-rc, 2020-01-14, v3.17.0-rc1~24^2) with llvm-rc we explicitly
preprocess RC source files and then compile separately without -I flags.
This broke cases where the RC source references data files adjacent to
itself or in the include path.
This change adds the expansion of the include paths when calling the
llvm-rc in order for the resource files to be picked up correctly by
llvm-rc. Since the RC compiled file is first preprocessed, the file
being compiled by llvm-rc resides in the build directory. In order for
llvm-rc to find the resource data specified relative to the .rc file
being compiled, the source file path is preppended in the include list
so that the original source path takes priority over all the other
includes paths specified.
A space was added in the CMAKE_INCLUDE_FLAG_RC to make the include
directive work properly for llvm-rc. Checks on the rc.exe showed that
the syntax change doesn't affect it's proper operation.
Fixes: #20529
If java_class_filelist exists, remove previous class files before building the
new ones. If java_sources content has changed, clean and rebuild the class
files of the target.
Fixes: #20377
46d9006efa XL: Add comment clarifying why we pretend it has full C++11/14 support
4aaa9ea96c XL: C++14 language level flags are only available on Linux
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4551
Since commit b0f46c48f6 (CompileFeatures: Now able to presume full
language level support, 2019-03-06, v3.15.0-rc1~265^2~1) we pretend that
the XL compiler has full C++11 and C++14 support so that projects
specifying granular features will at least get the corresponding
compiler mode. This is a work around for our lack of a full feature
check table for this compiler that works in common cases. Add a comment
explaining this.
Issue: #20521
Since commit 458ea9d76c (XL: Add C++14 language level flags, 2019-04-15,
v3.15.0-rc1~226^2) we use `-qlanglvl=extended1y` for C++14 with XL 16.1.
However, that flag is only supported on a Linux host.
Issue: #20521
On platforms where our default Boost static library prefix is incorrect,
make it possible for users to set it explicitly to work around the problem
until FindBoost can be updated.
Fixes: #20372
2c724c3aea llvm-rc: Write depfile to location specified by the generator
4cc876540e llvm-rc: Select preprocessor from active languages
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4524
2c724c3aea llvm-rc: Write depfile to location specified by the generator
4cc876540e llvm-rc: Select preprocessor from active languages
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4524
Prior to commit 3c125c6de0 (VS: Support Visual Studio Clang Toolkit
identification, 2019-12-03, v3.17.0-rc1~341^2) using `-T ClangCL`
would work but `CMAKE_{C,CXX}_COMPILER` would be detected as `cl.exe`
even though `clang-cl.exe` is the actual compiler. That commit
attempted to fix the detection by using `$(ClangClExecutable)`
as we do for LLVM-distributed toolsets, but that is not actually
defined. Instead, look for `$(CLToolExe)` in the `PATH`.
Fixes: #20504
Move the depfile flags to `CMAKE_DEPFILE_FLAGS_RC` so that they
are only usedwith generators that use depfiles. Also switch to
using the `<DEPFILE>` placeholder for the location of the depfile
so that it goes where the generator expects.
Fixes: #20493
The llvm-rc preprocessor is selected according to the
CMAKE_C_COMPILER_ID / CMAKE_CXX_COMPILER_ID which are only defined when
the C or CXX language is active.
905d5667e8 FindRuby: Add support for RVM installations
e6699b9b59 FindRuby: Validate Ruby_EXECUTABLE before accepting it
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4386
