On Tue, Jan 28, 2014 at 07:10:11PM -0800, tim Rowledge wrote:
> 
> On 28-01-2014, at 5:44 PM, Craig Latta <craig at netjam.org> wrote:
> 
> > 
> >     I've done VM rebuilds on all platforms recently. If there's
> > anything we need, please let me know.
> 
> All platforms? I didn?t know you had gone RISC OS ;-) But of course, if you have a Pi, you actually could?
> 
> We have some fairly sophisticated automation stuff in place and maybe we can leverage that to provide some more timely builds for fans of bleeding edges. I know there is the Jenkins builder but my understanding is that it is intended to do check builds (?) and right now the jenkins dashboard at http://build.squeak.org/ is showing a lot of red for OSX related VMs. I?m not about to guess what most of it even means. Well, except that the Cog related log seems to imply a problem with even trying to generate the sources.
> 

If you are looking at the CogVM job, it is currently failing on some sort of fairly
trivial bug in initializing VMClass when loading into a clean Squeak image. I was
looking it last weekend just long enough to spot the problem, but not to suggest
a solution.

I regret my choice of "CogVM" and "InterpreterVM" as names for those two jobs, as it
implies that they are VM build jobs. They are intended to verify VMMaker code generation
only, and the build artifacts are just source tarballs that claim to be compileable.

I don't know what any of the OS X related jobs are doing.

> What seems to be missing is assembling the sources *and checking them in* (I know this might cause some storage space issues for Ian on squeakvm.org after a while) in the way that IAn occasionally does for the unix tree; which means that it is harder than really neccessary for me to grab a source tree and build a Pi/Raspbian vm. Worse, it is harder for the guy that puts together the ?production? Raspbian vm package. And of course it would be nice to include both Cog and StackVM code.
> 

Per suggestion from Ian, I have been checking them in under trunk/src (in parallel
with trunk/platforms). Space is not an issue. It's a manual procedure, but the idea
is that when you commit something to VMMaker that affects the generated code, you
also update VMMaker class>>versionString, generate the sources, eyeball them for
sanity, and check them in to trunk/src. Ian has also updated the CMake build so
that it uses these sources (as opposed to the platforms/unix/src copy that tends
to go out of date). He also incorporated the conventions used for plugins.int,
plugins.ext, and plugins.exc so that they are compatible with the procedure that
Eliot is using for Cog. These changes appeared in various commit notices over the
last few months on the vm-dev list.

If we are going to do automated VM builds, this should be done on squeakvm.org and/or
whatever Eliot might want to use for Cog. I'm quite sure that Ian would be happy to
support this. I personally would like to see it under the control of the Jenkins
infrastructure on build.squeak.org, because this provides a nice console to show
status and to retrieve build artifacts. But I think that any actual VM builds need
to be done on suitable platforms (definitely not box3.squeak.org), and if possible
should be looked after by whomever supports that actual VM.

> Mostly what we need is some much more clear information with clear links to both ?stable? vms (and platform packages etc if wanted) and development vms, with a decent description of the ways to make use of them. 
>

100% agree. It might take some work to make this happen, but it is badly needed.

Dave