1. 12 Jan, 2014 1 commit
  2. 11 Dec, 2013 1 commit
  3. 10 Dec, 2013 1 commit
    • Stephen Kelly's avatar
      Remove INTERFACE build targets. · 97fae68b
      Stephen Kelly authored
      Commit b04f3b9a (Create make rules for INTERFACE_LIBRARY
      targets., 2013-08-21) extended the makefile generator to create
      build targets for INTERFACE_LIBRARY targets. No other generators
      were extended with this feature.
      This conflicts with the feature of whitelisting of target properties
      read from INTERFACE_LIBRARY targets. The INTERFACE_* properties
      of the INTERFACE_LIBRARY may legitimately contain TARGET_PROPERTY
      generator expressions for reading properties from the 'head target'.
      The 'head target' would be the INTERFACE_LIBRARY itself when creating
      the build rules for it, which means that non-whitelisted properties
      would be read.
  4. 25 Nov, 2013 1 commit
    • Stephen Kelly's avatar
      INTERFACE_LIBRARY: Avoid codepaths which set unneeded properties. · 0bfcb450
      Stephen Kelly authored
      As an INTERFACE_LIBRARY has no direct link dependencies, we can
      short-circuit in cmGeneratorExpressionEvaluator and
      in cmGlobalGenerator::CheckLocalGenerators.
      As they do not generate any output directly, any generate- or install-
      related code acn also be short-circuited. Many of the local generators
      already do this.
      Because only INTERFACE related properties make sense on INTERFACE_LIBRARY
      targets, avoid setting other properties, for example via defaults.
  5. 21 Oct, 2013 1 commit
    • Stephen Kelly's avatar
      Create make rules for INTERFACE_LIBRARY targets. · b04f3b9a
      Stephen Kelly authored and Brad King's avatar Brad King committed
      The result is that the depends of the target are created.
       add_library(somelib foo.cpp)
       add_library(anotherlib EXCLUDE_FROM_ALL foo.cpp)
       add_library(extra EXCLUDE_FROM_ALL foo.cpp)
       target_link_libraries(anotherlib extra)
       add_library(iface INTERFACE)
       target_link_libraries(iface INTERFACE anotherlib)
      Executing 'make iface' will result in the anotherlib and extra targets
      being made.
      Adding a regular executable to the INTERFACE of an INTERFACE_LIBRARY
      will not result in the executable being built with 'make iface' because
      of the logic in cmComputeTargetDepends::AddTargetDepend.
      So far, this is implemented only for the Makefile generator. Other
      generators will follow if this feature is possible for them.
      Make INTERFACE_LIBRARY targets part of the all target by default.
      Test this by building the all target and making the expected library
  6. 02 Jul, 2013 1 commit
  7. 08 Jan, 2013 2 commits
    • Stephen Kelly's avatar
      Add LINK_LIBRARIES property for direct target link dependencies · 76538627
      Stephen Kelly authored and Brad King's avatar Brad King committed
      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.
    • Stephen Kelly's avatar
      Make linking APIs aware of 'head' target · 40cf3fb9
      Stephen Kelly authored and Brad King's avatar Brad King committed
      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.
  8. 03 Jan, 2013 1 commit
  9. 29 Feb, 2012 1 commit
  10. 02 Oct, 2011 1 commit
    • Nicolas Despres's avatar
      Refactor TargetTypeNames. · 3db2973b
      Nicolas Despres authored
      Make it a static method instead of an array. It is safer for the
      type checking and if we add a new target type we will be warned to add
      a case to the switch.
  11. 04 Aug, 2011 1 commit
  12. 19 Nov, 2010 1 commit
    • Brad King's avatar
      Allow add_dependencies() on imported targets (#10395) · e01cce28
      Brad King authored
      Imported targets do not themselves build, but we can follow dependencies
      through them to find real targets.  This allows imported targets to
      depend on custom targets that provide the underlying files at build
  13. 18 Nov, 2010 1 commit
  14. 25 Aug, 2010 3 commits
  15. 01 Oct, 2009 1 commit
  16. 28 Sep, 2009 1 commit
    • Brad King's avatar
      Convert CMake to OSI-approved BSD License · 96afb120
      Brad King authored
      This converts the CMake license to a pure 3-clause OSI-approved BSD
      License.  We drop the previous license clause requiring modified
      versions to be plainly marked.  We also update the CMake copyright to
      cover the full development time range.
  17. 24 Aug, 2009 1 commit
  18. 06 Aug, 2008 2 commits
    • Brad King's avatar
      BUG: Avoid bogus dependency on executable targets · d76b20bf
      Brad King authored
      When an executable target within the project is named in
      target_link_libraries for another target, but the executable does not
      have the ENABLE_EXPORTS property set, then the executable cannot really
      be linked.  This is probably a case where the user intends to link to a
      third-party library that happens to have the same name as an executable
      target in the project (or else will get an error at build time).  We
      need to avoid making the other target depend on the executable target
      incorrectly, since the executable may actually want to link to that
      target and this is not a circular depenency.
    • Brad King's avatar
      ENH: Improve readability of circular depends error · 37a009b7
      Brad King authored
      When reporting the dependencies in a strongly connected component quote
      the target names to make the message more readable no matter the target
  19. 07 Feb, 2008 1 commit
    • Brad King's avatar
      ENH: Improve link line generation for static library cycles. · 4987e17f
      Brad King authored
        - Move Tarjan algorithm from cmComputeTargetDepends
          into its own class cmComputeComponentGraph
        - Use cmComputeComponentGraph to identify the component DAG
          of link dependencies in cmComputeLinkDepends
        - Emit non-trivial component members more than once but always
          in a contiguous group on the link line
  20. 05 Feb, 2008 1 commit
    • Brad King's avatar
      ENH: Analyze inter-target dependencies to safely fix cycles · 523ddeda
      Brad King authored
        - Cycles may be formed among static libraries
        - Native build system should not have cycles in target deps
        - Create cmComputeTargetDepends to analyze dependencies
        - Identify conneced components and use them to fix deps
        - Diagnose cycles containing non-STATIC targets
        - Add debug mode property GLOBAL_DEPENDS_DEBUG_MODE
        - Use results in cmGlobalGenerator as target direct depends