[SF][VM] SF for VMs: Phoenix out of ashes?

Tim Rowledge tim at sumeru.stanford.edu
Thu Feb 8 17:26:51 UTC 2001


In message <F539F53ECAF5D111B73D00805F65BAE601101DEF at WDIGL003>
          "Raab, Andreas" <Andreas.Raab at disney.com> wrote:

> Stephan,
> 
> I see your enthusiasm but I have reasons to think that it is unfounded. Have
> you ever actually thought about why the first SF setup was not accepted by
> any of the major VM maintainers?! While I can't speak for the others I can
> certainly tell you why I have resisted using it, and will probably continue
> to do so.
My reasons were basically

a) the tools issue ( I had to move over to linux to use the ssh access
to upload stuff, which is easy enough but just gets in the way)

b) who can write to the repository

c) most importantly (at the time) the code organisation was pathetic and
simply would not fit sensibly to provide a clean repository that
could serve everyone.

a) can be worked around various ways, and indeed maybe SF is not
the right place to keep stuff if the tools issue annoy us - any CVS
server would do the job ultimately

b) SF could be restricted to allow write only for a few people and I
assume it can be controlled reasonably precisely. I would guess that a
plausible mode d'emploi woud be to allow 'others' to write to new
branches but only allow the deities to declare
versions/levels/releases/whatevertheyarecalled.

c) I think I have found a decent answer to, and it ought to make it
quite simple to at least _try_ to build a single code tree for all
platforms. Where that tree is kept afterwards, I could barely care
about, but I think it would be very helpful for all of us if there were
a single place that could provide some reference. If nothing else, it
might provide a reminder and a means to notify people when some change
is made to the VM code; like adding
ioMacGetIrrelevantDetailsAboutPowerSupplyCableColour() for example.

There is no need whatsoever to have every minute change that we make
available to the public in between releases, but it might help in
developing new vm bits to have a convenient place to point other
deveoplers to, it is certainly nice to have a backup site that does all
its own admin, and I think it could encourage useful contributions from
others by giving some assurance that they can get recent code to work
from instead of spending time working on obsolete code and then finding
their work is going to take a major re-porting effort to get into a
sudden new release.

Perhaps if I explain my suggested code tree a little it might help:-

I have a tool that assembles a code tree for a particular
platform/plugin configuration from the stuff in the image and from a set
of directories already on disk. The RESULT of the assembly looks like

...src/
	building place/ {arranged by makefiles etc, platform specific}
	plugins/
		{all the plugins to be built _externally_ for this config}
		BitBLtPlugin/
		Squeak2DPlugin/
		etc
	vm/
		{all the vm and internal plugins code}
	utils {whatever, unix makefile stuff etc, anything needed}

and anyone can work out how to build from that; changing the unix
makefiles was tedious to a non-expert, but didn't really take much.

The SOURCE of the tree is, as mentioned, both files-on-disk andthe
image. The disk layout is

..platforms/
	unix/
		{a directory for each supported plugin that needs platform specific
code}
		AsynchFilePlugin/
		etc
		{directories for any extra hand written plugins}
		Profile/
		etc
		vm/
			{plat stuff for the core vm }
	RiscOS/
		{ditto}
	mac/
	etc

To declare that a platform cannot support a particular plugin, simply
don't have a directory for it.

It's very simple, trivially extendable to any number of platforms etc.

tim


-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Fractured Idiom:- AMICUS PURIAE - Platonic friend





More information about the Squeak-dev mailing list