In AOSP's build system, Soong (https://source.android.com/setup/build) is the Makefile generator. At least in the C and Java builders, modules are sort of like make targets; you give them a list of source files, some flags, and other details, and they'll output a massive Ninja build file. The build files themselves are kind of like JSON; it might be possible to use the same build files, but modify the build system to work in a more friendly manner?
To be honest though, I don't really know that much about how Android uses HALs. It looks like with Oreo, Google added HIDL and Project Treble to make devices easier to update, but I don't know much about before that. On Tue, Mar 10, 2020 at 9:34 PM Denis 'GNUtoo' Carikli <[email protected]> wrote: > > On Tue, 10 Mar 2020 09:29:38 -0500 > Joel Valenciano <[email protected]> wrote: > > > Yeah, I was asking about running on top of GNU/Linux. I think it > > should be possible; the Compatibility Definition Document > > (https://source.android.com/compatibility/overview) only requires ABI > > compatibility for a few native libraries, and most of that is covered > > by, for example, libhybris. > On one side it's meant to interface with the hardware specific > libraries that usually implement HAL API. Do you have some ideas on > what API it implements on the other side? Does it fully replace the HAL? > > For the framework there is also the issue of the JVM and things like > that, and I don't know much standalone can the Android components be. > > I probably need to find the time to do some research to find out if > there are other free software projects that have been or are doing that. > > > The build system does have "packages", I think, in the form of > > modules. The names used in Makefile LOCAL_MODULE definitions and > > Blueprint modules have to be unique, I think; a while ago I tried > > running the build system with just the frameworks, libcore and art > > repositories, and I got several "undefined module" errors. Maybe the > > license information could be added there as variables or Blueprint > > properties? > What I mean by packages is that a given build system has files, with > metadata about the package (like the license), that also has > instructions to wrap a low level build system like autotools or cmake, > and at the end a real package is produced. > > The package can then be used to construct an image that can be > installed on the device. > > Having a package manager on the target device would also be nice but > it's not strictly necessary yet as we didn't look into which process we > could use to reduce up the amount of time between updates. > > The GNU/Linux equivalent of the Android build system would be to use a > huge a repository with tons of submodules, each with the same build > system (like automake) which at the end produce an image. > > This is probably done for software like Chromium for instance. > > The issue with that kind of approach for a complete OS distribution is > that you start having huge issues when you want to integrate software > that have other low level build system like autotools or cmake. > > Each time you run a build, it needs to run make in the Linux source > code, even if nothing has changed. And the more we integrate GNU/Linux > components in Replicant, the more the build becomes painfully slow. > > And for MESA it's way worse than that as some changes aren't detected > at all. > > When moving a library in the target rootfs, the old library is also > kept, which can cause issues. > > > And I think the host-side utilities are linked to the version of Glibc > > in the AOSP's prebuilts repositories. Running "readelf -d" on adb says > > it's linked to "libc.so.6". > That's really interesting. > Thanks a lot, I really need to look into it. > > Denis. _______________________________________________ Replicant mailing list [email protected] https://lists.osuosl.org/mailman/listinfo/replicant
