Due to MCST LCC compiler identification is now changed to LCC,
there should be a way for old projects to still identify it as GNU,
as it was before.
This commits adds the policy:
CMP0129: Compiler id for MCST LCC compilers is now LCC, not GNU.
This policy controls such a behavior.
OLD behaivior is to treat LCC as GNU, NEW is to treat is as LCC.
Divert LCC compiler as a new one, instead of treating it as GNU.
Since old times, Elbrus C/C++/Fortran Compiler (LCC) by MCST has been
passing checks for GNU compilers, so it has been identified as GNU.
Now, with intent of seriously upstreaming its support, it has been
added as a separate LCC compiler, and its version displays not a
supported GCC version, but LCC version itself (e.g. LCC 1.25.19 instead
of GNU 7.3.0).
This commit adds its support for detection, and also converts basically
every check like 'is this compiler GNU?' to 'is this compiler GNU or
LCC?'. The only places where this check is untouched, is where it
regards other platforms where LCC is unavailable (primarily non-Linux),
and where it REALLY differs from GNU compiler.
Note: this transition may break software that are already ported to
Elbrus, but hardly relies that LCC will be detected as GNU; still such
software is not known.
Since commit d44c0db0b2 (clang: setup correct configuration in gnu mode,
2019-02-20, v3.15.0-rc1~41^2~5) we support the GNU-like Clang that
targets the MSVC ABI. However, Clang cannot compile with the MSVC
standard library unless it runs in a mode aware of C++14 (since MSVC
itself does not even have a lower mode). When `CMAKE_CXX_STANDARD` is
set to 98 or 11, use C++14 anyway.
Since Clang's default mode is aware of C++14, another option is to not
add any flags for 98 or 11. However, if a future Clang version ever
defaults to a higher C++ standard, setting the standard to 98 or 11
should at least not use a mode higher than 14.
Also revert test updates from commit 4819ff9647 (Tests: fix failures
with gnu mode clang on windows, 2019-03-21, v3.15.0-rc1~41^2~3) that
were meant to work around the standard selection problem.
Fixes: #19496
Root causes were:
* Using incorrect conditions (assuming MSVC-like command line mode)
* Trying to compile the MSVC STL in C++11 mode, when parts of it require
C++14 or enabling MS extensions in clang.
* Missing flush in a testcase using stdout in a dll and a main part
with static crt
613ac56e50 Add a test to verify meta-feature parity with granular features
b0f46c48f6 CompileFeatures: Now able to presume full language level support
646fb1a646 CompileFeatures: memoize C++ compilers with full language level support
0d641fcfad Tests: Remove outdated portion of CompileFeatures genex test
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !3176
Previously compilers that only supported the meta-level flags
would not have any of the granular features listed. Now we
presume that they have full support and enable all the features.
Update granular feature tests to skip the actual compilation
checks for the presumed features.
When a dependency was already found, find_dependency did not search it
again. While this works in basic case, it does not when there are
components as the check does not take components into account.
Given the fact that there is no documentation about this optimization and
that the correct implementation is not trivial as it would require
changes in find_package to have the list of components already found we
always search dependencies.
Fix#17583.
* Disable the system include unused variable test in ExportImport when
clang is in MSVC compatible mode.
* Disable CxxDialect testcase when clang is in MSVC compatible mode, as
it doesn't support `typeof`.
* Teach Module.WriteCompilerDetectionHeader to treat clang-cl as MSVC.
* Disable the SystemIncludeDirectories testcase within
IncludeDirectories when clang is in MSVC compatible mode.
* Disable the CMakeOnly.CheckCXXCompilerFlag testcase when clang is in
MSVC compatible mode.
* Treat clang-cl as MSVC in LinkOptions.cmake in the try_run and
try_compile testcases.
Run the `clang-format.bash` script to update all our C and C++ code to a
new style defined by `.clang-format`. Use `clang-format` version 6.0.
* If you reached this commit for a line in `git blame`, re-run the blame
operation starting at the parent of this commit to see older history
for the content.
* See the parent commit for instructions to rebase a change across this
style transition commit.
In commit v3.7.0-rc1~158^2 (ExternalData: Tolerate files duplicated
across multiple targets, 2016-07-07) we added a test case for repeating
the same data file reference in three different targets in the same
directory in order to exercise its corresponding fix. However, we
re-used the top-level `Data.dat` file which is already produced by
an unrelated test case. `ninja` diagnoses the duplicate rule.
Update the test to use a dedicated data file name for the three-times
repeated case to avoid this conflict. It still covers the original
purpose of the test.
This allows defining compat versions of some C/C++ features with the name of the
keyword itself, so all code can look as if it was written for the new language
standard.
This was broken in commit 98e6d1e5e4
(Tests/Module/WCDH: make it work with only C features defined) when all C tests
were made accessible even if no C++ features are available, but the header was
only created if C++ features are available. Fix it by creating the header
unconditionally before any checks on the available features.
This allows one to generate a header that will basically always work. In case
an unknown compiler or compiler version is encountered it simply falls back to
the unsupported case.
Add support for projects to have `Data.txt.md5` *and* `Data.txt.sha512`
where the content links hold hashes for the same file. Check all
`ExternalData_URL_TEMPLATES` entries in order for all available hashes.
The data acquisition is considered a failure if none of the available
URL resources has any of the given hashes. This makes it possible to
have multiple data server resources where all servers do not support all
hashing algorithms.
If multiple ExternalData_Target_Add calls generate the same output file
then we need to avoid calling add_custom_command multiple times with
that output. This was already done within a single target by setting a
variable in the local function scope. This will not be visible in other
calls though so we need to use a directory property instead to prevent
adding a custom command multiple times for one output in a directory.
Normally it is not safe to have multiple custom commands that produce
the same output file across multiple independent targets, but since we
use atomic replacement of outputs the resulting races should not be a
problem. For the convenience of projects, tolerate this instead of
diagnosing it. In particular, we previously allowed up to two copies
of the custom command in one directory because CMake has a fallback
from MAIN_DEPENDENCY to an `<output>.rule` file.
While at it, add a note to the documentation that typically only one
external data target should be needed for a project.
Reported-by: David Manthey <david.manthey@kitware.com>
Run the `Utilities/Scripts/clang-format.bash` script to update
all our C++ code to a new style defined by `.clang-format`.
Use `clang-format` version 3.8.
* If you reached this commit for a line in `git blame`, re-run the blame
operation starting at the parent of this commit to see older history
for the content.
* See the parent commit for instructions to rebase a change across this
style transition commit.
Previously we allowed this definition to persist outside our header.
This would cause conflicts across multiple such headers because the name
was always the same. Fix this by avoiding the definition altogether.
There's no need to stringify the values, but instead just pass in
strings. The core problem is that the path may have tokens which are
replaced by the preprocessor which causes an invalid path to be used.
Revert commit v3.4.0-rc1~10^2~2 (Features: Disable support for Oracle
SolarisStudio on non-Linux, 2015-09-29) and two follow-up commits.
The support of compile features and language standards on Orcale
SolarisStudio needs more investigation so for CMake 3.4 we should
just act as 3.3 did.
We do support SunPro 5.13 compiler features, but only on Linux.
Suppress the portion of the test that fails on Solaris until
the larger problem can be addressed.
Add an ExternalData_NO_SYMLINKS to enable use of copies instead of
symlinks to populate the real data files behind a DATA{} reference.
This will be useful on UNIX-like systems when the underlying filesystem
does not actually support symbolic links.
Suggested-by: Matt McCormick <matt.mccormick@kitware.com>
Extend the ``DATA{Dir/,...}`` syntax with a new ``RECURSE:`` option
to enable recursive matching of associated files. This will allow
an entire directory tree of data to be referenced at once.
Allow URL templates to contain a %(algo:<key>) placeholder that is
replaced by mapping the canonical hash algorithm name through a map
defined by the <key>.
Extend the Module.ExternalData test to cover the behavior.
Extend the RunCMake.ExternalData test to cover error cases.
This bug caused c_function_prototypes to not be recorded at configure
time when compiling with -std=gnu99 or similar. In the case of feature
recording, that was not a problem, because the logic in
CMakeDetermineCompileFeatures.cmake currently assumes that a feature
present for an earlier standard is present for a later standard.
However, the detection strings are also used in WriteCompilerDetectionHeader,
so the feature macro has been defined to '0' when using a later language
dialect.
Fix that by not checking the existence of the __STDC_VERSION__ macro at
all when detecting C90 features.
