Re: [HACKERS] Configure problem, redux (was Re: TCL installation troubles)
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Bruce Momjian <maillist@candle.pha.pa.us>
Cc: hackers@postgreSQL.org
Date: 1998-10-27T22:42:31Z
Lists: pgsql-hackers
Bruce Momjian <maillist@candle.pha.pa.us> writes: >> Namely: I think we have gotten much too willing to use configure to >> rewrite subsidiary files all over the distribution, rather than ensuring >> that the configuration decisions are expressed in a central place. > I disagree here. If people want to twiddle, they can after configure. > People would much rather spell params to configure, rather than to edit > Makefiles. I agree with you, up to a point. What happens if configure makes the wrong choice for a given system? For a person not familiar with autoconf (which is most people) fixing its output is likely to be easier than trying to fix the script. > ... but they MUST be required to supply the proper flags to > configure. We can't go down the road of allowing them to avoid the > 'configure' flags, and somehow enable things in Makefile.custom. There > is no logical way to do that, and unless we want to prevent 'configure' > from doing the things it does so well, we will have to live with that > limitation. I certainly agree we should use configure for what it's designed to do, namely make intelligent configuration settings. I'm just saying that it is better style to record each configuration choice in only one place (or at least, as few places as possible) rather than make a bunch of copies in a bunch of not-easily-found files. This has advantages even if you don't consider hand adjustments to be important. Right now, if you want to find out what configure did on a given system, you need to look at twenty different files. (Some will give you no new information, but which ones?) Maintenance and support will be easier if there are only a couple of files that configure changes, and everything else just reads those files during build. regards, tom lane