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

Question

Чем отличаются автоинструменты, Cmake и Scons?

Answer 1

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

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

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

Это работает ... большую часть времени ... это все, что вы можете сказать об 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.(Кроме того, если вам нужна TH * большая расширяемость по сравнению с другими решениями, вы должны спросить себя, не слишком ли сложен ваш проект ...)

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

Однако ...

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

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

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

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

Answer 2

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

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

Answer 3

Речь идет не о стандартах кодирования 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, могут быть только встроенными в дистрибутивы.

Answer 4

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

Answer 5

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

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

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

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