Some compilers may add their own RPATH entries when invoking the linker.
For example, a GCC installation may contain the following definition in
the specs file:
*link_libgcc:
%D -rpath <<some specific rpath in which libstdc++.so can be found>>
In this case binaries may contain RPATH entries that CMake did not add.
When we update the RPATH on installation we must preserve these entries
even if CMake thinks the INSTALL_RPATH value should be empty.
Fix this by always using file(RPATH_CHANGE) and teach it to behave as
file(RPATH_REMOVE) if the actual RPATH in the file is empty after
replacing the build-tree RPATH with the install-tree RPATH. This will
preserve any compiler-added RPATH value instead of removing it.
In Modules/Platform/WindowsPaths.cmake our previously recorded
environment variable combinations no longer seem to be correct. For
example, a 64-bit cmake binary may see ProgramW6432 in the environment
and end up not considering the "ProgramFiles(x86)" variable. Instead
check for all possible environment variables in the preferred order and
then remove duplicates.
Reported-by: Shawn Waldon <shawn.waldon@kitware.com>
Add `VERBATIM` to all `add_custom_command` calls so that CMake will
escape arguments properly even when special characters such as "()" are
present.
Suggested-by: Nils Gladitz <nilsgladitz@gmail.com>
Since commit v3.3.0-rc1~410^2~3 (ctest_test: Add QUIET option,
2015-02-17) if tests fail when QUIET is used one sees:
The following tests FAILED:
but not the subsequent line(s) indicating which tests failed.
Restore the list of failed tests.
This is a follow-up to 31b4700ed640bee962f9db9ce25fa84261a944d2.
Remove the extra character that was added to ensure the CMake.ModuleNotices
test passes.
Expand the -W set of cmake options to include support for the -Werror
and -Wno-error format, which is used to control upgrading and
downgrading warning and error messages. Implement support for these new
formats for the dev and deprecated message types.
Add tests and updated documentation for new options.
Most packages install their .pc files into PREFIX/lib/pkgconfig, but
some put them into PREFIX/share/pkgconfig. Either is valid, and
pkg-config itself looks in both for the /usr and /usr/local prefixes.
This fixes an issue where some packages (yajl, for example) are not
found if they are installed into a non-standard prefix and
CMAKE_PREFIX_PATH is used to locate them.
a57caf7e VS: Fix Windows 10 SDK version selection (#15831)
ad594de8 cmSystemTools: Add VersionCompareEqual helper
c173e37f VS: Do not select a partial Windows 10 SDK folder (#15831)
b3677b35 VS: Map the link `/debug` to its IDE property
c22da7cf VS: Drop unused condition in link debug flag generation
4ca9df8b cmIDEOptions: Add support for case-insensitive flags
This improvement to the FindDCMTK module improves compatibility with recent
DCMTK, which provides a DCMTKConfig.cmake file. See the module comments for a
compatibility matrix.
It also provides DCMTK_INCLUDE_DIRS.
Ported from CommonTK (commontk.org).
This was added by commit v2.8.0~2292 (... Set variable
wxWidgets_INCLUDE_DIRS_NO_SYSTEM on the Mac ..., 2008-04-16) and updated
by commit v2.8.9~183^2 (FindwxWidgets: Do not use -isystem on OpenBSD,
2012-05-14). Since the underlying cause was never investigated fully we
do not know the conditions under which -isystem breaks wxWidgets, but
suppressing -isystem is problematic for users that do not want to see
warnings in wxWidgets headers. Simply drop the special case for now so
we can see whether anyone hits the problem again, at which point it can
be investigated in more detail.
Reported-by: Simon Wells <swel024@gmail.com>
In commit v3.4.0-rc1~5^2~1 (VS: Add support for selecting the Windows 10
SDK, 2015-09-30) we added Windows 10 SDK selection choosing the most
recent SDK that is not newer than the target version. This is backward
because it should be up to the application code to not use APIs newer
than the target version. It is up to the build system to provide a SDK
that has at least the APIs expected to be available for the target
version. Furthermore, since the default target version is the host
version of Windows, the old approach breaks when the only SDK available
is for a newer version of Windows.
Fix this by always selecting a Windows 10 SDK if one exists. Use the
SDK for the exact version if is available. Otherwise use the latest
version of the SDK available because that will have at least the APIs
expected for the target version.
