Зачем использовать инструменты сборки, такие как Autotools, когда мы можем просто написать свои собственные make-файлы?

Question

Недавно я переключил свою среду разработки с Windows на Linux. До сих пор я использовал только Visual Studio для разработки на C ++, поэтому многие концепции, такие как make и Autotools , являются для меня новыми. Я прочитал документацию по make-файлу GNU и получил почти представление об этом. Но я немного растерялся из-за Автоинструментов.

Насколько я знаю, make-файлы используются для облегчения процесса сборки.

1. Зачем нам нужны такие инструменты, как Автоинструмент только для создания make-файлов? Поскольку все знают, как создать make-файл, я не получаю реального использования Autotools.
2. Что такое стандарт? Нужно ли нам использовать такие инструменты или это нужно делать только рукописным make-файлам?

Answer 1

Вы говорите о двух отдельных, но взаимосвязанных вещах:

• Autotools
• Стандарты кодирования GNU

В Autotools у вас есть несколько проектов:

• Autoconf
• Automake
• Libtool

Давайте рассмотрим каждый из них в отдельности.

Autoconf

Autoconf легко сканирует существующее дерево, чтобы найти его зависимости и создать скрипт конфигурации, который будет работать практически под любой оболочкой. Сценарий конфигурации позволяет пользователю контролировать поведение сборки (т. Е. --with-foo, --without-foo, --prefix, --sysconfdir и т. Д.), А также выполнять проверки для обеспечения возможности компиляции программы системой.

Configure генерирует файл config.h (из шаблона), который программы могут включать для решения проблем переносимости. Например, если HAVE_LIBPTHREAD не определено, используйте вместо него вилки.

Я лично использую Autoconf во многих проектах. Обычно людям требуется некоторое время, чтобы привыкнуть к m4 . Тем не менее, это экономит время.

У вас могут быть make-файлы, наследующие некоторые значения, которые настраивают находки, без использования automake.

Automake

Предоставляя краткий шаблон, который описывает, какие программы будут создаваться и какие объекты необходимо связать для их создания, можно автоматически создавать файлы Makefile, соответствующие стандартам кодирования GNU. Это включает в себя обработку зависимостей и все необходимые цели GNU.

Некоторым людям это проще. Я предпочитаю писать свои собственные make-файлы.

Libtool

Libtool - очень полезный инструмент для упрощения сборки и установки общих библиотек в любой Unix-подобной системе. Иногда я использую это; в других случаях (особенно при создании статических объектов ссылок) я делаю это вручную.

Есть и другие варианты, см. Вопрос StackOverflow Альтернативы Autoconf и Autotools? .

Стандарты автоматизации сборки и кодирования GNU

Короче говоря, вы действительно должны использовать некоторую систему переносимых конфигураций сборки, если вы выпускаете свой код в массы. То, что вы используете, зависит от вас. Известно, что программное обеспечение GNU собирается и работает практически на чем угодно. Однако вам может не потребоваться придерживаться таких (а иногда и крайне педантичных) стандартов.

Во всяком случае, я бы порекомендовал попробовать Autoconf, если вы пишете программное обеспечение для систем POSIX. Тот факт, что Autotools создает часть среды сборки, совместимой со стандартами GNU, не означает, что вы должны следовать этим стандартам (многие этого не делают!) :) Также существует множество других вариантов.

Редактировать

Не бойтесь m4 :) Всегда есть макроархив Autoconf . Множество примеров или чеков. Напишите свой или используйте то, что проверено. Autoconf слишком часто путают с Automake . Это две разные вещи.

Answer 2

Прежде всего, Autotools - это не непрозрачная система сборки, а слабо связанная цепочка инструментов, как уже указывал tinkertim. Позвольте мне добавить несколько соображений по Autoconf и Automake:

Autoconf - это система конфигурации, которая создает скрипт конфигурации на основе проверок функций, которые должны работать на всех типах платформ. За 15 лет ее существования в ее базу данных макросов m4 было много системных знаний. С одной стороны, я думаю, что последняя является основной причиной, по которой Autotools еще не был заменен чем-то другим. С другой стороны, Autoconf был гораздо важнее, когда целевые платформы были более разнородными и Linux, AIX , HP-UX , SunOS , .. ., и нужно было поддерживать большое разнообразие процессорной архитектуры. Я не вижу смысла, если вы хотите поддерживать только последние дистрибутивы Linux и Intel-совместимые процессоры.

Automake является уровнем абстракции для GNU Make и действует как генератор Makefile из более простых шаблонов. Некоторые проекты в конечном итоге избавились от абстракции Automake и вернулись к написанию Make-файлов вручную, потому что вы теряете контроль над вашими Make-файлами и вам могут не понадобиться все стандартные объекты сборки, которые запутывают ваш Make-файл.

