bug#17848: #17848 add suffix search to -l even when directory part in argument

[Eli Zaretskii <eliz@gnu.org>]

> From: npostavs@users.sourceforge.net
> Cc: 17848@debbugs.gnu.org,  rgm@gnu.org
> Date: Mon, 05 Sep 2016 18:59:22 -0400
> 
> > I'm not sure.  Wouldn't adding the leading directory to load-path in a
> > let-binding be a cleaner solution?  IOW, I don't understand the reason
> > for the "Take file from default dir if it exists there" logic in the
> > first place -- what are we gaining there?
> 
> If we let-bind `load-path', then this could influence the code that
> we're loading.  For more context, I came to this bug from
> test/Makefile.in:
> 
>     ## We need to use $loadfile because:
>     ## i) -L :$srcdir -l basename does not work, because we have files whose
>     ## basename duplicates a file in lisp/ (eg eshell.el).
>     ## ii) Although -l basename will automatically load .el or .elc,
>     ## -l ./basename treats basename as a literal file (it would be nice
>     ## to change this; bug#17848 - if that gets done, this can be simplified).

You have a point there, indeed.

However, I don't think the proposed solution, to pass to 'load' the
explicit absolute file name of a file that 'locate-file' found, is TRT
here.  Here's my rationale:

Stepping back a notch, what is the root cause of the reported bug?
The root cause, AFAICT, is that ./foo doesn't exist, and therefore we
pass literally "./foo" to 'load', which then looks for this relative
file name in every directory in load-path, and doesn't try the current
directory.  If we were to pass an absolute file name "/some/where/foo"
to 'load', it wouldn't have looked along load-path, but instead would
try /some/where/foo.elc, /some/where/foo.el, etc. -- exactly as
requested.

The proposed patch indeed passes an absolute file name to 'load', but
it passes the name of the first candidate file found by 'locate-file',
and that could very well be different from what 'load' would have
found, because 'load' has some additional features and logic that
'locate-file' doesn't.

So I think what we need is to see if 'locate-file' finds _any_
candidate at all, and if it does, simply pass to 'load' the result of

  (expand-file-name file)

disregarding the file name returned by 'locate-file'; and we should do
that only if 'file' is not an absolute file name to begin with.  WDYT?

One other thought: should we prefer an exact match, without any
extensions, in this particular case?  IOW, should "-l ./foo" prefer
'foo" even if "foo.el" or "foo.gz" etc. exist in the current
directory?  If we should indeed prefer an exact match, then we might
need to tweak the order of the suffixes to support that.

Thanks.