emacs-devel
[Top][All Lists]
Advanced

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

Re: Preview: portable dumper


From: Daniel Colascione
Subject: Re: Preview: portable dumper
Date: Thu, 15 Feb 2018 15:34:13 -0800

On Feb 15, 2018 2:46 PM, Alan Third <address@hidden> wrote:

On Thu, Feb 15, 2018 at 02:02:03PM -0800, Daniel Colascione wrote:
> All fixed, I think.

Thanks. I’m still seeing this:

macfont.m:4057:34: error: use of undeclared identifier
      'syms_of_macfont_for_pdumper'
  pdumper_do_now_and_after_load (syms_of_macfont_for_pdumper);

I moved syms_of_macfont_for_pdumper to before syms_of_macfont to fix
it.

> > @@ -1646,7 +1646,7 @@ static int macfont_variation_glyphs (struct font *, int c,
> >                                        unsigned variations[256]);
> >   static void macfont_filter_properties (Lisp_Object, Lisp_Object);
> > -static struct font_driver const macfont_driver =
> > +static struct font_driver macfont_driver =
> >     {
> >     .type = LISPSYM_INITIALLY (Qmac_ct),
> >     .get_cache = macfont_get_cache,
> > @@ -4034,6 +4034,18 @@ So we use CTFontDescriptorCreateMatchingFontDescriptor (no
>
> Why did you have to remove the const?

macfont.m:4045:23: error: cannot assign to variable 'macfont_driver' with
      const-qualified type 'const struct font_driver'
  macfont_driver.type = Qmac_ct;
  ~~~~~~~~~~~~~~~~~~~ ^
macfont.m:1649:33: note: variable 'macfont_driver' declared const here
static struct font_driver const macfont_driver =
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~

I think we’ll also have to copy the pdmp file into Emacs.app on
install, but I don’t know enough about how that works to do it just
now.
--


Thanks.

I do wonder whether it makes sense to try to copy the dump into the Emacs executable itself instead of leaving it as a separate file. We could do it independently of executable format by defining a data array in static storage that's initially full of, say, 15MB of zeroes prefixed by a long random header (like a MIME boundary), then, after we generate emacs.pdmp, copying the dump file into the executable at the place where we see that random header. If the dump turns out to be bigger than that 15MB, we can fail the build and ask the user to enlarge the array.

I don't know of any executable format for which this scheme would fail.

This way, we could get rid of the current complicated dump-file location logic early in Emacs init.



reply via email to

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