Recently we taught find_package that the NO_MODULE option is implied
when it is recursively invoked in a find-module. This behavior may be
confusing because two identical calls may enter different modes
depending on context. It also disallows the possibility that one
find-module defers to another find-module by changing CMAKE_MODULE_PATH
and recursively invoking find_package. This change reverts the feature.
We generate convenience rules to build object files, preprocessed
outputs, and assembly outputs of source files individually with make
rules. This removes a redundant working directory change when more than
one target builds the same source file.
Package version test files may now declare that they are unsuitable for
use with the project testing them. This is important when the version
being tested does not provide a compatible ABI with the project target
environment.
These changes teach find_package to behave nicely when invoked
recursively inside a find-module for the same package. The module will
never be recursively loaded again. Version arguments are automatically
forwarded.
In single-configuration generators a target installation rule should
apply to all configurations for which the INSTALL command was specified.
The configuration in which the target is built does not matter.
In multi-configuration generators each installation rule must be
associated with a particular build configuration to install the proper
file. The set of configurations for which rules are generated is the
intersection of the build configurations and those for which the INSTALL
command was specified.
In SharedForward, the call to execvp warned on MinGW because the
signature declared in process.h has an extra const. We use an explicit
cast to convert the pointer type.
To detect when the launcher is running from the build tree we now test
if the directory containing it is the same as the build-tree directory
using an inode test instead of string comparison. This makes it more
robust on case-insensitive filesystems and other quirky situations.
If the arguments to a command fail to parse correctly due to a syntax
error, the command should not be invoked. This avoids problems created
by processing of commands with bad arguments. Even though the build
system will not be generated, the command may affect files on disk that
persist across CMake runs.
We now properly report the source location of command arguments inside
macros instead of using the macro invocation site. No information is
lost because full call-stack information is already reported.
Previously error messages produced by parsing of command argument
variable references, such as bad $KEY{VAR} syntax or a bad escape
sequence, did not provide good context information. Errors parsing
arguments inside macro invocations gave no context at all. Furthermore,
some errors such as a missing close curly "${VAR" would be reported but
build files would still be generated.
These changes teach CMake to report errors with good context information
for all command argument parsing problems. Policy CMP0010 is introduced
so that existing projects that built despite such errors will continue
to work.
Automatic generation of 64-bit library search paths must preserve
trailing slashes. This fixes a failure case exposed by the recent
rewrite of find_library, which assumes trailing slashes occur on all
search paths.
OpenBSD shared libraries use a ".so.<major>.<minor>" extension and do
not have a symlink with just a ".so" extension. Its "ld" is capable of
finding the library with the best version. This change adds support for
finding such libraries. See issue #3470.
Previously we searched for library files by enumerating every possible
combination of prefix and suffix. Now we load (and cache) directory
content from disk and search for matching file names. This should
reduce disk access. It will also allow more advanced matching rules in
the future. See issue #3470.
Previously the cmGlobalGenerator::GetDirectoryContent method would work
safely only during build system generation. These changes make it safe
to use during each configure step by flushing it at the beginning.
When looking for NOTFOUND libraries, use the direct dependencies of a
target instead of all dependencies. At least one target will trigger
the NOTFOUND error anyway because at least one must directly link it.
This removes another use of the old-style link line computation.
In some cases it may be useful to compute a "link" line for a static
library even though it will not be put in the generated build system.
This removes the assertion which previously diallowed the case.
In cmComputeLinkInformation items in the final link line returned by
GetItems now contain a pointer to their corresponding cmTarget if they
were produced by a target. This makes available the set of all targets
linked.
In cmGlobalGenerator we use cmComputeTargetDepends to construct a safe,
non-circular set of inter-target dependencies. This change enables use
of the results by the Xcode generator. It also removes a lot of old
code and another use of the old-style linking logic. See issue #7652.
Provide VERSION_LESS, VERSION_EQUAL, and VERSION_GREATER operators in
the if() command. This simplifies component-wise comparison of version
numbers in the form "major[.minor[.patch[.tweak]]]".
Make the number of version components specified explicitly available.
Set variables for unspecified version components to "0" instead of
leaving them unset. This simplifies version number handling for find-
and config-modules. Also support a fourth "tweak" version component
since some packages use them.
Use the new-style error reporting mechanism to provide more context
information for a find_package call with a bad package name. When the
package is not required, issue a warning instead of an error.
The set_property command unsets a property if it is given no value. In
the case of GLOBAL properties, the cmake::SetProperty method would
replace a NULL value with "NOTFOUND". Instead it should be left as NULL
so that the property is unset as expected. Once it is unset the
get_cmake_property command will still report NOTFOUND while the
get_property command will return the empty string as documented.
When the -C or --build-config option is used to specify the
configuration to be tested by CTest, do not override it with the
configuration in which CTest is built.
A Mac OS X Framework should provide a Resources/Info.plist file
containing meta-data about the framework. This change generates a
default Info.plist for frameworks and provides an interface for users to
customize it.
This change cleans up the implementation of cmXCodeObject to avoid
un-escaping and re-escaping string values. There is no need to store
the string in escaped form. It can be escaped once when it is printed
out to the generated project file.
The recent fix to avoid including flags in dependency inferral also
dropped them from chaining of dependencies through targets. This fix
restores chaining of flags through known dependency lists while still
leaving them out of inferred dependency lists.
This change introduces a new algorithm for link line construction. The
order it computes always begins with the exact link line specified by
the user. Dependencies of items specified by the user are tracked, and
those that are not already satisified by the line are appended to it at
the end with minimal repeats. This restores the behavior of CMake 2.4
and below while still fixing some of its bugs. See issue #7546.
In cmComputeLinkDepends link items that look like flags (starting in
'-') should not be included in dependency inferral. They are not
libraries and therefore have no dependencies. They should just be
passed through to the final link line unchanged. See issue #7546.
This introduces the unset() command to make it easy to unset CMake
variables, environment variables, and CMake cache variables. Previously
it was not even possible to unset ENV or CACHE variables (as in
completely remove them). Changes based on patch from Philip Lowman.
See issue #7507.
Some native build tools, particularly those for cross compiling, may
have a limit on the length of the full path to an object file name that
is lower than the platform otherwise supports. This change allows the
limit to be set by the project toolchain file through the variable
CMAKE_OBJECT_PATH_MAX.
It is useful to be able to test if a target has been created. Often
targets are created only inside conditions. Rather than storing the
result of the condition manually for testing by other parts of the
project, it is much easier for the other parts to just test for the
target's existence. This will also be useful when find-modules start
reporting results with IMPORTED targets and projects want to test if a
certain target is available.
According to "man select" on Linux it is possible that select() lies
about data being ready on a pipe in some subtle cases. We deal with
this by switching to non-blocking i/o and checking for EAGAIN. See
issue #7180.
The LINK_INTERFACE_LIBRARIES target property may not contain the
"debug", "optimized", or "general" keywords. These keywords are
supported only by the target_link_libraries (and link_libraries) command
and are not a generic library list feature in CMake. When a user
attempts to add one of these keywords to the property value, we now
produce an error message that refers users to alternative means.
The LINK_INTERFACE_LIBRARIES property does not apply for STATIC
libraries. The IMPORTED_LINK_INTERFACE_LIBRARIES property does apply
for STATIC libraries. State both explicitly in the documentation.
Also, clarify that the per-configuration version of these properties
completely overrids the generic version.
The compatibility check to allow linking to modules should test for
CMake 2.2, not the unreleased 2.3. See issue #7500. Furthermore, the
message should be more clear about fixing the code instead of setting
CMAKE_BACKWARDS_COMPATIBILITY unless one is just trying to build an
existing project.
In the future some policies may be set to REQUIRED_IF_USED or
REQUIRED_ALWAYS. This change clarifies the error messages users receive
when violating the requirements.
When creating an IMPORTED target for a library that has been found on
disk, it may not be known whether the library is STATIC or SHARED.
However, the library may still be linked using the file found from disk.
Use of an IMPORTED target is still important to allow per-configuration
files to be specified for the library.
This change creates an UNKNOWN type for IMPORTED library targets. The
IMPORTED_LOCATION property (and its per-config equivalents) specifies
the location of the library. CMake makes no assumptions about the
library that cannot be inferred from the file on disk. This will help
projects and find-modules import targets found on disk or specified by
the user.
In switch statements that deal with only a few target types, use a
'default' case for the remaining target types instead of listing them
explicitly. This will make it easier to add more types in the future.
Rename the recently added INTERFACE mode of the target_link_libraries()
command to LINK_INTERFACE_LIBRARIES. This makes it much more distinct
from a normal call to the command, and clearly states its connection to
the property of the same name. Also require the option to appear
immediately after the target name to make it a mode rather than an
option.
Brad King
Alexander Neundorf
David Cole
Bill Hoffman