Currently on iOS, Nimbus and Glean are always compiled together as
part of the same Swift module in the iOS megazord. This means that
Nimbus can see and use many of Glean's internal helper functions,
which in fact it does.
When we switch to distributing via Swift packages, we'll need to
be more careful about inter-module hygiene. I think ideally the
Nimbus Swift code would consume Glean as an ordinary Swift dependency
via `import Glean`.
To make that work while also preserving the current behaviour for
current consumers, I have:
* Added a conditional import of Glean, which gets ignored in the
existing megazord but makes Glean available in a Swift package build.
* Copied the internal helper modules that we were using from Glean
into the `nimbus/ios` directory, so that this directory can be
compiled as a standalone Swift module using only public Glean
APIs.
Importantly, I have *not* included the copied utility files in the
iOS megazord Xcode project. That build already uses the ones from
Glean and would error out if we included duplicates.
All in all, this doesn't seem like a sustainable setup, but perhaps
it can be the first step towards something cleaner. Maybe we could
make a shared utility module that both Glean and Nimbus can depend
on? Maybe Glean could commit to making these utilities part of its
public API surface?
Suggestions welcome! What I know is that this helps unblock the work
on publishing as a Swift package in the meantime. Fixes#4308.
This is intended to be a small but significant step on the road to uniffi-ing
places. It takes all the hard stuff from Ryan's #3900, but limits the scope to just
the new-ish history_metadata module.
Co-authored-by: Ryan Kelly <ryan@rfk.id.au>
Co-authored-by: Sammy Khamis <skhamis@mozilla.com>
This makes it more consistent with the other components, which
should simplify our lives when we come to UniFFI it and/or start
distributing it as an independent Swift package.
This makes it more consistent with the other components, which
should simplify our lives when we come to UniFFI it and/or start
distributing it as an independent Swift package.
The FxAClient Swift module is the only thing that uses
the KeychainWrapper extensions, so let's make them live
inline in that codebase. This will simplify eventual
migration to publishing as separate Swift modules.
It's reasonable for mobile-focused consumers to want to be able
to do a quick `cargo build` to test their local checkout, and it's
not reasonable for us to expect them to understand how or why this
is different from building inside Xcode or Android Studio. Let's
help make this Just Work (tm) by verifying the Desktop development
environment whenever we verify a Mobile development environment.
This uses the new, cleaner factoring of our Android config from #4194
as an excuse to update some of our Android dependencies to bring them
inline with what's used in current android-components. It was much
easier than it has been in the past!
This summarizes the results of my prototyping work on Swift Packages
with a concrete proposal for how we should proceed. Given preliminary
feedback I've had so far I have gone ahead and selected a recommended
option, but that is of course up for change if further discussion leads
us in that direction.
Prior to this commit, the `build.gradle` for each individual
project contained copy-pasted logic for configuring Android
and protobuf. Some of them were even using slightly different
versions of the same dependencies.
With this commit, there are two new gradle scripts that encapsulate
this shared logic:
* ./build-scripts/component-common.gradle, for basic Android
and Kotlin setup.
* ./build-scripts/protobuf-common.gradle, for configuration specific
to the protobuf plugin.
Hopefully this will make the logic easier to maintain going forward.
Prior to the commit, the Taskcluster job for each individual component
would execute `./gradlew component:test` and would thus need to build
the Rust code for the megazord.
With this commit, each of those tasks now depend on the existing
`android-build` task which knows how to run all the tests in a single
build. This should reduce the number of times we have to build the
megazord from once-per-components to just once. (Plus the independent
builds we do for actually publishin the megazord).
Prior to this commit, the gradle tasks for building and for testing
each component would depend on the "cargoBuild" gradle task of the
megazord, which means they would built it for all configured targets.
In TaskCluster we configure *seven* targets, so each `module-build-X`
TaskCluster job will build the full megazord seven times.
This commit makes two changes:
* Building the gradle package of a component no longer depends on
building the megazord at all. We doesn't actually need to the
Rust code built in order to package up the Kotlin files, and I
think this dependency was a hangover from when each component
used to build its own individual Rust library.
* Running the gradle tests of a component now depends only on
building the megazord for the native host platform, since that's
the only one that is actually needed for running the tests.
Given that we have 11 components that depend on the megazord,
each of which will now avoid building 6 useless copies of it
for non-native platforms, I expect this will save a total of
66 expensive `cargo build` invocations in a full TaskCluster run.
I've also included a few other tweaks to do less unnecessary
work in TaskCluster, which seem to save about a minute on the
much-more-common `android-build-pr` task.
Prior to this commit, each of our individual components had its
own copy of gradle logic for depending on the megazord, including
a couple of lengthy comments about fiddling around with JNA for
the Android Studio test runner.
I've moved all that logic into a helper function in `publish.gradle`
so that we can maintain it in a single location from here out.
There may be a cleaner or more idiomatic way to achieve this kind
of code-sharing in gradle, but I figure this *has* to be better
than our current copy-paste-based approach.
I've manually confirmed that a local `./gradlew test` completes
successfully, as well as testing via Android Studio.
There's a lot if background info you need to know if you're going
to effectively work on the push component, this tries to add some
pointers to it in the README.
I've also removed what appeared to be an early prototype API doc
since it mostly didn't match what is actually in the code, and
removed the `LICENSE` file for consistency with other components.
Sammy Khamis
Tarik Eshaq
Ryan Kelly
Grisha Kruglov
Mark Hammond
Nishant Bhasin
Mathieu Leplatre
Ryan Kelly