configure command line in installed directories?

[Pavel Pisa]

On Wednesday 16 April 2008 17:17, Ralf Corsepius wrote:
> On Wed, 2008-04-16 at 10:58 -0400, Kate Feng wrote:
> > Robert S. Grimes wrote:
> > >Ralf's argument notwithstanding, I agree with Thomas and Joel on this
> > >one.
> >
> > Yes, the minimum is to have configure command line in installed
> > directory (e.g. config.log).
>
> You may want to ask upstream automake to implement this, if you consider
> this useful. I consider this proposal to be utterly silly.
>
> > The configure command lines definitely should be logged.
> >
> > Additionally, it would be wonderful to have a log file generated
> > automatically to keep track of history of all the configure command
> > lines for
> >
> > 1) The name and version of the package
> > 2) command lines
> > 3) time and date
> >
> > This log file could be generated at the same directory as
> > where -prefix=directory specifies or two level up from where
> > the package is built.  Thus, if the build directory is gone,
> > one have a history of the RTEMS configuration.
>
> Ask your system admin to do, if you think it's useful.
>
> None of the 10000's of auto*tools based packages on this planet does so
> and no distribution of any OS on this planet does so.
>
> You next step will be requesting to install ChangeLogs, I suppose?
> That's what almost all distributions on this planet do - As part of
> their packaging process.

Hello Ralf,

I cannot keep quiet and have to come up with counter examples
where configure parameters are saved in target binaries
or install directories

$ gcc -v --help 2>&1 | grep conf
Configured with: ../../configure --prefix=/usr --with-gnu-ld --with-gnu-as --enable-shared --enable-threads=posix --enable-__cxa_atexit --verbose --with-system-zlib --disable-nls --host=i586-pc-linux-gnu --enable-bootstrap

The GCC stores the toplevel config information into next Makefile variable
TOPLEVEL_CONFIGURE_ARGUMENTS=

The actual dir information is stored there

# This is set by the configure script to the arguments to use when configuring
# directories built for the build system.
BUILD_CONFIGARGS = --cache-file=../config.cache

The file "gcc/configargs.h" holds these information in the format
suitable for inclusion into final binary.

Same for Linux kernel, as already stated, the default
Linux kernel "make install" saves full configuration
options file in
  /boot/config-X.Y.Z

Even this is not enough, because there could be mismatch
between file and real running kernel image, so there
are two more options

-----------------------------------------------------------
Kernel .config support (IKCONFIG)

type: tristate
prompt: Kernel .config support

defined at init/Kconfig:237

This option enables the complete Linux kernel ".config" file
contents to be saved in the kernel. It provides documentation
of which kernel options are used in a running kernel or in an
on-disk kernel. This information can be extracted from the kernel
image file with the script scripts/extract-ikconfig and used as
input to rebuild the current kernel or to build another kernel.
It can also be extracted from a running kernel by reading
/proc/config.gz if enabled (below).
-----------------------------------------------------------

-----------------------------------------------------------
Enable access to .config through /proc/config.gz (IKCONFIG_PROC)

type: boolean
prompt: Enable access to .config through /proc/config.gz
    dep: IKCONFIG && PROC_FS

defined at init/Kconfig:249

This option enables access to the kernel configuration file
through /proc/config.gz.
-----------------------------------------------------------

This means, that you can only save options into bootable
image without runtime overhead or it is possible
even to waste RAM and access compressed config file
from /proc/config.gz file.

I personally think, that it could be extremely important
to find options used to prepare given build environment
installation, because it is allmost impossible to match
same state without knowledge of used configure options
in many cases (optimized for given CPU variant, etc).
The upgrade of the tools and build environment then
could be very dangerous process if some company dictated
practice to document all steps is not defined.

So my humble personal vote is for storing command line
in the installation directory same way as makefile
fragment is saved already. We use 
  include $(RTEMS_MAKEFILE_PATH)/Makefile.inc
  include $(RTEMS_CUSTOM)
  include $(CONFIG.CC)
to include RTEMS used options into our OMK Makefiles
rules based build environment
  <http://rtime.felk.cvut.cz/omk/>
and it works great.

By the way, some version of RTEMS OMK template can be found there
  http://rtime.felk.cvut.cz/repos/rtems-devel/rtems-omk-template/

If there is interrest, I can write more info.
We use it to build bigger projects even with packaging
of IMFS contents for RTEMS. The OMK simplifies writing
portable applications (we build from same sources for
RTEMS, Linux, System-less, and for different architectures,
ARM, PPC, H8S, etc) in the cases, where full
Automake is too big beast for user (mainly beginner
students in case of Czech Technical University,
where I give lectures).

Best wishes

                Pavel Pisa