summaryrefslogtreecommitdiffstats
path: root/Source/cmTarget.h
Commit message (Collapse)AuthorAgeFilesLines
...
* Merge topic 'INTERFACE_LIBRARY-target-type'Brad King2013-10-081-0/+1
|\ | | | | | | | | | | | | ce0c303 install: Teach EXPORT option to handle INTERFACE_LIBRARY targets 435c912 export: Add support for INTERFACE_LIBRARY targets fe73226 Add the INTERFACE_LIBRARY target type.
| * Add the INTERFACE_LIBRARY target type.Stephen Kelly2013-10-071-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This target type only contains INTERFACE_* properties, so it can be used as a structural node. The target-specific commands enforce that they may only be used with the INTERFACE keyword when used with INTERFACE_LIBRARY targets. The old-style target properties matching LINK_INTERFACE_LIBRARIES_<CONFIG> are always ignored for this target type. The name of the INTERFACE_LIBRARY must match a validity generator expression. The validity is similar to that of an ALIAS target, but with the additional restriction that it may not contain double colons. Double colons will carry the meaning of IMPORTED or ALIAS targets in CMake 2.8.13. An ALIAS target may be created for an INTERFACE library. At this point it can not be exported and does not appear in the buildsystem and project files are not created for them. That may be added as a feature in a later commit. The generators need some changes to handle the INTERFACE_LIBRARY targets returned by cmComputeLinkInterface::GetItems. The Ninja generator does not use that API, so it doesn't require changes related to that.
* | cmTarget: Properly escape @ char in doxygen commentsSean McBride2013-10-081-3/+3
|/ | | | Found by clang's -Wdocumentation.
* Genex: Disallow LINKER_LANGUAGE only when used on a static library.Stephen Kelly2013-07-261-0/+3
| | | | | For shared libraries and executables, the linker_language is indepenedent of the linked libraries.
* target_link_libraries: Add PUBLIC/PRIVATE/INTERFACE keyword signatureStephen Kelly2013-07-241-0/+8
| | | | | | | Add a new signature to help populate INTERFACE_LINK_LIBRARIES and LINK_LIBRARIES cleanly in a single call. Add policy CMP0023 to control whether the keyword signatures can be mixed with uses of the plain signatures on the same target.
* Merge topic 'drop-old-vs-dependency'Brad King2013-07-161-1/+1
|\ | | | | | | | | 4bb6e24 VS,Xcode: Drop incorrect legacy dependency trace (#14291)
| * VS,Xcode: Drop incorrect legacy dependency trace (#14291)Brad King2013-07-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Drop the "vsProjectFile" argument from cmTarget::TraceDependencies. It appears to be the modern equivalent to a hunk added in commit ba68f771 (...added new custom command support, 2003-06-03): + name = libName; + name += ".dsp.cmake"; + srcFilesToProcess.push(name); but was broken by refactoring at some point. The current behavior tries to trace dependencies on a source file named the same as a target, which makes no sense. Furthermore, in code of the form add_executable(foo foo.c) add_custom_command(OUTPUT "${somewhere}/foo" ... DEPENDS foo) the "vsProjectFile" value "foo" matches source "${somewhere}/foo.rule" generated to hold the custom command and causes the command to be added to the "foo" target incorrectly. Simply drop the incorrect source file trace and supporting logic.
* | Merge topic 'tid-system-argument'Brad King2013-07-161-0/+12
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | 9cf3547 Add the INTERFACE_SYSTEM_INCLUDE_DIRECTORIES target property. 1925cff Add a SYSTEM parameter to target_include_directories (#14180) 286f227 Extend the cmTargetPropCommandBase interface property handling. 83498d4 Store system include directories in the cmTarget. f1fcbe3 Add Target API to determine if an include is a system include. 2679a34 Remove unused variable.
| * | Add the INTERFACE_SYSTEM_INCLUDE_DIRECTORIES target property.Stephen Kelly2013-07-161-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | Unlike other target properties, this does not have a corresponding non-INTERFACE variant. This allows propagation of system attribute on include directories from link dependents.
| * | Store system include directories in the cmTarget.Stephen Kelly2013-07-021-0/+9
| |/ | | | | | | | | | | | | Entries from the cmMakefile are processed and maintained similarly to other include directories. The include_directories(SYSTEM) signature affects all following targets, and all prior targets in the same makefile.
* | Merge topic 'compile-defs-debugging'Brad King2013-07-151-1/+5
|\ \ | | | | | | | | | | | | | | | | | | | | | d7dd010 Add target property debugging for COMPILE_DEFINITIONS 1841215 Refactor cmTarget::GetCompileDefinitions to use an out-vector, not a string. afc9243 Add an overload of cmIDEOptions::AddDefines taking a vector of strings. d95651e Overload cmLocalGenerator::AppendDefines to add a list.
| * | Add target property debugging for COMPILE_DEFINITIONSStephen Kelly2013-07-121-0/+3
| | | | | | | | | | | | | | | | | | | | | Use constructs similar to those for COMPILE_OPTIONS. This is a little different because there is a command to remove_definitions(), so we can't populate the equivalent target property until generate-time in cmGlobalGenerator.
| * | Refactor cmTarget::GetCompileDefinitions to use an out-vector, not a string.Stephen Kelly2013-07-111-1/+2
| |/ | | | | | | Refactor to create AddCompileDefinitions.
* | Genex: Make CMP0021 and CMP0022 usable with TARGET_POLICYStephen Kelly2013-07-111-27/+19
| | | | | | | | | | | | Use preprocessor loops and add a unit test for the appropriate policies. All policies whose value is recorded at target creation time should be part of this list.
* | Introduce the INTERFACE_LINK_LIBRARIES property.Stephen Kelly2013-07-081-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This property replaces the properties which match (IMPORTED_)?LINK_INTERFACE_LIBRARIES(_<CONFIG>)?, and is enabled for IMPORTED targets, and for non-IMPORTED targets only with a policy. For static libraries, the INTERFACE_LINK_LIBRARIES property is also used as the source of transitive usage requirements content. Static libraries still require users to link to all entries in their LINK_LIBRARIES, but usage requirements such as INCLUDE_DIRECTORIES COMPILE_DEFINITIONS and COMPILE_OPTIONS can be restricted to only certain interface libraries. Because the INTERFACE_LINK_LIBRARIES property is populated unconditionally, we need to compare the evaluated result of it with the link implementation to determine whether to issue the policy warning for static libraries. For shared libraries, the policy warning is issued if the contents of the INTERFACE_LINK_LIBRARIES property differs from the contents of the relevant config-specific old LINK_INTERFACE_LIBRARIES property.
* | GenexEval: Add abstracted access to link interface for a target.Stephen Kelly2013-07-071-0/+3
|/ | | | | | This can be extended with special handling for static libraries so that we can process the link dependencies separately from the usage dependencies.
* Merge topic 'target-COMPILE_OPTIONS'Brad King2013-06-031-0/+6
|\ | | | | | | | | | | | | | | | | | | | | 24466f2 Add target_compile_options command. 80ca9c4 Add COMPILE_OPTIONS target property. 7cb2308 cmTarget: Rename LinkInterfaceIncludeDirectoriesEntries 47f80d9 cmTarget: Rename struct to be more re-usable. 1319a14 Add <LANG>_COMPILER_ID generator expressions. 3549676 Add cmLocalGenerator::GetCompileOptions. f3ad863 VS6: Rename some variables to correspond to config values.
| * Add target_compile_options command.Stephen Kelly2013-06-021-0/+2
| | | | | | | | This command populates the COMPILE_OPTIONS target property.
| * Add COMPILE_OPTIONS target property.Stephen Kelly2013-06-021-0/+4
| | | | | | | | | | | | This method reads generator expressions from the COMPILE_OPTIONS target property, as well as INTERFACE_COMPILE_OPTIONS from linked dependents.
* | Merge topic 'rpath-on-mac'Brad King2013-06-031-0/+9
|\ \ | | | | | | | | | | | | | | | | | | | | | dc1d025 OS X: Add test for rpaths on Mac. 8576b3f OS X: Add support for @rpath in export files. 00d71bd Xcode: Add rpath support in Xcode generator. 94e7fef OS X: Add RPATH support for Mac.
| * | OS X: Add RPATH support for Mac.Clinton Stimpson2013-06-031-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | RPATH support is activated on targets that have the MACOSX_RPATH property turned on. For install time, it is also useful to set INSTALL_RPATH to help find dependent libraries with an @rpath in their install name. Also adding detection of rpath conflicts when using frameworks.
* | | Merge topic 'framework-refactor'Brad King2013-06-031-13/+20
|\ \ \ | |/ / | | / | |/ |/| 373faae Refactor how bundles and frameworks are supported.
| * Refactor how bundles and frameworks are supported.Clinton Stimpson2013-05-231-13/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make handling of directory separators consistent between non-bundle and bundle code. Remove xcode specific flag from cmTarget when getting install_name. Add (more) consistent convenience functions in cmTarget to get directories inside of bundles and frameworks to add files to. This refactor also fixes bug #12263 where frameworks had the wrong install name when SKIP_BUILD_RPATH. Also make install_name for frameworks consistent between Makefile and Xcode generator.
* | Merge topic 'add-EXPORT_NAME-property'Brad King2013-05-221-0/+1
|\ \ | | | | | | | | | | | | b5d6f5d Add EXPORT_NAME property.
| * | Add EXPORT_NAME property.Stephen Kelly2013-05-181-0/+1
| | | | | | | | | | | | | | | | | | This allows for example, the buildsystem to use names like 'boost_any' instead of the overly generic 'any', and still be able to generate IMPORTED targets called 'boost::any'.
* | | Error on relative path in INCLUDE_DIRECTORIES target property.Stephen Kelly2013-05-211-0/+5
|/ / | | | | | | | | Add policy CMP0021 to preserve existing behavior in projects expecting it from earlier CMake versions.
* | Centralize maintenance of usage requirement include directoriesStephen Kelly2013-05-061-1/+0
|/ | | | | | Maintain a target's internal list of usage requirement include directories whenever the LINK_LIBRARIES property is set by either target_link_libraries or set_property.
* Fix the evaluation of per-config COMPILE_DEFINITIONS (#14037)Stephen Kelly2013-03-251-1/+1
| | | | | | | | | | | | | | The API for retrieving per-config COMPILE_DEFINITIONS has long existed because of the COMPILE_DEFINITIONS_<CONFIG> style properties. Ensure that the provided configuration being generated is also used to evaluate the generator expressions in cmTarget::GetCompileDefinitions. Both the generic COMPILE_DEFINITIONS and the config-specific variant need to be evaluated with the requested configuration. This has the side-effect that the COMPILE_DEFINITIONS does not need to be additionally evaluated with no configuration, so the callers can be cleaned up a bit too.
* Fix RPATH information when only a genex is used as a link library.Stephen Kelly2013-02-281-1/+1
| | | | | | | | As of commit 1da75022 (Don't include generator expressions in old-style link handling., 2012-12-23), such entries are not included in the LinkLibraries member. Generator expressions in LinkLibraries are not processed anyway, so port to the new way of getting link information.
* Use the link information as a source of compile definitions and includes.Stephen Kelly2013-02-131-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After evaluating the INTERFACE_INCLUDE_DIRECTORIES, of a target in a generator expression, also read the INTERFACE_INCLUDE_DIRECTORIES of its link interface dependencies. That means that code such as this will result in the 'user' target using /bar/include and /foo/include: add_library(foo ...) target_include_directories(foo INTERFACE /foo/include) add_library(bar ...) target_include_directories(bar INTERFACE /bar/include) target_link_libraries(bar LINK_PUBLIC foo) add_executable(user ...) target_include_directories(user PRIVATE $<TARGET_PROPERTY:bar,INTERFACE_INCLUDE_DIRECTORIES>) Also process the interface include directories from direct link dependencies for in-build targets. The situation is similar for the INTERFACE_COMPILE_DEFINITIONS. The include directories related code is currently more complex because we also need to store a backtrace at configure-time for the purpose of debugging includes. The compile definitions related code will use the same pattern in the future. This is not a change in behavior, as existing code has the same effect, but that existing code will be removed in follow-up commits.
* Rename the IncludeDirectoriesEntry to be more generic.Stephen Kelly2013-02-121-2/+2
|
* Don't keep track of content determined by target property values.Stephen Kelly2013-02-071-7/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | This tracking was added during the development of commit 042ecf04 (Add API to calculate link-interface-dependent bool properties or error., 2013-01-06), but was never used. It was not necessary to use the content because what is really useful in that logic is to determine if a property has been implied to be null by appearing in a LINK_LIBRARIES genex. I think the motivating usecase for developing the feature of keeping track of the targets relevant to a property was that I thought it would make it possible to allow requiring granular compatibility of interface properties only for targets which depended on the interface property. Eg: add_library(foo ...) add_library(bar ...) add_executable(user ...) # Read the INTERFACE_POSITION_INDEPENDENT_CODE from bar, but not # from foo: target_link_libraries(user foo $<$<TARGET_PROPERTY:POSTITION_INDEPENDENT_CODE>:bar>) This obviously doesn't make sense. We require that INTERFACE properties are consistent across all linked targets instead.
* Add includes and compile definitions with target_link_libraries.Stephen Kelly2013-01-311-3/+3
| | | | | | | | This establishes that linking is used to propagate usage-requirements between targets in CMake code. The use of the target_link_libraries command as the API for this is chosen because introducing a new command would introduce confusion due to multiple commands which differ only in a subtle way.
* Merge topic 'fix-automoc-compile-defs'Brad King2013-01-291-0/+2
|\ | | | | | | | | | | 429e369 Process COMPILE_DEFINITIONS as generator expressions in QtAutomoc. 0e10782 Move GetCompileDefinitions to cmTarget.
| * Move GetCompileDefinitions to cmTarget.Stephen Kelly2013-01-291-0/+2
| |
* | Add the COMPATIBLE_INTERFACE_STRING property.Stephen Kelly2013-01-241-0/+5
|/
* Merge topic 'clean-include-dirs-debugging'Brad King2013-01-231-0/+1
|\ | | | | | | | | | | | | | | 6063fef Output include directories as LOG messages, not warnings. aa66748 Specify the target whose includes are being listed. d70204a Only output includes once after the start of 'generate-time' when debugging. 0d46e9a Store includes from the same include_directories call together.
| * Only output includes once after the start of 'generate-time' when debugging.Stephen Kelly2013-01-211-0/+1
| | | | | | | | | | | | During configure-time, GetIncludeDirectories may be called too, for example if using the export() command. As the content can be different, it should be output each time then.
* | Merge topic 'qt4-autolink-qtmain'Brad King2013-01-231-0/+5
|\ \ | | | | | | | | | | | | | | | e3b5eb6 Automatically link to the qtmain library when linking to QtCore. 6c8d8af Add the $<TARGET_POLICY> expression
| * | Automatically link to the qtmain library when linking to QtCore.Stephen Kelly2013-01-231-0/+5
| |/ | | | | | | | | When using QAxServer, ensure that the qtmain library is excluded by reporting an error at CMake time if it is not.
* | Make INTERFACE determined properties readable in generator expressions.Stephen Kelly2013-01-201-0/+2
|/ | | | | The properties are evaluated as link-dependent interface properties when evaluating the generator expressions.
* Merge topic 'test-export-iface-genex'Brad King2013-01-151-0/+3
|\ | | | | | | | | | | | | | | | | | | | | | | | | 1d74ba2 Test evaluation target via export for generator expressions 522bdac Export the INTERFACE_PIC property. 4ee872c Make the BUILD_INTERFACE of export()ed targets work. 1d47cd9 Add a test for the interfaces in targets exported from the build tree. 6c828f9 Move the exported check for file existence. cfd4f0a Move the exported check for dependencies of targets d8fe1fc Only generate one check per missing target. f623d37 Don't write a comment in the export file without the code. b279f2b Strip consecutive semicolons when preprocessing genex strings.
| * Make the BUILD_INTERFACE of export()ed targets work.Stephen Kelly2013-01-151-0/+3
| | | | | | | | | | The existing BUILD_INTERFACE code is executed at generate time, which is too late for export().
* | Add a way to check INTERFACE user property compatibility.Stephen Kelly2013-01-151-0/+2
|/
* Allow generator expressions in LINK_INTERFACE_LIBRARIES.Stephen Kelly2013-01-101-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Config and IMPORTED_ variants may also contain generator expressions. If 'the implementation is the interface', then the result of evaluating the expressions at generate time is used to populate the IMPORTED_LINK_INTERFACE_LIBRARIES property. 1) In the case of non-static libraries, this is fine because the user still has the option to populate the LINK_INTERFACE_LIBRARIES with generator expressions if that is what is wanted. 2) In the case of static libraries, this prevents a footgun, enforcing that the interface and the implementation are really the same. Otherwise, the LINK_LIBRARIES could contain a generator expression which is evaluated with a different context at build time, and when used as an imported target. That would mean that the result of evaluating the INTERFACE_LINK_LIBRARIES property for a static library would not necessarily be the 'link implementation'. For example: add_library(libone STATIC libone.cpp) add_library(libtwo STATIC libtwo.cpp) add_library(libthree STATIC libthree.cpp) target_link_libraries(libtwo $<$<STREQUAL:$<TARGET_PROPERTY:TYPE>,STATIC_LIBRARY>:libone>) target_link_libraries(libthree libtwo) If the LINK_LIBRARIES content was simply copied to the IMPORTED_LINK_INTERFACE_LIBRARIES, then libthree links to libone, but executables linking to libthree will not link to libone. 3) As the 'implementation is the interface' concept is to be deprecated in the future anyway, this should be fine.
* Add API to calculate link-interface-dependent bool properties or error.Stephen Kelly2013-01-081-0/+3
| | | | | | | | This new method checks that the property FOO on a target is consistent with the INTERFACE_FOO properties of its dependees. If they are not the consistent, an error is reported. 'Consistent' means that iff the property is set, it must have the same boolean value as all other related properties.
* Keep track of properties used to determine linker libraries.Stephen Kelly2013-01-081-0/+10
| | | | | Those properties can't later be implicitly defined by the interface of those link libraries.
* Add LINK_LIBRARIES property for direct target link dependenciesStephen Kelly2013-01-081-0/+6
| | | | | | | | | | | | | | | | | | | Previously we kept direct link dependencies in OriginalLinkLibraries. The property exposes the information in the CMake language through the get/set_property commands. We preserve the OriginalLinkLibraries value internally to support old APIs like that for CMP0003's OLD behavior, but the property is now authoritative. This follows up from commit d5cf644a (Split link information processing into two steps, 2012-11-01). This will be used later to populate the link interface properties when exporting targets, and will later allow use of generator expressions when linking to libraries with target_link_libraries. Also make targets depend on the (config-specific) union of dependencies. CMake now allows linking to dependencies or not depending on the config. However, generated build systems are not all capable of processing config-specific dependencies, so the targets depend on the union of dependencies for all configs.
* Make linking APIs aware of 'head' targetStephen Kelly2013-01-081-12/+20
| | | | | | | | | | | The 'head' is the dependent target to be linked with the current target. It will be used to evaluate generator expressions with proper handling of mapped configurations and is used as the source target of properties. This requires that memoization is done with a key of a pair of target and config, instead of just config, because now the result also depends on the target. Removing the memoization entirely is not an option because it slows cmake down considerably.
* Use mapped config properties to evaluate $<CONFIG>Stephen Kelly2013-01-051-0/+5
|
generated by cgit v0.12 at 2024-10-31 18:16:00 (GMT)