CMake has several classes which have too many responsibilities.
cmLocalGenerator is one of them. Start to extract the link line
computation. Create generator-specific implementations of the interface
to account for generator-specific behavior.
Unfortunately MSVC60 has different behavior to everything else and CMake
still generates makefiles for it. Isolate it with MSVC60-specific
names.
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.
This way messages can be issued independent of the cmake instance.
It is now possible to make DisplayMessage a virtual interface and
override it to handle messages in the cmake-gui or future IDE
interaction interfaces.
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|'
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`.
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 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>
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.
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>
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".
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.
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
