Re: [HACKERS] Re: Configure problem, redux (was Re: TCL installation troubles)

Just curious, but exactly *what* problem are we trying to fix here?  It
sounds to me like alot of discussion is going into a solution to a problem
that I don't know if exists or not, since I don't recall anyone stating a
problem...

If configure is making 'wrong guesses', then we should be able to tighten
up the tests so that they are correct...

Frankly, and, again, I'm basing this off of memory, I can't think of
anywhere in the 'configure hierarchy' where configure changes anything
major.  Most of the 'changes' are to Makefile.global and config.h (and,
hey, I may not be the one that put the configure seed in, but am I the one
that cursed over a good portion of the tests and extending it)...

So, can someone state *what* the problem is?

On Tue, 27 Oct 1998, Bruce Momjian wrote:

> >    The problem here is that you are duplicating the normal configure
> >    processing in every Makefile that needs it.  This will get old very
> >    fast, and hard to maintain.  configure does this already, and
> >    automatically, in one place.  Yes, you must re-run configure, and you do
> >    loose your changes, but pulling all the stuff into every Makefile seems
> >    worse.
> > 
> > We are only doing this for the *.sql files because they don't have
> > within them some ability to do argument expansion.  This is definitely
> > not good for all the Makefiles or source code, both of which can get
> > what they need in a single place (Makefile.global or config.h).  I am
> > not advocating changing that.  In fact, I am agreeing with the idea of
> > becoming more centralized for those parts of the code that can handle
> > it, i.e., Makefiles and C source.
> 
> Oh.  :-)
> 
> I will go back to looking the other way.
> 
> 
> -- 
>   Bruce Momjian                        |  http://www.op.net/~candle
>   maillist@candle.pha.pa.us            |  (610) 853-3000
>   +  If your life is a hard drive,     |  830 Blythe Avenue
>   +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026
> 

Marc G. Fournier                                
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org