[Vm-dev] Re: Uploaded squeak-vm 3.11.3

[Eliot Miranda]

On Wed, Jan 27, 2010 at 7:13 PM, K. K. Subramaniam <subbukk at gmail.com>wrote:

>
> On Wednesday 27 January 2010 08:56:07 pm Bert Freudenberg wrote:
> > On 27.01.2010, at 05:37, K. K. Subramaniam wrote:
> > > On Tuesday 26 January 2010 11:09:26 pm Bert Freudenberg wrote:
> > >> Well, there is a source for this of course (in the VMMaker Squeak
> > >> package). Generating the C code is a manual, interactive process and
> > >> requires a running Squeak installation. Making that scriptable is
> > >> possible, but so far nobody has done it AFAIK
> > >
> > > That is because most of the builds so far have been one target (which
> is
> > > also the host). Batch builds are needed for multiple variants (e.g
> > > debug/release) or when cross-compiling (say to ARM targets).
> >
> > Ian does batched cross-builds. But the source is still only generated
> once.
> >  All targets use the same generated sources.
> The generated files are not the "source". To reiterate the issue raised in
> the
> bug report -
> ---
> the file platforms/unix/src/vm/interp.c starts with:
>
> /* Automatically generated from Squeak on an Array(9 May 2008 11:24:03 am)
> by VMMaker 3.8b6 [...]
>
> However, I cannot identify the source file for that file. Also,
> debian/copyright doesn't contain any hint how this file is generated.
>

Indeed.  In the Teleplace VMs we generate e.g.

/* Automatically generated by
    CCodeGenerator VMMaker-eem.524 uuid:
9b748596-0986-4ca7-ac5b-b7a050a08431
   from
    SimpleStackBasedCogit VMMaker-eem.524 uuid:
9b748596-0986-4ca7-ac5b-b7a050a08431
 */
static char __buildInfo[] = "SimpleStackBasedCogit VMMaker-eem.524 uuid:
9b748596-0986-4ca7-ac5b-b7a050a08431 " __DATE__ ;
char *__cogitBuildInfo = __buildInfo;

where the UUIDs are those form the Monticello package.  If the package is
dirty when the source file is output it gains an asterisk:

/* Automatically generated by
    CCodeGeneratorGlobalStructure * VMMaker-eem.519 uuid:
151cad6d-ee56-4458-a45d-a5c53502b5be
   from    CoInterpreter * VMMaker-eem.519 uuid:
151cad6d-ee56-4458-a45d-a5c53502b5be
 */
static char __buildInfo[] = "CoInterpreter * VMMaker-eem.519 uuid:
151cad6d-ee56-4458-a45d-a5c53502b5be " __DATE__ ;
char *__interpBuildInfo = __buildInfo;

So we can determine both the Smalltalk source and the version of the
generator that pushed out the C, or if it was an indeterminate version.
 This is also available through the system parameter primitive.  Also note
that tehthedate is the date of compilation, not generation, which should be
immaterial.


----
> The "source" for this file is in embedded in vmmaker image. The header only
> states that VMMaker was used as a tool but it is not evident that this
> version
> of VMMaker also embeds the "source" for the interpreter (and the plugins).
> I
> realize the tool and the sources are all one big blob in Squeak, but we
> still
> need to consider interpreter and plugins as separate units during builds.
>
> So the questions that arise for downstream builders are :
>
>  a) Where is the information about generating this intermediate file from
> the
> source? (i.e. tool, makefile, batch script)
>  b) What is the license on that particular source unit which was used to
> generate this intermediate file? Should all plugins use the same license as
> the
> interpreter?
>
> In a manual process, these are all "in the head" but that doesn't help
> downstream builders like Debian. In a batch process these steps are
> recorded
> in scripts for anyone to read, follow and modify, if necessary.
>
> Isn't "generated source" an oxymoron :-)? I would favor getting rid of
> these
> files from version control and go directly to filing Slang changesets into
> VMMaker and translating them on the fly in Makefiles. I would even support
> writing unix/ and Cross/ in Slang. Let C become the assembly language in
> Squeak.
>

Practically it is much more convenient to be able to gather all the C/C++
files together for a Vm build than it is to start form a set of C/C++ files
and a Smalltalk source file and a Smalltalk image and a tool.  We keep an
image containing a VMMaker in svn (in a directory image alongside platforms)
and generate the vm/plugin tree form that image, updating it when VMMaker or
a plugin is changed.  So a checking checks in the new source and the new
image.  But if one wants to build one simply checks out the entire tree and
builds, instead of having to fire up the VMMaker image.  Once Squeak is
reliably headlessly scriptable across platforms one might revisit that but
then you'd introduce a dependency of having to have a working VM to run
VMMaker to punch out the sources, which could put a damper on developing for
new platforms.

So while attractive in the abstract I think making the generated sources
purely an intermediate form is a mistake.  In this case If It Ain't Broke
Don't Fix It.


> Subbu
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20100127/383e939c/attachment-0001.htm