1. 01 Nov, 2013 1 commit
    • Brad King's avatar
      Genex: Reject $<TARGET_FILE:...> for object libraries (#14532) · d9605897
      Brad King authored
      Teach the cmGeneratorExpressionEvaluator filesystem artifact logic
      to reject OBJECT_LIBRARY targets since they have no main artifact.
      Without the explicit rejection evaluation falls through to an
      internal CMake error message in cmTarget::GetOutputInfo.
      
      Extend the RunCMake.GeneratorExpression test to cover these cases.
      d9605897
  2. 27 Aug, 2013 1 commit
    • Stephen Kelly's avatar
      Genex: Fix evaluation of MAP_IMPORTED_CONFIG_<CONFIG> · 15d98a42
      Stephen Kelly authored
      Commit 10a069b5 (Genex: Fix $<CONFIG> with IMPORTED targets and
      multiple locations., 2013-07-15) changed the logic here to include
      handling of the MAP_IMPORTED_CONFIG_<CONFIG> target property, but
      it was buggy in several ways.
      
      Uppercase the configs in all cases, and compare the mapped configs
      with the parameter to the CONFIG genex, instead of with the key of
      the mapping.
      15d98a42
  3. 02 Aug, 2013 1 commit
    • Stephen Kelly's avatar
      Add the ALIAS target concept for libraries and executables. · 370bf554
      Stephen Kelly authored
      * The ALIAS name must match a validity regex.
      * Executables and libraries may be aliased.
      * An ALIAS acts immutable. It can not be used as the lhs
        of target_link_libraries or other commands.
      * An ALIAS can be used with add_custom_command, add_custom_target,
        and add_test in the same way regular targets can.
      * The target of an ALIAS can be retrieved with the ALIASED_TARGET
        target property.
      * An ALIAS does not appear in the generated buildsystem. It
        is kept separate from cmMakefile::Targets for that reason.
      * A target may have multiple aliases.
      * An ALIAS target may not itself have an alias.
      * An IMPORTED target may not have an alias.
      * An ALIAS may not be exported or imported.
      370bf554
  4. 26 Jul, 2013 1 commit
  5. 24 Jul, 2013 2 commits
  6. 16 Jul, 2013 1 commit
  7. 11 Jul, 2013 1 commit
  8. 07 Jul, 2013 2 commits
  9. 28 Jun, 2013 1 commit
  10. 24 Jun, 2013 3 commits
  11. 12 Jun, 2013 1 commit
  12. 11 Jun, 2013 1 commit
  13. 10 Jun, 2013 1 commit
  14. 05 Jun, 2013 1 commit
    • Stephen Kelly's avatar
      Genex: Fix the HEAD target used for evaluated expressions · 5b222354
      Stephen Kelly authored and Brad King's avatar Brad King committed
      If the expression $<TARGET_PROPERTY:prop> appears in the content
      of a target property, the target that prop is read from is
      the 'head target' of the expression. In contexts such as evaluating
      the content of a target property during generation, such
      as INCLUDE_DIRECTORIES, the 'head target' is the one on which the
      initial request was made.
      
      If evaluating a generator expression which is not a target property
      content, the target must be explicitly specified. Such contexts
      include add_custom_command and file(GENERATE). The content might
      then look like
      
       $<TARGET_PROPERTY:tgt,prop>
      
      However, as there is no HeadTarget set, any generator expressions
      evaluated as part of reading prop from tgt which do not specify
      the tgt directly report an error.
      
      Modify the logic of the TARGET_PROPERTY generator expression so
      that in such contexts, the 'head target' is set to the appropriate
      target which was first encountered.
      5b222354
  15. 02 Jun, 2013 2 commits
  16. 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
  17. 24 May, 2013 1 commit
  18. 17 May, 2013 1 commit
  19. 16 May, 2013 5 commits
  20. 12 Mar, 2013 1 commit
  21. 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
  22. 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
  23. 22 Feb, 2013 1 commit
  24. 18 Feb, 2013 1 commit
  25. 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
  26. 08 Feb, 2013 1 commit