[Vm-dev] The code in the src folders in the repository

Esteban Lorenzano estebanlm at gmail.com
Thu Jun 23 09:58:59 UTC 2016


I want to clarify how we do it in Pharo, and why we think is a good approach. 

Please, note that I’m not asking to change anything, I’m just doing story telling :)

1) In Pharo, since a couple of years, VMMaker *and* plugin sources coexist along with platform sources, in same repository. 

pharovm/
	image/
	platforms/
	mc/					—> This is the important!
		VMMaker.package/
		Freetype-Plugin.package/
		…
	...

(we take the effort of keeping the plugin packages here, as a mirror from his original repositories, but this is more or less automated and also, we think it worths the effort)

2) In Pharo, CI build always rebuild all source code: 
	- it builds an image, using a BaselineOf from Metacello
	- then it builds ALL sources
	- then builds the VM

3) CI also executes all Pharo tests (we have an acceptable number of tests)

Of course, doing all this in development time is losing time, but in CI is very important and produces significant advantages: 

1) we know exactly which version (including Monticello versions) correspond with each build (and if we want to reproduce it, is a simple checkout)
2) we know immediately if a recent change breaks VMMaker image build (some times has happened)
3) we know immediately if a change broke compilation as a side effect (this happens more of less often, specially when working with the C translator)
4) we know immediately if a change broke something image side 

This process will change now, as we adopt OS/vm, but in our plans we will keep parts of this model.  We will include OS/vm as submodule along with the packages: 

pharovm/
	@osvm/ —> this is a submodule	
	mc/
	
- we will first generate image using our method 
- then we will follow OS/vm method, using this image (a Pharo image… for us is very important to be able to build the VM from Pharo)
	- we will generate sources using it
	- and then we’ll generate the VM using the OS/vm method. 

at least, this is what we are aiming for. 

Notice that this way everybody has what they want: Eliot and others can continue working how they like, and we have what we want: a complete reconstruction process who verifies everything. 

Once put in place, this system will also benefit non-pharo users, because there will be the feedback available too.

cheers, 
Esteban 

> On 22 Jun 2016, at 13:15, Esteban Lorenzano <estebanlm at gmail.com> wrote:
> 
> 
>> On 22 Jun 2016, at 12:52, phil at highoctane.be <mailto:phil at highoctane.be> wrote:
>> 
>> One could thing of doing a git submodule with them but it is more trouble than it is worth.
>> 
>> I want to be able to clone the VM and compile it right away.
>> 
>> Phil
>> 
>> On Wed, Jun 22, 2016 at 10:11 AM, Norbert Hartl <norbert at hartl.name <mailto:norbert at hartl.name>> wrote:
>>  
>> 
>>> Am 22.06.2016 um 09:51 schrieb Fabio Niephaus <lists at fniephaus.com <mailto:lists at fniephaus.com>>:
>>> 
>>> AFAIK the pharo-vm projects generates the sources from the VMMaker package during a build.
>>> Wouldn't it be better if the OpenSmalltalk vm does the same? Then no one needs to generate source manually anymore and we don't have millions of lines [2] of generated code in the repository.
>>> 
>> How would you release a version of the vm? This is only possible of you archive the static artefacts.
> 
> I do not understand this question, so maybe I’m answering anything :)
> in Pharo, VMMaker package sources coexist along with C sources (thanks to filetree for now, but we are working on enhance that). This way, each release of VM in github contains *exactly* all the sources needed to reconstruct it… 
> 
> Esteban 
> 
>> 
>> Norbert
>> 
>>> Fabio
>>> 
>>> [1] https://github.com/pharo-project/pharo-vm <https://github.com/pharo-project/pharo-vm>
>>> [2] see Eliot's stats at https://github.com/OpenSmalltalk/vm/graphs/contributors <https://github.com/OpenSmalltalk/vm/graphs/contributors>
>>> 
>>> -- 
>>> 
>>> On Wed, Jun 22, 2016 at 4:02 AM David T. Lewis <lewis at mail.msen.com <mailto:lewis at mail.msen.com>> wrote:
>>> 
>>> On Tue, Jun 21, 2016 at 11:11:28AM -0300, Laura Perez Cerrato wrote:
>>> >
>>> > Hi everyone,
>>> >
>>> > Excuse me if this has been asked already or it's documented somewhere and I
>>> > missed it, but what's the criteria to update the code in /src, /stacksrc,
>>> > /spursrc and other similar folders in the repository?
>>> >
>>> > -Laura Perez Cerrato
>>> 
>>> Good question. Traditionally, Eliot generates these sources periodically and
>>> commits them to the repository (and in recent years I have done that chore for
>>> the old trunk interpreter VM). At this point, unless Eliot advises otherwise,
>>> I would suggest that no one other than Eliot should commit to the /src trees.
>>> 
>>> Dave
>>> 
>> 
>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160623/3cc47c22/attachment.htm


More information about the Vm-dev mailing list