all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: phillip.lord@russet.org.uk
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: Emacs 27.1 Windows Binaries -- testing wanted
Date: Sat, 22 Aug 2020 14:53:15 +0100	[thread overview]
Message-ID: <21e339147a2817352781e4abcc342bfb@russet.org.uk> (raw)
In-Reply-To: <83blj2akvl.fsf@gnu.org>

On 2020-08-22 14:08, Eli Zaretskii wrote:
>> Date: Sat, 22 Aug 2020 13:52:22 +0100
>> From: phillip.lord@russet.org.uk
>> Cc: emacs-devel@gnu.org
>> 
>> > 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?
>> 
>> It would be manual. The list of features changes rarely enough that 
>> it's
>> hard to automate this and know that it will work. The automation is as
>> likely to break as a manual system
> 
> I don't understand why it must break, if you base it on
> system-configuration-features, or on some new file, to be generated by
> the build procedure.  Did you consider one of these alternatives?  If
> yes, why did you reject them?

I didn't consider it much. I cannot see how to go from this to something 
I can test. Say, `system-configuration-features` lists "XPM", I cannot 
turn that into something I could test.

I could modify by test something like

(ert-deftest
   (skip-unless (string-match-p "XPM" system-configuration-features))
   (should (image-type-available 'xpm))
)


>> If I think back to the bugs with Emacs binary releases, this would 
>> have
>> stopped only a few: harfbuzz and svg failure in this release. It would
>> not have prevented missing dependencies (I have missed all of 
>> harfbuzz,
>> lcms and libjansson till late in the day), nor the failed optimization
>> or stripping.
> 
> I don't understand this, either.  If the dependencies of HarfBuzz are
> not installed, then the HarfBuzz font backend will not be available,
> and the way I suggested for testing its availability will tell you
> HarfBuzz doesn't work, which is AFAIU what you wanted.  And the same
> with any other DLLs: if their dependencies are not available, they
> will fail to load when the feature test runs, and the test will fail.

It would work if, when harfbuzz was installed w32-features was updated, 
but not if it wasn't. As the harfbuzz merge didn't update build-deps.zh 
which it arguable should have, then why would a test file be updated.


>> > 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.
>> 
>> That is true with all of our tests, I think.
> 
> No, our tests use skip-unless to avoid running tests that need
> features or programs which are unavailable.
> 
>> json parsing is tested by make check and it will not work on msys2
>> if the dependencies are not installed.
> 
> I didn't look into this, but if json testing fails instead of skipping
> all the tests, that's a bug that should be fixed.

I think you are correct about all of these. In either case, the tests 
will not pass!


>> In this case, I am not suggesting adding ert tests to make check,
>> but a manually run test specifically for understanding the features
>> of a binary build. I am guessing anyone running this would be
>> understand what they are doing enough to know why. And I will
>> document the entry function.
> 
> That's not what worries me.  What worries me is the fact that a file
> distributed as part of the Lisp libraries will have its contents
> depend on the last release you personally did, with whatever quirks
> that required from the tests in that file.  It doesn't sound right to
> me.


Not sure I understand this. A lisp library with "w32-" in it's name will 
have behaviour which reflects how the official binaries are supposed to 
behave. If this worries you, as I say, I can add it to `data-directory' 
instead. But, it has to be in the distribution.


>> > 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.
>> 
>> That problem is there anyway in build-deps.py
> 
> But build-deps.py is under admin, whereas you are suggesting to do
> this under lisp/.

Having a test functionality under lisp/ does, I agree, seem morally 
wrong. Likewise `data-directory'. But, the reasons for it are clear, and 
what harm would it cause in practice?


Phil




  reply	other threads:[~2020-08-22 13:53 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-18  2:05 Emacs 27.1 Windows Binaries -- testing wanted Jonathan Mitchell
2020-08-18  4:55 ` Eli Zaretskii
2020-08-18  6:56   ` phillip.lord
2020-08-18  7:11     ` Jonathan Mitchell
2020-08-18 15:34     ` Eli Zaretskii
2020-08-18 15:57       ` Óscar Fuentes
2020-08-18 16:33         ` Eli Zaretskii
2020-08-18 16:48           ` Óscar Fuentes
2020-08-18 17:05             ` Eli Zaretskii
2020-08-18 19:32               ` Stefan Monnier
2020-08-19  2:32                 ` Eli Zaretskii
2020-08-19 13:10                   ` Stefan Monnier
2020-08-19 15:06                     ` Eli Zaretskii
2020-08-19 15:30                       ` Stefan Monnier
2020-08-19 16:39                         ` Eli Zaretskii
2020-08-18 17:20             ` phillip.lord
2020-08-18 18:11               ` Daniel Brooks
2020-08-18 18:58                 ` Eli Zaretskii
2020-08-18 19:54                   ` Daniel Brooks
2020-08-18 18:15               ` Eli Zaretskii
2020-08-21 19:16               ` phillip.lord
2020-08-21 19:44                 ` Eli Zaretskii
2020-08-21 21:37                   ` phillip.lord
2020-08-21 22:53                     ` Drew Adams
2020-08-22  6:46                     ` Eli Zaretskii
2020-08-22 10:30                       ` phillip.lord
2020-08-24  9:28                   ` Robert Pluim
2020-08-24 10:40                     ` Eli Zaretskii
2020-08-24 12:11                       ` Robert Pluim
2020-08-24 15:14                       ` Stefan Monnier
2020-08-24 15:48                         ` Eli Zaretskii
2020-08-24 16:49                           ` Stefan Monnier
2020-08-24 17:06                             ` phillip.lord
2020-08-24 17:10                             ` Eli Zaretskii
2020-08-24 18:35                             ` Stephen Leake
2020-08-24 18:54                               ` Stefan Monnier
2020-08-24 17:01                           ` phillip.lord
2020-08-21 20:15                 ` Alan Third
2020-08-21 21:56                   ` phillip.lord
2020-08-22  6:37                     ` Eli Zaretskii
2020-08-22 10:21                       ` phillip.lord
2020-08-22 10:40                         ` Eli Zaretskii
2020-08-22 10:53                           ` phillip.lord
2020-08-22 11:15                             ` Eli Zaretskii
2020-08-22 12:52                               ` phillip.lord
2020-08-22 13:08                                 ` Eli Zaretskii
2020-08-22 13:53                                   ` phillip.lord [this message]
2020-08-22 14:35                                     ` Eli Zaretskii
2020-08-22 15:13                                       ` phillip.lord
2020-08-22 15:19                                         ` Eli Zaretskii
2020-08-22 17:28                                           ` phillip.lord
2020-08-22 17:32                                             ` Eli Zaretskii
2020-08-22 20:18                                               ` phillip.lord
2020-08-22 20:32                                                 ` Stefan Monnier
2020-08-23 21:19                                                   ` phillip.lord
2020-08-23 21:57                                                     ` Stefan Monnier
2020-08-23  5:36                                                 ` Eli Zaretskii
2020-08-23  7:53                                                   ` phillip.lord
  -- strict thread matches above, loose matches on Subject: below --
2020-08-10 23:00 Emacs 27.1 released Nicolas Petton
2020-08-12 12:01 ` phillip.lord
2020-08-15 17:49   ` Emacs 27.1 Windows Binaries -- testing wanted phillip.lord
2020-08-15 17:54     ` Eli Zaretskii
2020-08-15 18:38     ` Stephen Leake
2020-08-15 19:57     ` Alan Third
2020-08-17  4:44     ` Sivaram Neelakantan
2020-08-17 23:24     ` Tak Kunihiro

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=21e339147a2817352781e4abcc342bfb@russet.org.uk \
    --to=phillip.lord@russet.org.uk \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.