| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| |
| |
| |
| |
| |
| | |
9a0a94fdaa VS: Add variable to to turn off Visual Studio compile batching
a7ebb73929 Help: Improve formatting in VS_NO_COMPILE_BATCHING docs
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Merge-request: !7405
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Extend the change from commit b764c7c273 (VS: Add property to turn off
Visual Studio compile batching, 2022-02-07, v3.24.0-rc1~710^2) by
adding a variable to initialize the property on every target.
Issue: #23179
Fixes: #23639
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
07bc3b07ec gitlab-ci: test C++ modules using GCC
1b2270aa4e ci: add a Docker image to test out C++ modules with GCC
8c5a53096a Tests/RunCMake/CXXModules: add module-using examples
4151547e2f cmGlobalNinjaGenerator: use `cmModuleMapper` implementation
b43bdaff3c cmCxxModuleMapper: implement support for GCC's module map format
02d0f0e752 cmCxxModuleMapper: add source to handle module mapper contents
a046a45aad cmGlobalNinjaGenerator: add a TODO for header units
386465bf83 cmTarget: add support for C++ module fileset types
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !7369
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
C++ modules have two variants which are of importance to CMake:
- `CXX_MODULES`: interface modules (those using `export module M;`,
`export module M:part;`, or `module M:internal_part;`)
- `CXX_MODULE_HEADER_UNITS`: importable header units
Creating C++ modules or partitions are *not* supported in any other
source listing. This is because the source files must be installed (so
their scope matters), but not part of usage requirements (what it means
for a module source to be injected into a consumer is not clear at this
moment). Due to the way `FILE_SET` works with scopes, they are a perfect
fit as long as `INTERFACE` is not allowed (which it is not).
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
69beee5314 Add SYSTEM target property
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !7308
|
| |/
| |
| |
| |
| |
| |
| |
| | |
If it is ON, treat INTERFACE_INCLUDE_DIRECTORIES as system include directories.
Issue: #18040
Signed-off-by: Da Quexian <daquexian566@gmail.com>
|
|/ |
|
|
|
|
| |
Issue: #23448
|
|\
| |
| |
| |
| |
| |
| |
| |
| | |
76a08cd253 COMPILE_WARNING_AS_ERROR: Add options to treat warnings as errors
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Acked-by: Michael Hirsch <michael@scivision.dev>
Merge-request: !7187
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Add `COMPILE_WARNING_AS_ERROR` target property and supporting
`CMAKE_COMPILE_WARNING_AS_ERROR` variable.
`COMPILE_WARNING_AS_ERROR` is initialized by
`CMAKE_COMPILE_WARNING_AS_ERROR`. It is a boolean variable. If it is
true, it expands to a different flag depending on the compiler such that
any warnings at compile will be treated as errors.
Supports compiler ids that I could find a relevant flag for.
|
| |
| |
| |
| |
| |
| |
| |
| | |
Add a `CMAKE_WATCOM_RUNTIME_LIBRARY` variable to control the
runtime library selection. Add policy CMP0136 to switch to
in place of the old hard-coded default flags.
Fixes: #23178
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
This allows for new fileset types to be added more easily by factoring
out the declarative information into a structure.
|
| |
| |
| |
| |
| |
| | |
With new types being proposed for C++ modules, requiring filesets to be
of the right type is now pertinent. No tests can be added yet as only
`HEADERS` is supported right now.
|
| | |
|
| |
| |
| |
| | |
This avoids having to copy the `std::string` overload.
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
40dd46a96a Xcode: Add tests for OBJECT library per target `OSX_ARCHITECTURES`
da4ccb502b Xcode: Check for multiple `OSX_ARCHITECTURES` on target
41ba35a42b cmTarget: Add `HasKnownObjectFileLocation()` shorthand
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !7154
|
| |/
| |
| |
| |
| |
| |
| |
| | |
Allow `cmGlobalGenerator`s to decide `HasKnownObjectFileLocation()` per given
`cmTarget`
- `cmGlobalGenerator::HasKnownObjectFileLocation()` now takes an optional `cmGeneratorTarget`
- `cmTarget::HasKnownObjectFileLocation()` added as a shorthand
|
|\ \
| |/
|/|
| |
| |
| |
| |
| |
| | |
5fa15ec9f3 Help: Document that target_sources defines [INTERFACE_]HEADER_SETS
c5d4812f20 cmTarget: make HEADER_SETS and INTERFACE_HEADER_SETS read-only
05783b168d cmFileSet: store visibility with the fileset
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !7168
|
| |
| |
| |
| |
| |
| | |
There is no reason to allow these properties to be manipulated by user
code. Instead, use the stored visibility on the fileset objects to
derive what these properties should contain.
|
| |
| |
| |
| |
| | |
The visibility is intrinsic to the fileset, so store it with it. This
avoids recalculating it on every addition to the fileset.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Revert commit f3ad061858 (Add usage requirements to update direct link
dependencies, 2022-01-12, v3.23.0-rc1~44^2) and the property storage
updates in its predecessor commit 193a999cd5 (cmTarget: Add
INTERFACE_LINK_LIBRARIES_DIRECT{,_EXCLUDE} backtrace storage,
2022-01-06, v3.23.0-rc1~44^2~1) from the 3.23 release branch.
After initial experience using the feature in practice, additional
design considerations have been raised for discussion in the original
issue. To avoid rushing this for the 3.23 series, we've decided to
revert the feature for now so it can be revised for a future release.
Issue: #22496
|
| |\
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
83d79636bf install(TARGETS): Restore per-export INCLUDES DESTINATION
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !6969
|
| | |
| | |
| | |
| | | |
Fixes: #23338
|
| | |
| | |
| | |
| | | |
Fixes: #23121
|
|\ \ \
| | |/
| |/|
| | |
| | |
| | |
| | |
| | | |
83d79636bf install(TARGETS): Restore per-export INCLUDES DESTINATION
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !6969
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
In commit 55e4753bbb (Refactor cmTargetExport removing
InterfaceIncludeDirecories, 2021-07-20, v3.22.0-rc1~337^2~1) the storage
of `INCLUDES DESTINATION` was moved into each target. However, a target
may be installed in multiple exports, and their `INCLUDES DESTINATION`
should not be mixed.
Convert the IncludeDirectoriesEntries vector to a map and modify access
function to store the directories lists with respect to cmExportTarget
object. This fixes error when the same target is exported more than once
via different exports and each for consequent export its include
directories list grows. Add a test for this case.
Fixes: #23183
|
| |/
|/|
| |
| |
| |
| |
| |
| | |
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
|
| |
| |
| |
| | |
These properties will be given meaning by later commits.
|
| |
| |
| |
| | |
Fixes: #20698
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
0eea32a376 VS: Add DOTNET_SDK property to generate SDK-style C# projects
a450cc9533 VS: Set ResolveNugetPackages to false for ALL_BUILD and ZERO_CHECK
fa76e5d194 cmVisualStudio10TargetGenerator: Factor out helper for classic MSBuild project
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6634
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Changes in cmVisualStudio10TargetGenerator::Generate to write .Net
SDK-style project for VS generators VS 19 and above. Also adds
documentation and tests.
Issue: #20227
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Optionally verify that items in `LINK_LIBRARIES` and
`INTERFACE_LINK_LIBRARIES` that can be target names are actually target
names. Add a `LINK_LIBRARIES_ONLY_TARGETS` target property and
corresponding `CMAKE_LINK_LIBRARIES_ONLY_TARGETS` variable to enable
this new check.
Fixes: #22858
|
|/ / |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Logically revert commit 390a7d8647 (cmTargetPropertyComputer: Implement
GetProperty without cmMakefile, 2016-10-13, v3.8.0-rc1~445^2~9).
It relied on using `cmListFileBacktrace` to get a scope in which to
look up policies.
This does remove a backtrace from `LOCATION` property errors at generate
time, but the backtrace we reported before was incorrect. It pointed at
the addition of a target, not to the reference to the property.
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
0798edfb85 Tests: Xcode scheme ENABLE_GPU_FRAME_CAPTURE_MODE
e09a3eddb6 Xcode: Support "GPU Frame Capture" scheme property
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !6639
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Added XCODE_SCHEME_ENABLE_GPU_FRAME_CAPTURE_MODE variable which
sets the scheme property value for "GPU Frame Capture" in the Options section by setting the Xcode project variable "enableGPUFrameCaptureMode".
Example values are "Metal" (1) and "Disabled" (3).
XCODE_SCHEME_ENABLE_GPU_FRAME_CAPTURE_MODE is initialized by the property CMAKE_XCODE_SCHEME_ENABLE_GPU_FRAME_CAPTURE_MODE.
Implements: #22700
|
|/ |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Methods SetProperty of classes cmPropertyMap, cmStateDirectory
and cmMakefile accept now cmProp or std::string as argument.
|
|
|
|
|
|
| |
To handle safely the values used by CMake variables and properties,
introduce the class cmProp as a replacement from the simple pointer
to std::string instance.
|
|
|
|
|
|
|
|
| |
Because of this property in the cmTargetExport struct, exporting targets
is not uniform: top-level ones have to be dealt with via the
cmTargetExport objects, while all linked ones are cmGeneratorTarget
objects. Let's pass this additional includedirectories via a special
target property making handling exported targets uniform.
|
| |
|
|
|
|
| |
Fixes: #18316
|
|
|
|
|
|
|
|
| |
Printing paths to CMake input files does not need to use the
generator-wide relative path conversion rules because we are not
actually generating a relative path for the build system that needs to
be consistent with anything else. Instead, simply print a relative path
if it does not need to start in `../`, and otherwise an absolute path.
|
|
|
|
| |
The "Not" in the method name is backward from its logic.
|