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

David T. Lewis lewis at mail.msen.com
Thu Jun 23 01:14:36 UTC 2016


On Thu, Jun 23, 2016 at 01:37:12AM +0800, Ben Coman wrote:
>  
> On Wed, Jun 22, 2016 at 10:02 AM, David T. Lewis <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
> >
> 
> But...  its all one repository.  Everyone who works on the vm in their
> personal space, doing a dozen generate/compile/commit cycles along the
> way, and then finally submits a worthwhile change via a pull request
> that is accepted, gets *all* their intermediate generated src added to
> the repository.

Don't do that. See Eliot's explanation. In addition to what Eliot said, I
will add that ./src generated from different images (e.g. two different
versions of Squeak, or Squeak versus Pharo) can and will produce different
results, even for the same version of VMMaker. It is important to check
carefully for changes like this, because they can have huge impacts on
performance and functionality.

In a perfect world, we would treat the generated ./src as intermediate
artifacts to be discarded just as we would discard the object files after
compiling a C program. But the world is not perfect, and we need to be
able to preserve and distribute the generated ./src files for various
reasons, and to do so in a controlled manner.

I very strongly advise following Eliot's guidelines.

Dave



More information about the Vm-dev mailing list