| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
