1bdb8cd2 IAR: Detect compiler platform version
b96ca728 Add infrastructure to detect secondary compiler version information
f952f16d Help: Fix placement of one variable in cmake-variables manual
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1324
Create a `CMAKE_<LANG>_COMPILER_VERSION_INTERNAL` variable to hold
a secondary/internal compiler version number detected at the same
time as the primary compiler version. This will be useful for some
compilers where we need such a number to determine correct usage.
Inspired-by: Stefan Andersson <tfosm@hotmail.com>
Suggested-by: Norbert Lange <norbert.lange@andritz.com>
Issue: #17264
- The .desc files will be in the same folder as the generated .cc and .h files.
- Paths to generate .desc files are stored in a variable passed in
- This is only implemented for C++
- Remove legacy ARGS
- Add test that generates and uses C++ protobuf message
- Add test that checks that the generated .desc file can be instantiated
with DynamicMessageFactory
- Add Help rst for new feature
The VS_SHADER_OUTPUT_HEADER_FILE property is the name of the generated
header file containing the object code of the shader.
The VS_SHADER_VARIABLE_NAME property is the name of the variable
containing the object code in the above header file.
Signed-off-by: Kevin M. Godby <kevin@godby.org>
Starting in CUDA 9 the default compilation mode is C++14, and you need
to explicitly enable C++98/03 mode.
While at it, document `14` among the values for `CUDA_STANDARD`. This
was accidentally left out of commit v3.9.0-rc1~118^2 (CUDA: Add support
for the C++14 standard flag, 2017-05-11).
Find GLVND components if available. Add `GLX` and `EGL` options for
COMPONENTS that allow requesting these libraries explicitly. Introduce
new import targets for these windowing-system-specific libraries.
On a GLVND system, populate the legacy `OPENGL_LIBRARIES` variable and
the `OpenGL::GL` target using the `OpenGL` and `GLX` components. On
non-GLVND systems, continue to use the legacy `GL` library and simply do
not provide the GLVND components. Application code can choose to adapt
based on the availability of GLVND components as imported targets.
The `CPackIFW` module `cpack_ifw_configure_component` and
`cpack_ifw_configure_component_group` commands gained a new
`REPLACES` and `CHECKABLE` options.
Adds support for epoch version to CPackRPM and
CPackDeb packagers.
Also adds better version checking to CPackDeb
that complies with Debian rules.
Fixes: #17057
67529aab Doc: document that CoverageExtraFlags will come first
69fac3c3 pass arguments as vector to cmCTest::RunCommand()
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1261
bf1e606f FindMPI: Add support for FreeBSD and SLES
2f673da6 FindMPI: Support components for various languages
9a58e69c FindMPI: Modernization from ground up
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !893
This is a near-total rewrite of FindMPI implementing the following
features:
Environmental improvements:
- C++ settings can now be picked from C settings if no dedicated C++
settings are found (some installs of IBM Platform MPI)
- Fortran settings can now be found on MPICH-1, MVAPICH-1, Microsoft
MPI and MPICH-2 on Windows.
- Improved flag procession logic: Flags related to security enhancements
of MPI itself, and unrelated to MPI usage (-fstack-protector-strong on
e.g. RHEL 7 for MPICH and MVAPICH) will be filtered out properly now.
-pthread is now being handled. -fno-strict-aliasing, which may be needed
while compiling MVAPICH (e.g. RHEL 7's MVAPICH package) is also
filtered.
Features added:
- MPI version can be determined for each language and is exposed as the
package version
- MPI functionality is being tested to ensure the correctness of
settings
- MPI-2 C++ bindings can be suppressed if desired by the project or
user. For older MPIs, this often resolves issues and eliminated the
infamous SEEK_SET trouble.
- MPI-2 C++ bindings are now being searched for and exposed by a
variable if detected.
- Fortran support now does not make assumptions over the MPI present and
works with ILP64 MPI implementations.
- Fortran now exposes which bindings (mpif.h, mpi/mpi_f08 modules) are
available
- MPI detection can now work hybridly, which for example permits using the
Fortran modules shipped with some compiler suites together with MPI
(e.g. PGI on Windows shipping MSMPI modules)
- Ability to determine MPI library version (*requires* try_run, caution)
upon request
- Ability to determine Fortran capabilities from MPI-3 for each of the
bindings (subarrays, asynchronous attribute protecting entities) (also
requires try_run)
Fine grained control over the search process:
- Possibility to selectively enable and disable steps like compiler
wrapper search and guessing. Permits picking Microsoft MPI over Intel
MPI if both are loaded (previously not possible without removing the
IMPI compiler wrappers from the environment)
- Ability to pick MPICH2 over MSMPI (previously the first one located
was taken)
- A user may now pass compiler flags to the compiler wrapper script,
enabling much more flexibility. This permits for example linking the
Intel MPI debug runtime, static linking, ILP64 with Fortran,
linking tracing, ...
- A user may define a suffix for all MPI binaries that are being looked
for (useful on Debian/Ubuntu where the alternative MPI installs are each
appended with their name, e.g. mpicc.mpich and mpicc.lam)
Cache variable improvements
- Instead of the previous plural cache variables a list-of-variables
approach is now in place. Permits correcting individual variables
instead of having to wade through a list, also speeds up the search
process and increases comfort by eliminating duplicate entries in
LIBRARIES over languages
- MPIEXEC was corrected to MPIEXEC_EXECUTABLE in order to fix the
grouping in the CMake GUI for the variable (previously ungrouped)