Теперь к альтернативам (и я настоятельно рекомендую альтернативу Автоинструментам на основе ваших требований):

CMake Самым заметным достижением является замена AutoTools в KDE . Это, вероятно, самое близкое, что вы можете получить, если вы хотите иметь функциональность, подобную Autoconf, без характерных черт m4. Он предоставляет поддержку Windows и доказал свою применимость в крупных проектах. Моя претензия к CMake заключается в том, что он все еще является генератором Makefile (по крайней мере, в Linux) со всеми его имманентными проблемами (например, отладка Makefile, подписи меток времени, неявный порядок зависимости).

SCons - это замена Make, написанная на Python. Он использует скрипты Python в качестве управляющих файлов сборки, позволяющих использовать очень сложные методы. К сожалению, его система конфигурации не соответствует Autoconf. SCons часто используется для внутренней разработки, когда адаптация к конкретным требованиям важнее, чем следующие соглашения.

Если вы действительно хотите использовать Autotools, я настоятельно рекомендую прочитать Рекурсивное создание, считающееся вредным и написать свой собственный Makefile GNU, настроенный через Autoconf.

Answer 3

Ответы, уже предоставленные здесь, хороши, но я настоятельно рекомендую не советовать вам писать собственный make-файл, если у вас есть что-то похожее на стандартный проект C / C ++. Нам нужны автоинструменты вместо рукописных make-файлов, потому что стандартный совместимый make-файл, сгенерированный automake, предлагает множество полезных целей под хорошо известными именами, а предоставление всех этих целей вручную утомительно и подвержено ошибкам.

Во-первых, написание Makefile вручную кажется поначалу отличной идеей, но большинство людей не потрудятся написать больше, чем правила для всех, установить и, возможно, почистить. automake генерирует dist, distcheck, clean, distclean, uninstall и все эти маленькие помощники. Эти дополнительные цели являются хорошим подарком для системного администратора, который в конечном итоге установит ваше программное обеспечение.

Во-вторых, обеспечение всех этих целей переносимым и гибким способом весьма подвержено ошибкам. В последнее время я много занимался кросс-компиляцией для целей Windows, и автоинструменты работали просто замечательно. В отличие от большинства рукописных файлов, которые были в основном задницей при компиляции. Имейте в виду, что можно создать хороший Makefile вручную. Но не переоценивайте себя, это требует большого опыта и знаний о множестве различных систем, и automake создает отличные Makefile для вас прямо из коробки.

Редактировать: И не поддавайтесь искушению использовать "альтернативы" . CMake и друзья - ужас для развертывателя, потому что они не совместимы с интерфейсом для настройки и друзей. Любой наполовину компетентный системный администратор или разработчик может делать такие замечательные вещи, как кросс-компиляция или простые вещи, например, устанавливать префикс из своей головы или с помощью простого --help с помощью скрипта configure. Но вы чертовски потратили час или три, когда вам приходится делать такие вещи с BJam. Не поймите меня неправильно, BJam - это, вероятно, отличная система под капотом, но это задница в использовании, потому что там почти нет проектов, использующих ее, и очень мало и неполной документации. autoconf и automake имеют огромное преимущество с точки зрения установленных знаний.

Итак, хотя я немного опоздал с этим советом по этому вопросу: сделайте себе одолжение и воспользуйтесь автоинструментами и automake. Синтаксис может быть немного странным, но они работают лучше, чем 99% разработчиков самостоятельно.

Answer 4

Для небольших проектов или даже для крупных проектов, которые работают только на одной платформе, рукописные make-файлы - это путь.

Где автоинструменты действительно сияют, когда вы компилируете для разных платформ, которые требуют разных опций. Автоинструмент часто является мозгом позади типичного

. / Configure

сделать

сделать установку

шаги по компиляции и установке для библиотек и приложений Linux.

Тем не менее, я считаю, что автоинструменты - это боль, и я искал лучшую систему. В последнее время я использую BJAM, но это также имеет свои недостатки. Удачи в поиске того, что работает для вас.

Answer 5

Автоинструменты необходимы, потому что Makefiles не гарантированно работают одинаково на разных платформах. Если вы напишите Makefile вручную, и он будет работать на вашем компьютере, есть большая вероятность, что он не будет на моем.

Answer 6

Знаете ли вы, какой Unix будут использовать ваши пользователи? Или даже какой дистрибутив Linux? Вы знаете, где они хотят установить программное обеспечение? Знаете ли вы, какие инструменты у них есть, какую архитектуру они хотят скомпилировать, сколько у них процессоров, сколько оперативной памяти и дискового пространства им доступно?

Мир * nix - это кроссплатформенный ландшафт, и ваши инструменты сборки и установки должны с этим справиться.

---

