Add options to the `install()` and `export()` commands to export the
targets we build into Android.mk files that reference them as prebuilt
libraries with associated usage requirements (compile definitions,
include directories, link libraries). This will allow CMake-built
projects to be imported into projects using the Android NDK build
system.
Closes: #15562
612d6f29 Tests: Refactor GenerateExportHeader test code
ce76abb4 Tests: Add data symbols to GenerateExportHeader test
8f95b93b Tests: Add failure test for GenerateExportHeader
Refactor the library code used in the GenerateExportHeader test to use
an improved naming convention that more directly identifies what it
being tested, making use of namespaces to avoid possible symbol
collisions. This also eliminates duplicate cases such as `libshared()`
and `libshared_not_exported()` which had the same decoration, and adds
consistent pairings of <name>_EXPORT and <name>_DEPRECATED_EXPORT which
were missing previously. The data tests from the previous commit are
also added to `libstatic` and `libshared_and_static` for consistency.
Note that there are no exported members of exported classes, as these
are not allowed on Windows.
Add static data members and global variables to the GenerateExportHeader
shared library, testing that export decoration for these works in
addition to decoration of classes and free functions.
Modify notation of statements in the GenerateExportHeader test expected
to result in link errors. Modify script used to build the test to also
generate a suite of modified sources, each having exactly one of the
failing lines enabled, and to generate EXCLUDE_FROM_ALL executables for
the same. Modify RunCMake script used to drive the test to read the list
of such executables and try to build each of them, verifying that they
do in fact fail to build.
This will verify that the _NO_EXPORT macros are working as expected, and
will also catch errors like the one that commit 0cbaaf2d
(GenerateExportHeader: Fix add_compiler_export_flags regression,
2016-09-01) fixed.
When setting up the failure tests for GenerateExportHeader, check if the
compiler actually hides non-exported stuff. If not, the failure tests
won't fail, and will cause the overall test to fail. Since this
typically is only the case for very old compilers, simply skipping them
as opposed to trying to do something more fine grained seems reasonably
safe.
The `ARGC`/`ARGV#` variables in function scope hold the original
arguments with no ;-list flattening. Add a way for functions to
cleanly parse arguments that may contain `;`. This also avoids
extra copying of the arguments.
Co-Author: Brad King <brad.king@kitware.com>
bdc679a8 VS15: Add Visual Studio 15 generator
a8936656 VS: Update v140 flag tables from VS 15 MSBuild files
21346d3f Features: Record features for VS 15 Preview 4
Call the generator "Visual Studio 15" without any year because the
preview version of VS 15 does not provide a year in the product name.
Copy cmGlobalVisualStudio14Generator to cmGlobalVisualStudio15Generator
and update version numbers accordingly. Add the VS15 enumeration value.
Note that we do not need to add a MSVC15 variable or v150 toolset
because Visual Studio 15 comes with an updated version of the v140
toolset and remains ABI-compatible.
Teach tests VSExternalInclude, RunCMake.GeneratorPlatform, and
RunCMake.GeneratorToolset to treat VS 15 as they do VS 10-14.
Closes: #16143
Since commit 14a8d61f (cmMakefile: Port nested error logic away from
cmExecutionStatus) we fail to continue processing function and macro
bodies after non-fatal errors. A non-fatal error should not stop
foreach loops, macro bodies, nested bodies, or the outer script.
Add a test covering these cases, and revert the change to fix them.
Also revert commit 2af853de (cmMakefile: Simplify IssueMessage
implementation) because the assertion it added (which was removed by the
above commit and is restored by reverting it) is incorrect. We do have
code paths that call cmMakefile::IssueMessage with an empty execution
stack, such as in CheckForUnusedVariables's LogUnused call.
72ecdd34 Tests: Cleanup RunCMake.GenerateExportHeader somewhat
fc3dab0e Tests: Port GenerateExportHeader test to RunCMake infrastructure
4feba34d GNU: Do not use -fvisibility on AIX or HP-UX
When `$<LINK_ONLY:...>` is used outside of linking we may evaluate it
without a `dagChecker`. Do not dereference the NULL pointer and issue a
diagnostic instead.
Closes: #16287
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
Even though the `file(GLOB)` documentation specifically warns against
using it to collect a list of source files, projects often do it anyway.
Since it uses `readdir()`, the list of files will be unsorted.
This list is often passed directly to add_executable / add_library.
Linking binaries with an unsorted list will make it unreproducible,
which means that the produced binary will differ depending on the
unpredictable `readdir()` order.
To solve those reproducibility issues in a lot of programs (which don't
explicitly `list(SORT)` the list manually), sort the resulting list of
the `file(GLOB)` command.
A more detailed rationale about reproducible builds is available
[here](https://reproducible-builds.org/).
Add a `CMAKE_NINJA_OUTPUT_PATH_PREFIX` variable. When it is set, CMake
generates a `build.ninja` file suitable for embedding into another ninja
project potentially generated by an alien generator.
Run the `Utilities/Scripts/clang-format.bash` script to update
all our C++ code to a new style defined by `.clang-format`.
Use `clang-format` version 3.8.
* If you reached this commit for a line in `git blame`, re-run the blame
operation starting at the parent of this commit to see older history
for the content.
* See the parent commit for instructions to rebase a change across this
style transition commit.
Packagers may now set their own rpm package
file names or request that rpmbuild tool
chooses one for them. It also supports handing
of situations where one spec file may produce
multiple rpm packages.
Since commit v3.3.0-rc1~430^2 (Teach find_(library|file|path) to get
prefixes from PATH, 2015-02-18) we search in <prefix>/include and
<prefix>/lib directories for prefixes with bin directories in the PATH
environment variable. The motivation was to support MSYS, MinGW and
similar Windows platforms in their default environments automatically.
At the time this behavior was thought to be worthwhile in general.
Suggested-by: Chuck Atkins <chuck.atkins@kitware.com>
Teach the `add_custom_command` and `add_custom_target' commands to
substitute argv0 with the crosscompiling emulator if it is a target with
the `CROSSCOMPILING_EMULATOR` property set.
A `$<TARGET_FILE:tgt>` generator expression does not cause insertion of
the emulator. Add a test covering this. While at it, extend the test
case to cover executables in a subdirectory. Also make the test
matching expressions more robust to support multiple add_test calls
without mixing them while matching.
e1c77472 Format include directive blocks and ordering with clang-format
180538c7 Source: Stabilize include order
0e7bca92 Utilities/Release: Stabilize include order in WiX custom action
eb817be0 Tests: Stabilize include order in MFC, VSXaml, and VSWinStorePhone
eda313b4 Tests: Stabilize include order in StringFileTest
7110b754 CursesDialog: add missing cmState include
d7a5f255 Modules: Remove unused CMakeTestWatcomVersion.c file
Sort include directives within each block (separated by a blank line) in
lexicographic order (except to prioritize `sys/types.h` first). First
run `clang-format` with the config file:
---
SortIncludes: false
...
Commit the result temporarily. Then run `clang-format` again with:
---
SortIncludes: true
IncludeCategories:
- Regex: 'sys/types.h'
Priority: -1
...
Commit the result temporarily. Start a new branch and cherry-pick the
second commit. Manually resolve conflicts to preserve indentation of
re-ordered includes. This cleans up the include ordering without
changing any other style.
Use the following command to run `clang-format`:
$ git ls-files -z -- \
'*.c' '*.cc' '*.cpp' '*.cxx' '*.h' '*.hh' '*.hpp' '*.hxx' |
egrep -z -v '(Lexer|Parser|ParserHelper)\.' |
egrep -z -v '^Source/cm_sha2' |
egrep -z -v '^Source/(kwsys|CursesDialog/form)/' |
egrep -z -v '^Utilities/(KW|cm).*/' |
egrep -z -v '^Tests/Module/GenerateExportHeader' |
egrep -z -v '^Tests/RunCMake/CommandLine/cmake_depends/test_UTF-16LE.h' |
xargs -0 clang-format -i
This selects source files that do not come from a third-party.
Inspired-by: Daniel Pfeifer <daniel@pfeifer-mail.de>
Since commit v3.4.0-rc1~321^2~2 (Genex: Store a backtrace, not a pointer
to one, 2015-07-08) we treat cmListFileBacktrace instances as
lightweight values. This was true at the time only because the
backtrace information was kept in the cmState snapshot hierarchy.
However, that forced us to accumulate a lot of otherwise short-lived
snapshots just to have the backtrace fields available for reference by
cmListFileBacktrace instances. Recent refactoring made backtrace
instances independent of the snapshot hierarchy to avoid accumulating
short-lived snapshots. This came at the cost of making backtrace values
heavy again, leading to lots of string coying and slower execution.
Fix this by refactoring cmListFileBacktrace to provide value semantics
with efficient shared storage underneath. Teach cmMakefile to maintain
its call stack using an instance of cmListFileBacktrace. This approach
allows the current backtrace to be efficiently saved whenever it is
needed.
Also teach cmListFileBacktrace the notion of a file-level scope. This
is useful for messages about the whole file (e.g. during parsing) that
are not specific to any line within it. Push the CMakeLists.txt scope
for each directory and never pop it. This ensures that we always have
some context information and simplifies cmMakefile::IssueMessage.
Push/pop a file-level scope as each included file is processed. This
supersedes cmParseFileScope and improves diagnostic message context
information in a few places. Fix the corresponding test cases to expect
the improved output.
Create a <LANG>_CLANG_TIDY target property (initialized by a
CMAKE_<LANG>_CLANG_TIDY variable) to specify a clang-tidy command line
to be run along with the compiler.
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`).
The Custom-Symbolic-and-Byproduct case fails strangely on some
filesystems used by our nightly testing. Somehow on the first build the
`use-byproduct` output ends up with a timestamp older than
`gen-byproduct-stamp` even though the build log clearly shows them build
in the correct order (and must according to build system dependencies).
Work around this problem by adding an extra delay before building
`use-byproduct`.
Tested-by: Gerhard Grimm <gerhard.grimm@detec.com>
The change in commit v3.5.0-rc1~198^2 (Ninja: Always re-run custom
commands that have symbolic dependencies, 2015-11-19) broke the
byproducts feature added by commit v3.2.0-rc1~340^2~2 (Add an option for
explicit BYPRODUCTS of custom commands, 2014-11-13) when SYMBOLIC
outputs also appear. This case occurs with AUTORCC-generated custom
targets because the output is SYMBOLIC (to always run) and the generated
file is a byproduct (for restat so dependents do not run unnecessarily).
The two use cases conflict because Ninja does not support per-output
restat. Favor restat whenever byproducts are present because it is
required for byproducts to work correctly. In use cases where we want
an always-run chain we simply will not be able to also use byproducts.
Brad King
Ruslan Baratov
Bill Hoffman
Matthew Woehlke
Domen Vrankar
Gregor Jasny
Kulla Christoph
Stephen Kelly
Tobias Hunger
Chaoren Lin
Daniel Pfeifer
Yury Zhuravlev
Felix Geyer
Alex Turbov
Daniel Scharrer
Harry Mallon
Reiner Herrmann
Nicolas Despres
Kitware Robot
Rolf Eike Beer
Jean-Christophe Fillion-Robin