Ross Boylan <RossBoylan at stanfordalumni.org> is claimed by the authorities to have written:

> I am trying to understand the interrelations between the different external 
> and internal plugins, with an eye toward an enhanced Win32 build for 
> VMMaker.  I am concerned both with the names of files and functions.

OK, I assume you've looked up all the pages relating to VMMaker on the
swiki; some of your questions _ought_ to be answered therein. Since
you've clearly worked out the essential workings of VMMaker to have
produced your enhancements, I'm going guess that they need improving.
> 
> Here's my current working model.  Is it correct?
> 1. The same file or function name may appear in two different plugins.
Certainly the same function name can appear in many plugins; in fact
most plugins have initialise/unload/version functions. As for filenames,
you pretty much answered yourself with Q7. Until recently there was no
practical problem with a single file namespace.
  
> 2. Consquently one should use a separate directory for each plugin.
The main reason I chose to split plugins up was organisational. It
seemedto me that it wuld help to have the intended structure at least
loosely reflected in the file tree layout. For example, this makes it
very much simpler to write scripts to work out which plugins to make in
which manner, as in the unix confugre stuff. It turns out that it
provides potentially useful insulation between plugins and avoids having
to worry about the filenames you choose when making a new plugin. It
also appears to be useful for allowing a specialised sub-makefile if
that is helpful.

> 3. The relevant include files for each plugin include those in its own 
> directory and the general VM files only.
This is a little tricky to explain, especially with the recent change
towards _not_ copying files from the /platforms tree into the/src tree.
Let's see if I can make sense of it:-
for FooPlugin, the relevant files comprise
a) those in either src/plugins/FooPlugin (for an external plugin) or
src/vm/intplugins/FooPlugin (for an internal plugin, assuming support
for the intplugins dir is up to date)
b) those in /platforms/{your platformname}/plugins/FooPlugin,
assuming any platform specific fiels are required. If they are, the
plugin class must implement #requiresPlatformFiles to return true.
c) those in /platforms/Cross/plugins/FooPlugin, assuming any
cross platform files are required. If they are, the plugin class must
implement #requiresCrossPlatformFiles to return true. Note that it is
quite feasible to require both - see B3DAcceleratorPlugin.
d) those headers in /platforms/Cross/vm and /platforms/{your platform
name}/vm  required by the C files.


> 4. The build for the core VM should not include headers for any of the 
> plugin directories.
By strong preference, correct. The core vm should stand on its own.

> 5. Plugins access other plugins only through calls to the interpreter 
> proxy, so do not need headers from the other plugins.
This should be true. I believe that at the moment OSProcessPlugin needs
access to the FilePlugin headers and maybe the Socket ones?

> 6. All the above statements apply equally to external or internal plugins.
That is the intention.

> 7. Until recently, the namespace collision issues were theoretical, so it 
> was possible to get away with a looser approach.  However, the separations 
> outlined above are the desired ones going forward.
That is my understanding.

> 8. For internal plugins, function names are prefixed by the module name to 
> make them unique (not sure where that happens).
In the code generation process within the image. (See
CCodeGenerator>cFunctionNameFor:) This makes sure that FilePlugin's
initialisemodule() is not confused with SocketPlugin's
initialiseModule() in the table of internal plugin functions (see the
generated file sqNamedPrimitives.h).
> For external plugins, the names are left as is; the lookup mechanisms specify
> the module and function name, so there is no problem.
Correct.
> 
> As a somewhat separate issue, can anyone comment on directory trees 
> appearing under an individual plugin directory?  It seems in some cases the 
> plugins themselves have components.
This should work ok. For a separate library, for example, this is a good
thing since it separates out the code that is 'ours' from 'theirs'.

tim
-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Strange OpCodes: RSC: Rewind System Clock