cg at home.cdegroot.com (Cees de Groot) is widely believed to have written:

> I've tried VMMaker and Tim's platforms zip file, but that had all sort of
> problems with paths and a broken configure; the platforms/ from SourceForge
> are much better, but the makefile is not updated for the plugins (a line
> '@auto_make@' lingers in the generated Makefile). Could someone help me in
> building My Own Hacker VM?
There has recently been a minor change in the file organisation that
VMMaker produces, which might explain your problem. Lex persuaded me
that a good solution to problems relating to some plugins that really
need their own makefile (or makefile.inc, whatever) would be to assemble
internal plugins into a subdirectory of the /src/vm directory rather
than (as previously) smooshing them all into the/src/vm directory.
Obviously this requires some rehashing of the makefile stuff, which Lex
was in the process of commiting to SF last I heard. I also managed to
fail to upload the new VMMajer changeset to my website due to some
terrible brain failure (sleep, probably).

So, it is quite possible that things are not in perfect state right now;
I _have_ now got the new changeset at
http://sumeru.stanford.edu/tim/pooters/SqFiles/deltas/VMMaker-3-2-version4.1.cs
and I hope that Lex can tell us thathe has finished updating the SF
files. The platform zip on my website is hopelessly out of date and
should not be used - I've just deleted it for safety in future.

For what it's worth, the makefile I have on my machine doesn't have this
errant line, which appears to be something to do with
the generated /src/util/mkMake - is it plausible your copy is not
executable for example? Remember that Squeak copies the files and
completely loses all permissions and meta-info. That might cause the
makefile assembly process to go wrong.

There has been some whining about vmmaker over recent days but the only
substantive actual problem mentioned is one I pointed out about a year
ago myself - copying files makes editing platform files problematic (you
have to remember to edit the right ones, then hit the button to have it
moved to the right place). I've never been very bothered about it
personally and it is an artifact of trying to make it easy to write a
script (like the autoconf type of script) that can work out from a
simple directory tree what bits go where. Of course, more experienced
writers of such scripts can cope with more complex situations, so maybe
it is possible to avoid this file copying altogether.

I can think of two plausible approaches:-
a) use links
b) use a split directory tree and slightly sneakier makefiles/scripts

a) is possible on all four of the mainly active platforms as far as I
can discover. Using links would allow makefiles and scripts to stay
relatively simple.
b) would result in makerules somethinglike
fooplugin.o: ../src/vm/intplugins/fooplugin/fooplugin.c
../platforms/unix/plugins/fooplugin/sqUnixfoostuff.c
../platforms/Cross/plugins/fooplugin/fooplugin.h
etc  - which I suppose is not a lot different than what we get now. The
one bit that worries me a little is the care needed with specifiying
the include file lookup paths so we make sure exactly the right stuff is
included. Can you tell that I've had trouble with this in the past?

The likely simplest approach is to use the split tree, since adding file
links is actual work and we don't want to have to do any of _that_
stuff. What do makefile makers think?

tim

-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Useful random insult:- Doesn't have the sense God gave an animal cracker.