Core
Core copied to clipboard
fixed bug for the target definition of podfile
When the class Pod::Podfile::TargetDefinition merges use_modular_headers_hash and inhibit_warnings_hash, if the inherited class overrides the settings of the parent class, it will cause the final stored data to exist in both types collections, so the data of the parent class needs to be deleted.
For example the following Podfile file
target 'CocoapodsDemo' do
pod 'YYCategories', :inhibit_warnings => true
target 'CocoapodsDemo_dp1' do
pod 'YYCategories', :inhibit_warnings => false
end
end
Set a breakpoint in the function inhibit_warnings_hash, and you will find that the dependency of the final merged result exists in the two sets: for_pods and: not_for_pods
Although cocoapods warning does not support two different settings at the same time, this may be a hidden danger in the future Interestingly, it can be seen from the comments that the purpose is to de-duplicate, but this is not done.
Thanks for your review
hi @talka123456 can you please add a test, a changelog entry and also rebase to latest master? thanks!
When the class Pod::Podfile::TargetDefinition merges use_modular_headers_hash and inhibit_warnings_hash, if the inherited class overrides the settings of the parent class, it will cause the final stored data to exist in both types collections, so the data of the parent class needs to be deleted.
For example the following Podfile file
target 'CocoapodsDemo' do pod 'YYCategories', :inhibit_warnings => true target 'CocoapodsDemo_dp1' do pod 'YYCategories', :inhibit_warnings => false end end
Set a breakpoint in the function inhibit_warnings_hash, and you will find that the dependency of the final merged result exists in the two sets: for_pods and: not_for_pods
Although cocoapods warning does not support two different settings at the same time, this may be a hidden danger in the future Interestingly, it can be seen from the comments that the purpose is to de-duplicate, but this is not done.
Thanks for your review