Re: Suppressing native compilation (short and long term)

[Rob Browning <rlb@defaultvalue.org>]

Michael Welsh Duggan <mwd@md5i.com> writes:

> 1) When building emacs (used as part of emacs bootstrap) 
> 2) When installing emacs via dpkg (maybe?  Not certain)
> 3) When building an emacs package (maybe?  Not certain)
> 4) When installing an emacs package via dpkg
> 5) When a user runs emacs

> 1) When building emacs (used as part of emacs bootstrap) 

"building the emacs package", which we do from an upstream tree usually
pretty close to the upstream tag, plus a varying number of patches.
Then it's mostly configure, make check, make DESTDIR=... install to
build the tree(s) that are packaged.

> 2) When installing emacs via dpkg (maybe?  Not certain)

Yes, "apt install emacs".  But that also includes upgrades.  The upgrade
and install scripts run as root, and should not affect HOME in most, if
not all, cases.

And note that both install and upgrade will run emacs a bazillion times
to rebuild all of the system-level .elc files for all of the installed
emacs "add-on" packages in dependency order.

> 3) When building an emacs package (maybe?  Not certain)

Yes, and that will likely run the installed /usr/bin/emacs any number of
times, in unpredictable ways, including via any test harnesses/processes
the package might have.

> 4) When installing an emacs package via dpkg

Yes, "apt install elpa-magit", which also includes upgrades, and will
invoke emacs to rebuild all of the elc files for the add-on.

> 5) When a user runs emacs

Yes, but in this case, 

> g) Case 4 might run emacs to build .elc and .eln files for the package's
>    .el files and place them in world-readable, read-only locations.  An
>    Emacs run in case 5 will include that location in its native file
>    search path.

Yes, if we proceed with ELN compilation (and don't also decide to start
packaging the .elc and .eln files too, rather than building them
on-demand -- which may be up for discussion, but would only be viable if
the emacs fingerprint only changed very deliberatlely).

> Open questions:
>
> i  ) In case 2, are the emacs binaries and the elisp files in the same
>      package, or are they split into different packages?  If the latter,
>      which package should contain the .eln files?

Currently, the elisp files are in a separate emacs-el package because
they used to be optional.  It sounds like they can't be anymore, so
emacs-common now depends on emacs-el, and everything else depends on
emacs-common.

I'd assume that the .eln files would go in the arch-dependent
emacs-bin-common package where other things like ctags, browse, etc. go.

Summary seems pretty accurate, overall.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4