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

Re: horology regression test failure

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Martin Pitt <martin(at)piware(dot)de>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: horology regression test failure
Date: 2005-12-20 21:39:54
Message-ID: 6494.1135114794@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-hackers
Martin Pitt <martin(at)piware(dot)de> writes:
> Maybe I did something wrong with the configure options. That bug is
> reproducible with the pristine upstream 8.1.1 tarball and doing:

> =2E/configure --prefix=/usr  --mandir="\${prefix}/share/man"  \
>   --sysconfdir=/etc  --libdir="\${prefix}/lib/postgresql/8.1/lib" \
>   --libexecdir="\${prefix}/lib/postgresql-8.1/lib" \
>   --mandir=\${prefix}/share/postgresql/8.1/man \
>   --with-docdir=\${prefix}/share/doc/postgresql-doc-8.1 \
>   --datadir=\${prefix}/share/postgresql/8.1 \
>   --bindir=\${prefix}/lib/postgresql/8.1/bin \
>   --includedir=\${prefix}/include/postgresql/8.1

> However, it does *not* happen when I do not specify any configure
> options at all. I'll try to narrow down the problematic change
> further, but can you already see what the problem is here?

Yeah, the chosen-at-random pathnames ;-).  I quote from the comments
for make_relative_path():

 * This function exists to support relocation of installation trees.
 *
 *      ret_path is the output area (must be of size MAXPGPATH)
 *      target_path is the compiled-in path to the directory we want to find
 *      bin_path is the compiled-in path to the directory of executables
 *      my_exec_path is the actual location of my executable
 *
 * If target_path matches bin_path up to the last directory component of
 * bin_path, then we build the result as my_exec_path (less the executable
 * name and last directory) joined to the non-matching part of target_path.
 * Otherwise, we return target_path as-is.
 *
 * For example:
 *      target_path  = '/usr/local/share/postgresql'
 *      bin_path     = '/usr/local/bin'
 *      my_exec_path = '/opt/pgsql/bin/postmaster'
 * Given these inputs we would return '/opt/pgsql/share/postgresql'

In short, you can set --prefix however you want, but you really can't
tack random decoration between --prefix and /bin, /share and friends;
else make_relative_path will be unable to figure out how to transform
one to the other.

We could doubtless improve make_relative_path to some extent, but the
mess you have above seems impossible to deal with.  How is a mere
program supposed to deduce where things were moved to, given only
knowledge of the actual location of --bindir?  I see little if any
pattern that would allow prediction of the corresponding --datadir,
let alone --libexecdir or --includedir ...

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Hans-Jürgen SchönigDate: 2005-12-20 21:40:52
Subject: status of concurrent VACUUM patch ...
Previous:From: Martin PittDate: 2005-12-20 21:33:30
Subject: Re: horology regression test failure

pgsql-bugs by date

Next:From: Tom LaneDate: 2005-12-20 22:16:07
Subject: Re: horology regression test failure
Previous:From: Martin PittDate: 2005-12-20 21:33:30
Subject: Re: horology regression test failure

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