`xlC` now warns "Additional optimization may be attained by recompiling
and specifying MAXMEM option" on `cmExportPackageInfoGenerator`.
Add the suggested option.
LCC, as of 1.26, has a buggy EDG frontend that emits
-Wunused-but-set-variable warning even if there's something
like "(void)var" when frontend optimizations are enabled (>=-O1).
To get rid of this warning, we disable it in CMake's root
CMakeLists.txt for LCC >= 1.26. Later, when this bug will be fixed
in LCC, this version check will have its top version limit.
To avoid problems accessing filesystem, use 64-bit file offsets when
compilation model is 32-bit. This explicit definition is needed now
that KWSys does not provide LFS settings in its headers anymore.
Fixes: #20568
* Deprecation removals previously specific to MSVC/Intel now also used
by clang
* String literals were assigned to non const pointers. These are stored
in mutable arrays now
* An implicit function pointer to pointer conversion is a Microsoft
extension warning is suppressed by an explicit reinterpret_cast
* The MSVC specific deprecation macro for jsoncpp was moved after the
clang macro to avoid redefinition warnings. This is consistent with
how jsoncpp fixed the issue in 36d8cfd7
A new cache option named `CMake_MSVC_PARALLEL` is now available that can
be used to control the usage of [`/MP`][1] to the MSVC compiler. This
enables parallelized builds on a per-translation unit basis. To enable
`/MP`, specify value `ON` to the option. Using an integral non-zero
value will control the specific number of threads used with the `/MP`
option, as opposed to letting the toolchain decide for you.
Fixes#17696
[1]: https://docs.microsoft.com/en-us/cpp/build/reference/mp-build-with-multiple-processes
Deep regex matching logic can exceed the default 1MB stack size. Until
a better regex engine is used, simply push the problem over a farther
horizon by increasing the stack size when built using a MSVC-compatible
linker.
Issue: #17659
CMake will soon require both C++11 and libuv to build. Neither of
these works on HP-UX, so unfortunately we need to drop support for
the platform until someone can get them working.
Issue: #17137
When hosting CMake's own build with the PGI compiler there are several
warnings that cannot easily be fixed or suppressed. We have enough code
quality tools and warnings from other compilers that it is unlikely a
PGI-only warning is useful.
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.
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.
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.
When testing CMAKE_<LANG>_COMPILER_ID values, do not explicitly
dereference or quote the variable. We want if() to auto-dereference the
variable and not its value. Also replace MATCHES with STREQUAL where
equivalent.
Workaround binutils bug by only marking unique section starting by
".text._".
This adds the HPPA workaround improved in commit b22a0f15 (bootstrap:
improve ld flag for Linux/HPPA builds, 2014-01-14) not only to the
bootstrap, but also to the normal build.
There is a binutils bug that leads to errors like this:
/usr/lib/gcc/hppa2.0-unknown-linux-gnu/4.6.3/../../../../hppa2.0-unknown-linux-gnu/bin/ld: libCMakeLib.a(cmTarget.cxx.o)(.text+0x12084): cannot reach 00001d28__ZNSspLEPKc@@GLIBCXX_3.4+0, recompile with -ffunction-sections
/usr/lib/gcc/hppa2.0-unknown-linux-gnu/4.6.3/../../../../hppa2.0-unknown-linux-gnu/bin/ld: libCMakeLib.a(cmTarget.cxx.o)(.text+0x12084): cannot handle R_PARISC_PCREL17F for std::basic_string<char, std::char_traits<char>, std::allocator<char> >::operator+=(char const*)@@GLIBCXX_3.4
/usr/lib/gcc/hppa2.0-unknown-linux-gnu/4.6.3/../../../../hppa2.0-unknown-linux-gnu/bin/ld: final link failed: Bad value
Until someone finds out what needs to be fixed in binutils this allows anyone
to compile a working CMake even in debug mode.
Ancient versions of CMake required else(), endif(), and similar block
termination commands to have arguments matching the command starting the
block. This is no longer the preferred style.
Run the following shell code:
for c in else endif endforeach endfunction endmacro endwhile; do
echo 's/\b'"$c"'\(\s*\)(.\+)/'"$c"'\1()/'
done >convert.sed &&
git ls-files -z -- bootstrap '*.cmake' '*.cmake.in' '*CMakeLists.txt' |
egrep -z -v '^(Utilities/cm|Source/kwsys/)' |
egrep -z -v 'Tests/CMakeTests/While-Endwhile-' |
xargs -0 sed -i -f convert.sed &&
rm convert.sed
The commit "Disable Intel CRT deprecation warnings" broke the logic that
disabled MS's CRT deprecation warnings. This fixes the logic to disable
the warnings for both MSVC and Intel.
The Intel Compiler for Windows uses the MS runtime library which
deprecates many C functions. We define _CRT_SECURE_NO_DEPRECATE and
_CRT_NONSTDC_NO_DEPRECATE to disable the deprecation warnings.
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.
Matthew Woehlke