| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When an object library is used via `target_link_libraries`, any targets
listed in the object library's `INTERFACE_LINK_LIBRARIES` closure should
become direct dependencies of the consuming target. However, these were
accidentally left out by `cmComputeTargetDepends::CollectTargetDepends`
because object libraries are encountered through external object sources
first and then added to the `emitted` set which blocks them from being
processed as link dependencies.
This was not noticed by the test case in commit bab24e782c
(target_link_libraries: Propagate dependencies of object libraries,
2018-12-10, v3.14.0-rc1~260^2) because the relevant dependency appears
transitively through the object library target itself.
Re-order the logic to process link dependencies first, and then external
object sources. That way object libraries used via
`target_link_libraries` will be treated as such by dependency analysis.
This also adds missing backtrace information for object libraries used
via `target_link_libraries`. The missing information was mentioned in a
FIXME comment in the RunCMake.FileAPI test added by commit ea0a060168
(fileapi: Add test for codemodel v2, 2018-11-09, v3.14.0-rc1~257^2~7).
That comment itself was dropped by commit a0de350e2f (FileAPI test:
Break gen_check_targets() into JSON files, 2020-02-07), but we can now
update the corresponding location in the `.json` files to have the
now-expected backtrace information.
Fixes: #20421
|
|
|
|
|
|
| |
Add the test case from commit bab24e782c (target_link_libraries:
Propagate dependencies of object libraries, 2018-12-10,
v3.14.0-rc1~260^2) to the main ObjectLibrary test.
|
|
|
|
|
| |
The geneator expression can now be used with static, shared, and
module libraries and executables.
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
This generator has been deprecated since CMake 3.6. Remove it.
|
|
|
|
|
|
|
|
| |
When `COMPILE_PDB_NAME` is used without `COMPILE_PDB_OUTPUT_DIRECTORY`
we cannot fall back on the link `PDB_OUTPUT_DIRECTORY` for an object
library because it has no link step.
Fixes: #16674
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
This generator has been deprecated since CMake 3.3. Remove it.
Update documentation, modules, and tests to drop content specific
to this generator.
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
The add_custom_command DEPENDS option needs a full path.
|
|
|
|
|
| |
We now have a generic way to add -fPIC without explicitly modifying
CMAKE_C_FLAGS, so use it.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A library or executable target that consists only of a reference to an
object library may have no sources to compile or custom commands to run.
The command in the target is the link (or archive) command. Add missing
order-only dependencies to link commands so that target ordering
dependencies are satisfied for it without depending on an intermediate
compilation rule.
Extend the ObjectLibrary test to cover this case.
Co-Author: Brad King <brad.king@kitware.com>
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
Setting include directories or compile definitions on a target created
with add_custom_target does not make sense.
|
|
|
|
|
|
|
|
| |
In commit b237dbd8 (Xcode: Fix object library references in
multi-project trees, 2012-08-03) we accidentally enabled CXX in the
subdiretories of this test by invoking project() with only one argument.
The top-level directory of the test enables only C, so do this in the
subdirectories too.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In cmGlobalXCodeGenerator::Generate we generate a .xcodeproj for each
directory in the tree containing a project() command. First we
iteratively use SetGenerationRoot to add "ALL_BUILD" and other targets
to each project. This leaves "CurrentProject" set to the last project
when we invoke cmGlobalGenerator::Generate, which is not the same as the
top-level project if any subdirectories invoke the project() command.
When cmGlobalGenerator::Generate reaches CreateGeneratorTargets it
constructs cmGeneratorTarget and calls ComputeTargetObjects exactly once
per target. In this context the value of CurrentProject is undefined so
we cannot pass it to GetObjectsNormalDirectory. Use "$(PROJECT_NAME)"
instead so it will adapt automatically to each project.
Also teach Tests/ObjectLibrary to cover this case.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Watcom compiler interprets "-DB" as option
-db generate browsing information
so define "A_DEF" and "B_DEF" instead of just "A" and "B".
Skip CMAKE_SHARED_LIBRARY_C_FLAGS for Watcom because it is set to
-bd build Dynamic link library
which adds a DLL entry point to each object.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reference OBJECT libraries for inclusion in targets that have no other
sources to verify that the linker language propagates correctly from the
object libraries. Test with a STATIC library, a SHARED library, and an
EXECUTABLE target. Use the static and shared libraries each in
executables that end up using the object library symbols.
In VS 6, 7, and 7.1 add a dummy object file to convince the IDE to build
the targets without sources. In Xcode add a dummy source file to
convince it to build targets without sources.
|
|
Add "ObjectLibrary" test to build and use OBJECT libraries. Build
multiple object libraries in separate directories with different flags.
Use a custom command to generate a source file in one OBJECT library.
Reference the OBJECT libraries for inclusion in a STATIC library, a
SHARED library, and an EXECUTABLE target. Use the static and shared
libraries each in executables that end up using the object library
symbols. Verify that object library symbols are exported from the
shared library.
|