From: Ken Brown <kbrown@cornell.edu>
To: cygwin-apps@cygwin.com
Subject: Re: autorebase and user-installed dynamic objects
Date: Sun, 19 Sep 2021 13:25:56 -0400 [thread overview]
Message-ID: <78fa0420-3626-d6bc-ec37-eb451a0c6e2a@cornell.edu> (raw)
In-Reply-To: <87r1dkbjv3.fsf@Rainer.invalid>
On 9/19/2021 12:39 PM, Achim Gratz wrote:
> Ken Brown via Cygwin-apps writes:
>> A per-user database sounds like a good idea.
>
> Well, the problem is how to maintain it. So let's for the moment skip
> that part and see if it would work when we pretend we'd already solved
> that problem. An ephemeral rebase is essentially a user-defined
> database that gets thrown away immediately, so you can not re-use its
> information. We would need to replace emacs with a wrapper script that
> checks a cookie file against the system wide rebase database and if the
> latter is newer, trigger an ephemeral rebase of the emacs user
> directory. The same should be done for each compilation. If that
> works, then we can try to figure out how to not constantly rebase stuff
> that doesn't need to get rebased again via some sort of user rebase
> database.
I'm not sure the rebase of the emacs user directory has to be ephemeral. First
of all, I think we should make /var/lib/rebase/user.d/<username> work as
documented. Users could list their emacs user directory there, and people who
build emacs themselves could also list their emacs build directory. That way
things could be kept reasonably stable in the long run via the autorebase
postinstall script. Implicit in this is that the results of all these rebases
would be stored in the user's rebase database.
After each compilation, but before the new .eln file is loaded, emacs could call
rebaselst with suitable arguments to rebase that new file (and add it to the
user database).
Ken
next prev parent reply other threads:[~2021-09-19 17:25 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4f799e88-40cd-2cdc-6d40-0285e66f5be0@cornell.edu>
[not found] ` <87o88pf5q1.fsf@Otto.invalid>
2021-09-19 12:37 ` Ken Brown
2021-09-19 16:39 ` Achim Gratz
2021-09-19 17:25 ` Ken Brown [this message]
2021-09-19 19:09 ` Achim Gratz
2021-09-19 22:24 ` Ken Brown
2021-09-20 5:58 ` ASSI
2021-09-20 12:57 ` Ken Brown
2021-09-22 21:21 ` Ken Brown
2021-09-23 17:34 ` Achim Gratz
2021-09-25 13:26 ` Achim Gratz
2021-09-25 15:37 ` Ken Brown
2021-09-25 15:45 ` Achim Gratz
2021-09-25 16:54 ` Ken Brown
2021-09-26 8:07 ` Achim Gratz
2021-09-26 23:17 ` Ken Brown
2021-09-27 6:43 ` ASSI
2021-09-27 12:48 ` Ken Brown
2021-09-27 13:21 ` ASSI
2021-09-27 21:48 ` Ken Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=78fa0420-3626-d6bc-ec37-eb451a0c6e2a@cornell.edu \
--to=kbrown@cornell.edu \
--cc=cygwin-apps@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).