Replace use of cmsys::auto_ptr with a CM_AUTO_PTR macro that maps to
our own implementation adopted from the KWSys auto_ptr implementation.
Later we may be able to map CM_AUTO_PTR to std::auto_ptr on compilers
that do not warn about it.

Automate the client site conversions:

    git grep -l auto_ptr -- Source/ | grep -v Source/kwsys/ | xargs sed -i \
      's|cmsys::auto_ptr|CM_AUTO_PTR|;s|cmsys/auto_ptr.hxx|cm_auto_ptr.hxx|'

Nicolas BUNEL authored 8 years ago and Brad King committed 8 years ago

Add a `CMAKE_BIN_DIR` cache entry to CMake's own build configuration.
Add a `--bindir` option to the `bootstrap` script to set it.

Niels Ole Salscheider authored 9 years ago and Brad King committed 9 years ago

Create a `CMAKE_XDGDATA_DIR` option and add a corresponding flag to the
`bootstrap` script.  This is needed for multiarch layouts where the
prefix is `/usr/${host}` but where architecture-independent files (like
the XDG-specific ones) are installed to `/usr/share`.

Do not activate it with the general use-system-libs options for now
because KWIML is not commonly distributed or available.

KWIML no longer uses a configured prefix.

KWSys no longer needs the cmsys/{ios,stl} directories so we no longer
populate them.  We no longer need to create them either.

Stephen Kelly authored 9 years ago and Brad King committed 9 years ago

Set a cmLocalGenerator on each instance at compute time.  That will
soon be needed to access cmGeneratorTarget instances.

If a cmExportBuildFileGenerator is processed early during configure time as a
result of CMP0024 it must be removed from the list to process later at generate
time.

The KWSys Configure.hxx header no longer needs KWSYS_STAT_HAS_ST_MTIM.
Our bootstrap-built CMake does not need to handle nanosecond precision
file times anyway.

KWSys has removed support for kwsys_ios, kwsys_stl, and pre-c++98
template compatibility layers.  Drop the bootstrap script checks for
these and configuration of the compatibility headers we no longer use.

The CMake bootstrap process uses Makefile generators so there is no
need to build the Ninja generators during bootstrap.

Provide a place to move functionality common to both.

The Convert methods never belonged to the local generator concept, so
split them out now.  The cmOutputConverter is cheap to construct and
destroy, so it can be instantiated where needed to perform
conversions.  This will allow further decoupling of cmLocalGenerator
from the configure step.

Inherit cmLocalGenerator from cmOutputConverter for the purpose of
source compatibility.

Create a SPHINX_FLAGS cache entry that users can populate with
command-line flags for sphinx-build.  Add an option to the
bootstrap script to populate it up front.

Suggested-by: Felix Geyer <debfx@ubuntu.com>

These cache entries should be generated with type BOOL, not FILEPATH.

Stephen Kelly authored 9 years ago and Brad King committed 9 years ago

At this point, it is an interface to the cache.  It will be extended
to be a universal interface for access to and manipulation of
configuration-time data (defintions, properties on targets,
directories, source files etc).

