| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
Update the change from commit 64690f6df0 (export: Do not fail generation
for namelink-only case, 2020-10-09, v3.19.0-rc1~7^2) to also handle
separate namelink-only and namelink-skip calls.
Fixes: #21529
|
| | |
|
| |
|
|
| |
Use 3.3 or 2.8.12 where possible.
|
| |
|
|
|
| |
When the build path is long with a space near the line length, a newline
is lost.
|
| |
|
|
|
|
|
|
|
|
| |
properties LINK_OPTIONS and INTERFACE_LINK_OPTIONS are propagated
to the device link step.
To control which options are selected for normal link and device link steps,
the $<DEVICE_LINK> and $<HOST_LINK> generator expressions can be used.
Fixes: #18265
|
| |
|
|
| |
Fixes: 20472
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CMake 3.16 and below allow multiple `export()` calls with the same output
file even without using `APPEND`. The implementation worked by accident
by leaking memory. Refactoring in commit 5444a8095d (cmGlobalGenerator:
modernize memrory managemenbt, 2019-12-29, v3.17.0-rc1~239^2) cleaned up
that memory leak and converted it to a use-after-free instead.
The problem is caused by using the `cmGlobalGenerator::BuildExportSets`
map to own `cmExportBuildFileGenerator` instances. It can own only
one instance per output FILE name at a time, so repeating use of the
same file now frees the old `cmExportBuildFileGenerator` instance
and leaves the pointer in the `cmMakefile::ExportBuildFileGenerators`
vector dangling. Move ownership of the instances into `cmMakefile`'s
vector since its entries are not replaced on a repeat output FILE.
In future work we should introduce a policy to error out on this case.
For now simply fix the use-after-free to restore CMake <= 3.16 behavior.
Fixes: #20469
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Refactoring in commit f5acecaa6f (cmExportCommand: Port to
cmArgumentParser, 2019-03-23, v3.15.0-rc1~270^2~3) broke the `export`
command's support for specifying `TARGETS` with no entries. Fix it and
add a test case.
Fixes: #19415
|
| | |
|
| |
|
|
| |
The added test verifies that a property listed in EXPORT_PROPERTIES
can be undefined. It confirms the crash recorded in issue #18260.
|
| |
|
|
|
|
|
|
|
| |
This change introduces an additional property that may be set on a
target to allow additional properties to be exported. Normally only a
limited number of properties are exported.
Additional properties may be exported by simply setting the
`EXPORT_PROPERTIES` property on a target that is exported.
|
| |
|
|
|
| |
Diagnose and reject custom targets given to the export() command
immediately. Previously we would generate an internal error later.
|
| | |
|
| |
|
|
|
|
| |
Teach the export command to handle export sets defined by invocations
of install(TARGETS ... EXPORT foo). This makes maintenance of targets
exported to both the build tree and install tree trivial.
|
|
|
Commit 66b290e7 (export(): Process the export() command at generate
time., 2012-10-06 ) refactored export() so that it could evaluate
strings at generate-time. This was intended for evaluating target
properties, but that commit also removed a check for target
existence at configure-time. Restore that check and add a test for
this case.
|
