b2fd479df5 FindBinUtils: Use the compiler to get the path to compiler tools
587ccffe74 Tests: Add symbols to FortranModules static libraries
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Alex Turbov <i.zaufi@gmail.com>
Merge-request: !3854
When not using the `-pthread` flag we instead return a library to link
by name. Previously we hard-coded the `-l` flag before the library
name. When used with `target_link_libraries`, the hard-coded `-l` flag
is preserved rather than transformed into the link option preferred by
the toolchain in use. Drop the explicit `-l` part to let CMake's
generators produce the proper way to link the threads library for the
current toolchain.
Fixes: #19747
cc0900d9cd Help: Add release notes for AUTOMOC_PATH_PREFIX
692d8e3492 Help: Add documentation for AUTOMOC_PATH_PREFIX
1933ade9f1 Tests: At QtAutogen.MocIncludeSymlink test
706d9738a6 Tests: Merge QtAutogen.MocIncludeStrict and MocIncludeRelaxed
d018d27c10 Autogen: Add moc path prefix generation (AUTOMOC_PATH_PREFIX)
77983c8147 Autogen: Add IsHeader flag to SourceFileT class
f9e5441eb4 Autogen: Abbreviate file paths in messages
51676cf655 Autogen: Split JobEvalCacheT job into separate moc and uic jobs
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !3818
pkg-config's .pc files can sometimes provide libraries that are visible to
the linker but not present in CMake's known search paths. In the case
where CMake can find some, but not all of the library dependencies
provided in a .pc file, this allows them to be passed through as "-lfoo"
when the full path can't be found.
This also removes the test failure cases that occured because of this
scenario and adjsuts the remaining tests to account for not-found
libraries
The new `AUTOMOC_PATH_PREFIX` boolean target property enables automatic
generation of the path prefix `-p` option for `moc`.
`AUTOMOC_PATH_PREFIX` is initialized from the variable
`CMAKE_AUTOMOC_PATH_PREFIX`, which is ON by default.
When `AUTOMOC_PATH_PREFIX` is enabled, CMake tests if a `moc`ed header file is
in one of the include directories. If so, then the `-p` option, with the
relative path of the header parent directory to the respective include
directory, is added to the `moc` command. If the header file is not in an
include directory, the `-p` option is omitted.
Closes: #18815 "AUTOMOC: generated files include full relative path,
breaking certain reproducible builds"
Since commit 0dd6772a89 (FindBoost: Add legacy variables and targets for
compatibility, 2019-06-14, v3.15.0-rc2~3^2~1) we query imported targets
provided by `BoostConfig.cmake` for their `IMPORTED_LOCATION_<cfg>`.
Querying this property is not allowed on INTERFACE libraries, so add a
condition to avoid doing so in case Boost adds one in the future.
Suggested-by: Alexander Grund <alexander.grund@tu-dresden.de>
Issue: #19656, #19402
Revise the wording of the warning added by commit 0dd6772a89 (FindBoost:
Add legacy variables and targets for compatibility, 2019-06-14,
v3.15.0-rc2~3^2~1) to refer to the old variables as "legacy" rather
than "standard".
Suggested-by: Alexander Grund <alexander.grund@tu-dresden.de>
Issue: #19402
The Intel Fortran compiler supports an extension that allows conditional
compilation based on preprocessor definitions specified on the command
line even when not preprocessing.
Fixes: #19664
dca9c33abc Tests: Remove old IPO test
c856d4556b bindexplib: supporting llvm bitcode formats using llvm-nm
079b8e2916 Clang: prefer lld-link over link.exe
6e3655db2c Clang: add LTO support for GNU-command line clang on windows
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !3527
25f29b9741 cuda: Adapted tests to work with modified cuda toolset
ee86770a3f cuda: Added docs for extended cuda toolset
0ad180d712 cuda: Extend cuda compiler detection to work with custom cuda path
55b0532128 cuda: Extend vs10 target generator to use custom cuda path
df0247a371 cuda: Extend toolset argument to accept path
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !3713
7828577065 FindBoost: Add support for Boost 1.71
cf29fa18c8 FindBoost: Unwrap compatibility INTERFACE targets for legacy variables
d7df3cd73f FindBoost: Remove incorrect 1.70 timer dependency
8ff43de1a5 FindBoost: Simplify conditional block for last known version
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Dennis Klein <d.klein@gsi.de>
Merge-request: !3763
Since commit 0dd6772a89 (FindBoost: Add legacy variables and targets for
compatibility, 2019-06-14, v3.15.0-rc2~3^2~1) we extract information
from imported targets provided by upstream `BoostConfig.cmake` files.
However, upstream Boost 1.71 provides some imported targets only for
compatibility. They are just INTERFACE libraries that wrap around the
real target named by `INTERFACE_LINK_LIBRARIES`. Unwrap this layer so
we can extract the real imported location.
Fixes: #19656
Running `Utilities/Scripts/BoostScanDeps.cmake` with the Boost 1.70.0
sources shows that the `timer` component no longer depends on `system`.
This is consistent with upstream Boost Timer commit `43eecbd071`.
For the multi-configuration generators one can specify the list
of configurations to include in the package.
E.g. having a project, where debug libraries have a suffix to
distinct them from the release builds, one can build the package
containing both `Debug` and `Release` binaries.
When running `pkg_search_module`, it may be useful to get the matching
module name in order to run `pkg_get_variable`.
`pkg_search_module` now defines `<prefix>_MODULE_NAME` which contains
the first matching module name.
Fixes: #19648
Brad King