From: Stefan Kangas <stefankangas@gmail.com>
To: "Pip Cet" <pipcet@protonmail.com>,
"Gerd Möllmann" <gerd.moellmann@gmail.com>
Cc: Gerd Moellmann <gerd@gnu.org>, Andrea Corallo <acorallo@gnu.org>,
Eli Zaretskii <eliz@gnu.org>,
75451-done@debbugs.gnu.org
Subject: bug#75451: scratch/igc: Enable CHECK_STRUCTS
Date: Thu, 9 Jan 2025 06:44:47 -0600 [thread overview]
Message-ID: <CADwFkm=EaCgrvrFh2rnJBpouWLSZX_Zmvmy7eCeaXOmbefLPaA@mail.gmail.com> (raw)
In-Reply-To: <87frls47uu.fsf@protonmail.com>
Pip Cet <pipcet@protonmail.com> writes:
> This isn't strictly about the scratch/igc branch, but I personally think
> struct hashes should be checked in all builds, mismatches should be
> downgraded to #warnings, and --enable-checking=all could include
> -Werror=cpp. (So the warnings would still abort a build with
> --enable-checking=all, but they'd *also* show up in regular builds.)
Sounds good to me.
> Also, we should include them in the nativecomp ABI hash, as nativecomp
> relies on struct layout and the tagging scheme in nontrivial ways
> (most-positive-fixnum, for example, is treated as a compile-time
> constant by comp.el, but I'm not sure all changes to it would
> automatically affect the comp abi hash).
I'm copying in Andrea for this part.
> Changes required might include:
>
> * autodetection of gawk vs awk (I think this simply means using $(AWK)
> rather than "awk" in src/Makefile.in; this is important on some
> machines which provide a very different "awk")
Using $(AWK) instead of raw "awk" makes sense, because why not.
But which awk implementations are you concerned about more specifically?
I would expect us to just use POSIX awk, without any gawk extensions.
For example, I have had no issues building on Debian (using mawk by
default) or macOS (with the BSD awk that descends from nawk, IIUC).
> * igc.o and comp.o should depend explicitly on dmpstruct.h (this is
> important for re-builds; in theory, the current scratch/igc branch is
> broken for highly parallel builds because dmpstruct.h might be
> generated after igc.o, but that is not important).
Sounds good also.
> * a hash-of-hashes for nativecomp
>
> Proposed partial patch:
(I didn't look at the patch yet, though the above sounds like it might
come out to more than one patch.)
prev parent reply other threads:[~2025-01-09 12:44 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-09 3:57 bug#75451: scratch/igc: Enable CHECK_STRUCTS Stefan Kangas
2025-01-09 5:09 ` Gerd Möllmann
2025-01-09 7:20 ` Stefan Kangas
2025-01-09 7:25 ` Gerd Möllmann
2025-01-09 10:09 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-09 12:44 ` Stefan Kangas [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CADwFkm=EaCgrvrFh2rnJBpouWLSZX_Zmvmy7eCeaXOmbefLPaA@mail.gmail.com' \
--to=stefankangas@gmail.com \
--cc=75451-done@debbugs.gnu.org \
--cc=acorallo@gnu.org \
--cc=eliz@gnu.org \
--cc=gerd.moellmann@gmail.com \
--cc=gerd@gnu.org \
--cc=pipcet@protonmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.