1. 09 Jun, 2014 3 commits
  2. 08 Jun, 2014 1 commit
  3. 07 Jun, 2014 1 commit
  4. 06 Jun, 2014 3 commits
  5. 05 Jun, 2014 8 commits
  6. 04 Jun, 2014 6 commits
    • Brad King's avatar
      Allow a toolchain file to specify a generator toolset · 528e8af1
      Brad King authored
      Delay use of CMAKE_GENERATOR_TOOLSET until the CMakeSystem.cmake
      file has been configured and loaded during the first project() or
      enable_language() command.  This gives the toolchain file named by
      point is still early enough to set the generator toolset prior to
      the initialization of any languages that might use the toolset.
      The cmake::GeneratorToolset member variable remains an indication
      of what was specified by the -T option or loaded from the cache.
      It does not need to be updated based on the toolchain file setting.
      The cmMakefile::TryCompile can still pass cmake::GeneratorToolset
      into the inner instance because the try-compiled project will do
      platform and language initialization using the CMakeSystem module
      configured for the outer project.
      Extend the RunCMake.GeneratorToolset test with cases that use a
      toolchain file to set CMAKE_GENERATOR_TOOLSET.
    • Brad King's avatar
      VS: Split user- and generator-provided PlatformToolset · 98afb454
      Brad King authored
      Divide the cmGlobalVisualStudio10Generator "PlatformToolset" member into
      two members representing the generator-selected default toolset and the
      user-specified CMAKE_GENERATOR_TOOLSET value.  Prefer the user-specified
      value, if any, and then fall back to the generator-selected default.
    • Brad King's avatar
      Xcode: Rename internal variable {Platform => Generator}Toolset · 3e9f6e36
      Brad King authored
      The latter matches with CMAKE_GENERATOR_TOOLSET better.
    • Joe Snyder's avatar
      CTest: Generalize Cobertura coverage format handling · 50daf239
      Joe Snyder authored
      Add support for Cobertura coverage files written by Java.
      Add a test which uses the report from a Java run of Cobertura to calculate coverage.
      In the documentation of CTEST_COVERAGE_COMMAND, give a sample .sh file to merge
      the Cobertura .ser files and generate the XML report from the merged file.
    • Joe Snyder's avatar
      CTest: Rename coverage implementation for "Python" to "Cobertura" · a2822d30
      Joe Snyder authored
      The coverage.py tool writes out an XML that conforms to the Cobertura
      Coverage tool standard.  Rename the cmParsePythonCoverage files to
      instead be cmParseCoberturaCoverage.
    • Kitware Robot's avatar
      CMake Nightly Date Stamp · a1e742c3
      Kitware Robot authored
  7. 03 Jun, 2014 5 commits
  8. 02 Jun, 2014 1 commit
  9. 01 Jun, 2014 1 commit
  10. 31 May, 2014 2 commits
  11. 30 May, 2014 1 commit
  12. 29 May, 2014 2 commits
  13. 28 May, 2014 6 commits
    • Mark Salisbury's avatar
      VS: Use lower-case boolean values in VS 7-9 (#14927) · b684ce58
      Mark Salisbury authored and Brad King's avatar Brad King committed
      The VS 7-9 IDEs parse .vcproj file boolean values in lower or upper
      case.  The .NET XML parsing chokes on anything but "true", "false", "0",
      "1".  Teach our generators to use lower-case names since they will work
      for both parsers.  Our VS >= 10 flag tables already use lower-case.
    • Stephen Kelly's avatar
      add_custom_command: Normalize OUTPUT and DEPENDS paths. · c4af46b4
      Stephen Kelly authored
      While tracing dependencies of a target, cmTargetTraceDependencies
      follows sources by full path to determine if the source is to be
      produced by a custom command.  Commit 4959f341 (cmSourceFileLocation:
      Collapse full path for directory comparisons., 2014-03-27) changed
      the storage of target sources to be in the form of a normalized
      path instead of an unnormalized path.
      The path is followed by looking it up in a mapping via
      cmMakefile::GetSourceFileWithOutput to acquire an appropriate
      cmSourceFile.  The mapping is populated with the OUTPUT components
      of add_custom_command invocations, however it is populated with
      unnormalized paths.  This means that the tracing logic does not
      find appropriate cmSourceFiles, and does not generate appropriate
      build rules for the generated sources.
      Normalize the paths in the OUTPUT components of add_custom_command
      to resolve this.
      The paths in the DEPENDS component of add_custom_command are also
      not normalized, leading to the same problem again.  Normalize the
      depends paths after generator evaluation and expansion.
    • Nils Gladitz's avatar
      CPackWiX: Implement CPACK_NEVER_OVERWRITE and CPACK_PERMANENT properties · d0b1d2a6
      Nils Gladitz authored and Brad King's avatar Brad King committed
    • Nils Gladitz's avatar
      Add an "installed file" property scope · 15a8af21
      Nils Gladitz authored and Brad King's avatar Brad King committed
      Teach set_property and get_property an "INSTALL" property type to be
      associated with install-tree file paths.  Make the properties available
      to CPack for use during packaging.  Add a "prop_inst" Sphinx domain
      object type for documentation of such properties.
    • Zach's avatar
      CTest: Fix Python coverage.py off-by-one error in results · deee7c42
      Zach authored and Brad King's avatar Brad King committed
      The cobertura format uses line numbers indexed starting at 1, and CTest
      uses a vector indexed starting at 0 to store them.
    • Roni Choudhury's avatar
      CTest: Improve Python coverage.py source file search algorithm · 88b3dcb1
      Roni Choudhury authored and Brad King's avatar Brad King committed
      If the coverage.py source file is not found in the source directory, the
      build directory is first searched before raising an error.
      This is necessary because it is a valid workflow to build a Python
      package from source, then install this package to a virtualenv that
      lives in the build directory.  Tests will run against this deployed
      package and therefore the covered source files will be found in a
      subdirectory of the build directory, and not anywhere in the source