".am.in"? Можно ли написать «.in» без его создания?

Question

Проще говоря, я наткнулся на файл «buildconf.py.am.in» внутри проекта, который мы разрабатываем на работе. Не очень эксперт в autotools (я должен был изучить их для этой работы), это кажется довольно странным для меня. Внутри есть два VAR=@VAR@ и два VAR=[@]VAR[@].

Как может быть «.am.in»? Для меня это означает, что мы пишем .in для генерации .am, который будет использоваться для генерации другого .in (или .py, возможно). Это выглядит «законным» или «фиксированным»? Таким образом, после этапа configure у меня есть «buildconf.py.am», который используется во время процесса make для генерации .py. Он содержит следующее:

do_subst = sed -e 's,\[@\]APP_VARDIR\[@\],$(localstatedir)/app/,g' \ 
    -e 's,\[@\]APP_LOGDIR\[@\],$(logdir),g' 

buildconf.py: buildconf.py.am 
    $(do_subst) < $(srcdir)/buildconf.py.am > buildconf.py 

Является ли это «нормальным» или «приемлемым»? Поскольку я пытаюсь консолидировать все это, поскольку все становится «сложным» и трудно обновляемым, похоже, что это одно из огромных исправлений для меня.

TY!

EDIT:

Сценарий в основном определяет пути для папок, используемых «плагин», таким образом, нуждающихся в таких вещах, как DATADIR или мягкая INSTALLDIR. Он также определяет структуру папок, которая будет использоваться этими плагинами, чтобы они могли быть импортированы с помощью кода python так называемых плагинов. Кроме того, эти «плагины» на самом деле являются уровнем сервера/маршрутизации приложения.

• buildconf.py.am.in файл не генерируется, но записывается вручную;
• buildconf.py.am объявлен среди других в AC_CONFIG_FILES (как это могло быть? Он должен сказать «должно быть buildconf.py.am.in.am рядом с ним, который будет использоваться для создания buildconf.py.am.in.in, чтобы затем сделать» buildoncf.py.am.in файл ... Но все мы хотим и получаем buildconf.py);
• работает configure генерирует buildconf.py.am, заданные переменные - это два булеана, которые указывают, предусмотрены ли плагины mongoDB и web UI;
• make создает окончательный buildconf.py, который должен быть импортирован там, где необходимы постоянные, которые он удерживает. Это делается в это время, так как ему нужны переменные, которые меняются во время шага настройки.

Answer 1

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

Обычно.am файлов включены Makefile.am и расширены automake, так, например, они используются, чтобы иметь в-справочник определение источников и цели, сохраняя при этом общие сборки нерекурсивны.

Вы можете включать файлы в то Makefile уровне, с тем, что включение выполняется make вместо этого, но называть их .am звучит неправильно, что путь.

Но в этом случае это ни один из них, скорее всего, это скорее должно быть вызвано .in.in (есть несколько сценариев, которые делают что-то подобное), но он немного позади. Вероятно, он делает примерно один и тот же смысл для обработки один раз, просто применяя все замены во время фазы make.

Я думаю, самый вероятный случай заключается в том, что каким-то образом первоначальное расширение было неправильным и оно было стратифицированным, но не зная, что кодовая база трудно сказать.