Ant + cpptasks vs. scons vs. make

Ответ 1

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

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

Скобы лучше, но перекрестная компиляция не является его сильной стороной. Это не "система сборки", как CMake или Autotools, это всего лишь инструмент построения. Как говорится в своей вики, это в значительной степени "Make in Python" . Однако у него есть встроенная обработка зависимостей, а это значит, что вам не нужно сворачивать свои собственные с помощью "gcc -MM -MD" или что-то еще, так что это преимущество перед Make. У SCons также есть поддержка для обнаружения сторонних библиотек, которые установлены, но способ, как это обычно делается, может значительно увеличить время сборки. В отличие от других систем, SCons запускает этап проверки каждый раз, когда вы его запускаете, хотя большинство результатов кэшируется. SCons также печально известен своими долгими сроками сборки, хотя для 50 файлов это не проблема. Поддержка кросс-компиляции в SCons отсутствует - вам нужно перевернуть свой как обсуждалось в этом потоке в списке рассылки. Как правило, вы принудительно устанавливаете сборку как платформу Unix, а затем переопределяете имя компилятора C. Создание нескольких вариантов или разделение каталога сборки из исходного каталога полна gotchas, что делает его менее подходящим, если вы переходите и изначально компилируете свой код.

У CMake и Autotools проблемы с зависимостью выясняются довольно хорошо, а поддержка кросс-компиляции autotools является зрелой. У CMake была перекрестная компиляция с версии 2.6.0, выпущенная в апреле 2008 года. Вы получаете эти функции бесплатно, плюс другие, такие как упаковка и запуск модульных тестов ( "make check" или аналогичные цели). Недостатком обоих этих инструментов является необходимость начальной загрузки. В случае с CMake вам необходимо установить бинарный файл CMake для создания файлов решений Makefile или Visual Studio. В случае с Autotools это немного усложняется, потому что не каждому, кто компилирует программное обеспечение, потребуется установить automake и autoconf, только те, которые должны изменить систему сборки (добавление новых файлов учитывает изменение системы сборки). Двухступенчатая загрузка (configure.ac → configure, configure + Makefile.in → Makefile) концептуально немного сложнее понять.

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

Ответ 2

Я использовал Ant + CppTasks в течение нескольких лет для создания очень больших кодовых баз, интегрированных в новый код Java через JNI, и был очень доволен результатом очень надежных инкрементных построений кода на С++, хорошей гибкости (в файлах сборки или с помощью настроек кода). НО, CppTasks - это проект без сообщества, а сопровождающий (Курт Арнольд) долгое время ничего не делал с ним. Он остается очень хорошим и полезным, но имейте в виду, что мало кто знает или использует CppTasks (способ компиляции "ставок" для файлов укусит меня, например, когда мне нужен конкретный компилятор для файлов C, а другой компилятор С++ собирал их вместо этого).

Способ, которым CppTasks отслеживает параметры компиляции и динамически сканирует источники для зависимостей заголовков, все время достаточно быстро (там некоторое кэширование зависимостей), означает единственную систему, с которой я работал, с точной инкрементной сборкой, что-то очень важно при создании очень больших кодовых баз.

Итак, как я уже говорил несколько раз в списках user/dev Ant, если у вас много материала Java и уже есть инвестиции в Ant, и вы не боитесь погружения в документ и код CppTasks, а теперь необходимо создать JNI-код "клей" и/или "устаревшие" собственные библиотеки, которые предоставляет код клея, это достойный соперник, и награды могут быть большими.

Я легко интегрировал <rc> для Windows dll добавить полную информацию о версии, например, написать небольшую задачу Ant для правильного форматирования файла .res. Это сработало для меня, но Ant + CppTasks определенно больше подходит для "продвинутого" пользователя Ant пользователя/разработчика IMHO.

Надеюсь, это поможет. --DD

Ответ 3

Я бы рекомендовал terp для создания проектов на С++ из ANT. Мы разработали терп, потому что ANT - наш выбранный инструмент сборки, а CppTasks немного укоренились в зубе и потому что мы хотели работать на другом уровне абстракции. Терп поддерживает множество разных компиляторов и поддерживается нашей компанией. Для большинства проектов это не бесплатно.

Мы разработали терп в основном для полных перестроек, а не для инкрементных построений с анализом зависимостей. Мы добираемся туда, но это еще не все. Сладкое пятно для терпа в многоплатформенных, многопроцесарных, многокомпиляционных версиях, где вы не хотите поддерживать n разных конфигураций для всех комбинаций. На этом этапе (июль '09) он находится в публичной бета-версии, но скоро будет выпущен.

Ответ 4

Я работаю над проектом за последние пять лет, который создает x86 и arm, используя ant. Мы настроили cpptasks для наших целей, чтобы создать общий компилятор, который мы просто передаем в префикс... например arm-gum-linux-gnueabi-, а затем он добавляется к реальному инструменту, например g++ или ar или что-то еще. Префикс не означает, что вы получаете инструменты для разработки платформ разработки. Инструментальные цепочки для кросс-компиляции имеют эти префиксы для двоичных файлов инструмента сборки. Почти вся причина перехода с Ant, а не на что-либо из основанных, была способностью cpptasks делать inremental builds и излишним путаницей вещей, которые должны произойти, чтобы сохранить autoconf счастливым. Мы можем поддержать парадигму о том, что практически любой исходный файл, особенно те, которые находятся в структуре дерева папок для набора библиотек, могут быть созданы/переименованы/удалены, и никакие изменения не должны произойти с файлами сборки. Один маленький недостаток заключается в том, что связывание файлов обновляет свойства таким образом, что это приведет к ненужной перестройке.

<target name="lib.cvp">
<fetch.and.log.version 
    svnvers.target="common/cvp" 
    svnvers.property="libcvp.version"/>
    <cc objdir="${obj.dir}/common/cvp" 
        commandPrefix="${command.prefix}" 
        compilerName="${compiler.name}"
        outfile="${lib.dir}/cvp" outtype="static">
        <compiler extends="base.compiler"/>
        <compilerarg 
            value="-D__CVP_LIB_BUILD_VERSION__=&quot;${libcvp.version}&quot;"/>
        <compilerarg 
            value="-D__BUILD_NOTES__=&quot;${libcvp.toolversion}&quot;"/>
        <compilerarg if="is.x86" value="-DARCH_X86"/>
        <linker extends="base.linker"/>
        <includepath refid="common.inc"/>
        <fileset dir="${project.home}/common/cvp">
            <include name="*.c"/>
            <include name="*.cpp"/>
        </fileset>
    </cc>
</target>

Ответ 5

Ant имеет очень Java-тяжелую пользовательскую базу (по естественным причинам). Тот факт, что Ant может быть очень полезен в гораздо более широких настройках, - это то, о чем не знают большинство разработчиков, отличных от Java. В результате, если вы используете Ant для создания своего кода на C/С++, вы гораздо больше по своему усмотрению, если используете систему с более широкой базой пользователей (CMake или SCons).

Лично я был очень доволен CMake, прежде всего потому, что это единственная система сборки, которая может генерировать реальные проекты Visual Studio. SCons тоже могут, но они только делают внешний вызов для SCons, тогда как CMake генерирует проекты, которые используют собственный механизм сборки Visual Studio. Это очень полезно, если вы работаете вместе с людьми, которые привыкли к Visual Studio.

Я не уверен, что я позвоню в поддержку CMake для кросс-компиляции "зрелый", так как он все еще довольно молодой. Но люди CMake серьезно относятся к этому, поэтому я бы не стал сомневаться в этом.