This will allow porting all command implementations away
from the cmMakefile and cmTarget classes, and result in something
more-purely related to configuration-time processing of cmake
commands.  That should serve at least the following goals:

 * Split the CMake implementation more definitively into three
   stages: Configuration, computation and generation, and be able to
   implement each optimally for memory access patterns etc.
 * Make better IDE integration possible by making more configuration
   data available.
 * Make it possiblte to use a smaller library than CMakeLib.a in
   cpack and ctest, resulting in smaller executables.
 * Make it possible to run the configure step multiple times in
   the same CMake run (#14539).

Manage its lifetime in the cmake class, and add a convenience accessor
to cmMakefile.

Provide bootstrap-time control for using a system JsonCpp library.

Build the needed infrastructure during bootstrap in order to allow
"cmake -E cmake_echo_color" to be used unconditionally during
generation.

We don't need to run compiler tests for ansi-for etc anymore. All
supported compilers support the features tested here.

SolarisStudio ships a very old RogueWave standard library
implementation (libCstd) and uses it by default for backward compatibility.
The macros defined when building the system libCstd need to be the same as
the macros defined when using it for binary compatibility reasons etc.  The
SolarisStudio compiler driver adds macros such as _RWSTD_NO_MEMBER_TEMPLATES and
_RWSTD_NO_CLASS_PARTIAL_SPEC etc. These macros disable certain APIs in the
standard library headers.

Although the compiler supports the features 'member templates' and 'partial
template specialization', the standard library does not provide APIs which
rely on those features.  This means that std::vector::insert in libCStd does
not accept a pair of iterators from a different type of container, because
that requires member templates, and reverse_iterator<const T> can not
be constructed from a reverse_iterator<T> because that requires partial
specialization (or at least the _RWSTD_NO_CLASS_PARTIAL_SPEC define) and
member templates.

This causes many problems while building CMake using SolarisStudio, which
have not been well understood until now.  The problems are usually
attributed to compiler limitations, while actually the problem is in
the standard library, as in commit v3.0.0-rc1~99^2~1 (Help: Document non-use
of std::set::insert., 2014-01-24) and commit 107dcac3 (Fix compilation with
the Oracle / Sun compiler (#15318), 2014-12-12).

SolarisStudio 12.3 and earlier also ships a version of stlport which may be
used instead of libCstd by specifying -library=stlport4

 https://docs.oracle.com/cd/E18659_01/html/821-1383/bkakg.html

SolarisStudio 12.4 ships a version of libstdc++ from GCC 4.8.2 which may be
used by specifying -std=c++03 or -std=c++11 etc

 http://docs.oracle.com/cd/E37069_01/html/E37075/bkamw.html#OSSCPgnaof

Use these more-capable standard library implementations when building cmake.
This will allow more use of 'normal' C++ (such as std::vector::insert), and cause
fewer surprises resulting from dashboards using SolarisStudio.

Because cmake is not a library linked against by 3rd parties and does not have
external dependencies, issues related to mixing code using libCStd and libstdc++
do not apply.

In commit v3.1.0-rc2~7^2 (Workaround for short jump tables on PA-RISC,
2014-11-04) we added use of shell syntax not supported on the Solaris
shell.  Avoid using the '!' operator.

Reported-by: Friedrich Haubensak <hsk@imb-jena.de>

Chuck Atkins authored 10 years ago and Brad King committed 10 years ago

The PA-RISC architecture requires special options for GCC to prevent
linker errors when libraries reach a certain size and / or complexity.
See http://mraw.org/blog/2007/10/10/Linking_on_hppa and gcc
documentation on -mlong-calls.

Since commit v3.0.0-rc1~374^2 (Refactor internal resource location APIs
and initialization, 2013-11-07) a bootstrap-built "cmake" tries to
reference "ctest" and "cpack" executables next to itself, which never
exist.  Teach cmSystemTools::FindCMakeResources, when bootstrap-built,
to refer to the "ctest" and "cpack" executables in the location where
they will be built after "make".

Rename CMAKE_ROOT_DIR to CMAKE_BOOTSTRAP_SOURCE_DIR to clarify both that
it is only for bootstrap and that it refers to the source directory.

Nils Gladitz authored 10 years ago and Brad King committed 10 years ago

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.

Rolf Eike Beer authored 10 years ago and Brad King committed 10 years ago

These flags are needed to enable support for C++98.  Also teach the
'bootstrap' script to add them if necessary.

Rolf Eike Beer authored 10 years ago and Brad King committed 10 years ago

These flags are needed to enable support for C++98.  Also teach the
'bootstrap' script to add them if necessary.

UTF-16 and UTF-32 files are rejected.

Historically CMake used three version components for the feature level.
We released new features while incrementing only the third version
component.  Since commit v2.8.2~105^2~4 (New version scheme to support
branchy workflow, 2010-04-23) we used the fourth version component for
bug-fix releases and the development date:

 <major>.<minor>.<patch>[.<tweak>][-rc<n>] = Release
 <major>.<minor>.<patch>.<date>[-<id>]     = Development

This solidified use of three components for the feature level, and was
necessary to continue releasing 2.x versions because:

* Some existing projects performed floating-point comparisons of
  ${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION} to 2.x numbers
  so ``x`` could never be higher than 9.

* Version 2.9.<date> was used briefly in post-2.8.0 development in
  CVS prior to the transition to Git, so using it in releases may
  have caused confusion.

Now that we are moving to 3.x versions, these two restrictions go away.
Therefore we now change to use only two components for the feature
level and use the scheme:

 <major>.<minor>.<patch>[-rc<n>] = Release
 <major>.<minor>.<date>[-<id>]   = Development

Also teach the bootstrap script to configure the needed headers.