"Rob Withers" <rwithers12 at mediaone.net> is widely believed to have written:
Thanks for trying this out so quickly Rob.

> Here is a final cleaned up version.  A few fixes, plus I use the FileMenu to
> ask for a saveConfig file.
> 
> I got the unix version to build and run, with BitBltPlugin internal.
That problem really confuses me. I've built all my vms with everything
external for over a year now, never getting this particular problem.
Mac, Acorn, linux, I think Craig built some that way forWin32.

>   I get
> a failure to load the Security module because of an undefined symbol:
> #ioCanDeleteFileOfSize.  When I build with all plugins external, the display
> never refreshes and I get a continuous output of the SecurityPlugin failure,
> until a stack overflow of some kind.
Foo - that means I forgot to REMOVE the security plugin stuff from the
unix part of the platform tree. Since the code for unix merely fudged
the calls from before the module was split out  properly, it doesn't
actually do the security stuff anyway. Rip it out! Burn it!
`rm -rf platforms/unix/plugins/SecurityPlugin`

> 
> 2 other problems under unix.  As Tim points out in the source, file copy
> doesn't preserve file permissions.  therefore, you have to chmod the
> following files:
>     - src/configure
>     - src/util/*
After you've suffered the first time, there shuld be a FileCopyPlugin
that implements a trivial system call to `cp blah blah` to avoid this.
As my comment in the changeset preamble says "you fix the file  stuff
and I'll fix VMMaker". I believe I heard Craig assert that he had a
nearly done fix for the filenames and paths and so on.

> 
> The other problem is that when we regenerate the vm on top of a prior vm,
> with different plugin plans, then the old plugin files for internal plugins
> stay in the prior location and the Makefile attempts to compile them in both
> places.  We ought to delete plugin files that change their modularization,
> so we can keep the src hierarchy curent.
You're absolutely right. I got into the habit of deleting the entire
'src' directory each time and so never spotted that obvious problem.
Probably it ought to do something like match the list of external
plugins to the directories under src/plugins and deleted the 'wrong'
ones.

W.R.T. the config files, I'm not at all sure that enough info is
includedin them to be truly useful yet. I sort of let the idea wither a
bit. Should have known thatletting it wither would be caught by a
Withers....
Loading a config probably needs quite a bit of checking for validity of
each of the internal and external lists, since it is possible that the
machine you are loading upon doesn't have the same list of plugin code
available. What should happen about the platform name if it differs from
the loader? The paths? I'm sure we can work out something useful though
given time.

One improvment that needs doing is to make the plugins lists multiple
selection lists so you don't have to drag so many times; also a couple
of buttons or menu choices to say 'all internal' or all external' would
help. 

tim
-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Plan to be spontaneous tomorrow.