Yes, Mariano, this is what we want to do. Maybe little different in detail, but the result will be the same: you can checkout XXX version of sources from repository and build the VM using same VMMaker which were used to build VM.
I hope we will meet tomorrow and discuss the details. On 19 December 2010 17:17, Mariano Martinez Peck <marianop...@gmail.com> wrote: > 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 <siguc...@gmail.com> 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. >> > > -- Best regards, Igor Stasenko AKA sig.
