Я работаю с деревом Android P (на основе AOSP), полученным от поставщика.
Поставщик где-то испортил зависимости сборки, и это полностью нарушило инкрементные сборки: "make" выполняется во второй разпосле только что успешно завершенного «make» хочет перестроить более 10000 целей.
Я знаю обо всех этих трюках с «mmma this / dir && make snod», но это не дает правильного результата при изменении основных библиотек Java(в частности, dex2oat не выполняется для всех необходимых целей).Чтобы получить правильный образ после смены базовых библиотек Java, нужно сделать хотя бы «make systemimage».
Я устал ждать бесполезных перестроек и искать практический метод для обнаружения / исправления сломанных зависимостей.Из предыдущего опыта работы с другими поставщиками я знал, что зависимости могут быть установлены правильно, чтобы работали инкрементные сборки.
Может кто-нибудь дать какие-нибудь подсказки о том, как выяснить, почему данная цель перестраивается в системе сборки AOSP?
Похоже, что инструмент "ниндзя" должен быть в состоянии сказать, почему он перестраивается, но я несколько застрял в попытке выяснить, как - учитывая, что сгенерированный файл .ninja внутри AOSP превышает 700 М, что слишком многодля любого анализа руками, и «ниндзя -d объяснение» только говорит, что что-то грязное, но не говорит, почему.