Building Linux VM with VMMaker from sourceforge CVS

Tim Rowledge tim at sumeru.stanford.edu
Thu Dec 27 16:22:38 UTC 2001


"David T. Lewis" <lewis at mail.msen.com> is widely believed to have written:

> On Thu, Dec 27, 2001 at 08:21:17AM -0500, Stephen Pair wrote:
> > I'm trying to get a VM build environment going on a Linux machine from
> > the CVS platforms tree and VMMaker.  It looks like the configure and
> > make scripts are not quite happy with this new directory structure.  I
> > try to run platforms/unix/misc/configure, but it's not happy.  Am I
> > missing something, or are things not quite there yet?
> 
> You're not missing anything. The good news it that it will build fine,
> except for the MPEG plugin; just ignore the warnings. You should consider
> the CVS repository to be an unauthorised hacker's copy of the master
> source, which belongs to Ian. Personally, I prefer to use the unauthorized
> hack, but don't be surprised if there are some problems with it.

Unauthorised ? In an open source wordd? Hmm, not sure that concept
really applies. Anyway, the code in a few files needed altering to allow
it to work with any/all plugins external; a diff between version would
show what they are and how minor. Mostly small bugs that would require
plugins to be internal in order for the vm to link successfully (I seem
to remember an explicit init of the serial port for example, which the
serial plugin handles if it is ever loaded)

The MPEG plugin needs some work in the makefile stuff - Lex originally
provided an altered 'mkfrags' file that apparently makes it work, but I
haven't had the time or reason to try to integrate it with the slightly
hacked makefiles needd for the VMMaker system. I think the new JPEG
plugin needs a tiny amount of rework as well, and I hope to get to it
sometime. Aside from that, it really should be a case of

get image (up to 4478 currently tested by me)
load VMMAker
VMMakerTool openInWorld
choose your poisons (which plugins are internal/external/ignored)
pres the go button
wait
.
.
.
chmod a+x src/con* src/ac* src/in* src/lt* src/util/*  (to make stuff
executable - see other emails about the problems of copying files and
losing vital info in the process)
mkdir build
cd build
../src/configure
make
cp squeak .libs {my destination}

done!

Once you have done this you should find you have a 'FileCopyPlugin'
which _ought_ to do the file copying properly next time and obviate
the need for the permissions changing. We really need to improve the
file system code.
> 
> A volunteer to discombobulate the Makefile.in for the CVS tree would
> no doubt be gratefully accepted.
I'm certain the makefiles stuff needs tidying up. I commented every
change I made with 'tpr' - or at least tried to. An expert can probably
make it much neater. Please do so....
> 
> Tim, did I get that about right?
Pretty much.

Building on a Mac ought to be similar, but Apple seem to delight in
making programming difficult. I know it _can_ be done because
John has been building the relese MAc VMs with it since goodness
knows when.
Windows is not something I can test personally since I haven't used a
'doze machine in five years or maybe more. Craig was able to get VMMAker
running in about an hour a few months ago and the results of that are in
the SF platform tree.

 tim
-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
To err is human; to forgive, beyond the scope of the Operating System.





More information about the Squeak-dev mailing list