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

"Thomas G. Lockhart" <lockhart@alumni.caltech.edu> writes:
> I started out with a Makefile.custom which has in it the following:
> USE_TCL= true
> TCL_LIB= -ltcl
> X_LIBS= -L/usr/X11/lib
> TK_LIB= -ltk
> [ and it didn't work ]

There is a comment in Makefile.global.in that says:# Please do not edit USE_TCL and USE_TK by hand.
I dunno who put that in or why, but it seems relevant ;-)

An offhand look at configure.in shows that it is also deriving values
for TCL_CONFIG_SH and TK_CONFIG_SH, which need to be propagated into
places that Makefile.custom can't reach.  It looks to me like
mkMakefile.tcldefs.sh is probably not coping gracefully if an empty
string is substituted into it, which is what will happen right now
if USE_TCL isn't set during configure.  By setting USE_TCL in
Makefile.custom, you made the Makefiles think that Tcl support is
set up, but that doesn't take care of the subsidiary files.

> Is someone prepared to fix up the Makefile to make it
> more robust (e.g. it can't include a file which hasn't been constructed
> yet, though there are ways around that by conditionally including it and
> then running make from within that makefile).

Well, *that* is not the problem here.  GNU Make is smarter than you
realize about files that are included into a makefile --- it will
arrange to build the file if missing and then reread the makefile.
The problem is an inconsistent set of configuration values caused
by your hand-setting only some of the needed variables.  And you can't
even fix it by adding the missing variables to Makefile.custom.


This brings up an issue that I had been planning to raise in response
to Brook and Billy's disagreement a couple days ago about how to handle
"libdir" in the Makefiles (thread "Configure problem (and fix)").
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 believe it is considered good Autoconf style to emit a Makefile (or
whatever) that is still hand-editable, so that one can go in and tweak
the configure script's decisions after the fact.  (In other words,
Brook had the right idea as to style: libdir should be left unexpanded
in all references, so that you can actually change it by hand in
Makefile.global if you are so minded.)

We have broken that capability entirely --- if you don't set a parameter
to configure, you have little choice but to go and re-run configure,
because chasing down all of the twenty or so output files that it
generates is not very practical.  (Which was Billy's point, or part of
it; and he's right too.)

This is not good, and it is not necessary.  AFAICS there is *no* good
reason that configure should be rewriting any subdirectory Makefile ---
they all include Makefile.global, so anything they need to know could
be stated, once, in Makefile.global.  With a little more work we could
probably make Makefile.global and config.h be the only files that
configure creates at all.  The various specialized shell scripts that
configure is currently editing could be fixed so that they get their
configuration info from the command line, whence it could be supplied
from Makefile.global via the subdirectory Makefile that is invoking the
script.

I'm not certain how best to handle the SQL scripts that need to know
where libdir is, but I can think of several possibilities, one being
that "create function" could have a library search path built into it,
thus pushing the knowledge of where libdir is into some C code (which
would probably be getting it from the PGLIB environment variable).
Or we could put the value of libdir into a system table somewhere that
the scripts can read at runtime.


It's awfully late to be fixing this stuff for 6.4, unless you want to
slip the release date again.  But I suggest revisiting it for 6.4.1,
and trying to consolidate configuration decisions into as few files
as possible.
        regards, tom lane