error: redefinition of module when building Swift library importing objc_library #310
Comments
|
The really puzzling thing here is that the compiler is seeing the module map as an input from two different configurations: You say If that doesn't change anything, can you run |
|
That didn't work either. It is kinda puzzling. |
🤔 That's just bizarre. The only thing I can imagine that's going on here is that We have a number of mixed language dependencies internally and have never seen this bug, so I'm not sure what's different in external Bazel currently that could be causing this. @keith, have you ever seen anything like this? |
|
In order to make this work, usually an The I'd recommend wrapping these targets into an |
Tried that and... totally different set of errors now
Errors are mostly like/related to: It's not out of the question I've got the targets set up incorrectly but I believe I've mirrored the Swift package and the Podspec correctly as examples. |
|
That looks like an issue with how the targets are set up, and something outside my area of expertise, but at least there are no duplicate interfaces any more :) |
Yeah, will look into it a bit. The worrying thing to be is that if you just remove the dependency on RxCocoaRuntime for RxCocoa, you get the exact same output as if you try to import it into the ios_application target. |
|
So, found a different way to build this (just following Podspec defs and forgetting the objc_library altogether) so going to close, although the objc_library -> swift_library conversion is a bit weird and I can see us running into that again down the road. Hopefully can come up with a clearer example if that's the case. |
|
Here's the final resolution: That builds everything correctly if you build the ios_static_framework; however, it doesn't feel super ideal so I'm wondering what a best practice around this would be. We have numbers of modules that we'd like to run/test independently outside of having to jump right to ios_static_framework, and it feels like giving the platform directive should be enough info to apply the right configuration? Although I'm just getting into this, so I've got some source reading to do. Appreciate all the help with this, we're just starting our Bazel journeys |
|
We haven't hit this case before because we don't have any
|
|
I am facing the same problem. Is there anything that can be done to solve this? I would like to contribute if there are some guidances. |
|
Had some other devs take a look and this seems to work? I'm not quite sure what's different but @esam091 if you give it a try, might do the trick |
|
I haven't tried that yet, but I finally found a solution that works. For every # Foo/BUILD
objc_library(
name = 'Foo',
deps = ['swift'],
visibility = ['//visibility:public']
)
swift_library(
name = 'swift',
srcs = glob(['**/*.swift])
)
# App/BUILD
swift_library(
name = 'app',
srcs = glob(['**/*.swift']),
deps = ['//Foo']
)The trick is to prevent a Swift module appears twice both in |
@sergiocampama What is needed to make |
I don't think that's the approach we want; instead, it would be nice if Our advice here is still the same—building libraries as standalone targets is not recommended for platforms like Apple's where the libraries themselves can be cross-platform but building them correctly needs to specify a particular platform/OS version. The recommended approach is to use a unit test or application target to apply the right transition throughout the dependency tree. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm trying to build RxSwift/RxCocoa (from https://github.com/ReactiveX/RxSwift) with Bazel, and getting some errors I can't quite figure out when trying to import the objc_library target for the RxCocoaRuntime into RxCocoa. I think I've got it structured right, but it looks like it's defining multiple modulemaps for RxSwift along the way, potentially due the the cross-language imports?
Full error output:
The module map in question just reads:
The text was updated successfully, but these errors were encountered: