Skip to content
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.

Sign up for GitHub

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

Zip Builder V2 Plan #4341

Merged
merged 3 commits into from
Nov 26, 2019
Merged

Zip Builder V2 Plan #4341

Changes from 2 commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
7e91bb9
Zip Builder V2 Plan
paulb777 Nov 18, 2019
0d86b87
whitespace
paulb777 Nov 18, 2019
e9ef2cc
Review feedback
paulb777 Nov 22, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
58 changes: 58 additions & 0 deletions ZipBuilder/ZipBuilderV2Plan.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,58 @@
V2 will add an option to generate a zip distribution of binary frameworks from an arbitrary list
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are a few different capitalizations throughout (and throughout existing docs, which should be changed eventually). In an effort to keep it consistent, what do you think about:

  • zip referring to a file that has the .zip extension, Zip if at the start of a sentence
  • the Zip Builder (capitalized with a space) for the product that will be building zip files
  • ZipBuilder for referring to the code and tool itself

I'm open to other suggestions as well but we should try to keep it consistent throughout if possible.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

of source and binary CocoaPods.

## Introduction

The current [Zip Builder](https://github.com/firebase/firebase-ios-sdk/tree/master/ZipBuilder)
is Firebase specific. This is a proposal and initial plan
to evolve the Zip Builder into a multi-purpose Apple binary framework creation tool.

It would be useful to have a generic
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Spacing seems wrong here, more can fit on this line

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

zip builder for other Google SDKs and other open source projects. In addition,
providing a generic ZipBuilder would enable Firebase users to generate binary
frameworks for configurations outside the standard Zip and Carthage distributions
released in the standard Firebase release process.

With the extra flexibility, the Zip Builder will be useful for both SDK distributors
to package binary distributions and app developers who want a customized binary
distribution that maps exactly to their app's requirements and provides a clean
build time speed up.


## Background

A more flexible zip builder would enable the following scenarios:

* Creating a zip distribution from an arbitrary set of pods
* Support different building different sets of platform slices
* Support building with different Xcode versions
* Build only the subspecs needed for use case
* [Existing solutions](https://github.com/firebase/firebase-ios-sdk/issues/4284#issuecomment-552677044)
are intermittently maintained and written in Ruby. A Swift-implementation is
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: no -?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

more accessible and maintainable by the Apple community.
* The Swift implementation will be easier to add Swift Package Manager support for which
there will likely be a need since Swift Package Manager is even more source-centric than
CocoaPods.

## Plan

1. Add `--zipPods {JSON file}` option. The JSON file contains a list of CocoaPods
along with an optional version specifier. If the version is not specified, a CocoaPods
install will determine the version - typically the latest, unless another pod requires
something lower.

1. Add `--minimum-ios-version {version}` option. Specify the minimum iOS version to build for. Default
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know it's awful for iOS but we should stick with the same camel-case convention for args, this should likely be --minimumIOSVersion, or we should switch over to use - everywhere in arguments (I'm fine with that as well).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

is 8.0.

1. Add `--archs {archs list}` option. Default is "arm64, arm64e, armv7, i386, x86_64"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the future when we add Catalyst support, how will we handle x86_64? Would it do both simulator and Catalyst, or would it rely on an extra flag being passed?

I think default to simulator and needing an extra flag for Catalyst seems reasonable but thought I'd check.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm. We'll need to think more about how to evolve this towards adding Catalyst and eventually only building xcframeworks instead of frameworks when we can drop Xcode 10.

I'll clarify this in Future Directions.


Unlike the Firebase zip build which builds a two-level zip file with a configurable set of
installation, when `--zipPods` is specified a single zip file of frameworks will be created.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will we have Resources embedded in the .framework files like Carthage or pull them out into a common directory like the Firebase zip file?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since the non-Firebase zip is completely new, it seems reasonable to simplify and stop moving the Resources around in the distribution.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SGTM - just wanted to clarify that.


## Future Directions

* Binary support for Catalyst
* Other Apple platforms besides iOS
* Swift Package Manager
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the idea here to make a binary for Swift package manifests? Or something else?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. Swift Package Manager will likely only increase the desire for SDK distributors and app developers to have pre-compiled frameworks.

* Dynamic Framework support
* More option customization