Re: horology regression test failure - Mailing list pgsql-bugs

From Tom Lane
Subject Re: horology regression test failure
Date
Msg-id 6494.1135114794@sss.pgh.pa.us
Whole thread Raw
In response to Re: horology regression test failure  (Martin Pitt <martin@piware.de>)
Responses Re: horology regression test failure
List pgsql-bugs
Martin Pitt <martin@piware.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

pgsql-bugs by date:

Previous
From: Martin Pitt
Date:
Subject: Re: horology regression test failure
Next
From: Tom Lane
Date:
Subject: Re: horology regression test failure