Thread

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

   Tom Lane <tgl@sss.pgh.pa.us> — 1999-05-11T14:18:16Z

   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/local
   	bindir=${exec_prefix}/bin
   	libdir=${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 tried
   	expanded_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
   
   

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

   Bruce Momjian <maillist@candle.pha.pa.us> — 1999-05-11T15:21:48Z

   > 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 tried
   
   
   
   > 	expanded_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?
   
   Please try:
   
   	expanded_libdir="`eval echo $libdir`"
   
   Then I assume you have to do a:
   
   sed "s/@libdir@/$expanded_libdir/g" <mklang.sql.template >mklang.sql
   
   I can take it if you commit what you have.  The one item I am not sure
   about is having it generate mklang.sql when the configure values change.
   When they run configure, I think we have to generate a new file, so the
   Makefile can see the change in datestamp and generate a new mklang.sql. 
   Sounds like we need mklang.template.in, mklang.template, and mklang.sql
   and a rule in the makefile that mklang.sql depends on mklang.template.
   
   You can complete it, or I will take a crack at it.
   
   -- 
     Bruce Momjian                        |  http://www.op.net/~candle
     maillist@candle.pha.pa.us            |  (610) 853-3000
     +  If your life is a hard drive,     |  830 Blythe Avenue
     +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026
   
   

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

   Brook Milligan <brook@trillium.nmsu.edu> — 1999-05-11T21:59:34Z

      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 tried
   	   expanded_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?
   
   Isn't the correct solution to have the Makefile contain a rule that
   creates the file from a template (e.g., with sed -e
   's/@xxx@/${xxx}/g')?  That way make resolves the variable references
   and you needn't worry about it.  You can have the rule depend on
   something like Makefile or Makefile.global or wherever the relevant
   variables are set so that if local tweaks are made the files get
   remade automatically.
   
   Cheers,
   Brook
   
   
   
   

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

   Bruce Momjian <maillist@candle.pha.pa.us> — 1999-05-11T22:04:40Z

   >    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 tried
   > 	   expanded_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?
   > 
   > Isn't the correct solution to have the Makefile contain a rule that
   > creates the file from a template (e.g., with sed -e
   > 's/@xxx@/${xxx}/g')?  That way make resolves the variable references
   > and you needn't worry about it.  You can have the rule depend on
   > something like Makefile or Makefile.global or wherever the relevant
   > variables are set so that if local tweaks are made the files get
   > remade automatically.
   
   Yes, that is what we were saying.
   
   -- 
     Bruce Momjian                        |  http://www.op.net/~candle
     maillist@candle.pha.pa.us            |  (610) 853-3000
     +  If your life is a hard drive,     |  830 Blythe Avenue
     +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026
   
   

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

   Bruce Momjian <maillist@candle.pha.pa.us> — 1999-05-12T04:39:11Z

   > 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/local
   > 	bindir=${exec_prefix}/bin
   > 	libdir=${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.
   
   Tom, I like your fix in configure.in better than adding a silly
   Makefilerule.  Yours is much cleaner.  You just created an
   expanded_libdir in configure.in and let that be expanded in the *.in
   files.  Great.
   
   -- 
     Bruce Momjian                        |  http://www.op.net/~candle
     maillist@candle.pha.pa.us            |  (610) 853-3000
     +  If your life is a hard drive,     |  830 Blythe Avenue
     +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026
   
   

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

   Brook Milligan <brook@trillium.nmsu.edu> — 1999-05-12T14:08:27Z

      Tom, I like your fix in configure.in better than adding a silly
      Makefilerule.  Yours is much cleaner.  You just created an
      expanded_libdir in configure.in and let that be expanded in the *.in
      files.  Great.
   
   The problem with solutions like this is that we end up proliferating
   expanded and unexpanded versions of the same variables; hence,
   maintenance problems with coordinating the various uses of this
   information.
   
   We've already had this discussion with some of the other cases (the
   perl or tcl interfaces come to mind but I'm not sure).  It would be
   unfortunate to make configure that much more complex when we don't
   really need to at all.  It seems we should be using Makefile rules to
   do what they are best at: automatically generating files based on
   known rules that depend on a specific database of local configuration
   options; configure's role should simply be to create that database.
   
   Cheers,
   Brook