ant+cpptasks по сравнению со сканированиями по сравнению с делают

Для кросс-компиляции, я думаю, ваш лучший выбор - CMake или Автоинструменты . Особенно, если вы можете скомпилировать свой код для нескольких архитектур / платформ. Обычно я компилирую подмножество своего кода на собственной машине для целей модульного тестирования и все это для целевой платформы. CMake справляется с этим особенно хорошо, поскольку позволяет указать, где находятся кросс-скомпилированные библиотеки. Поэтому вместо того, чтобы искать кросс-скомпилированный libpng в / usr / lib, можно сказать, что нужно искать в / opt / arm-eabi-gcc / или там, где на вашем компьютере сборки установлены библиотеки цепочки инструментов. Вы можете создать несколько каталогов сборки для разных вариантов и вручную скомпилировать каждый вариант с помощью make, или запустить серию с помощью безумной ручной рекурсивной make.

Ant имеет недостаток в том, что он в основном так же хорош или так же плох, как и vanilla Make , с дополнительным недостатком, заключающимся в том, что вы используете что-то, что не является особенно популярным для C или C ++. Вы должны иметь дело со всеми своими собственными зависимостями - как внутренними, такими как файл C, файл заголовка, библиотекой или исполняемым файлом, так и внешними зависимостями, такими как необходимость связывания со сторонними библиотеками. К тому же я не думаю, что задачи Ant C поддерживаются так часто. Все, кого я видел, кто использует Ant для C, выступают за вызов GCC с задачами exec.

SCons лучше, но кросс-компиляция не его сильная сторона. Это также не «система сборки», такая как CMake или Autotools, это всего лишь инструмент сборки. Как написано в их вики, это в значительной степени «Сделай на Python» . Тем не менее, он имеет встроенную обработку зависимостей, а это означает, что вам не нужно кататься там с помощью "

В CMake и Autotools проблемы с зависимостями решены достаточно хорошо, а поддержка кросс-компиляции autotools является зрелой. В CMake кросс-компиляция существует с версии 2.6.0, выпущенной в апреле 2008 года. Вы получаете эти функции бесплатно, а также другие функции, такие как упаковка и запуск модульных тестов («проверка выполнения» или аналогичные цели). Обратной стороной обоих этих инструментов является то, что они требуют начальной загрузки. В случае CMake вам необходимо установить двоичный файл CMake для создания файлов Makefiles или Visual Studio. В случае с Autotools это немного сложнее, потому что не всем, кто компилирует программное обеспечение, потребуется установка automake и autoconf, а только те, которым необходимо изменить систему сборки (добавление новых файлов считается изменением системы сборки). 2 этапа начальной загрузки (configure.ac -> configure, configure + Makefile.in -> Makefile) концептуально немного сложнее для понимания.

Для правки: кросс-компиляция - дополнительная головная боль в системах сборки по той причине, что она усложняет автоматическое обнаружение программ и библиотек. SCons не решает эту проблему, решать вам. Муравей тоже ничего не делает. Autoconf обрабатывает это в случае autotools, но вам, возможно, придется указать "--with-libfoobar = / some / path" в командной строке, когда вы настраиваете или сталкиваетесь с нарушением связывания, когда он пытается использовать / usr / lib на этапе связывания . Подход CMake немного сложнее с файлом цепочки инструментов, но это означает, что вам не нужно указывать все инструменты и библиотеки (CC, CXX, RANLIB, --with-ibfoo = и т. Д.), Как они выяснены из стандартное соглашение. Теоретически вы можете повторно использовать специально созданный файл цепочки инструментов CMake в нескольких проектах для их кросс-компиляции. На практике CMake недостаточно широко распространен, чтобы сделать это удобным для среднего хакера, хотя он может быть полезен, если вы создаете несколько частных проектов.