[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [EXPERIMENT] Emacs with the SpiderMonkey garbage collector

From: Paul Eggert
Subject: Re: [EXPERIMENT] Emacs with the SpiderMonkey garbage collector
Date: Fri, 24 Nov 2017 16:21:41 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0

Pip Cet wrote:

I have to remove the memrchr prototype.

Why just memrchr? I would think that if it has problems, other gnulib functions will have similar problems.

? Editing gnulib.mk seems like
it should help, but for some reason it doesn't; is gnulib.mk
regenerated by autogen.sh, and, if so, how do I change its options?

lib/gnulib.mk is regenerated by 'configure'. You can change how this happens by changing 'configure.ac', which is the source code for 'configure'.

'configure' creates lib/gnulib.mk by using lib/gnulib.mk.in as a template. This template file is created by admin/merge-gnulib, a script that is so obscure and so slow that we put its output into the repository (so most developers don't have to worry about it or run it).

admin/merge-gnulib gets the template text by running ../gnulib/gnulib-tool, which in turn gets the template text from files in ../gnulib/modules/*. Here I'm ssuming the Gnulib source code is in a sibling directory to the Emacs source code.

The other issues are minor (a union and a typedef sharing a name, C++
keywords, enums treated as ints),
So let's do the first and maybe the keywords, but leave the enums in.

Sounds good.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]