Re: Tests, Emacs-25 and Conditional Features

[Eli Zaretskii]

> From: address@hidden (Phillip Lord)
> Cc: address@hidden,  address@hidden
> Date: Fri, 18 Mar 2016 10:41:28 +0000
> 
> > More generally, I don't see how Emacs could know what you believe.  We
> > need to define the meaning of that first, and then find a way to
> > communicate that to Emacs.
> 
> 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 won't be useful at all: many such features are
platform-dependent, for example.  It makes very little sense to try
invoking w32notify or w32-shell-execute on GNU/Linux.  Likewise with
features that depend on specific GUI toolkits.

> > 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.

It would be trivial to add a libxml2-available-p function, but I fail
to see how is this different from using fboundp.  And AFAIU, in the
context of this discussion, you don't want to trust the likes of
gnutls-available-p, either.