Refer to actual generated swift header when making swift hmap #48
Conversation
Before, the file in hdrs referred to a non-existant source file
| "-fmodules", | ||
| "-fmodule-name=%s" % module_name, | ||
| "-gmodules", | ||
| ] | ||
|
|
||
| swift_copts += [j for i in ([["-Xcc", copt] for copt in headermap_copts]) for j in i] + [ | ||
| swift_copts += [ | ||
| "-Xcc", |
There was a problem hiding this comment.
it seems like you already added -Xcc on line 448.
There was a problem hiding this comment.
You need an -Xcc for every argument that you want passed to clang
| @@ -1,3 +1,3 @@ | |||
| # We can't create a bzl_library for rules-swift because of its visibility, | |||
| # so circumvent by not using the sandbox | |||
| common --strategy=Stardoc=standalone | |||
| build --strategy=Stardoc=standalone | |||
There was a problem hiding this comment.
Why does this setting need to change?
There was a problem hiding this comment.
--strategy is apparently not valid for query
There was a problem hiding this comment.
thx for fixing this! I just ran into it
| all_hdrs += provider.files.to_list() | ||
| all_hdrs = list(ctx.files.hdrs) | ||
| for provider in ctx.attr.direct_hdr_providers: | ||
| if apple_common.Objc in provider: |
There was a problem hiding this comment.
Ah, I assume swift rules provide the -Swift.h header in an objc provider now no?
There was a problem hiding this comment.
yeah, they're in direct_headers
There was a problem hiding this comment.
I don't think I am qualified at this point to approve this PR or not, but I did leave a question to see if I'm generally following along…
The only other question I have is:
Was the problem we were trying to solve here that we had an extra -Swift.h file? If so, is it possible to write a test to show that we no longer generate an extra -Swift.h file?
| name = swift_doublequote_hmap_name, | ||
| namespace = namespace, | ||
| hdrs = [], | ||
| direct_hdr_providers = [swift_libname], |
There was a problem hiding this comment.
Echoing @ob's question from above, I assume what we're doing here is passing an instantiated swift_library rule into the headermap rule. In my beginner Bazel adopters mind, what's happening here isn't that we are passing some artifact, we are passing the information that the instantiated swift_library rules wants its consumers it to have: in this case, swift_library generates a -Swift.h header. In Bazel terms, the information an instantiated rule wants its consumers to be able to access is called a Provider, and Providers can be thought of as the "return value" of the instantiating a rule.
In this case, this headermap rule would like to include information about the instantiated swift_librarys -Swift.hheader into a header map, so that ObjC classes in targets that consume this apple_library can call methods on the Swift classes that the swift_library exposes in its header.
Is that more or less what's happening here?
There was a problem hiding this comment.
Awesome. Thanks for confirming @ob!
It wasn't actually generated, but the hmap had a reference to a source file with the name This showed up in the Xcodeproj rule, since that rule gathers all transitive source (e.g. not generated) files, and the -Swift.h file was showing up there, even though it (should have been a) generated file. |
Before, the file in hdrs referred to a non-existant source file
We can see the fix in effect by the xcodeproj build not failing, since the
-Swift.hheader is no longer getting added to the xcode project !cc @wileykestner