The Linux distro we've been using for this is so old that it limits our
ability to import newer third-party software. Until a new machine can
be configured to provide this binary we can simply drop it. Users will
still be able to build from source or use a distro-provided version.
Provide a way for custom commands to inform the ninja build tool about
their implicit dependencies. For now simply make use of the option an
error on other generators.
Closes: #15479
7b637ebd Android: Add `ANDROID` variable to indicate the target
c2f561e5 Android: Add test cases covering use of the NDK and standalone toolchains
6b84df8d Help: Document cross compiling for Android
d7d40830 Android: Select the STL type for NDK builds
b22294bc Android: Populate compiler flags for current ABI
b6a3102a Android: Add a CMAKE_BUILD_TYPE default
d1e3cec2 Android: Add Clang -target option for current ABI
504db72d Android: Add placeholders for compiler/abi-specific settings
fa632578 Android: Avoid interfering with common pre-existing toolchain files
6299693f Android: Search for NDK and standalone toolchain in more places
29b51379 Android: Detect and save a standalone toolchain without the NDK
7d9b49fb Android: Detect settings from the CMAKE_SYSROOT if it is set
4389664a Android: Detect and save a toolchain from the NDK
328191f6 Android: Set CMAKE_SYSROOT automatically
9e032304 Android: Detect and save the architecture, ABI, and processor
fde59c4d Android: Detect and save the API level
...
b4556b47 Help: Add release notes for 'vim-cmake-syntax' import
25c01cf0 Aux: Install vim-cmake-syntax files with CMake
e3ac68cf Merge branch 'upstream-vim-cmake-syntax' into import-vim-syntax
4a22c06e vim-cmake-syntax 2016-08-16 (e782679c)
f21a8235 Aux: Drop vim files prior to import of third-party version
0966f1c5 Add script to update vim-cmake-syntax from upstream
CMake now supports cross compiling for Android using the NDK or a
standalone toolchain. Document the associated variables and how how to
write toolchain files for Android.
With the Makefile generator one can use `cd $subdir; make install` to build and
install targets associated with a given subdirectory. This is not possible to
do with the Ninja generator since there is only one `build.ninja` file at the
top of the build tree. However, we can approximate it by allowing one to run
`ninja $subdir/install` at the top of the tree to build the targets in the
corresponding subdirectory and install them.
This also makes sense for `test`, `package`, and other GLOBAL_TARGET targets.
It was already done for `all` by commit v3.6.0-rc1~240^2~2 (Ninja: Add
`$subdir/all` targets, 2016-03-11).
f951d0ad Add tests for BUNDLE_EXTENSION
c63380b1 Update documentation about bundle extensions
134d5c1f Honor BUNDLE_EXTENSION also for Frameworks (#14742)
2b909c08 Honor BUNDLE_EXTENSION also for App Bundles (#16148)
Protect our `$0` reference in the shell as `"$0"`. Otherwise it works
with a space in the path only due to an insecure Windows feature.
Prior to this fix, any installer using the option added by commit
v2.8.9~234^2 (Added CPACK_NSIS_ENABLE_UNINSTALL_BEFORE_INSTALL,
2011-06-11) exposes a local privilege escalation vulnerability.
Reported-by: Amir Szekely <kichik@gmail.com>
Reported-by: Ug_0 Security
Add an explicit `<Natvis>` element in VS project files for `*.natvis`
files. These enable custom debug visualizers for project-specific
types.
Fixes#16043.
8a98cf64 Honor CMAKE_*_LINKER_FLAGS[_<CONFIG>]_INIT set in toolchain files
37d15c39 MSVC: Set all CMAKE_*_LINKER_FLAGS_INIT directly
55c884ed Embarcadero: Set all CMAKE_*_LINKER_FLAGS_INIT directly
aec3c79a Strip CMAKE_*_LINKER_FLAGS[_<CONFIG>] initializer whitespace
Document these variables.
Change our convention for setting these variables from:
set(CMAKE_EXE_LINKER_FLAGS_INIT "...")
to
string(APPEND CMAKE_EXE_LINKER_FLAGS_INIT " ...")
so that any value previously set by a toolchain file will be used.
Port changes from VTK commit fda6a31cb9 (Added Improved FindOpenMP
module, 2015-04-23). Improve use of try_compile to avoid needing
to pass OpenMP flags as libraries.
Document these variables.
Change our convention for setting these variables from:
set(CMAKE_C_FLAGS_INIT "...")
to
string(APPEND CMAKE_C_FLAGS_INIT " ...")
so that any value previously set by a toolchain file will be used.
Automate the conversion with:
sed -i 's/set *(\(CMAKE_\(C\|CXX\|Fortran\|RC\|ASM\|${[^}]\+}\)_FLAGS\(_[^_]\+\)\?_INIT \+"\)/string(APPEND \1 /' \
Modules/Compiler/*.cmake Modules/Platform/*.cmake
and follow up with some manual fixes (e.g. to cases that already
meant to append). Also revert the automated changes to contexts
that are not protected from running multiple times.
In the `try_compile` source file signature we propagate the caller's
value of `CMAKE_<LANG>_FLAGS` into the test project. Extend this to
propagate `CMAKE_<LANG>_FLAGS_<CONFIG>` too instead of always using the
default value in the test project. This will be useful, for example, to
allow the MSVC runtime library to be changed (e.g. `-MDd` => `-MTd`).
However, some projects may currently depend on this not being done,
so we need to activate the behavior using a policy.
This change was originally made by commit v3.6.0-rc1~160^2 (try_compile:
Honor CMAKE_<LANG>_FLAGS_<CONFIG> changes, 2016-04-11) but without the
policy and so had to be reverted during the 3.6 release candidate cycle.
Fixes#16174.
Revert commit v3.6.0-rc1~160^2 (try_compile: Honor
CMAKE_<LANG>_FLAGS_<CONFIG> changes, 2016-04-11). The behavior it
introduced can break projects that depend on the lack of such behavior.
We will have to introduce a policy or other mechanism to enable the
behavior in a compatible way. Simply revert it for now.
See issue #16174.
This property allow to specify a specific Visual Studio tool for a
source file overriding the default tool behavior. For example, a
`.resw` file being processed as a `PriResource` file. This has the
advantage of being able to teach CMake to process new file types without
code modifications.
Even in relatively small projects using `--trace` (and `--trace-expand`)
may produce a lot of output. When developing a custom module usually
one is interested in output of only a few particular modules.
Add a `--trace-source=<file>` option to enable tracing only a subset of
source files. The final output would be only from requested modules,
ignoring anything else not matched to given filename(s).
Add a ``FIND_LIBRARY_USE_LIB32_PATHS`` global property analogous to the
``FIND_LIBRARY_USE_LIB64_PATHS`` property. This helps find commands on
multilib systems that use ``lib32`` directories and either do not have
``lib`` symlinks or point ``lib`` to ``lib64``.