summaryrefslogtreecommitdiffstats
path: root/Help/command/target_link_libraries.rst
Commit message (Collapse)AuthorAgeFilesLines
* VS: Treat libraries ending in `.targets` as msbuild importsSoji Yamakawa2016-11-091-0/+5
| | | | | | | Generate `<Import Project="..." .../>` to import the `.targets` files into `.vcxproj` files. Closes: #16340
* Help: Clarify treatment of link flags in target_link_librariesJohn Beard2016-10-031-0/+6
|
* Link libraries by full path even in implicit directoriesBrad King2015-04-091-5/+11
| | | | | | | | | | | | | | | | | | | | | | 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.
* Help: Revise target_link_libraries command documentationBrad King2015-04-031-84/+124
| | | | | | 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.
* Help: Place relocatable package notes in their own subsectionsBrad King2015-04-031-3/+6
| | | | | | | 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.
* Help: Warn that paths should not be used in INTERFACE_ build properties.Stephen Kelly2014-11-251-0/+3
|
* Help: Clarify target_link_libraries treatment of flags (#15034)Brad King2014-07-281-1/+4
| | | | Explain that link flags should not be used in transitive contexts.
* Help: Mark up the buildsystem commands documentationStephen Kelly2014-02-061-86/+89
| | | | Cross-link to the cmake-buildsystem manual.
* Help: Use ``inline-literals`` to mark generator expressions.Stephen Kelly2014-02-061-1/+1
|
* CMP0022: Update target_link_libraries plain signature documentationBrad King2013-11-031-7/+10
| | | | | | 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.
* target_link_libraries(): Fix code snippet in documentation.Stephen Kelly2013-10-181-1/+2
| | | | The porting script seems to have made a mistake here.
* Help: Factor out cmake-generator-expressions manual pageBrad King2013-10-161-75/+2
| | | | | | | | | 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.
* Convert builtin help to reStructuredText source filesKitware Robot2013-10-151-0/+215
Run the convert-help.bash script to convert documentation: ./convert-help.bash "/path/to/CMake-build/bin" Then remove it.