unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Lars Ingebrigtsen <larsi@gnus.org>
To: Pip Cet <pipcet@gmail.com>
Cc: emacs-devel@gnu.org
Subject: Re: Run (some) tests more automagically?
Date: Sun, 21 Feb 2021 17:05:04 +0100	[thread overview]
Message-ID: <87pn0tiez3.fsf@gnus.org> (raw)
In-Reply-To: <CAOqdjBdLVYmzRfxLdXdszfaRnzp7vUdG6Q0zJbHCXoUzjAM3PA@mail.gmail.com> (Pip Cet's message of "Sun, 21 Feb 2021 14:28:00 +0000")

Pip Cet <pipcet@gmail.com> writes:

> Yes, let's! Except we need to agree on what "has been changed" means.
> My initial idea would be to create a time stamp file the first time
> make is run in an emacs directory and consider only those source files
> which are newer than the time stamp, only if they're recompiled.

Hm, yes, a time stamp would probably be the way to go...

> But what should we do when we run "git pull"? Should the time stamp be
> updated for all tests after every make, for successful tests only, or
> only if all tests that were run were successful? Should the check run
> after the rest of make has (possibly after a "build successful,
> continuing automatically to run tests" message so the impatient can
> interrupt it at that point), at the same time as the rest of make
> (increasing time-to-test, IMHO) or asynchronously after make has
> finished?

These are all good questions.  :-)

Off the top of my head without thinking about it more than ten seconds:
Since this is a low-cost low-effort thing, I think the timestamp should
just be updated when it's run, and just a single timestamp, no matter
how much fails.

So if you do a git pull, and that updates foo.el and bar.el, then "make"
would (as now) compile foo.el and bar.el, and Emacs would then notice
that foo.elc and bar.elc are newer than the previous timestamp, and then
run the foo-tests.el and bar-tests.elc files, and then update the
timestamp.

I think that might be unnoticeable enough that developers wouldn't be
disabling this when working?

Of course, if we rely on this too much, then there's the temptation to
never actually run a full "make check", but we have the CI for that, so
perhaps that's not too big a worry.

> Speaking of code changes, one thing I'm worried about is that one
> developer on, say, Windows does something, forgets to adjust the tests
> so there's a spurious failure on GNU/Linux, and then the next
> GNU/Linux developer to touch the file will see a test failure that has
> nothing to do with their changes. I don't have a good solution for
> that one.

Me neither.  But that's also the case today.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



  parent reply	other threads:[~2021-02-21 16:05 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-21 13:25 Run (some) tests more automagically? Lars Ingebrigtsen
2021-02-21 13:48 ` dick.r.chiang
2021-02-21 14:28 ` Pip Cet
2021-02-21 14:45   ` Philipp
2021-02-21 16:05   ` Lars Ingebrigtsen [this message]
2021-02-21 15:37 ` Eli Zaretskii
2021-02-21 15:57   ` Lars Ingebrigtsen
2021-02-24 10:42 ` Phillip Lord
2021-02-24 14:34   ` Lars Ingebrigtsen
2021-02-26 11:44     ` Phillip Lord
2021-02-26 11:50       ` Lars Ingebrigtsen
2021-03-01 17:50         ` Phillip Lord

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

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87pn0tiez3.fsf@gnus.org \
    --to=larsi@gnus.org \
    --cc=emacs-devel@gnu.org \
    --cc=pipcet@gmail.com \
    /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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).