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.
We frequently need to wipe out all the CMake test build directories in
order to run tests from scratch. This change adds a test_clean custom
target to remove all these directories for out-of-source builds.
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.