From: Nicolas Martyanoff <nicolas@n16f.net>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: Dynamic module building and reloading
Date: Tue, 13 Jun 2023 19:10:25 +0200 [thread overview]
Message-ID: <2E2FE4DB-0DBC-47F5-B0BB-6D8010826159@n16f.net> (raw)
In-Reply-To: <834jnbwbcb.fsf@gnu.org>
Got it, thank you for responding this quickly.
Are there technical limitations against reloading or is this just a case of “if you need it send a patch”? I know that some platforms may have issues with it; but I use foreign library reloading in Common Lisp on Linux all the time, and it also works en BSD.
Nicolas Martyanoff
https://www.n16f.net
nicolas@n16f.net
> On 13 Jun 2023, at 18:55, Eli Zaretskii <eliz@gnu.org> wrote:
>
>
>>
>> From: Nicolas Martyanoff <nicolas@n16f.net>
>> Date: Tue, 13 Jun 2023 18:11:47 +0200
>>
>> 1. There does not seem to be any builtin utilities to deal with
>> the process of building and loading shared library. I ended up writing a
>> couple elisp functions to find the location of the C file, spawn cc,
>> load the shared library… Is this the expected method? In this state, it
>> would seem that every Emacs packages using dynamic modules has to write
>> its own build/load code.
>
> The expected method of building a shared library is the same as you'd
> use for building any other shared library out there. The Emacs
> modules aren't special in any way, and the details of their build
> procedures depend on what code you are compiling in, which other
> libraries you need to link against, etc. There's no way an Emacs
> command could cover all that. However, if you write a Makefile to
> compile and link the module, you can use "M-x compile" to run the Make
> utility to build your module.
>
>> 2. It seems that once a dynamic module has been loaded, it cannot be
>> reloaded after the shared library has been rebuilt. A Google search
>> seems to confirm it. Is there a workaround? If I pursue my little
>> project, I'll have to write quite a lot of C code in the dynamic module;
>> I *really* do not want to restart Emacs to test every single
>> modification.
>
> We don't have a facility to unload a module, no. The usual way of
> testing your development code is to start a new scratch session (in
> addition to your production Emacs session) each time you recompile a
> module.
next prev parent reply other threads:[~2023-06-13 17:10 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-13 16:11 Dynamic module building and reloading Nicolas Martyanoff
2023-06-13 16:55 ` Eli Zaretskii
2023-06-13 17:10 ` Nicolas Martyanoff [this message]
2023-06-13 17:26 ` chad
2023-06-13 18:12 ` Eli Zaretskii
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2E2FE4DB-0DBC-47F5-B0BB-6D8010826159@n16f.net \
--to=nicolas@n16f.net \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
/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.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
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).