| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|\
| |
| |
| | |
Merge-request: !3283
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
On macOS ranlib truncates the fractional part of the static achive
file modification time. If the archive and at least one contained
object file were created within the same second this will make look
the archive older than the object file. On subsequent ninja runs
this leads to re-achiving and updating dependent targets.
As a work-around we touch the archive after ranlib.
Closes: #19222
|
|\ \
| | |
| | |
| | | |
Merge-request: !3272
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When building for iOS, the compiled target is placed into a bundle.
If a single-configuration generator is used, like Makefiles or Ninja,
the try_compile FILE_COPY behavior fails to find the bundle, because
it only looks for the bundle inside a Debug subfolder (presumably
to support a multi-configuration generator like Xcode).
Consider looking for the bundle in the root try_compile folder, as
well as in the location specified by CMAKE_TRY_COMPILE_CONFIGURATION.
Closes: #19211
|
|\ \ \
| |/ /
|/| |
| | | |
Merge-request: !3276
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
In commit a1ad0a699b (target_link_libraries: Allow use with targets in
other directories, 2018-09-07, v3.13.0-rc1~94^2) we accidentally broke
the logic that adds `$<LINK_ONLY:...>` to private dependencies of static
libraries in their `INTERFACE_LINK_LIBRARIES` in the case that the
dependency is added from outside the directory creating the library.
The check for a valid target name should apply to the original name
specified by the caller and not the encoded cross-directory reference.
Fixes: #19197
|
| | | |
|
| |\ \
| | | |
| | | |
| | | | |
Merge-request: !2883
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This allows functions which enable AutoGen to make the version variables
available at generate time.
See: #18732
|
| |\ \ \
| | | | |
| | | | |
| | | | | |
Merge-request: !2878
|
| | |/ /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The `FRAMEWORK` target property affects the way the `install()` command
treats the target and so should be set first. Our implementation
assumed that this was always the case and led to an assertion failure.
Prior to CMake 3.12 this was visible only when using an explicit
`LIBRARY ... NAMELINK_ONLY` option, but commit 0212d7c762 (install: add
NAMELINK_COMPONENT argument, 2018-04-18, v3.12.0-rc1~139^2~3) made
it possible with a simple `LIBRARY DESTINATION`.
Fully supporting out-of-order specification will require non-trivial
refactoring to defer install generator creation to generate time.
For now simply restore the old behavior of installing the framework
to the library destination.
Fixes: #18848
|
| |\ \ \
| | | | |
| | | | |
| | | | | |
Merge-request: !2873
|
| |\ \ \ \
| | | | | |
| | | | | |
| | | | | | |
Merge-request: !2858
|
| | |_|/ /
| |/| | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Temporarily restore previous behavior that allowed specifying
no source or build directory to work, even though it was
neither documented nor supported. This commit is expected
to eventually be reverted to restore the fatal error for such
cases.
Relates: #18817
|
| | | | | |
|
| |_|_|/
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The value of `CMAKE_VS_PLATFORM_NAME` is computed by Visual Studio
generators based on `CMAKE_GENERATOR_PLATFORM` or some default.
Prior to the VS 2019 generator, the default was always `Win32`.
However, for the `Visual Studio 16 2019` generator, the default is
based on the host platform.
Store the default in a new `CMAKE_VS_PLATFORM_NAME_DEFAULT` variable for
use by project code. This is particularly useful in toolchain files
because they are allowed to set `CMAKE_GENERATOR_PLATFORM` and so
`CMAKE_VS_PLATFORM_NAME` is not yet known. Of course the toolchain file
author knows whether it will set `CMAKE_GENERATOR_PLATFORM`, and if not
then `CMAKE_VS_PLATFORM_NAME_DEFAULT` provides the platform name that
will be used.
Fixes: #19177
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | |
| | | | | |
Merge-request: !3217
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Since commit 9175a378f5 (QtDialog: Add windows taskbar progress,
2018-11-17, v3.14.0-rc1~330^2) we've added a missing overlay icon.
This results in Windows falling back to a default overlay icon.
Simply drop this line.
Fixes: #19160
|
|\ \ \ \ \
| | | | | |
| | | | | |
| | | | | | |
Merge-request: !3208
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
For `MACOSX_BUNDLE` targets we generate an `Info.plist` automatically
and add it to the sources presented to Xcode. Avoid mutating the
original target's list of sources to achieve this. Otherwise when we
generate the same target again (e.g. in a sub-project's Xcode file) it
will look different than the first time and possibly break invariants.
Fixes: #19114
|
| |/ / / / |
|
|/ / / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
In Qt 5.10 the theme support moved to a separate QWindowsVistaStyle
plugin.
Issue: #19147
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | |
| | | | | |
Merge-request: !3159
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The `cmLocalGenerator::GetIncludeDirectoriesImplicit` method is called
by `cmQtAutoGenInitializer` to get the compiler's list of implicit
include directories. Since commit 557b2d6e65 (Fix regression in
-I/usr/include exclusion logic, 2019-02-13, v3.14.0-rc2~6^2~2) the
method hard-codes exclusion of `/usr/include` for historical reasons.
However, it should not be reported as a real implicit include directory
unless the compiler really has it.
Refactor the logic to distinguish the hard-coded exclusion of
`/usr/include` from the real list of implicit include directories.
Fixes: #19100
|
|\ \ \ \ \
| |/ / / /
|/| | | |
| | | | | |
Merge-request: !3145
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Backport KWSys commit 92334e7670 (SystemTools: CopyFileAlways: avoid
copying file over self, 2019-03-25) to the CMake 3.14 release branch.
Fixes: #19075
|
|\ \ \ \ \
| | | | | |
| | | | | |
| | | | | | |
Merge-request: !3147
|
| |/ / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
When the current source file is not found the FilePath variable was left
with the previous path content. In case the previous file had less lines
than the current one and there are 'line' entries for the current one
with higher number we ended up in a buffer overflow while indexing the
previous file entry with a line number higher. By clearing the
FilePath, the empty() guard triggers correctly on an empty path and it
avoid modifying the wrong data.
|
|\ \ \ \ \
| | | | | |
| | | | | |
| | | | | | |
Merge-request: !3140
|
| |/ / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Any `include_directories()` calls in toolchain files are used during our
ABI detection step even though it does not include any system headers.
Since commit 5990ecb741 (Compute implicit include directories from
compiler output, 2018-12-07, v3.14.0-rc1~108^2), that check is also used
to detect implicit include directories. Any `include_directories()` in
a toolchain file are detected as implicit and later excluded from
explicit specification on compiler command lines, thus breaking the
purpose of the calls in the first place.
Fix the implicit include directory detection step to avoid using paths
from `include_directories()` calls in the toolchain file.
Fixes: #19079
|
|\ \ \ \ \
| | | | | |
| | | | | |
| | | | | | |
Merge-request: !3125
|
| |/ / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Do not process interface libraries in ways that expect build information
to be present internally. This filtering was left out of the extra
generator accidentally when interface libraries were introduced, but it
worked by accident until commit 76ad2ecb50 (Order SYSTEM include
directories after non-system directories, 2018-04-13, v3.12.0-rc1~179^2)
added a code path that was not tolerated.
Fixes: #18363
|
|\ \ \ \ \
| | | | | |
| | | | | |
| | | | | | |
Merge-request: !3105
|
| |/ / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Since commit c76c1ea208 (find_program: Consider CWD only for paths with
separator, 2018-05-31, v3.13.0-rc1~413^2) we accidentally convert the
leading `//` to just `/` on results with Windows network paths.
This was caused by `CollapseCombinedPath` being less robust than
`CollapseFullPath`. Restore use of the latter but in a way that
preserves the requirement of the above commit to support candidates that
are themselves absolute.
Fixes: #19049
Issue: #19050
|
|/ / / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
In commit 57e48f16f2 (VS: Add Visual Studio 16 2019 generator,
2019-01-09, v3.14.0-rc1~150^2) and commit 0fd742a6ff (VS: Teach VS 2019
generator to select host tools matching host arch, 2019-01-28,
v3.14.0-rc1~63^2) we intended to select the `x64` target architecture
and `x64` host tools by default on x64 host machines. Fix detection
of a x64 host when CMake itself is a 32-bit x86 process.
The KWSys SystemInformation `Is64Bits` member is not set correctly,
which led to this bug. Pending investigation on the KWSys side,
simply test ourselves via `IsWow64Process`.
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Revert commit da402a081b (VS: Use MSBuild matching toolset host
architecture, 2019-01-28, v3.14.0-rc1~50^2). Multiple people have
reported that the 64-bit `amd64/msbuild` tool fails in cases that the
32-bit `msbuild` works. Drop our change pending further investigation
and hopefully a fix to VS.
Fixes: #18904, #19037
Issue: #18219
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | |
| | | | | |
Merge-request: !3075
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Require the word "warning" to appear at the start of a line, after
whitespace, or after a `:`. This is the same that CTest launchers use
to match warnings. It avoids matching "warning" inside file paths.
Fixes: #19019
|
|\ \ \ \ \
| | | | | |
| | | | | |
| | | | | | |
Merge-request: !3071
|
| |/ / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Since commit e89ad0f94e (install: Allow installing targets created in
another directory, 2018-06-18, v3.13.0-rc1~407^2) the `install(TARGETS)`
command may find a global-scoped target outside the calling directory.
Ignore an `IMPORTED GLOBAL` target if it is found in this way. Imported
targets cannot be installed, and trying to do so violates internal
invariants.
Fixes: #19022
|
|\ \ \ \ \
| | | | | |
| | | | | |
| | | | | | |
Merge-request: !3065
|
| |/ / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Encode `\n` as ` ` to avoid generating a literal newline inside an
XML attribute. This is more readable and also fixes custom commands in
`.csproj` files with VS 2019 RC.
Fixes: #19001
|
|/ / / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The Intel Fortran `.vfproj` files do support both Fortran and the
Windows Resource compiler (`.rc)` files. Prior to CMake 3.9 we did not
support that, but commit 2c9f35789d (VS: Decide project type by linker
lang as fallback, 2017-03-30, v3.9.0-rc1~340^2) accidentally enabled it.
It was then broken by commit d3d2c3cd49 (VS: Fix Fortran target type
selection when linking C++ targets, 2019-02-04, v3.14.0-rc1~13^2).
Restore support for Fortran+RC in VS projects and add a test case.
Fixes: #19002
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | |
| | | | | |
Merge-request: !3039
|