-
Notifications
You must be signed in to change notification settings - Fork 258
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Regression: Unexpected clang argument for extension targets #92
Comments
Just to make sure I'm understanding your issue:
And the PR you linked is definitely the one that causes it? I wouldn't expect that one to affect it. |
The PR I linked is the first one that starts to show the error for me. I wonder if it's because
|
Ok, having I'll take a stab at it soon. The code you cited wasn't intended to change the behavior, but it's possible there was a subtle change there. |
@allevato - Thanks! |
@allevato - I was actually able to remove the dependency to unblock the issue. I still think you should have a way to disable this but just wanted to give you a heads up. |
I realized this morning that there's actually nothing to be done here. The Even though you've already unblocked yourself, if you build Bazel from HEAD, the problem should go away. Since we're moving fast with the Apple Skylark rules and they often require changes to Bazel's core, we're kind of avoiding keeping features in sync with official releases right now. In the future if we |
If we....? : 🍿 |
Oops 😄 In the future if we fix the handling of the flag at the binary level, then we can revisit the "escape hatch" and have an attribute on the bundling rules that does the "escape hatch" behavior described above. |
@allevato - Would it be possible to use GH releases to have notes for when |
@c-parsons :
We have a share and siri
ios_extension
rule in our application and they have a few dependencies like the Facebook SDK.They've been building correctly but as of this PR we are getting failures because
-fapplication-extension
is passed and fails on third-party code.Additionally we are unable to specify
extension_safe=False
in our rule definition without encountering an error since it seems to already be hard-coded toTrue
.The text was updated successfully, but these errors were encountered: