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
next prev 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).