The previous docs assumed one had to set INSTALL_RPATH for
this target property to have an effect, but the actual condition is
only that the install rpath is different to the build rpath. Even if
the install rpath is empty, it is possible that CMake will rewrite
the rpath during install because the build rpath could be
non-empty.
Resolve conflicts with changes since the 3.15 series:
* Convert `cmSystemTools::IsOn` => `cmIsOn`.
* Move one "EXCLUDE_FROM_ALL" target property logic fix to
its new location in `cmMakefile::AddNewUtilityTarget`.
The "all" target in each directory is supposed to have targets from that
directory even if the directory itself is marked `EXCLUDE_FROM_ALL` in
its parent. This was broken by commit dc6888573d (Pass EXCLUDE_FROM_ALL
from directory to targets, 2019-01-15, v3.14.0-rc1~83^2) which made the
participation of a target in "all" independent of context. Revert much
of the logic change from that commit to restore the old behavior. Then
re-implement the behavior intended by the commit to keep its test
working. Extend the test to cover the old behavior too.
Fixes: #19753
cc0900d9cd Help: Add release notes for AUTOMOC_PATH_PREFIX
692d8e3492 Help: Add documentation for AUTOMOC_PATH_PREFIX
1933ade9f1 Tests: At QtAutogen.MocIncludeSymlink test
706d9738a6 Tests: Merge QtAutogen.MocIncludeStrict and MocIncludeRelaxed
d018d27c10 Autogen: Add moc path prefix generation (AUTOMOC_PATH_PREFIX)
77983c8147 Autogen: Add IsHeader flag to SourceFileT class
f9e5441eb4 Autogen: Abbreviate file paths in messages
51676cf655 Autogen: Split JobEvalCacheT job into separate moc and uic jobs
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !3818
Swift has supported `CMAKE_Swift_LANGUAGE_VERSION` and
`Swift_LANGUAGE_VERSION` but didn't apply that to Ninja generated
targets. Consider the property when calculating the flags.
Generator expressions in target property VS_CONFIGURATION_TYPE might be used to
set the ConfigurationType to Utility for certain configurations to not build
the target while still linking to the target in other configurations.
Fixes: #19613
On AIX, plugins meant to be loaded into executables via `dlopen` must be
linked with access to a list of symbols exported from the executable in
order to use them (when not using runtime linking). The AIX linker
supports specifying this list as an "import file" passed on the command
line either via the `-bI:...` option or (with a leading `#! .` line) as
a normal input file like any other library file.
The linker import file plays the same role on AIX as import libraries do
on Windows. Teach CMake to enable its import library abstraction on AIX
for executables with the `ENABLE_EXPORTS` target property set. Teach
our internal `ExportImportList` script to optionally generate a leading
`#! .` line at the top of the generated export/import list. Update our
rule for linking an executable with exports to generate a public-facing
"import library" implemented as an AIX linker import file.
With this approach, our existing infrastructure for handling import
libraries on Windows will now work for AIX linker import files too:
* Plugins that link to their executable's symbols will be automatically
linked using the import file on the command line.
* The executable's import file will be (optionally) installed and
exported for use in linking externally-built plugins.
This will allow executables and their plugins to build even if we later
turn off runtime linking.
Issue: #19163
Mention the usage of a configuration specific
`IMPORTED_LOCATION_<CONFIG>` value even if the `<CONFIG>` is not the
same as the active configuration of the currently built project.
Co-Author: Brad King <brad.king@kitware.com>
- Rewrites and restructures the AUTOMOC target property documentation
- Remove the reference to the deprecated CMAKE_AUTOMOC_RELAXED_MODE
Fixes: #19167
