7d756f37cc FindBLAS: do not write an imported target name into BLAS_LIBRARIES
946846aaf5 FindPkgConfig: do not unset unused variable
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2006
f59c33a763 VS: Generate a custom command only in the least dependent target
d58d4daa6b cmVisualStudio10TargetGenerator: Use cmLocalVisualStudio10Generator
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1889
Since commit v3.11.0-rc1~177^2 (FindBLAS: optionally query pkg-config
for a library, 2017-12-15) the `BLAS_LIBRARIES` result variable may
incorrectly contain the name of an imported target. Instead store the
list of libraries in the variable. Unfortunately pkg_check_modules does
not provide a way to get this so we need to use a (temporary) hack of
reading `INTERFACE_LINK_LIBRARIES` from the interface library target.
Fixes: #17934
When using https://github.com/cristianadam/cmake-checks-cache I have
noticed that CheckTypeSize would in certain cases have an empty
`__check_type_size_dir` variable. The errors would point to
`TestBigEndian`. By moving `include(CheckTypeSize)` outside the macro,
the errors go away.
Including dependencies of a module when the module is first included is
simpler and cleaner anyway.
The change in commit v3.11.0-rc1~480^2 (UseJava: add_jar OUTPUT_DIR
option used only for jar generation, 2017-10-12) added code of the form
`file(MAKE_DIRECTORY ${CMAKE_BINARY_DIR})`. This exposed an existing
bug in `CMAKE_DISABLE_SOURCE_CHANGES` in which it does not recognize
that the top of the build tree itself is in the build tree. Fix that
now.
Fixes: #17933
Users can create it through an explicit command-line option if desired.
Initializing the variable as an empty cache entry can wipe out a normal
variable of the same name that may have been set by a toolchain file.
Since commit v3.8.0-rc1~261^2~11 (CUDA: Use the host compiler for
linking CUDA executables and shared libs, 2016-09-19) we save the value
of `CMAKE_CUDA_HOST_COMPILER` persistently in the compiler information
file as a normal variable.
Fixes: #17935
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.
When cross-compiling on a Windows host, we use a `:cmake_mode_t` NTFS
alternate stream to store the file mode for use during packaging.
Writing to this stream changes the file modification time, so save and
restore the original modification time since we are not modifying the
real file content.
Fixes: #17922
* 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
If a custom command is assigned to multiple targets, generate the build
rule only in the least-dependent `.vcxproj` file. Otherwise MSBuild
will run the command on the first build of a dependent target even if
its dependencies already brought the command up to date (in order to
populates its build log).
Generate targets in least-to-most-dependent order, and assign a custom
command to the least dependent target.
Added cmLocalVisualStudio10Generator::GenerateTargetsDepthFirst to call
cmVisualStudio10TargetGenerator::Generate in least-dependent order.
Moved SourcesVisited from cmVisualStudio10TargetGenerator to
cmLocalVisualStudio10Generator to avoid attaching a custom command to
multiple targets among the local generator.
Fixes: #16767
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
