Re: Tests, Emacs-25 and Conditional Features

[Michael Albinus <michael.albinus@gmx.de>]

phillip.lord@russet.org.uk (Phillip Lord) writes:

Hi Philip,

> Something like
>
> (skip-unless (or (gnutls-available-p) conditional-feature-force))
>
> So, we pick have a standard test selector which means "all the
> conditional features should be expected to be on". Probably, you would
> want "all the conditional features that are supposed to be on by
> default, should be expected to be on"

That does not exist for everything. For example, in the file
notification case there are 5 different possible "conditional features",
all of them valid:

- inotify enabled
- kqueue enabled
- gfilenotify enabled
- w32notify enable
- file notification disabled.

How does a test library shall know what is intended by the user?

In all my tests packages, I have one test which checks all these
alternatives, and maybe checks additionally whether they make sense. See
file-notify-test00-availability or, more sophistiacted,
tramp-test00-availability. For all other test cases, I'll start with the
(skip-unless ...) form.

>> Then there's the issue of how do you test this.  An API that was not
>> compiled into Emacs cannot be invoked, so what do we want to show the
>> user? a "void function" error? ert error messages are not so easy to
>> interpret.
>
> It would be nice if there were a standard way of detecting this. As
> Michael's example shows, we have a gnutls-available-p function which
> is defined if gnutls is not available, but for libxml, we check for
> non-definition of functions.

This would require for all optional packages to provide such a
standardized form. We don't have it.

One way would be to test (skip-unless (featurep 'package)). But even
this is not possible in general, packages like xml.c miss

  Fprovide (intern_c_string ("libxml"), Qnil);

Maybe this is an error in xml.c, which should be fixed?

> Phil

Best regards, Michael.