Some are user facing.
Found using
codespell -q 3 --skip="./Utilities" -I .cmake-whitelist.txt`
whereby the whitelist contained:
ans
dum
helpfull
emmited
emmitted
buil
iff
isnt
nto
ot
pathes
substract
te
todays
upto
whitespaces
In `AddGlobalTarget_{Test,Package,PackageSource}`, check conditions up
front and return early if the targets are not needed. This reduces the
indentation of the main logic.
4e7f6738 Defer check for sources within a target until generation.
6e4e7c65 Tests: Exclude bad RunCMake.add_executable case on multi-arch Xcode
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1242
The `add_library` and `add_executable` commands can now be called with
no source-files and won't generate a warning or error message, as long
as source-files will be added later via the `target_sources` command.
If during the generation step still no sources are associated with
targets created by such calls a useful error message will be generated
and generation fails.
Targets of type `INTERFACE_LIBRARY`, `UTILITY` or `GLOBAL_TARGET` are
excluded from this check because we do not need sources for these target
types during generation.
Fixes: #16872
std::{begin,end} are part of C++11, std::{cbegin,cend} are part of C++14
and an standard compliant implementation has been introduced within the
'cm' namespace: cm::{cbegin,cend}.
std::size is only part of C++17, hence exposing a compliant implementation
within namespace cm (cm::size).
where possible, the standard implementations are reused.
Add cache entry `CMAKE_GENERATOR_INSTANCE` to hold the instance location
persistently across re-runs of CMake in a given build tree.
For now we reject the option by default if explicitly set. It will be
implemented on a per-generator basis. Pass the setting into try_compile
project generation. Add a RunCMake.GeneratorInstance test to cover
basic use cases for the option. Verify that `CMAKE_GENERATOR_INSTANCE`
is empty by default, and that it is rejected when the generator does not
support a user setting.
Issue: #17268
This is a large commit that serves multiple purposes
- Iterate source files only once and store all extracted
information in a cmQtAutogenDigest class that can be reused.
This is brings speed improvements because several properties
are only evaluated once. More that that it helps to avoid
duplication of code with non trivial files property checks.
- Fix the Visual Studio generator to use PRE_BUILD when possible.
- Convert `for( ... )` loops to C++11 range base loops where possible
(cmQtAutogen*.cxx only).
- String concatenation optimizations.
Add an index to Change cmLocalGenerator::GeneratorTargets for faster lookup by
name.
Also changed a bunch of uses of cmLocalGenerator::GetGeneratorTargets() to take
const references instead of copying the vector.
Represent generator targets as a map (name -> target) to make name lookups more
efficient instead of looping through the entire vector to find the desired one.
The `CurrentMakefile` member is shadowed by a generate-time member of
the same name in `cmGlobalXCodeGenerator`. Rename our member to clarify
its configure-time role and avoid the shadow.
In order to support generator expressions in target COMPILE_FEATURES
we apply them at generate time. Move this step to the beginning of
generation instead of doing it on demand while collecting flags.
This avoids repeating the process unnecessarily, and will then allow
`cmLocalGenerator::AddCompilerRequirementFlag` to be used any time
during generation.
1d829c86 Use quotes for non-system includes
26ee9e42 CPack: drop CPack prefix for includes
5afac50f cmConfigure: Ensure separate include block in headers
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !691
Comments that indicate a special include order is necessary because
GetCurrentDirectory might get redefined are outdated. Remove those
outdated comments and use the normal ordering of includes.
These functions just need to change the directory for a block of code
and then go back to the caller's expected location. Use
cmWorkingDirectory to ensure that all return paths are handled.
BUILD_WITH_INSTALL_RPATH, SKIP_BUILD_RPATH, CMAKE_SKIP_RPATH and
CMAKE_SKIP_INSTALL_RPATH no longer any effect on the install name
of a target on macOS.
Fixes: #16589
When building with multiple SDKs within one project Xcode requires
the usage of ${EFFECTIVE_PLATFORM_NAME} to put temporary and build
outout into separate directories. For example an iOS device and
simulator build use two different SDKs (iphoneos and iphonesimulator).
In the past cmake tries to detect embedded toolchains that could
possibly use simulators and emitted EFFECTIVE_PLATFORM_NAME (EPN)
at the proper locations. In #16253 Mark noticed that if he
uses macosx and iphoneos in combination the necessary EPN is not
emitted. This is because CMake by default assumes macosx SDK which
does not trigger EPN emission.
The fist naive approach - enabling EPN unconditionally revealed that
then the EPN leaks into generator expressions like $<TARGET_FILE:xxx>
which might be a regression and thus is unacceptable.
The next approach was to add an CMake property to enable EPN emission
unconditionally. This solved the reported problem.
But the EPN leakage also happened for the embedded toolchains already
without anyone noticing. So the control property was turned into a
tri-state one:
* No definition: EPN is activated for embedded toolchains like before
* ON: EPN is always emitted
* OFF: EPN is never emitted
That approach gives the user the chance to disable EPN for embedded
toolchains and restores generator expression functionality for those.
Closes: #16253
Users or scripts commonly remove or replace `CMakeCache.txt` without
also removing `CMakeFiles/`. In this case the information saved in the
cache from platform information initialization is missing, so we need to
re-initialize it. In such a case, remove the platform information
directory so that re-initialization will occur and restore needed
information to the cache.
Closes: #14820
cd8a57ae Add option to build CMake against a system librhash
71180fc8 FindLibRHash: Add module to find the librhash package
3216e94c Remove unused cm_sha2 infrastructure
5420278d Port hash computation to cmCryptoHash
9a596b33 cmCryptoHash: Re-implement in terms of librhash
47f91a61 cmCryptoHash: Avoid using subclasses at client sites
d0ff3e70 librhash: Port to KWIML for ABI and integer type information
465a85fb librhash: Avoid signed left-shift overflow
fc2cb74f librhash: Implement bswap_32 as a function even in strict C90 mode
0bd333bc librhash: Implement bswap_64 even in strict C90 mode
7189d62c librhash: Use __builtin_bswap{32,64} on Clang
af7ebf8a librhash: Install COPYING file with CMake documentation
bb01f20e librhash: Disable warnings to avoid changing 3rd party code
31bb727f librhash: Build the library within CMake
53048afa librhash: Remove source fragments not needed for CMake
5cb1b345 Merge branch 'upstream-librhash' into import-librhash
...
Add a `cmGeneratorTarget::GetEffectiveFolderName` helper to abstract
lookup of the `FOLDER` property in combination with checking for
generator support of folders.
Add a cmOutputConverter to the cmLinkLineComputer and factory methods to
facilitate shell escapes.
Add state to the cmLinkLineComputer to record whether outputting for
response files or for watcom, to satisfy the cmOutputConverter API.
These are constant for the lifetime of the cmLinkLineComputer, even when
its functionality is extended in the future. This also keeps the
signatures of cmLinkLineComputer relatively simple.
Pass the cmComputeLinkInformation as a method parameter so that
cmLinkLineComputer is free from target-specific state. An instance
should be usable for all targets in a directory.
CMake has several classes which have too many responsibilities.
cmLocalGenerator is one of them. Start to extract the link line
computation. Create generator-specific implementations of the interface
to account for generator-specific behavior.
Unfortunately MSVC60 has different behavior to everything else and CMake
still generates makefiles for it. Isolate it with MSVC60-specific
names.
At generate-time, definitions are sometimes read from a nearby cmMakefile,
making the value directory-specific because they are read once per
directory. Often however, the intention is more
often to create a 'global' setting, such that the user writes for
example:
set(CMAKE_IMPORT_LIBRARY_SUFFIX something)
once at the top level of their project.
Many of these are also set by internal platform files, such as
CMAKE_EXTRA_LINK_EXTENSIONS.
The set() definitions are not really suitable for 'global' settings
because they can be different for each directory, and code consuming the
settings must assume they are different for each directory, and read it
freshly each time with new allocations.
CMake has other variable types which are global in scope, such as global
properties, and cache variables. These are less convenient to populate
for users, so establish a convention and API using the value as it is at
the end of the top-level CMakeLists file.
