Skip site navigation (1) Skip section navigation (2)

configure template-matching change

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org, pgsql-patches(at)postgreSQL(dot)org
Subject: configure template-matching change
Date: 1998-11-23 05:02:18
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
I've just checked in a rewrite of configure's method for guessing
the right template file to use when --with-template is not provided.

The old method was to look for an exact match to the $host value
(from config.guess) in template/.similar, and if that wasn't found
to strip all version information (digits and dots at the end) from
$host and try to match that against prefixes of entries in .similar.
This is clearly broken, because given .similar entries like
it is incapable of correctly choosing the one to use for a $host
value like "sparc-sun-sunos4.1.3".  After you strip the "4.1.3"
there is no basis for choosing the right .similar entry.

What I checked in tries for an exact match, and then tries to match
.similar entries to prefixes of the $host string.  This is fairly
obviously the right way round, IMHO.  I was able to remove some
redundant entries in .similar after making the change; for instance
collapse to
which has some chance of working on bsdi 3.2 as well, if there is such
a thing. 

*However*, I'm not too sure that the shell-script constructs I used
are 100% portable.  If you find that configure now goes belly-up when
you leave off --with-template, please let me know.

I checked this into the 6.4 tree as well, since it is in response
to a recent complaint that 6.4 fails to configure correctly on
SunOS 4.1.3...

			regards, tom lane


pgsql-hackers by date

Next:From: The Hermit HackerDate: 1998-11-23 05:20:17
Subject: Re: [HACKERS] configure template-matching change
Previous:From: The Hermit HackerDate: 1998-11-22 22:44:29
Subject: Re: [HACKERS] What happened to FAQ_Linux, FAQ_Irix?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group