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
|