summaryrefslogtreecommitdiffstats
path: root/Tests/RunCMake/ObjectLibrary/RunCMakeTest.cmake
Commit message (Collapse)AuthorAgeFilesLines
* Xcode: Add tests for OBJECT library per target `OSX_ARCHITECTURES`Hyper Nova Sun2022-04-121-0/+9
| | | | | | | | | | | | | | | | | 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
* add_library(): Allow imported object libraries with multi-archCraig Scott2021-02-061-1/+1
| | | Fixes: #21276
* Relax the usage of TARGET_OBJECTS generator expressionRobert Maynard2019-04-191-0/+5
| | | | | The geneator expression can now be used with static, shared, and module libraries and executables.
* target_link_libraries: Propagate dependencies of object librariesKyle Edwards2018-12-101-0/+1
| | | | | | | | | 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>
* Tests: Add cases for usage requirements of linked object libsBrad King2018-03-011-0/+2
| | | | | | | Add tests to cover transitive usage requirements on installation and export of targets that link to object libraries. Issue: #14778
* objlib: Link object-files from `OBJECT` libraries.Deniz Bahadir2018-03-011-0/+2
| | | | | | | | | | 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
* objlib: Allow `OBJECT` libraries to link to `OBJECT` libraries.Deniz Bahadir2018-03-011-0/+13
| | | | | | | | | | 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
* objlib: Allow other libraries to link to `OBJECT` libraries.Deniz Bahadir2018-03-011-2/+2
| | | | | | | | 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
* objlib: Allow `OBJECT` libraries to link to other libraries.Deniz Bahadir2018-03-011-1/+14
| | | | | | | | | | 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
* install,export: Maybe transform OBJECT libraries to INTERFACE librariesBrad King2018-02-281-2/+1
| | | | | | | | | | | 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.
* Diagnose object library self-referenceBrad King2017-07-141-0/+1
| | | | | | | | | | | | | | | | | | | 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
* Allow OBJECT libraries to be installed, exported, and importedRobert Maynard2017-04-181-3/+9
| | | | | | | | 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>
* Tests: Change RunCMake.ObjectLibrary dependencies case to CBrad King2017-02-261-2/+2
|
* Tests: Fix RunCMake.ObjectLibrary dependency delayBrad King2017-02-261-5/+11
| | | | | | Sleep before the second copy to avoid the need for a touch. Sleep for longer on generators whose build tools have low resolution timestamps.
* Add test for object library dependenciesGregor Jasny2017-02-221-0/+19
| | | | Issue: #16615
* Merge topic 'object-library-missing-source'Brad King2013-11-021-0/+1
|\ | | | | | | | | 5a2fc3d Check for OBJECT_LIBRARY source files at start of generation
| * Check for OBJECT_LIBRARY source files at start of generationBrad King2013-11-011-0/+1
| | | | | | | | | | | | | | Teach cmGlobalGenerator::CheckTargets to include OBJECT_LIBRARY targets in the check for source file existence. Extend the RunCMake.ObjectLibrary test to cover this case.
* | Make ExportLanguages a subtest of the ObjectLibrary testStephen Kelly2013-10-241-1/+0
|/ | | | | | 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.
* Test OBJECT library language propagationBrad King2012-03-161-0/+1
| | | | | | 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.
* Test OBJECT library failure casesBrad King2012-03-161-0/+17
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.
generated by cgit v0.12 at 2025-09-15 02:22:18 (GMT)