[Vm-dev] CMMaker.oscog to fork or not to fork, that! is the question

Esteban Lorenzano estebanlm at gmail.com
Wed May 7 05:11:33 UTC 2014


Hi,

if I can give an opinion, I would go through making a “SqueakVMMaker”, PharoVMMaker style. 
then you don’t need to fork the common base who will still be available for all platforms. 

Esteban

On 07 May 2014, at 05:17, David T. Lewis <lewis at mail.msen.com> wrote:

> 
> Hi tty,
> 
> I think that you are outlining a reasonable way to set up a build system,
> but if your objective is to get oscog and trunk VM builds to use a common
> build system based on Cmake, and if you want Ian and Eliot to adopt that
> approach, then I think you may be taking the long way around the problem.
> 
> The platforms source tree is maintained in Subversion, not in git. The
> Cmake code that is used to set up the build is maintained along with the
> platform sources (e.g unix/plugins/FilePlugin/config.cmake goes with
> unix/plugins/FilePlugin). Those cmake scripts are also maintained in
> Subversion, such than any Cmake snippet that may be needed to customize
> the build for unix/plugins/FilePlugin is maintained in Subversion along
> with the related platform sources.
> 
> It is certainly possible maintain the sources in git rather than Subversion,
> and it is also possible to generate the Cmake scripts from a Squeak (Pharo)
> image, thereby moving the version management into Monticello rather than
> Subversion. Both of these are possible, and the Pharo VM build demonstrates
> this quite nicely.
> 
> I am not going to try to argue that one approach or another is better (I do
> have opinions on the matter, but we are not suffering here from a shortage
> of opinions). But if your objective is to get oscog and trunk VM builds to
> use a common build system based on Cmake, then developing another build
> system may not put you on a fast path toward that objective.
> 
> Dave
> 
> 
> On Tue, May 06, 2014 at 06:19:26PM -0700, gettimothy wrote:
>> 
>> Hi Eliot and David and Tim.
>> 
>> 
>> Tomorrow I start the actual Smalltalk coding of the CMake stuff for Squeak. (My shell script that I thought would take 1 day took 5. sigh)
>> While I am leaning towards a fork of the CMMakeVMaker work on Pharo, I will defer to you folks on that decision.
>> 
>> 
>> Below are notes I had made a week ago about why I was leaning that way. 
>> 
>> 
>> -----begin notes I made a week or so ago----
>> 
>> 
>> For development purposes I am leaning towards creating a CMakeVMMaker.oscog clone of the existing CMakeVMMaker and incrementally adding platform/interpreter configurations starting with
>> the Stack Interpreter. Much of the work will be cut-n-paste modifications of the existing work in CMakeVMMaker done by the pharo team as that is the guts of the pharo system.
>> 
>> 
>> The Pharo environment (very clean, btw) has three layers to it (from top down they are).
>> 
>> 
>> 1. PharoVMMaker
>> 2. CMakeVMMaker
>> 3. Source Tree and scripts from github.
>> 
>> 
>> What is very interesting about pharo is that given 3) a git checkout, you can download, run and configure a new pharo image using a shell script provided with the git source.
>> Launching the resulting generator.image you  are presented a workspace with scripts invoking 1) PharoVMMaker which is a "wrapper" or "interface" to 2) CMakeVMMaker.
>> This generates the sources and CMake files and from there you go to the build directory and build
>> 
>> 
>> I like this approach and will be emulating it, but I do not think it is integrate the Squeak infrastructure into the existing package; here is why.
>> 
>> 
>> 1. Squeak source tree from svn is a superset of the tree from git with a slight difference in naming for the default build. Where Squeak has unixbuild, nssprucogbuild, etc, pharo just has build. 
>>    This "probably" has implications for the CMMake script generation that will not suffice for supporting the standard interpreter nor for the other flavors Eliot is developing.
>> 
>> 
>> 2. If I attempt to merge the two approaches (git and svn, pharo build tree and squeak build tree)  it will clutter the very clean work-flow pharo has. 
>> 
>> 
>> 3. As I develop this, I would like the squeak community to test-drive what I do. It is not appropriate for me to muddy the existing CMakeVMMaker with dev work
>> 
>> 
>> 4. Assuming I can actually do this thing, I do not think a merge of the two projects would be too difficult
>> 
>> 
>> ---end notes I made a week or so ago---
>> 
>> 
>> Please let me know your decision. 
>> 
>> 
>> 
>> 
>> cordially,
>> 
>> 
>> 
>> 
>> tty
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> :
>> 
>> 
>> 
>> 
>> 
> 



More information about the Vm-dev mailing list