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

From: Brook Milligan <brook(at)trillium(dot)NMSU(dot)Edu>
To: tgl(at)sss(dot)pgh(dot)pa(dot)us
Cc: lockhart(at)alumni(dot)caltech(dot)edu, Bill(dot)Allie(at)mug(dot)org, hackers(at)postgresql(dot)org
Subject: Re: Configure problem, redux (was Re: TCL installation troubles)
Date: 1998-10-27 18:42:35
Message-ID: 199810271842.LAA06261@trillium.nmsu.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

The way to handle this is to have rules in the Makefile that do the
substitution. For example, something like the following Makefile
fragment will do the trick, even if the definitition of $libdir in
Makefile.global is modified after configure is run.

SRCDIR=../../..
include ${SRCDIR}/Makefile.global
mklang.sql: mklang.sql.in ${SRCDIR}/Makefile.global
sed < $< > $@ -e 's:@libdir@:${libdir}:'

If I remember correctly, this is used in contrib/spi and should be
common practice throughout.

Your suggestion of a single central Makefile.global/config.h to
contain all the configure decisions is a good one. Together with
rules such as above in the various appropriate places, the problems of
variable expansion and post-configure modifications disappear.
Perhaps not for 6.4, though.

Cheers,
Brook

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 1998-10-27 18:43:52 Re: [HACKERS] make install fails in perl5 ...
Previous Message Tom Lane 1998-10-27 18:29:04 Re: [HACKERS] make install fails in perl5 ...