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(at)candle(dot)pha(dot)pa(dot)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(at)hub(dot)org secondary: scrappy(at){freebsd|postgresql}.org