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

Cool!

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.

Stef

>
> 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
>