Peter Eisentraut <e99re41@DoCS.UU.SE> writes:
> On Tue, 9 May 2000, Tom Lane wrote:
>> dnl Check tr flags to convert from lower to upper case

>> Does anyone recall why this test is in there to begin with?

> I don't see the results of this test being used anywhere at all, so I'd
> say yank it. If your system doesn't support tr '[A-Z]' '[a-z]' the
> configure script will fail to run anyway, as it uses this contruct
> indiscriminately.

The results *are* used, in backend/utils/Gen_fmgrtab.sh.in (and
apparently nowhere else).  But the data being processed there is just
builtin function names, so I'm at a loss why someone thought that it'd
be worth testing for a locale-specific variant of 'tr'.  I agree, I'm
pretty strongly tempted to yank it.

But we haven't yet figured out Travis' problem: why is the configure
test failing?  Useless or not, I don't see why it's falling over...

			regards, tom lane

Wed, 10 May 2000 12:02:43 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Re: Problems compiling version 7 
I've found part of the problem.  I put "echo $TR" right before the line
that is failing.  $TR is set to "/usr/ucb/tr" during the
configuration.  The directory ucb does not exist.  If execute "which
tr" at the command line, I get "/usr/bin//tr."  Why is $TR getting set to
/usr/ucb/tr?

By the way, I do not get this problem when compiling the last version of
Postgresql on this same machine.  I'm in the processof upgrading.  That
compile was fine.

Thanks,

----------------------------------------------------------------
Travis Bauer | CS Grad Student | IU |www.cs.indiana.edu/~trbauer
----------------------------------------------------------------

> 
> But we haven't yet figured out Travis' problem: why is the configure
> test failing?  Useless or not, I don't see why it's falling over...
> 
> 			regards, tom lane


Wed, 10 May 2000 12:11:43 -0500 (EST)
Travis Bauer <trbauer@indiana.edu>
Re: [HACKERS] Re: Problems compiling version 7 
Tom Lane writes:

> >> dnl Check tr flags to convert from lower to upper case

> The results *are* used, in backend/utils/Gen_fmgrtab.sh.in (and
> apparently nowhere else).

Ah, I see. Substituting into source files directly from configure ... very
evil...

(Before you ask why: What if I change Gen_fmgrtab.sh.in, do I have to
re-configure?)

> But we haven't yet figured out Travis' problem: why is the configure
> test failing?  Useless or not, I don't see why it's falling over...

Unfortunately he cut off the line where it says `checking for tr'.


-- 
Peter Eisentraut                  Sernanders vï¿½g 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden


Wed, 10 May 2000 23:25:29 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: [HACKERS] Re: Problems compiling version 7 
Peter Eisentraut <peter_e@gmx.net> writes:
> Ah, I see. Substituting into source files directly from configure ... very
> evil...
> (Before you ask why: What if I change Gen_fmgrtab.sh.in, do I have to
> re-configure?)

Yup, or at least re-run config.status.  I've griped that configure
writes far too many files myself.  But I didn't have much luck
convincing the other developers that it's a bad idea to set things up
that way, rather than writing just a small number of config files.

We're going to have to deal with the problem though if we ever want
to be able to build in a separate directory tree...

			regards, tom lane

Wed, 10 May 2000 18:24:19 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Re: Problems compiling version 7 