Merge-request: !1289

Rolf Eike Beer authored 7 years ago and Rolf Eike Beer committed 7 years ago

The opened XML elements were not closed, so an assert was triggered when the
file was finally closed. If CMake is built with assertions disabled then an
invalid XML file will be produced.

Merge-request: !1280

Roger Leigh authored 7 years ago and Brad King committed 7 years ago

Backport the changes from commit fa114e7d (FindBoost: Add Boost 1.65
dependencies, 2017-08-22) and commit dbba53a5 (FindBoost: Add version
1.65.1, 2017-09-06) to CMake 3.9.

Fixes: #17289

Merge-request: !1273

Maarten de Vries authored 7 years ago and Brad King committed 7 years ago

An update from vim-cmake-syntax by commit v3.9.0-rc1~167^2^2
(vim-cmake-syntax 2017-05-02, 2017-05-02) brought in a change to set
`expandtab` in CMake language files.  This should be a per-project or
per-user choice instead, so drop the setting.

Merge-request: !1257

Sebastian Holtermann authored 7 years ago and Brad King committed 7 years ago

Target dependencies of the origin target were mistakenly forwarded to
the _autogen target as *file* dependencies.  This patch introduces
proper distinction between *target* and *file* dependencies of the
_autogen target.

This patch also changes when PRE_BUILD is used for AUTOGEN in the Visual
Studio generator. Formerly PRE_BUILD was disabled when the origin target
depended on *any* other target. Now PRE_BUILD is only disabled if a
dependency of the _autogen target to an additional *file* is detected.

Fixes: #17278, #17205

Merge-request: !1258

Since commit v3.9.0-rc1~281^2 (Use quotes for non-system includes,
2017-04-11) we include `cmConfigure.h` via `""` instead of `<>`.
This breaks the `bootstrap` script when run more than once in an
in-source build.  In that case `cmConfigure.h` is generated next
to the source files that include it, so `""`-style includes prevent the
`Bootstrap.cmk/cmConfigure.h` file from being included during bootstrap.

Fix this by teaching the bootstrap script to remove any `cmConfigure.h`
that may have been generated by an earlier run in an in-source build.

Fixes: #17082

Merge-request: !1256

Since commit v3.9.0-rc1~309^2 (include_external_msproject: Honor
MAP_IMPORTED_CONFIG_<CONFIG>, 2017-04-04) we accidentally honor
`MAP_IMPORTED_CONFIG_<CONFIG>` while generating the `.sln` file entries
for normal targets.  This causes `devenv.com`-driven builds to use the
mapping incorrectly for normal targets.  Check that a target really
comes from `include_external_msproject` before considering the map.

Furthermore, when we do use the map, we should only take the first entry
if more than one configuration is specified.  Otherwise we end up giving
VS a configuration name with a `;` in it.

Fixes: #17276

CMake 3.9 does not have CMP0070, so port away from it for that branch.

Merge-request: !1240

Assume that all cl 19.xx versions will use the same runtime DLL pattern.

Suggested-by: Tomasz Słodkowicz <slodki@users.noreply.github.com>

Merge-request: !1238

Revert commit v3.9.0-rc1~41^2 (FindBoost: Simplify search in lists,
2017-04-23).  It regressed the module by exposing issue #17257, but the
fix for that issue is not suitable for inclusion in a patch release.
It is simplest to revert the commit until the larger problem can be
addressed.

Fixes: #17252

Merge-request: !1237

Since NDK commit 90ec78ffd96b87cd75d82575587ead14d6494df1 (Remove Clang
toolchain path from setup.mk, 2017-05-31) the `setup.mk` files for Clang
no longer hold the path to the `toolchains/llvm` directory.  It has been
the same since NDK r11, so use that as the default.

Fixes: #17253

Merge-request: !1232

Michael Stürmer authored 7 years ago and Brad King committed 7 years ago

Use the same environment variable for the initial flags that we
use for the compiler id.

Fixes: #17250

Merge-request: !1233

Christian Pfeiffer authored 7 years ago and Brad King committed 7 years ago

The overhaul in commit v3.9.0-rc1~207^2~1 (FindOpenMP: Complete
overhaul, 2017-04-24) documented this variable but accidentally left it
unset.

Fixes: #17251

Merge-request: !1203

Michael Stürmer authored 7 years ago and Brad King committed 7 years ago

Since commit v3.9.0-rc4~4^2 (Vs: allow CSharp targets to be linked to
CXX targets, 2017-06-20) CSharp targets get `ProjectReference` entries
to their dependencies.  This causes VS to also reference the
dependency's output assembly by default, which is incorrect for
non-managed targets.

Fix this by setting `ReferenceOutputAssembly` to `false` for targets
that can't provide output assemblies.  Unmanaged C++ targets (shared
libs & executables) can still be referenced and a warning will be shown
in the IDE but the build will not break anymore.

Fixes: #17172

Merge-request: !1218

Refactoring in commit v3.8.0-rc1~445^2~2 (cmTarget: Move sanity checks
and computed property access to callers, 2016-10-13) exposed a typo in
commit v3.8.0-rc1~445^2~3 (cmGeneratorTarget: Implement
cmTargetPropertyComputer interface, 2016-10-13).  Together they broke
the `$<TARGET_PROPERTY:mytgt,SOURCES>` generator expression in the case
that the `SOURCES` target property is populated in part by the
`target_sources` command.  Add the missing `;`-separator.

Fixes: #17243

Merge-request: !1208

The change in commit v3.9.0-rc1~116^2~6 (cmakemain: use script role for
-P, 2017-05-11) accidentally left project commands out of find-package
mode, causing packages that provide imported targets to break.

Fixes: #17124

Merge-request: !1206

We use `std::sort` and so must include `<algorithm>`.

Issue: #17233

Merge-request: !1183

The change in commit v3.9.0~3^2 (Xcode: Add "outputPaths" to custom
command script build phase, 2017-07-13) was meant to support Xcode 9's
new build system.  However, without matching "inputPaths", Xcode will
not re-run the build phase if its outputs have already been generated.
This broke the old Xcode build system too.

Revert the change for now so at least the old Xcode build system works.
Further investigation will be needed to add proper support for Xcode 9's
new build system.

Fixes: #17178

Merge-request: !1179

With MSVC the Ninja generator extracts the `cl -showIncludes` prefix.
When MSVC is configured to have non-English output, e.g. via
`VSLANG=2052` in the environment, then `cl` prints the prefix encoded
for the current code page, which is not necessarily UTF-8 encoding.
Currently we fail to convert the prefix to our internal UTF-8 encoding,
but assume it is UTF-8 later.

While writing `rules.ninja`, the Ninja generator converts our internal
UTF-8 encoding to the current code page.  The `msvc_deps_prefix =` line
needs to be encoded as the current code page so that `ninja` can match
in the output from `cl -showIncludes` during the build.

Prior to commit v3.9.0-rc1~47^2 (codecvt: Re-implement do_out and
do_unshift, 2017-05-25), the non-UTF-8 prefix extracted above was
written without noticing its incorrect internal encoding.  The
`rules.ninja` file was successfully written, but possibly with a mangled
`msvc_deps_prefix`.  Since that commit the output stream correctly
rejects the non-UTF-8 byte sequence and writing `rules.ninja` fails.

Fix this by correctly converting the `cl -showIncludes` output from the
current code page to our internal UTF-8 encoding.

Fixes: #17191

Merge-request: !1168