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
39ac889d cmake: Add trivial usage of libuv
7cf369fe Do not build libuv on HP-UX
075cae51 Do not build libuv on SPARC
9a53af40 Do not build libuv on Cygwin
219f7411 Do not build libuv on Mac OS X 10.4 and lower
8a5beef3 Add option to build CMake against a system libuv
e56aa462 FindLibUV: Add module to find libuv package
551d5aed libuv: Fix unused variable warning in uv_loop_close
f4f8074b libuv: Avoid including macOS CoreServices header globally
a63aaaed libuv: Always include our own header first
9130b53a libuv: Conditionally declare Windows APIs for VS 2008 and below
b52afa46 libuv: Fix anonymous union syntax
05dbc204 libuv: Fix Windows API function typedef syntax
75139374 libuv: Install LICENSE file with CMake documentation
95dcc4e4 libuv: Disable warnings to avoid changing 3rd party code
13b7e758 libuv: Build the library within CMake
...
Add it to a private source directory that is not installed so that we
can use it for building CMake itself. This will allow it to mature
before being distributed publicly.
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
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
...
Find packages that install their cmake package configuration files in
`lib/cmake/<name>` when they are installed in the default Windows
CMAKE_INSTALL_PREFIX, `C:/Program Files/<name>`.
Closes: #16212
Add a new SOURCE_SUBDIR option to ExternalProject_Add that allows
specifying the location of the CMakeLists.txt to use as the project root
relative to the SOURCE_DIR.
This is helpful for projects that have unusual layouts, or projects that
provide both a superbuild and project-only build depending on which
CMakeLists.txt is used.
Fixes: #15118
61a607e8 Help: Document AUTORCC behavior for same .qrc name case
e4f508e4 Tests/QtAutogen: Test same moc/qrc source names in different directories
4e9b97d7 QtAutogen: Allow multiple qrc files with the same name
41c9e14a QtAutogen: Allow multiple moc files with the same name
3c3b37b0 QtAutogen: Use std:: instead of ::std::
0a5dd3c7 cmFilePathUuid: Add class to generate deterministic unique file names
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).
CMake used to put all header search paths into HEADER_SEARCH_PATHS
attribute. Unfortunately this attribute does not support to declare
a search path as a system include.
As a hack one could add a -isystem /path to the cflags but then include
ordering is not deterministic. A better approach was chosen with this
patch by not filling HEADER_SEARCH_PATHS at all and to populate
the C, C++, and Fortran flags directly. The include paths used by
Xcode should be now identical to the ones used by Unix Makefiles and
Ninja generator.
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>
Revert these commits:
* v3.6.0-rc1~134^2
Tests: QtAutogen: Same source name in different directories test, 2016-04-13
* v3.6.0-rc1~134^2~1
Autogen: Generate qrc_NAME.cpp files in subdirectories, 2016-04-19
* v3.6.0-rc1~134^2~2
Autogen: Generate not included moc files in subdirectories, 2016-04-19
They regress existing builds that depend on the paths/symbols generated
previously. Another approach will be needed to solve the name collision
problem they were intended to solve. Leave the error diagnostics for
the colliding cases that were added in the same topic as the above
commits because they provide a useful early failure in relevant cases.
Fixes#16209.
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.
The cmGetPropertyCommand::StoreResult expects NULL for unset
properties. Make ALIASED_TARGET align with that expectation.
Additional corrections to the unit tests are necessary because
get_property removes variables for unset properties (in contrast
to get_target_property which stores a -NOTFOUND value).
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.
These libraries are used for Clang runtime analysis support with
flags like `-fsanitize=memory` and are not actually implicitly
linked libraries.
Fixes#16194.
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.
In commit v3.6.0-rc1~174^2 (Ninja: Honor CMAKE_NINJA_FORCE_RESPONSE_FILE
for compile rules, 2016-04-06), Ninja learned to look for
`CMAKE_NINJA_FORCE_RESPONSE_FILE` in the current scope or the
environment in order to force response file usage for all compilation
rules.
However, on Windows, the RC compiler goes through cmcldeps which does a
`replace(output, output + ".dep.obj")` on the command line. However,
with a response file (which we name `output + ".rsp"`), the response
file path is replaced instead causing the compiler to (correctly)
complain that the response file `output + ".dep.obj.rsp"` does not
exist.
What needs to happen is for cmcldeps to look through the response file,
replace *its* contents and place it in the `output + ".dep.obj.rsp"`
file.
Also add a test which actually compiles an RC file into a library and
executable for all generators on Windows and additionally test
`CMAKE_NINJA_FORCE_RESPONSE_FILE` for Ninja generators.
Fixes#16167.
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.
Brad King
Daniel Pfeifer
Domen Vrankar
Gregor Jasny
Kulla Christoph
Raffi Enficiaud
Stephen Kelly
Silvio Traversaro
Chaoren Lin
Tobias Hunger
Matthew Woehlke
Ben Boeckel
Sebastian Holtermann
Chuck Atkins
Roger Leigh
Yury Zhuravlev
Felix Geyer
Gilles Khouzam