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

Better path-matching for package relocatability (was 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, pgsql-hackers(at)postgresql(dot)org
Subject: Better path-matching for package relocatability (was Re: horology regression test failure)
Date: 2005-12-21 15:53:39
Message-ID: 13560.1135180419@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-hackers
Martin Pitt <martin(at)piware(dot)de> writes:
> Tom Lane [2005-12-20 16:39 -0500]:
>> 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 ...

> Right, with make_relative_path's current approach that seems to be
> impossible. However, in a test suite I had expected a semantics like
> $DESTDIR, i. e. instead of mangling the path somewhere in the middle,
> the test suite should just prepend the tmp_check path.

Well, more generally what we need is a better match algorithm in
make_relative_path.  After a few moment's thought I propose:

* Determine the common prefix of the compiled-in target_path and
bin_path (for typical cases this would be "/usr" or "/usr/local";
worst case is that the common prefix is just "/").  Call everything
to the right of the common prefix the "tail" of these paths.  The
currently expected scenario is that the tails are "share" and "bin",
but there might be more than one directory level in them.

* Try to match the tail of the bin_path to the end of the actual binary
location (my_exec_path without the executable's name).

* If match, take everything to the left of the match in my_exec_path,
and append the tail of target_path to produce the result.

* If no match, use target_path as-is, same as now.

I think this would get right all of the cases the current code gets
right, and more generally would work when we need to substitute N
levels of directory names instead of just one.  It may still be a
few bricks shy of a load, however.  Any thoughts?

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2005-12-21 16:04:08
Subject: Re: localization problem (and solution)
Previous:From: Tom LaneDate: 2005-12-21 14:49:21
Subject: Re: localization problem (and solution)

pgsql-bugs by date

Next:From: Peter EisentrautDate: 2005-12-21 21:23:45
Subject: Re: horology regression test failure
Previous:From: Sagi BashariDate: 2005-12-21 12:18:51
Subject: BUG #2120: Crash when doing UTF8<->ISO_8859_8 encoding conversion

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