Hi folks!

Ok, so I want to give dependencies in SM Yet Another Stab. :)

This time around I am going for a *much* simpler approach.

The idea is simple: By analyzing the code in the packages (most are
code, and most are in mcz format I think) we can probably figure out the
dependencies in 95% of the cases (or another round figure).

So if we for each package release on SM knew:

1. What globals it defines (=classes in practice)
2. What globals it accesses that it does not define itself (=classes in
practice)

Then we should quite easily be able to find releases it depends on.

Figuring out 1) and 2) seems to be easily done (even though one could
possibly do it in a naive source code manual scanning method) by
adjusting Monticello (and we also need to support other source code
formats of course) so that it can load an .mcz into a "sandbox" (it
builds classes just like normal, but don't put them in Smalltalk, nor
hook them up as subclasses in forreign super classes - even though I am
uncertain about if that can disturb compilation).

I have done the above and it seems to work without having tested it
thoroughly. So why do we compile stuff? It is because otherwise it gets
hairy to figure out what references are actually globals (think class
vars, class inst vars, pool dicts, inheritance etc).

So the SM server can then "scan" all releases in its server side cache
using the above technique, build some dictionaries and then hopefully
automatically be able to figure out plausible dependencies.

If we match this with a bit of user controlled policy and questions that
we can ask the user - we might get something nice, simple and automatic.

regards, Göran