Move some target related enumeration types from `cmStateTypes.h` to a
new header, as these really aren't "state" types. Also, make
`TargetType` a strongly-typed enumeration.
Modify install exports to make use of the install generator's captured
diagnostic context. Modify build exports to capture and use a diagnostic
context. This allows diagnostics issued by export file generation to use
the diagnostic context from the instigating command, and to provide a
backtrace to the same.
Create methods to issue diagnostics. Diagnostics are similar to
messages, except that they are associated with a diagnostic category,
and the diagnostic state determines their severity. Also, add overloads
of methods to issue messages and diagnostics that accept a backtrace, as
a number of places must currently bypass layers in order to pass a
custom backtrace. These are also sub-optimal because the lower level
APIs require the diagnostic state to be explicitly passed by the caller,
which we would prefer to avoid whenever possible.
Export generators sometimes need to issue errors, and we had an existing
API for that. However, in the future, it will be useful to issue
non-fatal diagnostics as well. Rework the API to allow specifying the
type of diagnostic to issue.
Modify how cmExportBuildFileGenerator::FindExportInfo collects target
export information to properly record the export sets which export a
target. (The old behavior treated every invocation as a separate set,
which is reasonable for export(TARGETS) but does not allow referencing a
target exported multiple times via export(EXPORT). This reflects recent
changes to allow this for installed exports.)
Refactor methods in the build and install export file generators to have
the same, simplified API. Expose the resulting method as an abstract
method on the base class, so that it can be called from mode-agnostic
generators. While we're at it, refactor cmExportInstallFileGenerator's
version to use std::any_of.
In order to support generation of Common Package Specifications, the
mechanisms CMake uses to export package information need to be made more
abstract. The prior commits began this refactoring; this continues by
(actually) restructuring the classes used to generate the actual export files.
To minimize churn, this introduces virtual base classes and
diamond inheritance in order to separate logic which is format-agnostic
but depends on the export mode (build-tree versus install-tree) from
logic which is format-specific but mode-agnostic.
This could probably be refactored further to use helper classes instead,
and a future commit may do that, however an initial attempt to do that
was proving even more invasive, such that this approach was deemed more
manageable.
While we're at it, add 'const' in more places where possible.
Use clang-format to fix placement of const qualifiers to be consistently
right of the typename. The inconsistency was getting annoying,
especially as the following refactor changes a lot of methods and
sometimes adds const. (Being inconsistent within a file is not ideal,
but in some cases there was inconsistency within single lines!)
Teach the `$<TARGET_PROPERTY:...>` generator expression to check for a
new `TRANSITIVE_COMPILE_PROPERTIES` property in the target's link
closure to enable transitive evaluation of named properties through
the link closure, excluding entries guarded by `$<LINK_ONLY:...>`.
Issue: #20416
142a85f9c1 cxxmodules: use filesystem-safe export names in filenames
4452d41488 cmGeneratorTarget: add method to get a filesystem-safe export name
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !9474
Include the name of the `EXPORT` in the filename when generating export
information for C++ modules. This allows the same directory to be used
for multiple sets of C++ module-using targets.
For `export(TARGETS)` uses, generate a name based on the hash of the
concatenation of the target names involved with the `export()` call.
Fixes: #25609
When consuming exported targets which contain C++ modules, the consuming
project must be able to recompile BMI files using the original target's
flags. This is because a module source may use some private target usage
requirement but not want to propagate it to consumers. To facilitate
this, export the private information as necessary for consumers to be
able to perform the BMI compilations.
Calling `install(EXPORT)` with the `CXX_MODULES_DIRECTORY` parameter
leads to installation rules being generated which `include()` CMake
scripts that set the `IMPORTED_CXX_MODULES_[CONFIG]` target property for
relevant targets. However, these scripts don't get generated for
targets in an export set which don't have any C++20 modules. When the
installation rules attempt to `include()` the missing scripts, the
install fails.
Co-authored-by: Brad King <brad.king@kitware.com>
Add this target property to specify macro names that propagate to
dependents as `AUTOMOC_MACRO_NAMES`. The dependents will automatically
generate MOC files for source files that contain the inherited macro
names.
Co-Authored-By: Craig Scott <craig.scott@crascit.com>
Fixes: #19679
C++ modules have two variants which are of importance to CMake:
- `CXX_MODULES`: interface modules (those using `export module M;`,
`export module M:part;`, or `module M:internal_part;`)
- `CXX_MODULE_HEADER_UNITS`: importable header units
Creating C++ modules or partitions are *not* supported in any other
source listing. This is because the source files must be installed (so
their scope matters), but not part of usage requirements (what it means
for a module source to be injected into a consumer is not clear at this
moment). Due to the way `FILE_SET` works with scopes, they are a perfect
fit as long as `INTERFACE` is not allowed (which it is not).
Previously a fileset with `$<$<CONFIG:Debug>:some_file>` would show up
as-is (with escaping) in the build directory export. Instead, evaluate
all fileset entries as generator expressions and list them as they are
similar to the installation information.
Allow `cmGlobalGenerator`s to decide `HasKnownObjectFileLocation()` per given
`cmTarget`
- `cmGlobalGenerator::HasKnownObjectFileLocation()` now takes an optional `cmGeneratorTarget`
- `cmTarget::HasKnownObjectFileLocation()` added as a shorthand
To handle safely the values used by CMake variables and properties,
introduce the class cmProp as a replacement from the simple pointer
to std::string instance.
Update the change from commit 64690f6df0 (export: Do not fail generation
for namelink-only case, 2020-10-09, v3.19.0-rc1~7^2) to also handle
separate namelink-only and namelink-skip calls.
Fixes: #21529
Matthew Woehlke
Tom Osika
Marc Chevrier
Kitware Robot
Martin Duffy
Brad King
Ben Boeckel
Kyle Edwards
TylerandBrad King
Orkun TokdemirandCraig Scott
Hyper Nova Sun
Eugene Shalygin
Deniz Bahadir
Tushar Maheshwari
Regina Pfeifer
Daniel Pfeifer