unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
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.



  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).