1. 15 Jan, 2013 4 commits
  2. 10 Jan, 2013 6 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
      expressions.
      
      If 'the implementation is the interface', then the result of
      evaluating the expressions at generate time is used to populate
      the IMPORTED_LINK_INTERFACE_LIBRARIES property.
      
      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(libtwo
            $<$<STREQUAL:$<TARGET_PROPERTY:TYPE>,STATIC_LIBRARY>:libone>)
          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.
      77d26467
    • Stephen Kelly's avatar
      Fix linking to imported libraries test. · 93034a83
      Stephen Kelly authored
      Make a C executable instead of attempting to make a C++ static
      library (and not really succeeding). This was introduced in
      commit 894f52f3 (Handle INTERFACE properties transitively for
      includes and defines., 2012-09-23).
      93034a83
    • 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.
      3581b96c
    • Stephen Kelly's avatar
      Add the target_compile_definitions command. · fc61a7a7
      Stephen Kelly authored
      This is a convenience API to populate the corresponding properties.
      fc61a7a7
    • Stephen Kelly's avatar
      Add the target_include_directories command. · 8a37ebec
      Stephen Kelly authored
      This is a convenience API to populate the corresponding properties.
      8a37ebec
    • Stephen Kelly's avatar
  3. 08 Jan, 2013 3 commits
    • Stephen Kelly's avatar
      Add CMAKE_BUILD_INTERFACE_INCLUDES build-variable. · 9ce1b9ef
      Stephen Kelly authored
      This makes
      
       set(CMAKE_BUILD_INTERFACE_INCLUDES ON)
      
      add the equivalent of
      
       set_property(TARGET tgt APPEND PROPERTY
         INTERFACE_INCLUDE_DIRECTORIES
         $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR};${CMAKE_CURRENT_BINARY_DIR}>
       )
      
      to every target.
      
      If the headers are in CMAKE_CURRENT_SOURCE_DIR, and the generated headers
      are in CMAKE_CURRENT_BINARY_DIR, this is a convenient way to build a target
      bar, which depends on foo, just by using target_link_libraries() and adding
      the INTERFACE_INCLUDE_DIRECTORIES to the INCLUDE_DIRECTORIES of the target
      being linked. There will be more-convenient porcelain API to consume the
      property in the future.
      9ce1b9ef
    • Stephen Kelly's avatar
      Allow target_link_libraries with IMPORTED targets. · 9cfe4f1b
      Stephen Kelly authored
      This makes it possible to use:
      
       target_link_libraries(foo LINK_INTERFACE_LIBRARIES bar)
      
      where foo is an IMPORTED target. Other tll() signatures are not
      allowed.
      9cfe4f1b
    • 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.
      76538627
  4. 07 Jan, 2013 3 commits
  5. 04 Jan, 2013 3 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
      Add the TARGET_NAME generator expression. · b0c8f73e
      Stephen Kelly authored
      It will be used as a preprocessing marker.
      b0c8f73e
    • 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
  6. 03 Jan, 2013 5 commits
    • Stephen Kelly's avatar
      Tests: Fix warning about unused variable · b6346f25
      Stephen Kelly authored
      Resolve this warning:
      
       ".../Tests/CMakeCommands/target_link_libraries/depB.cpp", line 8: warning:
                variable "a" was declared but never referenced
          DepA a;
               ^
      b6346f25
    • Stephen Kelly's avatar
    • Stephen Kelly's avatar
      Keep track of INCLUDE_DIRECTORIES as a vector of structs. · 18a3195a
      Stephen Kelly authored
      The struct can keep track of where the include came from, which gives
      us proper backtraces.
      18a3195a
    • David Cole's avatar
      Add CTestLimitDashJ test (#12904) · e378ba5f
      David Cole authored
      Add a test that verifies that when ctest -j 4 is called, at most, 4 tests
      are executed at any one time.
      
      The test works by running the same script as each of 100 tests. And then setting
      up test properties for DEPENDS, RUN_SERIAL, PROCESSORS and COST in order to get
      the tests to run in a semi-deterministic ordering, even in parallel. The script
      writes a file, sleeps for a bit, and then deletes the file. In the meantime, it
      counts files that currently exist, and emits output that triggers a test failure
      if the count of files is ever greater than 4.
      
      Prior to the commit that fixed bug #12904, this would result in a failed test
      because the output of some of the tests would indicate that more than 4 tests
      were running simultaneously.
      
      Now that this issue is resolved, this test will help guarantee that it stays
      resolved moving forward.
      e378ba5f
    • Stephen Kelly's avatar
  7. 11 Dec, 2012 2 commits
    • Brad King's avatar
      OS X: Detect implicit linker framework search paths · cc676c3a
      Brad King authored
      Previously we hard-coded a list of implicit framework directories but
      did not account for CMAKE_OSX_SYSROOT or for changes to the list across
      OS X versions.  Instead we should automatically detect the framework
      directories for the active toolchain.
      
      The parent commit added the "-Wl,-v" option to ask "ld" to print its
      implicit directories.  It displays a block such as:
      
       Framework search paths:
      	/...
      
      Parse this block to extract the list of framework directories.
      
      Detection may fail on toolchains that do not list their framework
      directories, such as older OS X linkers.  Always treat the paths
      
       <sdk>/Library/Frameworks
       <sdk>/System/Library/Frameworks
       <sdk>/Network/Library/Frameworks # Older OS X only
       /System/Library/Frameworks
      
      as implicit.  Note that /System/Library/Frameworks should always be
      considered implicit so that frameworks CMake finds there will not
      override the SDK copies.
      cc676c3a
    • Brad King's avatar
      OS X: Detect implicit link directories on modern toolchains · 2dd67c7e
      Brad King authored
      We detect the implicit link directories for the toolchain by adding a
      flag to get verbose output from the compiler front-end while linking the
      ABI detection binary.  Newer OS X toolchains based on Clang do not add
      the implicit link directories with -L options to their internal
      invocation of "ld".  Instead they use a linker that comes with the
      toolchain and is already configured with the proper directories.
      
      Add the "-Wl,-v" option to ask "ld" to print its implicit directories.
      It displays them in a block such as:
      
       Library search paths:
      	/...
      
      Parse this block to extract the implicit link directories.
      
      While at it, remove the checks introduced by commit efaf335b (Skip
      implicit link information on Xcode, 2009-07-23) and commit 5195a664
      (Skip implicit link info for multiple OS X archs, 2009-09-22).  Discard
      the non-system link directories added by Xcode.  Discard all detected
      implicit libraries in the multi-architecture case but keep the
      directories.  The directories are still useful without the libraries
      just to suppress addition of explicit -L options for them.
      2dd67c7e
  8. 07 Dec, 2012 1 commit
    • Brad King's avatar
      Add policy CMP0019 to skip include/link variable re-expansion · 711b63f7
      Brad King authored
      Historically CMake has always expanded ${} variable references in the
      values given to include_directories(), link_directories(), and
      link_libraries().  This has been unnecessary since general ${}
      evaluation syntax was added to the language a LONG time ago, but has
      remained for compatibility with VERY early CMake versions.
      
      For a long time the re-expansion was a lightweight operation because it
      was only processed once at the directory level and the fast-path of
      cmMakefile::ExpandVariablesInString was usually taken because values did
      not have any '$' in them.  Then commit d899eb71 (Call
      ExpandVariablesInString for each target's INCLUDE_DIRECTORIES,
      2012-02-22) made the operation a bit heavier because the expansion is
      now needed on a per-target basis.  In the future we will support
      generator expressions in INCLUDE_DIRECTORIES with $<> syntax, so the
      fast-path in cmMakefile::ExpandVariablesInString will no longer be taken
      and re-expansion will be very expensive.
      
      Add policy CMP0019 to skip the re-expansion altogether in NEW behavior.
      In OLD behavior perform the expansion but improve the fast-path
      heuristic to match ${} but not $<>.  If the policy is not set then warn
      if expansion actually does anything.  We expect this to be encountered
      very rarely in practice.
      711b63f7
  9. 05 Dec, 2012 2 commits
  10. 03 Dec, 2012 1 commit
  11. 29 Nov, 2012 1 commit
    • David Cole's avatar
      Tests: Use the right path to CPack value for running CPack tests · 587b7b6f
      David Cole authored
      These tests were not running properly on Visual Studio or
      Xcode dashboards before this commit because of the "Debug"
      or "Release" sub-directory. The scripts already have
      CMAKE_CPACK_COMMAND since the correct CMake executable is
      used to run the scripts, so just use that, rather than
      passing down an incorrect path to the CPack executable.
      587b7b6f
  12. 28 Nov, 2012 1 commit
  13. 27 Nov, 2012 2 commits
  14. 26 Nov, 2012 1 commit
  15. 21 Nov, 2012 1 commit
  16. 16 Nov, 2012 1 commit
  17. 13 Nov, 2012 3 commits