Page MenuHomePhabricator

[iOS] Delete libPods-Comm.a dependency
ClosedPublic

Authored by tomek on Feb 15 2022, 4:57 AM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Nov 14, 6:07 AM
Unknown Object (File)
Sun, Nov 10, 7:30 AM
Unknown Object (File)
Thu, Nov 7, 5:31 AM
Unknown Object (File)
Thu, Nov 7, 5:31 AM
Unknown Object (File)
Nov 2 2024, 8:07 AM
Unknown Object (File)
Nov 2 2024, 8:07 AM
Unknown Object (File)
Nov 2 2024, 8:06 AM
Unknown Object (File)
Nov 2 2024, 8:04 AM

Details

Summary

This is not needed yet and causes issues on M1.
We probably need that to share the code between the app and notification service extension. This is not implemented yet, so removing it for now doesn't hurt us.
The issue with M1 is that, when the code is checked out, in order to build it, it is required to run pod install (otherwise the app does not build). After running pod install this framework is automatically deleted from the dependency list and the app works correctly.

Test Plan

Check if app builds on both Intel and M1

Diff Detail

Repository
rCOMM Comm
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

tomek requested review of this revision.Feb 15 2022, 5:01 AM

Not it builds on M1 Mac correctly, and after pod install, project.pbxproj is not changed.

This revision is now accepted and ready to land.Feb 15 2022, 8:14 AM
This revision now requires review to proceed.Feb 15 2022, 8:14 AM
In D3197#85584, @def-au1t wrote:

Not it builds on M1 Mac correctly, and after pod install, project.pbxproj is not changed.

Thanks for checking that! (assuming that there's a typo "Now")

Huh interesting, is this something that the CI should have caught?

We can try to be more aggressive about doing a truly clean build on the Buildkite CI. Right now we're only doing a "real" clean build on the GitHub Actions CI, but those are x86 machines.

Could also be that since we're doing Release builds on both Buildkite and GitHub Actions, we're missing issues that only appear in Debug builds?

This revision is now accepted and ready to land.Feb 15 2022, 5:53 PM
In D3197#85623, @atul wrote:

Huh interesting, is this something that the CI should have caught?

We can try to be more aggressive about doing a truly clean build on the Buildkite CI. Right now we're only doing a "real" clean build on the GitHub Actions CI, but those are x86 machines.

Could also be that since we're doing Release builds on both Buildkite and GitHub Actions, we're missing issues that only appear in Debug builds?

It's hard to say. Ideally CI should catch that, but I would like to avoid making the builds take a lot more time in order to achieve that - changes like this aren't going to be frequent.

This revision was automatically updated to reflect the committed changes.