| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Update commit 1c15eb39d2 (Tests: Suppress failures on macOS arm64 due to
separate Xcode signing phase, 2021-02-22, v3.20.0-rc2~11^2) for Xcode 15,
which ignores our `-Xlinker -adhoc_codesign` flag, prioritizes its own
`-Xlinker -no_adhoc_codesign` flag, and does not add an ad-hoc signature
at link time.
Issue: #21845
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Added test to cover handling of when `CMAKE_OSX_ARCHITECTURES` differs from
OBJECT library target's `OSX_ARCHITECTURES`:
TargetOverrideSingleArch:
- When `CMAKE_OSX_ARCHITECTURES` is set to multiple archs,
- But OBJECT library's `OSX_ARCHITECTURES` is set to single
- Assert that OBJECT library target "`HasKnownObjectFileLocation`" and is
installable
TargetOverrideMultiArch:
- When `CMAKE_OSX_ARCHITECTURES` is set to single arch,
- But OBJECT library's `OSX_ARCHITECTURES` is set to multiple
- Assert that OBJECT library target does not "`HasKnownObjectFileLocation`"
and hence not installable
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since commit 2ae72ef74b (Xcode: Enable multi-arch TARGET_OBJECTS genex
in [INTERFACE_]LINK_LIBRARIES, 2021-05-26, v3.21.0-rc1~126^2) the
TARGET_OBJECTS genex, when referenced for linking, is now evaluated with
EvaluateForBuildsystem enabled. This causes the object file paths to be
computed with a buildsystem-specific placeholder for the configuration.
This is normally fine because the placeholder will be evaluated by the
native buildsystem tool using the proper configuration. However, the
Ninja Multi-Config generator's `${CONFIGURATION}` placeholder may not
have the correct value for cross-config object files. Switch back to
using the per-config location of each object file for this generator.
Fixes: #22436
|
| |\
| |
| |
| |
| |
| |
| | |
b84f1e6159 Autogen: Restore mocs_compilation in OBJECT libraries
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6024
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Since commit f65f20938c (Autogen: Avoid processing CSharp targets,
2020-11-12, v3.20.0-rc1~301^2) we collect all sources for a target
earlier than previously. Clear the sources cache so that it will be
re-computed later after AUTOGEN processing.
Fixes: #22085
|
| |/ |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some tests fail because Xcode runs `POST_BUILD` commands before signing
the binaries they run. Tell the linker to perform ad-hoc codesign even
though Xcode normally tells it not to.
Other tests fail because `install_name_tool` does not revise ad-hoc
signatures without the codesign `linker-signed` flag. Add that flag
ourselves where needed by our tests.
For now these changes help our test suite pass so we can use it to cover
everything else. Both of these cases may need further investigation to
update CMake to help projects in general.
Issue: #21845, #21854
|
| |
|
| |
Fixes: #21276
|
| |
|
|
|
| |
It was very easy to forgot to check against all language file
extensions. This updates the internal API to have a unified API.
|
| |
|
|
|
|
|
|
| |
Some RunCMake tests fail with this warning due to extra stderr content:
warning: this old-style function definition is not preceded by a prototype
Convert `foo()` to `foo(void)` in `.c` sources of affected tests.
|
| |
|
|
| |
Fixes: #20051
|
| |
|
|
|
|
|
|
| |
When linking to a shared library target that has version symlinks, add
an order-only dependency on the build statement that creates the links.
This ensures that the links exist for use at runtime.
Fixes: #19774
|
| |
|
|
|
|
|
| |
Following commit 49cfd390 (cmExportBuildFileGenerator: improve error
message, 2019-06-26), improve the error message related to installed
export sets by referencing the files which contain the exported target
ambiguously.
|
| | |
|
| |
|
|
|
| |
The geneator expression can now be used with static, shared, and
module libraries and executables.
|
| |
|
|
|
|
|
|
|
| |
Prior to this commit, linking against an object library did not
propagate private link dependencies of object libraries to their
consuming targets. This change implements the correct behavior.
Fixes: #18692
Co-Author: Brad King <brad.king@kitware.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Run the `clang-format.bash` script to update all our C and C++ code to a
new style defined by `.clang-format`. Use `clang-format` version 6.0.
* If you reached this commit for a line in `git blame`, re-run the blame
operation starting at the parent of this commit to see older history
for the content.
* See the parent commit for instructions to rebase a change across this
style transition commit.
|
| |
|
|
|
|
|
| |
Add tests to cover transitive usage requirements on installation and
export of targets that link to object libraries.
Issue: #14778
|
| |
|
|
|
|
|
|
|
|
| |
Note: This finally links the object-files of the `OBJECT` library from
the right-hand side of `target_link_libraries` to the target on the
left-hand side. However, this will only happen with directly linked
`OBJECT` libraries, not with `OBJECT` libraries "linked" through
property `INTERFACE_LINK_LIBRARIES` of a target on the right-hand side!
Fixes: #14778
|
| |
|
|
|
|
|
|
|
|
| |
Note: This still does not link the object-files of the `OBJECT` library
from the right-hand side of `target_link_libraries` to the target on the
left-hand side. (In this particular case of another `OBJECT` library on
the left-hand side this would not make any sense anyway. The target on
the left-hand side has no link-step.)
Issue: #14778
|
| |
|
|
|
|
|
|
| |
Note: This only allows `OBJECT` libraries to be on the right-hand side
of `target_link_libraries` but still does not link its object-files to
the target on the left-hand side.
Issue: #14778
|
| |
|
|
|
|
|
|
|
|
| |
The proper way to use libraries is now through `target_link_libraries`
for things such as usage requirements, compile definitions, include
directories, etc. To facilitate this, allow `OBJECT` libraries to "link"
to other libraries.
Co-Author: Ben Boeckel <ben.boeckel@kitware.com>
Issue: #14778
|
| |
|
|
|
|
|
|
|
|
|
| |
Teach the `install` and `export` commands to support installing and
exporting `OBJECT` libraries without their object files. Transform
them to `INTERFACE` libraries in such cases.
For `install(TARGETS)`, activate this when no destination for the object
files is specified. For `export`, activate this only under Xcode with
multiple architectures when we have no well-defined object file
locations to give to clients.
|
| |
|
|
|
| |
Some error-messages are slightly adjusted to better tell what
invocation would be correct instead. Tests are adjusted accordingly.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The code
add_library(A OBJECT a.c)
target_sources(A PRIVATE $<TARGET_OBJECTS:A>)
used to crash CMake via infinite recursion while evaluating the
generator expression. Then the change in commit v3.9.0-rc1~266^2~1
(cmGeneratorTarget: Replace source classifier implementation,
2017-04-07) avoided the infinite recursion because GetKindedSources now
creates a map entry and initializes it once. If it is called again on
the same target during that initialization, the partially computed
results are returned. This is still wrong but does not crash.
Detect and diagnose this case instead.
Co-Author: Ben Boeckel <ben.boeckel@kitware.com>
Fixes: #16578
|
| |
|
|
|
|
|
|
| |
Teach install() and export() to handle the actual object files.
Disallow this on Xcode with multiple architectures because it
still cannot be cleanly supported there.
Co-Author: Brad King <brad.king@kitware.com>
|
| | |
|
| |
|
|
|
|
| |
Sleep before the second copy to avoid the need for a touch.
Sleep for longer on generators whose build tools have low
resolution timestamps.
|
| |
|
|
| |
Issue: #16615
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Run the `Utilities/Scripts/clang-format.bash` script to update
all our C++ code to a new style defined by `.clang-format`.
Use `clang-format` version 3.8.
* If you reached this commit for a line in `git blame`, re-run the blame
operation starting at the parent of this commit to see older history
for the content.
* See the parent commit for instructions to rebase a change across this
style transition commit.
|
| |
|
|
|
|
|
|
|
|
|
| |
Loosen this restriction on OBJECT libraries to allow source files of any
name to be generated by custom commands or listed for reference in IDE
projects so long as they would not affect linking of a normal library.
Update the rejection message to be more specific about the looser
restriction.
Extend the ObjectLibrary test to cover a ".cmake" file generated by a
custom command in an OBJECT library.
|
| |
|
|
|
|
|
| |
Remove up-front object library computation from cmGlobalGenerator.
Adjust tests for message coming from the generator expression
evaluation.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove use of UseObjectLibraries from Makefile and Ninja generators. It
is not needed now because those generators use GetExternalObjects
which already contains the objects from object libraries.
The VS10 generator calls both the UseObjectLibraries and the GetExternalObjects
methods. Ensure that duplicates are not created by skipping objects
from object libraries in handling of GetExternalObjects.
Similarly, fix VS6, VS7 and Xcode object handling by skipping
external objects from OBJECT_LIBRARY usage as appropriate.
The error message in the BadSourceExpression1 test is now reported
by the generator expression evaluator, so it has different text.
|
| |\
| |
| |
| |
| | |
5a2fc3d Check for OBJECT_LIBRARY source files at start of generation
|
| | |
| |
| |
| |
| |
| |
| | |
Teach cmGlobalGenerator::CheckTargets to include OBJECT_LIBRARY targets
in the check for source file existence.
Extend the RunCMake.ObjectLibrary test to cover this case.
|
| |/
|
|
|
|
| |
It was a subtest of the RunCMake.ObjectLibrary test. However, we need
to test a build with ExternalProject after running CMake, which RunCMake tests
do not do.
|
| |
|
|
|
|
| |
Set the minimum required version of CMake high enough to avoid the
warning for CMAKE_LEGACY_CYGWIN_WIN32. The warning appears on stderr
and breaks the expected output matching.
|
| |
|
|
|
|
| |
Teach the RunCMake.ObjectLibrary test to verify that languages used in
an OBJECT library are propagated to targets that use it so that the
languages can be included in link analysis.
|
|
|
Add "RunCMake.ObjectLibrary" test to verify that unsupported use cases
are rejected with errors:
* An OBJECT library may not reference another object library
* An OBJECT library may not be referenced in target_link_libraries
* An OBJECT library may not contain non-compiling sources
* An OBJECT library may not have pre/post build/link commands
* An OBJECT library may not be installed, exported, or imported
Also verify that invalid $<TARGET_OBJECTS:...> expressions are
diagnosed.
|
