[Vm-dev] VM packaging for Cog transition
David T. Lewis
lewis at mail.msen.com
Wed Nov 10 19:20:47 UTC 2010
On Wed, Nov 10, 2010 at 11:33:28PM +0530, K. K. Subramaniam wrote:
> On Tuesday 09 Nov 2010 11:50:42 pm Andreas Raab wrote:
> > On 11/9/2010 10:10 AM, K. K. Subramaniam wrote:
> > > Bert's reply is ingenious ;-). Generated files are intermediate files,
> > > not true source files. True "sources" are actually Slang code in VMMaker
> > > image and these should be in version control.
> > The generated files are true source files. If you've ever had the need
> > to ensure that you're building the same VMs across various platforms
> > you'll quickly find that you're moving generated files around, not images.
> I meant "source" in the sense of being able to copyright, apply patches and
> track version history, not just in the sense of using them to compile into
> object code.
> While it is possible to ???bypass VMMaker and maintain sources manually, it is
> not how Squeak is being maintained today. AFAIK, If there is a bug in
> interp.c or in any of the internal plugin code that causes build to fail,
> patches go into VMMaker, not into generated source. The generated code
> contains a reference to VMMaker version for applying patches.
> Of course, once the patched code is regenerated, VMMaker is not required for
> subsequent builds. Then, what you say applies.
I think we are mixing words here. From the point of view of development,
Smalltalk is the source. From the point of view of rebuilding the VM
in a reliable and reproducable manner, the generated C files are the
source. Both are valid and important uses. It is important for people
to be aware of the distinction so that they do not mistakenly "fix" a
problem by modifying generated C sources, but aside from that there
is no conflict.
The various suggestions for keeping generated sources outside of
the ./platforms tree are, I presume, intended to reduce this kind
More information about the Vm-dev