1. 18 Mar, 2019 1 commit
  2. 26 Feb, 2019 1 commit
    • Brad King's avatar
      FindOctave: Remove module pending further work · 7a1f3fe0
      Brad King authored
      The `FindOctave` module added by commit 170bcb6f (FindOctave: Add
      module to find GNU octave, 2018-11-17, v3.14.0-rc1~283^2) has a few
      problems in its implementation that need to be worked out before the
      module can be included in a CMake release.  These were missed during
      review.  Remove the module for now.  It can be restored later with a
      fresh review.
      
      Issue: #18991
      7a1f3fe0
  3. 10 Jan, 2019 1 commit
  4. 19 Dec, 2018 1 commit
  5. 06 Dec, 2018 1 commit
  6. 14 Nov, 2018 1 commit
    • Kyle Edwards's avatar
      find_package(): Add policy to remove the FindQt module · 0f5c1b40
      Kyle Edwards authored
      Removing FindQt.cmake gives Qt upstream a path forward to export its
      own QtConfig.cmake files which can be found by find_package()
      without having to explicitly specify CONFIG. Projects that still
      want to use Qt3/4 can call find_package(Qt[34]), include(FindQt),
      or add FindQt.cmake to their CMAKE_MODULE_PATH.
      0f5c1b40
  7. 13 Nov, 2018 1 commit
    • Joachim Wuttke's avatar
      Help: Move deprecated modules to appropriate section. · df780bcc
      Joachim Wuttke authored
      Move deprecated or obsolete modules to the section
      "Deprectated Modules" of cmake-modules(7):
      
      - MacroAddFileDependencies (Text says: Using the macro
        MACRO_ADD_FILE_DEPENDENCIES() is discouraged.)
      - UsePkgConfig (Text calls it "obsolete")
      - Use_wxWindows (was already listed in deprecation section)
      df780bcc
  8. 11 Nov, 2018 1 commit
  9. 06 Nov, 2018 1 commit
  10. 18 Oct, 2018 1 commit
  11. 11 Oct, 2018 1 commit
  12. 09 Oct, 2018 2 commits
  13. 21 Jun, 2018 1 commit
    • Kyle Edwards's avatar
      Help: Move legacy CPack modules into separate section · 0180524c
      Kyle Edwards authored
      These modules are being moved out of user visibility and into an
      internal section of CMake. To keep them for historical reference in
      the manual, this commit moves them into a separate "Legacy CPack
      Modules" section.
      0180524c
  14. 22 May, 2018 1 commit
  15. 11 May, 2018 1 commit
    • Alex Turbov's avatar
      CPack: Add NuGet support · f739752a
      Alex Turbov authored
      Create a CPack generator that uses `nuget.exe` to create packages:
      
          https://docs.microsoft.com/en-us/nuget/what-is-nuget
      
      NuGet packages could be easily produced from a `*.nuspec` file (running
      `nuget pack` in the directory w/ the spec file).  The spec filename does
      not affect the result `*.nupkg` name -- only `id` and `version` elements
      of the spec are used (by NuGet).
      
      Some implementation details:
      
      * Minimize C++ code -- use CMake script do to the job. It just let the
        base class (`cmCPackGenerator`) to preinstall everything to a temp
        directory, render the spec file and run `nuget pack` in it, harvesting
        `*.nupkg` files...;
      
      * Ignore package name (and use default paths) prepared by the base class
        (only `CPACK_TEMPORARY_DIRECTORY` is important) -- final package
        filename is a responsibility of NuGet, so after generation just scan the
        temp directory for the result `*.nupkg` file(s) and update
        `packageFileNames` data-member of the generator;
      
      * The generator supports _all-in-one_ (default), _one-group-per-package_
        and _one-component-per-package_ modes.
      f739752a
  16. 20 Mar, 2018 1 commit
  17. 29 Nov, 2017 1 commit
  18. 16 Oct, 2017 1 commit
  19. 22 Sep, 2017 1 commit
  20. 01 Sep, 2017 1 commit
  21. 10 Jun, 2017 1 commit
    • Adriaan de Groot's avatar
      CPack-FreeBSD: add a generator for FreeBSD pkg(8) · 2042cae9
      Adriaan de Groot authored
      Adds an option CPACK_ENABLE_FREEBSD_PKG to allow CPack to look
      for FreeBSD's libpkg / pkg(8). If this is set and the libpkg
      headers and library are found (which they will be, by default,
      on any FreeBSD system), then add a FreeBSD pkg(8) generator.
      
      The FreeBSD package tool pkg(8) uses tar.xz files (.txz) with two
      metadata files embedded (+MANIFEST and +COMPACT_MANIFEST).
      This introduces a bunch of FreeBSD-specific CPACK_FREEBSD_PACKAGE_*
      variables for filling in the metadata; the Debian generator does
      something similar. Documentation for the CPack CMake-script is styled
      after the Debian generator.
      
      Implementation notes:
       - Checks for libpkg -- the underlying implementation for pkg(8) --
         and includes FreeBSD package-generation if building CMake on
         a UNIX host. Since libpkg can be used on BSDs, Linux and OSX,
         this potentially adds one more packaging format. In practice,
         this will only happen on FreeBSD and DragonflyBSD.
       - Copy-paste from cmCPackArchiveGenerator to special-case
         the metadata generation and to run around the internal
         archive generation: use libpkg instead.
       - Generating the metadata files is a little contrived.
       - Most of the validation logic for package settings is in
         CPackFreeBSD.cmake, as well as the code that tries to re-use
         packaging settings that may already be set up for Debian.
       - libpkg has its own notion of output filename, so we have
         another contrived bit of code that munges the output file
         list so that CPack can find the output.
       - Stick with C++98.
      2042cae9
  22. 16 May, 2017 1 commit
  23. 11 Mar, 2017 1 commit
  24. 01 Mar, 2017 1 commit
  25. 07 Feb, 2017 1 commit
    • Bradley Lowekamp's avatar
      GoogleTest: Add module to contain gtest_add_tests independently · 9837ed96
      Bradley Lowekamp authored
      Extract the `gtest_add_tests` macro from `FindGTest` into a separate
      module. GTest or GoogleTest can be used by a project in a several
      different ways, including installed libraries in the system, from an
      ExternalProject, or adding the GTest source directory as a sub directory
      of the project. As not all of these uses are supported by the FindGTest
      module the useful `gtest_add_tests` macro is separated to easily enable
      reuse.
      
      Issue: #14151
      9837ed96
  26. 11 Jan, 2017 1 commit
  27. 30 Sep, 2016 1 commit
  28. 13 Jul, 2016 1 commit
  29. 08 Jun, 2016 1 commit
  30. 03 Jun, 2016 1 commit
  31. 07 Mar, 2016 1 commit
  32. 20 Jan, 2016 1 commit
  33. 23 Mar, 2015 1 commit
  34. 20 Feb, 2015 1 commit
    • Brad King's avatar
      FindJsonCpp: Drop new module due to upstream jsoncpp providing package · a5768442
      Brad King authored
      Since jsoncpp 0.7.0 (2014-11-20) the upstream may provide a CMake
      package configuration file such that find_package(jsoncpp) will find a
      jsoncppConfig.cmake file.  In order to avoid conflicting with this
      (especially on case-insensitive filesystems), and since we always prefer
      projects to provide package config files (that they maintain), it is
      better to not provide FindJsonCpp publicly.
      
      Move FindJsonCpp into a private source directory that is not installed
      so that we can still use it for building CMake itself.
      Reported-by: Ryan Pavlik's avatarRyan Pavlik <ryan.pavlik@gmail.com>
      a5768442
  35. 05 Feb, 2015 1 commit
  36. 22 Jan, 2015 1 commit
    • Bill Hoffman's avatar
      CTestCoverageCollectGCOV: Add module to run gcov · f3e0b6f1
      Bill Hoffman authored
      Provide a function to run gcov and create a tarball of results.
      Since CDash tracks the md5sum of the files uploaded, use the
      --mtime option with "cmake -E tar" so that tar files could be
      created that would have the same md5sum with the same content.
      f3e0b6f1
  37. 19 Jan, 2015 1 commit
  38. 17 Dec, 2014 1 commit
  39. 04 Dec, 2014 1 commit