mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Natanael Copa <>
To: Rich Felker <>
Subject: Re: [musl] Current state and future of musl development infrastructure
Date: Thu, 16 Dec 2021 12:40:05 +0100	[thread overview]
Message-ID: <20211216120253.158cc852@ncopa-desktop.lan> (raw)
In-Reply-To: <>

On Thu, 16 Dec 2021 00:02:20 -0500
Rich Felker <> wrote:

> On Wed, Dec 15, 2021 at 04:52:05PM -0600, Zach van Rijn wrote:
> > On Wed, 2021-12-15 at 22:22 +0100, jvoisin wrote:  
> > > Hello everyone,


> > As for CI.
> > 
> > It would probably be helpful to be able to run libc-test and
> > perhaps other applications on a number of real hardware platforms
> > in some automated manner.  
> Yes. Having this automated would be really nice. Even better if it
> could be done not just for the official upstream repo but for proposed
> patches/patchsets or third-party git branches (on some sort of
> request).

I think it would be helpful to have the tests bundled in musl git
repository and in release tarballs. It is common practice for
downstream packagers to run `make && make check`, to run unit tests to
have some basic smoke testing (that does not require root permissions).

Depending on some external test suite (libc-test) is suboptimal because
they may not catch recent additions, and it may be difficult to keep
track of what is expected to pass or fail.

I think it would make sense to have both a lighter/faster integrated
set of unit tests, that are bundled with musl itself and have a more
extensive (external) integration tests that is run with the CI.

> I'd really love if the CI were optimized to do incremental builds and
> reuse artifacts as much as possible for rapid results, but doing that
> right probably requires fixing missing dependency tracking in the
> build.

Just an idea for incremental builds: Do out-of-tree builds. let the CI
store a tarball of the out-of-tree build in some key/value storage,
using the commit hash as the id. Subsequent builds tries fetch the old
heads community id from storage and extract it to the out-of-tree build

It might also be a good idea to try get it work first and optimize
afterwards :)


  reply	other threads:[~2021-12-16 11:40 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-15 21:22 jvoisin
2021-12-15 22:52 ` Zach van Rijn
2021-12-16  5:02   ` Rich Felker
2021-12-16 11:40     ` Natanael Copa [this message]
2021-12-16 13:50       ` Rich Felker
2021-12-16 19:20     ` Zach van Rijn

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:

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

  git send-email \
    --in-reply-to=20211216120253.158cc852@ncopa-desktop.lan \ \ \ \

* 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

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 NNTP newsgroup(s).