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