Re: CHECK_STRUCTS/dmpstruct.h mechanism is broken.

[Alan Mackenzie <acm@muc.de>]

Hello, Paul.

On Wed, Apr 10, 2019 at 11:05:02 -0700, Paul Eggert wrote:
> On 4/10/19 9:22 AM, Alan Mackenzie wrote:
> > All that was needed to disable it was a single line change to set
> > CHECK_STRUCTS to zero.

> That would also have sufficed, but the code clutter (and slowdown in the
> build due to the computation of hashes which forces that part of the
> build to be sequential) was also annoying. If you really want it we can
> bring back the mechanism (with CHECK_STRUCTS off by default please!),
> though I'd rather not - see below.

According to Daniel (and my experience backs it up), the problems
CHECK_STRUCTS detects happen when merging master into a branch.  I'm not
sure you do such merges much.  But if you are making frequent changes to
the structures guarded by the mechanism, having deleted that mechanism,
you are saving effort for yourself, but imposing extra effort on other
people.

> > it was of use to me recently when it reminded me to
> > amend dump_subr after extending struct subr.
> I didn't observe that in master - presumably this was in some
> experimental branch? In master, dump_subr is currently the same as it
> was when the pdumper was installed.

Naturally.  I don't change basic structures in master without (usually
extensive) discussion on emacs-devel.  The changes were in branch
scratch/accurate-warning-pos.  The hashes were helpful in making these
changes.

> Before making the recent change, I reviewed all the changes made to
> pdumper.c in master, and observed none where the hashes helped and
> several where they hurt. Since the portable dumper was added I have made
> four commits that involved the hashes, and the hashes only got into my
> way and slowed me down.

The hashes do slow us down, yes.  But not really by very much, IMAO.
For example I timed make dmpstruct.h, and it only took 0.16s.  The extra
time taken in a build can't be more than a very small number of seconds.

Having a build aborted by CHECK_STRUCTS, and having manually to change
the hashes in pdumper.c is what takes the time.  But really, how often
are we changing those structures of an evening?

> You made one commit (9c0fa1172fd987a8f23b115145270383a11c12fc) that
> involved the buffer.h hash, and portions of that commit were
> mistakenly pushed in pdumper.c's previous commit so the hashes didn't
> seem to have helped there.

That was actually Eli's commit.

> The only other persons to make hash-related commits to pdumper.c were
> Alan and Stefan, and the hashes didn't help there either.

I think the hashes are a hindrance when developing on master, but a help
on branches (when merging from master).

> As the hashes get in the way of ordinary development (mostly affecting
> me) and don't seem to help in practice, I really want them to go.

I think I would prefer the hashes to stay, but I can see the other side
of the argument, too.

-- 
Alan Mackenzie (Nuremberg, Germany).