Closed gyfelton closed 2 years ago
I'm a little confused by the PR description. It would be helpful to include a concrete example of what was broken by this and why. The question I was left wondering is if we couldn't add the missing key when needed in the upstream consumer. Having a setting set to an empty string isn't the same as having it not set. The former will stomp any Xcode default values.
Sorry to hear that, in the rspec there is a new EMPTY_CONFIG that is not preserved before the fix but now is. Correct that having a setting set will stomp any xcode default values, but in this fix the pre-condition is that the key is already present/set by podspec side so the author of podspc has the intention to set it to empty? I could not think of a case where we will accidentally write off other settings and I will run a CI job on the downstream project to ensure about it.
... in this fix the pre-condition is that the key is already present/set by podspec side so the author of podspc has the intention to set it to empty?
Sounds good, thanks for the clarification!
should have done more check but right now downstream gets lot of changes that might backfire when we don't omit the empty values. CI also fails on lots of tests. I start to think this omitting empty values
is done intentionally and it's not really a good idea to fix it via this way. I think I should close this for now
Closing for now as this might do more harm than good without some proper testing. Will bring out the good changes out of this PR as another PR though
Why this change
Because each key will be used in build setting side as substitution, if we just remove the key if value is empty, we will end up not having the substitution to work with in the first place. Here we simply preserve the key value pairs with empty values.
Tests done
Also did the following changes: