Create a CMAKE_USE_SYSTEM_LIBRHASH option.

Add it to a private source directory that is not installed so that we
can use it for building CMake itself.  This will allow it to mature
before being distributed publicly.

All clients of `cm_sha2` have been ported to `cmCryptoHash`, which now
uses librhash internally.

Avoid using KWSys MD5 or `cm_sha2` and use the `cmCryptoHash`
abstraction instead.

Offer direct construction with an enumeration of supported algorithms.
Also expose the Initialize/Append/Finalize steps publicly and add a
FinalizeHex method.

Use only the main `cmCryptoHash` interface.

Fix `rhash_md5_final` to use unsigned integers for left shifting to
avoid the possibility of undefined overflow behavior.

We cannot fall back to the macro implementation because some call sites
may call it with an argument like `*ptr++` that has side effects.

When we install using the bundled librhash source, notify users of its
license terms.

Add '-w' or equivalent flag on compilers supporting it.
Tell MSVC to use its lowest warning level inside librhash sources.

Update `ustd.h` to include KWSys Large File Support configuration so
that consistent stream libraries are used (on AIX with XL).

Add a `cm_rhash.h` header to include the CMake-provided copy of the
`rhash.h` header from CMake sources.

We only need a subset of the hash algorithms supported by librhash.
Add preprocessor conditionals to remove source fragments that we do
not need.  Write an alternative algorithm enumeration that matches
the indexing on our reduced array.

Also remove a few fragments outright.

* upstream-librhash:
  librhash 2016-11-01 (d839a1a8)

Kitware Robot authored 8 years ago and Brad King committed 8 years ago

Code extracted from:

    https://github.com/rhash/rhash.git

at commit d839a1a853f22b8cfd26c2006ee5481739ea1114 (master).

Brad King authored 8 years ago and Kitware Robot committed 8 years ago

ff3ccc1f FindHDF5: Restore pre-3.6 behavior of finding only C by default

Brad King authored 8 years ago and Kitware Robot committed 8 years ago

baead1e2 Encoding: Remove option to use ANSI code page internally

Brad King authored 8 years ago and Kitware Robot committed 8 years ago

9a8d758c Help: Document language standard meta-features
df252db1 Features: Test cycle diagnostic with language standard meta-feature
6d5fb0e0 Features: Test feature propagation with language standard meta-feature
a34b98a8 WCDH: Ignore language standard meta-features
b0996a3f Features: Add meta-features requesting awareness of a particular standard
8b6cc251 Features: Centralize per-compiler recording macros
2d23f7b2 Features: Do not record features on MSVC < 2010

Brad King authored 8 years ago and Kitware Robot committed 8 years ago

b902f2a9 Features: Fix Intel cxx_attributes existence condition

This condition needs to follow the same pattern added in note `[1]` by
commit a5a3642f (Features: Port Intel CXX features to test macros where
possible, 2016-10-26).  It was accidentally left out of that commit.

The switch to use UTF-8 encoding has been defaulted to on for quite some
time since commit v3.2.0-rc1~116^2 (Encoding: Switch to use UTF-8
internally by default on Windows, 2014-12-26).

The `cxx_static_assert` feature may be available in C++ 98 mode of some
compilers or not available at all in others.  Intstead of using an
individual feature to test cyclic requirement of a feature requiring
C++ 11, use the `std_cxx_11` meta-feature that has exactly this meaning.

The `cxx_static_assert` feature may be available in C++ 98 mode of some
compilers or not available at all in others.  Intstead of using an
individual feature to test propagation of a feature requiring C++ 11,
use the `std_cxx_11` meta-feature that has exactly this meaning.

The `{c,cxx}_std_*` features are meant for use with
`target_compile_features` but do not make sense for use with
WriteCompilerDetectionHeader.  Filter them out of any requested list.

A common use case of `target_compile_features` is simply to specify that
the compiler should be run in a mode that is aware of e.g. C++11.  Some
projects simply specify a particular C++11-only feature to request this.
Provide a first-class way to do this by naming features after the
corresponding language standard.  Record them as always available in the
corresponding standard level so that requesting them always ensures that
standard (or higher) is used.

Simplify and de-duplicate per-compiler feature recording macros and
convert to a centralized per-language macro.

We have no feature tests for versions of VS older than 2010, so do
not even call `record_compiler_features` for such versions.  This
is consistent with other compilers where we call this macro only
for versions for which we have recorded features.