Google develops Soong modular assembly system for Android

Google develops assembly system Soongdesigned to replace the old build scripts of the Android platform based on the use of the make utility. Soong suggests using simple declarative descriptions module assembly rules, given in files with the extension ".bp" (blueprints). The file format is close to JSON and, if possible, repeats the syntax and semantics of assembly files Basel. The code is written in Go and distributed under the Apache 2.0 license.

Soong build files do not support conditional statements and branching expressions, but only describe the project structure, modules and dependencies used in the build. Files to be built are described using wildcards and grouped into packages, each of which is a collection of files with their associated dependencies. It is possible to define variables. Variables and properties are strongly typed (the type of variables is selected dynamically on first assignment, and for properties statically, depending on the module type). Complex elements of assembly logic are moved to handlers, written by in the Go language.

Soong intertwines with a more general project Blueprint, within the framework of which an assembly meta-system that is not tied to Android is developed, which, based on files with declarative descriptions of modules, generates assembly scripts Ninja (replacing make) describing the commands to be run to build and the dependencies. Instead of using complex rules or a domain-specific language to define build logic, Blueprint uses project-specific build handlers in the Go language (Soong is essentially a set of similar handlers for Android).

This approach allows for large and heterogeneous projects, such as Android, to implement complex elements of assembly logic in code in a high-level programming language, while maintaining the ability to make changes to modules related to assembly organization and project structure using a simple declarative syntax. For example, in Soong, the choice of compiler flags is made by the handler llvm.go, and the application of hardware architecture-specific settings is performed by the handler art.go, but the binding of files with the code is carried out in the ".bp" file.

cc_library {
...
srcs: ["generic.cpp"],
arch: {
arm: {
srcs: ["arm.cpp"],
},
x86:{
srcs: ["x86.cpp"],
},
},
}

Source: opennet.ru