mirror of
https://gitlab.winehq.org/wine/wine-gecko.git
synced 2024-09-13 09:24:08 -07:00
f99a3d2d54
This gets us a limited version of AAR support: we can consume static AAR libraries, where here static does not refer to linking, but to static assets that are fixed at build-backend time and not modified (or produced) during the build. This lets us pin our dependencies (and move to Google's versioned Maven repository packages, away from Google's unversioned ad-hoc packages). By restricting to static AAR libraries, we avoid having to handle truly complicated dependency trees, as changing parts of generated AAR files require delicate rebuilding of the APKs (and internal libraries) that depend on the AAR files. It is possible that we will generate AARs in the tree at some time. Right now, we don't do that, even for GeckoView: the AARs produced are assembled as artifacts at package time and are intended for external consumption. We might want this for GeckoView and Fennec at some time; we should consider using Gradle everywhere at that point. The patch itself does the simplest possible thing (which has precedent from Gradle and other build systems): it simply "explodes" the AAR into the object directory and uses existing mechanisms to refer to the exploded pieces. AARs have both required and optional components. Each component is defined with an expected and required flag. If a component is expected and not present, or not expected and is present, an error is raised. If the component is expected and present, autoconf's ifelse() macro is used to define the relevant AAR_* component variables. If the component is not expected and not present, no action is taken. A consuming build backend therefore can guard all AAR_* component variables with just the top-level AAR variable. Many AAR files have empty assets/ directories. This patch doesn't explode empty assets/ directories, protecting against trivial changes to AAR files that don't impact the build. There's a lot not to like in this approach, including: * We need to manually reference internal AAR libs; * I haven't separated the pinned version numbers out of configure.in. However, it's closer to what we want than what we have! |
||
|---|---|---|
| .. | ||
| java/org/mozilla/mozstumbler/service | ||
| manifests | ||
| Makefile.in | ||
| moz.build | ||
| stumbler_sources.mozbuild | ||