From: Eli Zaretskii <eliz@gnu.org>
To: Philipp Stephani <p.stephani2@gmail.com>
Cc: phst@google.com, emacs-devel@gnu.org
Subject: Re: [PATCH] Unbreak build when building without GMP support.
Date: Wed, 24 Apr 2019 22:30:31 +0300 [thread overview]
Message-ID: <83o94v19rc.fsf@gnu.org> (raw)
In-Reply-To: <CAArVCkTeXhV6P3GLRK2RtZmd8psXE6Ke4hTyreUSBeyX7jGBjA@mail.gmail.com> (message from Philipp Stephani on Wed, 24 Apr 2019 21:19:54 +0200)
> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Wed, 24 Apr 2019 21:19:54 +0200
> Cc: Emacs developers <emacs-devel@gnu.org>, Philipp Stephani <phst@google.com>
>
> Am Mi., 24. Apr. 2019 um 21:06 Uhr schrieb Eli Zaretskii <eliz@gnu.org>:
> >
> > > From: Philipp Stephani <p.stephani2@gmail.com>
> > > Date: Wed, 24 Apr 2019 20:49:34 +0200
> > > Cc: Emacs developers <emacs-devel@gnu.org>, Philipp Stephani <phst@google.com>
> > >
> > > > Btw, why are we including emacs-module.h in lisp.h? IME, this usually
> > > > causes trouble, so it is best to avoid that.
> > >
> > > lisp.h needs types from emacs-module.h to define Lisp_Module_Function.
> >
> > A single data type? I'd rather move XMODULE_FUNCTION to
> > emacs-module.c, and the data type definition and all the other related
> > stuff to emacs-module.h. It isn't worth the hassle.
>
> We shouldn't move anything to emacs-module.h because it's a public
> header, to be used outside of Emacs.
Then keep them in lisp.h, but make them self-sufficient. Which types
does Lisp_Module_Function need that are defined by emacs-module.h?
> What hassle are you talking about? There is no hassle. We have been
> including emacs-module.h in lisp.h for years, and there was never any
> problem.
I had one just today. And the patch you are now proposing includes a
time bomb: files that include lisp.h will have emacs-module.h with a
different definition of emacs_mpz than those which include
emacs-module.h directly, depending on whether they do or don't define
EMACS_MODULE_GMP etc. It's confusing and error prone. The only other
header lisp.h includes, thread.h, was also a source of many
compilation problems, and will be again if we change the thread
machinery.
next prev parent reply other threads:[~2019-04-24 19:30 UTC|newest]
Thread overview: 87+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-23 13:17 [PATCH 1/2] Add conversions to and from struct timespec to module interface Philipp Stephani
2019-04-23 13:17 ` [PATCH 2/2] Add module functions to convert from and to big integers Philipp Stephani
2019-04-23 14:30 ` Eli Zaretskii
2019-04-23 14:51 ` Paul Eggert
2019-04-23 15:12 ` Philipp Stephani
2019-04-23 15:48 ` Paul Eggert
2019-04-23 15:54 ` Philipp Stephani
2019-11-02 19:17 ` Philipp Stephani
2019-11-03 19:38 ` Stefan Monnier
2019-11-13 18:46 ` Philipp Stephani
2019-11-17 18:38 ` [PATCH] Change module interface to no longer use GMP objects directly Philipp Stephani
2019-11-18 21:21 ` Paul Eggert
2019-11-19 21:12 ` Philipp Stephani
2019-11-19 21:54 ` Paul Eggert
2019-11-20 21:06 ` Philipp Stephani
2019-11-20 21:24 ` Paul Eggert
2019-11-20 21:30 ` Philipp Stephani
2019-11-21 1:12 ` Paul Eggert
2019-11-21 20:31 ` Philipp Stephani
2019-11-23 2:13 ` Paul Eggert
2019-11-23 20:08 ` Philipp Stephani
2019-11-23 23:10 ` Paul Eggert
2019-11-23 20:46 ` Stefan Monnier
2019-11-23 23:10 ` Paul Eggert
2019-11-24 9:28 ` Andreas Schwab
2019-11-25 21:03 ` Paul Eggert
2019-11-25 21:59 ` Philipp Stephani
2019-12-04 20:31 ` Philipp Stephani
2019-12-05 14:43 ` Eli Zaretskii
2019-12-08 20:28 ` Philipp Stephani
2019-12-09 3:26 ` Eli Zaretskii
2019-12-09 4:58 ` Paul Eggert
2019-12-09 13:22 ` Eli Zaretskii
2019-12-09 23:15 ` Philipp Stephani
2019-12-10 0:22 ` Paul Eggert
2019-12-10 13:15 ` Philipp Stephani
2019-12-10 15:57 ` Eli Zaretskii
2019-12-14 16:06 ` Philipp Stephani
2019-12-14 19:54 ` Paul Eggert
2019-12-09 0:35 ` Paul Eggert
2019-12-09 13:19 ` Eli Zaretskii
2019-04-23 15:16 ` [PATCH 1/2] Add conversions to and from struct timespec to module interface Paul Eggert
2019-04-23 21:32 ` Philipp Stephani
2019-04-24 7:21 ` Eli Zaretskii
2019-04-24 11:03 ` Philipp Stephani
2019-04-24 11:44 ` Eli Zaretskii
[not found] ` <20190423213218.35618-2-phst@google.com>
2019-04-23 21:43 ` [PATCH 2/2] Add module functions to convert from and to big integers Paul Eggert
2019-04-24 16:03 ` Eli Zaretskii
2019-04-24 16:37 ` Philipp Stephani
2019-04-24 16:51 ` Eli Zaretskii
2019-04-24 16:57 ` Philipp Stephani
2019-04-24 17:11 ` Eli Zaretskii
2019-04-24 17:15 ` Philipp Stephani
2019-04-24 17:23 ` Eli Zaretskii
2019-04-24 17:28 ` Philipp Stephani
2019-04-24 17:51 ` [PATCH] Unbreak build when building without GMP support Philipp Stephani
2019-04-24 18:41 ` Eli Zaretskii
2019-04-24 18:49 ` Philipp Stephani
2019-04-24 19:06 ` Eli Zaretskii
2019-04-24 19:19 ` Philipp Stephani
2019-04-24 19:30 ` Eli Zaretskii [this message]
2019-04-24 21:15 ` Philipp Stephani
2019-04-25 6:04 ` Eli Zaretskii
2019-04-25 6:39 ` Eli Zaretskii
2019-04-25 10:24 ` Philipp Stephani
2019-04-24 21:34 ` Philipp Stephani
2019-04-24 19:44 ` [PATCH 2/2] Add module functions to convert from and to big integers Stefan Monnier
2019-04-24 20:15 ` Paul Eggert
2019-04-24 20:57 ` Stefan Monnier
2019-04-24 21:17 ` Philipp Stephani
2019-04-24 23:32 ` Paul Eggert
2019-04-24 21:19 ` Philipp Stephani
2019-04-25 0:00 ` Paul Eggert
2019-04-25 5:33 ` Eli Zaretskii
2019-04-25 10:41 ` Philipp Stephani
2019-04-25 13:46 ` [PATCH 1/2] Require full GMP when building module support Philipp Stephani
2019-04-25 13:46 ` [PATCH 2/2] Check for __attribute__ ((cleanup)) during configuration Philipp Stephani
2019-04-25 21:18 ` Paul Eggert
2019-04-28 18:12 ` Philipp Stephani
2019-04-25 14:37 ` [PATCH 1/2] Require full GMP when building module support Eli Zaretskii
2019-04-25 15:06 ` Philipp Stephani
2019-04-25 16:14 ` Eli Zaretskii
2019-04-25 17:09 ` [PATCH] Require full GMP for big integer module functions Philipp Stephani
2019-04-25 21:00 ` Paul Eggert
2019-04-28 18:14 ` Philipp Stephani
2019-04-28 20:18 ` Paul Eggert
2019-04-28 17:10 ` [PATCH 1/2] Require full GMP when building module support Philipp Stephani
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=83o94v19rc.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=p.stephani2@gmail.com \
--cc=phst@google.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.
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).