По правде говоря, «единственная реальная« изящество »экономии 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.
Раздел, в котором упоминается Heartbleed, отвлекает от этой разочарованной напыщенной речи. Проблема заключалась в том, что OpenSSL НЕ использовал пакет типа конфигуратора для обнаружения сломанных malloc, но повторно реализовывал системные библиотеки и побеждал разработчиков платформ, которые создавали библиотеки, которые обнаруживали бы ошибки гораздо раньше. Одна из причин портирования программ заключается в том, что они становятся более качественными, поскольку они меньше зависят от тех небольших предположений, которые вы даже не понимаете, что делаете
Rob11311
9
Дело в том, что это совсем не умаляет этого. С Autotools вы беспокоитесь о компенсации за подобные вещи - эти повторные реализации являются РАСШИРЕНИЕМ этого самого мышления. Взяв его на следующий уровень, как это было. Вы должны смотреть на это с той стороны ... когда это совсем не умаляет этого. Вы не указали причину в своих рассуждениях - только то, что произошло. Я перебираю точное МЫШЛЕНИЕ, которое привело его к этому наряду с Shellshock и несколькими другими, как это. Если он сломан, вы должны исправить это. Если вы не можете - вы должны спросить, зачем продолжать.
Свартальф
5
Я не сомневаюсь, что autotools и scons отстой, но этот ответ плохо справляется с замечанием минусов CMake (моей предпочтительной системы сборки, только из-за очень, очень печального состояния систем сборки). По сути, CMake - это фрактал несоответствия со встроенной поддержкой отдельных крайних случаев, а не какой-то базовой абстракцией, которая обрабатывает большинство вещей. Это определенно клейкая лента и залог программирования. Я уверен, что я делаю что-то не так, но он не поддерживает VisualStudio, если вы не найдете один VS-проект для CMakeLists.txt приемлемым (я не VS-пользователь, но мои друзья говорят, что это плохо).
@JAB Мне говорят пользователи VS, что это не идиоматично. Фактически, CMake был заменен в качестве системы сборки для нашего проекта, потому что никто не мог понять, как создавать «идиоматические» файлы VS Project.
weberc2
73
Важное различие должно быть сделано между тем, кто использует инструменты. Cmake - это инструмент, который должен использовать пользователь при создании программного обеспечения. Автоинструменты используются для создания архива дистрибутива, который можно использовать для сборки программного обеспечения, используя только стандартные инструменты, доступные в любой SuS-совместимой системе. Другими словами, если вы устанавливаете программное обеспечение из архива, созданного с помощью автоинструментов, вы не используете автоинструменты . С другой стороны, если вы устанавливаете программное обеспечение , которое использует CMake, то будут с помощью CMake и должна установить его для создания программного обеспечения.
Подавляющему большинству пользователей не нужно устанавливать автоинструмент на свой компьютер. Исторически сложилось так, что много путаницы было вызвано тем, что многие разработчики распространяли неправильно сформированные архивы, которые вынуждали пользователя запускать autoconf для регенерации скрипта configure, и это является ошибкой упаковки. Больше путаницы было вызвано тем фактом, что большинство основных дистрибутивов Linux устанавливают несколько версий автоинструментов, когда они не должны устанавливать ни одну из них по умолчанию. Еще большую путаницу вызывают разработчики, пытающиеся использовать систему контроля версий (например, cvs, git, svn) для распространения своего программного обеспечения, а не для создания tar-архивов.
Правда, хотя это звучит так, как будто плохо использовать VCS для распространения программного обеспечения. Если содержимое оформления заказа или клона совпадает с содержимым тарбола, почему вы бы порекомендовали тарболы?
d -_- б
5
@ Мне не понятно твой вопрос. Все проекты, над которыми я работаю, создают тарбол, который отличается от оформления VCS. Сохранение двух разных помогает с надежным распределением.
Уильям Перселл
13
Это правда, что многие проекты просят людей использовать VCS для получения последней версии, но это подходит только для разработчиков. К сожалению, многие пользователи не понимают разницы между тарболлом релиза и VCS. Попытка построить из VCS налагает больше зависимостей. Пользователю может понадобиться asciidocили, help2manили doxygen, что важно, правильная комбинация автоинструмента. Это было огромной маркетинговой проблемой для автоинструментов. Пользователи ошибочно думают, что им нужно установить autoconf, потому что они не понимают разницы между tarball и VCS.
Уильям Перселл
3
Почему проект не может распространять вывод Cmake, файлы проекта и файлы Makefile для распространенных платформ, например Win, Linux и MacOSX? Это похоже на ту же ситуацию, что и с инструментами lex / yacc, вы включаете генерируемый код C, чтобы его можно было
собирать
3
Хотя я думаю, что пункты, упомянутые в этом обсуждении, верны, я считаю, что в этом обсуждении не хватает смысла. Пользователю нужно установить целый ряд других вещей, и необходимость дополнительных действий для установки cmake не должна быть большой проблемой. Я бы больше беспокоился о библиотеках, цепочке инструментов компилятора и других инструментах, необходимых для сборки программного обеспечения.
lanoxx
24
Это не о стандартах кодирования 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, могут быть только встроенными в дистрибутивы.
+1, и мир был бы лучше, если бы это было правдой. К сожалению, ./configure CFLAGS=-O0часто происходит сбой с пакетами, которые перезаписывают CFLAGS в make-файле и вместо этого требуют запуска пользователя ./configure --enable-debug. (например tmux).
Уильям Перселл
2
Это не более запутанно, чем Autotools, и, как справедливо указывает Уильям, он весь в аду с неправильно оформленным CFLAGS = "<foo>" в make-файле. Проще говоря, это еще один из тех предметов "старой пилы". И примеры CMake являются поддельными ... опять же ... Вы можете сделать первое, если вы не указали RELEASE или DEBUG. ПОТЕРПЕТЬ ПОРАЖЕНИЕ.
Svartalf
17
Что важно знать об Autotools, так это то, что они не являются общей системой сборки - они реализуют стандарты кодирования GNU и ничего более. Если вы хотите создать пакет, соответствующий всем стандартам GNU, то Autotools - отличный инструмент для работы. Если вы этого не сделаете, то вы должны использовать Scons или CMake. (Например, см. Этот вопрос .) Это распространенное недоразумение - то, откуда большинство разочарований в Autotools.
Стандарты GNU могут быть отключены в Automake с помощью AUTOMAKE_OPTIONS = -foreignвашего Makefile.am. (Или -foreignв вашем autogen.sh. Я думаю, что почти все используют это.)
Дитрих Эпп
9
Да, но это только контролирует, применяет ли Automake поверхностные правила GNU, например, требуется ли файл README. Это не меняет основную предпосылку создания тарболла в стиле GNU с такими правилами, как installcheckи distclean. Если вы пытаетесь изменить такое поведение, все еще используя Autotools, то вы просто теряете время.
ptomato
1
Они (теоретически) позволяют собирать и устанавливать все программные пакеты одинаково.
ptomato
Теоретически они позволяют вам иметь дело с компиляторами и операционными системами BROKEN более уместно, чем с другими инструментами, и применять поверхностные правила, такие как @ptomato. Если вы используете современный (например, GCC или clang ... для примера) инструмент в современной операционной системе, в котором нет ничего по-настоящему глупого, скажем, Linux или текущего * BSD, вам не НУЖНЫ «правила». Они, на самом деле, делают намного больше работы для вас и не могут помочь, если честно, для кросс-компиляции. В наши дни почти половина всех случаев использования - для встроенного Linux и * BSD. ПОЧЕМУ ты идешь с вещами, которые не могут тебе там помочь?
Свартальф
Не уверен, почему вы отклонили ответ, так как вы, кажется, признаете его в своем комментарии ...?
ptomato
9
Хотя с точки зрения разработчиков, cmake в настоящее время является наиболее простым в использовании, с точки зрения пользователя, автоинструменты имеют одно большое преимущество.
autotools генерирует один скрипт конфигурации файла, и все файлы для его генерации поставляются вместе с дистрибутивом. это легко понять и исправить с помощью grep / sed / awk / vi. Сравните это с Cmake, где в / usr / share / cmak * / Modules найдено много файлов, которые пользователь не может исправить, если у него нет прав администратора.
Таким образом, если что-то не совсем работает, его обычно можно легко «исправить» с помощью стандартных инструментов Unix (grep / sed / awk / vi и т. Д.) Способом кувалды, не разбираясь в системе сборки.
Вы когда-нибудь копались в вашем каталоге сборки cmake, чтобы выяснить, что не так? По сравнению с простым шеллскриптом, который можно прочитать сверху вниз, проследить за сгенерированными файлами Cmake, чтобы выяснить, что происходит, довольно сложно. Также, с CMake, адаптация файлов FindFoo.cmake требует не только знания языка CMake, но также может потребовать привилегий суперпользователя.
Потому что autotools - сложная система (как и CMake). Если вы думаете, что автоинструменты «легко исправимы» (могут быть причины думать об этом), было бы неплохо ИМХО объяснить в ответ, каким образом проблемы легче устранить.
слеске
5
autotools генерирует один скрипт конфигурации файла, и все файлы для его генерации поставляются вместе с дистрибутивом. это легко понять и исправить с помощью grep / sed / awk / vi. Сравните это с Cmake, где много файлов находится в / usr / share / cmak * / Modules, которые не могут быть исправлены пользователем, если у него нет прав администратора. Вы когда-нибудь копались в вашем каталоге сборки cmake, чтобы выяснить, что не так? По сравнению с простым шеллскриптом, который можно прочитать сверху вниз, проследить сгенерированные файлы Cmake, чтобы выяснить, что происходит, довольно сложно
arven
2
Да, это имеет смысл, спасибо. Я позволил себе добавить это к вашему ответу. Не стесняйтесь вернуться :-).
слеске
1
Вы всегда можете использовать свою собственную локальную версию cmake; нет причин использовать то, что установлено на системном уровне. Для любого, кто делает кроссплатформенную работу, это совершенно нормально; это, конечно, то, как я использую cmake большую часть времени.
Ответы:
По правде говоря, «единственная реальная« изящество »экономии Autotools заключается в том, что именно этим в основном пользуются все проекты GNU.
Проблемы с автоинструментами:
Это работает ... большую часть времени ... это все, что вы можете сказать об Autotools. Это система, которая решает несколько проблем, которые действительно касаются только проекта GNU ... для их базового, базового кода инструментария. (Правка (24.05.2014): Следует отметить, что этот тип беспокойства является потенциально ПЛОХОЙ вещью, о которой стоит беспокоиться - сердечное кровотечение частично связано с этим мышлением и с правильными, современными системами, вы действительноЯ не имею никакого дела с тем, что исправляет Autotools. GNU, вероятно, необходимо выполнить тщательное удаление кодовой базы в свете того, что произошло с Heartbleed. Вы можете использовать его для своего проекта, и он может хорошо работать для небольшого проекта, который, как вы ожидаете, не будет работать нигде, кроме Linux или где Ясно, что цепочка инструментов GNU работает правильно. Утверждение, что оно «прекрасно интегрируется с Linux», является довольно смелым и совершенно неверным . Он достаточно хорошо интегрируется с инструментарием GNU и решает проблемы, возникающие у ИТ-специалистов с его целями.
Это не означает, что нет проблем с другими вариантами, обсуждаемыми здесь.
SCons - это скорее замена для Make / GMake / etc. и выглядит довольно красиво, учитывая все обстоятельства, однако ...
Примеры, приведенные для CMake в этой теме, немного обманчивы.
Тем не мение...
По правде говоря, ваши цели должны диктовать, что вы выбираете здесь.
Существует множество причин, по которым многие проекты отказываются от qmake, Autotools и т. Д. И переходят на CMake. До сих пор я вполне мог ожидать, что проект на основе CMake либо попадет в ситуацию кросс-компиляции, либо на установку VisualStudio, либо потребуется лишь небольшая очистка, потому что проект не учитывает только компоненты Windows или OSX. в кодовую базу. Я не могу ожидать, что в проекте, основанном на SCons, - и я полностью ожидаю, что 1/3 или более проектов Autotools допустили что-то неверное, что исключает его правильное построение в любом контексте, кроме хоста, создающего один или Scratchbox2.
источник
Важное различие должно быть сделано между тем, кто использует инструменты. Cmake - это инструмент, который должен использовать пользователь при создании программного обеспечения. Автоинструменты используются для создания архива дистрибутива, который можно использовать для сборки программного обеспечения, используя только стандартные инструменты, доступные в любой SuS-совместимой системе. Другими словами, если вы устанавливаете программное обеспечение из архива, созданного с помощью автоинструментов, вы не используете автоинструменты . С другой стороны, если вы устанавливаете программное обеспечение , которое использует CMake, то будут с помощью CMake и должна установить его для создания программного обеспечения.
Подавляющему большинству пользователей не нужно устанавливать автоинструмент на свой компьютер. Исторически сложилось так, что много путаницы было вызвано тем, что многие разработчики распространяли неправильно сформированные архивы, которые вынуждали пользователя запускать autoconf для регенерации скрипта configure, и это является ошибкой упаковки. Больше путаницы было вызвано тем фактом, что большинство основных дистрибутивов Linux устанавливают несколько версий автоинструментов, когда они не должны устанавливать ни одну из них по умолчанию. Еще большую путаницу вызывают разработчики, пытающиеся использовать систему контроля версий (например, cvs, git, svn) для распространения своего программного обеспечения, а не для создания tar-архивов.
источник
asciidocили,help2manилиdoxygen, что важно, правильная комбинация автоинструмента. Это было огромной маркетинговой проблемой для автоинструментов. Пользователи ошибочно думают, что им нужно установить autoconf, потому что они не понимают разницы между tarball и VCS.Это не о стандартах кодирования 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, могут быть только встроенными в дистрибутивы.источник
./configure CFLAGS=-O0часто происходит сбой с пакетами, которые перезаписывают CFLAGS в make-файле и вместо этого требуют запуска пользователя./configure --enable-debug. (напримерtmux).Что важно знать об Autotools, так это то, что они не являются общей системой сборки - они реализуют стандарты кодирования GNU и ничего более. Если вы хотите создать пакет, соответствующий всем стандартам GNU, то Autotools - отличный инструмент для работы. Если вы этого не сделаете, то вы должны использовать Scons или CMake. (Например, см. Этот вопрос .) Это распространенное недоразумение - то, откуда большинство разочарований в Autotools.
источник
AUTOMAKE_OPTIONS = -foreignвашегоMakefile.am. (Или-foreignв вашемautogen.sh. Я думаю, что почти все используют это.)installcheckиdistclean. Если вы пытаетесь изменить такое поведение, все еще используя Autotools, то вы просто теряете время.Хотя с точки зрения разработчиков, cmake в настоящее время является наиболее простым в использовании, с точки зрения пользователя, автоинструменты имеют одно большое преимущество.
autotools генерирует один скрипт конфигурации файла, и все файлы для его генерации поставляются вместе с дистрибутивом. это легко понять и исправить с помощью grep / sed / awk / vi. Сравните это с Cmake, где в / usr / share / cmak * / Modules найдено много файлов, которые пользователь не может исправить, если у него нет прав администратора.
Таким образом, если что-то не совсем работает, его обычно можно легко «исправить» с помощью стандартных инструментов Unix (grep / sed / awk / vi и т. Д.) Способом кувалды, не разбираясь в системе сборки.
Вы когда-нибудь копались в вашем каталоге сборки cmake, чтобы выяснить, что не так? По сравнению с простым шеллскриптом, который можно прочитать сверху вниз, проследить за сгенерированными файлами Cmake, чтобы выяснить, что происходит, довольно сложно. Также, с CMake, адаптация файлов FindFoo.cmake требует не только знания языка CMake, но также может потребовать привилегий суперпользователя.
источник