Closed allewun closed 7 years ago
@chhaylatte FWIW your suggestion to use the Pre-action for the Build scheme is great, and it solves the problem essentially the same way I did (though yours does feel a bit cleaner in that the user doesn't have to edit the Pods target at all).
I took a quick look, and I'm not seeing any API for the xcodeproj
gem to add a Run Script to a scheme, so I'll stick with my current approach (using xcodeproj
to add a Run Script to a target).
Final comment, after these changes, the benefits of the post_install
hook barely outweigh manually making the changes to the project. IMO it's still preferable, because it exposes things and makes it clear what's happening. But moving install responsibility to the client and not pod install
was unavoidable I think...
I don't know ruby but it looks fine to me. Now if only we had api to edit the scheme...
Looks good to me as well :)
Fixes #14
@pkluz @rweindl @chhaylatte.
The problem was that the Pods project gets built before the main app project. The Build Script we were adding was part of the app target, so even moving it before the
Compile Sources
phase wouldn't move help, since by this point the Pods project has already been compiled.Auxiliary problem: The .podspec's
prepare_command
doesn't appear to fire when we need it to (it fires only on download, not every timepod install
is invoked). Unfortunately, we need to move the responsibility to the client via apost_install
hook.I've created a new script and streamlined this manual step as much as possible. It's documented in the README.