1. 30 May, 2013 3 commits
    • Stephen Kelly's avatar
      GenexEval: Fix evaluation of INCLUDE_DIRECTORIES target property. · 3aa9ce44
      Stephen Kelly authored
      This property should come from the content of the property itself,
      plus the INTERFACE_INCLUDE_DIRECTORIES of the link *implementation*.
      
      In contrast, when the INTERFACE_INCLUDE_DIRECTORIES is evaluated for
      a target, the INTERFACE_INCLUDE_DIRECTORIES of the link *interface*
      is used.
      
      Similar logic applies for the COMPILE_DEFINITIONS target properties.
      
      If the propertyName is already an INTERFACE_ variant of the property,
      ie, the expression is similar to
      
       $<TARGET_PROPERTY:foo,INTERFACE_INCLUDE_DIRECTORIES>
      
      then the INTERFACE_INCLUDE_DIRECTORIES of the link *interface* of foo
      is used.
      
      However, if the propertyName is not an INTERFACE_ variant, and the
      interfacePropertyName is, ie, the expression is similar to:
      
       $<TARGET_PROPERTY:foo,INCLUDE_DIRECTORIES>
      
      then the INTERFACE_INCLUDE_DIRECTORIES of the link *implementation*
      of foo is used.
      3aa9ce44
    • Stephen Kelly's avatar
      GenexEval: Extract a getLinkedTargetsContent from TargetPropertyNode. · 0b39fefe
      Stephen Kelly authored
      This will be used to process transitive components of properties
      which depend on linked targets. Currently only the link interface
      of the target can be used as the source of the linked targets, but
      in the next commit it will be possible to use the link implementation
      as the source of link targets.
      
      This commit does not change the semantics of the code.
      0b39fefe
    • Stephen Kelly's avatar
  2. 12 Mar, 2013 1 commit
  3. 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
  4. 23 Feb, 2013 2 commits
    • Stephen Kelly's avatar
      Expand includes and defines transitively in 'external' genexes. · 7e707444
      Stephen Kelly authored
      This means that we can use expressions of the form
      
       $<TARGET_PROPERTY:foo,INTERFACE_INCLUDE_DIRECTORIES>
      
      to get a list of the interface include directories of foo, including
      those coming from dependencies.
      
      We can't have a test of a target which has a single include directory in
      its INCLUDE_DIRECTORIES because the shell on the MSYS platforms transforms
      a single include directory to include a prefix, which is not what the test
      expects. We test a target with two directories instead as a means to
      test a target with no link dependencies.
      7e707444
    • Stephen Kelly's avatar
      Workaround broken code where a target has itself in its link iface. · e72eaadc
      Stephen Kelly authored
      There is a test for this since commit 8e756d2b (Tolerate cycles in
      shared library link interfaces (#12647), 2012-01-12), so make sure
      it continues to pass, even as we require no self-references in new
      INTERFACE_ property generator expressions.
      e72eaadc
  5. 22 Feb, 2013 1 commit
  6. 18 Feb, 2013 1 commit
  7. 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
  8. 08 Feb, 2013 1 commit
  9. 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
  10. 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
  11. 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
  12. 31 Jan, 2013 3 commits
  13. 27 Jan, 2013 1 commit
  14. 24 Jan, 2013 1 commit
  15. 23 Jan, 2013 1 commit
  16. 20 Jan, 2013 1 commit
  17. 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
  18. 13 Jan, 2013 1 commit
  19. 08 Jan, 2013 1 commit
  20. 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
  21. 03 Jan, 2013 1 commit
  22. 23 Dec, 2012 1 commit
  23. 27 Nov, 2012 1 commit
  24. 26 Nov, 2012 1 commit