Re: Finding the dump

[Eli Zaretskii]

> Cc: address@hidden, address@hidden, address@hidden,
>  address@hidden
> From: Paul Eggert <address@hidden>
> Date: Sun, 27 Jan 2019 20:13:11 -0800
> 
> > I very much doubt that you could do that portably, let alone allow
> > repeated dumping after the initial one.
> 
> For repeated dumping without a C compiler present, we'd need to stick to 
> something like the current approach. But hardly anybody needs repeated 
> dumping, 
> and those who do typically have a C compiler available, so the approach that 
> I'm 
> thinking of should work for the vast majority of real-world cases.

Like Daniel, I very much disagree that repeated dumping is
unimportant.  I think we want that capability restored very much, and
I think that it will be quite popular.  Having a working compiler as a
prerequisite for that would be a severe limitation.

> > I really don't see why we should waste our energy on making the Emacs
> > package one file less (out of 3000 it already has).
> 
> This particular file is a bigger deal than the rest because Emacs cannot run 
> without it. Emacs can run without all those other 3000 files.

Emacs can run without them, but it is quite limited, so I don't think
we should consider that a significant difference.

> > It certainly isn't a "hassle".
> 
> It's already been a hassle for us, as seen in this thread.

Well, by that measure we have a lot of "hassle" in Emacs already ;-)

> It will be a hassle for installers and maintainers too.

I don't see why.  It's just one more file in libexec, that's all.

> The separate file also slows down startup compared to the approach I
> have in mind.
> 
> But you're the maintainer, so if you are opposed to the idea I'll drop it.

I wouldn't tell you to drop it, certainly not without knowing more
details, but in general I think we should not make any significant
design changes in how the pdumper works, until we (a) stabilize what
we have now (for now, a bug related to pdumper is reported roughly
every other day, so we still have some fallout), and (b) collect some
significant experience with it.  Based on that experience, we might
find good reasons to make some radical changes, but we are not there
yet, and I certainly don't see any serious problems with the current
design at this time, nothing that would justify yet another
significant change in that area.