Treat OBJECT libraries as STATIC libraries. The Xcode project file
format provides no way to avoid running the libtool so hide the
resulting .a away next to the object files as it should never be
referenced. The object files will be left behind for reference by other
targets later.
As discussed on cmake-developers, this patch adds a macro
check_required_components() to the file configured via
configure_package_config_file(), so for proper handling
of components in Config.cmake files users can simply call
check_required_components(PackageName)
and this will do the right thing.
Alex
if the HANDLE_COMPONENTS is used, FPHSA() now also checks all required COMPONENTS,
i.e. all elements from <name>_FIND_COMPONENTS for which <name>_FIND_REQUIRED_<comp>
is true, and sets <name>_FOUND only to true if all have been found.
As discussed on cmake-developers.
Alex
This patch adds documentation for OPTIONAL_COMPONENTS to cmFindPackage.cxx,
and also extends Modules/readme.txt significantly with regard to how
components should be handled.
Alex
Add an OPTIONAL_COMPONENTS keyword to find_package() so we can have a
clear distinction between required and optional components. Don't allow
a component to be both required and optional.
Alex
8485208 Ninja: shell escape $(CMAKE_SOURCE_DIR) and $(CMAKE_BINARY_DIR)
df84767 Ninja: add support for OBJECT_OUTPUTS, fix PrecompiledHeader test case
48eb7fc Ninja: Avoid using 'this' in member initializers
bba37dd Ninja: Fix for PDB files with spaces in the path.
ac800f4 Ninja: Constify use of cmCustomCommand
9a0d5a8 Ninja: add /DEF: flag to linker call
d40eebd Ninja: Add a cache option CMAKE_ENABLE_NINJA to enable the ninja generator.
8c63433 Ninja: Add friend struct so it can access the private ConvertToNinjaPath.
dbe3dce Ninja: add .def file support
f1bb08f Ninja: ensure the output dir exists at compile time
7a6b5f4 Ninja: Remove an unnecessary variable
80ff210 Ninja: Use cmSystemTools::ExpandListArgument to split compile/link commands
d2731a3 Ninja: Add a missed license header
eabc9b0 Ninja: CMake: Adapt Ninja generator for per-target include dirs
bada88e Merge branch 'target-include-directories' into ninja-generator
54bd175 Ninja: windows msvc: create for each target a .pdb file
...
For example, when CPACK_<GEN>_COMPONENT_INSTALL and
CPACK_MONOLITHIC_INSTALL are both set. Previously, this
combination of variable settings produced an error without
any explanation. Now, in this case CPACK_MONOLITHIC_INSTALL wins
without trouble.
This is useful for when e.g. CPACK_ARCHIVE_COMPONENT_INSTALL is
globally on and one wants MONOLITHIC install for STGZ (but not
other generators). The same behavior may be obtained by re-setting
CPACK_ARCHIVE_COMPONENT_INSTALL to 0 but in any case the
'both set' case should have been handled without error.
Necessary for the Xcode generator, in which the CMakeLists.txt
files are added as sources merely for convenient access, without
any associated custom command.
Implement cmGlobalGenerator::ComputeTargetObjects in the Ninja generator
to pre-compute all the object file names. Use the results during
generation instead of re-computing it later.
Describe the OBJECT library signature of add_library and the
$<TARGET_OBJECTS:...> expressions needed to use object libraries.
Also document the what is not allowed for object library targets.
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.
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.
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.
For now do not allow an OBJECT library to reference other object
libraries. Teach cmTarget::ComputeLinkImplementation to include the
languages of object libraries used by a target.
The write code introduced by commit 0b0d1b1d (add CMakeCache.txt
support, 2001-02-22) uses a temporary file but does not replace the
original atomically. Use cmGeneratedFileStream to do both
copy-if-different and atomic replacement.
Before, find_package in Config mode always set Foo_FOUND to true if the
Config file has been found and could be executed.
If the Config file itself detected some problem, like a missing dependency,
it did not have a way to signal to the outside that the package is not working.
With this patch, if a Config file sets Foo_FOUND to FALSE, this is taken into
account and not overridden.
Alex
Treat OBJECT libraries as STATIC libraries. The VS project file format
provides no way to avoid running the librarian so hide the resulting
.lib away next to the object files as it should never be referenced.
The object files will be left behind for reference by other targets
later.
This library type can compile sources to object files but does not link
or archive them. It will be useful to reference from executable and
normal library targets for direct inclusion of object files in them.
Diagnose and reject the following as errors:
* An OBJECT library may not be referenced in target_link_libraries.
* An OBJECT library may contain only compiling sources and supporting
headers and custom commands. Other source types that are not normally
ignored are not allowed.
* An OBJECT library may not have PRE_BUILD, PRE_LINK, or POST_BUILD
commands.
* An OBJECT library may not be installed, exported, or imported.
Some of these cases may be supported in the future but are not for now.
Teach the VS generator that OBJECT_LIBRARY targets are "linkable" just
like STATIC_LIBRARY targets for the LinkLibraryDependencies behavior.
On machines where a usr/bin/packagemaker symlink is found, we were
unable to find the version.plist file relative to the symlink.
Resolve the symlink first, so we can find it relative to the
real PackageMaker.