GNU bug report logs - #30106
Loading file /sources/emacs/lisp/emacs-lisp/ert.elc failed to provide feature `mod-test'

Previous Next

Full log

Message #106 received at 30106 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: phst <at> google.com, 30106 <at> debbugs.gnu.org
Subject: Re: bug#30106: [PATCH 2/2] Fix module support if threads are disabled
 (Bug#30106)
Date: Thu, 18 Jan 2018 17:23:29 +0200

> From: Philipp Stephani <p.stephani2 <at> gmail.com>
> Date: Thu, 18 Jan 2018 14:23:03 +0000
> Cc: phst <at> google.com, 30106 <at> debbugs.gnu.org
> 
>  I'd prefer that the only file that calls systhread.c functions is
>  thread.c; systhread.c is supposed to be low-level code concealed from
>  application levels.  So this would call for another level of
>  indirection: add a new function to thread.c, and call that from
>  emacs-module.c.
> 
> Makes sense, I've moved in_current_thread to thread.c because it's unrelated to modules.

Thanks.

>  Otherwise, LGTM for master; thanks.
> 
> Can we push this to emacs-26? Right now emacs-26 can't even be compiled with --without-threads
> --with-modules (on some systems at least). 

How important is this?  --with-modules is an opt-in switch, and the
default is to build with threads.  So this sounds not very important
to me, and the change, although simple, is not really trivial, and
will affect any module.  So I'm uneasy putting this on emacs-26,
especially since the Emacs 26.0.91 tarball is already ready and is
awaiting upload, so this will only go into the next pretest, which I
hoped could be a release candidate...

Do you think leaving this for the next release will be so bad?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.