Hi, Am Sonntag, den 26.08.2007, 16:51 +0200 schrieb Robert Schwebel: > You are not, by accident, searching for a job? =8-)
Not at the moment ;-) I just got some intresting toys to play with ... > However, it'll be interesting to see how things turn out. If your > experiments look promising, it might be worth to re-activate our old > ColdFire boards. I hope to get an eval board soon. The next days we will know, if we go for mcf548x - chances are good :-) I already spoke with the hardware developer of the eval board, and he already got a linux terminal running on it. So first steps seem to be done already for Linux, and it sounds like a good starting point. > > And as FreeScale now also starts production of the v4m core (just MMU > > and no FPU), there might be a chance to get m68k out of ist niche. > > Don't think so. Not even PowerPC will survive for the long term, I > assume. Yes, that unfortunetely might be true. So this is -maybe- one of my last chances to work on something different than i386 derivates or ARM/MIPS stuff. But a good and performant Linux available for these targets might change things. > > For testing I can setup some nightly build for all toolchains on a > > dedicated server with _lots_ of free disk space. At the moment the > > server is more or less idleing all day. So people can download current > > toolchains as binary for functional tests at least - might save many > > hours waiting for recompilation. > > We already have an autobuild script. If you are interested, please tell > me and I give you access. Definitively. I have no ideas how many GBs of object code this script creates, but about 100GB should be available :-) I already made some thoughts about some kind of "nightly build/refresh toplevel makefile", which checks deps on the ptxconfigs in the toolchain - whenever a config updates, the makefile should rebuild the chain. All status info (compiled/compile-breakage) and logfiles should be accessible via some html page created by this makefile. Of course, something similiar can be done with a bash script as well. > It would be especially interesting to have something which automatically > tries our patch stacks ontop of nightly upstream snapshots. Such toplevel makefile could 'svn export' the gcc trunk to some dummy archive (e.g. gcc-svn-trunk.tar.bz2), whenever the revision changes (ok, seems to happen every day anyway). A matching ptxconfig could be executed on this snapshot gcc. Same could be done to capture glibc changes. As soon as some patch starts to fail, we would be informed by the script. > And, of course, doing something to integrate the gcc testsuite support > into PTXdist would be pretty cool. I never spent much time on these tests. I always got the impression, that these tests work best on the target system. That's no easy task, if you work on an embedded target with just a minimal root fs installed. So we probably need some working eval platforms or emulators with some NFS mounted root FS. The nightly build system must trigger the executionof the GCC tests suites somehow. Just an idea - any better ideas to test the correctness of a toolchain (beside empiric testing) are welcomed. Carsten -- ptxdist mailing list [email protected]
