bug#20968: 25.0.50; Be able to specify the output directory for `byte-compile-file'

[Drew Adams]

> > > One reason is to be able to use "M-x load-library RET", and have
> > > it DTRT.  If the *.elc files are separate from *.el, then at best
> > > the problem of deciding which version to load becomes harder and the
> > > loading becomes slower, and at worst you'll have a subtle bug on
> > > your hands.  E.g., what if more than one directory on load-path
> > > has a file that goes by the same name?  And in what order do you
> > > search load-path for the companion .el file, given that you found
> > > .elc in in some directory?
> >
> > It can of course happen that someone is confused, doesn't know how
> > `load-library' works, and doesn't get the behavior that s?he
> > mistakenly expected.
> >
> > But AFAIK, the behavior is well-defined.
> 
> It's well-defined only for the current behavior, where the *.el and
> the corresponding *.elc files live in the same directory.

How so?  Please give a concrete example where it is not well-defined
for a foo.el and a foo.elc that are in different directories.  Explain
what problems you think arise in such a case.

> > Ordering multiple dirs in `load-path' is a way to control which
> > version of a library gets loaded (whether .el or .elc gets loaded,
> > and which .el or .elc gets loaded).
> 
> Users will get to manage the resulting complexity.  I bet the OP
> didn't even understand what kind of hole he is digging for himself.

Who knows what the OP or other users might know?  Your point here
seems to be that even if the behavior is well-defined some users
might find it confusing.  Which is exactly what I already acknowledged:

  It can of course happen that someone is confused, doesn't know how
  `load-library' works, and doesn't get the behavior that s?he
  mistakenly expected.

> There's a limit where more becomes less.

Vague platitude, I'm afraid.  Please point to a specific problem,
if you expect us to make headway here in understanding.

> > So unless I'm missing something, I see no good argument against
> > the suggestion when it comes to `load-library'.
> 
> You see it, you just disagree with it.

I see (and already acknowledged) the possibility of a user, given
the additional control this provides, getting confused.  I have
not seen any other concrete argument.  There are plenty of places
in Emacs where we give users enough rope to hang themselves with.
`load-path' already presents plenty of such opportunity.

I don't see this enhancement as adding anything particular to the
possible confusion - someone confused by what it offers is very
likely confused about `load-path' behavior in general.  I don't
think this changes *anything* wrt `load-path' or the current
code that handles it.  You can already put .el and .elc wherever
you like, in the same dir, in separate dirs, mix&match - whatever.

You hand-wave about there being some problem with `load-library'
that would make the behavior ill-defined.  If you can show that with
an example, perhaps I will agree with you.  I really have no need
for the suggested enhancement, myself, and no axe to grind about this.
So far, it sounds to me like a reasonable request, but I welcome you
to provide an argument to the contrary.

> > > Last, but not least: the current implementation of loading a
> > > Lisp file is a 2-level loop, where the outer one loops over
> > > the directories, and the inner one over the suffixes.
> >
> > Which means that if there is only one suffix in a given directory
> > then the inner one becomes a trivial case, no?
> 
> ??? Are you saying we will no longer allow both *.el and *.elc, only
> one of them?

Did I say anything even vaguely suggesting such a thing?  Please
try to calm down.

Your argument is (as near as I can tell) that, because there is a
two-level loop, an enhancement that would let users automatically
place *.elc in a separate directory would be problematic and would
require changes in the C code.  You say nothing concrete about this.

I can only assume that you think it is a problem for the *current*
code to process multiple directories in `load-path', which might
have different .el or .elc files with the same (relative) file names.

I'm not aware of any such problem.  I think the code already
handles all such cases, regardless of where the .el and .elc files
might be located.  But as you know, I'm no expert in any of this,
and I am especially ignorant of the C code.

The case of the OP would put .el in one dir and .elc in another.
S?he would have to decide which of the two dirs, or both, to add
to `load-path' (and if both, in which order).  But in any case,
I see no problem or need for C code changes.

Can you please point out just what the problems are?

> > > So this suggestion, if implemented, will need C-level changes
> > > as well.
> >
> > I trust your estimation of that, but I don't understand why it
> > would be the case.
> 
> See above.

See above.  All I see is hand-waving, so far, I'm afraid.  But I
welcome a concrete example and explanation of the problem it poses
for the current code.