1. 26 Mar, 2013 1 commit
    • Stephen Kelly's avatar
      Report an error on IMPORTED targets with a faulty INTERFACE · 28051f11
      Stephen Kelly authored
      It is considered an error if the INTERFACE_INCLUDE_DIRECTORIES contains
      a directory which does not exist, which indicates a programmer error
      by the upstream, or a packaging error.
      One of the RunCMake.CompatibleInterface tests also needs to be updated
      due to this change. Non-existant includes were used in the test, but
      are not needed.
  2. 19 Mar, 2013 1 commit
  3. 16 Mar, 2013 1 commit
  4. 12 Mar, 2013 3 commits
    • Brad King's avatar
      Avoid crash when checking property compatibility without link info · ab079ee6
      Brad King authored
      Teach the compatibility check added by commit 042ecf04 (Add API to
      calculate link-interface-dependent bool properties or error, 2013-01-06)
      to return early if no link information is available.  This avoids
      crashing in a case that should fail with an error message.
    • Brad King's avatar
      Avoid crash when checking property link dependencies without link info · 92a2ab70
      Brad King authored
      Teach the isLinkDependentProperty helper added by commit e9879910 (Make
      INTERFACE determined properties readable in generator expressions,
      2013-01-19) to return early if no link information is available.
    • Petr Kmoch's avatar
      Documentation: Clarify a few subtleties · 3cf2f67a
      Petr Kmoch authored
      * Clarify accepted values of <LANG> suffix in CMAKE_COMPILER_IS_GNU<LANG>.
      * Clarify fact that target property GENERATOR_FILE_NAME usually cannot be
        used at configure time.
      * Clarify that enable_language() can only be used in global scope of
        top-level project using language.
      * State that enable_language(... OPTIONAL) currently doesn't work.
      * Document regular expression operator precedence.
  5. 06 Mar, 2013 1 commit
    • Stephen Kelly's avatar
      Only process transitive interface properties for valid target names. · 254687d3
      Stephen Kelly authored
      Commit a1c4905f (Use the link information as a source of compile
      definitions and includes., 2013-02-12) introduced the use of link
      information as the source of target properties via the TARGET_PROPERTY
      generator expression. This generator expression has a strict
      interpretation of a valid target name and emits a fatal error for
      invalid names.
      Ensure that only targets with names valid for use with TARGET_PROPERTY
      or targets which are determined by generator expressions are processed
      by it. This means that at worst, invalid target names do not participate
      in the transitive evaluation of properties, but the validation
      generator expression can be extended where needed to resolve that.
  6. 28 Feb, 2013 1 commit
  7. 24 Feb, 2013 1 commit
    • Stephen Kelly's avatar
      Memoize includes and defines from interface libraries. · 42ebb188
      Stephen Kelly authored
      This is similar in spirit to commit e48d8420 (Cache context-independent
      includes on evaluation., 2013-02-03), but it is needed since commit
      a1c4905f (Use the link information as a source of compile definitions
      and includes., 2013-02-12), which changed how includes and defines
      are determined. As they are now determined through the link interface,
      we need to cache the result of evaluating them through that.
      In the case of the includes, the result was already being cached
      and then immediately disposed. Store the result as a member variable
      instead to make use of the caching.
  8. 13 Feb, 2013 1 commit
    • 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
      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.
  9. 12 Feb, 2013 1 commit
  10. 08 Feb, 2013 2 commits
    • Stephen Kelly's avatar
    • Stephen Kelly's avatar
      Ensure that the build interface includes have been added. · 4de71786
      Stephen Kelly authored
      This is needed in the case that Automoc is used, as that calls
      GetIncludeDirectories, which may cache the resulting include dirs
      too early in the generate step.
      Also, because the automoc step is so early, we can't cache the
      include directories at that point. At that point the build interface
      of all dependencies are not populated yet, so we'd be caching the
      includes before appending the build interface. Only start caching
      when we're definitely generating the buildsystem. At that point, the
      includes should be stable.
      We still need to invoke AppendBuildInterfaceIncludes
      in the GlobalGenerator because the build interface includes affect
      mostly the dependencies of targets (such as the automoc targets),
      rather than the targets themselves, so the build interface needs
      to be appended for all targets before generation is done.
  11. 07 Feb, 2013 6 commits
  12. 05 Feb, 2013 1 commit
  13. 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.
  14. 29 Jan, 2013 1 commit
  15. 24 Jan, 2013 2 commits
  16. 23 Jan, 2013 1 commit
  17. 21 Jan, 2013 3 commits
  18. 20 Jan, 2013 2 commits
  19. 18 Jan, 2013 1 commit
  20. 16 Jan, 2013 1 commit
  21. 15 Jan, 2013 2 commits
  22. 13 Jan, 2013 1 commit
    • Stephen Kelly's avatar
      Don't include generator expressions in old-style link handling. · 1da75022
      Stephen Kelly authored
      Don't add generator expressions to variables which are used
      for CMP0003, CMP0004, and the old-style _LIB_DEPENDS content. They
      will not be evaluated when read anyway and would probably confuse
      the code reading them.
      This makes it legitimate to use target_link_libraries with generator
      expressions as arguments.
  23. 10 Jan, 2013 2 commits
    • Stephen Kelly's avatar
      Allow generator expressions in LINK_INTERFACE_LIBRARIES. · 77d26467
      Stephen Kelly authored
      The Config and IMPORTED_ variants may also contain generator
      If 'the implementation is the interface', then the result of
      evaluating the expressions at generate time is used to populate
      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(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.
    • Stephen Kelly's avatar
      Process the INTERFACE_PIC property from linked dependencies · 3581b96c
      Stephen Kelly authored
      This allows a dependee to inform a target that it should have its
      POSITION_INDEPENDENT_CODE property set to ON, or OFF. The value of
      the POSITION_INDEPENDENT_CODE property, if set, must be consistent
      with any INTERFACE_POSITION_INDEPENDENT_CODE properties on dependees.
      Add a test covering the consistency checks on platforms where they run.
  24. 08 Jan, 2013 3 commits
    • Stephen Kelly's avatar
      Add API to calculate link-interface-dependent bool properties or error. · 042ecf04
      Stephen Kelly authored
      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.
    • Stephen Kelly's avatar
      Keep track of properties used to determine linker libraries. · bf5ece51
      Stephen Kelly authored
      Those properties can't later be implicitly defined by the interface
      of those link libraries.
    • Stephen Kelly's avatar
      Add LINK_LIBRARIES property for direct target link dependencies · 76538627
      Stephen Kelly authored
      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.