Got VMMaker now what?

Jimmie Houchin jhouchin at texoma.net
Tue Aug 12 22:28:04 UTC 2003


Tim Rowledge wrote:
> Jimmie, the first thing you should do is RTFM; in the VMMakerTool,
> press the help button. Really, it helps :-)

True. However, I did that twice before sending the original message.
Now a third time after your admonition. :)
And yes as per its instructions I did read the class comment. ;)

 From a naive, never used VMMaker and have no idea what to expect or 
what it (VMMaker) expects, it was not apparent to me that the generated 
src directory should be in next to the cvs source directory.

> VMMaker does not build any plugins that have declared that they need
> outside, handwritten, code unless it finds some evidence of that code
> existing. The current simple test is to look for a directory of a
> suitable name. The path to that code is by default {working
> dir}/platforms. It can be changed easily in the VMMTool. Similarly the
> default path for the generated sources is {working dir}/src and it too
> can be altered.

Correct. This is the point I went and installed cvs for my system and 
then retrieved the source from Sourceforge.

Yes the default dir is what I had. I did not know whether or not VMMaker 
would read the sources from the source directory and generate new files 
in the generated sources directory or how VMMaker was handling the 
situation.

I am reading and re-reading the Help and Class comment as I compose this 
message.

Does where the generated source directory is make much difference?
Naively from visual inspection it appears as if the generated source 
ends up being inside of the platforms directory? Is the generated source 
directory at all used in the compilation process?

Naively I thought all source would end up in the generated sources 
directory and from there the build process would occur.

> So far as I know there are no technical reasons to prefer internal
> plugins over external nor vice versa. I have heard arguments that it is
> easier to get users to install things corectly when all/most plugins are
> internal because then they are all in the one file. For OSs with
> sensible bundling mechanisms this is moot. The *nix makefile seems to
> cope well with any mix since the shell code can detect the directories
> and assemble the appropriate rules. Acorn builds everything external,
> Mac uses almost all internal and a couple external and so on. 

Okay. My first build any, will be all internal.

One comment on the Find Path method.

It claimed it may take a while. Not a problem.
It seems (maybe naively) that most platforms have a general place(s) 
where source resides. I know there can be a little variety.
I place mine in /usr/local/src others might have used /opt/... etc.
But still it is in general for most cases a relatively small finite 
number. Maybe we can create a list of the most common places for source 
to reside to search first. Then upon failure search from root.

I would imagine this would get most of the cases most of the time.

Possibly after doing this possibly prompt the user if there is a 
difference between the working dir and the platforms dir with regard to 
the generated sources dir if they would like to change the generated dir 
  to the suggested location?

With regard to the platforms dir. Maybe we could have some suggested 
locations for it if the user (like me) did not have the sources and had 
to go retrieve them. I chose /usr/local/src because it seemed like a 
reasonable choice, not because of any particular knowledge or 
understanding. :)

Just some thoughts.

Anyway, thanks for all the help.

Jimmie Houchin



More information about the Squeak-dev mailing list