all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Nikolai Weibull <now@disu.se>
To: Emacs Developers <emacs-devel@gnu.org>
Subject: Autoconf autotest compilation-error-regexp
Date: Thu, 26 Nov 2015 21:28:37 +0100	[thread overview]
Message-ID: <CADdV=Mt4cjz82bS_9FA4txk9iZhQVKPYz_EVAJPw8ATz=kwvWg@mail.gmail.com> (raw)

Hi!

I’ve long been trying to set up a working autoconf autotest
compilation-error-regexp.  Autoconf’s autotest has some rather funky
output that’s quite difficult to parse correctly.  In fact, it only
outputs usable paths if given the -v command-line option, in which
case the output is (where all capitals replace generic information):

1. testsuite.at:5: testing TEST TITLE ...
./testsuite.at:11: COMMAND
1. testsuite.at:5:  ok

2. testsuite.at:16: testing TEST TITLE ...
./testsuite.at:22: COMMAND
--- -   2012-11-18 13:00:01.000000000 +0100
+++ .../stdout       2012-11-18 13:00:01.000000000 +0100
DIFF OUTPUT

2. testsuite.at:16:  FAILED (testsuite.at:22)

All lines prefixed by “ORDINAL. ” are headers.  The path is always
displayed without any directory part, so this information is next to
useless for a compilation-error-regexp.  The problem is that to the
gnu compilation-error-regexp, such lines look like actual errors,
which they are not.  We therefore need a compilation-error-regexp that
makes sure that these lines are ignored.

The first line after these header lines displays the command being run
to execute the test.  If this line is followed by a diff, the test
failed.

Given this specification, this is what I’ve come up with:

(add-to-list 'compilation-error-regexp-alist-alist
             '(autotest-header
               "^\\([1-9][0-9]*\\. \\([^\n
:]+\\.at\\):\\([1-9][0-9]*\\)\\): \\(?:
FAILED\\|WARNIN\\(G\\)\\|\\(testing\\| ok\\)\\)"
               2 3 nil (4 . 5) 1))
(add-to-list 'compilation-error-regexp-alist 'autotest-header)

(add-to-list 'compilation-error-regexp-alist-alist
             '(autotest-check
               "^\\(\\([^\n :]+\\.at\\):\\([1-9][0-9]*\\)\\): "
               2 3 nil 0 1))
(add-to-list 'compilation-error-regexp-alist 'autotest-check)

(add-to-list 'compilation-error-regexp-alist-alist
             '(autotest-check-error
               "^\\(\\([^\n :]+\\.at\\):\\([1-9][0-9]*\\)\\): [^\n]+\n--- "
               2 3 nil 2 1))
(add-to-list 'compilation-error-regexp-alist 'autotest-check-error)

The first issue is that there’s no way to tell compile.el that a
compilation-error-regexp should simply be ignored.  My suggested
solution is to allow HYPERLINK to be given as -1 (or 3) and for this
to mean that the match should be ignored.

The second issue is that it seems that multi-line regexps might miss
when there’s another regexp that can match on a single line
(autotest-check-error and autotest-check).  This happens
intermittently, and I suppose it’s due to how this is being handled,
where a scan gives a match on the autotest-check regexp if not enough
output has been produced yet to be matched by the autotest-check-error
regexp.  (Autotest-check is needed so that the line won’t be matched
by the gnu regexp.)  I don’t know how to get around this, beyond
applying patches to Autoconf that make the output a bit more sane.

Anyway, any suggestions on how to proceed?

Are there better ways of handling this?

Does it seem reasonable to add support for ignoring a matched line?

Is there any way of avoiding the intermittent issues with regexps that
match depending on how much output has been produced?



             reply	other threads:[~2015-11-26 20:28 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-26 20:28 Nikolai Weibull [this message]
  -- strict thread matches above, loose matches on Subject: below --
2012-11-18 12:06 Autoconf autotest compilation-error-regexp Nikolai Weibull
2012-11-18 18:36 ` Nikolai Weibull

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='CADdV=Mt4cjz82bS_9FA4txk9iZhQVKPYz_EVAJPw8ATz=kwvWg@mail.gmail.com' \
    --to=now@disu.se \
    --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.