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

Ответ 1

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

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

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

• Autoconf
• Automake
• Libtool

Посмотрите на каждый отдельно.

Autoconf

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

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

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

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

Automake

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

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

Libtool

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

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

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

Во всяком случае, я бы рекомендовал попробовать Autoconf, если вы пишете программное обеспечение для систем POSIX. Если вам нужна документация и справочные ссылки, обновите свой вопрос.

Edit

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

Ответ 2

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

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

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

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

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

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

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

Ответ 3

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

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

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

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

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

Ответ 4

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

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

./Configure

сделать

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

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

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

Ответ 5

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

Ответ 6

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

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

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

В мире * nix много всего похоже.

Ответ 7

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

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