Имейте в виду, что автоматические * инструменты относятся к более ранней эпохе, и на них есть много веских нареканий на них, но несколько проектов по замене их на более современные альтернативы испытывают проблемы с развитием большого количества импульсов.

В мире * nix много таких вещей.

Answer 7

Автоинструментальные катастрофы.

Сгенерированный сценарий ./configure проверяет функции, которых не было ни в одной системе Unix последние 20 лет или около того. Для этого он тратит огромное количество времени.

Бег ./configure занимает целую вечность. Хотя современные серверные процессоры могут иметь даже десятки ядер, и может быть несколько таких процессоров на сервер, ./configure является однопоточным. У нас еще достаточно лет закона Мура, чтобы количество ядер ЦП увеличивалось как функция времени. Таким образом, время, необходимое для ./configure, будет оставаться приблизительно постоянным, тогда как время параллельной сборки уменьшается в 2 раза каждые 2 года в соответствии с законом Мура. Или, на самом деле, я бы сказал, что ./configure может даже увеличиться из-за увеличения сложности программного обеспечения с использованием улучшенного оборудования.

Простой процесс добавления только одного файла в ваш проект требует от вас запуска automake, autoconf и ./configure, что займет много времени, и тогда вы, вероятно, обнаружите, что, поскольку некоторые важные файлы изменились, все будет перекомпилирован. Поэтому добавьте только один файл, и make -j${CPUCOUNT} перекомпилирует все.

А про make -j${CPUCOUNT}. Сгенерированная система сборки является рекурсивной. Рекурсивное создание долгое время считалось вредным .

Затем, установив скомпилированное программное обеспечение, вы обнаружите, что оно не работает. (Хотите доказательства? Клонируйте protobuf репозиторий от Github, проверьте коммит 9f80df026933901883da1d556b38292e14836612, установите его в систему Debian или Ubuntu, и эй presto: protoc: error while loading shared libraries: libprotoc.so.15: cannot open shared object file: No such file or directory - поскольку он находится в /usr/local/lib, а не /usr/lib; обходной путь - export LD_RUN_PATH=/usr/local/lib перед вводом make).

Теория заключается в том, что с помощью автоинструментов вы можете создать программный пакет, который можно скомпилировать в Linux, FreeBSD, NetBSD, OpenBSD, DragonflyBSD и других операционных системах. Факт? Каждая не Linux-система для сборки пакетов из исходного кода имеет множество файлов патчей в своем репозитории для обхода ошибок автоинструментов. Просто взгляните, например, на FreeBSD /usr/ports: он полон патчей. Таким образом, было бы так же легко создать небольшой патч для системы сборки не-autotools для каждого проекта, чем создать небольшой патч для системы сборки autotools для каждого проекта. Или, может быть, даже проще, так как стандартный make гораздо проще в использовании, чем автоинструменты.

Дело в том, что если вы создаете свою собственную систему сборки на основе стандарта make (и делаете ее инклюзивной, а не рекурсивной, следуя рекомендациям из бумаги "Рекурсивная сборка считается вредной"), все работает гораздо лучше , Кроме того, время сборки уменьшается на порядок, возможно, даже на два порядка, если ваш проект представляет собой очень маленький проект с языковыми файлами 10-100 C и у вас есть десятки ядер на процессор и несколько процессоров. Кроме того, гораздо проще связать пользовательские инструменты автоматической генерации кода с пользовательской системой сборки, основанной на стандартном make, вместо того, чтобы справляться с путаницей m4 автоинструментов. Со стандартным make вы можете, по крайней мере, ввести команду оболочки в Makefile.

Итак, чтобы ответить на ваш вопрос: зачем использовать автоинструменты? Ответ: нет причин для этого. Autotools устарела с тех пор, как коммерческий Unix устарел. А появление многоядерных процессоров сделало автоинструменты еще более устаревшими. Почему программисты этого еще не поняли - загадка. Я с радостью использую стандарт make в своих системах сборки, спасибо. Да, для создания файлов зависимостей для включения заголовка языка C требуется определенный объем работы, но объем работы сохраняется благодаря отсутствию необходимости бороться с автоинструментами.

Answer 8

Я не чувствую, что являюсь экспертом, чтобы ответить на этот вопрос, но все же даю вам небольшую аналогию с моим опытом.

Потому что в некоторой степени это похоже на то, почему мы должны писать встроенные коды на языке C (язык высокого уровня), а не писать на ассемблере. Оба решают одну и ту же задачу, но последняя более длинная, утомительная, отнимает много времени и более подвержена ошибкам (если вы не очень хорошо знаете ISA процессора). То же самое и в случае с инструментом Automake и написанием собственного make-файла. Написание Makefile.am и configure.ac довольно просто, чем написание отдельного проекта Makefile.