================
@@ -138,6 +139,14 @@ struct ModuleDeps {
/// determined that the differences are benign for this compilation.
std::vector<ModuleID> ClangModuleDeps;
+ /// The set of libraries or frameworks to link against when
+ /// an entity from this module is used.
+ llvm::SmallVector<Module::LinkLibrary, 2> LinkLibraries;
+
+ /// Autolinking uses the framework name for linking purposes
+ /// when this is false and the export_as name otherwise.
+ bool UseExportAsModuleLinkName;
----------------
artemcm wrote:
>If the idea is to drop the autolink of the current module, should we rework
>that so that we remove it from the link libraries of the importer instead?
Yeah, that's the thinking behind adding it here - the scanner is aggregating a
set of link libraries for the root importer, and an assumption is made that a
module with export_as link name set will be covered by a `LinkLibrary` of one
of its dependents. e.g. `SomeKit` depends on `SomeKitCore` and the latter sets
`export_as SomeKit`. And the scanner's client may only see `ModuleDeps`, and
not this info, so it can use this bit to know to avoid processing its
`LinkLibraries`.
>From what I can tell the above scenario matches the circumstance where this
>bit is set on a `Module` -> when a module with the `export_as` name has
>already been found.
Given this, I do not really see a reason to report `LinkLibraries` for such
modules at all, what do you think that instead of having this bit here we
instead just use it in the scanner to know to avoid populating `LinkLibraries`
added here?
https://github.com/llvm/llvm-project/pull/93588
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
