Date: Thu, 31 Jul 2014 17:47:16 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Building a solid musl automated-testing framework 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 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. 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 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. Rich
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.