Re: horology regression test failure

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