> > > 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.