Re: [HACKERS] HPUX 10.01 build issues and solutions.

The Hermit Hacker <scrappy@hub.org> writes:
>     I do not agree with the requirement to consolidate the
> configuration decisions into just a couple of files...we do nothing
> differently, as it is now, then any other large package does it, and I do
> not see a requirement to change from what currently works.

What we have now works OK for run-of-the-mill installations on supported
platforms.  It's not very friendly for people who have slightly
nonstandard setups.  We've seen at least one actual example of that
since the discussion started (not counting Thomas' original complaint,
which I suppose you could write off as pilot error ... but if even
Thomas doesn't understand how to configure Postgres, then it must be a
pretty closely held secret...).  I expect a pass through the pgsql-admin
archives would turn up a bunch more examples.

Also, while I have seen packages that use configure to rewrite a ton of
subdirectory Makefiles (GNU Emacs, for example), I think they have
simpler and less failure-prone configuration setups than we do.  Emacs,
for example, isn't trying to interface to both Tcl/Tk and Perl --- two
packages that are out there in multiple versions and have no well
defined installation location.

Autoconf configure scripts are inherently not 100% reliable.  They are
heuristic tests that maybe will work 95% or 99% or even 99.9% of the
time, but trying to make them absolutely bulletproof for *any* target
system setup is folly.  Good practice is to provide a manual override
path for any decision the script makes.  Now, we can do that either by
adding configure script options or by making it reasonably convenient
to hand-modify the results of configure.  I submit that it is
counterproductive to have a list of script options that approaches the
size of Makefile.global.in + config.h.in.  That will just confuse the
average person who has no need for most of those options.

Also, to bring the discussion back to Thomas' original complaint, what
of Makefile.custom?  If editing Makefile.global stops being a useful
technique because we've put copies of configuration settings in too many
other places, then Makefile.custom is also a useless way of customizing
the system.

In fact there's an even more direct issue, namely the port files.
Roughly speaking, Makefile.port is capable of altering decisions
expressed in Makefile.global, and os.h is capable of altering decisions
expressed in config.h.  If we scatter configuration settings everywhere,
then those two files no longer have their hands on all the levers, and
writing new port files becomes more difficult if not impossible.
Furthermore, that style of working makes it more likely that developers
will break existing ports, by causing configure to write some choice
into some file without noticing that the port files for a platform other
than their own want to override that choice.

(Yeah, I know that we'd like to reduce dependence on the port files
by having configure auto-detect more things.  But I don't expect to be
able to eliminate the port files entirely --- there will always be some
things that it's not really practical to make configure detect.)

So I believe that it's good style and good sense to try to centralize
the results of configure in as few files as possible, preferably just
those two.
        regards, tom lane