The problem here is that you are duplicating the normal configure processing in every Makefile that needs it. This
willget old very fast, and hard to maintain. configure does this already, and automatically, in one place. Yes, you
mustre-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
ofwhich 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
advantagethat 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;
configurewill do the right thing with these (i.e., only expand this but leave the "normal" variables unexpanded so
thatchanges 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