Re: Configure problem, redux (was Re: TCL installation troubles)
От | Brook Milligan |
---|---|
Тема | Re: Configure problem, redux (was Re: TCL installation troubles) |
Дата | |
Msg-id | 199810271842.LAA06261@trillium.nmsu.edu обсуждение исходный текст |
Ответ на | Configure problem, redux (was Re: TCL installation troubles) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Re: Configure problem, redux (was Re: TCL installation troubles)
|
Список | 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 knowledgeof 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
В списке pgsql-hackers по дате отправления: