An effect of the `-isystem` flag is to search the directory after those
specified via `-I` flags. Make behavior more consistent on compilers
that do not have any `-isystem` flag by explicitly moving system include
directories to the end.
* Determining automatically the MCR version on OSX and Windows
* Distinguishing between MCR and Matlab
* Specific tests for the MCR
* mexext on windows does not work properly: the mexext is hardcoded
* Doc updates for the MCR
Fixes: #16487
b1f95e5b14 Fortran: Extend submodule test with great-grandchild
402735314e Fortran: Add support for submodule dependencies
62538b2c4c Fortran: Refactor to treat .mod extension as part of module name
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Izaak Beekman <contact@izaakbeekman.com>
Merge-request: !1989
a4f71b4ba8 Help: Document existence of cmake_install.cmake
fcf64866da Help: move DESTDIR into a separate page
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1979
Since commit v3.7.0-rc1~73^2~1 (Fortran: Add support for submodule
syntax in dependency scanning, 2016-09-05) we support parsing Fortran
sources that use submodule syntax, but it left addition of `.smod`
dependencies to future work. Add it now.
The syntax
submodule (module_name) submodule_name
means the current source requires `module_name.mod` and provides
`module_name@submodule_name.smod`. The syntax
submodule (module_name:submodule_name) nested_submodule_name
means the current source requires `module_name@submodule_name.smod`
provides `module_name@nested_submodule_name.smod`.
Fixes: #17017
When tracking module names internally, include the `.mod` extension.
This will later be useful to distinguish them from `.smod` extensions
for submodules.
Fix version comparisons to handle patch components. List and check
known archs for each version of CUDA so mismatching versions are not
suggested.
Fixes: #17921
This file, which is currently undocumented, is useful for external
packaging programs that wish to install only a single component at a
time. This change adds documentation for the file.
63e0c16e3d Help: Link from CMAKE_<LANG>_FLAGS to <LANG>FLAGS environment variables
8acf46caf1 Utilities/Sphinx: Add role and directive for 'envvar' in CMake domain
7e532abc78 Utilities/Sphinx: Fix QtHelp generator identifiers
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !1985
Create `CMAKE_VS_SDK_*_DIRECTORIES` variables to tell the VS generator
how to populate fields in `.vcxproj` files that specify SDK directories.
Fixes: #17908
This enables cross-reference syntax for CMake environment variables:
:envvar:`SOMEVAR`
and definition of CMake environment variables via a directive:
.. envvar:: SOMEVAR
It also adds environment variables defined by the directive and by
`Help/envvar/SOMEVAR.rst` documents to the index.
This `envvar` role and directive is defined in our `cmake` domain
and overrides the equivalent `envvar` role and directive provided
by Sphinx in its default domain. This is okay because we build
CMake documents in the `cmakd` domain.
This follows up the work from commit v3.10.0-rc1~43^2 (Help: Document
CMake's environment variables, 2017-09-01) that originally added
`envvar` documentation.
