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

[Drew Adams <drew.adams@oracle.com>]

> > Why should the target dir be hardwired to the source dir?  Testing
> > might be a reason for the enhancement: quickly remove the *.elc
> > dir from `load-path' to take byte-compilation complications out of
> > the equation.  Having different compilation dirs for different
> > Emacs versions could be another argument for such flexibility.
> >
> > Is there a compelling reason, beyond "we've always done without
> > this", not to let users specify the output dir?
> 
> 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.  And this was precisely
one of the possible use cases I outlined.  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).

So yes, this gives users more, not less control.  And with greater
control comes more possibilities to shoot oneself in the foot.

(The control is not strictly greater than now, of course, since
even now you can move .elc and .el files to whatever dirs you like.
All the suggested enhancement does is facilitate separation of .el
and .elc, letting you do that at compilation time.)

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

> 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?

> 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.  Can you give a concrete example showing why
separate dirs with .el and .elc would not be handled today?