5389bb4274 Xcode: Don't hard-code SDK-provided implicit framework search paths
df08f8df30 cmComputeLinkInformation: Fix misspelt private variable name
375b307bae Apple: Fix linking to frameworks that do not exist until build time
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5760
When a framework is linked to a target by its full path and that
framework is located in one of the implicit framework search directories,
CMake 3.18.5 and earlier discarded that path.
ce2dee9e5b (Xcode: Don't add framework as -framework argument in
linker info list, 2020-09-28) introduced a regression which resulted in
the framework path always being added to the search path even if it
matched one of the implicit search paths. This broke the ability to do
device and simulator builds from the same configured project.
Fixes: #21678
Arguably, many of these are bugs in `clang-tidy`. An if/else tree with
other conditionals between cloned blocks may be relying on the
intermediate logic to fall out of the case and inverting this logic may
be non-trivial.
See: https://bugs.llvm.org/show_bug.cgi?id=44165
Since commit d4d0dd0f6a (cmLinkLineComputer: Add ComputeLinkLibs
overload with backtraces, 2019-09-13, v3.16.0-rc1~87^2~4), backtraces
have been collected by `ComputeLinkLibs` by looking back through the
link implementation libraries for one matching the text of the link line
item. This is slow in projects with long link lines.
Instead, teach `cmComputeLinkDepends` and `cmComputeLinkInformation` to
carry backtrace information explicitly along with the text of each item.
Fixes: #20322
Fixes#17559
Replace our hard-coded default of cudart=static with a first-class abstraction to select the runtime library from an enumeration of logical names.
Set the MinTypeNameLength option to an impossibly high value in order
to limit the diagnostics to iterators. Leave new expressions and cast
expressions for later.
Extend the change from commit 689be6235e (Generator: support
per-language link library flag, 2019-08-08) to cover more link library
command-line flag components. Allow compilers for different languages
to use different values for these linking-related variables within the
same build.
Closes: #19631
This patch is generated by a python script that uses regular expressions to
search for string concatenation patterns of the kind
```
std::string str = <ARG0>;
str += <ARG1>;
str += <ARG2>;
...
```
and replaces them with a single `cmStrCat` call
```
std::string str = cmStrCat(<ARG0>, <ARG1>, <ARG2>, ...);
```
If any `<ARGX>` is itself a concatenated string of the kind
```
a + b + c + ...;
```
then `<ARGX>` is split into multiple arguments for the `cmStrCat` call.
If there's a sequence of literals in the `<ARGX>`, then all literals in the
sequence are concatenated and merged into a single literal argument for
the `cmStrCat` call.
Single character strings are converted to single char arguments for
the `cmStrCat` call.
`std::to_string(...)` wrappings are removed from `cmStrCat` arguments,
because it supports numeric types as well as string types.
`arg.substr(x)` arguments to `cmStrCat` are replaced with
`cm::string_view(arg).substr(x)`
This replaces invocations of
- `cmSystemTools::IsInternallyOn` with `cmIsInternallyOn`
- `cmSystemTools::IsNOTFOUND` with `cmIsNOTFOUND`
- `cmSystemTools::IsOn` with `cmIsOn`
- `cmSystemTools::IsOff` with `cmIsOff`
This enables the use of MSVC and Swift on Windows in a single project.
MSVC uses no flag to indicate linked libraries while Swift uses `-l`.
Add support for a language specific link library flag which takes
precedence over the global `CMAKE_LINK_LIBRARY_FLAG` which preserves
compatibility with earlier releases.
Enables the clang-tidy test performance-inefficient-string-concatenation
and replaces all inefficient string concatenations with `cmStrCat`.
Closes: #19555
The `CMAKE_LINK_LIBRARY_FILE_FLAG` variable is meant for linkers that
want library file paths to be preceded by a flag. This is used only
for OpenWatcom to add the `library` argument before library file paths.
Refactor the approach to treat `CMAKE_LINK_LIBRARY_FILE_FLAG` as a
command-line string fragment to add just before the library file path.
This has two advantages:
* `CMAKE_LINK_LIBRARY_FILE_FLAG` now works like `CMAKE_LINK_LIBRARY_FLAG`.
* `CMAKE_LINK_LIBRARY_FILE_FLAG` can now be an attached flag whose value
is the library file path.
Technically this is a change in behavior, but this setting was created
for internal use and should be rarely used outside of CMake itself.
Fixes: #19541
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
