cbf0c0fce4 cmake: Enable --warn-uninitialized inside string(CONFIGURE) and configure_file
1d32a35c10 cmCommandArgumentParserHelper: use cmMakefile::MaybeWarnUninitialized
67ac4ed1dc cmMakefile: Move uninitialized vars logic into MaybeWarnUninitialized()
5257af3634 cmMakefile: move common logic to IsProjectFile function
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2676
08be74bfd7 GetPrerequisites: Fix handling of executable scripts
52445300d6 GetPrerequisites: Allow prefixed tools
1bac4678ea GetPrerequisites: Add GET_PREREQUISITES_VERBOSE to set verbose
5072598f07 BundleUtilites: Don't use hardcoded name for install_name_tool
428680da92 GetPrerequisites: Don't use hardcoded name for otool
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2748
This option only has an effect if at least one of the other LOG_<step>
options is enabled. If an error occurs for a step which has logging to
file enabled, that step's output will be printed to the console. For
cases where a large amount of output is recorded, just the end of that
output may be printed to the console.
Because cmake_parse_arguments() has been implemented as a native
command, there is no need to include(CMakeParseArguments) anymore.
Its inclusion has been removed from several CMake modules.
Tests/CMakeOnly/CMakeLists.txt has been changed to include the
*building* CMake's copy of CMakeParseArguments rather than the
*built* CMake's copy. This file included the *built* copy because
when this file was introduced, CMake could still be built with versions
that didn't supply cmake_parse_arguments(). Now, CMake requires 3.1 or
greater, where cmake_parse_arguments() existed but was still in the
form of a module, so we include it from the *building* CMake.
This environment variable allows developers to locally run only a
subset of RunCMake subtests in a single RunCMakeTest.cmake script.
If the environment variable is not set, all of the tests in the
script are run.
2d68b2c593 String: Add str_if_stable() as a const alternative to str()
a0841b59bd String: Add support for a ""_s string literal syntax
9d5fe8e96a String: Add 'borrow' member to construct borrowing instances
80802a002c String: Add support for concatenation by operator+
ff69763ca0 String: Add a custom string type
410a3e4b22 Add support for using C++17 string_view or a fallback
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Daniel Pfeifer <daniel@pfeifer-mail.de>
Acked-by: Pavel Solodovnikov <hellyeahdominate@gmail.com>
Merge-request: !2578
- Add imported target LibLZMA::LibLZMA
- Show found message with library path
- Add test for FindLibLZMA
Fixes: #18680, #18679
Signed-off-by: Hiroshi Miura <miurahr@linux.com>
Offer clients a `project()`-centric view of the build system. This is
similar to the directory-centric view but consolidates subdirectories
that do not call `project()` with a new project name.
Issue: #18398
Co-Author: Kyle Edwards <kyle.edwards@kitware.com>
The `str()` method must be non-const because it may need to internally
mutate the representation of the string in order to have an owned
`std::string` instance holding the exact string (not a superstring).
This is inconvenient in contexts where we can ensure that no mutation
is needed to get a `std::string const&`.
Add a `str_if_stable() const` method that returns `std::string const*`
so we can return `nullptr` if if mutation would be necessary to get a
`std::string const&`. Add supporting `is_stable() const` and
`stabilize()` methods to check and enforce stable availability of
`std::string const&`. These can be used to create `String const`
instances from which we can still get a `std::string const&` via
`*str_if_stable()` by maintaining the stability invariant at runtime.
This will allow creation of `cm::String` instances that borrow from
non-owned storage. It is the caller's responsibility to ensure that
no copy of the instance outlives the borrowed buffer.
Create a `cm::String` type that holds a view of a string buffer and
optionally shares ownership of the buffer. Instances can either
borrow longer-lived storage (e.g. static storage of string literals)
or internally own a `std::string` instance. In the latter case,
share ownership with copies and substrings. Allocate a new internal
string only on operations that require mutation.
This will allow us to recover string sharing semantics that we
used to get from C++98 std::string copy-on-write implementations.
Such implementations are not allowed by C++11 so code our own in
a custom string type instead.
Add support for client-owned *stateful* query files. These allow
clients to request a list of versions of each object kind and get only
the first-listed version that CMake recognizes. Since clients own their
stateful query files they can mutate them over time. As a client
installation is updated it may update the queries that it writes to
build trees to get newer object versions without paying the cost of
continuing to generate older versions.
Issue: #18398
Add support for client-owned stateless query files. These allow clients
to *own* requests for major object versions and get all those recognized
by CMake.
Issue: #18398
Add a file-based API that clients may use to get semantic information
about the buildsystem that CMake generates. Clients will write query
files under a designated location in the build tree, and CMake will
write reply files for clients to read.
Start with support for shared stateless query files. These allow
clients to share requests for major object versions and get all those
recognized by CMake. Once any client has written a shared request to a
build tree it will persist. Other clients will not need to overwrite
the request (since it is stateless) and should not remove it either.
For now we add only an undocumented object kind to use for testing the
query and reply infrastructure. Object kinds providing real semantic
information will be added later.
Issue: #18398
Prior to this commit, linking against an object library did not
propagate private link dependencies of object libraries to their
consuming targets. This change implements the correct behavior.
Fixes: #18692
Co-Author: Brad King <brad.king@kitware.com>
