\
>> -f batch-byte-compile /tmp/foo/foo.el
>>
>> -> generates /tmp/bar/foo.elc
>>
>> batch-byte-compile exists since forever.
>
> Thank you. That looks better, indeed. I will see if I can adapt the
> automake patch accordingly.
I've done that and will push the
On Mon, Dec 11, 2017 at 9:56 AM, Glenn Morris wrote:
>
> Jim Meyering wrote (on Sun, 10 Dec 2017 at 17:01 -0800):
>
>> However, I don't see how "-f batch-byte-compile" can be used when
>> the .elc file must be created in a directory separate from the one
>> containing the .el file.
Jim Meyering wrote (on Sun, 10 Dec 2017 at 17:01 -0800):
> However, I don't see how "-f batch-byte-compile" can be used when
> the .elc file must be created in a directory separate from the one
> containing the .el file.
I meant, instead of reinventing the wheel with this part:
--eval
On Wed, Nov 29, 2017 at 12:17 PM, Glenn Morris wrote:
> The obsolete bytecomp feature is back as of Emacs 9964db4.
Thanks, I noticed when that was restored, but have been a way for a while.
> BTW, why doesn't lisp.am use the standard "-f batch-byte-compile"
> method of producing
The obsolete bytecomp feature is back as of Emacs 9964db4.
BTW, why doesn't lisp.am use the standard "-f batch-byte-compile"
method of producing .elc files?
Your two issues that affected only automake illustrate that the way
automake generates .elc files is different to the vast majority of
On Tue, Nov 28, 2017 at 2:23 PM, Glenn Morris wrote:
> Jim Meyering wrote:
>
>> Remember: this arises only in a non-srcdir build. That means build
>> artifacts end up being written into the mostly-empty current directory
>> hierarchy, which does not have copies of the sources.
Jim Meyering wrote:
> Remember: this arises only in a non-srcdir build. That means build
> artifacts end up being written into the mostly-empty current directory
> hierarchy, which does not have copies of the sources. Installation
> processes will continue to copy both .el and .elc files into
dition) patch that I expect to push to
> master tomorrow. Feedback welcome. I will also delete the "micro"
> branch I created.
> From 7558bddcc9cf5ee14441304c2cfc7cffb566daba Mon Sep 17 00:00:00 2001
> From: Jim Meyering <meyer...@fb.com>
> Date: Wed, 22 Nov 20
pies of the sources.
> Installation processes will continue to copy both .el and .elc files
> into place.
Here is the updated (NEWS addition) patch that I expect to push to
master tomorrow. Feedback welcome. I will also delete the "micro"
branch I created.
From 7558bddcc9cf5ee14441304c
On Mon, Nov 27, 2017 at 12:52 PM, Jim Meyering wrote:
> On Mon, Nov 27, 2017 at 10:27 AM, Glenn Morris wrote:
>> Jim Meyering wrote:
>>
>>> In May of 2017, support for using the long-deprecated
>>> byte-compile-dest-file function was removed, and that removal
On Mon, Nov 27, 2017 at 10:27 AM, Glenn Morris wrote:
> Jim Meyering wrote:
>
>> In May of 2017, support for using the long-deprecated
>> byte-compile-dest-file function was removed, and that removal broke
>> automake's elisp-compiling rule for any .el file not in the current
>>
Jim Meyering wrote:
> In May of 2017, support for using the long-deprecated
> byte-compile-dest-file function was removed, and that removal broke
> automake's elisp-compiling rule for any .el file not in the current
> directory.
In general, Emacs expects .el and .elc to be found in the same
On Fri, Nov 24, 2017 at 4:42 AM, Mathieu Lirzin wrote:
> Mathieu Lirzin writes:
>
>> Indeed HACKING is not up-to-date, I will fix that.
>
> Here is a patch that should help describing the new branching model more
> accurately. If you see further improvements or would
Mathieu Lirzin writes:
> Indeed HACKING is not up-to-date, I will fix that.
Here is a patch that should help describing the new branching model more
accurately. If you see further improvements or would prefer different
wording, tell me.
>From
Jim Meyering writes:
> On Thu, Nov 23, 2017 at 3:57 PM, Mathieu Lirzin wrote:
>>
>> Jim Meyering writes:
>>
>>> Pushed to the micro branch:
>>>
>>>
ot;new" way.
>>>
>>> I started discussion on emacs-devel last night:
>>> https://lists.gnu.org/archive/html/emacs-devel/2017-11/msg00551.html
>>>
>>>
>>> From ecad5844100d5193ecd58f66f31f6bbf0ef04e23 Mon Sep 17 00:00:00 2001
>>> From: J
017-11/msg00551.html
>>
>>
>> From ecad5844100d5193ecd58f66f31f6bbf0ef04e23 Mon Sep 17 00:00:00 2001
>> From: Jim Meyering <meyer...@fb.com>
>> Date: Wed, 22 Nov 2017 21:07:29 -0800
>> Subject: [PATCH] port elisp-compilation support to emacs-23.1 and n
From: Jim Meyering <meyer...@fb.com>
> Date: Wed, 22 Nov 2017 21:07:29 -0800
> Subject: [PATCH] port elisp-compilation support to emacs-23.1 and newer
>
> In May of 2017, support for using the long-deprecated
> byte-compile-dest-file function was removed, and that removal broke
>
ttps://lists.gnu.org/archive/html/emacs-devel/2017-11/msg00551.html
>From ecad5844100d5193ecd58f66f31f6bbf0ef04e23 Mon Sep 17 00:00:00 2001
From: Jim Meyering <meyer...@fb.com>
Date: Wed, 22 Nov 2017 21:07:29 -0800
Subject: [PATCH] port elisp-compilation support to emacs-23.1 and newer
In M
19 matches
Mail list logo