From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#20968: 25.0.50; Be able to specify the output directory for `byte-compile-file' Date: Sat, 4 Jul 2015 07:41:47 -0700 (PDT) Message-ID: References: <<23829743-922e-4304-8ab3-b762b8193860@default>> <<74y4iytdjg.fsf@fencepost.gnu.org>> <> <<83pp49zb03.fsf@gnu.org>> <> <<83pp48xqm8.fsf@gnu.org>> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1436021100 14528 80.91.229.3 (4 Jul 2015 14:45:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 4 Jul 2015 14:45:00 +0000 (UTC) Cc: 20968@debbugs.gnu.org To: Eli Zaretskii , Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Jul 04 16:44:47 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZBOgQ-0004lP-OD for geb-bug-gnu-emacs@m.gmane.org; Sat, 04 Jul 2015 16:44:47 +0200 Original-Received: from localhost ([::1]:44548 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZBOgQ-0000FS-2a for geb-bug-gnu-emacs@m.gmane.org; Sat, 04 Jul 2015 10:44:46 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34771) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZBOet-0006CJ-CQ for bug-gnu-emacs@gnu.org; Sat, 04 Jul 2015 10:43:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZBOel-0004Fz-Lw for bug-gnu-emacs@gnu.org; Sat, 04 Jul 2015 10:43:11 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:38394) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZBOel-0004Fd-JX for bug-gnu-emacs@gnu.org; Sat, 04 Jul 2015 10:43:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZBOek-0005c7-VO for bug-gnu-emacs@gnu.org; Sat, 04 Jul 2015 10:43:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 04 Jul 2015 14:43:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20968 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 20968-submit@debbugs.gnu.org id=B20968.143602092421487 (code B ref 20968); Sat, 04 Jul 2015 14:43:02 +0000 Original-Received: (at 20968) by debbugs.gnu.org; 4 Jul 2015 14:42:04 +0000 Original-Received: from localhost ([127.0.0.1]:39840 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZBOdn-0005aU-Kb for submit@debbugs.gnu.org; Sat, 04 Jul 2015 10:42:04 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:18490) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZBOdl-0005Zx-7f for 20968@debbugs.gnu.org; Sat, 04 Jul 2015 10:42:01 -0400 Original-Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t64EfsvD015457 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 4 Jul 2015 14:41:55 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t64EfskX027166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 4 Jul 2015 14:41:54 GMT Original-Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t64EfsCS024274; Sat, 4 Jul 2015 14:41:54 GMT In-Reply-To: <<83pp48xqm8.fsf@gnu.org>> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] X-Source-IP: userv0022.oracle.com [156.151.31.74] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:104695 Archived-At: > > 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? >=20 > 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?