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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 4 Jul 2015 07:41:47 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: rgm@gnu.org, 20968@debbugs.gnu.org
> 
> > > 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.

It's well-defined only for the current behavior, where the *.el and
the corresponding *.elc files live in the same directory.

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

> So yes, this gives users more, not less control.

There's a limit where more becomes less.

> And with greater control comes more possibilities to shoot oneself
> in the foot.

Exactly.

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

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

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