Re: [HACKERS] Re: [SQL] plpgsql error

Bruce Momjian <maillist@candle.pha.pa.us> writes:
>> Oh ... OK, that looks like a garden-variety configure bug (one too many
>> levels of quoting, or some such).  I can look at this if no one else
>> beats me to it.

> It replaces @libdir@ with ${exec_prefix}/lib.  It appears the
> configure code expects the replacement to occour in a Makefile, so
> ${exec_prefix} can be replaced in Makefile.global.  However,
> $exec_prefix is not in Makefile.global, so maybe it is just a problem
> with configure that $exec_prefix is replace before @libdir@, and
> libdir's that contain exec_prefix have a problem.

configure is designed to generate makefiles that look like this:
exec_prefix=/usr/localbindir=${exec_prefix}/binlibdir=${exec_prefix}/lib

with the notion that this will simplify after-the-fact hand tweaking
of install destinations in the makefile if you feed a need to do that.
So that's why libdir's default definition looks the way it does.

Now, that works OK in makefiles and in shell scripts, where the
reference to the exec_prefix variable can get expanded when the file
is read.  But it falls down for mklang.sql, where the value of libdir
is substituted into an SQL command --- Postgres ain't gonna expand the
variable reference.

What we need is to substitute a "fully expanded" version of libdir into
this file, instead of a version that might depend on other variables.

Any shell-scripting gurus on the list?  I thought this would be an easy
fix, but I'm having some difficulty getting the configure script to
produce a fully-expanded value for libdir.  Given a shell variable that
may contain $-references to other variables, the requirement is to
assign to a new variable an expanded value containing no $-references.
I triedexpanded_libdir="$libdir"
but that just gets you an exact copy, no recursive expansion.  A few
other ideas didn't work either; the Bourne shell doesn't seem to want
to re-expand text it's already expanded.  Suggestions?
        regards, tom lane