Re: [patch driver]: Fix relocatable toolchain path-replacement in driver

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Wed, 11 Sep 2013, Kai Tietz wrote:

> > update_path should, as I understand it, always be called with PATH being a
> > relocated path (one that has had the configured prefix converted to the
> > prefix where the toolchain is in fact installed, using
> > make_relative_prefix, or that doesn't need any relocation, e.g. a path
> > passed with a -B option).  In incpath.c, for example, you see how a path
> > is computed using make_relative_prefix before update_path is called.
> > Thus, it is correct for std_prefix to be the relocated prefix rather than
> > the unrelocated one.
> 
> I understand this different.  See here translate_name function (used
> by update_path).  If path is empty it falls back to PREFIX (not
> std_prefix).  So I understand that this routine tries to cut off
> compiled in prefix from paths and replaces it by key's path.  But
> well, I might got this wrong.

It doesn't really make sense to me for there to be a mixture of direct 
replacement of the configure-time prefix based on keys, and first 
replacing the configure-time prefix with the install location and then 
replacing that based on keys.

I think the most appropriate design is as I said: make_relative_prefix, 
and nothing else, deals with replacing the configure-time prefix with the 
install location, and then prefix.c deals with any subsequent replacements 
of the install location.  On that basis, translate_name should be using 
std_prefix not PREFIX, and any callers of these prefix.c interfaces that 
pass paths still using the configure-time prefix should be fixed so that 
the make_relative_prefix substitution occurs first.

You've found evidence of an inconsistency.  A fix needs to be based on a 
clear design - a clear understanding of what sort of paths should be used 
where and what interfaces should translate them to other kinds of paths - 
rather than just locally changing the paths used in one particular place 
without a basis for arguing that the change fits a coherent design and so 
won't cause problems elsewhere.

-- 
Joseph S. Myers
joseph@codesourcery.com