stringtranslate.com

GNU Autotools

GNU Autotools , также известный как GNU Build System , представляет собой набор инструментов программирования , предназначенных для создания пакетов исходного кода , переносимых на многие Unix-подобные системы.

Сделать программу переносимой может быть сложно: компилятор C отличается от системы к системе; некоторые библиотечные функции отсутствуют в некоторых системах; заголовочные файлы могут иметь разные имена; общие библиотеки могут компилироваться и устанавливаться разными способами. Одним из способов обработки различий платформ является написание условного кода с блоками кода, выбранными с помощью директив препроцессора ( #ifdef); но из-за большого разнообразия сред сборки этот подход быстро становится неуправляемым. Autotools разработан для более управляемого решения этой проблемы.

Autotools является частью GNU toolchain и широко используется во многих свободных программных пакетах и ​​пакетах с открытым исходным кодом . Его компоненты tools являются свободным программным обеспечением , лицензированным в соответствии с GNU General Public License со специальными лицензионными исключениями [1] [2], разрешающими его использование с проприетарным программным обеспечением .

Система сборки GNU позволяет собирать множество программ, используя двухэтапный процесс: configure, а затем make . [3]

Компоненты

Диаграмма последовательности действий autoconf и automake

Autotools состоит из утилит GNU Autoconf , Automake и Libtool . [4] Другие связанные инструменты, часто используемые вместе с ним, включают GNU make , GNU gettext , pkg-config и GNU Compiler Collection (GCC).

Автоконф

Autoconf генерирует configureскрипт на основе содержимого файла configure.ac, который характеризует определенный фрагмент исходного кода. configureПри запуске скрипт сканирует среду сборки и генерирует подчиненный config.statusскрипт, который, в свою очередь, преобразует другие входные файлы и чаще всего Makefile.inв выходные файлы ( Makefile), которые подходят для этой среды сборки. Наконец, makeпрограмма использует Makefileдля генерации исполняемых программ из исходного кода.

Сложность Autotools отражает разнообразие обстоятельств, при которых может быть создан исходный код.

Для обработки файлов autoconf использует реализацию GNU макросистемы m4 .

Autoconf поставляется с несколькими вспомогательными программами, такими как autoheader, которая используется для управления заголовочными файлами C ; , которая может создать начальный входной файл для Autoconf; и , которая может вывести список идентификаторов препроцессора C, используемых в программе.autoscanifnames

Автопроизводитель

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

Libtool

Libtool помогает управлять созданием статических и динамических библиотек в различных Unix-подобных операционных системах. Libtool достигает этого, абстрагируя процесс создания библиотеки, скрывая различия между различными системами (например, Linux- системы против Solaris ).

Использование

Autotools помогает разработчикам программного обеспечения писать кроссплатформенное программное обеспечение и делать его доступным для гораздо более широкого сообщества пользователей, включая исходный код для тех пользователей, которые хотят собрать программное обеспечение самостоятельно. В большинстве случаев пользователи просто запускают предоставленный configureскрипт (который не имеет никаких зависимостей, кроме наличия оболочки, совместимой с Bourne ), а затем программу. [5] Им не нужно устанавливать Autotools на компьютер.make

Его можно использовать как для сборки собственных программ на сборочной машине, так и для кросс-компиляции на другие архитектуры. [6]

Кросс-компиляция программного обеспечения для запуска на хосте Windows из Linux или другой Unix-подобной системы сборки также возможна с использованием MinGW, однако нативная компиляция часто желательна в операционных системах (таких как семейство систем Microsoft Windows ), которые не могут самостоятельно запускать скрипты оболочки Bourne. Это делает сборку такого программного обеспечения в операционной системе Windows немного сложнее, чем в Unix-подобной системе, которая предоставляет оболочку Bourne в качестве стандартного компонента. Можно установить систему Cygwin или MSYS поверх Windows, чтобы обеспечить уровень совместимости с Unix , что позволит запускать скрипты конфигурации . Cygwin также предоставляет GNU Compiler Collection , GNU make и другое программное обеспечение, которое обеспечивает почти полную Unix-подобную систему в Windows; MSYS также предоставляет GNU make и другие инструменты, предназначенные для работы с версией MinGW GCC.

Хотя ожидается, что разработчик предоставит скрипт конфигурации для конечного пользователя, иногда пользователь может захотеть повторно сгенерировать сам скрипт конфигурации. Такая работа может быть необходима, если пользователь захочет изменить исходный код. Таким пользователям потребуется установить Autotools и использовать такие компоненты, как autoreconf .

Autoconf-generated configureможет быть медленным, поскольку он многократно выполняет такие программы, как компилятор C, чтобы проверить наличие различных библиотек, заголовочных файлов и языковых функций. Это особенно касается Cygwin , который из-за отсутствия собственного системного вызова fork может выполнять скрипты конфигурации значительно медленнее, чем Linux . [7]

Критика

В своей колонке для ACM Queue разработчик FreeBSD Пол-Хеннинг Камп раскритиковал систему сборки GNU: [8]

Идея заключается в том, что скрипт конфигурации выполняет около 200 автоматизированных тестов, чтобы пользователь не был обременен ручной настройкой libtool. Это ужасно плохая идея, уже сильно раскритикованная в 1980-х годах, когда она появилась, поскольку она позволяет исходному коду притворяться переносимым за фасадом скрипта конфигурации, вместо того чтобы изначально иметь качество переносимости. Это пародия, что идея конфигурации выжила.

Камп описывает историю системы сборки, рассматривая проблемы переносимости, присущие множеству вариантов Unix 1980-х годов , и сетует на необходимость существования таких систем сборки:

31 085 строк конфигурации для libtool по-прежнему проверяют, существуют ли <sys/stat.h> и <stdlib.h> , хотя Unixen, в котором их не было, не имел ни достаточной памяти для выполнения libtool, ни дисков достаточного размера для его исходного кода объемом 16 МБ.

Хотя критики Autotools часто выступают за альтернативы, которые обеспечивают большую простоту для своих пользователей, некоторые утверждают, что это не обязательно хорошо. Джон Калькот, автор [9] Autotools , 2nd Edition: A Practitioner's Guide to GNU Autoconf, Automake, and Libtool , высказал следующее мнение: [10]

Autotools на самом деле более прозрачны, чем любые другие инструменты сборки. Все эти другие инструменты (cmake, maven и т. д.), которые претендуют на то, чтобы быть намного проще, потому что они изолируют пользователя от основных деталей процесса сборки, — основной недостаток этих инструментов в том, что эта самая изоляция не позволяет пользователям вносить изменения, необходимые для достижения их уникальных целей сборки, специфичных для проекта.

Любой, кто может сказать только хорошее об этом аспекте cmake, maven, gradle или чего-то еще, просто не работал над проектом, который требует от них достаточного отхода от настроек по умолчанию. Я использовал их все и провел часы в отчаянии, пытаясь определить, как обойти недостатки некоторых функций инструментов «делающих все» (кроме того, что мне нужно). Это просто не проблема Autotools. Как кто-то уже упоминал ранее в этой теме, вы можете поместить скрипт оболочки в файл configure.ac и сделать скрипт в файл Makefile.am. Это само определение прозрачности. Ни один другой существующий инструмент не обеспечивает такого уровня гибкости.

Смотрите также

Ссылки

  1. ^ "Savannah Git Hosting - autoconf.git/blob - COPYING.EXCEPTION". Git.savannah.gnu.org . Архивировано из оригинала 2011-07-21 . Получено 2016-04-01 .
  2. ^ "libtool.git - GNU Libtool". Git.savannah.gnu.org . 2005-01-08 . Получено 2016-04-01 .
  3. ^ "Система настройки и сборки GNU - Введение". Airs.com . 1998-07-01 . Получено 01.04.2016 .
  4. ^ "Изучение инструментов разработки GNU". Autotoolset.sourceforge.net . Получено 01.04.2016 .
  5. ^ "automake: GNU Build System". Gnu.org . 2014-12-31 . Получено 2016-04-01 .
  6. ^ "Кросс-компиляция с помощью GNU Autotools". Архивировано из оригинала 13 октября 2008 г. Получено 24 сентября 2008 г.
  7. ^ "Роберт Огрен - Медленное выполнение скрипта оболочки на Cygwin". Cygwin.com . Получено 2016-04-01 .
  8. ^ Камп, Поуль-Хеннинг (2012). «Поколение, затерянное на базаре». ACM Queue . 10 (8): 20–23. doi : 10.1145/2346916.2349257 . S2CID  11656592.
  9. ^ "Autotools, 2-е издание Джона Калькота | Penguin Random House Canada" . Получено 22 января 2021 г. .
  10. ^ "Re: Планы на будущее для Autotools" . Получено 22 января 2021 г.

Внешние ссылки