Для кросс-компиляции я думаю, что ваш лучший выбор: CMake или Autotools . Особенно, если вы можете скомпилировать свой код для нескольких архитектур / платформ. Обычно я собираю подмножество своего кода на собственной машине для целей модульного тестирования и все это для целевой платформы. CMake справляется с этим особенно хорошо, поскольку позволяет указать, где находятся кросс-скомпилированные библиотеки. Поэтому вместо поиска кросс-скомпилированной библиотеки libpng в / usr / lib можно посоветовать искать в / opt / arm-eabi-gcc / или там, где на вашей машине сборки установлены библиотеки цепочек инструментов. Вы можете создать несколько каталогов сборки для разных вариантов и вручную скомпилировать каждый вариант с помощью make или запустить серию с помощью рекурсивного make, созданного вручную.
У Ant есть недостаток, заключающийся в том, что он в основном такой же или плохой, как vanilla Make, с дополнительным недостатком в том, что вы используете что-то, что не особенно распространено для C или C ++. Вы должны иметь дело со всеми вашими собственными зависимостями - как внутренними, такими как C-файл в файл заголовка для библиотеки или исполняемого файла, так и внешними зависимостями, такими как необходимость связи со сторонними библиотеками. Кроме того, я не думаю, что задачи Ant C действительно так сильно поддерживаются. Все, кого я видел, используют адвокатов Ant for C, обращающихся в GCC с exec заданиями.
SCons лучше, но кросс-компиляция не является его сильной стороной. Это не «система сборки», как CMake или Autotools, это всего лишь инструмент сборки. Как говорится в их вики, это в значительной степени "Make in Python" . Тем не менее, он имеет встроенную обработку для зависимостей, что означает, что вам не нужно накатывать свои собственные с помощью «gcc -MM -MD» или чего-либо еще, так что это преимущество перед Make. SCons также имеет поддержку обнаружения сторонних библиотек, которые установлены, но способ, которым это обычно делается, может значительно увеличить время сборки. В отличие от других систем, SCons запускает этап проверки каждый раз, когда вы его запускаете, хотя большинство результатов кэшируются. SCons также печально известен своим длительным временем сборки, хотя для 50 файлов это не было бы проблемой. Поддержка кросс-компиляции в SCons отсутствует - вы должны указать свой , как описано в этой теме, в списке рассылки . Обычно вы заставляете сборку быть похожей на платформу Unix, а затем переопределяете имя компилятора C. Сборка нескольких вариантов или отделение каталога сборки от исходного каталога содержит множество ошибок, что делает его менее подходящим, если вы кросс-компилируете и нативно компилируете свой код.
В CMake и Autotools проблемы с зависимостями выяснены достаточно хорошо, и поддержка кросс-компиляции в autotools является зрелой. CMake имел кросс-компиляцию начиная с версии 2.6.0, которая была выпущена в апреле 2008 года. Вы получаете эти функции бесплатно, а также другие, такие как упаковка и запуск модульных тестов («make check» или аналогичные цели). Недостатком обоих этих инструментов является то, что они требуют начальной загрузки. В случае CMake вам необходимо установить двоичный файл CMake для создания файлов решений Makefiles или Visual Studio. В случае с Autotools это немного сложнее, потому что не всем, кто скомпилирует программное обеспечение, потребуется установить automake и autoconf, только те, которые должны изменить систему сборки (добавление новых файлов считается изменением системы сборки). Двухэтапная загрузка (configure.ac -> configure, configure + Makefile.in -> Makefile) концептуально немного сложнее понять.
Для редактирования: Кросс-компиляция - это дополнительная головная боль в системах сборки, поскольку она усложняет автоматическое обнаружение программ и библиотек. SCons не справляется с этой проблемой, она позволяет вам разобраться. Муравей так же ничего не делает. Autoconf обрабатывает это в случае с автоинструментами, но вам может потребоваться указать «--with-libfoobar = / some / path» в командной строке, когда вы конфигурируете или сталкиваетесь с неработающими ссылками, когда он пытается использовать / usr / lib на этапе компоновки , Подход CMake немного более сложен с файлом цепочки инструментов, но это означает, что вам не нужно указывать все свои инструменты и библиотеки (CC, CXX, RANLIB, --with-ibfoo = и т. Д.), Как они получены из стандартное соглашение. Теоретически вы можете повторно использовать специально созданный файл инструментария CMake в нескольких проектах для их кросс-компиляции. На практике CMake недостаточно широко распространен, чтобы сделать его удобным для вашего среднего хакера, хотя он может быть полезен, если вы создаете несколько проприетарных проектов.