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...?
The purpose of the make utility is to determine automatically which pieces of a large program need to be re-compiled, and issue the commands necessary to recompile them.
A build configuration is a collection of settings used to start a build and group the sequence of the builds in the UI. Examples of build configurations are distribution, integration tests, prepare release distribution, "nightly" build. A build configuration belongs to a project and contains builds.
What does all of this do. The configure script is responsible for getting ready to build the software on your specific system. It makes sure all of the dependencies for the rest of the build and install process are available, and finds out whatever it needs to know to use those dependencies.
A configuration file, also known as a config file, is a local file that controls the operations of a program, utility or process. Linux configuration files contain the settings and instructions for different systems, utilities, applications and processes.
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
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With