GNU bug report logs -
#36681
Feature Request: Option to build Emacs without byte-compilation.
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 36681 in the body.
You can then email your comments to 36681 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#36681
; Package
emacs
.
(Mon, 15 Jul 2019 23:12:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Keith David Bershatsky <esq <at> lawlist.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Mon, 15 Jul 2019 23:12:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
There is an open question that I posed on emacs.stackexchange.com nearly two years ago:
https://emacs.stackexchange.com/questions/34362/how-to-build-emacs-without-byte-compiling-lisp-files
The current build time for the master branch is over 30 minutes, and seems like approximately 45 minutes, but I have not timed it exactly. A command-line option to skip byte-compilation when building Emacs would greatly enhance the productivity of people contributing to the development of Emacs. There are also threads that I have seen in the past couple of years looking for ways to quickly build Emacs for something called "unit testing":
https://emacs.stackexchange.com/questions/14043/build-a-minimal-emacs-25-for-unit-testing
I would suggesting creating a build option such as "--byte-compile=no" or "--without-byte-compile".
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#36681
; Package
emacs
.
(Mon, 15 Jul 2019 23:34:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 36681 <at> debbugs.gnu.org (full text, mbox):
make -C src emacs
is basically what you ask for (may not work in older versions).
But the better answer is to use multiple cores, since the build is very
parallelizable. A -j8 build from nothing takes < 4 minutes for me.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#36681
; Package
emacs
.
(Tue, 16 Jul 2019 00:54:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 36681 <at> debbugs.gnu.org (full text, mbox):
Thank you, Glenn, for looking into this feature request. As part of this feature request, I am hoping to essentially complete the entire build process without byte-compilation. For the following test, I used a master branch from today (0797b39185e66983c7286e89f93dd4f6c83b6ea7). My configure command line on a w32 virtual machine (running mingGW with ezwinports) is:
CFLAGS='-O0 -g3' ./configure \
--prefix=/c/docume~1/admini~1/desktop/trunk \
--enable-checking='yes,glyphs' \
--enable-check-lisp-object-type \
--without-compress-install \
--without-makeinfo \
--with-gnutls=no \
--with-mailutils \
--without-makeinfo
Here is a link to a gist containing the output (with errors) after calling 'make -C src emacs' from the command line of the root emacs repository directory:
https://gist.github.com/lawlist/de6bea1b348276e5318d227a074c9d14
This particular build is anticipated to fail towards the end with:
* * *
GEN ../../info/elisp.info
/c/docume~1/admini~1/desktop/emacs/doc/lispref//display.texi:5740: `SVG Path Commands' has no Up field (perhaps incorrect sectioning?).
* * *
as referenced in the thread that I posted today to the Emacs Devel mailing list:
https://lists.gnu.org/archive/html/emacs-devel/2019-07/msg00349.html
However, the build failed much sooner than expected using 'make -C src emacs' as reflected in the above-mentioned linked gist. In a nutshell, I'd like to reach the point at which the build would fail naturally because of a particular build-bug, or complete the entire process (if no build-bugs exist) -- including, installing Emacs to the directory specified by the "--prefix" option. In the above example, it would be nice to reach the above-mentioned `SVG Path Commands' build-bug error in less than 45 minutes.
As to the multi-thread suggestion, I'll need to do some reading to see if any of my antiquated machines and antiquated OSes support such an option. For the w32 builds, I am running a virtual machine containing Windows XP SP3 using MinGW and ezwinports.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> Date: [07-15-2019 16:33:24] <15 Jul 2019 19:33:24 -0400>
> From: Glenn Morris <rgm <at> gnu.org>
> To: Keith David Bershatsky <esq <at> lawlist.com>
> Cc: 36681 <at> debbugs.gnu.org
> Subject: Re: bug#36681: Feature Request: Option to build Emacs without byte-compilation.
>
> make -C src emacs
>
> is basically what you ask for (may not work in older versions).
>
> But the better answer is to use multiple cores, since the build is very
> parallelizable. A -j8 build from nothing takes < 4 minutes for me.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#36681
; Package
emacs
.
(Tue, 16 Jul 2019 01:50:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 36681 <at> debbugs.gnu.org (full text, mbox):
Keith David Bershatsky <esq <at> lawlist.com> writes:
> --without-makeinfo
>
> GEN ../../info/elisp.info
> /c/docume~1/admini~1/desktop/emacs/doc/lispref//display.texi:5740: `SVG Path Commands' has no Up field (perhaps incorrect sectioning?).
As I mentioned on the emacs-devel thread, the fact that you are building
info even though you've specified --without-makeinfo suggests something
has gone badly wrong.
> However, the build failed much sooner than expected using 'make -C src
> emacs' as reflected in the above-mentioned linked gist.
It looks like you have messed up timestamps which are confusing make. I
suggest trying again after 'make clean'. But note that on master, you
should use 'make -C src emacs.pdmp' (see
https://debbugs.gnu.org/36369#38).
> In the above example, it would be nice to reach the above-mentioned
> `SVG Path Commands' build-bug error in less than 45 minutes.
I wouldn't be sure that skipping elc building entirely would be a win,
since some of the build requires running the Emacs, and an Emacs using
.el files instead of .elc files would be slower.
> As to the multi-thread suggestion, I'll need to do some reading to see
> if any of my antiquated machines and antiquated OSes support such an
> option.
If you have a GNU Make recent enough to build Emacs, then you have
support for the option. Whether it actually speeds up the build depends
on how many cores you have, I guess.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#36681
; Package
emacs
.
(Tue, 16 Jul 2019 07:47:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 36681 <at> debbugs.gnu.org (full text, mbox):
On Jul 15 2019, Noam Postavsky <npostavs <at> gmail.com> wrote:
> Keith David Bershatsky <esq <at> lawlist.com> writes:
>
>> --without-makeinfo
>>
>> GEN ../../info/elisp.info
>> /c/docume~1/admini~1/desktop/emacs/doc/lispref//display.texi:5740: `SVG Path Commands' has no Up field (perhaps incorrect sectioning?).
>
> As I mentioned on the emacs-devel thread, the fact that you are building
> info even though you've specified --without-makeinfo suggests something
> has gone badly wrong.
If you have makeinfo, then --without-makeinfo is ignored. To truely
disable info generation you need to pass MAKEINFO=no.
Andreas.
--
Andreas Schwab, SUSE Labs, schwab <at> suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#36681
; Package
emacs
.
(Tue, 16 Jul 2019 23:07:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 36681 <at> debbugs.gnu.org (full text, mbox):
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
We used to distribute the compiled Lisp files, which made installation
much faster. They were removed a few years ago, I think to avoid the
possibility of variation in building. But this is a big slowdown in
building, and I am not surprised some users would rather we included
them.
--
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#36681
; Package
emacs
.
(Tue, 16 Jul 2019 23:14:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 36681 <at> debbugs.gnu.org (full text, mbox):
Richard Stallman <rms <at> gnu.org> writes:
> We used to distribute the compiled Lisp files, which made installation
> much faster. They were removed a few years ago
I don't think that's the case, compiled .elc files are still in the
latest tarball releases. They're not version controlled, so people
tracking development with git do have to compile the Lisp files.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#36681
; Package
emacs
.
(Wed, 17 Jul 2019 07:21:01 GMT)
Full text and
rfc822 format available.
Message #26 received at submit <at> debbugs.gnu.org (full text, mbox):
On July 17, 2019 12:13:21 AM GMT+01:00, Noam Postavsky <npostavs <at> gmail.com> wrote:
> Richard Stallman <rms <at> gnu.org> writes:
>
> > We used to distribute the compiled Lisp files, which made
> installation
> > much faster. They were removed a few years ago
>
> I don't think that's the case, compiled .elc files are still in the
> latest tarball releases. They're not version controlled, so people
> tracking development with git do have to compile the Lisp files.
I think Richard meant that in the past we kept *.elc files in the repository.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#36681
; Package
emacs
.
(Wed, 17 Jul 2019 07:21:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#36681
; Package
emacs
.
(Wed, 17 Jul 2019 22:29:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 36681 <at> debbugs.gnu.org (full text, mbox):
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> > We used to distribute the compiled Lisp files, which made installation
> > much faster. They were removed a few years ago
> I don't think that's the case, compiled .elc files are still in the
> latest tarball releases.
Didn't the Savannah repository also contain the compiled .elc files,
before?
However, if nost users who build Emacs from sources get them from
the tarball, having the .elc files in the tarball does most of the good.
--
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#36681
; Package
emacs
.
(Wed, 17 Jul 2019 23:07:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 36681 <at> debbugs.gnu.org (full text, mbox):
Noam Postavsky wrote:
> I wouldn't be sure that skipping elc building entirely would be a win,
> since some of the build requires running the Emacs, and an Emacs using
> .el files instead of .elc files would be slower.
IMO That's one reason why:
make -C src all # "all" seems better than "emacs" these days
is a better solution. It compiles the required elc files but no more.
It also avoids the makeinfo step, which can be slow.
I'm marking this as wontfix.
Added tag(s) wontfix.
Request was from
Glenn Morris <rgm <at> gnu.org>
to
control <at> debbugs.gnu.org
.
(Wed, 17 Jul 2019 23:07:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#36681
; Package
emacs
.
(Wed, 17 Jul 2019 23:19:01 GMT)
Full text and
rfc822 format available.
Message #40 received at 36681 <at> debbugs.gnu.org (full text, mbox):
Richard Stallman wrote:
> Didn't the Savannah repository also contain the compiled .elc files,
> before?
Certainly not within the past "few years", nor the past 10.
There was once a "lisp-elc.tgz" file, but it was removed 17 years ago.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#36681
; Package
emacs
.
(Wed, 17 Jul 2019 23:23:02 GMT)
Full text and
rfc822 format available.
Message #43 received at 36681 <at> debbugs.gnu.org (full text, mbox):
Glenn Morris wrote:
> Richard Stallman wrote:
>
>> Didn't the Savannah repository also contain the compiled .elc files,
>> before?
>
> Certainly not within the past "few years", nor the past 10.
> There was once a "lisp-elc.tgz" file, but it was removed 17 years ago.
PS such issues are better solved by making snapshots available.
Eg https://hydra.nixos.org/jobset/gnu/emacs-trunk/latest-eval
Choose "tarball" job and download source distribution.
Reply sent
to
Stefan Kangas <stefan <at> marxist.se>
:
You have taken responsibility.
(Fri, 13 Sep 2019 12:09:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Keith David Bershatsky <esq <at> lawlist.com>
:
bug acknowledged by developer.
(Fri, 13 Sep 2019 12:09:02 GMT)
Full text and
rfc822 format available.
Message #48 received at 36681-done <at> debbugs.gnu.org (full text, mbox):
Glenn Morris <rgm <at> gnu.org> writes:
> I'm marking this as wontfix.
Two months later, I'm now also closing this bug report.
Best regards,
Stefan Kangas
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sat, 12 Oct 2019 11:24:06 GMT)
Full text and
rfc822 format available.
This bug report was last modified 4 years and 170 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.