Каковы различия между Autotools, Cmake и Scons?

Каковы различия между Autotools, Cmake и Scons?

По правде говоря, «единственная реальная« изящество »экономии Autotools заключается в том, что именно этим в основном пользуются все проекты GNU.

Проблемы с автоинструментами:

• Действительно макрос макрос ARCANE m4 в сочетании с многословным, витой сценарий оболочки для тестов на «совместимость» и т. Д.
• Если вы не обращая внимания, вы будете запутались способность кросс-компиляции (Следует четко отметить , что Nokia придумал ScratchBox / Scratchbox2 на боковой шаг сильно разбитой Autotools сборки установок для Maemo / Meego.) Если вы, по какой - либо По этой причине, исправив статические пути в ваших тестах, вы нарушите поддержку кросс-компиляции, потому что она не будет соответствовать спецификации sysroot и вытянет что-то из вашей хост-системы. Если вы нарушите поддержку кросс-компиляции, это сделает ваш код непригодным для таких вещей, как OpenEmbedded, и сделает его «забавным» для дистрибутивов, пытающихся построить свои выпуски на кросс-компиляторе, а не на цели.
• Выполняет ОГРОМНОЕ количество тестов на проблемы с древними, сломанными компиляторами, которые в настоящее время NOBODY использует практически для всего производства в наши дни. Если вы не создаете что-то вроде glibc, libstdc ++ или GCC на действительно древней версии Solaris, AIX и т. П., Тесты являются пустой тратой времени и источником многих, многих потенциальных поломок, подобных упомянутым выше.
• Очень тяжело получить настройку Autotools для создания полезного кода для системы Windows. (Хотя я мало пользуюсь Windows, это серьезная проблема, если вы разрабатываете якобы кросс-платформенный код.)
• Когда он сломается, вы потратите ЧАСЫ, гоняясь за хвостом, пытаясь разобраться в вещах, которые кто-то написал, что скриптинг ошибался, чтобы разобраться в вашей сборке (На самом деле, это то, что я пытаюсь сделать (или, скорее, выдирать Autotools completely- Я сомневаюсь , что есть достаточно времени в остальной части этого месяца , чтобы разобраться в беспорядке ...) для работы прямо сейчас , когда я печатаю это. Apache Бережливость имеет один из этих ПОВРЕЖДЕНИЙ систем сборки , которые не пересечется -compile.)
• «Обычные» пользователи на самом деле НЕ собираются просто «./configure; make» - во многих случаях они будут извлекать пакет, предоставленный кем-то, например, из PPA или их дистрибутора. «Нормальные» пользователи не являются разработчиками и не берут тарболлы во многих случаях. Это снобизм со стороны каждого, предполагая, что так и будет. Типичные пользователи tarballs - это разработчики, которые делают что-то, поэтому они сломаются от поломки, если она там есть.

