-
Notifications
You must be signed in to change notification settings - Fork 85
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
remove infoplists_by_build_setting #612
Comments
cc @thiagohmcruz @luispadron if you have any objections to this please LMK - we can work together to fix any upstream code that depended on this key and provide a suggestion for people moving off of it. |
Agree we should get rid of it. After thanksgiving I'll look to update the plist processing to happen at analysis phase. From there we should be able to use the normal After that, we can deprecate or remove the field. How does that sound to y'all? |
@luispadron cool - let's sync up at a later point in time on this. There is a couple obscure and newer feature in cocoapods that makes this harder to reason about. I had to patch up some related code that required the previous behavior to noop. I think that aside your PR is more ideal / in the right direction. Today the downside is you need the same exclusivity / configuration outcome of |
After digging into this a bit more, we can re-work some code to add better support this API. I had moved the xcconfig mapping to configuration time here: #618 |
The API doesn't have any tangible benefit AFAIK but would love to learn otherwise. In Xcode there is no idiom of a per infoplist xcconfig so likely this just makes the rules more confusing to use.
This also fixes the issue raised in this change, which had to merge the keys of
infoplist_by_build_setting
: 66afc58The text was updated successfully, but these errors were encountered: