История изменений
Исправление EXL, (текущая версия) :
Мне что-то не получилось подружить -MD с вилдкардом и subst. android ndk тоже использовал sed или awk для автоподмены путей в .d файлах.
А я вот с теплотой вспоминаю старую сборочную систему проектов Android NDK на Makefile Engine. Похожая используется у libopencm3 и DevKitArm (GBA, DS). Просто. Логично. Понятно. Удобно.
Подобные системы «Makefile’ов на стероидах» позволяют гибко управлять различными аппаратными особенностями платформ. К примеру, в Android NDK было сделано так, что при наличии в имени файла ARM-постфикса source.c.arm он компилируется с -marm вместо -mthumb, аналогично Makefile Engines для GBA файлы с постфиксом source.c.iwram помещали скомпилированный код внутрь быстрой IWRAM вместо RAM, а source.c.arm7 давал возможность запуска кода на втором ARM7-сопроцессоре вместо основного камня.
С переходом Android NDK на CMake эта гибкость и логичность Makefile Engines улетучилась, а проекты начали использовать вот такие вот убогие костыли из-за ограниченности CMake перед классическими Makefile.
Стало:
Было:
https://github.com/libsdl-org/SDL/blob/d7939abf42de34fff409f5e7c4b77ace79dff4de/Android.mk#L25-L26
Вместо того чтобы явно указывать -marm только там где это нужно, они серут -marm -mthumb и надеются на господа Бога, что поведение выбора режима процессора в компиляторах не изменится. Такой вот современный CMake макакинг.
Исправление EXL, :
Мне что-то не получилось подружить -MD с вилдкардом и subst. android ndk тоже использовал sed или awk для автоподмены путей в .d файлах.
А я вот с теплотой вспоминаю старую сборочную систему проектов Android NDK на Makefile Engine. Похожая используется у libopencm3 и DevKitArm (GBA, DS).
Подобные системы «Makefile’ов на стероидах» позволяют гибко управлять различными аппаратными особенностями платформ. К примеру, в Android NDK было сделано так, что при наличии в имени файла ARM-постфикса source.c.arm он компилируется с -marm вместо -mthumb, аналогично Makefile Engines для GBA файлы с постфиксом source.c.iwram помещали скомпилированный код внутрь быстрой IWRAM вместо RAM, а source.c.arm7 давал возможность запуска кода на втором ARM7-сопроцессоре вместо основного камня.
С переходом Android NDK на CMake эта гибкость и логичность Makefile Engines улетучилась, а проекты начали использовать вот такие вот убогие костыли из-за ограниченности CMake перед классическими Makefile.
Стало:
Было:
https://github.com/libsdl-org/SDL/blob/d7939abf42de34fff409f5e7c4b77ace79dff4de/Android.mk#L25-L26
Вместо того чтобы явно указывать -marm только там где это нужно, они серут -marm -mthumb и надеются на господа Бога, что поведение выбора режима процессора в компиляторах не изменится. Такой вот современный CMake макакинг.
Исправление EXL, :
Мне что-то не получилось подружить -MD с вилдкардом и subst. android ndk тоже использовал sed или awk для автоподмены путей в .d файлах.
А я вот с теплотой вспоминаю старую сборочную систему проектов Android NDK на Makefile Engine. Похожая используется у libopencm3 и DevKitArm (GBA, DS).
Подобные системы «Makefile’ов на стероидах» позволяют гибко управлять различными аппаратными особенностями платформ. К примеру, в Android NDK было сделано так, что при наличии в имени файла ARM-постфикса source.c.arm он компилируется с -marm вместо -mthumb, аналогично Makefile Engines для GBA файлы с постфиксом source.c.iwram помещали скомпилированный код внутрь быстрой IWRAM вместо RAM, а source.c.arm7 давал возможность запуска кода на втором ARM7-сопроцессоре вместо основного камня.
С переходом Android NDK на CMake эта гибкость и логичность Makefile Engines улетучилась, а проекты начали использовать вот такие вот убогие костыли из-за ограниченности CMake перед классическими Makefile.
Стало:
Было:
https://github.com/libsdl-org/SDL/blob/d7939abf42de34fff409f5e7c4b77ace79dff4de/Android.mk#L25-L26
Вместо того чтобы явно указывать -marm только там где это нужно, они серут -marm -mthumb и надеются на господа бога, что поведение выбора режима процессора в компиляторах не изменится. Такой вот современный CMake макакинг.
Исходная версия EXL, :
Мне что-то не получилось подружить -MD с вилдкардом и subst. android ndk тоже использовал sed или awk для автоподмены путей в .d файлах.
А я вот с теплотой вспоминаю старую сборочную систему проектов Android NDK на Makefile Engine. Похожая используется у libopencm3 и DevKitArm (GBA, DS).
Подобные системы «Makefile’ов на стероидах» позволяют гибко управлять различными аппаратными особенностями платформ. К примеру, в Android NDK было сделано так, что при наличии в имени файла ARM-постфикса source.c.arm он компилируется с -marm вместо -mthumb, аналогично Makefile Engines для GBA файлы с постфиксом source.c.iwram помещали скомпилированный код внутрь быстрой IWRAM вместо RAM, а source.c.arm7 давал возможность запуска кода на втором ARM7-сопроцессоре вместо основного камня.
С переходом Android NDK на CMake эта гибкость и логичность улетучилась Makefile Engines, а проекты начали использовать вот такие вот убогие костыли из-за ограниченности CMake перед классическими Makefile.
Стало:
Было:
https://github.com/libsdl-org/SDL/blob/d7939abf42de34fff409f5e7c4b77ace79dff4de/Android.mk#L25-L26
Вместо того чтобы явно указывать -marm только там где это нужно, они серут -marm -mthumb и надеются на господа бога, что поведение выбора режима процессора в компиляторах не изменится. Такой вот современный CMake макакинг.