Это работает ... большую часть времени ... это все, что вы можете сказать об Autotools. Это система, которая решает несколько проблем, которые действительно касаются только проекта GNU ... для их базового, базового кода инструментария. (Правка (24.05.2014): Следует отметить, что этот тип беспокойства является потенциально ПЛОХОЙ вещью, о которой стоит беспокоиться - сердечное кровотечение частично связано с этим мышлением и с правильными, современными системами, вы действительноЯ не имею никакого дела с тем, что исправляет Autotools. GNU, вероятно, необходимо выполнить тщательное удаление кодовой базы в свете того, что произошло с Heartbleed. Вы можете использовать его для своего проекта, и он может хорошо работать для небольшого проекта, который, как вы ожидаете, не будет работать нигде, кроме Linux или где Ясно, что цепочка инструментов GNU работает правильно. Утверждение, что оно «прекрасно интегрируется с Linux», является довольно смелым и совершенно неверным . Он достаточно хорошо интегрируется с инструментарием GNU и решает проблемы, возникающие у ИТ-специалистов с его целями.

Это не означает, что нет проблем с другими вариантами, обсуждаемыми здесь.

SCons - это скорее замена для Make / GMake / etc. и выглядит довольно красиво, учитывая все обстоятельства, однако ...

• Это все еще действительно инструмент POSIX. Вероятно, вы могли бы с большей легкостью заставить MinGW создавать вещи для Windows с этим, чем с Autotools, но это все же действительно более приспособлено для работы с POSIX, и вам нужно было бы установить Python и SCons для его использования.
• Есть проблемы с кросс-компиляцией, если вы не используете что-то вроде Scratchbox2.
• По общему признанию, медленнее и менее стабильно, чем CMake из собственного сравнения. Они придумали нерешительные (сторона POSIX нуждается в make / gmake для построения ...) негативов для CMake по сравнению с SCons. (Кроме того, если вам нужна ЭТО большая расширяемость по сравнению с другими решениями, вы должны спросить себя, не слишком ли сложен ваш проект ...)

Примеры, приведенные для CMake в этой теме, немного обманчивы.

Тем не мение...

• Вам нужно будет выучить новый язык.
• Существуют нелогичные вещи, если вы привыкли к Make, SCons или Autotools.
• Вам нужно будет установить CMake на систему, для которой вы создаете.
• Вам понадобится солидный компилятор C ++, если у вас нет готовых двоичных файлов для него.

По правде говоря, ваши цели должны диктовать, что вы выбираете здесь.

• Вам нужно иметь дело с ОЧЕНЬ большим количеством неработающих цепочек инструментов, чтобы создать действующий рабочий бинарный файл? Если да, вы можете рассмотреть Autotools, зная о недостатках, которые я упомянул выше. CMake может справиться со многими из этих проблем, но он меньше беспокоится об этом, чем Autotools. SCons можно расширить, чтобы беспокоиться об этом, но это не готовый ответ.
• Вам нужно беспокоиться о целях Windows? Если это так, Autotools должен быть в буквальном смысле не работает. Если это так, SCons может / не может быть хорошим выбором. Если это так, то CMake - хороший выбор.
• Вам нужно беспокоиться о кросс-компиляции (универсальные приложения / библиотеки, такие вещи, как Google Protobufs, Apache Thrift и т. Д. ДОЛЖНЫ заботиться об этом ...)? Если это так, Autotools можетработать на вас до тех пор, пока вам не нужно беспокоиться о Windows, но вы будете тратить много времени на обслуживание своей системы конфигурации, когда все меняется на вас. SCons практически не используется в настоящий момент, если вы не используете Scratchbox2 - у него действительно нет ручки для кросс-компиляции, и вам нужно будет использовать эту расширяемость и поддерживать ее так же, как Вы будете с Automake. Если это так, вы можете рассмотреть CMake, так как он поддерживает кросс-компиляцию, не беспокоясь об утечке из песочницы, и будет работать с / без чего-то вроде Scratchbox2 и прекрасно интегрируется с такими вещами, как OpenEmbedded.

Существует множество причин, по которым многие проекты отказываются от qmake, Autotools и т. Д. И переходят на CMake. До сих пор я вполне мог ожидать, что проект на основе CMake либо попадет в ситуацию кросс-компиляции, либо на установку VisualStudio, либо потребуется лишь небольшая очистка, потому что проект не учитывает только компоненты Windows или OSX. в кодовую базу. Я не могу ожидать, что в проекте, основанном на SCons, - и я полностью ожидаю, что 1/3 или более проектов Autotools допустили что-то неверное, что исключает его правильное построение в любом контексте, кроме хоста, создающего один или Scratchbox2.

Важное различие должно быть сделано между тем, кто использует инструменты. Cmake - это инструмент, который должен использовать пользователь при создании программного обеспечения. Автоинструменты используются для создания архива дистрибутива, который можно использовать для сборки программного обеспечения, используя только стандартные инструменты, доступные в любой SuS-совместимой системе. Другими словами, если вы устанавливаете программное обеспечение из архива, созданного с помощью автоинструментов, вы не используете автоинструменты . С другой стороны, если вы устанавливаете программное обеспечение , которое использует CMake, то будут с помощью CMake и должна установить его для создания программного обеспечения.

Подавляющему большинству пользователей не нужно устанавливать автоинструмент на свой компьютер. Исторически сложилось так, что много путаницы было вызвано тем, что многие разработчики распространяли неправильно сформированные архивы, которые вынуждали пользователя запускать autoconf для регенерации скрипта configure, и это является ошибкой упаковки. Больше путаницы было вызвано тем фактом, что большинство основных дистрибутивов Linux устанавливают несколько версий автоинструментов, когда они не должны устанавливать ни одну из них по умолчанию. Еще большую путаницу вызывают разработчики, пытающиеся использовать систему контроля версий (например, cvs, git, svn) для распространения своего программного обеспечения, а не для создания tar-архивов.

Это не о стандартах кодирования GNU.

В настоящее время преимущества autotools - особенно при использовании с automake - в том, что они очень хорошо интегрируются с созданием дистрибутива Linux.

Например, для cmake это всегда "мне нужно -DCMAKE_CFLAGS или -DCMAKE_C_FLAGS?" Нет, это не так, это "-DCMAKE_C_FLAGS_RELEASE". Или -DCMAKE_C_FLAGS_DEBUG. Это сбивает с толку - в autoconf это просто ./configure CFLAGS = "- O0 -ggdb3" и у вас это есть.

При интеграции с инфраструктурами сборки проблема scons не может использоваться make %{?_smp_mflags}, _smp_mflagsв данном случае это макрос RPM, который примерно расширяется до (может установить администратор) мощности системы. Люди помещают такие вещи, как -jNCPUS, через свое окружение. С scons это не работает, поэтому пакеты, использующие scons, могут быть только встроенными в дистрибутивы.

Что важно знать об Autotools, так это то, что они не являются общей системой сборки - они реализуют стандарты кодирования GNU и ничего более. Если вы хотите создать пакет, соответствующий всем стандартам GNU, то Autotools - отличный инструмент для работы. Если вы этого не сделаете, то вы должны использовать Scons или CMake. (Например, см. Этот вопрос .) Это распространенное недоразумение - то, откуда большинство разочарований в Autotools.

Хотя с точки зрения разработчиков, cmake в настоящее время является наиболее простым в использовании, с точки зрения пользователя, автоинструменты имеют одно большое преимущество.

autotools генерирует один скрипт конфигурации файла, и все файлы для его генерации поставляются вместе с дистрибутивом. это легко понять и исправить с помощью grep / sed / awk / vi. Сравните это с Cmake, где в / usr / share / cmak * / Modules найдено много файлов, которые пользователь не может исправить, если у него нет прав администратора.

Таким образом, если что-то не совсем работает, его обычно можно легко «исправить» с помощью стандартных инструментов Unix (grep / sed / awk / vi и т. Д.) Способом кувалды, не разбираясь в системе сборки.

Вы когда-нибудь копались в вашем каталоге сборки cmake, чтобы выяснить, что не так? По сравнению с простым шеллскриптом, который можно прочитать сверху вниз, проследить за сгенерированными файлами Cmake, чтобы выяснить, что происходит, довольно сложно. Также, с CMake, адаптация файлов FindFoo.cmake требует не только знания языка CMake, но также может потребовать привилегий суперпользователя.