bug#41242: Port feature/native-comp to Windows

[Nicolas Bértolo]

> I'm not sure I understand what check did you have in mind.

I misunderstood your first message. I thought you were talking about deleting
the .eln file when it no longer is up to date after the .el file changes.

If we want that we will have to add it to `auto-compile.el`.

El sáb., 16 may. 2020 a las 13:42, Eli Zaretskii (<eliz@gnu.org>) escribió:

> From: Nicolas Bértolo <nicolasbertolo@gmail.com>
> Date: Sat, 16 May 2020 13:31:41 -0300
> Cc: Andrea Corallo <akrl@sdf.org>, 41242@debbugs.gnu.org
>
> > No, on Posix systems we can delete the file, and it will be actually
> > deleted when its last handle is closed.  I believe this works with
> > shared libraries as well.
>
> Do we actually do it? I don't think so. I don't even know where exactly
> that check should be. Maybe `eval-buffer`?

I'm not sure I understand what check did you have in mind.

> > It's the same problem, yes.  Just a slightly different use case, which
> > could therefore have different probabilities for some aspects.  For
> > example, the probability of the same .el file being recompiled from
> > two separate sessions is relatively small, except when you consider
> > the "make -jN" use case.
>
> The probability of two Emacs recompiling the same file in the "make -jN" case is
> 0.

Sorry, I meant the probability of one session compiling a file while
another uses it.

> The case of two Emacs sessions recompiling the same file at the same time is
> actually a problem.
>
> We could implement the following algorithm:
>
> - Have libgccjit write the .eln to a temporary name in the destination folder.
>
> - While "foo.eln" exists:
>   - Rename it to "foo.eln.oldN".
>   - Move the new .eln file to "foo.eln"

Something like that, yes.