[Vm-dev] Putting internal and external generated plugins in a common directory (was: VMMaker-oscog issues on RISC OS)

tim Rowledge tim at rowledge.org
Wed Apr 10 17:42:58 UTC 2013

On 09-04-2013, at 8:41 PM, "David T. Lewis" <lewis at mail.msen.com> wrote:
> On a related (?) note, I would like to ask if the RISC OS build could be
> changed to allow all plugins (whether internal or external) to be generated
> to a single source directory, i.e. 
>  src/plugins/FilePlugin/
>  src/plugins/OSProcessPlugin/
> Instead of:
>  src/vm/intplugins/FilePlugin/
>  src/plugins/OSProcessPlugin/

Absolutely no problem at all; I only ever used external plugins anyway so all it means to me is a simple name change somewhere in the verbiage-tangle that is the makefile.

I can't even remember with any precision why we had separate internal/external directories originally; I think it was something Andreas used as a way to discriminate something about building the plugins before the code was made to be the same for both ways? Like a lot of the apparent strangeness of how VMMaker works it was a matter of compromise between several idiotic OS's (remember this was 15 years ago) being maintained by several headstrong, irritable, opinionated geeks, dealing with a codebase that was up till then largely managed as an ad hoc patching of a set of 'files' kept as comments in the image and local platform specialisations on individuals' machines.

I originally split things up into so many places as away of keeping different things tidy, because, well, tidy. Keeping generated code separate from static code made it reasonable to programmatically delete all the generated code to clean out and re-generate, as well as test the file date and use that to work out which ones might need re-creating. (The extra little pain there was Andreas insisting that he wanted Windows generated code to go into the same place as his platform specific code) I also wanted to avoid copying static code files - which might have made makefiles simpler - since you just know that one will edit the wrong copy, delete it and then wonder what the hell happened to break all your work. Oh and of course the Squeak file copying method was utterly fucked for any system that had any sort of meta-data associated with a file, like dates, permissions, what have you.

 I would have replicated the directory layout that Eliot used for BrouHaHa, with nice distinct directories for all the parts and a directory of links to all the files actually needed for a particular version - except only unices had working links back then and of course Squeak had no link related stuff to allow creating such directories. I always assumed both would come pretty soon. So much for *that* prediction.

tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
If at first you don't succeed, call it version 1.0

More information about the Vm-dev mailing list