How do you "echo" the last configure/make build --options within a source directory?

Question

When doing a a GNU-style " ./configure, make, and install " - with specific options, flags, etc... As you all know, sometimes this can be a black art.. and what works for one piece of software may not for any other...

Now, imagine that you had successfully built some package XYZ.app with some options like...

% ./configure --with-1=2 USFLAG="-3 four" OBSCURE_LIB=l/lib/doihave

and gone ahead and used it. Great. At a later point, you realize you need a previously omitted compile-time option, or maybe you've resolved a dependency issue, etc... For whatever reason, you want to recompile this perfectly good binary.

Now... how can you "recall" ALL of the options you passed to ./configure, verbatim, so as to use those SAME options, while possibly adding or subtracting some, this time around?

I'm sure this stuff is buried somewhere in all those config.xxxx or AClocal or Makefile.xx files, but for the life of me, I haven'e been able to Google one straight answer.

% 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... all seem unwilling to help. One close-call seems to be the contents of the XYZ.pc file created by 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

However, these just seem like environmental variables, not arguments from the actual config invocation... I'm sick of guessing... what is the real way to figure out the original build arguments, so that you can use them again, at will...?

Unwelcome

Answer 1

config.status has the options in it; ./config.status --recheck re-runs configure with the original options. You could interrupt that and reissue the command (which it will show you before running it), or you could edit config.status and add your new parameters to $ac_configure_extra_args.

I do kinda wish they'd made it easier to do this. Once upon a time head config.status would get you the original configure command. ./config.status --rerun extra args here would have been nice.

Bronchial

i opened a random config.status on my machine... it was 2,600 lines - and 84,325 characters of virtual gobbledygook. i believe you, the info is probably in there... but where? i want to know what I did, before, that worked... and not change anything i don't have to, contradict a previous setting, etc. by the way, and i don't mean to digress, but who are they, really, (that you mentioned)? without looking it up, the gnu "people" exist solely in my mind as some quasi-mythological, ram-shepharding, elder-folk - that refuse to stop using Netscape 3.0, etc. – Unwelcome

Open it in your favorite editor and search for the second occurrence of the string ./configure; that line, and the setting of ac_configure_extra_args immediately prior (2 lines in the examples I have conveniently available here), is where the settings live. (They will move around depending on the autoconf version used, though. Very old ones will reproduce the configure command line in a comment in the top few lines of the script.) As for "they", the GNU autoconf project page documents the primary maintainers and contributors. – Bronchial

Answer 2

Incredibly, somehow everyone else missed the canonical way to do this, which has been around since 2 years before this thread began. :-)

I wondered the same thing as the OP and was disappointed by the lack of proper (non-ugly) ways to do this when I read this thread.

A few days later, while idly browsing release notes for Autoconf, I reached the release notes for Autoconf 2.65. And would you believe it?

Major changes in Autoconf 2.65 (2009-11-21) [stable]

[...]

config.status now provides a --config option to produce the configuration.

So, just running ./config.status --config does precisely what the OP asked for.

Here is the corresponding reference in the documentation: 17 config.status invocation, and a quote:

--config

Print the configuration settings in reusable way, quoted for the shell, and exit. For example, for a debugging build that otherwise reuses the configuration from a different build directory build-dir of a package in src-dir, you could use the following:

args=`build-dir/config.status --config`
eval src-dir/configure "$args" CFLAGS=-g --srcdir=src-dir

Kinship

I think this should the right answer. Straight to the point on what OP is asking. – Agnesagnese

./config-status also supports a --help option that describes the other options, which might be worth mentioning. – Galactic

Answer 3

I can't believe nobody mentioned config.log - it give you exactly what you are looking for:

This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake.

It was created by configure, which was generated by GNU Autoconf 2.69. Invocation command line was

$ ./configure --prefix /usr/local/syslog-ng/ --enable-linux-caps --enable-spoof-source

Iodous

Answer 4

If you still have the build tree, run ./config.status --recheck, then quickly press CTRL-C as it prints out what it will run before re-running configure.

Eras

That's pretty good. For instance, i got... ./config.status --recheck --> running CONFIG_SHELL=/bin/sh /bin/sh ./configure --with-mysql --with-ffmpeg --with-php=/usr/local/sbin/php-fpm --with-wwwuser=_www --with-wwwgroup=_www CFLAGS=-arch x86_64 -g -Os -pipe -no-cpp-precomp LDFLAGS=-arch x86_64 -bind_at_load --no-create --no-recursion when hitting a random build folder. That all sounds familiar, and is definitely what I wanted to know.. Now, why do you think they've made it so hard to get to... and worth nary a mention in any of the aforementioned's documentation? – Unwelcome

@alex gray: Probably because it's not expected that users would actually use it, I think. The only reason I knew of it is because I've seen the rebuild rules for configure fire it off. – Eras