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
1462576b Parser: Port away from cmMakefile
421012a3 cmMessenger: Extract from cmake class
14a8d61f cmMakefile: Port nested error logic away from cmExecutionStatus
2af853de cmMakefile: Simplify IssueMessage implementation
33bb9cfa Parser: Issue messages through cmake, not cmSystemTools
db7de303 Parser: Store the Backtrace for use in issuing messages
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
...
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)
Teach Visual Studio generators to include object files from object
libraries in the list of objects whose symbols are to be exported.
The Makefile and Ninja generators already did this. Update the
test to cover this case.
Reported-by: Bertrand Bellenot <Bertrand.Bellenot@cern.ch>
Custom command dependencies are followed for each target's source files
and add their transitive closure to the corresponding target. This
means that when a custom command in one target has a dependency on a
custom command in another target, both will appear in the dependent
target's sources. For the Makefile, VS IDE, and Xcode generators this
is not a problem because each target gets its own independent build
system that is evaluated in target dependency order. By the time the
dependent target is built the custom command that belongs to one of its
dependencies will already have been brought up to date.
For the Ninja generator we need to generate a monolithic build system
covering all targets so we can have only one copy of a custom command.
This means that we need to reconcile the target-level ordering
dependencies from its appearance in multiple targets to include only the
least-dependent common set. This is done by computing the set
intersection of the dependencies of all the targets containing a custom
command. However, we previously included only the direct dependencies
so any target-level dependency not directly added to all targets into
which a custom command propagates was discarded.
Fix this by computing the transitive closure of dependencies for each
target and then intersecting those sets. That will get the common set
of dependencies. Also add a test to cover a case in which the
incorrectly dropped target ordering dependencies would fail.
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.
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.
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).
Create a LINK_WHAT_YOU_USE target property and corresponding
CMAKE_LINK_WHAT_YOU_USE variable to enable this behavior.
Extend link commands by running `ldd -u -r` to detect shared
libraries that are linked but not needed.
The makefile is only used when called by the cmMessageCommand, so inline
the use of it there. It otherwise creates an undesirable dependency on
cmMakefile for issuing messages in the cmake instance, a violation of
the Interface Segregation Principle.
https://en.wikipedia.org/wiki/Interface_segregation_principle
This also makes it more explicit that the variable definitions only
affect the message() command. If an AUTHOR_WARNING is issued for any
other reason, it is not affected. To affect that, it is necessary to
set the cache variable instead of the regular variable.
This is an unfortunate interface quirk, but one which can't be fixed
easily now.
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``.
After finding it in `foo.Framework/Headers/dir/header.h`, we should
report the `foo.Framework/Headers` directory, not
`foo.Framework/Headers/dir`, because the former is what actually
contains the path the caller wishes to include.
Policy CMP0026 deprecated the LOCATION property, and we have long
provided a $<TARGET_FILE:...> generator expression. However, if
a project tries to use $<TARGET_PROPERTY:...,LOCATION> we should
at least not crash.
The compatibility implementation of the LOCATION property uses
cmGlobalGenerator::CreateGenerationObjects to create the structures
needed to evaluate the property before generation starts. The
implementation assumed that accessing the property could only be done
during configuration (via the typical get_property command use case).
The $<TARGET_PROPERTY:...,LOCATION> genex causes the LOCATION property
to be accessed during generation. Calling CreateGenerationObjects
during generation blows away all the objects currently being used for
generation and is not safe. Add a condition to call it only when
configuration is not finished.
Add a `CMAKE_TRY_COMPILE_PLATFORM_VARIABLES` variable to specify a list
of custom variables to be forwarded to a `try_compile` test project.
This will be useful for platform information modules or toolchain files
to forward some platform-specific set of variables from the host project
(perhaps set in its cache) to the test project so that it can build the
same way.
This patch preserves backward compatibility of
deb package names with previous CMake versions
but similarly to CPack/RPM allows to change
package name format and supports DEB-DEFAULT
setting that produces proper Debian package names.
eb076692 Tests: Select RunCMake.Ninja test cases based on ninja version
8a862a4d Ninja: Support embedding of CMake as subninja project
038e7716 Ninja: Pass all build paths through a central method
7c26a6a2 Ninja: Fix path to soname-d target file
ac3cdd9a Ninja: Convert object file names to ninja paths earlier
d4381cb1 Ninja: Convert link library file names like all other output paths
0397c92a Ninja: Pre-compute "CMakeCache.txt" build target name
3b3ecdfa Ninja: Pre-compute "all" build target name
5ca72750 Ninja: Simplify generation of custom target logical path
Brad King
Gregor Jasny
Kulla Christoph
Domen Vrankar
Stephen Kelly
Tobias Hunger
Chaoren Lin
Daniel Pfeifer
Yury Zhuravlev
Felix Geyer
Alex Turbov
Bill Hoffman
Daniel Scharrer
Harry Mallon