1. 25 Feb, 2013 1 commit
    • Stephen Kelly's avatar
      Revert "Add the TARGET_DEFINED generator expression" · cbf07569
      Stephen Kelly authored
      This reverts commit 2bee6f5b.
      
      This expression is not used, and has a semantic which is not completely
      optimal (namely considering utility targets to be targets, though
      usually we are interested in linkable targets).
      
      Remove it so that we have more freedom to define better expressions in
      the future.
      
      Conflicts:
              Source/cmGeneratorExpressionEvaluator.cxx
              Tests/CMakeCommands/target_compile_definitions/CMakeLists.txt
              Tests/CMakeCommands/target_compile_definitions/consumer.cpp
      cbf07569
  2. 13 Feb, 2013 3 commits
    • Stephen Kelly's avatar
      Revert "Add the $<LINKED:...> generator expression." · 3df36b59
      Stephen Kelly authored
      This reverts commit 0b92602b.
      
      Conflicts:
      	Source/cmGeneratorExpressionEvaluator.cxx
      	Tests/CMakeCommands/target_compile_definitions/CMakeLists.txt
      	Tests/CMakeCommands/target_include_directories/CMakeLists.txt
      3df36b59
    • Stephen Kelly's avatar
      567c8d10
    • Stephen Kelly's avatar
      Use the link information as a source of compile definitions and includes. · a1c4905f
      Stephen Kelly authored
      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.
      a1c4905f
  3. 08 Feb, 2013 1 commit
  4. 07 Feb, 2013 4 commits
    • Stephen Kelly's avatar
      Don't keep track of content determined by target property values. · d4e5c678
      Stephen Kelly authored
      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.
      d4e5c678
    • Stephen Kelly's avatar
    • Stephen Kelly's avatar
      Only use early evaluation termination for transitive properties. · 57175d55
      Stephen Kelly authored
      We need to make sure expressions which evaluate TARGET_PROPERTY:TYPE
      multiple times for example get the correct result each time, and
      not an empty string instead.
      57175d55
    • Stephen Kelly's avatar
      7c0ec75c
  5. 03 Feb, 2013 1 commit
    • Stephen Kelly's avatar
      Cache context-independent includes on evaluation. · e48d8420
      Stephen Kelly authored
      Generator expressions whose output depends on the configuration
      now record that fact. The GetIncludeDirectories method can use
      that result to cache the include directories for later calls.
      
      GetIncludeDirectories is called multiple times for a target
      for each configuration, so this should restore performance for
      multi-config generators.
      e48d8420
  6. 02 Feb, 2013 1 commit
    • Stephen Kelly's avatar
      Optimize genex evaluation for includes and defines. · 089fe1c1
      Stephen Kelly authored
      While porting boost to use these features, the generation step took
      too long (several minutes before I stopped it). The reason was that
      the boost libraries form a large interdependent mesh. The libraries
      list their dependencies in their INTERFACE such as:
      
       $<LINKED:boost::core>;$<LINKED:boost::config>;$<LINKED:boost::mpl>
      
      As boost::core already depends on the boost::config libraries, that
      expression has no impact on the end-content, as it is removed after
      the generation step. There is no DAG issue though, so the generator
      expression evaluation would fully evaluate them. In the case of the
      config library, it also depends on the core library, so all depends
      are followed through that again, despite the fact that they've just
      been evaluated. After this patch, the evaluation skips libraries if
      they have already been seen via depends or directly in the content.
      
      This patch keeps track of targets whose INTERFACE has been consumed
      already. The INCLUDE_DIRECTORIES and COMPILE_DEFINITIONS properties
      are whitelisted because repeated content will be stripped out later
      during generation. For other properties now and in the future, that
      may not be the case.
      089fe1c1
  7. 31 Jan, 2013 3 commits
  8. 27 Jan, 2013 1 commit
  9. 24 Jan, 2013 1 commit
  10. 23 Jan, 2013 1 commit
  11. 20 Jan, 2013 1 commit
  12. 17 Jan, 2013 1 commit
    • Stephen Kelly's avatar
      Add the $<TARGET_POLICY> expression · 6c8d8afe
      Stephen Kelly authored
      This new expression allows checking how a policy was set when a target
      was created.  That information is only recorded for a subset of policies,
      so a whitelist is used.
      6c8d8afe
  13. 13 Jan, 2013 1 commit
  14. 08 Jan, 2013 1 commit
  15. 04 Jan, 2013 7 commits
    • Stephen Kelly's avatar
      Handle INTERFACE properties transitively for includes and defines. · 894f52f3
      Stephen Kelly authored
      Contextually, the behavior is as if the properties content from another
      target is included in the string and then the result is evaluated.
      894f52f3
    • Stephen Kelly's avatar
      Make cycles in target properties ignored, not an error. · c67b8124
      Stephen Kelly authored
      Constructs such as these are an error as they are direct self-references:
      
       set_property(TARGET foo APPEND PROPERTY
         INCLUDE_DIRECTORIES $<TARGET_PROPERTY:foo,INCLUDE_DIRECTORIES>)
       set_property(TARGET foo APPEND PROPERTY
         INCLUDE_DIRECTORIES $<TARGET_PROPERTY:INCLUDE_DIRECTORIES>)
      
      However, this is an indirect self-reference in a cycle, and not an error:
      
       set_property(TARGET foo APPEND PROPERTY
         INCLUDE_DIRECTORIES $<TARGET_PROPERTY:bar,INCLUDE_DIRECTORIES>)
       set_property(TARGET bar APPEND PROPERTY
         INCLUDE_DIRECTORIES $<TARGET_PROPERTY:foo,INCLUDE_DIRECTORIES>)
      c67b8124
    • Stephen Kelly's avatar
      d0f950fd
    • Stephen Kelly's avatar
      Make all relevant targets available in the genex context. · 26def177
      Stephen Kelly authored
      The current node being evaluated transitively in the generator
      expression must be available to resolve mapped configs.
      26def177
    • Stephen Kelly's avatar
      Add the TARGET_NAME generator expression. · b0c8f73e
      Stephen Kelly authored
      It will be used as a preprocessing marker.
      b0c8f73e
    • Stephen Kelly's avatar
      77475fe6
    • Stephen Kelly's avatar
      GenEx: Add expressions to specify build- or install-only values · b2f1700b
      Stephen Kelly authored
      This is for specifying INCLUDE_DIRECTORIES relevant to the build-location
      or the install location for example:
      
       set_property(TARGET foo PROPERTY
         INTERFACE_INCLUDE_DIRECTORIES
         "$<BUILD_INTERFACE:${CMAKE_CURRENT_BINARY_DIR};${CMAKE_CURRENT_SOURCE_DIR}>"
         "$<INSTALL_INTERFACE:${CMAKE_INSTALL_PREFIX}/include>"
       )
      
      A 'bar' target can then use:
      
       set_property(TARGET bar PROPERTY
         INCLUDE_DIRECTORIES
         "$<TARGET_PROPERTY:foo,INTERFACE_INCLUDE_DIRECTORIES>"
       )
      
      and it will work whether foo is in the same project, or an imported target
      from an installation location, or an imported target from a build location
      generated by the export() command.
      
      Because the generator expressions are only evaluated at build-time, these
      new expressions are equivalent to the ZeroNode and OneNode.
      
      The GeneratorExpression test is split into parts. Some shells can't run
      the custom command as it is getting too long.
      b2f1700b
  16. 03 Jan, 2013 1 commit
  17. 23 Dec, 2012 1 commit
  18. 27 Nov, 2012 1 commit
  19. 26 Nov, 2012 1 commit
  20. 20 Nov, 2012 1 commit
  21. 05 Nov, 2012 1 commit
  22. 22 Oct, 2012 1 commit
  23. 11 Oct, 2012 1 commit
  24. 09 Oct, 2012 4 commits