1122840 - Split out storage from the rest of the client

Status: RESOLVED FIXED

(Firefox for iOS :: Build & Test, defect)

Description

[Richard Newman [:rnewman]]

Having a single monolithic project makes our sub-applications (ShareTo, SendTo) larger than they need to be, and also harms our build times.

We should start splitting out frameworks, starting with a division between "storage" (databases, cursors, schemas) and "client" (frontend, UI).

Comment 1

[Richard Newman [:rnewman]]

Attachment: Proposed patch. v1

Let's see who gets to this first.

This is a decent first step, I think.

Comment 2

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

This looks good to me. I'm curious why you decided to make Storage a completely new project instead of a new target within the Client project. I don't have a strong preference for either but a new target seemed more logical since that is also what happens to the embedded App Extensions for example.

Comment 3

[Richard Newman [:rnewman]]

I picked a new project for a few reasons:

1. It seems to offer the most potential for perf improvements. Dependent project + framework => only rebuilds when a file in that project has changed. It looks like the Swift compiler currently builds every Swift file in a project when any file in the project changes, regardless of any dependency analysis. That'll be fixed in time, but right now this seems to be the only way to make builds quicker.

2. Files can't easily span multiple projects. That's not the case for targets; it's easy for them to be members of multiple targets, which very much blurs dependency analysis.

3. Better modularity. In the course of splitting this up, you can see some of the public-ing I had to do, which encourages thinking about public/protected APIs. The same goes for tests, where Sync lives, etc.

4. This was an excellent experiment in how to set up a dependent framework project with a non-module header (sqlite3.h). If we can do this, we can take (or create) a dependency on just about anything, because this is just about as hard as it gets.

Comment 4

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

1. It is not true. With a target you get the same build artifact, a framework, and the same rules for rebuilding that framework: only if one of the target sources changes. Or if the project that embeds the framework requests a full clean build.

2. This is an artificial reason. If you make a file a member of a specific target then it is perfectly clear when it should be built. For example, Xcode does not look at the files in our extensions when you make a change in the main application. That would be exactly the same with a framework target. No blurred lines.

3. Same with a framework target.

I am worried that we are making our project already more complicated than it should be. For the wrong reasons.

Comment 5

[Richard Newman [:rnewman]]

To answer one of Stefan's 'angel' objections:
 
> 2. This is an artificial reason. If you make a file a member of a specific
> target then it is perfectly clear when it should be built.

I actually meant _human_ dependency analysis, not compilation. I'd assert that our abstractions are better if our tools help us to enforce modularity, rather than giving us a one-click checkbox to break it.


Landed; if it gets too painful, then we can merge the projects and just do a target.

https://github.com/mozilla/firefox-ios/commit/e0fcbf5ca5f320f6194b63429f1570b605464714

Comment 6

[Wesley Johnston (:wesj)]

Comment on attachment 8550642 [details] [review]
Proposed patch. v1

Cleaning up. But also, we've hit some problems with this and test automation. I'm not sure if we want to revert it or not...