[Top][All Lists]

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

Re: Tests, Emacs-25 and Conditional Features

From: Eli Zaretskii
Subject: Re: Tests, Emacs-25 and Conditional Features
Date: Fri, 18 Mar 2016 13:07:18 +0200

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

reply via email to

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