1. 11 Apr, 2017 1 commit
    • Daniel Pfeifer's avatar
      Use quotes for non-system includes · 1d829c86
      Daniel Pfeifer authored
      Automate with:
      git grep -l '#include <cm_' -- Source \
        | xargs sed -i 's/#include <\(cm_.*\)>/#include "\1"/g'
      git grep -l '#include <cmsys/' -- Source \
        | xargs sed -i 's/#include <\(cmsys\/.*\)>/#include "\1"/g'
      git grep -l '#include <cm[A-Z]' -- Source \
        | xargs sed -i 's/#include <\(cm[A-Z].*\)>/#include "\1"/g'
  2. 27 Sep, 2016 1 commit
    • Brad King's avatar
      Simplify CMake per-source license notices · 86578ecc
      Brad King authored
      Per-source copyright/license notice headers that spell out copyright holder
      names and years are hard to maintain and often out-of-date or plain wrong.
      Precise contributor information is already maintained automatically by the
      version control tool.  Ultimately it is the receiver of a file who is
      responsible for determining its licensing status, and per-source notices are
      merely a convenience.  Therefore it is simpler and more accurate for
      each source to have a generic notice of the license name and references to
      more detailed information on copyright holders and full license terms.
      Our `Copyright.txt` file now contains a list of Contributors whose names
      appeared source-level copyright notices.  It also references version control
      history for more precise information.  Therefore we no longer need to spell
      out the list of Contributors in each source file notice.
      Replace CMake per-source copyright/license notice headers with a short
      description of the license and links to `Copyright.txt` and online information
      available from "https://cmake.org/licensing".  The online URL also handles
      cases of modules being copied out of our source into other projects, so we
      can drop our notices about replacing links with full license text.
      Run the `Utilities/Scripts/filter-notices.bash` script to perform the majority
      of the replacements mechanically.  Manually fix up shebang lines and trailing
      newlines in a few files.  Manually update the notices in a few files that the
      script does not handle.
  3. 16 Aug, 2016 1 commit
  4. 16 May, 2016 1 commit
    • Kitware Robot's avatar
      Revise C++ coding style using clang-format · d9fd2f54
      Kitware Robot authored
      Run the `Utilities/Scripts/clang-format.bash` script to update
      all our C++ code to a new style defined by `.clang-format`.
      Use `clang-format` version 3.8.
      * If you reached this commit for a line in `git blame`, re-run the blame
        operation starting at the parent of this commit to see older history
        for the content.
      * See the parent commit for instructions to rebase a change across this
        style transition commit.
  5. 18 Dec, 2015 1 commit
  6. 10 Feb, 2014 1 commit
    • Brad King's avatar
      cmVersion: Fix CMake_VERSION_ENCODE for date in patch level · d2059d25
      Brad King authored
      Use a uint64_t to store encoded version numbers so we have plenty of
      bits available.  Encode with room for up to 1000 minor releases between
      major releases and to encode dates until the year 10000 in the patch
      level.  This is necessary because CMake development versions prior to
      release 2.8.0 used the date in the patch level, and this practice may be
      restored after the 3.0 release.
  7. 23 Apr, 2010 1 commit
    • Brad King's avatar
      New version scheme to support branchy workflow · 5bfffd6f
      Brad King authored
      Prepare to switch to the workflow described by "git help workflows".  In
      this workflow, the "master" branch is always used to integrate topics
      ready for release.  Brand new work merges into a "next" branch instead.
      We need a new versioning scheme to work this way because the version on
      "master" must always increase.
      We no longer use an even/odd minor number to distinguish releases from
      development versions.  Since we still support cvs checkout of our source
      tree we cannot depend on "git describe" to compute a version number
      based on the history graph.  We can use the CCYYMMDD nightly date stamp
      to get a monotonically increasing version component.
      The new version format is "major.minor.patch.(tweak|date)".  Releases
      use a tweak level in the half-open range [0,20000000), which is smaller
      than any current or future date.  For tweak=0 we do not show the tweak
      component, leaving the format "major.minor.patch" for most releases.
      Development versions use date=CCYYMMDD for the tweak level.  The
      major.minor.patch part of development versions on "master" always
      matches the most recent release.
      For example, a first-parent traversal of "master" might see
              v2.8.1    v2.8.2
                 |              |              |
      Since the date appears in the tweak component, the next release can
      increment the patch level (or any more significant component) to be
      greater than any version leading to it.  Topic branches not ready for
      release are published only on "next" so we know that all versions on
      master lead between two releases.
  8. 01 Oct, 2009 1 commit
  9. 28 Sep, 2009 1 commit
    • Brad King's avatar
      Convert CMake to OSI-approved BSD License · 96afb120
      Brad King authored
      This converts the CMake license to a pure 3-clause OSI-approved BSD
      License.  We drop the previous license clause requiring modified
      versions to be plainly marked.  We also update the CMake copyright to
      cover the full development time range.
  10. 05 Mar, 2009 1 commit
    • Brad King's avatar
      ENH: Overhaul CMake version numbering · 98c51ff6
      Brad King authored
      This moves the version numbers into an isolated configured header so
      that not all of CMake needs to rebuild when the version changes.
      Previously we had spaces, dashes and/or the word 'patch' randomly chosen
      before the patch number.  Now we always report version numbers in the
      traditional format "<major>.<minor>.<patch>[-rc<rc>]".
      We still use odd minor numbers for development versions.  Now we also
      use the CCYYMMDD date as the patch number of development versions, thus
      allowing tests for exact CMake versions.
  11. 17 Jun, 2005 1 commit
  12. 22 Oct, 2004 1 commit
  13. 23 Oct, 2002 1 commit
  14. 21 Jan, 2002 1 commit
  15. 27 Apr, 2001 1 commit
  16. 23 Feb, 2001 1 commit
  17. 12 Feb, 2001 1 commit