SM deps: Yet Another Stab
ducasse at iam.unibe.ch
Fri May 26 20:23:07 UTC 2006
> Ok, so I want to give dependencies in SM Yet Another Stab. :)
Now I have a stupid question. Why trying to guess the dependencies?
Goran what I would love to have is a simple way to express dependencies.
After we can find a smart way to guess then.
For now I would really like to be able to give an MCZ package and
that my user
does not have to fight the dependencies hell alone.
> 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
> 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
> 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
> we can ask the user - we might get something nice, simple and
> regards, Göran
More information about the Squeak-dev