bug#58318: 28.2; Emacs installed from package won't work with MinGW

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: corwin@bru.st,  akrl@sdf.org,  bartosz.bubak@gmail.com,
>   58318@debbugs.gnu.org
> Date: Sat, 08 Oct 2022 15:10:05 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> That leaves the question of what we should do with the Windows zip file
> >> we (that is, Corwin) distributes, and I think we should avoid enabling
> >> nativecomp in that build, so that it works on the widest range of
> >> Windows machines.
> >
> > The Windows build with nativecomp is supposed to be fully workable on
> > systems that don't have libgccjit, even if the libgccjit bundled with
> > the zip file is not installed or deleted.  If there are issues with
> > that, they should be fixed, because we want to allow users to move
> > Emacs from system top system without the optional libraries, and have
> > a functional Emacs, like is already the case with image libraries.
> 
> And my suggestion for achieving that is to not enable nativecomp in
> this build.

I don't agree.

> Adding extra these extra mechanisms for Windows builds only seems to be
> against the general GNU guidelines for non-free systems (as well as
> adding an extra maintenance burden to an already complicated area,
> because the code that finds and uses the extra pre-built trampolines
> will have to be in the general comp.el code).

The general mechanism already exists, and for a long time.  We are
just using it.  Adding an optional library is boilerplate and quite
easy.  It's basically a non-issue.

As for the specific issue of trampolines, I understand that compiling
them is a simple command, and so also a non-issue.