This is lovely. A few thoughts: - I wonder if using Docker instead of VirtualBox could make incrementality easier, since that's one of things that they focus on. - I wanted to be able to see which of my packages had problems, so I wrote this PR: https://github.com/plt/racket/pull/721 but I'm not sure how to test it. - I think we need to support planet packages -- there are some people still releasing new ones, and there are old ones would take non-trivial work to port.
Sam On Tue, Jul 8, 2014 at 7:46 AM, Matthew Flatt <mfl...@cs.utah.edu> wrote: > I've been working on a service that builds all packages listed at > "pkgs.racket-lang.org". The idea is to run builds regularly (at least > once a day) and link to documentation and build-status information from > "pkgs.racket-lang.org". > > Here's a table showing the current results for each package: > > http://www.cs.utah.edu/~mflatt/tmp/pkg-build/ > > Overall, there's still some work to do before this service can can go > live, but I think it's getting close. > > Currently, a package fails to install if it depends on a PLaneT package > --- even a compatibility variant from "planet-compats.racket-lang.org". > That limitation could be removed with more work, but I think it's > probably better to get all packages that we care about onto > "pkgs.racket-lang.org". > > The rightmost column of the table may need some explanation. The column > highlights conflicts among names of package-installed executables, > foreign libraries, and documents. Currently, all the conflicts are > document names, because several packages have a documents named simply > "manual" or "main". Overlapping documentation names cause no trouble > among packages in user scope, which is why this problem has gone mostly > unnoticed. Packages in installation scope, however, must have distinct > document names, because installation-scope documentation goes to a > single directory. So, to support installation scope, various packages > need to be updated to give a more specific name to generated > documentation. > > > The implementation of the build service is `meta/pkg-build/main` in the > Racket repo. The build service relies on VirtualBox MV instances to > sandbox package builds, and the complexity is related to handling > failure and making the build incremental (so that a small amount of > work can be done if a small number of packages need to be rebuilt). > It's still a work in progress, but I'm happy to provide more details if > anyone wants to try it out. A full package build takes about an hour on > my laptop, in addition to the 45 minutes or so to build a snapshot > distribution from scratch. > > _________________________ > Racket Developers list: > http://lists.racket-lang.org/dev _________________________ Racket Developers list: http://lists.racket-lang.org/dev
