bug-inetutils
[Top][All Lists]
Advanced

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

Re: gnulib self-tests


From: Bruno Haible
Subject: Re: gnulib self-tests
Date: Wed, 11 Sep 2024 01:31:06 +0200

Hi Simon,

> I think the ideal state I would prefer is if the gnulib self-tests are
> run first (with a simple way to disable them, for speed) and then
> displayed, but a failure won't cause the projects' core self tests to
> not be run.  If the core self tests pass, then any failure in the gnulib
> self tests can be shown.

I agree that this would be ideal. But I don't know how to implement this
either, without major 'make' contortions.

> One problem with
> putting the gnulib tests last is that for most normal cases, after a
> successful run, the user will see the output of the gnulib self tests in
> the terminal, not the actual project's self tests.  IMHO, it looks nicer
> to see the result of the project's self-tests at the end of the run, and
> have the gnulib self tests higher up because they are internal.

Interesting to see how different people have different preferences.
I always go with "most important first", not with "most important last"...

> This is
> also relevant for CI/CD systems: sometimes you only see the tail of the
> log output, and displaying earlier outputs requires extra work.

This is particularly true for GitLab, but not for GitHub. In GitHub,
you can display as much output as you want in the scrollable log,
and you can also put as much output as you want into downloadable
artifacts.

In other words: Don't let the choices of today, that we will use for
the next 10 years, be influenced too much by limitations of today's
tools. (E.g. I hate the 80-columns limitation from the GNU Coding
Standards, a limitation that has its origin in the sizes of the
terminals of the 1980ies and of the displays of the 1990ies.)

Bruno






reply via email to

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