[Pharo-project] [Hudson] Cog Unix build

laurent laffont laurent.laffont at gmail.com
Sun Feb 13 09:27:10 CET 2011


Waouh, not a week without incredible news :) Thank you !

Laurent


On Sat, Feb 12, 2011 at 11:19 PM, Igor Stasenko <siguctua at gmail.com> wrote:

> On 12 February 2011 18:38, Marcus Denker <marcus.denker at inria.fr> wrote:
> > Hudson news
> > ------------------
> >
> > Cog Unix
> >
> >        https://pharo-ic.lille.inria.fr/hudson/job/Cog%20Unix%201.3/
> >
> > This is using Igor's non-interactive build. Hudson does the following:
> >
> > git clone git://gitorious.org/~abrabapupa/cogvm/sig-cog.git
> > cd sig-cog/codegen-scripts
> > sh ./buildImage.sh -nodisplay
> > sh ./generate.sh -nodisplay ./CogUnix.st
>
> i changed the generate.sh to take the configuration class name.
>
> So now we should have multiple (sub)projects for building VM for each
> of the following configurations:
>
> sh ./generate.sh -headless CogUnixConfig
> sh ./generate.sh -headless StackInterpreterUnixConfig
> sh ./generate.sh -headless StackInterpreterDebugUnixConfig
> sh ./generate.sh -headless CogDebugUnixConfig
>
>
> > cd sig-cog/build
> > cmake .
> > make
> > zip -r Cog.zip results/*
> >
> > Problems:
> >        - do not do a clone but update the checked out source when they
> are already there
> >        - the generated VM crashes shortly after image startup
> >
> > But nevertheless, another tiny step.
> >
>
> Yes. i found the issue. Now it runs!!! :)
>
> And i were able to run all tests in pharo 1.3 core image on StackVM:
>
> 7864 run, 7787 passes, 51 expected failures, 8 failures, 17 errors, 1
> unexpected passes
>
> no more crashes! :)
>
>
> > What is nice is that this allows to trigger a build (and test)
> automatically when either
> > a new monticello or git commit happens, leading to a much faster
> turnaround when
> > doing changes to the VM.
> >
>
> Ideally, build should be triggered only when we commit something to git :)
>
> I should fix the codegen-scripts/LoadVMMaker.st to always use exact
> package version(s) for building image,
> not the latest one.
> So, then by checking-out some historical commit, one should be able to
> reproduce the same VM as we had,
> when committing it.
>
> And for testing if VMMaker could be loaded into latest development
> image, we can set up a separate project or use different scripts.
>
>
> > And of course the other important reason is that this allows people to
> set up their
> > own auto-build from a git clone when doing VM experiments, very useful in
> a
> > research and university setting.
> >
> >
> >        Marcus
> >
> >
> > --
> > Marcus Denker  -- http://www.marcusdenker.de
> > INRIA Lille -- Nord Europe. Team RMoD.
> >
> >
> >
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gforge.inria.fr/pipermail/pharo-project/attachments/20110213/0a89054a/attachment.htm>


More information about the Pharo-project mailing list