Is there anybody working on a generator for the Android Open Source Project (AOSP) build system, called Soong? It uses so-called Blueprint files (.bp file extension), which have a JSON-like syntax, but are unique to this build system.
I haven’t seen any mention of it come up in the issue tracker or discourse forum so far.
Alright. Thanks. I’ll clone CMake and see how difficult it will be to add one.
I would take a look at the existing Android.mk support. It’s not a build using Android.mk, but it does make CMake’s targets available to other Android.mk-using projects.
Google has deprecated the makefiles in AOSP in favor of the newer Blueprint system. It it unreasonable to expect the Make-based build components to get guaranteed support. They have an interim solution, for now.
Eventually, I expect Google will shift again over to Bazel.
In that case, I suspect CMake’s support becomes irrelevant because (AFAIK) Bazel is utterly allergic to code not built by itself anyways.
It’s not feasible for CMake to be able to Generate Bazel build files? It’d be nice to be able to write one set of build scripts that can handle vanilla UNIX, Windows, macOS, and Android (which matters, in that AOSP is so alien in how it handles building and incorporating native code and shared libraries that it necessitates focus in accordance to its own build system as standard Linux build methodologies will not work).
AFAIK, no. Bazel has its own model of how libraries and whatnot work. The other generators work because CMake has a lot more control over the command lines and can put things together as needed. The IDEs tend to be the limiting factor in a number of things because they don’t allow all features to work as CMake intends/promises. It’s why CMake doesn’t support literal makefile snippets or all the features of ninja rules in its model. There are some generator-specific features, but they don’t affect the correctness of the build; usually optimizations or the like.
Actually you may simply use the Gradle’s CMake support for native parts of Android apps, I think
That’s cool, but the problem is that the AOSP project does not use
Gradle to organize builds. Everything, including the bundled apps, is
built using a custom-made build system called Soong, and Soong uses
build files called Blueprints. Actually, pardon if I deviate a bit, but
this needs to be said to avoid confusion. In the AOSP documentation you
may see reference to the something called “Android Blueprints”, or
something to that effect. The best that I can tell is that such is
usually referring to the build description files Soong uses, which are
called blueprints.
Back on topic, wherein it might be beneficial to add support for Soong
to CMake is two-part:
(Disclaimer: I do not work for Google. I am just a developer interested
in working on Android)
1.) AOSP (and Android in general) uses a significant number of
third-party libraries and executables. Currently, adding new libraries
requires writing new blueprint files for the Soong build system. As a
large number of projects use CMake to script builds, adding an Android
blueprint generator to CMake would ease maintenance burdens.
2.) Being able to script builds in CMake and trusting that CMake could
generate either blueprint files or regular makefiles as desired would
make testing new ideas and concepts for AOSP and its derivatives outside
of the Android environment for initial testing and refinement easier.
I do not mean to gloss over the amount of work it would take to create
and maintain such a generator. My only goal is to present arguments in
favor of its development. It is worth keeping in mind that this would
also benefit those who wish to create custom derivatives of AOSP, not
just Google.