When installing FILE_SETs, it is possible the FILE_SET has not yet been
created with target_sources(FILE_SET). Instead of ignoring this
situation, we need to track the installed FILE_SET names and their
possible install destinations.
At generation time we resolve the names and destinations concretely. If
a FILE_SET wasn't provided or isn't an INTERFACE, we silently bail out.
Fixes: #26697
When install(TARGETS) and install(EXPORT) were called with file sets
and an absolute CMAKE_INSTALL_INCLUDEDIR, "${_IMPORT_PREFIX}/" was
still being prepended to the base directory and files, resulting in
incorrect paths. Don't prepend this when absolute paths are used.
Fixes: #25010
If a source file is not found, the error message reports a backtrace.
Previously the backtrace pointed at where the target was created.
In the case of `target_sources`, the missing source may have been
named elsewhere.
Fixes: #24538
`FILE_SET` is only supported within `target_sources()` and only directly
after a visibility keyword or another `FILE_SET`. Give a hint as to what
might be wrong if a file named `FILE_SET` cannot be found for any
reason.
Fixes: #24539
For policy-specific tests, use the version before the policy was
introduced. Otherwise, use 3.5 where possible.
Also, remove `cmake_minimum_required()` and `project()` calls from
individual cases where they are handled by `CMakeLists.txt`.
These patches now support the `-MF` output, so remove the `none` support
added just for the old patchset which did not use it.
Also update the flag name to `-fmodule-output=`.
Due to the new Clang module mapper flag, use a new experimental support
UUID as well.
Missing file sets were originally checked at configure time in
install(TARGETS ... EXPORT), but were not checked at generate time. If
a file set was added after install(TARGETS ... EXPORT) was called,
an abortion error was thrown. Check again at generate time to gracefully
display an error message instead of crashing.
Fixes: #23680
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.
If an INTERFACE library has HEADER_SETS, and its header sets contain
files generated by a custom command, the library needs to participate in
the buildsystem so that the files will be generated.
Fixes: #23422
There is no reason to allow these properties to be manipulated by user
code. Instead, use the stored visibility on the fileset objects to
derive what these properties should contain.
The feature needs a specialized implementation to place headers
in the right place inside frameworks. To avoid silently doing
the wrong thing, make this case an error for the 3.23 series.
Issue: #23386
The following was disallowed:
add_library(iface INTERFACE)
target_link_libraries(iface PUBLIC)
just due to the mention of the `PUBLIC` keyword. Instead, only error if
there are actually `PUBLIC` dependencies specified (and analogously for
other restrictions).
Update tests to expect this new behavior.
Not all of these commands accept non-compilable (i.e., IMPORTED)
targets, so those calls are currently just commented out. If they ever
do start to accept them, the tests should be enabled.
