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

[Eliot Miranda]

On Tue, May 6, 2014 at 10:11 PM, Esteban Lorenzano <estebanlm at gmail.com>wrote:

>
> 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.
>

+1


>
> 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
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> :
> >>
> >>
> >>
> >>
> >>
> >
>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20140507/edad772a/attachment.htm