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

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.

For *.sql files there are two choices:

- have configure do the expansion. This requires either special
variables or expansion of lots of variables, neither of which is a
good solution because they require unusual coding practices or
prevent easy maintenance (i.e., change of Makefile.global) later.

- have make do the expansion. Certainly this puts some of configure's
job into some Makefiles, but it offers the advantage that
Makefile.global can be changed and those changes will propagate
where they are needed.

It seems like we need a well-documented policy decision, perhaps
between the two following options (plus any others people want to
formulate).

1. we are only speaking (to my knowledge) of the library locations, so
use ${expanded_libdir} in *.sql files; configure will do the right
thing with these (i.e., only expand this but leave the "normal"
variables unexpanded so that changes to Makefile.global propagate
easily), but changes to Makefile.global cannot touch the configured
choice for ${expanded_libdir}. Changes to that require going
through all the *.sql files seeking those with the wrong
expansions (or reconfiguring).

2. add rules to those few Makefiles that require it so that make will
expand for *.sql based on the configured choices. Changes to
Makefile.global will do the right thing.

The latter perhaps duplicates a tiny bit of configure, but is more
flexible. If the rule is made generic (which it really is) it can
even be put into Makefile.global as a pattern target and not even
worried about in any of the Makefiles; if there is a *.sql.in it will
be made into *.sql with the correct substitution, end of story, no
need to be concerned with duplicating parts of configure all over the
place. This follows the recent trend for a centralized set of rules
for shared library handling. Why not a central place for the common
*.sql substitution as well, so that what is in Makefile.global gets
propagated?

Cheers,
Brook