Old versions of `libsigc++` do not have the version macros inside of its
`sigc++config.h` header. Assume nothing about such headers and report
version "zero".
Fixes: #16654
d58d28a9 ParserHelper: Move macros to bottom of files
07953c18 remove file cmStandardIncludes.h
f918b053 cmFortranParser: include what you use
b74314c6 cmDependsJavaParser: include what you use
74404df4 cmCommandArgumentParser: include what you use
e7168c08 cmExprParser: include what you use
ee72803e fix some include-what-you-use diagnostics
Since the class name is used in the macros, the iwyu tool gets confused
wheter it needs a forward declaration or not.
While editing the files, make sure structs have no typedef. Also,
remove confusing comments about Java.
When using the productbuild generator this lets you specify the value of
the `--component-plist` parameter when it runs pkgbuild for a component.
Fixes: #16638
In commit v3.4.0-rc1~333^2 (Merge branch 'upstream-kwsys' into
update-kwsys, 2015-07-15) we brought in upstream KWSys commit 86a24794
(SystemTools: Fix GetActualCaseForPath drive letter case handling,
2015-07-09). This caused our path processing to convert drive letters
to upper-case and exposed an existing bug in our implementation of
CMP0017.
Policy CMP0017 is responsible for ensuring that modules included from a
builtin module only load other builtin modules and cannot be overridden
by a file in `CMAKE_MODULE_PATH`. If there is a case difference in the
drive letter (or other path components) then the path to the including
module may not match our builtin module directory in a simple string
comparison. This means builtin modules may not be recognized as such,
and they may not reliably include their builtin dependencies. For
example, if a project provides a `Platform/Windows` module in
`CMAKE_MODULE_PATH` it can break inclusion of our builtin
`Platform/Windows` module, leading to strange behavior.
Fix this by comparing the path to the including module to our builtin
module directory using a function that is aware of case-insensitivity of
paths on Windows.
Fixes: #16648, #16622
We compute the location of `CMAKE_ROOT` and other resources relative to
the location of our own executable. On some platforms this path is
computed in a way that depends on the case of the path used to invoke
the executable. Convert the result to the actual case preserved by the
filesystem on disk in order to make it consistent regardless of how the
executable is launched.
This approach generalizes the fix made by commit v3.8.0-rc1~71^2
(cmSystemTools: use the actual case for root detection, 2017-01-18).
Issue: #16648
Refactoring in commit v3.6.0-rc1~85^2 (HDF5: Refactor the use of
compiler wrappers, 2016-04-04) converted code of the form
if(${LANGUAGE} MATCHES ...)
to
if(LANGUAGE MATCHES ...)
However, `LANGUAGE` is a foreach() loop variable and not a normal
variable so auto-dereference does not occur. Restore the explicit `${}`
syntax and use the new name of the loop variable that has changed since
then too.
Fixes: #16651
Refactoring in commit v3.6.0-rc1~72^2 (HDF5: Rework component searching
to correctly find HL for all bindings, 2016-05-12) renamed the language
loop variable used to construct the name of `HDF5_<LANG>_INCLUDE_DIR`
but forgot to update it in the `mark_as_advanced` call. Fix it now.
Issue: #16651
1ba91291 Add policy CMP0068 separate install_name and RPATH settings on macOS
f7b9bf41 Apple: Add BUILD_WITH_INSTALL_NAME_DIR target property
4bff2d14 Apple: Refactor support for using INSTALL_NAME_DIR.
624fb9d7 Help: Format BUILD_WITH_INSTALL_RPATH documentation
f10b2f72 ctest_update: Capture failure of svn to load revisions and local mods
ef399f9b ctest_update: Refactor internal APIs to support more failure cases
Thread failure of VC tool commands through more APIs so that we can
detect when they fail. Defer updating of the individual VC tool usage
the future and just return true from them for now.
Michael Maltese