[Top][All Lists]

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

Re: [EXPERIMENT] Emacs with the SpiderMonkey garbage collector

From: Pip Cet
Subject: Re: [EXPERIMENT] Emacs with the SpiderMonkey garbage collector
Date: Sat, 25 Nov 2017 23:50:07 +0000

On Sat, Nov 25, 2017 at 12:21 AM, Paul Eggert <address@hidden> wrote:
> 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.

I can't really answer that. I suspect the problem is that memrchr is
overloaded in C++, and the other similarly-overloaded functions do not
require gnulib replacements on my system.

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

Thank you! That explanation helps a lot!

reply via email to

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