No, but I'm putting together a hetrogenous cluster of Windows, Mac OS X, Linux x86, and Linux x86_64 boxes all running the same distcc'd compiler....
I'm very interested in packaging the toolchain and crosscompilers so people can deploy all that using RPM packages. It would be nice to only need 1 system for each architecture but still use the whole distcc-cluster.
OK, but note that the RPMs will be useless on the non-linux boxes, which are kinda the whole point... it probably wouldn't be too hard to build cygwin, fink, and/or solaris packages for this too, which would give you the equivalent ease-of-use...
I don't agree that RPM is useless on non-linux boxes. RPM runs on all Unix boxes and even in cygwin. Even when you're not using RPM as a package manager, you can still use RPM SPEC files (or source packages) to build binaries for a specific platform.
Beware. I did package up these toolchains as RPM files, and the resulting packages were so large they took 15 minutes to install. Unpacking a .tgz, by comparison, took about 5 minutes. Maybe rpm is more optimized by now. If not, this is probably an easy performance bug to fix.
It's even worse when you try to use alien to install these large RPMs on Debian. It's way slow, and I've seen people run out of disk space with the extra temp copy.
I agree with you that it probably isn't the best solution for Windows though. My interest is more in the general case. (and Red Hat specifically)
Unless the performance issues are addressed, you may find RPMs aren't the best way to handle these large packages.
By the way, since there are so many combinations of processor, gcc version, and glibc version, it would be hard to build all the RPMs for those combinations. If you're supporting a stable of engineers working on the same project, it's worth building the combinations you need once (possibly as an RPM, if that's how your site likes things). But Fedora probably wouldn't want to include all the possible RPMs my script can spit out. This is a case where package managers have a bit of a disadvantage compared to an engineer downloading the build script from http://kegel.com/crosstool and just building the damn thing themselves. - Dan
--
My technical stuff: http://kegel.com
My politics: see http://www.misleader.org for examples of why I'm for regime change
__ distcc mailing list http://distcc.samba.org/
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/distcc
