Confused about configure script и Makefile.in - программирование

В настоящее время я изучаю, как использовать toolchain autoconf/automake. Кажется, у меня есть общее понимание рабочего процесса - в основном у вас есть configure.ac script, который генерирует исполняемый файл configure. Созданный configure script затем выполняется конечным пользователем для генерации Makefile s, поэтому программа может быть создана/установлена.

Таким образом, установка для обычного конечного пользователя в основном:

./configure
make
make install
make clean

Хорошо, теперь здесь, где я смущен:

Как разработчик, я заметил, что автоматически сгенерированная конфигурация script иногда не запускается и будет с ошибкой:

config.status: error: cannot find input file: `somedir/Makefile.in'

Это меня смущает, потому что я думал, что configure script должен генерировать Makefile.in. Поэтому, чтобы найти ответы на некоторые вопросы, я обнаружил, что это можно исправить с помощью autogen.sh script, который в основном "сбрасывает" состояние среды autoconf. Типичным autogen.sh script будет что-то вроде:

aclocal \
&& automake --add-missing \
&& autoconf

Хорошо. Но, как конечный пользователь, который загружал бесчисленные tarballs на протяжении всей моей жизни, мне никогда не приходилось использовать autogen.sh script. Все, что я сделал, это разблокировать tarball и выполнить обычную команду configure/make/make install/make clean.

Но как разработчик, который теперь использует autoconf, кажется, что configure фактически не запускается, если вы сначала не запустите autogen.sh. Поэтому я считаю это очень запутанным, потому что я думал, что конечный пользователь не должен запускать autogen.sh.

Итак, зачем мне сначала запускать autogen.sh - для того, чтобы configure script нашел Makefile.in? Почему configure script просто не генерирует его?

Ответ 1

Чтобы действительно понять утилиты autotools, вы должны помнить, откуда они пришли: они происходят из мира с открытым исходным кодом, где есть (а) разработчики, которые работают из репозитория исходного кода (CVS, Git и т.д.).) и создания tar файла или аналогичного исходного кода и размещения этого tar файла на сайте загрузки и (b) конечных пользователей, которые получают файл tar-кода исходного кода, компилируют этот исходный код в своей системе и используют результирующий двоичный файл. Очевидно, что люди в группе (а) также компилируют код и используют результирующий двоичный файл, но люди из группы (б) не имеют или не часто используют все инструменты для развития, которые нужны людям в группе (а).

Таким образом, использование инструментов ориентировано на этот раскол, где люди в группе (b) не имеют доступа к autoconf, automake и т.д.

При использовании autoconf люди обычно проверяют файл configure.ac (ввод на autoconf) в исходный элемент управления, но не проверяют вывод autoconf, configure script (некоторые проекты проверяют configure script, конечно: это зависит от вас).

При использовании automake люди обычно проверяют файл Makefile.am (ввод automay), но не проверяют вывод automake: Makefile.in.

configure script в основном рассматривает вашу систему для различных необязательных элементов, которые пакет может или не нужен, где они могут быть найдены, и т.д. После того, как он найдет эту информацию, он может использовать ее для преобразования различных XXX.in (обычно, но не только, Makefile.in) в файлы XXX (например, Makefile).

Итак, шаги обычно идут следующим образом: напишите configure.ac и Makefile.am и проверьте их. Чтобы создать проект из проверки контроля исходного кода, запустите autoconf для генерации configure из configure.ac. Запустите automake, чтобы сгенерировать Makefile.in из Makefile.am. Запустите configure, чтобы сгенерировать Makefile из Makefile.in. Запустите make для сборки продукта.

Если вы хотите освободить исходный код (если вы разрабатываете продукт с открытым исходным кодом, который выпускает исходные коды), вы запускаете autoconf и automake, а затем объединяете исходный код с файлами configure и Makefile.in так что людям, строящим исходный код, просто нужно сделать и компилятор, и не нужны никакие autotools.

Поскольку порядок запуска autoconf и automake (и libtool, если вы его используете) может быть сложным, поэтому существуют сценарии типа autogen.sh и autoreconf и т.д., которые проверяются в исходном элементе управления, которые будут использоваться разработчиками, создающими исходный элемент управления, но они не нужны/используются людьми, созданными из файла tar файла релиза исходного кода и т.д.

Autoconf и automake часто используются вместе, но вы можете использовать autoconf без automake, если вы хотите написать свой собственный Makefile.in.