Originally created by @JCSooHwanCho on GitHub (Jun 14, 2023).
in addition to #480 , operator redeclaration made verification fail of .swiftinterface file. It can be resolved with only one declaration in module.
```
error: verify-emitted-module-interface command failed with exit code 1 (use -v to see invocation)
CoreStore/CoreStore.swiftinterface:3365:16: error: operator redeclared
infix operator .= : AssignmentPrecedence
^
CoreStore/CoreStore.swiftinterface:3326:16: note: previous operator declaration here
infix operator .= : AssignmentPrecedence
^
CoreStore/CoreStore.swiftinterface:3366:16: error: operator redeclared
infix operator .== : ComparisonPrecedence
^
CoreStore/CoreStore.swiftinterface:3327:16: note: previous operator declaration here
infix operator .== : ComparisonPrecedence
```
Interesting. Can you tell me how (SPM, Cocoapods, etc.) you are importing CoreStore into your dependencies?
@JohnEstropia commented on GitHub (Jun 15, 2023):
Interesting. Can you tell me how (SPM, Cocoapods, etc.) you are importing CoreStore into your dependencies?
In fact, there is a workaround. That is giving an no-verify-emitted-module-interface option to compiler. But I think it should be not user's concern.
@JCSooHwanCho commented on GitHub (Jun 15, 2023):
I made it as static .xcframework using bazel.
1. use [http_archive](https://bazel.build/rules/lib/repo/http#http_archive) rule to download repository
2. to build it as static framework using [Line's rule(ios_static_framework)](https://github.com/line/rules_apple_line/blob/main/apple/swift_static_framework.bzl)
In fact, there is a workaround. That is giving an `no-verify-emitted-module-interface` option to compiler. But I think it should be not user's concern.
In fact, there is a workaround. That is giving an no-verify-emitted-module-interface option to compiler. But I think it should be not user's concern.
I'm not very familiar with Bezel, but I'm not sure there is a way library authors can specify compiler directives when the code is compiled as a static library. The formally supported installation modes build frameworks instead of a static lib, so I think this should be handled on the API users' side.
On that note, the specific issue on operators can be avoided at least, since CoreStore can just declare it once for the whole module. I'll push something later just to avoid this case, but I'd warn that this fix is local to CoreStore. If an external static library declares their own .= and .== operators it's likely you will have this same issue anyway.
@JohnEstropia commented on GitHub (Jun 15, 2023):
> In fact, there is a workaround. That is giving an `no-verify-emitted-module-interface` option to compiler. But I think it should be not user's concern.
I'm not very familiar with Bezel, but I'm not sure there is a way library authors can specify compiler directives when the code is compiled as a static library. The [formally supported installation modes](https://github.com/JohnEstropia/CoreStore#installation) build frameworks instead of a static lib, so I think this should be handled on the API users' side.
On that note, the specific issue on operators can be avoided at least, since CoreStore can just declare it once for the whole module. I'll push something later just to avoid this case, but I'd warn that this fix is local to CoreStore. If an external static library declares their own `.=` and `.==` operators it's likely you will have this same issue anyway.
Conflicting with other module is just potential problem, but conflicting within module is present problem. How about focusing on present problem?
@JCSooHwanCho commented on GitHub (Jun 15, 2023):
Conflicting with other module is just potential problem, but conflicting within module is present problem. How about focusing on present problem?
I'll push something later just to avoid this case, but I'd warn that this fix is local to CoreStore
Feel free to make a PR ahead, if you have time.
@JohnEstropia commented on GitHub (Jun 15, 2023):
Yes, I mentioned here:
> I'll push something later just to avoid this case, but I'd warn that this fix is local to CoreStore
Feel free to make a PR ahead, if you have time.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @JCSooHwanCho on GitHub (Jun 14, 2023).
in addition to #480 , operator redeclaration made verification fail of .swiftinterface file. It can be resolved with only one declaration in module.
@JohnEstropia commented on GitHub (Jun 15, 2023):
Interesting. Can you tell me how (SPM, Cocoapods, etc.) you are importing CoreStore into your dependencies?
@JCSooHwanCho commented on GitHub (Jun 15, 2023):
I made it as static .xcframework using bazel.
In fact, there is a workaround. That is giving an
no-verify-emitted-module-interfaceoption to compiler. But I think it should be not user's concern.@JohnEstropia commented on GitHub (Jun 15, 2023):
I'm not very familiar with Bezel, but I'm not sure there is a way library authors can specify compiler directives when the code is compiled as a static library. The formally supported installation modes build frameworks instead of a static lib, so I think this should be handled on the API users' side.
On that note, the specific issue on operators can be avoided at least, since CoreStore can just declare it once for the whole module. I'll push something later just to avoid this case, but I'd warn that this fix is local to CoreStore. If an external static library declares their own
.=and.==operators it's likely you will have this same issue anyway.@JCSooHwanCho commented on GitHub (Jun 15, 2023):
Conflicting with other module is just potential problem, but conflicting within module is present problem. How about focusing on present problem?
@JohnEstropia commented on GitHub (Jun 15, 2023):
Yes, I mentioned here:
Feel free to make a PR ahead, if you have time.
@JCSooHwanCho commented on GitHub (Jun 15, 2023):
I'll make it. Thanks for quick reply!