| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
After b665966933 (cmComputeLinkInformation: track `OBJECT` library
dependencies, 2023-07-22), introduced in !8645 as a fix for #25112,
`OBJECT` libraries were tracked in a separate member to reduce the risk
of further regressions. This commit prepares consumers to handle
`OBJECT` libraries once they start appearing as link items.
|
| |
|
| |
|
|
|
|
| |
This generator has been deprecated since CMake 3.25. Remove it.
|
|
|
|
|
|
|
|
| |
When the build system re-runs `cmake` to regenerate itself, preserve the
`--compile-no-warning-as-error` option if it was used when `cmake` was
last explicitly invoked. Normally such settings are preserved in the
cache, but the purpose of this option is to be beyond the reach of
project code.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The VS generators add a custom command to `CMakeLists.txt` to re-run
CMake when input files have changed. Mark this custom command as if it
were specified with `USES_TERMINAL`. We already do this for the
equivalent `rebuild_cache` target in Makefile and Ninja generators.
This matters since commit d6353e74b4 (VS: Add policy to build custom
commands concurrently, 2023-03-10) because with policy CMP0147 set to
NEW, we now add `BuildInParallel` in `.vcxproj` file entries for custom
commands that do not have `USES_TERMINAL` set, but we do not want to
re-run CMake concurrently with other custom commands.
Issue: #18405
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Many custom commands are created by CMake itself rather than by
the user. These custom commands should always have their policies
set to NEW, and user-created custom commands should have their
policy values set only from the state snapshot. In addition, we
want to genericize the mechanism of recording a policy at the time
of custom command creation.
Add a CM_FOR_EACH_CUSTOM_COMMAND_POLICY macro to genericize
custom command policies. Use this to define all custom command
policies. Make all such policies NEW instead of WARN by default.
Remove individual policy modifier methods and add a single method
that records relevant values from a cmStateSnapshot. Remove the
no longer needed explicit policy settings from synthesized custom
commands.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Refactoring was done because EvaluateComment leaked memory.
|
|
|
|
|
|
| |
https://learn.microsoft.com/en-us/cpp/assembler/arm/arm-assembler-reference
Fixes: #23999
|
|
|
|
| |
This generator has been deprecated since CMake 3.22. Remove it.
|
|
|
|
| |
Fixes #22200
|
|
|
|
|
|
|
|
| |
This generator expression offers the capability, for the link step, to
decorate libraries with prefix/suffix flags and/or adding any specific flag for each
library.
Fixes: #22812, #18751, #20078, #22703
|
| |
|
|
|
|
|
|
| |
Move ProjectFileExtension handling logic to use ProjectType and remove
extraneous checks in .Net SDK style project generation. This change will
make introducing new project types relatively simpler.
|
|
|
|
|
|
|
|
|
| |
In commit dff98aa9ca (VS: add missing label in C# project-build events,
2021-12-15) the condition for adding our own `VCEnd` label was based on
the project being managed or not. Since we support managed C++
projects, switch the condition to be based on whether the project is C#.
Issue: #21440
|
|\
| |
| |
| |
| |
| |
| | |
dff98aa9ca VS: add missing label in C# project-build events
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6801
|
| | |
|
|/
|
|
|
|
|
| |
Store the main dependency as the first entry in the dependency list plus
a boolean member indicating its existence. Note that this slightly
changes existing behavior: the main dependency was previously the last
entry of the dependency list.
|
|\
| |
| |
| |
| |
| |
| | |
13a7ae2194 VS: Revert "Add missing label in C# project-build events"
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6781
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Revert commit b284a21fee (VS: Add missing label in C# project-build
events, 2021-09-03, v3.22.0-rc1~156^2). The change broke cases using
multiple successful custom commands. Revert it pending further
investigation into the interaction of the generated script code with
`Microsoft.Common.CurrentVersion.targets`, and whether this is needed
for all managed projects or just C# projects.
Also add a test covering the case that was broken.
Fixes: #22964
Issue: #21440
|
| | |
|
| | |
|
|/
|
|
| |
In applicable areas only, of course.
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| | |
f84193292c Use new AddCacheEntry signatures
3c2e58eeb8 AddCacheEntry accept cmProp or std::string
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6495
|
| | |
|
|/
|
|
| |
Fixes: #21440
|
|
|
|
| |
Use an enum to avoid implicit conversions to bool.
|
|
|
|
|
|
| |
Most calls to `MaybeConvertToRelativePath` use one of our common work
directories (e.g. top of the build tree) as the local path. Add helpers
for each of the common cases to simplify and clarify call sites.
|
| |
|
| |
|
|
|
|
| |
Fixes: #20201
|
|
|
|
|
| |
This reverts commit 9f060971411aca979807f70307d8b9fe1b43ff24.
It was merged accidentally.
|
|
|
|
| |
Fixes: #20201
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These were included when the Fortran flag table was first created by
commit 10c91ded4f (ENH: add support for Intel Fortran Visual studio IDE,
2008-04-30, v2.8.0~2227), but they map to fields not actually supported
by the IDE. Remove their table entries.
Instead use just `/debug:minimal` and `/debug:full` to control debug
information level in VS Intel Fortran. Let flags like `/Z7` pass
through as raw additional options because they have no corresponding IDE
property and can be used to complement the supported options.
Fixes: #21340
|
|\
| |
| |
| |
| |
| |
| | |
c1f1eaf7a4 VS: Teach CMAKE_MFC_FLAG to support generator expressions
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5283
|