When encountering an `#include "<PATH>ui_<BASE>.h"` statement,
search for `<BASE>.ui` in
- <SOURCE_DIR>/<BASE>.ui
- <SOURCE_DIR>/<PATH><BASE>.ui
- <AUTOUIC_SEARCH_PATH>/<BASE>.ui
- <AUTOUIC_SEARCH_PATH>/<PATH><BASE>.ui
In CMake 3.8.2 the lookup list was
- <SOURCE_DIR>/<BASE>.ui
In CMake 3.9.[01] the lookup list was
- <SOURCE_DIR>/<PATH><BASE.ui>
- <AUTOUIC_SEARCH_PATH>/<PATH><BASE>.ui
Closes#17168
Disable the feature added by commit v3.9.0-rc1~71^2~2 (find_*: Add a new
PackageRoot search path group, 2017-05-03) and remove documentation
added by commit v3.9.0-rc1~71^2 (find_*: Add docs for PackageRoot search
path group, 2017-05-03). Unfortunately the name `<pkg>_ROOT` may
already be set by projects for their own incompatible purposes. Disable
the behavior change for now to fix the regression for CMake 3.9. We can
restore it later with a policy.
In order to keep the implementation and tests working, add an
undocumented variable we can use in the tests to enable the behavior
before the policy is introduced.
Fixes: #17144
The **AUTOGEN** include directory was always passed to the compiler but
only generated on demand. To avoid compiler complaints when using
`-Wmissing-include-dirs` make sure the directory gets created always.
Closes#17147
In some environments MSBuild chooses the `Release` configuration
even though only `Debug` is available in our detection project.
Force use of the `Debug` configuration with a command-line option.
Fixes: #17118
The code
add_library(A OBJECT a.c)
target_sources(A PRIVATE $<TARGET_OBJECTS:A>)
used to crash CMake via infinite recursion while evaluating the
generator expression. Then the change in commit v3.9.0-rc1~266^2~1
(cmGeneratorTarget: Replace source classifier implementation,
2017-04-07) avoided the infinite recursion because GetKindedSources now
creates a map entry and initializes it once. If it is called again on
the same target during that initialization, the partially computed
results are returned. This is still wrong but does not crash.
Detect and diagnose this case instead.
Co-Author: Ben Boeckel <ben.boeckel@kitware.com>
Fixes: #16578
This is needed for Xcode 9's "New Build System", whose release notes
mention "that output must be declared as an explicit output by the
script which generates it" in reference to outputs of custom script
build phases.
The change in commit v3.9.0-rc1~174^2~2 (CompileFeatures: Let STD
compile options be a list, 2016-10-05) did not change all the places we
add the language standard options. Expand the list in the other places.
The logic added in commit v3.6.0-rc1~30^2 (Add a variable to specify
language-wide system include directories, 2016-05-24) to use
`CMAKE_<LANG>_STANDARD_INCLUDE_DIRECTORIES` incorrectly filters them by
`CMAKE_<LANG>_IMPLICIT_INCLUDE_DIRECTORIES`. Rather than recognizing
this, commit v3.8.0-rc1~60^2 (Android: Pass sysroot include directory
explicitly, 2017-01-20) worked around the problem by incorrectly
removing `/usr/include` from `CMAKE_<LANG>_IMPLICIT_INCLUDE_DIRECTORIES`
so it worked in `CMAKE_<LANG>_STANDARD_INCLUDE_DIRECTORIES`.
By not filtering out `/usr/include` from user-specified include
directories, we allow the code
include_directories(${CMAKE_SYSROOT}/usr/include)
to place the include directory too early on the command line.
Fix support for standard include directories to not be filtered by
implicit include directories, and do not remove `/usr/include` from the
list of implicit include directories for Android builds. Add a test
case to verify that an explicit `/usr/include` is ignored in favor
of the standard directory at the end.
Fixes: #17059
Revert the main logic change of commit v3.9.0-rc1~192^2 (bindexplib: fix
constants symbols export, 2017-04-26) and its test case. Unfortunately
some constants may be provided by multiple object files with different
`@...` suffixes, leading to ambiguous references. Revert support
pending further investigation.
Fixes: #17045
In the `Visual Studio 15 2017` generator, if the `VS150COMNTOOLS`
environment variable points at a specific VS 2017 instance reported by
the Visual Studio Installer tool, use that as the preferred instance.
Inspired-by: Iyyappa Murugandi <iyyappam@microsoft.com>
Fixes: #16846
Since commit v3.9.0-rc1~58^2 (find_package: shorten output for missing
package in config mode, 2017-05-09) we print only the one line
- Could NOT find Foo (missing: Foo_DIR)
when package Foo cannot be found in CONFIG mode and it is not REQUIRED.
However, in the case that package configuration files were found but not
used, this one line message leaves out important information. This can
happen when a package configuration file sets `Foo_FOUND` to `FALSE` or
when its package version file does not match the requested version.
Restore the longer message in these cases. Otherwise a seemingly valid
explicit `Foo_DIR` setting appears to be silently ignored even if it was
considered.
Fixes: #17029
The change in commit v3.9.0-rc1~464^2~8 (Autogen: Add AUTOMOC/UIC
support for generated source files, 2017-03-02) changes behavior of
existing projects that may not expect `AUTOGEN` on generated files and
do not yet set `SKIP_AUTOGEN` on them. Disable the behavior change for
now to fix the regression for CMake 3.9. We can restore it later with a
policy.
In order to keep the implementation and tests working, add an
undocumented property we can use in the tests to enable the behavior
before the policy is introduced.
Fixes: #17031
Issue: #16186
When encountering an #include "FOO.moc" statement where
FOO.hpp was chosen over FOO.cpp as the moc source, the
FOO.hpp name was not checked against the moc SKIP list.
Although `$(VCTargetsPath)/1033/link.xml` for v140 and v141 toolsets
contains an entry for `LinkControlFlowGuard`, it does not work when used
in a `.vcxproj` file. Drop our link flag table entries for these
toolsets so that the flag will be passed via `AdditionalOptions`.
When calculating Object Library paths take a look at the
`XCODE_EMIT_EFFECTIVE_PLATFORM_NAME` property to enable builds with
different SDKs. Otherwise a hard-coded architecture could be chosen.
Fixes: #16040
When VS 2015 was first released, its new v140 toolset came with a
`link.xml` file that changed the `GenerateDebugInformation` boolean
(`false` and `true`) value from earlier toolsets to an enumeration
consisting of the possible values `No`, `Debug`, and `DebugFastLink`.
We first adapted to this in commit v3.4.2~2^2 (VS: Fix VS 2015 .vcxproj
file value for GenerateDebugInformation, 2016-01-08), but that broke
older toolsets that still expected the boolean. Then commit
v3.6.0-rc1~295^2~1 (VS: Fix VS 2015 .vcxproj debug setting for older
toolsets, 2016-02-24) added a hack to fix up the value based on the
toolset in use. Several follow-up commits fixed this for more older
toolsets because our flag table was at the time based on the generator
in use rather than the toolset in use.
Since commit v3.8.0-rc1~396^2 (VS: Choose flag map based on the toolset
name, 2016-10-17) we use a flag table based on the toolset, so the fixup
hack should not be needed. We had to keep it around only due to our
default value for GenerateDebugInformation (`false` or `No`) still being
based on the generator instead of the toolset.
A VS 2015 update was released that changed the v140 toolset `link.xml`
file back to using `false` and `true` for the `GenerateDebugInformation`
enumeration variants previously known as `No` and `Debug`. In order to
know which pair to use, we need to parse the `link.xml` file for the
current toolset.
Switch back to using `false` and `true` unconditionally in our
`GenerateDebugInformation` flag table entries and default value. With
that plus the toolset-based flag table, we now get incorrect values for
`GenerateDebugInformation` only when using a v140 toolset from an older
VS 2015 installation. Detect this case by parsing `link.xml` and add
special logic to convert `false` and `true` to `No` and `Debug` to
satisfy the older toolset specification.
Inspired-by: Ian Hojnicki <nullref@live.com>
Fixes: #17020
