[squeak-dev] re: Downloading a VM is hard

Frank Shearar frank.shearar at gmail.com
Thu Jan 30 10:27:43 UTC 2014


On 29 January 2014 23:23, David T. Lewis <lewis at mail.msen.com> wrote:
> On Wed, Jan 29, 2014 at 09:57:06AM +0000, Frank Shearar wrote:
>> On 29 January 2014 05:13, David T. Lewis <lewis at mail.msen.com> wrote:
>> >
>> > 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.
>>
>> What names would you like? We can change them. Maybe "CogVM: verify
>> code generation"? My only desire here would be that "Cog" and
>> "Interpreter" remain as prefixes for the names.
>>
>
> Maybe CogVM-Slang and InterpreterVM-Slang would have been better. Or perhaps
> CogVM-VMMaker and InterpreterVM-VMMaker? The idea is that these jobs are
> focused on the Smalltalk to C code generation, as opposed to compiling a
> runtime VM with all the associated libraries and platform dependencies.

I have no issue with you renaming the builds. One thing to watch out
for is that it creates, AFAIK, a _whole new_ workspace. Any special
scripts in the old workspace must be manually copied over.

>> > 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.
>>
>> build.squeak.org does run builds, but it doesn't have to. For
>> instance, those OSX builds run on my Mac mini.
>>
>
> Agreed, and this is as it should be. I don't mean to sound as though I am
> contradicting you, as I think we are saying the same thing. The Jenkins at
> build.squeak.org does a very nice job of orchestrating tests, and these tests
> may be run on any number of slave servers. In the case of actual VM builds,
> we would want the the slave servers to be whatever the VM developers prefer to
> use, so that they can be set up with the appropriate compilers, libraries,
> and build tools.

Right. Yes, exactly. Ideally that ideal setup would be encoded in
however the build's started, through a bootstrap script, so that a
blank machine could be added and simply because it's, say, a RasPi
machine running RiscOS, magically the right binaries get pulled down
and installed and the job runs to completion. Ideally.

frank

> Dave


More information about the Squeak-dev mailing list