Linkers always use object files explicitly specified on the command line
regardless of where they appear. Move them to the front of the list of
linked libraries in so that symbols required by the object files can be
resolved by any library.
Issue: #22149
This change ony concerns directives that appear in the document body.
The guidelines for inserting version directives:
* Baseline version is CMake 3.0, i.e. directives start at 3.1.
* Always use `.. versionadded::` directive, avoid ad-hoc version
references. Exception: policy pages.
* For new command signatures, put `versionadded` on a separate line
after the signature.
* For a group of new signatures in a new document section,
a single version note at the beginning of the section is sufficient.
* For new options, put `versionadded` on a separate line before
option description.
* If all the option descriptions in the list are short one-liners,
it's fine to put `versionadded` on the same line as the description.
* If multiple option descriptions in close proximity would have
the same ..versionadded directive, consider adding a single
directive after the list, mentioning all added options.
* For compact value lists and sub-option lists, put a single
`versionadded` directive after the list mentioning all additions.
* When a change is described in a single paragraph, put
`versionadded` into that paragraph.
* When only part of the paragraph has changed, separate the changed
part if it doesn't break the flow. Otherwise, write a follow-up
clarification paragraph and apply version directive to that.
* When multiple version directives are close by, order earlier
additions before later additions.
* Indent related lists and code blocks to include them in the scope
of `versionadded` directive.
Issue: #19715
Items that have full paths will be quoted automatically. Other
items are treated as command-line string fragments and get no
automatic escaping. Document the behavior for each item kind.
Fixes: #18467
The `optimized` and `debug` keyword items are meaningful only to
the `target_link_libraries` command and have no meaning when
produced by a generator expression. State this explicitly.
Also recommend use of a quoted argument when the genex itself
may contain a semicolon.
Fixes: #18424
Previously the command did not allow naming targets on the LHS that
were not created in the calling directory. Lift this restriction to
enable more flexible use by projects.
Targets named on the RHS will need to be looked up during generation in
the scope of the call site rather than the scope of the LHS target.
Introduce an internal syntax in `[INTERFACE_]LINK_LIBRARIES` properties
to specify target names that need to be looked up in a directory other
than that containing the target on which the property is set. Add
minimal documentation of the syntax to help users that encounter it.
Unfortunately CMake previously did allow such calls in the case that
only `INTERFACE` libraries are specified, but those libraries would be
looked up in the target's directory rather than the caller's. Add
policy `CMP0079` to enable the new behavior with new lookup scope in a
compatible way.
Fixes: #17943
0d7114987c Revert "target_link_libraries: Allow use with targets in other directories"
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2191
Revert commit v3.12.0-rc1~82^2 (target_link_libraries: Allow use with
targets in other directories, 2018-05-11). The RHS target scoping and
visibility rules are not clear and will need further investigation
before the feature can be added.
Issue: #17943
This family enable to manage link flags
Three new properties:
* directory property: LINK_OPTIONS
* target properties: LINK_OPTIONS and INTERFACE_LINK_OPTIONS
Two new commands
* add_link_options(): to populate directory property
* target_link_options(): to populate target properties
Fixes: #16543
Previously the command did not allow naming targets on the LHS that
were not created in the calling directory. Lift this restriction to
enable more flexible use by projects.
Fixes: #17943
Now, several `INTERFACE_*` properties can be set on `IMPORTED` targets,
not only via `set_property` and `set_target_properties` but also via
`target_compile_definitions`, `target_compile_features`,
`target_compile_options`, `target_include_directories`, `target_sources`
and `target_link_libraries`.
Fixes: #15689
Issue: #17197
When CMP0003 was first introduced we wanted to link all libraries by
full path. However, some projects had problems on platforms where
find_library would find /usr/lib/libfoo.so when the project really
wanted to link to /usr/lib/<arch>/libfoo.so and had been working by
accident because pre-CMP0003 behavior used -lfoo to link.
We first tried to address that in commit v2.6.0~440 (Teach find_library
to avoid returning library paths in system directories, 2008-01-23) by
returning just "foo" for libraries in implicit link directories. This
caused problems for projects expecting find_library to always return a
full path. We ended up using the solution in commit v2.6.0~366 (...
switch library paths found in implicit link directories to use -l,
2008-01-31). However, the special case for libraries in implicit link
directories has also proven problematic and confusing.
Introduce policy CMP0060 to switch to linking all libraries by full path
even if they are in implicit link directories. Explain in the policy
documentation the factors that led to the original approach and now to
this approach.
Organize the documentation into subsections to separate the signatures.
Refactor the discussion of allowed link items into bullet points and
expand into more detail on each.
These notes apply only for the use case of creating a package for
redistribution on machines other than that where it is built. Clarify
this to readers by placing the discussion in dedicated sections titled
accordingly.
Make the documentation change made by commit ef10b87c (CMP0022: Plain
target_link_libraries must populate link interface, 2013-11-02) in the
new location for the same documentation.
Generator expressions are supported in many places and are a distinct
concept worthy of their own manual page. The old builtin documentation
was previously represented by preprocessor macros to generate it into
each place that supports them. Factor out the duplicate content into a
dedicated cmake-generator-expressions manual page and reference it from
each original location.
