Can you do this? Re: Automated VM build server

> Hi Igor. I really appreciate your work on this field.
>
> I wonder if you or someone could provide (in a future) the following:
>
> I would like to be able to download a PharoVM OneClick (or put the name you
> want), which is a zip with the following:
>
> 1) All the platform code of a version XXX.
> 2) All the src folder with the code generated by ConfigurationOfVMMaker
> version YYY.
> 3) Inside the platform folder, for mac, there is always a xcode project.
> This project file, should be configured so that it takes the sources from
> the src folder.
> 4) An squeak/pharo image with VMMaker and plugins loaded. And this has to be
> loaded by ConfigurationOfVMMaker version YYY
> 5) The previous image can also have a workspace with the Do-it that was used
> to generate the src folder. And, this should be pointing to the path ../src
>
> And of course, version YYY should work with XXX.
>
> If you can provide this, not necessary automaticallly generated all the
> time, but every some time, this would be awesome. This will let people to:
>
> - just open xcode/make and compile a vm
> - just open the image, change VMMaker, generate sources and then compile a
> new vm
>
> I think this will REALLY increase the people using/developing/learning VM.
>
> cheers
>
> mariano
>
> On Fri, Dec 17, 2010 at 9:17 PM, Igor Stasenko <[hidden email]> wrote:
>>
>> In our nearest plans is make an automated (Hudson based) build setup
>> for Cog and Squeak VMs.
>>
>> All files, which used for building an artifacts should be included in
>> source code repository.
>> So, most probably i will add the 'hudson-build' dir at same level as
>> 'platforms', where scripts and configs will be stored.
>>
>> Some changes which i going to do:
>>  - all generated code will be removed from version controlled tree.
>> Instead of it i will add an information, which will be enough
>> to reproduce the generated code by taking 3 separate config file(s)
>>
>> a) image version (or its URL(s) for download)
>> b) script for loading VMMaker (of concrete version) + all addons like
>> FFI , FT2 etc etc into image
>> c) script for generating the source code using VMMaker image
>> ..
>> z) tell me if i miss anything here
>>
>> With removing generated source code from repo we now can make sure
>> that any changes in VMMaker (including code generation itself)
>> can be tested and can be reproduced by build server at any snapshot
>> version.
>> Also, we could test & see if VMMaker loads well and can generate code
>> using different base images.
>> So, we will instantly know if any changes in compiler, or other layers
>> of system is breaking VMMaker.
>>
>> Because having a years old image where VMMaker works 100%, but at same
>> time have 100% chances that it
>> couldn't be loaded (or even if loaded, but can't run correctly) in
>> latest image is not what i think good practice for
>> keeping your house clean.
>>
>>
>> So, by getting rid any intermediate artifacts from build  chain we
>> will be able to make sure that:
>>  - VMMaker loads w/o problems in latest/multiple image(s)
>>  - VMMaker works well and can generate code
>>
>> That's means that for any newcomer, loading and building VM will be
>> much less tedious process, and for 99%
>> of cases it can be fully automated error free process.
>>
>> And let me remind our motto: we're not trying to produce perfect
>> system/setup from first lucky shot.
>> We slowly but steady crawling towards improved state of art.
>>
>> Any comments, ideas and suggestions are welcome.
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>
>