bug#66554: [PATCH] Add the public API of Compat to the core

[Philip Kaludercic]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: Daniel Mendler <mail@daniel-mendler.de>,  66554@debbugs.gnu.org,
>>   eliz@gnu.org,  Stefan Kangas <stefankangas@gmail.com>
>> Date: Thu, 11 Jan 2024 20:24:25 +0000
>> 
>> > The addition cab done procedurally, as in
>> >
>> >     ;;;;####autoload (push (list 'compat emacs-major-version
>> > emacs-minor-version) package--builtin-versions)
>> 
>> If this work, I like this idea a lot!  I'll test it out to see if this
>> could simplify things.
>
> I'm not sure I understand the effects of the above -- can you explain?

The idea is to manually register the file as a package while scraping
for autoloads, thereby setting the version of the built-in Compat
package to whatever the current version of Emacs is.  My patch adds a
`most-positive-fixnum' to the version number to ensure that the built-in
compat is always (or at least for a more than reasonably long while)
preferred over an external dependency.

The consequence is that we don't have to update any files, and I would
assume we don't have to document anything in make-tarball.txt, because
nothing has to be done when bumping the version of Emacs itself.

> In general, if something needs to be done when the Emacs version is
> bumped, that action should be described in make-tarball.txt.  It is a
> nuisance to follow the procedure there, only to be reminded of
> something else via a warning emitted by the build (and that is even
> before we consider the possibility that someone launches a build and
> goes for a coffee, while the warnings scroll on the screen with no one
> to see them).  Likewise, if a file is modified by whatever commands we
> invoke to bump an Emacs version, that file should be mentioned in
> make-tarball.txt, because the person who performs that procedure will
> then need to commit the changes with a suitable log message, like we
> do today with configure.ac and the rest.