Re: [PATCH] Remember configure's options for later recall

[Phil Edwards <pedwards at disaster dot jaj dot com>]

I apologize for the late reply.  My car died after I submitted that patch
(coincidence? you decide), and I've just now been able to get a rental.


On Mon, Sep 25, 2000 at 11:02:12PM -0700, Richard Henderson wrote:
> On Tue, Sep 26, 2000 at 12:46:36AM -0400, Phil Edwards wrote:
> > -LIB2FUNCS_EXTRA =
> > +LIB2FUNCS_EXTRA = configargs.c
> 
> This will be happily overridden by many a backend.  Not approved.

Okay.  Where /do/ additional generated source files for libgcc go?
Are they documented elsewhere, or is this just one of the things that
us new guys learn by bitter experience?  Perhaps the LIB2ADD assignment
directly, around line 954?  Currently that's all done by composition of
other variables; I assume you want to keep it that way.


> I don't understand why you're doing what you're doing, frankly.
> Despite the v3 thread.

Here's the rationale:

So that when users come to us with some freaky weird problem, we have an
easier way of answering the question, "Did J. Random User configure GCC
with --with-foo or with --disable-bar?  Or maybe with some rarely-tested
unusual combination?  Maybe J.R.U. didn't have anything to do with the
GCC installation; maybe the sysadmin at that site is off his rocker," etc.

There are a lot of configure --with's and --enable's for v3 that interact
in really "interesting" ways, and I mean "interesting" in the sense of
the old Chinese curse.  (And not just for v3, I'm sure.)

Trying to debug some of the problems when faced only with the effects
can be hard.  If the configure options are safely stashed away for later
retrieval, then we can see the causes instead of just the effects, right
down to the miscellaneous typos which configure cannot detect.


Here are some alternative approaches that don't touch libgcc:

=  We could store them in a one line text file somewhere down in there, just
   by doing the same thing that the tidbit in my configure.in patch does.
   To keep it safe[er], it'd have to be down in the backend binaries
   directory (or somewhere else that only GCC touches), and that just
   doesn't strike me as good.

=  Since it's intended for debugging, we could just write it directly into
   gccbug, when it gets created from gccbug.in.  I looked at this first,
   and have come to the conclusion that once again, GNATS has defeated
   my understanding.  Also this method doesn't help people (including
   local users of that GCC installation, or future package writers) who
   just want to get that string without submitting a bug report.

=  Rather than storing the configure argument string by itself, we could
   dump it directly into that little program that I showed in my patch,
   compile that program, and leave it sitting somewhere else in the
   installation.  Running the program prints the string.  The pros and
   cons to this are probably obvious to everyone.


Phil