Nevin Pratt <nevin at smalltalkpro.com> is claimed by the authorities to have written:


> 1. I googled "Squeak VMMaker".  It gave me Lex's page: 
> "http://minnow.cc.gatech.edu/squeak/2173 "
> 
> 2. Following the instructions on Lex's page, I downloaded and installed 
> VMMaker into my existing Linux image (a 3.2g-4843 image).  I get the 
> VMMaker filein by clicking the VMMaker link in Lex's page, and then on 
> the next page scrolling to the bottom and clicking on the link that says 
> "The changesets are at: ...".  Immediately below this changesets link, 
> it suggests also using a "ClassBuilderFix.cs" filein, which I try and it 
> crashes the image complaining about a serious meta inconsistency, so I 
> redo everything again without using ClassBuilderFix.cs this time.  I 
> move on without the ClassBuilderFix.cs.
> 
>            PROBLEM #1: THE "ClassBulderFix.cs" FILEIN CRASHES MY IMAGE
Does simply proceeding work ok? It files (takes a very long time) into
images on my Mac, Acorn and RH7.1 machines ok. Obviously if you have an
image with the ClassBuilder fix aready installed, don't bother to add it
again.

> 
> 3. Back on Lex's page, I click on "Getting source using the CVS 
> repository".  I create a 'src' directory within the directory I am 
> currently running squeak in, and then follow the cvs login instructions 
> in Lex's page.
Hmm, some explanations needed here. Although VMMaker can cope with any
old path to the place where you put the downloaded sources and any old
path to where the generated ones go, the makefiles for various machines
have assorted restrictions. On my Acorn for example, the two paths are
utterly hardcoded because there is np scripting in RiscOS. On Mac you
have to do approriate projectpath magic to change anything and under
linux you can apparently use assorted commandline dooberries. The
defaults provided by VMMaker are workable with all the makefiles I've
been able try.
That is to say (and the builtin Help stuff and VMMaker class comment it
refers to does explain some of this but perhaps  needs to explain more)
by default we expect:-

{working directory}
	/platforms
		/Cross (required for all cases)
		/Mac OS
		/RiscOS
		/unix
		/win32

I always download everything from SF, it hardly takes any more time than
fetching just mac or unix or whatever. It also provides useful
comparison code for when debugging one platform.

Then when you run VMMaker with all the defaults left alone (it assumes
./platforms for the 'path to platforms code' and the bubble help
explains this, it assumes the platform name is that returned by
Smalltalk platformName, and finally it assumes it can write newly
generated files into ./src) it creates the sources in the ./src tree and
(depending on platform) copies files from ./platforms to ./scr ready to
go.

Then depending on platform (again, and it would be really nice to
simplify this but you try getting agreement on this sort of thing) you
have to do different things to actually build the vm.

On Mac you have to unpack an archived resources file, open codeworrier
and import an xml version of the project file, do other Macish things
and press the go button.

On windows you have to do things I don't know about.

On Acorn you d-click on ./src/ MakePlug, wait then d-click on
MakePlugins and wait some more.

On unix you make a 'build' dir in your working directory, cd to it and
run ../platforms/unix/misc/configure which does lots of stuff. Then you
'make'. If you changed any of the directories in VMMaker you need to
read the help info in the generated makefile or the autoconf scripts or
wherever. Personally I'm too lazy to bother changing them. It works
without messing, so why bother? Once all the compiling is done you can
either 'make install' or d what I do which is 'cp squeak ..' and 'cp
.libs/*.so ..' to get a working vm & plugins in your working directory.

So, I think you made life difficult for yourself by
 - creating the src directory and trying to work within it. It happens
 to clash with the name chosen by VMMaker.
 - downloading only part of the CVS tree. If you get the whole lot I
 don't think you need to mess with getting the CVSROOT stuff.
 - touching the find * buttons. You don't need to. You're right about
 the CVS being included in the platform choices though - needs removing
 from the list.
 - using gcc 3.* which seems to have utterly screwed up some important
 things.
 
The big question is what we can do to improve the documentation to avoid
this confusion.

At some point, it is intended to provide ready-assembled source trees
for people that simply want to compile for some platform rather than
those that are intending to experiment with or develop for the vm. That
hasn't been done yet. We need some actual agreement before that can
happen.

tim

-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Strange OpCodes: LCD: Launch Cartridge Disk