`cmsys::SystemTools::SplitPath` will return empty segments on paths
where there's duplicaded consequent slashes (e.g. `/home/dir/my//stuff`).
This makes the cmFileWatcher choke. Teach cmFileMonitor to skip these
empty segments.
Closes: #16531
Since commit v3.7.0-rc1~142^2~1 (VS: Explicitly default to v100 toolset
in Visual Studio 2010, 2016-07-21) we prefer to always set a platform
toolset explicitly so that `CMAKE_VS_PLATFORM_TOOLSET` can be reported.
However, the `v100` default for the VS 10 generator is not appropriate
for all environments. We fixed support for VS 2010 Express Edition in
commit v3.7.0-rc1~142^2 (VS: Do not default to missing v100 64-bit
toolset on VS 2010 Express, 2016-09-09).
Fix support for the standalone Windows7.1SDK toolset environment by
recognizing the `PlatformToolset` environment variable that it sets to
`Windows7.1SDK` and using this as our default toolset instead.
Closes: #16483
The documentation of this option [1] claims that the default is off, but
VS seems to use `-Zc:inline` by default if `RemoveUnreferencedCodeData`
does not appear in the `.vcxproj` file. Add the flag table entry to
allow use of the flag to be configured.
[1] https://msdn.microsoft.com/en-us/library/dn642448.aspx
Suggested-by: Serti Ayoub <ayb.serti@gmail.com>
The negative form of the `-Zc:inline` flag is missing from
c:/Program Files (x86)/Microsoft Visual Studio/2017/Professional/Common7/IDE/VC/VCTargets/1033/cl.xml
so it was not included in our flag table automatically. Add it manually.
Suggested-by: Serti Ayoub <ayb.serti@gmail.com>
Revert commit v3.7.0-rc1~266^2 (Xcode: Obey SYSTEM keyword for includes,
2015-08-31). It worked for C, C++, and Swift but not for GNU Assembly
files for which Xcode has no property to set flags.
Closes: #16449
Refactoring in commit v3.6.0-rc1~134^2~10 (Autogen: Split out moc file
generation code to dedicated method, 2016-04-18) removed the
unconditional creation of the `<target>_automoc.cpp` file. Now it is
generated only when `AUTOMOC` is enabled. However, if this file is not
created then our internal `GenerateAll` setting is enabled on every
build, causing `AUTORCC` to re-generate its file(s) every time. Fix the
`GenerateAll` setting to be used only for when autogen settings change.
The old logic was left from when we had only automoc.
Closes: #16413
Catch more problematic input during handshake and report failure.
These were caught before when trying to configure, but it is way better
to get these reports early.
Change our message wrapper from
[== CMake Server ==[ ... ]== CMake Server ==]
to
[== "CMake Server" ==[ ... ]== "CMake Server" ==]
to guarantee that no JSON content can ever contain the ending string
(because it would be encoded as `]== \"CMake Server\" ==]`).
The targets added by commit v3.6.0-rc1~240^2~2 (Ninja: Add `$subdir/all`
targets, 2016-03-11) use as `$subdir` the relative path from the top of
the source tree to the current source directory. This is not correct
when using `add_subdirectory(test test_bin)`. Instead we need to use
the relative path from the top of the binary tree to the current binary
directory as was done for related targets by commit v3.7.0-rc1~268^2
(Ninja: Add `$subdir/{test,install,package}` targets, 2016-08-05).
Do not treat a pointer itself as a `uv_stream_t`, but instead the
pointed-to `uv_pipe_t`. It is unclear how this ever worked before in
local testing.
While at it, remove duplicate setup code and improve an error message.
The condition added by commit v2.8.12~179^2 (OS X: Fix regression
handling frameworks for Ninja, 2013-07-16) for excluding use of
versioning symlinks on macOS Frameworks must match that used for
POST_BUILD selection. Otherwise we place the POST_BUILD commands after
a symlink step that is never added.
Closes: #16363
Explicitly setting variable CMAKE_LINK_WHAT_YOU_USE or property
LINK_WHAT_YOU_USE to OFF should not cause LWYU to run. Fix the
property lookup to use GetPropertyAsBool.
In commit v3.7.0-rc1~275^2 (Ninja: Use full path for all source files,
2016-08-05), the source path was changed to use an absolute path.
Inside of `cmcldeps` for `.rc` file compilation, it uses a separate
argument for the path to the source file. This ended up causing
`cmcldeps` to transform the following call:
cmcldeps.exe RC source.rc ... C:/full/path/to/source.rc
into:
... C:/full/path/to//Tc source.rc
which is invalid. Update the source filename to use the full path to
the source file so that the path is replaced properly.
Refactoring in commit v3.7.0-rc1~291^2~1 (Refactor extra generator
registration to use factories, 2016-07-20) accidentally switched
the order of the "extra - base" generator names to "base - extra".
Switch it back. While this could affect all callers of the
`GetRegisteredGenerators` method, only cmake-gui actually used this
particular field.
Closes: #16359
In commit v3.7.0-rc1~156^2~1 (VS: Update v140 flag tables from VS 15
MSBuild files, 2016-09-02) we extended the v140 flag table with values
from the v141 toolset that comes with VS 15. However, the v140 toolset
that comes with VS 14 does not have all of these entries and so the
flags just need to be passed without special mapping. In order to
support both toolsets, split our CL flag table into separate copies for
each version and switch off the toolset name.
Closes: #16352
When a `PREBUILT_STATIC_LIBRARY` uses C++ in its sources then the `.a`
file will have a link-time dependency on the C++ runtime libraries.
Android NDK r14 will add a way to give this information to the NDK build
system by adding a `LOCAL_HAS_CPP` setting to the `Android.mk` file.
Add this for exported static libraries that use C++.
At generate-time, definitions are sometimes read from a nearby cmMakefile,
making the value directory-specific because they are read once per
directory. Often however, the intention is more
often to create a 'global' setting, such that the user writes for
example:
set(CMAKE_IMPORT_LIBRARY_SUFFIX something)
once at the top level of their project.
Many of these are also set by internal platform files, such as
CMAKE_EXTRA_LINK_EXTENSIONS.
The set() definitions are not really suitable for 'global' settings
because they can be different for each directory, and code consuming the
settings must assume they are different for each directory, and read it
freshly each time with new allocations.
CMake has other variable types which are global in scope, such as global
properties, and cache variables. These are less convenient to populate
for users, so establish a convention and API using the value as it is at
the end of the top-level CMakeLists file.