configure command line in installed directories?

[Ralf Corsepius]

On Thu, 2008-04-17 at 02:07 +0200, Pavel Pisa wrote:
> 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
A completely informative textual message from an application in it help string.

Ask yourself: How do you technically use it?

You don't use it anywhere. It's only purpose is to serve as "brief
summary" in support requests.

> The file "gcc/configargs.h" holds these information in the format
> suitable for inclusion into final binary.
This is a temporary, internal config-header. Nothing wrong with it.

On a broader view, nobody denies the usefulness of config-headers.
It actually is what I have been talking about from the very beginning of
this thread.

The real issue is: What to put into exported config-headers (bspopts.h,
cpuopts.h in RTEMS terms) and what to put into internal config-headers
(auto-headers, aka. config.h).

> Same for Linux kernel, as already stated, the default
> Linux kernel "make install" saves full configuration
> options file in
>   /boot/config-X.Y.Z
This is a generated configuration file of the Linux kernel's
configuration system - a closed and isolated world of its own.

A special case, if you want to call it this way.

> So my humble personal vote is for storing command line

Do you? 

You don't want "to store the command line". It's meaningless to anything
outside of a closed world's buildsystem.

If you want to store something, you want to store some results of
processing command-line options, such as to add 
"#define RTEMS_MULTIPROCESSING 1"
to a header (a config-header)
or add a compiled symbol to a library.

You do not want to store directories and the like, because this would
render a library non-locatable.


> 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.
You will want to make yourselves familiar with pkg-config.

It's very simple to use. It a very simple way to reflect system setups
and package dependencies to users and thereby to help users to use
libraries.

The problem with this thread is people lumping together different
aspects in knee-jerk reflexs ;)

Ralf