On Thu, Jul 10, 2025, 12:50 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Spencer Baugh <sbaugh@janestreet.com>
> > Date: Wed, 9 Jul 2025 13:43:11 -0400
> > Cc: acorallo@gnu.org, 78783@debbugs.gnu.org, app-emacs-dev@janestreet.co
> <app-emacs-dev@janestreet.com>m

> > > The strict testing done by comp-el-to-eln-rel-filename is deliberately
> > > > weakened for files under PATH_REL_LOADSEARCH or PATH_DUMPLOADSEARCH:
> > > > part of the filename is ignored and not checked.  I am simply
> > > > suggesting that we should do the same exact thing for files under
> > > > PATH_SITELOADSEARCH.
> > >
> > > I don't see the need.  The Emacs build doesn't compile any files
> > > inside directories on that path, so there's no reason for the upstream
> > > project to complicate the code on behalf of situations that don't
> > > happen when Emacs is built.  There should be no problem for you to do
> > > it with your local arrangements.
> >
> > What local arrangement are you suggesting?
>
> I don't know!  You haven't explained the rationale for the urge to
> AOT-compile the files in site-lisp,

To save compute and storage space on the user's machines by avoiding them
needing to native compile thousands of files every time the Emacs binary
changes.

nor even why they need to be in
> site-lisp (and not in your Emacs tree, where you build) in the first
> place.


No reason.  They can move to the Emacs tree instead of site-lisp if that's
the correct place to put hundreds of ELPA packages that are bundled with
Emacs at my site.  I'll do that if that's what you suggest.

  You haven't explained why you cannot natively-compile the
> files after the build is complete, directing the *.eln files to some
> shared directory, and package those *.eln files together with the rest
> of the built Emacs.


Because the native compilation doesn't just need to happen after the build
is complete, but also after Emacs is installed, because
comp-el-to-eln-rel-filename refuses to use native compilation artifacts
that were produced before Emacs was installed, because of its strict
filename checking.  Except that it has a special exception for .el files
shipped with Emacs, which could be extended to site-lisp.

And you haven't explained many other aspects.
> Which you don't need to do if you implement your own local solution
> for your local problem, but without which you cannot expect us to
> suggest the solution of the problem for you.
>
> My point is that I don't see a need for the Emacs upstream project to
> support AOT native compilation of site-lisp files, because files in
> site-lisp are by definition the responsibility of a site.  The Emacs
> project is not obliged to accommodate every single quirk of every
> downstream distribution.  We provide the tools and the source code for
> you to use and change as you see fit, and I see several possible
> avenues of approach for this issue that you could have taken for
> solving your problem locally.  But for some reason, you reject all the
> proposals, and insist on having something in upstream Emacs.
>
> > I can indeed locally patch comp-el-to-eln-rel-filename to ignore
> > part of the filename for files under PATH_SITELOADSEARCH, and that's
> > my current plan, if you think this is reasonable.
>
> I don't think it's reasonable, but it's your distribution and your
> users you are putting at risk.
>

Why isn't it reasonable?  Andrea has previously commented in other bugs
that the file name check is not very important in the first place; it's not
about correctness, it's just a convenience for avoiding conflicts during
parallel compilation.  Honestly the file name check could probably be
removed entirely, as it has already been weakened in other bugs.

>