On Windows, libuv's one-time initialization changes the C runtime
library's `_fmode` setting to `_O_BINARY`, thus causing files to open
as binary after that instead of the default `_O_TEXT` mode. See
upstream libuv issue 840. Work around the problem by performing libuv
initialization early and then restoring `_fmode`.
In particular, this currently affects server mode. Without this fix,
the `_fmode` setting changes when the server mode initializes libuv.
Fixes: #16962
We only define `INTERPROCEDURAL_OPTIMIZATION` behavior for C, CXX, and
Fortran languages. Do not try to enable support for other languages.
Furthermore, each language builds with a different compiler, so check
for support by CMake and the compiler for each language independently.
Fixes: #16944
The CUDA compiler automatic deprecation warnings are pure noise when
doing device linking, and should be suppressed to reduce the amount of
confusion from users.
Adds an option CPACK_ENABLE_FREEBSD_PKG to allow CPack to look
for FreeBSD's libpkg / pkg(8). If this is set and the libpkg
headers and library are found (which they will be, by default,
on any FreeBSD system), then add a FreeBSD pkg(8) generator.
The FreeBSD package tool pkg(8) uses tar.xz files (.txz) with two
metadata files embedded (+MANIFEST and +COMPACT_MANIFEST).
This introduces a bunch of FreeBSD-specific CPACK_FREEBSD_PACKAGE_*
variables for filling in the metadata; the Debian generator does
something similar. Documentation for the CPack CMake-script is styled
after the Debian generator.
Implementation notes:
- Checks for libpkg -- the underlying implementation for pkg(8) --
and includes FreeBSD package-generation if building CMake on
a UNIX host. Since libpkg can be used on BSDs, Linux and OSX,
this potentially adds one more packaging format. In practice,
this will only happen on FreeBSD and DragonflyBSD.
- Copy-paste from cmCPackArchiveGenerator to special-case
the metadata generation and to run around the internal
archive generation: use libpkg instead.
- Generating the metadata files is a little contrived.
- Most of the validation logic for package settings is in
CPackFreeBSD.cmake, as well as the code that tries to re-use
packaging settings that may already be set up for Debian.
- libpkg has its own notion of output filename, so we have
another contrived bit of code that munges the output file
list so that CPack can find the output.
- Stick with C++98.
Add a `CUDA_COMPILER_LAUNCHER` target property like those added for C
and CXX by commit v3.4.0-rc1~450^2 (Add options to launch the compiler
through tools like ccache or distcc, 2015-06-04).
Fixes: #16953
Previously `file(GENERATE)` did not define any behavior for relative
paths given to the `OUTPUT` or `INPUT` arguments. Define behavior
consistent with CMake conventions and add a policy to provide
compatibility for projects that relied on the old accidental behavior.
Fixes: #16786
Normalize absolute paths so that no extra components like `../` or
`...//...` appear that later confuse relative path computation.
In particular, we expect paths sent to AddCMakeDependFile and
AddCMakeOutputFile to be normalized.
Do this only for paths that are already absolute because
we can't handle relative paths yet (see #16786).
Fixes: #16892
Simply matching "0 Warning" may match "10 Warning(s)". Instead remove
the entire ` 0 Warning(s)` content from the MSBuild output before
searching it for warnings.
Issue: #16942
The change in commit v3.9.0-rc1~42^2~1 (Autogen: Per-config file
suffixes, 2017-05-15) broke Visual Studio builds because the generators
do not yet fully support per-config sources. Disable the behavior on
Visual Studio generators for now.
Fixes: #16939
The change in commit v3.9.0-rc1~6^2~1 (C++ feature checks: check output
for '[Ww]arning', 2017-06-03) accidentally matches `0 Warning(s)` in the
output and always thinks a warning exists, thus failing all checks in
Visual Studio builds.
Fixes: #16942
