1. 20 Feb, 2013 1 commit
  2. 18 Feb, 2013 1 commit
  3. 07 Feb, 2013 5 commits
    • Brad King's avatar
      Tests: Add generator toolset support · 56ca8d4e
      Brad King authored
      Propagate CMAKE_GENERATOR_TOOLSET through the test hierarchy so that all
      tests can build with the selected generator toolset, if any.
    • Brad King's avatar
      Tests: Consolidate ctest --build-and-test generator options · f36c665d
      Brad King authored
      All ctest --build-and-test invocations require the options
        --build-generator ${CMAKE_GENERATOR}
        --build-makeprogram ${CMAKE_TEST_MAKEPROGRAM}
      to be passed and have consistent values, except for a few special cases.
      Collect the generator options in a variable instead of repeating the
      options everywhere explicitly.
    • Brad King's avatar
      Xcode: Implement generator toolset selection (#9831, #13802) · f980a804
      Brad King authored
      Implement generator toolset selection (cmake -T) for Xcode > 2.0 by
      adding the GCC_VERSION build setting to project files.
    • Brad King's avatar
      VS: Implement generator toolset selection (#10722, #13774) · 650c6471
      Brad King authored
      Implement generator toolset selection (cmake -T) for VS >= 10 by setting
      the PlatformToolset.  Extend the RunCMake.GeneratorToolset test case to
      verify CMAKE_GENERATOR_TOOLSET when the generator supports -T.
      Since commit 485a940e (VS: Simplify MSVC version reporting, 2012-08-23)
      all MSVC version information is detected during the compiler id step
      from the actual compiler invoked by generated build systems rather than
      hard-coded in VS generators.  Therefore we can set the PlatformToolset
      in VS >= 10 project files and support toolsets from other VS versions.
    • Brad King's avatar
      CMake: Add -T option to choose a generator toolset · 4fd53429
      Brad King authored
      Reject the option by default.  It will be implemented on a per-generator
      basis.  Pass the setting into try_compile project generation.  Add cache
      entry CMAKE_GENERATOR_TOOLSET and associated variable documentation to
      hold the value persistently.
      Add a RunCMake.GeneratorToolset test to cover basic "-T" option cases.
      Verify that CMAKE_GENERATOR_TOOLSET is empty without -T, that -T is
      rejected when the generator doesn't support it, and that two -T options
      are always rejected.
  4. 06 Feb, 2013 1 commit
    • Brad King's avatar
      Normalize full paths in implicit link library list · 10e8b2da
      Brad King authored
      Teach CMakeParseImplicitLinkInfo to convert implicit link library full
      paths to a canonical form.  This makes them more reproducible in case
      different language compiler front-ends add the same library by different
      paths e.g. ".../libA.a" and "...//libA.a".
      Add a case to the CMake.ImplicitLinkInfo test to cover removal of extra
      slashes from both library and directory paths.
  5. 04 Feb, 2013 2 commits
    • Brad King's avatar
      Fix Module.ExternalData test on VS 6 · a6d3ffcb
      Brad King authored
      Run the test with the ctest --build-noclean option.  The test
      CMakeLists.txt file already uses file(REMOVE_RECURSE) to clean out
      downloaded data anyway.  Some file removed by "msdev ... /clean" causes
      CMake to re-run in the middle of the build step and file(REMOVE_RECURSE)
      wipes out already-generated files.
    • Brad King's avatar
      Fix Module.ExternalData test on Cygwin · aed590a7
      Brad King authored
      In ExternalData_URL_TEMPLATES add a leading slash to the path after
      file:// only if the path does not already start with one.
  6. 31 Jan, 2013 8 commits
  7. 30 Jan, 2013 5 commits
  8. 29 Jan, 2013 3 commits
  9. 27 Jan, 2013 1 commit
  10. 24 Jan, 2013 4 commits
  11. 23 Jan, 2013 1 commit
  12. 21 Jan, 2013 6 commits
    • Stephen Kelly's avatar
      Disallow porcelain to populate includes and defines of IMPORTED targets. · b98d14d4
      Stephen Kelly authored
      With similar reasoning to the parent commit, as downstreams, we can't
      determine what $<CONFIG> generator expressions would be appropriate.
      Upstream would have populated the INTERFACE_INCLUDE_DIRECTORIES with
      config-specific generator expressions, possibly appropriate for
      their DEBUG_CONFIGURATIONS. In theory, if we would add include
      directories for a DEBUG intent, we would have to match the upstream
      configurations for that.
      Rather than attempting to discover the appropriate configurations
      at this time, simplify the feature instead. The use of IMPORTED targets
      with these commands could still be added in the future if targets
      would export their DEBUG_CONFIGURATIONS somehow.
    • Stephen Kelly's avatar
      Revert "Allow target_link_libraries with IMPORTED targets." · 48a4cf21
      Stephen Kelly authored
      This reverts commit 9cfe4f1b.
      It turns out that correctly adding the content to
      the IMPORTED_LINK_INTERFACE_LIBARIES_<CONFIG> of an upstream target
      from the buildsystem of a downstream project is not simple.
      If upstream had added the INTERFACE content, the config-specific
      properties would  be determined by the DEBUG_CONFIGURATIONS of
      As downstream, we don't have any information about what
      the DEBUG_CONFIGURATIONS of upstream were, so we can't determine
      which configuration-specific properties to populate. The best we can do
      is add it to all of them or add it to the ones downstream considers to
      be DEBUG_CONFIGURATIONS, neither of which is a good solution.
      So, removing the porcelain API for that is the best approach. A human
      can still determine which properties to populate and use
      the set_property API to populate the desired properies.
      Another solution to this would be for upstream targets to publish
      what they consider DEBUG_CONFIGURATIONS, but that can be added in
      a future release.
    • Stephen Kelly's avatar
    • Stephen Kelly's avatar
    • Stephen Kelly's avatar
      Store includes from the same include_directories call together. · 0d46e9a0
      Stephen Kelly authored
      Otherwise, we get a separate IncludeDirectoriesEntry for each include,
      and that causes unnecessary and confusing splitting in the output when
      debugging the INCLUDE_DIRECTORIES property.
    • Stephen Kelly's avatar
  13. 20 Jan, 2013 1 commit
  14. 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.