Merge-request: !5105

Jörg Bornemann authored 4 years ago and Brad King committed 4 years ago

Change the default value of `CMAKE_AUTOMOC_PATH_PREFIX` to `OFF` to
restore compatibility with behavior of CMake 3.15 and below.

C++ source files that are generated by Qt's meta object compiler (moc)
include the header file that was passed as input argument to moc. This
is usually a path relative to the source directory, for example

    #include "../../source/dir/myobject.h"

That is problematic for reproducible builds as described in #18815.
To cope with that, the target property AUTOMOC_PATH_PREFIX was
introduced in CMake 3.16 by commit d018d27c (Autogen: Add moc path
prefix generation (AUTOMOC_PATH_PREFIX), 2019-09-13, v3.16.0-rc1~94^2~4).
The property is default-initialized from the variable
`CMAKE_AUTOMOC_PATH_PREFIX`, which defaults to `ON`.

If this property is ON, and myobject.h is located in an include
directory of the target, moc-generated C++ files include the file
without the "path prefix":

    #include "myobject.h"

This behavior, however, can break projects that have equally named
header files in different include directories.  As "not breaking
existing projects" trumps "have reproducible builds by default" we
change the default of `CMAKE_AUTOMOC_PATH_PREFIX` to `OFF`.

Also, it is now possible to pass `-DCMAKE_AUTOMOC_PATH_PREFIX=ON` on the
CMake command line.  Before, it was overridden in `CMakeGenericSystem`.

Fixes: #20598
Issue: #18815

Merge-request: !5108

Avoid interference from `CMAKE_PREFIX_PATH` and friends if they
happen to be set in the environment from which the tests are run.

Merge-request: !4815

Since commit 729d997f (Precompile Headers: Add REUSE_FROM signature,
2019-08-30, v3.16.0-rc1~101^2), `GetPchFileObject` handles the case that
it is called first for another target's `REUSE_FROM` by calling
`AddSource` to make sure `GetObjectName` can produce the correct object
name.  However, `AddSource` causes `ClearSourcesCache` to be called,
which since commit a9f4f58f (cmGeneratorTarget: Clear AllConfigSources
in ClearSourcesCache, 2020-05-15, v3.16.7~2^2) now correctly erases the
`AllConfigSources` structure.  This is okay during `AddPchDependencies`,
but there is another code path in which it is problematic.

When the Visual Studio generator's `WriteAllSources` method is looping
over the sources, the `cmake_pch.cxx` source is encountered first.  This
causes `OutputSourceSpecificFlags` to call `GetPchCreateCompileOptions`,
which calls `GetPchFile`, which under MSVC with `CMAKE_LINK_PCH` calls
`GetPchFileObject`.  That leads to `ClearSourcesCache` erasing the
structure over which `WriteAllSources` is iterating!

This bug is caught by our `RunCMake.PrecompileHeaders` test when run
with the VS generator as of the commit that exposed it by fixing
`ClearSourcesCache`.  However, that change was backported to the CMake
3.16 series after testing only with later versions versions that contain
commit a55df204 (Multi-Ninja: Add precompile headers support,
2020-01-10, v3.17.0-rc1~136^2).  By adding proper multi-config support
for PCH, that commit taught `cmLocalGenerator::AddPchDependencies` to
call `GetPchFile` with the real set of configurations instead of just
the empty string.  This allows the `GetPchFile` cache of PCH sources to
be populated up front so that the later calls to it in the
`WriteAllSources` loop as described above do not actually call
`GetPchFileObject` or `ClearSourcesCache`.  That hid the problem.

Fix this by re-ordering calls to `AddPchDependencies` to handle
`REUSE_FROM` targets only after the targets whose PCH they re-use.
Remove the now-unnecessary call to `AddSource` from `GetPchFileObject`
so that `ClearSourcesCache` is never called during `WriteAllSources`.
Update the PchReuseFrom test case to cover an ordering of targets that
causes generators to encounter a `REUSE_FROM` target before the target
whose PCH it re-uses.

Fixes: #20770

Merge-request: !4765

Since commit 3b51343e (VS: Emit UTF-8 BOM for generated solution files,
2019-08-19, v3.16.0-rc1~237^2) the `.sln` file does not work with the
VS Version Selector.  Add a newline after the BOM to restore support.

Fixes: #20725

Merge-request: !4751

Merge-request: !4752

Add a release note for the change in commit 4d446c68 (FindPkgConfig:
also handle "-isystem" prefixes for include directories, 2020-04-30).

In commit 40aa6c05 (cmGeneratorTarget: Add method to collect all
sources for all configs, 2017-04-10, v3.9.0-rc1~268^2~5) we forgot to
update `ClearSourcesCache` to also clear `AllConfigSources`.  This leads
to subtle cases where code paths like PCH handling that add sources
during generation break depending on ordering.

Suggested-by: Christian Fersch
Fixes: #20712, #20702

If the `OBJC` or `OBJCXX` environment variable is not set to specify an
Objective C or C++ compiler, check `CC` or `CXX` too.

Fixes: #20703

Merge-request: !4736

VS 2017 15.6 introduced support for this pragma.  Older MSVC versions
warn that it is unknown.

Fixes: #20692

Merge-request: !4734

If a source file gets per-source flags from both PCH and custom
`COMPILE_OPTIONS`, combine them correctly.

Fixes: #20694, #20456

Merge-request: !4725

Since commit effafca7 (FindGTK2: Add harfbuzz to GTK2_INCLUDE_DIRS,
2019-10-01, v3.16.0-rc1~22^2), pango's dependency on harfbuzz has been
captured, but only for the `GTK2_INCLUDE_DIRS` and `GTK2_LIBRARIES`
variables.  Add the `GTK2::harfbuzz` imported target and update the
`GTK2::pango` target to depend on it.

Issue: #19531

Merge-request: !4693

Fixes: #20652

Merge-request: !4711

Fix the condition added by commit fada8cbf (CheckLanguage: Report
CMAKE_CUDA_HOST_COMPILER if needed for compilation, 2019-05-31,
v3.15.0-rc1~12^2) to activate CUDA-specific logic.  The old condition
had worked in our test suite only by accident because the loop variable
used in the test happened to be the name and value that the old
condition used!  Update the test to use a different name.

Fixes: #19013

Merge-request: !4675

Fixes: #20634

Fixes: #20635

Merge-request: !4678

When the path to a header file is specified using a generator
expression, evaluation of the genex must produce an absolute path.
Update our documented example and add a test covering the case.

Fixes: #20617

Merge-request: !4611

Merge-request: !4598

Fixes: #20582