VM source stucture

Tim Rowledge tim at sumeru.stanford.edu
Sat Sep 30 00:43:51 UTC 2000


There seems to have been some confusion over recent months about the
layout of the VM sources; all the way back to the time people were
attempting to setup the SourceForge site in fact. I'd like to offer some
suggestions for a solution to the problem.

One of the problems is that the files need to separated along several
axes.
a) generated vs 'hand-written'
b) portable vs platform specific
c) main VM vs external plugin
d) a tree of platform specifc files for the large list of platforms we
support.

I'm not altogether convinced that a) is a very useful split, but I don't
think it matters much either way. Remember that quite a few of the files
that are generated by running the assorted VM making methods are
actually handwritten in practice (sq.h, sqPlatformSpecific.h etc).

b) & d) is quite important as an organising split to help make it clear
what files are platform specific. In a system like sourceForge it would
also be important for separating the groups of files for the different
machines. Here we would want a tree something like:-
src/
    portable/
        interp.c
        sq.h
        etc...
    platform/
        acorn/
            sqRPCWindow.c
            etc...
        beos/
        dos/
        epoc/
        mac/
        windows/
        unix/
        etc...

c) is one aspect that I feel a lot of people have completely missed
recently. When you want a plugin to be external it has to be generated
seperately from the main vm (by removing it from the list in Interpreter
class> tranlsate:doInlining:forBrowser:) and the internal plugins. The
code for any external plugin will be generated in a directory named
after the plugin; thus FooPlugin will be created with
    FooPlugin translate
which will result in a partial tree like this:-
    FooPlugin/
        FooPlugin.c
        FooPlugin.h
If FooPlugin is generated as an internal plugin, then you leave it in
the list mentioned above and the files would be placed in the same
directory as intep.c etc.

Now, an interesting question is what to do with the platform specific
files that go along with the generated plugin files? For example,
FilePlugin typically requires sqAcornDirectory.c to go with it (on my
Acorn). I suggest that these files need to be in the same directory as
the generated files _wherever_ that is. This should make automagically
working out what needs compiling in what manner easier; the older unix
`autoconf ` stuff managed to work it out on this basis  quite easily so
I imagine most other similar systems would be happy as well. It would
completely obviate any need for some handwritten list of what is an
external plugin and what is internal.
So, some way to work out where to move the plugin-companion files would
be needed. Assuming we know the names of the plugin-companion files, we
can look to see where the 'root' plugin file is and move the companions
to be in the same place. To know which files belong together I suggest
renaming files to include the plugin and platform with which they need
to be associated.
Thus we might have:-
    FilePlugin.c
    FilePlugin.h
    FilePluginAcornDirectory.c
    FilePluginAcornURL.c
etc.
If the file plugin is generated for internal linking then the two Acorn
specifc files would be moved to the same directory that FilePlugin.c &
interp.c live in. If it were generated for externla linking, then they
would be moved to the FilePlugin directory - again, the same location as
FilePlugin.c. This should be simple for anyone to follow.

Of course, this arangement of files is not the same as that shown above!

To compile on any particular platform (using my Acorn as an example
again) we need a tree more like:-
acorn/
    src/
        vm/
            interp.c
            sq.h
            B2DPlugin.c
            B2DPlugin.h
            SurfacePlugin.c
            sqAcornWindow.c
            etc...
        plugins/
            FilePlugin/
                FilePlugin.c
                FilePlugin.h
                FilePluginAcorn.c
                FilePluginAcornURL.c
            SocketPlugin/
                SocketPlugin.c
                SocketPlugin.h
                SocketPluginAcorn.c
and similarly
windows/
    src/
        vm/
        plugins/
etc/

How do we get from one form to another? Well, you only need the one (the
latter) form on your machine to compile a vm. Any system with links
between files could support both forms trivially; the linux system
supporting SourceForge should have no problems with having trees for
each platform that are basically nothing more than links across to files
laid out in the /portable /platform tree shown above.

Such a linking scheme has advantages for future flexibility; when the J3
stuff needs to be included there will be CPU specific files as well as
OS specific files. By simply adding directories for each of these and
linking to suitable files we would be able to rapidly add support for
(say) an Alpha powered MacOS platform.

So what needs doing to change things?
- a tool to make it easy to choose which plugins are internal or
external (though you will I'm sure remember that I claim there is no
virture in having any plugin internal on any machine that can support
external plugins) - Rob Withers and Stephan Rudlof have done most of the
work for this.
- rename the files to make the names regular and easily parsable
- add code to move plugin-companion files to the same place as the
plugin-root file
- change the make files to be able to tell the difference between the
vm/ tree and the plugins/ tree, much as the release 2.7 unix autoconf
could do.
I suspect that many IDEs will not be able to do much with this last
point - I know that my Acorn can't do it automagically, but then I have
makefiles already sorted out for all-external plugins anyway :-) It just
means that the platform janitor will have to do a little manual
makefile/project file/whatever altering.

tim







More information about the Squeak-dev mailing list