From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Jim Meyering Newsgroups: gmane.emacs.devel Subject: Re: automake's .el support vs. recent loss of byte-compile-dest-file Date: Tue, 28 Nov 2017 19:35:04 -0800 Message-ID: References: <50da4282-fb9c-6de8-b054-73038a8ea338@cs.ucla.edu> <8B999815-EA73-4B86-8588-889E1F855A56@gnu.org> <833755ar44.fsf@gnu.org> <83k1yb65mk.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Trace: blaine.gmane.org 1511926580 15637 195.159.176.226 (29 Nov 2017 03:36:20 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 29 Nov 2017 03:36:20 +0000 (UTC) Cc: Paul Eggert , emacs-devel To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 29 04:36:13 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eJtAL-00037P-B5 for ged-emacs-devel@m.gmane.org; Wed, 29 Nov 2017 04:36:05 +0100 Original-Received: from localhost ([::1]:41131 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eJtAS-00029V-Jf for ged-emacs-devel@m.gmane.org; Tue, 28 Nov 2017 22:36:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51684) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eJt9m-00029O-05 for emacs-devel@gnu.org; Tue, 28 Nov 2017 22:35:31 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eJt9k-0001L7-Pk for emacs-devel@gnu.org; Tue, 28 Nov 2017 22:35:30 -0500 Original-Received: from mail-qt0-x232.google.com ([2607:f8b0:400d:c0d::232]:34274) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eJt9i-0001KH-Ox; Tue, 28 Nov 2017 22:35:26 -0500 Original-Received: by mail-qt0-x232.google.com with SMTP id 33so2747881qtv.1; Tue, 28 Nov 2017 19:35:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=BLPSVu6YfsgEbu7JBoqqsvGEjAynx8xqXAigKXOQOX8=; b=D8fDKWs1aRANSjUJ0WUyG0pjacPfxOYSn/1XM3r2x6lnIGLZB/q3oeKrkVSp2tqWPr Rf6XqwtO72a58RR9CR2ywkGwZNunlruOXnf7PdG0tBlUCZHv48fDwFpTov7pPo3OPhXI yX+lql657CoF1xPbkUTDdFaf+YvIIj5vghKt7HT2LgLMg6QPzZRGwP2crZXuH7w/0wjJ /CgsSqUKAuu+jSXOlcRIST5JV6mXBu6KsAF62RUP8Vvj5kGKRlP3jtuuWB98DFkiH+2d aMdW74y8iOOJUgjBALJUCb43drMhPWrbULqqIL7p7wJpHwxR0GXWnMPN+7yNq8iGbOal WjvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=BLPSVu6YfsgEbu7JBoqqsvGEjAynx8xqXAigKXOQOX8=; b=ATWjBK5g6AoacbgwExIKF0stmj+TBta6MGWjSZhgGO1MXg4qS2wx/7RJIES9xerbDH iM5MgEmfE8pyCvFUFqPUkDSZ4TKEKWGqYmpX4aqUITAmNEoILYtDCP/gIsTbLNvdD24S GFbUxjpPzO/P3/p6s804n6hfHDyOyQtf7Q4cCUUOahPkmPWgc+0C4NIsJek+S9Kt9gjS 9fp0ds3/xCi5Q4/A1/93Bv+asG8QsQ8xT74WRCrpo5A+JZfXJUb3I6/EQok2nxmRduqP avai9djORJS1DKYMifDpe3gMwYbhKilfIRQgKnB0MD1KwFTbvCQLpCKwzZzui1VfuW2h HzSg== X-Gm-Message-State: AJaThX4KwjT/T8RX1cRI2Jp0XxWJrUVi6aU4ZhPVZwiQstwG6F3XcViD o0GjPLuRZoRaYqD2Ha4KVDFCvPz3qrF63tJRfNwDag== X-Google-Smtp-Source: AGs4zMYfEUX/VCOcvLbqpsri2NSFBIH4r50+fFidVH4wAWJ3fy6+WdlrwnMcODwfOfMT55mS1l2pU63jwAVNnAX0MaE= X-Received: by 10.200.36.203 with SMTP id t11mr2380541qtt.277.1511926525435; Tue, 28 Nov 2017 19:35:25 -0800 (PST) Original-Received: by 10.55.9.17 with HTTP; Tue, 28 Nov 2017 19:35:04 -0800 (PST) In-Reply-To: <83k1yb65mk.fsf@gnu.org> X-Google-Sender-Auth: 5dXzyS5943_t-9pXjXBwL5dXQdY X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:400d:c0d::232 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:220514 Archived-At: On Mon, Nov 27, 2017 at 8:36 AM, Eli Zaretskii wrote: >> From: Jim Meyering >> Date: Sun, 26 Nov 2017 17:17:59 -0800 >> Cc: emacs-devel , Paul Eggert >> >> >> I've just posted an automake fix: >> >> https://lists.gnu.org/archive/html/automake/2017-11/msg00038.html >> > >> > Thanks. The question that's important to us is, of course, when will >> > this fixed version be available widely enough for us to consider >> > removing the support for the old ones. >> >> I agree. What Emacs does here will influence at least the wording of >> the automake NEWS entry for that automake change I mentioned. Should I >> call it a bug fix, because this behavior will make it into a release? >> Or is it just a work-around for those who happen to be using >> pre-release Emacs, and it won't affect anyone using an actual release? > > My intention, unless I hear objections, is to resurrect the removed > feature on the emacs-26 branch, but add an annoying warning there, so > that any packages and maintainers who didn't notice the deprecation > will do so sooner rather than later. But the feature will remain > removed on the master branch, which will eventually become Emacs 27. > So I think your change is a bug fix, and its purpose is to make > Automake future-proof against imminent changes in Emacs. It is also > for those who already use development snapshots of Emacs 27, because > the function will remain removed there. Thanks. Another possible fix proposed by Glenn was to use -l bytecomp and to continue to override byte-compile-dest-file. However, I have hit a new seemingly unrelated snag: subdirs. This now fails, where the argument to byte-compile-file is a dot-relative name in a subdirectory: $ (export TMPDIR=/tmp; mkdir sub && : > sub/x.el && emacs --batch -l bytecomp --eval '(defun byte-compile-dest-file (f) "sub/x.elc")' --eval "(unless (byte-compile-file \"sub/x.el\") (kill-emacs 1))" ) Creating file with prefix: No such file or directory, /tmp/sub/x.elc While it worked fine with emacs built from a commit on master from 2017-07-29, some time between then and Aug 11, things changed so that byte-compiling such a source file name requires the relative directory name first be created in $TMPDIR. Was that deliberate? For reference, this was exposed because an automake test exercises that code path: I ran it individually via this: make check TESTS='t/lisp-subdir.sh'