Date: Mon, 4 Aug 2014 00:10:12 -0500 From: Bobby Bingham <koorogi@...rogi.info> To: musl@...ts.openwall.com Subject: Re: Building a solid musl automated-testing framework 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 Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.