Когда делает au GNU-стиль "./configure, make и install" - с определенными опциями, флагами и т.д. Как вы все знаете, иногда это может быть черное искусство. и то, что работает для одной части программного обеспечения, может не для других...
Теперь представьте, что вы успешно создали пакет XYZ.app с некоторыми опциями, например...
% ./configure --with-1=2 USFLAG="-3 four" OBSCURE_LIB=l/lib/doihave
и пошел вперед и использовал его. Отлично. В более поздний момент, , вы понимаете, что вам нужна ранее пропущенная опция компиляции или, возможно, вы решили проблему зависимости и т.д.. По какой-то причине вы хотите перекомпилировать этот совершенно хороший двоичный файл.
Теперь... как вы можете "напомнить" ВСЕ опции, которые вы передали, чтобы. /configure, verbatim, чтобы использовать эти ТОЛЬКО варианты, хотя возможно добавление или вычитание некоторых, на этот раз вокруг?
Я уверен, что этот материал похоронен где-то во всех файлах config.xxxx или AClocal или Makefile.xx, но для жизни меня я не смог ответить на один прямой ответ Google.
% file /usr/bin/$1 --> Mach-O 64-bit executable x86_64
% ld /usr/bin/$1 --> -macosx_version_min not specificed, assuming 10.6
% make -d --> * 20 pages of Makefile nonsense.... *
% ./config.log --> * shows some history, but nothing interesting. *
% ./config.status --> * does a strange sequence oddly similar to a "clean" *
% ./configure -h --> * 500 options, none of which is "show-me=your-shit" *
glibtoolize, otool, autoconf, automake, pkg-config... все, похоже, не хотят помочь. Одним из близких вызовов является содержимое файла XYZ.pc, созданного pkg-config..
prefix=/usr/local \ exec_prefix=${prefix} \ libdir=${exec_prefix}/lib
includedir=${prefix}/include \ Libs: -L${libdir} -lxyz-base
Cflags: -I${includedir} -I${includedir}/xyz
Однако они просто выглядят как переменные окружения, а не аргументы из фактического вызова config... Мне надоело гадать... каков реальный способ выяснить исходные аргументы построения, чтобы вы могли использовать их снова, по желанию...?
config.status имеет в нем опции; ./config.status --recheck повторно запускает configure с исходными параметрами. Вы можете прервать это и переиздать команду (которую она покажет вам перед запуском), или вы можете отредактировать config.status и добавить новые параметры в $ac_configure_extra_args.
Я хочу, чтобы они облегчили это. Когда-то head config.status предоставил вам оригинальную команду configure. ./config.status --rerun extra args here было бы хорошо.
Невероятно, как-то все остальные пропустили канонический способ сделать это, что было вокруг с 2 лет до начала этой темы.
Я задавался вопросом то же самое, что и OP, и был разочарован отсутствием надлежащих (не уродливых) способов сделать это, когда я прочитал этот поток.
Несколько дней спустя, при просмотре заметок о выпуске Autoconf, я достиг примечаний к выпуску для Autoconf 2.65. И вы поверили бы этому?
Основные изменения в Autoconf 2.65 (2009-11-21) [стабильные]
[...]
config.status теперь предоставляет параметр -config для создания конфигурации.
Итак, просто запуск ./config.status --config делает именно то, что запросил OP.
Вот ссылка в документации: 17 config.status invocation и цитата:
--configРаспечатайте параметры конфигурации многоразовым способом, указанным для оболочки, и выйдите из нее. Например, для сборки для отладки, которая в противном случае повторно использует конфигурацию из другого каталога build-dir пакета в src-dir, вы можете использовать следующее:
args=`build-dir/config.status --config` eval src-dir/configure "$args" CFLAGS=-g --srcdir=src-dir
Не могу поверить, что никто не упоминал config.log - он дает вам именно то, что вы ищете:
Этот файл содержит любые сообщения, созданные компиляторами, в то время как запустить configure, чтобы помочь отладке, если configure делает ошибку.
Он был создан configure, который был созданный GNU Autoconf 2.69. Командная строка вызова была
Если у вас все еще есть дерево сборки, запустите ./config.status --recheck, затем быстро нажмите CTRL-C, когда он распечатает, что он будет запускать, перед повторным запуском configure.