Все проекты git для AOSP клонируются инструментом репо, который читает этот xml: https://android.googlesource.com/platform/manifest/+/refs/heads/master/default.xml.
Руководство AOSP говорит, что для сборки мы должны запустить source build/envsetup.sh
в папке, где репо клонировало все репозитории. Итак, давайте посмотрим на platform/build
в файле default.xml из репозитория манифеста. Мы получаем
<project path = "build/make" name = "platform/build" groups = "pdk" >
<copyfile src = "core/root.mk" dest = "Makefile" />
<linkfile src = "CleanSpec.mk" dest = "build/CleanSpec.mk" />
<linkfile src = "buildspec.mk.default" dest = "build/buildspec.mk.default" />
<linkfile src = "core" dest = "build/core" />
<linkfile src = "envsetup.sh" dest = "build/envsetup.sh" />
<linkfile src = "target" dest = "build/target" />
<linkfile src = "tools" dest = "build/tools" />
</project>
Подтверждаем, где находится envsetup.sh., это в platform/build
. Он определяет функцию m
, которая, согласно руководству AOSP, строит весь проект AOSP:
function _trigger_build()
(
local -r bc = "$1"; shift
if T = "$(gettop)"; then
_wrap_build "$T/build/soong/soong_ui.bash" --build-mode --${bc} --dir = "$(pwd)" "$@"
else
echo "Couldn't locate the top of the tree. Try setting TOP."
fi
)
function m()
(
_trigger_build "all-modules" "$@"
)
Итак, похоже, что build/soong/soong_ui.bash
— это место, которое вызывается, когда мы запускаем функцию m
, поэтому этот скрипт должен все построить.
Вот soong_ui.bash. Он получает source ${TOP}/build/soong/scripts/microfactory.bash
, а затем вызывает soong_build_go soong_ui android/soong/cmd/soong_ui
Вот microfactory.bash, где мы находим функцию soong_build_go
soong_build_go
{
BUILDDIR=$(getoutdir) \
SRCDIR=${TOP} \
BLUEPRINTDIR=${TOP}/build/blueprint \
EXTRA_ARGS = "-pkg-path android/soong=${TOP}/build/soong -pkg-path github.com/golang/protobuf=${TOP}/external/golang-protobuf" \
build_go $@
}
Находим build_go
в microfactory.bash из build/blueprint:
Похоже, все это для создания проекта microfactory.go. Я думаю, что это как-то связано с системой сборки soong.
Теперь я потерян. Что происходит после сборки microfactory.go? Где строится фактический код Android?
microfactory.sh говорит, что build_go делает следующее: Bootstrap microfactory from source if necessary and use it to build the requested binary.
Запрошенный двоичный файл: android/soong/cmd/soong_ui
Я пытаюсь найти android/soong/cmd/soong_ui
, но я не знаю, что/где это, но я предполагаю, что это система сборки скоро, а не проект AOSP.
ОБНОВЛЯТЬ:
на soong_ui.bash
, я заметил, что он заканчивается на
cd ${TOP}
exec "$(getoutdir)/soong_ui" "$@"
Помните, что это называется формой envsetup.sh
. Ну, ${TOP}
, я думаю, это место, где репо все клонирует. Похоже, он пытается выполнить soong_ui
с аргументами из envsetup.sh
, которые являются --build-mode --${bc} --dir = "$(pwd)" "$@"
, где этот $@
является "all-modules" "$@"
, я думаю.
Я предполагаю, что song_ui
- это скоро исполняемый файл. Он должен искать Android.bp
на ${TOP}
, но я не думаю, что он есть на том месте, где репо все клонировало.
Возьмем make systemimage в качестве примера:
Последовательность вызова такова:
Вы уже многое узнали, и вы правы со ссылкой из m
в soong_ui.bash
и затем начиная microfactory
.
Судя по тому, как я читал код, цель soong_build_go
— собрать пакет android/soong/cmd/soong_ui
с двоичным именем soong_ui
. Как сказал Йонг в другом ответе, это создает двоичный файл soong_ui
в каталоге $(getoutdir) , а источник этого двоичного файла находится в build/soong/cmd/soong_ui/main.go.
Что касается вашего обновленного вопроса о Android.bp
файле, он связан с build/soong/root.bp при запуске repo sync
, но, как вы видите, файл пуст.
Вместо этого в m
он говорит Сунгу построить all_modules , который в конечном итоге запускает другой инструмент под названием kati . Судя по описанию в https://github.com/google/kati , Кати обрабатывает make-файлы GNU и превращает их в файлы сборки Ninja.
На данный момент мы можем (в основном) предположить обычную семантику Make, даже несмотря на то, что базовой системой сборки на самом деле являются Kati, Ninja, Soong и т. д. Поскольку рабочим каталогом является $TOP
, Makefile
в корневом каталоге, на который ссылается build/ make/core/root.mk используется. Который включает main.mk который затем включает build/make/core/Makefile
. Внутри этого make-файла вы можете увидеть, как создаются различные файлы .img
(например, system.img).
Обратите внимание, что прошло некоторое время с тех пор, как я в последний раз просматривал этот код, и система немного изменилась, поэтому вам лучше перепроверить то, что я сказал выше. В частности, я вижу, что build/soong/filesystem/filesystem.go
проверяется совсем недавно, и похоже, что он может заменить некоторые/большую часть пути кода, описанного выше.
Помню, читал про Android.bp, заменяющий несколько make-файлов, но, похоже, он почти не используется. Скоро должны собрать файлы Android.bp, но все, что он делает, это вызывает Кати для сборки make-файлов?
Используются файлы Android.bp. С точки зрения пользователя системы сборки определение цели в .bp эквивалентно ее определению в make. Если вы посмотрите в исходный код build.go, он вызывает ряд действий, включая runSoong, runKati, runNinja и runBazel. Мое (непроверенное) предположение состоит в том, что Сун превращает файлы .bp в ниндзя, а Кати превращает файлы .mk в ниндзя, а затем Ниндзя использует оба для создания выходного артефакта. Я не знаю, какое место занимает Базель.
Я могу дважды подтвердить: Сун анализирует .bp в файлы .ninja. Это упоминается в исходном коде Soong. Bazel представлен только в последних версиях Android (11, 12). Так что, возможно, он еще не получил широкого распространения.
Мне интересно, почему архитектура системы сборки AOSP не имеет открытой документации.