Jimmie Houchin <jhouchin at texoma.net> wrote:

> 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. ;)
Good chap. IIRC the help should also direct you to the swiki pages.
> 
>  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.
Hmm, I wouldn't say _should_ so much as normally seems to end up that
way. As I said, the VMMTool lets you edit the paths if you want to. I
suppose there is probably some explanation that could be added.

[snip]
> 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.
It's actually hard to provide a general answer here. The 'normal'
procedure is that the generated code is put in a tree called 'src' in
your working directory, the handwritten code is in 'platforms' and
the makefiles deal with it.

Things get more complicated in the details and we should probably try to
simplify.
Acorn copies a makefile from platforms/RiscOS/misc/ToCopy so that it
runs from the root of the src subtree. All the interior paths assume
that layout, which is fine since only a few people (honest, not just me)
compile RiscOS vms.
Mac seems to keep the makefiles etc in platforms/Mac OS/vm/Developer and
I have no idea if it moves them or runs them in place.
Unix keeps all the make stuff in platforms/unix/misc and you have to
make a 'bld' directory and invoke autoconf or something to copy/create
makefiles.
Win32 also use plat.....misc but the Win32 subclass of VMMaker chooses
to generate the code into the plat subtree for reasons I don't recall
but that Andreas found good and sufficient at the time.


> Does where the generated source directory is make much difference?
Not to VMM but crucially to the makefiles. Unless you have a tool that
generates the makefile like unix, in which case you can specify
different directories if you know the incantation. RiscOS for example
simlpy would build if you changed the paths, unless you manually eidt
the makefile.

> 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?
See above; sometimes yes sometimes no but the generated code and
handwritten code are both used somehow!
> 
>
> 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.
Too naive unfortunately. The FindPath can potentially end up hitting a
connection to a server - or two, or three and go down their filesystems
searching. That's why the warning.... 


> 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. :)
I _think_ there is information on this on the swiki pages but I would be
the first to agree that they could do with cleaning up. Someone with
some spare time could do us all a service by doing some editorial work.

tim
--
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
A list is only as strong as its weakest link.  - Don Knuth