[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: Fri, 24 Nov 2017 23:27:12 +0000

On Fri, Nov 24, 2017 at 6:20 PM, Paul Eggert <address@hidden> wrote:
> Pip Cet wrote:
>> The most vexing issue for me right now is that I haven't figured out
>> how to get gnulib working with g++ without modifying files after every
>> sh autogen.sh, though. I admit I don't understand the gnulib build
>> process at all, so any hints would be appreciated.
> Emacs has a special way of using Gnulib, unfortunately. I wrote the Gnulib
> interface (sorry! :-) and so can perhaps be of help here. What sort of
> modifications are needed after autogen.sh? Perhaps we can lessen and/or
> eliminate the need for them.

I have to remove the memrchr prototype. 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?

>> The other issues are minor (a union and a typedef sharing a name, C++
>> keywords, enums treated as ints),
> If you would submit patches to fix these, that might help you in future
> merges.
> Of the three, enums treated as ints seems like it'd be the most
> hassle, as enums are the only way that C has to name small ints that can be
> used where an integer constant expression can be used. I'd hate to have to
> cast these names to int every time I used them, just to pacify C++. Perhaps
> the enum-to-int business could be handled by the C-to-C++ translator
> instead.

So let's do the first and maybe the keywords, but leave the enums in.

reply via email to

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