From: phillip.lord@russet.org.uk (Phillip Lord)
To: Michael Albinus <michael.albinus@gmx.de>
Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
Subject: Re: Tests, Emacs-25 and Conditional Features
Date: Fri, 18 Mar 2016 17:19:22 +0000 [thread overview]
Message-ID: <87vb4jemat.fsf@russet.org.uk> (raw)
In-Reply-To: <87pousdp9g.fsf@gmx.de> (Michael Albinus's message of "Fri, 18 Mar 2016 12:00:43 +0100")
Michael Albinus <michael.albinus@gmx.de> writes:
> 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?
Good point, although, if I understand the notification correctly, you
have an abstraction layer over these?
>>
>> 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?
Having a standard list of compile conditional features would be nice.
Phil
next prev parent reply other threads:[~2016-03-18 17:19 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-16 13:36 Tests, Emacs-25 and Conditional Features Phillip Lord
2016-03-16 14:29 ` Michael Albinus
2016-03-17 10:14 ` Phillip Lord
2016-03-17 16:25 ` Eli Zaretskii
2016-03-18 10:41 ` Phillip Lord
2016-03-18 11:00 ` Michael Albinus
2016-03-18 17:19 ` Phillip Lord [this message]
2016-03-18 18:38 ` Eli Zaretskii
2016-03-18 11:07 ` Eli Zaretskii
2016-03-18 17:20 ` Phillip Lord
2016-03-18 18:37 ` Eli Zaretskii
2016-03-19 21:26 ` Phillip Lord
2016-03-18 15:15 ` Stefan Monnier
2016-03-18 15:41 ` Eli Zaretskii
2016-03-18 15:54 ` Stefan Monnier
2016-03-18 18:32 ` Eli Zaretskii
2016-03-18 17:22 ` Phillip Lord
2016-03-16 15:48 ` Dmitry Gutov
2016-03-16 16:12 ` Eli Zaretskii
2016-03-16 18:53 ` John Wiegley
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=87vb4jemat.fsf@russet.org.uk \
--to=phillip.lord@russet.org.uk \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=michael.albinus@gmx.de \
/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.