emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs 27.1 Windows Binaries -- testing wanted


From: Eli Zaretskii
Subject: Re: Emacs 27.1 Windows Binaries -- testing wanted
Date: Sat, 22 Aug 2020 14:15:56 +0300

> Date: Sat, 22 Aug 2020 11:53:54 +0100
> From: phillip.lord@russet.org.uk
> Cc: emacs-devel@gnu.org
> 
> On 2020-08-22 11:40, Eli Zaretskii wrote:
> >> Date: Sat, 22 Aug 2020 11:21:27 +0100
> >> From: phillip.lord@russet.org.uk
> >> Cc: emacs-devel@gnu.org
> >> 
> >> > The correct answers can be found by comparing against
> >> > system-configuration-features, I think.
> >> >
> >> > And you have the same problem with your ERT-based approach, no?
> >> 
> >> 
> >> No, because the correct answers are hardcoded into the file.
> > 
> > I'm confused: how can you know the correct answers in advance in one
> > case, but not in the other?
> 
> I think we are talking cross purposes.

Maybe so, but please bear with me, okay?

> I do not want to display all the output, I want to know what it
> should be. And I don't care about the output from things that work
> as expected only things that do not. All of this is what ert is
> designed for. I might like to tweak the output a little, but as ert
> doesn't have a pluggable interface, that's harder.

I'm not talking about using ert or not, I'm talking about determining
which of the features should check out and which shouldn't.  Are you
going to edit w32-features.el by hand each time you add or remove an
optional library from the build?  Or will the list of the features
which should check out be constructed automagically somehow?  If the
latter, I didn't see you describe how will that happen.  If the
former, it means a file in the distribution will depend on the details
of how you build the official binaries, which could be different from
what end-users do on their systems (those who build their own Emacs),
so the tests will fail for them, AFAIU.  It might also mean problems
in merging from the release branch to master, e.g. if we remove some
optional library from master that is still being used on the release
branch.

I guess what I'm saying is that I don't yet see the overall picture of
how this is supposed to work.  Apologies if I'm missing something.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]