A common use case of `target_compile_features` is simply to specify that
the compiler should be run in a mode that is aware of e.g. C++11. Some
projects simply specify a particular C++11-only feature to request this.
Provide a first-class way to do this by naming features after the
corresponding language standard. Record them as always available in the
corresponding standard level so that requesting them always ensures that
standard (or higher) is used.
We have no feature tests for versions of VS older than 2010, so do
not even call `record_compiler_features` for such versions. This
is consistent with other compilers where we call this macro only
for versions for which we have recorded features.
Refactoring in commit v3.6.0-rc1~72^2 (HDF5: Rework component searching
to correctly find HL for all bindings, 2016-05-12) changed the default
behavior from finding only the C bindings to finding everything for the
enabled languages. Restore the original behavior for compatibility and
because many projects need only the C bindings.
Closes: #16397
`CPACK_RPM_COMPONENT_INSTALL` is the correct variable to set to enable
component packaging. `CPACK_RPM_PACKAGE_COMPONENT` is just set to a
component name when CPack calls corresponding installer.
`CPACK_DEB_COMPONENT_INSTALL` is the correct variable to set to enable
component packaging. `CPACK_DEB_PACKAGE_COMPONENT` is just set to a
component name when CPack calls corresponding installer.
`swig` has two output-related options:
* `-o <outfile>`: Set name of C/C++ output file to <outfile>
* `-outdir <dir>`: Set language-specific files output directory to <dir>
We already have `CMAKE_SWIG_OUTDIR` for the latter. Add a new
`SWIG_OUTFILE_DIR` option for the former.
Starting with Xcode 8 the SDK folder also contains an unversioned entry:
MacOSX.sdk
MacOSX10.12.sdk -> MacOSX.sdk
If this unversioned path is used CMake cannot detect the SDK version.
Furthermore, querying the SDK version via
xcodebuild -sdk <sysroot> -version Path
gives bogus results for the Command Line Tools installed into `/`.
The OS X deployment target version and SDK version are not as tied as
they once were, so this check is now more trouble than it is worth.
Simply remove it.
Closes: #16323
Revert commit v3.7.0-rc1~48^2 (Xcode: Convert maybe unversioned OSX
sysroot into versioned SDK path, 2016-09-25). The replacement of
`else()` with `if(CMAKE_OSX_SYSROOT)` defeats the prior handling of
`if("x${CMAKE_OSX_SYSROOT}" MATCHES "/")`. This causes the combination
-DCMAKE_OSX_DEPLOYMENT_TARGET:STRING="" -DCMAKE_OSX_SYSROOT:STRING=/
to not be honored and `-isysroot` to be emitted as a compiler flag
universally. We will need another solution to the problem the
now-reverted commit was meant to address.
Closes: #16394
Fix typo in variable used to communicate between matlab_add_unit_test
and its helper script MatlabTestsRedirect.cmake that was introduced in
commit v3.7.0-rc1~116^2 (FindMatlab: Extend matlab_add_unit_test to run
arbitrary test code, 2016-08-30).
Since this compiler always defines `__cplusplus` to `1` we need to use
`_MSC_VER`, `__INTEL_CXX11_MODE__`, and the feature test macro named
`__cpp_aggregate_nsdmi` to detect C++11 and C++14 modes.
With no `-Qstd=` flag this compiler defaults to C++98 plus a subset of
C++11/C++14 features needed to be compatible with MSVC. We pretend it
is plain C++98 and add a `-Qstd=` flag whenever needed for C++11 or
above features even if they would happen to be available in MSVC-mode.
Closes: #16384
The change in commit 05e05cd2 (Intel: Fix compiler C++98 standard flag
on Windows, 2016-10-26) was wrong. The Intel C++ Compiler for Windows
does not support either `-Qstd=c++98` or `-Qstd=gnu++98`. Simply remove
both flags for this compiler and use no options at all to achieve this
mode.
Issue: #16384
The extension flags enabled by commit v3.6.0-rc1~120^2~1 (Features:
Record standard flags for Intel C/C++ on Windows, 2016-04-18) of the
form `-Qstd=gnu++11` are not supported by the Intel C/C++ Compiler for
Windows. Fall back to using the non-extension form of the flags.
Issue: #16384
Add `-fPIE -pie` to the default executable link flags when
`CMAKE_POSITION_INDEPENDENT_CODE` is enabled. This is required by
Android 16 and above for executables to run on the device.
Closes: #16382
If the toolchain file or cache does not set this, enable it
automatically based on the Android API version. Versions 16
and above expect position independent code.
Use the main `CMAKE_POSITION_INDEPENDENT_CODE` setting in favor of
hard-coding `-fpic` or `-fPIC` in the compiler flags for each ABI.
This allows CMake to use `-fpie` or `-fPIE` as needed when sources
are meant for executables, and `-fpic` or `-fPIC` for other sources.
See `${ndk}/build/core/default-build-commands.mk` for link flags the NDK
uses for executables. Add them to our default executable link flags.
Suppress `nocopyreloc` on `arm64-v8a` because it does not work with
some STL types.
Closes: #16380
Add missing "unwind" and "atomic" libraries needed for this combination.
See `${ndk}/sources/cxx-stl/llvm-libc++/libs/armeabi/libc++.a` for the
libraries the NDK uses.
Issue: #16380
Previously, the configure command generated by ExternalProject was not
accessible prior to actually adding the targets. This makes the CMake
configure command accessible with just a call to _ep_parse_arguments.
Future work will leverage this to support custom environment settings on
a per-project basis.
9af881d8 Tests: Add VSNsightTegra test for VS 2015
6739d240 Tests: Fix VSNsightTegra test on Android NDK r12b
06c39612 VS: Fix NVIDIA Nsight Tegra Visual Studio Edition support
