Вопрос по Automake

Копни чуть глубже в историю и найди первый десяток коммитов с этим GENERIC-костылем. Где-нибудь там (скорее всего) будет пояснение что это и зачем. Спустя 20 лет другого пути примерно нет.

test -f file.c || echo $(srcdir)/

Эта команда возвращает пустую строку, если file.c найден, и $(srcdir)/ в противном случае

//мимокэп

Чувак, спасибо.

Я уже копнул. Ссылка на второй коммит.

• automake.in (&add_depend2): Transform `GENERIC’.

Get rid of the ad hoc transformation of @EXT@.o:' which in addition was broken by the@ -> %’ patch.

• depend2.am: Adjust to use ?GENERIC?.

Только это по-прежнему нихрена не объясняет. Потому и написал сюда.

Всё верно. С этим мы уже разобрались ранее.

В случае сборки “in-tree” срабатывает первая ветка, в случае “out-of-tree” (оно же “VPATH build”) — вторая.

Мой вопрос в том, зачем вообще нужны эти финты ушами, если тип сборки (обычная или VPATH) можно определить на этапе запуска configure.

Из предыдущей темы:

[…] я бы предположил, что файл из локального каталога (если есть) должен иметь более высокий приоритет, чем тот же файл из VPATH.

Мне кажется это и есть ответ. По относительному пути находится файл из каталога сборки. А его наличие может зависеть от чего-то во время самой сборки, поэтому проверяют в последний момент.

Спасибо за ответ.

Но мой вопрос, ещё раз, заключается немного в другом.

Почему в некоторых проектах путь к файлу вычисляется на этапе выполнения configure (т е путь получается жёстко прошит в сгенерированных Makefile’ах), а в некоторых — он становится вот таким, «динамическим» ? Я пытался сравнить исходные configure.ac и Makefile.am — и так и не нашёл, что влияет на вид конечного Makefile.

Не знаю.

Если в документации ответа нет, предлагю написать этот вопрос автору изменений. Или кто там сейчас действующий мейнтейнер.

А есть пример относительно простого проекта с «динамическим» путём?

если тип сборки (обычная или VPATH) можно определить на этапе запуска configure.

А если нельзя? Вариант с test -f — универсальный, он сработает в любом случае. Надо оно тебе или нет — решай сам, autotools же просто «фреймворк».

Спасибо.

Да, есть.

strace и libgstreamer.

Не так чтобы простые проекты, но что-то получилось. Установка по крайней мере одной из этих переменных (в любое значение, даже пустое):

foo_CFLAGS =
foo_CPPFLAGS =

превращает

gcc -DHAVE_CONFIG_H -I.     -g -O2 -MT foo.o -MD -MP -MF .deps/foo.Tpo -c -o foo.o foo.c

в

gcc -DHAVE_CONFIG_H -I.     -g -O2 -MT foo-foo.o -MD -MP -MF .deps/foo-foo.Tpo -c -o foo-foo.o `test -f 'foo.c' || echo './'`foo.c

Как можно заметить у объектный файлов дополнительно появился префикс приложения (foo-).

В depend2.am кстати есть рядом с test -f:

## For non-suffix rules, we must emulate a VPATH search on %SOURCE%.

Ещё из automake.in (оно из секции о info-файлах, но это тот же флаг вроде):

  # We can output two kinds of rules: the "generic" rules use Make
  # suffix rules and are appropriate when $source and $dest do not lie
  # in a sub-directory; the "specific" rules are needed in the other
  # case.
  #
  # The former are output only once (this is not really apparent here,
  # but just remember that some logic deeper in Automake will not
  # output the same rule twice); while the later need to be output for
  # each Texinfo source.

Generic правила в выходном Makefile не перечисляют именя файлов явно, а non-generic выписывают для каждого файла свои правила (при этом generic правила в выходном файле тоже есть). Каким боком ко всему этому флаги, я не понял. Может быть это баг.

Установка по крайней мере одной из этих переменных (в любое значение, даже пустое):

foo_CFLAGS =
foo_CPPFLAGS =

Спасибо тебе, добрый человек.

Попробовал – подтверждаю: добавление CFLAGS/CPPFLAGS действительно приводит к переходу из «generic»-режима в «specific»-режим.

Проблему можно считать решённой.