From: Bobby Bingham <koorogi@koorogi.info>
To: musl@lists.openwall.com
Subject: Re: Building a solid musl automated-testing framework
Date: Mon, 4 Aug 2014 00:10:12 -0500 [thread overview]
Message-ID: <20140804051012.GA8714@duality.lan> (raw)
In-Reply-To: <20140731214716.GA27647@brightrain.aerifal.cx>
[-- Attachment #1: Type: text/plain, Size: 2503 bytes --]
On Thu, Jul 31, 2014 at 05:47:16PM -0400, Rich Felker wrote:
> I'd like to figure out how to setup the openadk test framework, or
> adapt things from it, for automated testing all musl ports. The repo
I like this idea. I'll probably start looking into putting this
together soon if nobody gets to it first.
> is here:
>
> http://www.openadk.org/cgi-bin/gitweb.cgi?p=adk-test-framework.git
>
> There's a lot of stuff hard-coded for the openadk toolchains, whereas
> I'd like to be able to use it with the musl-cross toolchains which are
> more canonical. The scripts also seem to be incompatible with busybox
> (using GNU features in something for making the initramfs, probably
> cpio?). And by default it tries to test musl 1.0.1 and doesn't have an
> obvious way to test from git.
>
> The idea I have in mind for using it as a basis for automated testing
> would be:
>
> 1. Have a Makefile and a subdirectory full of cross compiler trees.
> The set of archs could be based purely on the set of cross
> compilers, computed by the Makefile based on directory contents.
>
> 2. Have the Makefile clone/pull one musl tree from upstream git and
> then clone/pull an additional copy of the tree per arch/subarch
> (with the set of archs determined as in point 1).
>
> 3. Build each musl (via recursive make, i.e. make calling configure
> and make in each musl clone) and install them into the cross
> compiler include/lib dirs for their corresponding cross compilers.
>
> 4. Do like points 2 and 3, but for libc-test repo.
>
> 5. Use the kernel, initrd, and qemu stuff from the adk-test-framework
> to build initrd images and run them.
>
Last I looked, libc-test didn't support being built on one system and
run on another. Has this changed?
> The idea of using a Makefile (aside from declarative being The Right
> Way to do anything like this :) is to make it easy to make a single
> fix and re-run the test without rebuilding everything. Of course
+1
> rebuilding (via a "make clean" or similar) should aof coursebe an
> option and what's usually used.
>
> Does any of this make sense? Or is it simpler to get this kind of
> automated testing just making a few tweaks to the existing scripts?
>
> It would be ideal if the whole thing would work with dumping the test
> repo on a system not necessarily setup for running it (e.g. some kind
> of build farm or 'cloud computing' resource) and just produce the
> results that could be read offline.
+1
>
> Rich
--
Bobby Bingham
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2014-08-04 5:10 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-31 21:47 Rich Felker
2014-08-01 6:32 ` u-igbb
2014-08-04 5:10 ` Bobby Bingham [this message]
2014-08-04 5:30 ` Szabolcs Nagy
2014-08-04 12:18 ` Waldemar Brodkorb
2014-08-04 14:56 ` Rich Felker
2014-08-06 7:57 ` Waldemar Brodkorb
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=20140804051012.GA8714@duality.lan \
--to=koorogi@koorogi.info \
--cc=musl@lists.openwall.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.vuxu.org/mirror/musl/
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).