header search path change with 2003-03-02 commit

[Hans-Peter Nilsson]

On Tue, 18 Mar 2003, Daniel Jacobowitz wrote:
> On Tue, Mar 18, 2003 at 02:03:32PM -0500, Hans-Peter Nilsson wrote:
> > I think /A should still be be searched as a fallback, as long as
> > you can't *prove* that *all files* are moved (like, by finding
> > them at the relocated place).  For example, the use of the -B
> > option or finding "gcc" or "xgcc" somewhere else does not mean
> > everything has moved; it just implies a new include-path that
> > should be preferred over previous ones.  Maybe just the gcc
> > binary was moved!  If not, there's breakage, as happened to my
> > test-installations.  Repeatable and hopefully sane example
> > follows.
>
> I don't agree at all.  "maybe just the gcc binary was moved" is a sort
> of relocation that requires us to read the user's mind.  We're not in
> that business, are we?

I did not imply that.  Rather, if we can't find a piece of the
compiler, library and include files that we would trivially find
with a relocated installation (mv of directory), then the
installation hasn't actually moved.  It is *right* to search the
original location as a last resort.

> Do you have an example of an installed, relocated tree that you think
> justifies searching the original prefix?  I can't think of one.

Well, "can't think of" implies an attempt at reading the user's
mind, methinks. (So we're in that business after all? ;-)

Do you have pointers to bug reports or PR:s for the "bugs" you
refer to that are solved by not searching the original
installation location?  Since the moved-to location should be
searched before the original location, "I can't think of" a case
where that'd go wrong (assuming it's correctly implemented and
not a mix of searching the original and the moved-to location).

brgds, H-P