Hi Andreas,
sorry to be late in replying. This has been a busy month (I moved house).
Yes, this is already done. We are building spur VMs and images since awhile now. You can find all the related jobs here:
And as Eliot says��� is not *much* work��� except when it is :)
In fact, we were planning to release Pharo 4 (next week) with a Spur VM, but we didn���t finish all the small things around. So we will release next July (or around) a Pharo 4S (S, for Spur) with ���official��� spur support. We do not want to stay to much time in older versions. Also, our development process is different than squeak, AFAIK��� we drop backward compatibility in a regular basis. Which basically means we will move to spur and we will drop support for older versions.
Right, we are happy with our process and I do not see it fitting with svn. We changed a lot of ���organisational��� stuff to ensure traceability and ���buildability��� (if such word exists���). And we have made a lot of progress in that area using git and github infrastructure at a point most of the time to incorporate a change we just accept a pull request.
To be able to do that:
- we have to be sure what version of each component (vm, plugin, platform source) is part of the commit info. That���s why we keep together both platform sources and image sources (using filetree monticello format). That way each commit has everything we need to build the new vm. In fact��� I have a script ���./newVM <commit>��� that does a clone, prepares an image, generates sources and builds the vm��� then I can test if a pull request is valid. But most of the time that is not needed, because:
- for each pull request, we fire a travis job that creates a vm from scratch and then runs all tests we have in Pharo (and we have improved a lot in that area latest years). They are not ���vm specific tests���, but since they tests all the system, if vm does not crashes and tests are run, we can be sure is working (this wouldn���t be possible without right traceability).
- we also build the vm using CMake, but not directly, we use CMakeMaker which allow us to define the build in smalltalk.
- finally, we would like to use the other capabilities (for documentation, etc.) we gain for free by using github. Not that we are already using it��� but we would like, in the future.
So��� obviously all of this can be achieved without using git and github��� but there the infrastructure is already done.
Said that. Even if we actually have a different process, we (Myself, particularly) are trying to reduce the gap between both VMs. And right now this is the status:
- in the VM itself there is almost no change. AFAIR, just two small things:
a) I include setjmp.h somewhere, because compiler was asking for it (We use different versions than Eliot)
b) the macro to read the image is changed, because we needed to change it for allow build an iOS image. This is just one line in the image and the addition of one macro in 4 platform sources (Linux, Win and Mac redirects to old macro, but iOS implements something different)
- In the platforms we have the most important difference, because we deprecated the ���Mac OS��� branch in favor of ���iOS���, which in fact should be called OSX, because is the Cocoa version. I understand Eliot want to go in that direction soon so we will align in that area too (btw, that branch has growth organically so we'll need to do some reorganisation to clarify it, eventually)
- in the plugins, we try to adopt a different approach than the previous one: instead using particularities of the platform, we want to align sources as much as possible, so we use the posix libraries. Again, that���s just when is possible (and when we have time). The most important change we produced here is with FilePlugin: we changed it to provide posix-permissions (and soon we will add primitives to retrieve also ownership). To allow that, we changed a lot in the windows version of the plugin, because instead windows functions we use MinGW. We would like to see this changes merged.
After that, I think there will be some other minor changes��� not many, and most probably we can remove those differences.
hope this clarify all :)
cheers,
Esteban